Presentation laddar. Vänta.

Presentation laddar. Vänta.

Dialogsystem Logopediutbildningen VT05 Staffan Larsson Institutionen för lingvistik, GU.

Liknande presentationer


En presentation över ämnet: "Dialogsystem Logopediutbildningen VT05 Staffan Larsson Institutionen för lingvistik, GU."— Presentationens avskrift:

1

2 Dialogsystem Logopediutbildningen VT05 Staffan Larsson Institutionen för lingvistik, GU

3 Översikt •Dialogsystem som gränssnitt •Dialogmodellering •Agenter och dialog •TrindiKit och informationstillstånd •Ett exempel: BeadieEye •Frågebaserad dialoghantering i GoDiS •Dialogsystem och AAC

4 Dialogsystem som gränssnitt

5 Vad är gränssnitt? •Teknologier som utgör kontaktytan mellan människan och maskinen •Tillåter kommunikation mellan människa och maskin •Exempel: –Skärm –Tangentbord –Mus –Talad dialog? •Gränssnittet bestämmer hur vi relaterar till maskinerna i vardagen

6 Språket som gränssnitt •Kan språket (det mänskliga, naturliga, talade) användas för att överbrygga gränsen mellan människa och maskin? •Hur? –Genom att få maskiner (datorer) att förstå mänskligt språk och kunna föra dialoger: detta är ett av målet för språkteknologin •Varför? –Talad dialog är – för människor - det mest naturliga sättet att interagera

7 Dialog och dialogsystem •Dialog: –interaktivt informationsutbyte med hjälp av naturligt språk •Dialogsystem: –Teknologier som möjliggör interaktion mellan människa och maskin med hjälp av (talad) dialog

8 Praktiska användningsområden (urval) •Demokratisering av teknologi –Dialog som gränssnitt till teknologi som annars hade varit för komplex –Fördel: kräver ingen teknisk fallenhet eller förkunskaper (utöver att kunna tala) •Kommunikationsstöd –För döva –För blinda –Andra funktionshinder •Möjliggöra kommunikation –Tal-till-tal-översättning

9 Varför är dagens dialogsystem inte bättre? •Exempel: SJ:s tidtabellsupplysning ( ), Tidpunkten ( ) •Dessa systems förmåga att föra en dialog ligger ljusår från människans. Varför? •De utgår i stor utsträckning från maskinernas förutsättningar, inte från teorier om den mänskliga dialogförmågan!

10 Hur ska vi kunna bygga bra dialogsystem? •För det första: Vi måste förstå hur människor använder språk! •Wittgenstein ( ): –Språklig aktivitet är alltid förankrad i någon specifik mänsklig aktivitet! –Till varje aktivitet hör ett språkspel; ett språk som svenska är i själva verket en samling språkspel •För det andra: vi måste formulera våra teorier på ett sätt som är begripligt för en dator –Formalisering och simulation

11 Formalisering •Översättning till ett formellt språk •Exempel på formella språk –Matematik •Används för att formalisera bl a fysik –Logik –Programmeringsspråk, t ex Java •Formella språk är generellt sett extremt enkla och regelbundna •Detta gör att datorer kan ”förstå” dem

12 Simulation •Antag att vi har en teori om (en del av) den mänskliga språkförmågan •Hur ska vi ta reda på om den är sann? –Empiriska studier (lingvistik) •Studera insamlat språkligt material •Gör experiment –Simulering (språkteknologi / datalingvistik) •Översätt teorin till ett datorprogram (formalisera) •Kör programmet och se om beteendet är det förväntade •”reverse engineering”

13 Dialogsystem som simulationer •Dialogsystem försöker simulera hela den mänskliga språkförmågan –Att uppfatta, tolka och förstå talade yttranden –Att resonera om vad som ska sägas och när det ska sägas –Att formulera och uttala yttranden

14 Två sorters språkteknologi? •”Praktisk” språkteknologi –Förbättra gränssnitt –I princip ointressant huruvida man försöker efterlikna en mänsklig språklig förmåga •Simulerande språkteknologi / datalingvistik –En forskningsmetodik för att utforska den mänskliga språkförmågan –I princip ointressant huruvida resultatet är praktiskt användbart •Dessa sammanfaller i den mån det människolika också är det praktisk användbara •Det finns skäl att tro att möjligheterna att simulera hela den mänskliga språkförmågan är begränsad

