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 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

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

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

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

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

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: 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 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

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 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

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

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

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

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?

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 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 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 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

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

From manual to dialogue plan Plan conversion table DOMAINDIALOGUE precondition: Pinstruct(check(P)) action: Ainstruct(exec(A)) conditional: if C then A else B findout(C); if C then instruct(A) else instruct(B)

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

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 (