Issue-based Dialogue Management in GoDiS / IBiS

1. Issue-based Dialogue Management in GoDiS / IBiS Staffan Larsson Dialogue Systems 2 GSLT spring 2003

2. overview of contents • Introduction • Basic issue-based dialogue management • Grounding Issues • Adressing Unraised Issues • Action-oriented and Negotiative Dialogue • Issues Under Negotiation • Multilinguality • Conclusions

3. 1. Introduction, goals • explore and implement issue-based dialogue management • starting from Ginzburg’s theory and other relevant theories (Lewis, Allwood, Clark, Traum, Sidner, …) • adapt to dialogue system and implement • extend theory (incl. accommodation, action-oriented dialogue, negotiation) • separate general and domain-dependent phenomena • theoretical: general theory of dialogue • practical: minimize effort for adapting to new domains • incrementally extending system to handle increasingly complex types of dialogue • theoretical: clarifies relation between dialogue types • practical: reuse of update rules

4. A sample TrindiKit system: GoDiS • Built using TrindiKit • Explores and implements issue-based dialogue management • adapt Ginzburg’s KOS to dialogue system (GoDiS) and implement • Extends theory to more flexible dialogue • Menu based dialogue • Action-oriented dialogue, VCR application • Multiple tasks, information sharing between tasks • Feedback and grounding • Accommodation, re-raising, clarification • Multi-linguality & mutiple domains • Conditional responses (Ivana Kruijff-Korbayova)

5. application-specific Xerox manual home device manager Travel Agency VCR manager Auto- route genre-specific GoDiS-I GoDiS-A IBDM GoDiS TrindiKit IS approach

6. 2. Issue-based dialogue management • enquiry-oriented dialogue (database search) • basis: • Ginzburg’s Dialogue Gameboard (DGB) and • related DGB update protocols • moves: ask, answer, greet, quit • raising and addressing issues • incl. short answers. e.g.”yes”, ”no”, ”paris”, ”in april” • dialogue plans • sample domain: travel agency • extension: • reraising issues • handling multiple issues

7. Semantics • ”FOL” without quantifiers,disjunction,conjunction • Questions • Y/N-questions: ?P, P is a proposition • wh-questions: ?x.p(x) (p is a predicate) • alt-questions: {?P1, …, ?Pn} • Content of short answers • individual markers: paris, april, … • yes, no

8. Semantics, cont’d • Q-A relations (adapted from Ginzburg) • resolves(A,Q): A resolves Q • dest-city(paris) resolves ?x.dest-city(x) • relevant(A,Q): A is relevant to Q (about Q) • not(dest-city(paris)) is relevant to ?x.dest-city(x), but does not resolve it

9. basic infostate AGENDA : OpenQueue( Action ) PLAN : stack( Action ) PRIVATE : BEL : set( Prop ) COM : set( Prop ) QUD : stack( Question ) SHARED : LU: SPEAKER: Speaker MOVES: OQueue( Move ) + module interface variables INPUT : String LATEST-MOVES: Set(Move) LATEST-SPEAKER: Speaker NEXT-MOVES: Set(Move) OUTPUT: String + resource interface variables LEXICON : Lexicon DOMAIN : Domain DATABASE : Database

