information action and negotiation in dialogue systems n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Information, action and negotiation in dialogue systems PowerPoint Presentation
Download Presentation
Information, action and negotiation in dialogue systems

Loading in 2 Seconds...

play fullscreen
1 / 53

Information, action and negotiation in dialogue systems - PowerPoint PPT Presentation


  • 103 Views
  • Uploaded on

Information, action and negotiation in dialogue systems. Staffan Larsson sl@ling.gu.se Edinburgh, Jan 2001. Overview. the information state approach & TrindiKit GoDiS – a dialogue system action- and information oriented dialogue negotiative dialogue. TrindiKit.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Information, action and negotiation in dialogue systems' - tuari


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
information action and negotiation in dialogue systems

Information, action and negotiation in dialogue systems

Staffan Larsson

sl@ling.gu.se

Edinburgh, Jan 2001

overview
Overview
  • the information state approach & TrindiKit
  • GoDiS – a dialogue system
  • action- and information oriented dialogue
  • negotiative dialogue
trindikit

TrindiKit

A toolkit for building and experimenting with dialogue move engines and systems, based on the information state approach

the information state approach key concepts
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
  • Update rules consist of conditions and operations on the information state
  • Dialogue move engine updates the information state based on observed moves, and decides on next move(s)
trindikit architecture
TrindiKit architecture
  • The information state is an abstract data structures (record, DRS, set, stack etc.)
  • Modules (dialogue move engine, input, interpretation, generation, output etc.) access the information state
  • DME (Dialogue Move Engine): module or group of modules responsible for integrating and generating dialogue moves
  • Resources (device interface, lexicons, domain knowledge etc.) are hooked up to the information state
slide6

control

DME

input

inter-

pret

update

select

gene-

rate

output

Information State

...

lexicon

domain

knowledge

trindikit components
TrindiKit components
  • A library of datatype definitions (records, DRSs, sets, stacks etc.)
  • A language for writing information state update rules
  • Methods and tools for visualising the information state
  • debugging facilities
trindikit components cont d
TrindiKit components (cont’d)
  • A language for defining update algorithms used by TrindiKit modules to coordinate update rule application
  • A language for defining basic control structure, to coordinate modules
  • A library of basic ready-made modules for input/output, interpretation, generation etc.;
  • A library of ready-made resource interfaces, e.g. to hook up databases, domain knowledge etc.
slide9

Building a system

domain-specific

system

domain knowledge

(resources)

dialogue theory

(IS, rules, moves etc)

domain-independent

DME

TRINDIKIT

software engineering

(basic types, control flow)

building a domain independent dme
Building a domain-independent DME
  • Starting from a theory of dialogue management, decide on
    • Type of information state (DRS, record, set of propositions, frame, ...)
    • A set of dialogue moves
    • Information state update rules, including rules for integrating and selecting moves
    • DME Module algorithm(s) and basic control algorithm
  • The DME is domain independent, given a certain type of dialogue
    • information-seeking
    • instructional
    • negotiative
    • ...
domain specific system
Domain-specific system

Build or select from existing components:

  • Resources, e.g.
    • domain (device/database) interface
    • dialog-related domain knowledge, e.g. plan libraries etc.
    • grammars, lexicons
  • Modules, e.g.
    • input
    • interpretation
    • generation
    • output
trindikit features
TrindiKit Features
  • Explicit information state datastructure makes systems more transparent
  • Update rules provide an intuitive way of formalising theories in a way which can be used by a system
  • Domain knowledge encoded in resources; the rest of the system is domain independent
features cont d
Features, cont’d
  • Allows both serial and asynchronous systems
  • Interfaces to OAA (only available for UNIX)
  • Generic WWW interface
  • Runs on UNIX, Windows, Linux etc.
  • Needs SICStus Prolog
  • Version 2 .0 is available, next version expected early 2001 (SIRIDUS)
  • www.ling.gu.se/projects/trindi/trindikit