15 Maskinen människan? •Descartes ( ) –Djur är att betrakta som maskiner –Människan har en själ, och skiljer sig därför på ett fundamentalt sätt från djuren •de la Mettrie ( ) –”Maskinen människan” –Skillnaden mellan människa och maskin är en kvantitativ skillnad i komplexitet –Ingen fundamental skillnad!

16 Turingtestet •Kan en maskin vara intelligent? •Är ”artificiell intelligens” (AI) möjlig? •Turing ( ): ”Turingtestet” –Testperson A får föra en dialog (via textterminaler) med B. –A:s mål är att försöka avgöra om B är en människa eller en dator –(OBS! Detta är en förenklad version av Turingtestet!)

17 Turingtest och dialogsystem •Enligt Turingtestet – vad är det fundamentalt mänskliga? –Förmågan att föra en dialog med naturligt språk! •Varför skulle detta vara fundamentalt? –Antagande: I talet visar sig alla andra mänskliga förmågor (direkt eller indirekt)

18 En svart låda •Turing behandlar i stor utsträckning psyket som en svart låda •Om vi lyckas simulera mänskligt beteende, betyder det att vår teori är korrekt? –Turing: Ja; alla eventuella skillnader är oväsentliga! –Fenomenologisk kritik (Dreyfus, Heidegger) : Nej; även om vi lyckats fånga de centrala iakttagbara aspekterna av det mänskliga psyket i datorn, så ÄR den inte en människa – vi kan inte veta att datorn fungerar som en människa inuti!

19 Heideggers projekt i Varat och tiden •Beskriv grunderna för det mänskliga varandet –Hur det är att vara människa •Detta kan enligt Heidegger bara göras ”inifrån” –H:s utläggning är ej avsedd att vara begriplig för någon som inte är människa –En sådan förklaring är inte möjlig, hävdar H.; det mänskliga går inte att förklara ”från scratch” –Ändå är det en sådan förklaring som eftersträvas inom AI-forskningen

20 Principargument mot ”artificiell intelligens” •(här: AI = att datorer skulle kunna förstå språk på samma sätt som människor gör det) •”Religiösa” argument –Människan har en immateriell själ, vilket maskiner aldrig kan ha •Materiella argument –Varelser av silikon och metall kan aldrig vara sant mänskliga; till detta krävs kött och blod (och neuroner)

21 Fler principargument •Freudianska argument –Människor och maskiner har radikalt annorlunda konstitution och ursprung; detta ursprung (t ex barnets utvecklingsfaser) är fundamentalt för hur vi förstår världen och språket –Maskiner föds inte av två andra maskiner; de byggs •Fenomenologiska argument –Spädbarn är, strikt talat, inte människor; de måste först socialiseras in i världen •Maskiner socialiseras aldrig in i världen; de programmeras –AI kräver formalisering av tolkningsbakgrund, vardaglig omedveten praktisk förmåga att förstå världen •Men denna ”kunskap” är inte en samling fakta –Människor har en biologisk kropp som ligger till grund för deras sätt att förstå världen •AI förutsätter att intelligens kan abstraheras från kroppen

22 (Hur människolika ska maskinerna bli?) •Vill man verkligen efterlikna alla mänskliga engenskaper? –Freudianska felsägningar? –Dåligt minne? –Panikångest? Utbrändhet?

23 Principfrågan – i princip ointressant? •Är det egentligen intressant huruvida människor i princip är / inte är maskiner? Frågan om huruvida en dator kan tänka är inte mer intressant än frågan om huruvida en ubåt kan simma. (E. W. Dijkstra, )

24 Fel fråga? •Istället för ”Kan maskiner vara intelligenta”: •På vilket sätt kan maskiner vara intelligenta? •Hur simmar ubåtar?

25 Dialog i begränsade regelbundna domäner •Även om vi inte kan hoppas simulera den mänskliga språkförmågan.. •...så kan dialogsystem fortfarande göra nytta för att förbättra gränssnitt till datorer och annan teknologi –Detta kan göras för relativt enkla och regelbundna domäner (resebyrå. programmera videon, ordbehandling...) –(Wittgensteins språkspel) •Men även om vi inte försöker simulera mänsklig dialogförmåga i datorn... –...så måste den kunna delta i en dialog med en människa –detta kräver kunskap om mänsklig kommunikation och dialog

