an information state approach to natural interactive dialogue staffan larsson, robin cooper...
TRANSCRIPT
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)