extensions
Extensions
  • Modules for speech input and output, for using off-the-shelf products (SIRIDUS project)
  • GUI for increased usability and overview, including tools for building systems
  • Extend libraries of ready-made modules and resources
  • Use in new tasks?
    • previously, the main focus has been on dialogue management
    • other tasks may require additional components
systems developed using trindikit
Systems developed using TrindiKit
  • GoDiS and IMDiS – information state based on Questions Under Discussion
  • MIDAS – DRS information state, first-order reasoning
  • EDIS – information state based on PTT
  • Autoroute – information state based on Conversational Game Theory
godis

GoDiS

An experimental dialogue system built using the TrindiKit

godis features
GoDiS features
  • Information-seeking dialogue
  • Information state based Ginzburg’s notion of Questions Under Discussion (QUD)
  • Dialogue plans to drive dialogue
  • Simpler than general reasoning and planning
  • More versatile than frame-filling and finite automata
slide18

control

DME

input

inter-

pret

update

select

gene-

rate

output

Information State

data-

base

lexicon

domain

knowledge

sample godis information state
SampleGoDiS information state

AGENDA = { findout(?return) }

findout(?x.month(x))

findout(?x.class(x))

respond(?x.price(x))

PRIVATE =

PLAN =

BEL = { }

TMP = (same structure as SHARED)

dest(paris)

transport(plane)

task(get_price_info)

COM =

SHARED =

QUD = < x.origin(x) >

LM = { ask(sys, x.origin(x))}

sample update rule
Sample 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)

reduce(Q, A, P)

add(SHARED.COM, P)

eff:

typical human computer dialog
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
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
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

...

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

question and task accommodation in information seeking dialogue
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?

an optimistic approach to grounding
An optimistic approach to grounding
  • DPs assume their utterances are understood
    • If A asks a question with content Q, A will update shared.lm with ask(A,Q)
  • If addressee indicates that the previous utterance was not understood (reqRep), backtrack
    • uses the PRIVATE.TMP field, which contains a copy of the SHARED field from before the latest utterance was made
  • The alternative is a pessimistic approach
    • If A asks Q, A will not update shared.lm until B indicates understanding (implicitly or explicitly)
activity based moves
Activity-based moves
  • Moves are determined by the relation of the content to the domain
    • utterance U is an answer if the content A of U is a relevant answer to a question Q in the domain
    • moves are not necessarily speech acts!
  • GoDiS basic dialogue moves
    • ask(Q)
    • answer(A)
    • request_repetition
    • greeting, quit
godis features cont d
GoDiS features (cont’d)
  • Adapted for travel agency and autoroute domains, as well as acting as interface to handheld computer or mobile phone
  • Question and task accommodation to enable mixed initiative
  • Simple “optimistic” grounding strategy
  • Focus intonation based on information state contents
  • Has been extended to handle instructional dialogue (IMDiS)
  • Also being extended to handle negotiative dialogue (SIRIDUS)
problem with current godis
Problem with current GoDiS
  • assumes database always returns exactly one post (price info); not generally true
  • but we want to be able to
    • talk about several flights,
    • allowing the user to ask questions about them,
    • deciding on one of them, and then
    • getting price information
  • Requires negotiation
information vs action oriented dialogue
Information- vs. action-oriented dialogue
  • Information oriented dialogue (IOD) has the primary goal of exchanging information, regardless of how this information will be used in future actions
  • Action oriented dialogue (AOD) has the primary goal of a participant performing or being obliged to perform an action (or plan, i.e. a complex action)
information oriented dialogue
Information-oriented dialogue
  • Information-seeking dialogue (ISD): one DP asks the questions, the other answers them
  • Information-exchange (information oriented) dialogue: both DPs ask questions and provide answers
  • IOD can be seen as a sequence of infoseeking dialogues, possibly with embedded subdialogues
  • shared information is stored in shared.com
