370 likes | 521 Views
Question Accommodation and Information States in Dialogue. Staffan Larsson, Robin Cooper, Elisabet Engdahl Department of linguistics G ö teborg University, Sweden. Structure of this talk. Key concepts Introduction to the GoDIS system Information-seeking dialogue Question accommodation
E N D
Question Accommodation and Information States in Dialogue Staffan Larsson, Robin Cooper, Elisabet Engdahl Department of linguistics Göteborg University, Sweden
Structure of this talk • Key concepts • Introduction to the GoDIS system • Information-seeking dialogue • Question accommodation • Task accommodation • Focus and information states
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 (->David Traum)
GoDiS: a dialogue system • Implemented using the TrindiKit • Information-seeking dialogue • Information state based Ginzburg’s notion of Questions Under Discussion (QUD) • a stack (or partially ordered set) of questions which have been raised and can be answered elliptically • Dialogue plans to drive dialogue • QUD and dialogue plans provide the right level of complexity for information-seeking dialogue • Simple “optimistic” grounding strategy • Question and task accommodation • Focus intonation based on information state contents (partially implemented)
GoDiS & TrindiKit domain-specific GoDiS system domain & language resources QUD-based dialogue theory (IS, rules, ...) generic GoDiS system TrindiKit information state approach
GoDiS features (cont’d) • Adapted for travel agency and autoroute domains (also being adapted to cinema booking, and to function as dialogue interface to a handheld computer and a mobile phone) • Lexicons for English and Swedish; lexicon can be switched dynamically
control input inter- pret update select gene- rate output Information State lexicon data- base domain
Sample GoDiS information state AGENDA = { findout(?return) } findout(?x.month(x)) findout(?x.class(x)) respond(?x.price(x)) PRIVATE = PLAN = BEL = { } TMP = ( same as SHARED ) dest-city(paris) transport(plane) task(get_price_info) BEL = SHARED = QUD = < x.origin(x) > LM = { ask(sys, x.from-city(x))}
Sample GoDiS update rule • integrateAnswer • 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) apply(Q, A, P) add(SHARED.COM, P) eff:
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
Typical human-computer dialog S: Hello, how can I help you? U: I want price information please 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
Dialogue plans for information-seeking dialogue • Find out how user wants to travel • Find out where user wants to go to • Find out where user wants to travel from • Find out when user wants to travel • … • Lookup database • Tell user the price
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 ...
Accommodation • Lewis (1979): If someone says something at t which requires X to be in the conversational 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, as parts of the conversational scoreboard / information state
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 • Requires that the number of possible matching questions is not too large (or can be narrowed down by asking clarification question)
Update rule for question accommodation QuAcc 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:
Task accommodation • 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 (in the domain resource) a task and corresponding plan containing a matching question; • accommodate the task and load the appropriate plan • Similar to plan recognition, but no dynamic plan reconstruction or assumption that the full plan is shared
Update rule for task accommodation taskAcc - An answer move matches a task if the plan contains a question matching the answer - More complex version generates clarification question if the number of plans > 1 in(SHARED.LM, Move) domain :: match_task(Move, Task, Plan) pre: add(SHARED.BEL, task(Task)) set(PRIVATE.PLAN, Plan) eff:
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?
Why accommodation? • Generality • no need to distinguish requested and non-requested (but relevant) information • single rule for integrating answers • Theoretically motivated concept, with independent justification • Easy to implement, given information state approach
Extensions • Questions can also be reaccommodated • if the user answers a question which has already been answered: • remove proposition from shared beliefs, and put question back on QUD • Extend to domain where there are many plans containing a question matching a given answer • e.g. menu-based dialogue • Focus intonation and QUD
Focus and information states • Focal Question Presupposition (FQP) (based on Ginzburg and others): • An utterance with narrow focus on a constituent presupposes a function/question obtained by abstracting over the focussed constituent • Example: • “Jill likes BILL” [like(jill, bill)] presupposes “Who does Jill like?” [?lx.like(jill, x)]
Focal Question Accommodation FQuAcc: interpretation version of FQP “When an utterance occurs which focally presupposes Q, and Q is not topmost on QUD, make Q topmost on QUD” in(SHARED.LM, Move) foc-presupp(Move, Q) ~fst(SHARED.QUD , Q) pre: push(SHARED.QUD, Q) eff:
Interpreting utterances with focus • Example: • A: Are you FLYING to london? • Q = ?(to-city(london)&transport(fly)) presupposes Q’ = ?(lx.to-city(london)&transport(x)), i.e. “how are you getting to london” • B1: Yes • B2: No, I’m taking a TRAIN • ?B3: No [Q’ still on QUD!]
Generating utterances with focus • Generation version of FQP: • When generating Q, and there is a Q’ on QUD such that Q’ is an abstraction of Q over constituent C (Q=Q’(C)), put narrow focus on C
Generating utterances with focus (cont’d) • Example 1: • U: I want a flight please • S: Where city do you want to go to? (Q’) • U: London • S: So you’re flying to LONDON? (Q) [Q=Q’(london); Q’ still on QUD, so put focus on “London”] • Example 2: • U: I want to go to London • S: How do you want to travel? (Q’) • U: A flight please • S: So you’re FLYING to London? (Q)
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 • Implemented in GoDiS using the TRINDIKIT software package(www.ling.gu.se/research/projects/trindi/trindikit.html) • Focus can be generated and interpreted using information state, esp. QUD
Want more? • Menu-based dialogue • generating focus based on Global QUD • Clarification questions
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
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.
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
Question and task 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.
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
Global QUD • The QUD in GoDiS is very local • GoDiS could be extended with a global QUD, containing all questions which have been asked so far • This would enable e.g. reraising of questions (See Cooper et. al., Gotalog 2000) • Also, a global QUD could be used in generation of questions with focus intonation
Generating questions with focus II • If a question Q1 is to be asked, and there is a parallel question Q2 in GQUD, put focus on the part that differentiates Q1 and Q2 • lx.to-city(x) parallell to lx.from-city(x) • Example: • S: What CITY do you want to go to? • U: Paris .... • S: What city do you want to go FROM?
Generating questions with focus II (cont’d) • Extension to focal question presupposition: • A question Q with narrow focus on C presupposes a parallell question Q’’ which differs from Q by having C replaced by some B • Does accommodation apply? • What about propositions? • What, exactly, does “parallell” mean? (cf. Pulman 1998 for a formal account of parallellism for propositions)