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

The information state approach 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

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 Before an answer can be integrated by the system, it must be matched to a question on QUD Includes dialogue plan

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 dou 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: hi U: flights to paris S: when do you want to travel? U: april, as cheap as possible S:

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

Question accommodation If questions are part of the information state, they too can be accommodated Information state update rule for Question accommodation: 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

Question 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 (DMTS?), 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.

Question accommodation in menu-based dialogue U: John S: John’s number is Do you want to call John? U: Yes S: Calling John.

From manuals to instructional dialogue

From manual to dialogue plan

Advantages of dialogue mode for manuals

From menus to dialogue plans Plan for searching phonebook: “What name do you want to look up?” “Do you want to call N?” Does user want to call Call N