action oriented dialogue
Action-oriented dialogue
  • In simple AOD, only one participant becomes obliged/comitted to some action or plan
  • Actions can either be performed ”online” while the dialogue is happening, or they may be stored as a plan to be performed after the dialogue (”offline”)
  • Requires a store of obliged actions in the IS (SHARED.ACTIONS)
negotiative dialogue

Negotiative dialogue

some definitions and ideas

negotiation vs acceptance
Negotiation vs. acceptance
  • Clark’s ladder:
    • 1. A attends to B’s utterance
    • 2. A percieves B’s utterance
    • 3. A understands B’s utterance (grounding)
    • 4. A accepts or rejects B’s utterance
  • Sidner and others sees negotiative dialogue as proposals and acceptance/rejections of proposals
    • this means that all dialogue is negotiative
    • all assertions (and questions, instructions etc.) are proposals
  • But some dialogues are negotiative in another sense, by explicitly containing discussions about different solutions to a problem, and finally deciding on one
    • Negotiation is not Clark’s level 4
two senses of negotiation
Two senses of “negotiation”
  • Negotiation in Sidner’s sense
    • A: I want to go to Paris [propose]
    • B(1): OK [accept]
    • B(2): Sorry, there are no flights to Paris [reject]
  • Negotiation in our sense
    • U: flights to paris on september 13 please [answer]
    • S: there is one flight at 07:45 and one at 12:00 [propose]
    • U: what airline is the 12:00 one [ask]
    • S: the 12:00 flight is an SAS flight [answer]
    • U: I’ll take the 12:00 flight please [accept]
optimistic approach to acceptance
Optimistic approach to acceptance
  • DPs assume their utterances are accepted (and integrated into SHARED)
    • If A asks a question with content Q, A will put Q topmost on SHARED.QUD
  • If addresse indicates rejection, backtrack
    • using the PRIVATE.TMP field
  • No need to indicate acceptance explicitly; it is assumed
  • The alternative is a pessimistic approach
    • If A asks a question with content Q, A will wait for an acceptance (implicit or explicit) before putting Q on top of QUD
negotiativity
Negotiativity
  • Negotiation is a type of problem-solving (cf. Di Eugenio et. al., Coconut)
  • Negotiation: DPs discuss several alternative solutions before choosing one of them
  • Negotiation does not imply conflicting goals
    • perhaps not 100% correspondence to everyday use of the word “negotiation”, but useful to keep collaborativity as a separate dimension from negotiation
  • Both AOD and IOD can be negotiative
    • in a flight information service, the user does not become obliged to fly anywhere; so it’s IOD
    • but several different flights may be discussed
negotiation tasks
Negotiation tasks
  • Some factors influencing negotiation
    • distribution of information between DPs
    • whether DPs must commit jointly (e.g. Coconut) or one DP can make the comittment (e.g. flight booking)
  • We’re initially trying to model negotiation in flight booking
    • sample dialouge
      • U: flights to paris on september 13 please
      • S: there is one flight at 07:45 and one at 12:00
      • U: what airline is the 12:00 one
      • S: the 12:00 flight is an SAS flight
      • U: I’ll take the 12:00 flight please
    • Sys provides alternatives, User makes the choice
    • Sys knows timetable, User knows when he wants to travel etc.
degrees of negotiativity
Degrees of negotiativity
  • non-negotiative dialogue: only one alternative is discussed
  • semi-negotiative dialogue: a new alternative can be introduced by altering parameters of the previous alternative, but previous alternatives are not retained
  • negotiative dialogue: several alternatives can be introduced, and old alternatives are retained and can be returned to
semi negotiative dialogue
Semi-negotiative dialogue
  • Does not require keeping track of several alternatives
  • Answers must be revisable; this can be done using reraising of answered questions
  • Correction of optimistic assumption of acceptance not necessarliy distinguished from revision
  • Example: Swedish SJ system (Philips): ”Do you want an earlier or later train?”
