trindikit staffan larsson göteborg university sweden
TRANSCRIPT
TrindiKit
Staffan LarssonGöteborg University
Sweden
What is TrindiKit?
• A toolkit for dialogue systems R&D• Based on the Information State Update
approach• Aims to close the gap between theory
and practice of dialogue systems– today: complex theories, simplistic systems– adapt theories to make use of them in
systems
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
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
Key ideas
• thinking in terms of IS updates– update rules
• functions IS (+moves) IS (+moves)
• generic domain-independent dialogue management– requires modularity
• use of global information state – all modules can access all information
module1 module…
Total Information State (TIS)•Information state proper (IS)•Module Interface Variables•Resource Interface Variables
resource1
control
modulei modulej module… modulen
resource… resourcem
DME
TrindiKit
basicdialogue theory
domain & languageresources
basic system
application
information state approach
genre-specific theoryadditions
genre-specific system
• 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
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
TrindiKit and VoiceXML
• VoiceXML– industry standard– form-based dialogue manager– web/telephony infrastructure– requires scripting dialogues in detail
• Theory-specific?– VoiceXML implements a specific theory of
dialogue– TrindiKit allows implementation of several
different theories of dialogue– More complex dialogue phenomena hard to deal
with in VoiceXML
TrindiKit and VoiceXML, cont’d
• Combine VoiceXML with TrindiKit?– future research area – support connecting TrindiKit to
VoiceXML infrastructure– use TrindiKit system as VoiceXML
server, dynamically building VoiceXML scripts
– convert VoiceXML specifications to e.g. GoDiS dialogue plans
availability• version 2.1 is available• version 3.0a coming at end of 2002
– SIRIDUS deliverable D6.4
• 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)
Conclusions: TrindiKit & Information State Approach
• a toolkit for dialogue systems R&D• freely available to researchers• close the gap between theory and
practive of dialogue systems• theory-independent• promotes reuse and
reconfigurability on multiple levels
Flexible issue-based dialogue management
in GoDiS
Staffan LarssonGöteborg University
Sweden
Goals
• explore and implement issue-based dialogue management– adapt an existing semi-computational theory of
dialogue (Ginzburg’s KOS) to dialogue system (GoDiS) and implement
– extend theory (incl. accommodation, action-oriented dialogue, negotiation, conditional responses)
• separating general and domain-dependent phenomena helps reconfigurability– general theory of dialogue, extended into
subtheories for different dialogue types– minimize effort for adapting to new domains
TrindiKit
GoDiS
GoDiS-I GoDiS-A
TravelAgency
Auto-route
Xeroxmanual
VCRmanager
IBDM
homedevice
manager
ISapproach
genre-specific
application-specific
Basic issue-based dialogue management
• GoDiS-I: enquiry-oriented dialogue – typically, database search
• dialogue as raising and addressing issues
• dialogue plans to drive dialogue– each plan associated with a ”task question”
• deals with multiple simultaneous issues• enables information sharing between
plans
Multiple issues and information sharing
• user can switch freely between any number of tasks– e.g. set the clock while programming the VCR
• information collected while doing task A can be used in task B– e.g. where the user wants to travel; can be used for
travel reservation, visa enquiries, hotel reservation etc.
• this is a consequence of keeping a global information state, rather than task-local states (as in e.g. VoiceXML)
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 flightS> (…) What city do you want to go to? U> parisS> (…) What city do you want to go from? U> do I need a visa ?S> (…) Lets see. What country are you from? U> swedenS> Okay. Yes, you need a Visa. S> Returning to the issue of price. Lets see. What city do
you want to go from?
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– (short) utterances which signal grounding status of
previous utterance– in addition, utterances which signal switching task
(”returning to…”), reraising questions (”so…”) etc.
Question Accommodation
• to deal with – user giving more/less/other information than requested– simple information revision– reraising issues
• basic idea:– move questions to QUD or ISSUES to adapt to user
utterances– e.g. short answers where question can be found in the
context– generate clarification question if necessary
• more powerful than corresponding mechanisms in VoiceXML
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=<?x.how(x), ?x.price(x)>
Action-oriented dialogue based on menus
• GoDiS-A: adapted for the genre of action-oriented dialogue
• each plan now associated with an action or a question
• semi-automatic conversion of menus to dialogue plans
• sample domain: menu-based dialogue for VCR
Sample menu dialogue(with language change!)
S: Welcome to the VCR manager. Let’s see. What can I do for you?
U: Add a program today, channel five– request(add_program) -> plan is loaded– issue accommodation to integrate ”channel
five”
…S: What time do you want to start recording?U: Five fifteen…
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– negotiative dialogue (not yet implemented)
• rapid prototyping of applications– dialogue plans
• switching language online
end
Other architectures
• Agent communication protocols– Open Agent Architecture– KQML
• Dialogue system toolkits– DARPA Communicator– SOAR, NL-SOAR
• Systems (implementing specific dialogue theory)– Verbmobil– VoiceXML
• have been compared to TrindiKit (see deliverables or ask)
relevant properties
• support for information state approach– which datastructures/datatypes are
supported?
• support for managing control flow– not limited to pipelining
• asynchronous processing• modularity• potential for scalability
OAA
• ”Facilitator” (hub) manages communication between ”agents” (spokes)
• facilitator can maintain global information state– what datastructures are available?
• asynchronous processing• modular• similar to scriptless version of DARPA
Communicator
KQML
• Knowledge Querying and Manipulation Language
• communication protocol between agents
DARPA Communicator
• Hub-and-spoke architecture• modularity, flexible control,
asynchronous processing• hub functions
– message routing between servers (spokes)– state maintenance– control flow; script decides which server to
call next
DARPA communicator cont’d
• limited support for information states– ”tokens”: frames with name, index, and list
of feature-value pairs– tokens processed by scripts
• set of rules determining when to call a server + which arguments (features) to pass
• Hub scripts too limited to do real dialogue management– most actual systems have separate
dialogue manager– hub mostly used for data routing
SOAR
• toolkit for modeling cognitive agents• similar to TrindiKit in some respects• keeps single information state
– however, only one datastructure whereas TrindiKit has extendible range of (possibly complex) datatypes
• update rules– some nice ways of triggering rules which can be
considered for TrindiKit
• supports ”chunking” of rules– however, may not be too useful in practice
Verbmobil
• not dialogue system per se– rather, dialogue translation system
• several local information states, not one global – ”partitioned blackboard”– which datastructures? extendible set?
• limited control support