26 Dialogmodellering

27 Dialogue modelling •Theoretical motivations –find structure of dialogue –explain structure –relate dialogue structure to informational and intentional structure •Practical motivation –build dialogue systems to enable natural human- computer interaction –(what is natural?)

28 Informal approaches to dialogue modelling •speech act theory (Austin, Searle,...) –utterances are actions –illocutionary acts: ask, assert, instruct etc. •discourse analysis (Schegloff, Sacks,...) –turn-taking, pre-sequences etc. •dialogue games (Sinclair & Coulthard,...) –structure of dialogue segments (rather than separate utterances) –can e.g. be encoded as regular expressions or finite automata •qna-game -> question qna-game* answer

29 Computational approaches implemented in systems and toolkits •finite state automata (CLSU toolkit, Nuance) •frame-based (Philips, SpeechWorks) •plan-based (TRAINS, Allen, Cohen, Grosz, Sidner,...) •general reasoning (Sadek,...) •information states (TRINDI: Traum, Bos,...)

30 Why build dialogue systems? •theoretical: test theories (of human-computer dialogue) –e.g. what kind of information does the an artificial dialogue agent 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

31 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

32 Why spoken dialogue? •Spoken dialogue is the natural way for people to communicate –as far as possible, computers should adapt to humans rather than the other way around –(but humans will also need to adapt their conversational style) •important to enable system and user to communicate in a natural (human-like) way –mixed initiative –turntaking, feedback, barge-in –handle embedded subdialogues –...

33 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

34 Agenter (och dialog)

35 Vad är en (artificiell) agent? •beteendebaserad defintion •autonomi: –agenter handlar utan direkt inblandning av människor eller andra, och har kontroll över sina egna handlingar och sitt eget interna tillstånd •social förmåga: –agenter interagerar med andra agenter (inkl. människor), bl a med hjälp av språk •reaktivitet: –agenter uppfattar sin omgivning (den fysiska världen, ett grafiskt användarinterface, internet...) och reagerar på förändringar i omgivningen •proaktivitet: –aganter reagerar inte bara på omgivningen, utan är också kapabla till målinriktat beteende och kan ta initiativ

36 Två huvudtyper av ramverk för artificiella agenter •”Deliberative” –en agent har en explicit representerad symbolisk modell av världen –beslut fattas genom logiskt slutledning (mönstermatchning, symbolmanipulation) –teoribaserade –Exempel: General Problem Solver (Newell & Simon) •Reaktiv –ingen symbolisk modell –ingen komplex symbolprocessning –Exempel: situerade finita automater (Rosenschein & Kaelbling) –tenderar att vara ad hoc •det finns ocskå hybridteorier –ett reaktivt och ett deliberativt lager •Är människor reaktiva eller deliberativa? Eller kanske hybrider...

37 Attityder för deliberativa agenter •Privat •Social •Informationsattityd –kunskap / tro •Proattityd –handling, mål

38 Reaktivitet •Perception –agenter uppfattar världen genom sinnesorganen, vilket ger upphov till kunskap / trosföreställningar om världen •Privata informationsattityder –trosföreställningar (beliefs, B) –kunskap (sann berättigad tro) •Reaktion –kräver förmåga att agera

39 Proaktivitet •Initiativ –Agenter har behov, önskningar och avsikter och försöker ofta ändra världen utgående från dessa •Kräver –förmåga att planera –förmåga att bestämma sig •Privat proattityd: intention

40 Autonomi •agenter handlar utan direkt inblandning av människor eller andra, och har kontroll över sina egna handlingar och sitt eget interna tillstånd •Privata attityder (info- och proattityder): –trosföreställningar (beliefs, B) –önskningar/vilja (desires, D) –intentioner (I)

41 Social förmåga •Människor är också sociala varelser; de står i sociala relationer till varandra och agerar utifrån dessa •Sociala informationsattityder: –delad tro/kunskap (shared belief), •Sociala proattityder –skyldigheter (obligations) –åtaganden (committments), –rättigheter (rights) (?)

