1 / 113

Dialogsystem del 2 Informationstillstånd, TrindiKit, GoDiS

Dialogsystem del 2 Informationstillstånd, TrindiKit, GoDiS. Staffan Larsson Pragmatik VT04. Dialogspel för agenter: Conversational Game Theory (Lewin 2000). Informationstillstånd och dialogtillstånd. Dialogtillstånd ett tillstånd i en finit automat; ingen information lagrad i tillståndet

jed
Download Presentation

Dialogsystem del 2 Informationstillstånd, TrindiKit, GoDiS

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Dialogsystem del 2Informationstillstånd, TrindiKit, GoDiS Staffan Larsson Pragmatik VT04

  2. Dialogspel för agenter:Conversational Game Theory (Lewin 2000)

  3. Informationstillstånd och dialogtillstånd • Dialogtillstånd • ett tillstånd i en finit automat; ingen information lagrad i tillståndet • Informationstillstånd • ett ``dialogprotokoll'' som håller reda på gemensamma antaganden, aktuella frågor, skyldigheter, referenter mm. • kan även inkludera privata och sociala attityder • både privat och delad information • kan t o m inkludera dialogtillstånd (t ex ett heltal som refererar till ett tillstånd i en automat)

  4. CGT & dialogspelsbaserade agenter • Teori som tillämpar dialoggrammatik i dialogsystem • Använder också informationstillstånd • Spel representerade som RTNs (Recursive Transition Networks) • d v s bågar i ett spel kan vara associerade med ett annat spel • Kombineras med enkelt informationstillstånd/kontext <Pd, Cm>: • Pd: Propositions under discussion • < P, d(P) >, där d(P) är ett fokuserat element i P • Cm: Commitment slate

  5. Moves & games är funktioner som uppdaterar kontexten • Moves uppdaterar Pd • Games uppdaterar Cm • committments: ej mentala attityder utan ”publika objekt” som man kan bindas till • social attityd • Ej som i t ex Cohen & Perrault! • förvillkor och effekter i termer av mentala tillstånd, privata attityder

  6. Move types (urval) • qw(p): wh-fråga • Pd := < p, 0 > • rw(p): svar på wh-fråga • Pd := < p, 0 > • ack: acknowledgement; Pd oförändrad • cnf(c): confirmation • Pd före = < P, _ > • Pd := < P, c > • Ryes: ja-svar ; Pd oförändrad • Rno: nej-svar ; Pd oförändrad

  7. Games • Att spela dialog involverar ”parsning” av spel m h a dialoggrammatiken • parallell, inkrementell parser • rankar möjliga parsningar m h a en preferensmekanism • detta sköts av en ”monitor” • Men agenten måste också producera egna yttranden • sköts av dialogbidragsgenerator • genererar output om monitorn indikerar att det är systemets tur • vilken output som väljs beror dels av speltillstånd, dels av informationstillstånd

  8. QW(p) qw rw ack 0 1 2 3 Ryes|Rno|Rmod qw-r cnf 4 QW(p) -> {qw | qw-r} rw (cnf {Ryes | Rno | Rmod}) ack ...

  9. Exempeldialog

  10. Uppgifter (2-4 sidor) • 10.1 Vilka egenskaper har en agent? Vilka attityder kan en agent ha, och hur hänger dessa samman med egenskaperna? (Wooldridge & Jennings) • 10.2 Beskriv de olika approacherna till att bygga artificiella dialogagenter (Traum, Lewin) • planbaserad • logikbaserad • tillståndsbaserad • 10.3 Vilken typ av information behöver en dialogagent hålla reda på i de olika approacherna? (Traum, Lewin)

  11. Dialogsystem

  12. Dialogue modelling • Theoretical motivations • find structure of dialogue • explain structure • relate dialogue structure to informational and intentional structure • Practical motivations • build dialogue systems to enable natural human-computer interaction • speech-to-speech translation • ...

  13. Why build dialogue systems? • theoretical: test theories • e.g. what kind of information does the system need to keep track of? • problem: complex system with many components • practical: natural language interfaces • databases (train timetables etc) • electronic devices (mobile phones,...) • instructional/helpdesk systems • booking flights etc • tutorial systems

  14. What does a system need to be able to do? • speech recognition • parsing, syntactic and semantic interpretation • resolve ambiguities • anaphora and ellipsis resolution, etc... • dialogue management • how does an utterance change the state of the dialogue? • given the current state of the dialogue, what should the system do? • natural language generation • speech synthesis

  15. Why spoken dialogue? • Spoken dialogue is the natural way for people to communicate • computers should adapt to humans rather than the other way around • important to enable system and user to communicate in a natural (human-like) way • mixed initiative • turntaking, feedback, barge-in • handle embedded subdialogues • ...

  16. What’s happening with dialogue systems • Beginning to be used commercially • Limited domains • need to encode domain-specific knowledge; a general system would require general world knowledge • speech recognition is harder with large lexicon • Simple dialogue types • mostly information-seeking • Need to bridge gap between dialogue theory and working systems

  17. Dialogsystemtyper • finite state automata (CLSU toolkit) • Dock ofta med möjlighet att ha tilltåndsvariabler (=informationstillstånd) • Reaktiva agenter??? • frame-based (VoiceXML) • plan-based (TRAINS, Allen, Cohen, Grosz, Sidner, ...) • general reasoning (Sadek, ...) • information states (TRINDI: Traum, Bos, ...)

  18. Problemområden & teorierformell pragmatik för dialogsystem • hantering av dialogstruktur • dialogspel • talakter • implicit information • presupposition • implikatur • planigenkänning • relatera explicit & implicit information till kontext; uppdatera kontext • pronomenlösning (DRT, Centering Theory, abduktion) • planigenkänning • accommodation • välj/planera yttrande • planering • implicit information? • kommunikationshantering • ICM, OCM • grounding • konversationsanalys

  19. TrindiKit

  20. What is TrindiKit? a toolkit for building and experimenting with dialogue move engines and systems, based on the information state approach not a dialogue system in itself

  21. Architecture & concepts

  22. control DME module1 module… modulei modulej module… modulen • Total Information State • (TIS) • Information state proper (IS) • Module Interface Variables • Resource Interface Variables resource1 resource… resourcem

  23. Information State (IS) • an abstract data structure (record, DRS, set, stack etc.) • accessed by modules using conditions and operations • the Total Information State (TIS) includes • Information State proper (IS) • Module Interface variables • Resource Interface variables

  24. Dialogue Move Engine (DME) • module or group of modules responsible for • updating the IS based on observed moves • selecting moves to be performed • dialogue moves are associated with IS updates using IS update rules • there are also update rules no directly associated with any move (e.g. for reasoning and planning) • update rules: rules for updating the TIS • rule name and class • preconditon list: conditions on TIS • effect list: operations on TIS • update rules are coordinated by update algorithms

  25. Modules and resources • Modules (dialogue move engine, input, interpretation, generation, output etc.) • access the information state • no direct communication between modules • only via module interface variables in TIS • modules don’t have to know anything about other modules • increases modularity, reusability, reconfigurability • may interact with user or external processes • Resources (device interface, lexicons, domain knowledge etc.) • hooked up to the information state (TIS) • accessed by modules • defined as object of some type (e.g. ”lexicon”)

  26. What’s in TrindiKit?

  27. What does TrindiKit provide? • High-level formalism and interpreter for implementing dialogue systems • promotes transparency, reusability, plug-and-play, etc. • allows implementation and comparison of dialogue theories • hides low-level software engineering issues • GUI, WWW-demo • Ready-made modules and resources • speech • interfaces to databases, devices, etc. • reasoning, planning

  28. TrindiKit contents (1) • alibrary of datatype definitions (records, DRSs, sets, stacks etc.) • user extendible • alanguage for writing information state update rules • GUI: methods and tools for visualising the information state • debugging facilities • typechecking • logs of communication modules-TIS • etc.

  29. TrindiKit contents (2) • 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 resources and resource interfaces, e.g. to hook up databases, domain knowledge, devices etc.

  30. Special modules and resources included with TrindiKit • OAA interface resource • enables interaction with existing software and languages other than Prolog • Speech recognition and synthesis modules • TrindiKit shells for off-the-shelf products, e.g. Nuance • Possible future modules: • planning and reasoning modules • multimodal input and output

  31. Asynchronous TrindiKit • Internal communication uses either • OAA (Open Agent Architecture) from SRI, or • AE (Agent Environment), a stripped-down version of OAA, implemented for TrindiKit • enables asynchronous dialogue management • e.g.: system can listen and interpret, plan the dialogue, and talk at the same time

  32. How to build a system

  33. How to use TrindiKit We start from TrindiKit Implements the information state approach Takes care of low-level programming: dataflow, datastructures etc. TrindiKit information state approach

  34. How to build a basic system Formulate a basic dialogue theory Information state Dialogue moves Update rules Add appropriate modules (speech recognition etc) basic dialoguetheory basic system TrindiKit information state approach

  35. How to build a genre-specific system Add genre-dependent IS components, moves and rules genre-specific theory additions genre-specific system basic dialoguetheory basic system TrindiKit information state approach

  36. How to build an application Add application-specific resources application domain & language resources genre-specific theory additions genre-specific system basic dialoguetheory basic system TrindiKit information state approach

  37. Building a domain-independent Dialogue Move Engine • Come up with a nice theory of dialogue • Formalise the theory, i.e. 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 • any extra datatypes (e.g. for semantics: proposition, question, etc.)

  38. Specifying Infostate type • the Total Information State contains a number of Information State Variables • IS, the Information State ”proper” • Interface Variables • used for communication between modules • Resource Variables • used for hooking up resources to the TIS, thus making them accessible from to modules • use prespecified or new datatypes

  39. example: BeadieEye IS information state type BEL: Set(Prop) DES: Set(Prop) INT: Set(Action) MBEL: Set(Prop) IS : LM: Set(Move)

  40. Specifying a set of moves • amounts to specifying objects of type move (a reserved type) • there may be type constraints on the arguments of moves • Example: GoDiS dialogue moves • Ask(Q), Q is a question • Answer(A), A is an answer (proposition or fragment) • Request(),  is an action • Confirm() • Greet • Quit

  41. Writing rules • rule = conditions + updates • if the rule is applied to the IS and its conditions are true, the operations will be applied to the IS • conditions may bind variables with scope over the rule (prolog variables, with unification and backtracking)

  42. Example: BeadieEye moves and a rule moves: assert(P), askif(P) rule( integrate_assert, [ in( $lm, assert(P) ) ], add( is/mbel, P ), add( is/bel, P ), del( lm, assert(P) ) ] ).

  43. Example BeadieEye rule application BEL = { happy(sys) } DES = { knowif( happy(usr) ) } INT = { } MBEL = { } IS = LM = { assert( happy(usr) } Rule application: integrate_assert, > add( IS/MBEL, happy(usr) ), > add( IS/BEL, happy(usr) ), > del( LM, assert(happy(usr) ) BEL = { happy(sys), happy(usr) } DES = { knowif( happy(usr) ) } INT = { } MBEL = { happy(usr) } IS = LM = { }

  44. Example: a rule from GoDiS rule( integrateUsrAnswer, [ $/shared/lu/speaker = usr, assoc( $/shared/lu/moves, answer(R), false ), fst( $/shared/qud, Q ), $domain : relevant_answer( Q, R ), $domain : reduce(Q, R, P) ], [ set_assoc( /shared/lu/moves, answer(R),true), shared/qud := $$pop( $/shared/qud ), add( /shared/com, P ) ] ).

  45. Building modules • Algorithm • For DME modules: coordinate update rules • For control modules: coordinate other modules • TrindiKit includes a language for writing algorithms • For DME modules: basic imperative programming constructs • For control module: basic imperative constructs plus asynchronous triggers

  46. Sample update algorithm grounding, if $latest_speaker == sys then try integrate, try database, repeat downdate_agenda, store else repeat integrate orelse accommodate orelse find_plan orelse if (empty ( $/private/agenda ) then manage_plan else downdate_agenda repeat downdate_agenda if empty($/private/agenda)) then repeat manage_plan repeat refill_agenda repeat store_nim try downdate_qud

  47. Sample control algorithm (2) input: { init => input:display_prompt, new_data(user_input) => input } | interpretation: { import interpret, condition(is_set(input)) => [ interpret, print_state ] } | dme: { import update, import select, init => [ select ], condition(not empty(latest_moves)) => [ update, if $latest_speaker == usr then select ] } | generation: { condition(is_set(next_moves)) => generate } | output: { condition(is_set(output)) => output } )).

  48. From DME to dialogue system Build or select from existing components: • Modules, e.g. • input • interpretation • generation • output • Still domain independent • the choice of modules determines e.g. the format of the grammar and lexicon

  49. 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 • Example resources: GoDiS VCR control • VCR interface • Domain knowledge • Lexicon

  50. Extending TrindiKit

More Related