issues under negotiation i negotiative dialogue
Issues Under Negotiation i negotiative dialogue
  • IUN is a question e.g. what flight to take
  • In an activity, some questions are marked as negotiable issues; other questions are assumed to be non-negotiable
  • Needs a new IS field: SHARED.IUN of type assocset(question,set(answer))
alternatives in negotiation
Alternatives in negotiation
  • Alternatives are alternate answers to an IUN
  • a proposal is the introduction of a new possible answer to IUN
  • An IUN is resolved when an answer to it is given, i.e. when an alternative is accepted
  • Alternatives and information about them is optimistically assumed to be accepted
  • Alternatives are needed whenever database search can return more than one result
general and specific information
General and specific information
  • General information concerns all alternatives, and is collected in an initial information-seeking dialogue (e.g. flights to paris)
    • e.g. x.dest(x,Paris)
  • Specific information concerns specific alternatives (e.g. flight f345 leaves at 10:45)
  • Specific info usually results from a database search whose input is general info; does this motivate separate fields in IS?
example
Example
  • IUN is lx.sel_flight(x) (“which is the chosen flight”?)
  • A: flight to paris, december 13
    • answer(x.dest(x,paris)) etc.;
  • B: OK, there’s one flight leaving at 07:45 and one at 12:00
    • propose(f1), propose(f2),
    • answer(dep_time(f1,07:45)), answer(dep_time(f2,12:00))
  • A: I’ll take the 07:45 one
    • answer(sel_flight(X), dep_time(X, 07:45)),
    • after contextual interpretation: answer(sel_flight(f1))
slide47

B: OK, there’s one flight leaving at 07:45 and

one at 12:00

AGENDA = { findout(?x.sel_flight(x)) }

PLAN =

findout((?x. ccn(x))

book_ticket

PRIVATE =

BEL = {flight(f1), dep_time(f1,0745), ... }

TMP = (same structure as SHARED)

IUN = < ?x.sel_flight(x)-{f1, f2 }>

SHARED =

dep_time(f1,0745),

dep_time(f2,1200)

x.dest(x, paris), ...

COM =

QUD = <>

LM = {propose(f1), propose(f2),

answer(dep_time(f1,07:40),...}

interpretation of nps
Interpretation of NPs
  • Interpretation of ”the 7:45 one” uses unification and coercion
    • all answer-contents which match propositions in SHARED.COM is unifed with this info; e.g. dep_time(X,07:45) is unified with dep_time(f1,07:45)
    • the rest is added, e.g. sel_flight(X) with X=f1
database search
Database search
  • Consulting DB with a set of (general) facts and a question (e.g. X^flight(X)) gives a list of alternative answers to the question AND info related to each of these alternatives
  • Example
    • FLIGHT DEP_TIME COMPANY
    • f1 07:45 KLM
    • f2 12:00 SAS
  • After doing the inital DB search, store results in PRIVATE.BEL, give some information about each alternative, e.g. flight departure time
plans
Plans
  • some info must be obtained from user, and some is found in DB; how flexible is this division?
  • a simple solution
    • departure date, destination, origin and class is obtained from user
    • (exact) departure times, company etc is always found in DB
    • departure times are always adressed when giving proposals; other info can be requested by user
  • flight booking
    • findout(X^dest_city(_,X)), ...
    • consultDB
    • propose
    • adress(X^dep_time(_,X))
    • findout(X^sel_flight(X))
  • a better solution: implicit negotiation of dialogue strategy (Lewin)
revising general information
Revising general information
  • Problem when general information is revised
    • solution: see it as defaults; if it is altered, turn it into specific info for all current alternatives which do not contradict the default
evidence for negotiable issues
Evidence for negotiable issues
  • optimistic approach to acceptance
    • A: Where do you want to travel?
    • B: London
    • A: When do you want to travel?
    • Intuition: A’s first question has been resolved
  • actual negotiation
    • B: Do you have a flight for London?
    • A: There’s one at 7:45
    • B: What hotels are available?
    • Intuition: the question “which flight will B take” is still unresolved