42 (Agenter och) dialog • Kunskap för dialogagenter • Informella approacher • Formella ramverk

43 Typer av kunskap som behövs för att kunna delta i en dialog •sociala informationsattityder (delad kunskap) •statisk –generell världskunskap för att tolka yttranden –aktivitetsspecifik världskunskap –språklig kunskap; förmåga att tolka och konstruera yttranden, inkl. kunskap om talakter och dialogspel •dynamisk –privata och sociala attityder –dialogmodell; ``dialogprotokoll'’: håller reda på gemensamma antaganden, aktuella frågor, skyldigheter, referenter mm.

44 Hur ska kunskap representeras? •Kunskapsrepresentationsspråk, t ex FOL, semantiska nätverk, frames... •Kunskapsbas = mängd av statser + inferensregler •ontologier / typhierarkier (för begreppskunskap)

45 •Hur mycket och vilken typ av kunskap som behövs beror på dialogtyp •enkel -> komplex –call routing –tidtabellsupplysning –databassökning –programmera video –instruktionsdialog (t ex ge vägbeskrivning) –förhandling –planera framtida aktivitet –vardagligt småprat (?)

46 Ramverk för dialogagenter •Finita automater –strikt ”flödesschema” från starttillstånd till sluttillstånd –i varje tillstånd är ett begränsat antal handlingar möjliga •Logikbaserade –Rationalitetsaxiom + inferens –axiomatiserad talaktsteori (i modallogik) –problem med komplexitet och avgörbarhet •Planbaserade –Planering & planigenkänning –talakter som planer –problem med komplexitet •Informationstillstånd –dialogdrag, dialogspel, uppdateringsregler –variabel komplexitet deliberativ reaktiv •Dessa kan kombineras!

47 •En (artificiell) dialogagent kan –interagera och kommunicera med andra agenter på ett koherent sätt –delta i dialoger (d v s kommunikativa utbyten med en längre sekvens av yttranden) om ett givet ämne med avsikten att uppnå ett gemensamt övergripande mål •Yttranden är handlingar som ändrar –mentala tillstånd –kontexten och dialogtillståndet

48 Interaktion på flera nivåer •Ide: modellera dialog som handlingar på flera nivåer –ej bara satsnivå (talakter) •4 talaktsnivåer (Traum & Hinkelmann 1992) –turtagning –”grounding” •bekräftelse att man förstår varandra –”core speech acts” (traditionella illokuta akter) •Exempel: Inform, YNQ, Check, Eval, ReqRepair, RecAck •en CSA involverar flera agenter, eftersom de måste bekräftas –argumentationshandlingar (retoriska handlingar) •Exempel: Elaborate, Summarize, Clarify, Q&A, Convince, Find-Plan

49 TrindiKit

50 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

51 module 1 module … Total Information State (TIS) •Information state proper (IS) •Module Interface Variables •Resource Interface Variables resource 1 control module i module j module … module n resource … resource m DME

52 •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 Information State (IS)

53 •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 Dialogue Move Engine (DME)

54 •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”) Modules and resources

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

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

57 TrindiKit basic dialogue theory basic system information state approach genre-specific theory additions genre-specific system How to build a genre-specific system •Add genre-dependent IS components, moves and rules

58 TrindiKit basic dialogue theory domain & language resources basic system application information state approach genre-specific theory additions genre-specific system How to build an application •Add application-specific resources

59 •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.) Building a domain-independent Dialogue Move Engine

60 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

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

62 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

63 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)

64 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) ) ] ).

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

66 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 ) ] ).

67 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

68 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

69 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

70 •explicit information state datastructure –makes systems more transparent –enable e.g. context sensitive interpretation, distributed decision making, asynchronous interaction •update rules –provide an intuitive way of formalising theories in a way which can be used by a system –represent domain-independent dialogue management strategies TrindiKit features

71 TrindiKit features cont’d •resources –represent domain-specific knowledge –can be switched dynamically •e.g. switching language on-line in GoDiS •modular architecture promotes reuse –basic system -> genre-specific systems –genre-specific system -> applications

72 Theoretical advantages of TrindiKit •theory-independent –allows implementation and comparison of competing theories –promotes exploration of middle ground between simplistic and very complex theories of dialogue •intuitive formalisation and implementation of dialogue theories –the implementation is close to the theory

