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 = < x.origin(x) >

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 dialogS: 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 dialogueS: hiU: 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 planS: 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 phonebookS: What name do you want to search for?

U: JohnS: John’s number is 0312345566. Do you want to call John?

U: YesS: 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 correctS: 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

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

DOMAIN DIALOGUE

precondition: P instruct(check(P))

action: A instruct(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 (www.ling.gu.se/research/projects/trindi/trindikit.html)