10. sample dialogue plan • findout(?x.transport(x)) • findout(?x.dest-city(x)) • findout(?x.depart-city(x)) • findout(?x.dept-month(x)) • findout(?x.dept-day(x)) • raise({?class(economy), ?class(business)} • consultDB(?x.price(x))

11. Answer integration • integrateAnswer • Before an answer can be integrated by the system, it must be matched to a question on QUD in($/SHARED/LU/MOVES, answer(A)) fst($/SHARED/QUD, Q) $DOMAIN:relevant(A, Q) pre: ! DOMAIN:combine(Q, A, P) add(/SHARED/COM, P) eff:

12. basic dialogue with updates U: ”price information please”; raises price issue • if user asks Q, push respond(Q) on AGENDA • if respond(Q) on AGENDA and PLAN empty, find plan for Q and load to PLAN • if findout(Q) first on PLAN, ask Q S: ”where do you want to go?” U: ”Paris” • if LM=answer(A) and A about Q, add P=Q[A] to SHARED.COM • if P in SHARED.COM and Q topmost on QUD and P resolves Q, pop QUD • if P in SHARED.COM and P fulfils goal of findout(Q) and findout(Q) on PLAN, pop PLAN

13. basics cont’d • … S: ”Do you want economy class or business class?” U: ”economy class” • if consultDB(Q) on PLAN, consult database for answer to Q; store result in PRIVATE.BEL • if Q on QUD and P in PRIVATE.BEL s.t. P resolves Q, answer(P) S: ”The price is £123”

14. Information sharing across plans • GoDiS does not keep track of when propositions were added, or which plan was being executed • so information sharing is determined by question sharing across plans • plan for VISA question: findout(?x.dest-city(x)) findout(?x.citizenship(x)) • shares a questions with plan for ?x.price(x) • so if visa-issue raised after price-issue, no need to ask for destination again

15. dealing with multiple open issues • if user asks Q, push Q on QUD and load plan for dealing with Q • if users asks Q’ while system is dealing with Q, throw out plan for Q but Q remains on QUD; load plan for Q’ • when Q’ resolved, Q topmost on QUD will trigger reloading plan for dealing with Q • general rule: if SHARED.COM contains info resolving Q, don’t ask Q • so any resolved questions in plan will be thrown out

16. Sample dialogue U: I want price information [raise ?x.price(x)] S: Where do you want to go? U: London S: When do you want to travel? QUD=<?x.dept-month(x), ?x.price(x)> U: Do I need a Visa? [raise ?visa] irrelevant followup to U’s question -> remove it (not assumed grounded); push new issue raised by U QUD=<?visa, ?x.price(x)> load plan for dealing with visa-issue S: Where are you travelling from? U: Gothenburg S: No, you don’t need a Visa.

17. Sample dialogue, cont’d S: No, you don’t need a Visa. visa-issue resolved, so pop off QUD QUD=<?x.price(x)> PLAN empty, so reload plan for dealing with ?x.price(x) Throw out all question which have already been resolved; raise the first unresolved question on plan S: When do you want to leave? U: April [answer dept-month(april)] QUD=<?x.price(x)> S: What day do you want to leave? …

18. Sample dialogue: multiple tasks & info sharing S> Welcome to the travel agency! U> price information S> (…) Lets see. How do you want to travel? U> by flight S> (…) What city do you want to go to? U> paris S> (…) What city do you want to go from? U> do I need a visa ? S> (…) Lets see. What country are you from? U> sweden S> Okay. Yes, you need a Visa. S> Returning to the issue of price. Lets see. What city do you want to go from?

19. pros and cons of this solution • Possibly inefficient since system does not keep track of where it was in the plan before it was thrown out • No way of knowing which issue is currently being dealt with, and thus whether a new plan should be loaded • possible solution: guarantee that plan always concerns topmost Q on ISSUES • Alternative solution is to keep unfinished plans around • PLAN : Stackset(Pair(Question, Plan)) • However, going through the plan again may be useful in case e.g. some information was removed when dealing with the embedded issue • Possible solution is to keep track of overlap between plans • if Q’ is raised while dealing with Q, and the plans overlap, throw out plan for Q and reload it later • otherwise, keep partially executed plan for Q around

20. 3. Grounding issues • feedback types • action level: contact, perception, understanding, acceptance/integration • polarity: positive, negative, elliciting (interrogative) • grounding issues • do I have contact with other DP? what did S say? what did S mean? does H accept what was said/meant? • update strategies • optimistic • non-cautious • cautious • pessimistic • feedback and grounding for a dialogue system

21. Feedback polarity • polarity: positive, negative, interrogative • Examples • ”I don’t understand” • negative • ”Do you mean that the destination is Paris?” • elliciting • ”To Paris.” • positive • ”Pardon” • negative

22. ICM dialogue moves • Interactive Communication Management • feedback • sequencing • (turntaking) • icm:Level{*Polarity}{:Args} • icm:per*pos:String – ”I heard you say ’londres’” • icm:und*neg – ”Sorry, I don’t understand” • icm:und*int:AltQ – ”Do you mean x or y?” • icm:und*pos:P – ”To Paris.” • icm:acc*neg:Q – ”Sorry, I can’t answer Q” • icm:acc*pos – ”Okay” • icm:reraise:Q – ”Returning to the issue of Q” [sequencing ICM]

23. Realisation of ICM dialogue moves • Form: • declarative: ”I didn’t hear what you said.”; ”The destination city is Paris.” • interrogative: ”What did you say?”; ”Do you want to go to Paris?” • imperative: ”Please repeat your latest utterance!” • elliptical • interrogative: ”Paris?”, ”To Paris or from Paris?” • declarative: ”To Paris.” • eliciting is always interrogative (possibly elliptical)

24. Implicit feedback • Clark: ”relevant followup” to U • what is relevant? • simple cases for followups to questions: • answer to question • ”subquestion” • feedback concering question • in general, complex inference and knowledge may be needed (implicatures) • irrelevant followup counts as negative feedback • What about no followup at all? • in reaction to ask-move or interrogative feedback, counts as negative • in reaction to answer or positive feedback, counts as positive

25. System feedback for user utterances • contact • negative (”I didn’t hear anything from you.”) • perception • negative: fb-phrase (”Pardon?”, ”I didn’t hear what you said”) • positive: repetition (”I heard ’to paris’”) • understanding • negative: fb-phrase (”I don’t quite understand”) • positive: reformulation (”To Paris.”) • eliciting neutral: reformulation (”To Paris, is that correct?”, ”To Paris?”) • acceptance/integration • negative:fb-phrase with reformulation (”Sorry, I cannot answer Q”, ”Sorry, Paris is not a valid destination city.”) • positive: fb-word (”okay.”)

26. User feedback for system utterances • contact: - • perception • negative: fb-phrase (”Pardon?”, ”I didn’t hear what you said”) • understanding: - • acceptance/integration • negative: fb-phrase (”I don’t know”, ”Never mind”) • positive: fb-word (”okay.”)

27. Grounding on multiple levels Negative perception feeback S> Lets see. What can I do for you? U> (mumble mumble) S> Sorry, I didnt hear what you said. What can I do for you? U> siridus S> I heard you say siridus . Sorry, I dont understand. What can I do for you? U> channel one S> channel one. I dont quite understand. Do you want to add a program or change channel? (dialog3a_edit) Positive perception Negative understanding Positive understanding (word meaning) Negative understanding (relevance) Task clarification

28. Positive understanding Rejection (negative acceptance feedback) U> turn on the t v S> turn on the TV… Sorry, I cannot control the TV set. Do you want to add a program or change channel?” U> pardon S> Sorry, I cannot control the TV set. Do you want to add a program or change channel? U> change channel S> Okay. (dialog3b_edit) User negative perception System repetition Positive acceptance

29. Correcting the system S> Lets see. What can I do for you? U> add program S> Okay. Add a program… S> Lets see. What channel do you want? U> channel six S> channel five? U> no S> not channel five. So, What channel do you want? U> channel six S> Okay. channel six.” (dialog4_edit) Interrogative feedback Negative answer to fb. Signals reraising (Sequencing ICM)

30. Feedback: action levels and associated metaissues • assume A uttered U to B • A and B are faced with a number of issues • contact: do A and B have contact? • perception: • A: does B percieve U (correctly)? • B: did B say anything? / what did B say? / Did B say V? • understanding: • A: does B understand U (correctly) • B: what did B mean? / Did B mean C? • acceptance • A: does B accept U • B: should I accept U?

31. Grounding and action levels • ”To ground a thing … is to establish it as part of common ground well enough for current purposes.” (Clark) • grounding applies to all action levels • U is grounded on level L = the answer to the grounding issue on level L is positively resolved • grounding assumptions correspond to information state updates in system • contact, perception not explicitly modeled • understanding: SHARED.LU.MOVES • acceptance: SHARED.QUD, SHARED.COM

32. Grounding update strategies • strategic questions: • When should U assumed to be grounded on level L? • as soon as it has been uttered (of course, the hearer cannot assume grounding until grounding wh-issues have some answer, e.g. ”what did A say?” ) • if B does not give negative feedback • when B gives positive feedback • when B has given eliciting feedback which has been confirmed by A • What to do if the grounding assumption turns out to be mistaken • optimism on level L: • assume U is grounded on level L as soon as U has been uttered

33. Grounding update strategies cont’d • optimism on level L: • assume U is grounded on level L as soon as U has been uttered • cautious optimism: • make sure the optimistic assumption can easily be retracted • pessimism: • don’t assume U grounded until there has been some positive feedback (or at least no negative feedback)

34. Meta-issue: understanding • Ginzburg’s meaning question • ?x.meaning(LU,x) • ”What’s the meaning of LU?” • understanding-issue • for speaker who uttered LU with move type m, content c • or hearer who interpreted LU • ?und(m(c)) • ”Is m(c) a correct interpretation of LU?

35. Optimistic approach to grounding • assumption that answer to grounding questions are positive • for system utterances • need to deal with cases where user indicates optimistic assumption is wrong • at least for perception and acceptance levels • for user utterances • need to indicate failure, and on which action level • if fail to understand or accept, don’t modify SHARED

36. optimistic understanding update input inter- pret update select gene- rate output LATEST-MOVES: Set(Move) LATEST-SPEAKER: Speaker AGENDA : Queue( Action ) PLAN : stackset( Action ) PRIVATE : BEL : set( Prop ) TMP : (same type as SHARED) COM : set( Prop ) QUD : stack( Question ) SHARED : LU: SPEAKER: Speaker MOVES: OQueue( Move )

37. Meta-issue: acceptance • Ginzburg’s protocols for acceptance • LM = ask Q -> consider ?MAX-QUD(Q) • if yes, push Q on QUD • otherwise, address ?MAX-QUD(Q) • LM = assert P -> consider ?MAX-QUD(?P) • if yes, consider ?P • if yes, add P to FACTS • otherwise, address ?P • otherwise, address ?MAX-QUD(?P)

38. rejections • ?MAX-QUD(Q) is answered ”no” • inability to answer Q • ”Sorry, I can’t answer that question” • unwillingness to answer Q • ”I don’t want to discuss that” • ?MAX-QUD(?P) is answered ”no” • unwillingness to discuss whether ?P • ”I don’t want to discuss that” • other reasons? • ?P answered ”no” • ”Sorry, I don’t agree.”, ”You’re wrong!”, ”That’s impossible!” • a rejection may lead to argumentation

39. problematic cases S: ”Where do you want to go?” U1: ”Nowhere” U2: ”I don’t know” U3: (silence) OR ”I want first class!” • do these count as rejections? • U1: negative answer? presupposition failiure? rejection? • U2: rejection? • but not as definite as ”No comment!” • U3: rejection? • in any case, irrelevant followup

40. optimistic acceptance update AGENDA : stack( Action ) PLAN : stackset( Action ) PRIVATE : BEL : set( Prop ) TMP : (same type as SHARED) COM : set( Prop ) QUD : stack( Question ) SHARED : LU: SPEAKER: Speaker MOVES: assocSet( Move )

41. choice of strategies in system • system utterances • optimistically assumed to be grounded on all levels • negative feedback on perception or acceptance levels -> backtrack to saved state • user utterances • if problem on any level, give negative fb • if OK on all levels, update strategy and feedback determined by recognition score • S > 0.9 • optimistic update, icm:acc*pos • 0.9 >= S > 0.8 • optimistic update, icm:acc*pos, icm:und*pos:Content • 0.8 >= S >0.5 • pessimistic update, icm:und*int:Content • if ?und(Content) recieves answer ”yes”, add assume Content grounded

42. optimistic acceptance • assume positive answer to acceptance issue • we don’t need to represent these issues explicitly • no use representing them unless we can handle argumentation subdialogues to resolve disagreement • for system utterances • need to deal with cases where user indicates optimistic assumption is wrong • so far, only for system questions • for user utterances • need to indicate when optimistic assumption is wrong • both questions (sys has no plan) and propositions (invalid database parameter)

43. 4: Addressing Unraised Issues • ISSUES and QUD • answer integration • question accommodation (to QUD) • issue accommodation (to ISSUES) • reraising issues • multiple issues: modified account • information sharing across plans • reacommodation (reraising by accomm.) • transitive reaccommodation and reraising

44. problem with QUD • If QUD=<q1,q2> and q1 is resolved, q2 is available for resolution of short answers • takes no account of how many turns since q2 was raised • but short answers a long distance away from the question are not as easily processed as an adjacent answer

45. ISSUES and QUD • We extend Ginzburg’s DGB by adding ISSUES of type Stack(Question) • ISSUES contains all raised but unresolved questions • ISSUES determines relevance of user answers • QUD used for resolving short answers • questions drop off QUD after N turns • a short answer to a question that’s on ISSUES but not QUD requires QUD accommodation!

46. short answer integration • If • LM=answer(A); A is a short answer • Q topmost on QUD • A about Q • then • P = Q[A] • add P to SHARED.COM • QUD downdate: if Q topmost on QUD and P in SHARED.COM s.t. resolves(P,Q), pop QUD

47. full answer (”assertion”) integration • If • LM=answer(A); A is a proposition • Q in ISSUES • A about Q • then • add A to SHARED.COM • Issue downdate: if Q on ISSUES and P in SHARED.COM s.t. P resolves Q, remove Q from ISSUES

48. issue accommodation PLANISSUES • If • LM=answer(A) • no Q in ISSUES s.t. about(A,Q) • then • find findout(Q) in PLAN s.t. about(A,Q) • push Q on ISSUES • used when prevously unraised question (available in plan) is answered using a short or full answer

49. question accommodation ISSUESQUD • If • LM=answer(A) • no Q in QUD s.t. about(A,Q) • then • find Q in ISSUES s.t. about(A,Q) • push Q on QUD • raise Q in ISSUES (make Q topmost) • used when • previously raised question has dropped off QUD, but is answered using a short answer • previously unraised question is answered using short answer [needs PLANISSUES accommodation]

50. dependent issue accommodationDOMAINISSUES (+PLAN) • If • LM=answer(A) • no Q in ISSUES s.t. about(A,Q) • no findout(Q) in PLAN s.t. about(A,Q) • then • find Plan for some Q’ in DOMAIN s.t. findout(Q) or raise(Q) in Plan and about(A, Q) • push Q’ on ISSUES • set PLAN to Plan • used when previously unraised question, unavailable in PLAN, is answered using full or short answer