73 Practical advantages of TrindiKit •promotes reuse and reconfigurability on multiple levels •general solutions to general phenomena enables rapid prototyping of applications •allows dealing with more complex dialogue phenomena not handled by current commercial systems

74 availability •TrindiKit website –www.ling.gu.se/projects/trindi/trindikit •SourceForge project –development versions available –developer community? •licensed under GPL •more info in –Larsson & Traum: NLE Special Issue on Best Practice in Dialogue Systems Design, 2000 –TrindiKit manual (available from website)

75 Issue-based Dialogue Management in GoDiS

76 Overview of contents 1.Introduction 2.Basic issue-based dialogue management 3.Grounding and feedback 4.Adressing Unraised Issues 5.Action-oriented Dialogue 6.Multilinguality 7.Conclusions

77 Introduction, goals •explore and implement issue-based dialogue management –starting from Ginzburg’s theory of dialogue semantics based on notion of QUD (Questions Under Discussion) –adapt to dialogue system (GoDiS) and implement –extend theory coverage, taking in relevant theories •general theory of dialogue –minimize effort for adapting dialogue system to new domains •incrementally extending system to handle increasingly complex types of dialogue –clarifies relation between dialogue genres –promotes reuse of update rules •Larsson (2002): Issue-based Dialogue Management (PhD Thesis)

78 GoDiS: an issue-based dialogue system •Built using TrindiKit –Toolkit for implementing and experimenting with dialogue systems based on the information state approach •Explores and implements issue-based dialogue management •Extends theory to more flexible dialogue –Multiple tasks, information sharing between tasks –Feedback and grounding –Accommodation, re-raising, clarification –Menu based action oriented dialogue –Multi-linguality & mutiple domains

79 input inter- pret TIS DATABASE LEXICON DOMAIN data- base control updateselect gene- rate output lexicon domain knowledge DME

80 TrindiKit GoDiS GoDiS-I GoDiS-A Travel Agency Auto- route Xerox manual VCR manager IBDM home device manager IS approach genre- specific applicatio n-specific

81 Issue-based dialogue management •enquiry-oriented dialogue (database search) •basis: –Ginzburg’s Dialogue Gameboard (DGB) and –related DGB update protocols •dialogue 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

82 Semantics •simple First Order Logic without quantifiers, but with questions •questions –Y/N-questions: ?P, P is a proposition –wh-questions: ?x.p(x) (p is a predicate) •? works much like like  –alt-questions: {?P1, …, ?Pn} •Content of short answers –individual markers: paris, april, … –yes, no

83 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

84 basic GoDiS information state record type PRIVATE : PLAN : stack( Action ) AGENDA : OpenQueue( Action ) SHARED : BEL : set( Prop ) COM : set( Prop ) QUD : stack( Question ) LU: SPEAKER: Speaker MOVES: OQueue( Move )

85 sample dialogue plan

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

87 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 relevant to 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

88 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”

89 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

90 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

91 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?

92 Grounding and feedback •Grounding –making sure that the participants are percieving, understanding, and accepting each other’s utterances –dealing with problematic situtations where e.g. an utterance is not percieved •Feedback moves –(short) utterances which signal grounding status of previous utterance •Sequencing moves –utterances which signal switching task (”returning to…”), reraising questions (”so…”) etc.

93 Grounding moves •We want a typology of grounding moves –Both feedback and sequencing •Some parameters: –Action levels in dialogue (Allwood, Clark) •contact •perception •Understanding –Word meanings –Contextual meaning •acceptance –Polarity •Positive •Negative •Interrogative (asking for confirmation)

94 Some grounding moves in GoDiS •Formal representation –icm:Level/Type{*Polarity}{:Content} •Feedback moves –icm:und*neg – ”I don’t understand” –icm:und*pos:P – ”To Paris.” –icm:acc*neg:Q – ”Sorry, I can’t …” –icm:acc*pos – ”Okay” •Feedback type selected depending on –Quality of recognised speech –Whether system can find a (relevant) interpretation –Whether system can accept what’s been said •Sequencing moves –icm:reraise:Q – ”Returning to the issue of Q” –icm:loadplan – ”Let’s see…”

95 Grounding on multiple levels 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) Negative perception feeback Positive perception Negative understanding Positive understanding (word meaning) Negative understanding (relevance) Task clarification

