1 / 24

An information state approach to natural interactive dialogue

An information state approach to natural interactive dialogue. Staffan Larsson, Robin Cooper Department of linguistics G ö teborg University, Sweden. The information state approach – key concepts.

ronald
Download Presentation

An information state approach to natural interactive dialogue

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. An information state approach to natural interactive dialogue Staffan Larsson, Robin Cooper Department of linguistics Göteborg University, Sweden

  2. The information state approach – key concepts • Information states represent information available to dialogue participants, at any given stage of the dialogue • Dialogue moves trigger information state updates, formalised as information state update rules • TRINDIKIT: software package for implementing dialogue systems; based on the information state approach to dialogue management

  3. GoDiS – a dialogue system • Implemented using the TRINDIKIT • Adapted for information-seeking dialogue, menu-based dialogue, and instructional dialogue

  4. Information state in GoDiS • Based on Ginzburgs notion of QUD (Questions Under Discussion): a partially ordered set of questions which have been raised and are under discussion • Includes dialogue plan

  5. Sample GoDiS information state findout(?x.month(x)) findout(?x.class(x)) respond(?x.price(x)) PLAN = PRIVATE = AGENDA = { findout(?return) } dest(paris) transport(plane) task(get_price_info) COM = SHARED = QUD = < x.origin(x) > LM = { ask(sys, x.origin(x)) }

  6. Sample update rule • downdateQUD • Before an answer can be integrated by the system, it must be matched to a question on QUD in(SHARED.LM, answer(usr, A)) fst(SHARED.QUD, Q) relevant_answer(Q, A) pre: pop(SHARED.QUD) reduce(Q, A, P) add(SHARED.COM, P) eff:

  7. Information-seeking dialogue • User needs to give information which enables the system to perform its task (booking a ticket, providing price information etc.) • Typical dialogue system behaviour: user must give information in the order determined by the system questions

  8. Typical human-computer dialog S: Where do you want to go? U: Paris S: How do you want to travel? U: A flight please S: When do you want to travel U: April S: what class did you have in mind? … S: The price is $123

  9. Dialogue plans for information-seeking dialogue • Ask how user wants to travel • Ask where user wants to go to • Ask where user wants to travel from • Ask when user wants to travel • … • Lookup database • Tell user the price

  10. Typical human-human dialogue S(alesman), C(ustomer) S: hi C: flights to paris S: when do you want to travel? C: april, as cheap as possible ...

  11. Accommodation • Lewis (1979): If someone says something at t which requires X to be in the conversa- tional scoreboard, and X is not in the scoreboard at t, then (under certain conditions) X will become part of the scoreboard at t • Has been applied to referents and propositions

  12. Question accommodation • If questions are part of the information state, they too can be accommodated • If the latest move was an answer, and there is an action in the plan to ask a matching question, put that question on QUD

  13. Update rule for question accommodation accommodateQuestion in(SHARED.LM, answer(usr, A)) in(PRIVATE.PLAN, findout(Q)) relevant_answer(Q, A) pre: delete(PRIVATE.PLAN, findout(Q)) push(SHARED.QUD, Q) eff:

  14. Task accommdation • In some cases, the system may not even know what task the user wants the system to perform • If latest move was an answer, and there is currently no plan, find a task and corresponding plan containing a matching question; accommodate the task and load the appropriate plan • If there are several matching plans, ask clarification question

  15. Question and task accommodation in information-seeking dialogue S: hi U: flights to paris • system finds plan containing appropriate questions, and loads it into the plan field in the information state • system accommodates questions: how does user want to travel + where does user want to go, and integrates the answers “flight” and “to paris” • system proceeds to next question on plan S: when do you want to travel?

  16. Menus vs. dialogue • Menu-driven interaction is ubiquitous: automated cinema ticket booking, mobile phones, computers, video recorders… • Often tedious and frustrating; hard to find what you want; inflexible • Can be straightforwardly implemented as dialogue systems, but you still have to descend the menu structure one node at a time

  17. Typical menu-based dialogue S: What do you want to do? U: Search the phonebook S: What name do you want to search for? U: John S: John’s number is 0312345566. Do you want to call John? U: Yes S: Calling John.

  18. Plans derived from menu structure • Toplevel: ask what user wants to do (phonebook, messages etc); load corresponding plan • Phonebook: ask what user wants to do (search phonebook, add to phonebook etc); load corresponding plan • Search phonebook: ask for name; if name exists, inform of number; ask if user wants to call number; if yes, call number

  19. Question accommodation in menu-based dialogue U: John • system finds several plans containing a request for a name, and asks the user which one is correct S: Do you want to search the phonebook for John? U: Yes, and call him up • system accommodates answer to the question whether user wants to call S: John’s number is 0312345566. Calling John.

  20. Strategies for asking clarification questions • Ask a series of yes/no-questions, one for each alternative; OK if user can interrupt • Ask wh-question; if user does not provide answer, list alternatives • Ask alternative question

  21. From manuals to instructional dialogue • Domain plan is extracted from manual • Domain plan is converted into dialogue plan, including dialogue moves • Surface realisation of moves based on manual • Manual can be reconstructed from domain plan, if system is run in monologue mode

  22. From manual to dialogue plan • Plan conversion table

  23. Advantages of dialogue mode for manuals • User does not have to look in manual, or keep track of the current point • System avoids irrelevant information when the action to be taken depends on a condition • User controls the level of detail; can skip parts already known or ask for more specific instructions if necessary • Grounding and question accommodation

  24. Conclusion • Question and task accommodation support natural interactive dialogue, where user controls in which order information is presented • Information state approach enables easy implementation of question and task accommodation • (in paper: more on instructional dialogue and its relation to manuals) • Implemented in GoDiS using the TRINDIKIT software package (www.ling.gu.se/research/projects/trindi/trindikit.html)

More Related