96 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) Rejection (negative acceptance feedback) Positive understanding User negative perception System repetition Positive acceptance

97 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> OK, 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)

98 Addressing Unraised Issues •QUD and ISSUES •General strategy: question accommodation •issue accommodation •QUD accommodation •dependent issue accommodation •issue reacommodation

99 A problem with QUD •If QUD= 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

100 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 adjusting QUD by copying a question on ISSUES

101 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...

102 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, as parts of the conversational scoreboard / information state

103 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, then –put that question on ISSUES –(and QUD if it is a short answer) •Requires that the number of possible matching questions is not too large –(or can be narrowed down by asking clarification question)

104 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

105 QUD 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]

106 dependent issue accommodation DOMAIN  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 (AKA ”task accomodation”)

107 Sample dialogue: accommodation S: Welcome to the travel agency. U: From London to Paris in April –not relevant to any question that has been raised, or to any current task –look in domain knowledge for a plan (for dealing with some question Q) with matching questions –load this plan, push Q on ISSUES –find in the plan the question(s) matching the user’s answer –integrate answer (requres matching question on ISSUES) S: Alright, you want to know about price. (…) –proceed to next plan item S: How do you want to travel? –ISSUES=

108 Task clarification (VCR application) S> What can I do for you? U> channel five S> channel five. I dont quite understand. Do you want to add a program or change channel? U> change channel S> Okay. change channel. S> Lets see. channel five? U> yes S> The channel was changed

109 Issue reraising SHARED.COM  ISSUES •If –LM=ask(Q) –there is a P in SHARED.COM s.t. relevant(P,Q) •then –push Q on ISSUES –remove P from SHARED.COM •used when previously resolved question is asked again •reraising should be inicated; ”so,…”; reformulation may be needed

110 Issue reaccommodation SHARED.COM  ISSUES •If –LM=answer(A) –no Q in ISSUES s.t. about(A,Q) –P in SHARED.COM s.t. there is a Q s.t. about(A,Q) and about(P,Q) •then –push Q on ISSUES –remove P from SHARED.COM •Used when previously resolved question is answered again

111 Revision by reaccommodation and reraising S> What can I do for you? U> add program channel five S> Okay. Do you want to add a program? U> yes S> Lets see. channel five? U> yes S> What date? U> channel six S> Okay. channel six… What date?

112 Issues and goals in Action-Oriented Dialogue (AOD) •each goal action associated with a dialogue plan •add field –SHARED.ACTIONS : StackSet(Action) •New moves: request(Action), report(Action, Status) •ACTIONS has a similar role to ISSUES •adapt accommodation strategies to AOD

113 AOD information state PRIVATE : PLAN : stackset( Action ) AGENDA : stack( Action ) SHARED : BEL : set( Prop ) TMP : (same type as SHARED) COM : set( Prop ) QUD : stackset( Question ) ACTIONS : stackset( Action ) LU:… ISSUES: stackset(Question)

114 Requests vs. answers •requests adresses a general question –”what shall I do next?”, ”what can I do for you?” or similar (”prompt”) –semantics in AOD: ?x.action(x) •dialogue –”What can I do for you?” raises?x.action(x) –”Search the phonebook” interpreted as request(search_phonebook) •Rule: –If ?x.action(x) is topmost on ISSUES and L-M is request(a) –then pop ISSUES

115 Questions vs. answers •a question can be regarded as a special type of request •so in a specific sense, questions are also answers… •questions adresses a general question –”what issue shall I address next?”, ”what can I do for you?” or similar (”prompt”) –semantics: ?x.issue(x) –this question is not presupposed •semantics of ”How can I help you?” in IOD is ask(?x.issue(x))

116 Action Oriented Dialogue subtypes •”Command dialogue” –user instructs system to perform actions •device control; menu-based •travel agency booking •”Instructional dialogue” –system instructs user to perform actions •”interactive manual” –system can explaing how to perform some action •joint planning –user and system jointly agree to a plan –also involves negotiation

117 input nuance inter- pret Information State LEXICON DOMAIN DEVICES lexicon vcrphone control updateselect gene- rate output nuance device phone domain vcrphone device vcr lexicon home domain home rel1 rel2 dim10 VCR device alert

118 Converting menus to plans MenuPlan multi-choice list P 1, P 2,..., P n findout({?P 1,?P 2,...,?P n }) tick-box +/-Pfindout(?P) dialogue window p=___ findout(?x.p(x)) pop-up message Minform(M)

119 Menu-based AOD S: Welcome to the telephone and VCR manager! U: Channel one today S: Right, I assume you want to add a program. Let’s see. Okay. Channel one. Today. What time do you want to start recording? S: What time is it? U: It’s one forty five S: Set the clock to two forty five U: Okay, set the clock. Two forty five, is that correct? S: Yes. U: Okay. The clock was set. Returning to timer recording. So, what time do you want to start recording? U: eight thirty to nine thirty S: Okay. Starting at eight thirty. Ending at nine thirty. The program has been added.

120 Task and question accommodation in AOD S> Lets see. What can I do for you? U> channel five today S> Alright. add a program… Lets see. Okay. channel five… today… What time do you want to start recording? U> from six thirty to seven thirty S> Okay. from six thirty… to seven thirty… The program has been added. ” Signals accommodation (sequencing ICM)

121 7. Multilinguality and multiple domains •Language and domain resources can be switched on the fly •Does not affect the rest of the system •Thanks to modularity structure of system

122 Multilinguality S> Lets see. What can I do for you? U> add program S> Okay. Do you want to add a program? U> yes S> Lets see. What channel do you want? U> svenska S> Okej. S> Gå tillbaks till lägg till ett program. Vilken kanal vill du spela in? U> kanal ett S> kanal ett, är det korrekt? S> Så, Vilken kanal vill du spela in? U> english S> Okay...

123 Multiple domains S> Welcome to the VCR manager! S> Lets see. What can I do for you? U> change domain S> Okay. change domain… Lets see. What domain do you want? U> telephone S> Okay. This is your automatic telephone operator… Lets see. Please specify a function. U> call S> Okay. make a phone call. S> Lets see. Please specify the destination of the call. U> luis S> Okay. Luis… Calling

124 Conclusions: GoDiS & Issue-Based Dialogue Management •general solutions to –dealing with multiple tasks –sharing information between tasks –grounding and feedback –user initiative (accommodation) –menu-based dialogue •rapid prototyping of applications –dialogue plans •switching language and domain online

125 Current and future work •Extend to more complex dialogue types –Negotiation (theory exists, not yet implemented) –Tutorial dialogue •Explore use of QUD and ISSUES to assign proper focus intonation –Stina Ericsson, forthcoming PhD thesis •In-home multimodal menu-based dialogue –Video player, mp3 player, lamps, agenda •Integrate with type-theoretical situation semantics

126 Dialogue systems and AAC •Speech-controlled devices, e.g. toys –standard dialogue system –speech recognition adapted for AAC needs •Communication aids –dialogue system tracks dialogue between user and other people; attempts to give proposals of what to say

127 Dialogsystem och AAC

128 •Using speech-controlled toys to train verbal interaction using AAC technology –user communicates using some communication device –user+device communicates verbally with the toy via a dialogue system –also send information (text) directly from AAC device to dialogue system; speech recognition not essential AAC device dialogue system Turtle ))) (((

129 •An example: a Logo turtle (Papert) –for learning math –a robot is programmed to draw geometrical shapes –what’s new: instead of typing commands to the turtle, the user speaks to it

130 •Multimodal dialogue systems for AAC users –multimodal menu-based dialogue allows user to adapt modalities to current needs

131 Ett annat sätt att se på dialogsystem: •Snarare än gränssnitt människa-maskin: •Hjälpmedel för kommunikation mellan människor och organisationer •Exempel: SJ’s dialogsystem kan ses som en representant för SJ –att tala med systemet är att tala med SJ, förmedlat via ett dialogsystem –jfr talesman för en organisation •Detta perspektiv kanske är intressant för AAC? –en användare kan välja att överlåta en del av sin kommunikation till en “representant” i form av ett dialogsystem (som användaren förprogrammerat till vissa beteenden, yttranden, historier...)


Ladda ner ppt "Dialogsystem Logopediutbildningen VT05 Staffan Larsson Institutionen för lingvistik, GU."

Liknande presentationer


Google-annonser