SPOKEN LANGUAGE DIALOGUE : FROM THEORY TO PRACTICE

A spoken language dialogue system is composed of many parts: speech recognition, speech synthesis, natural language understanding, dialogue manager, database, etc. Building a spoken language system for a new application requires in general a big effort for integrating all these parts, in addition to the effort required for designing, testing and tuning the dialogue behavior. This is especially true when complex dialogue tasks are built based on a mixed initiative paradigm. The approach suggested in this paper consists in shaping both the overall general architecture as well as the particular dialogue strategy as sequential decision processes. We discuss the concepts of stateful and stateless dialogue managers and we introduce a scripting language, DMD, which supports both. Finally we conclude with the description of the dialogue manager implemented for the DARPA Communicator multi l eg travel task. 1. DIALOGUE AS A SEQUENTIAL DECISION PROCESS A dialogue system can be formalized as a sequential decision process in terms of its state space, the set of possible actions, and the strategy [5][7]. The state space is defined by the collection of all variables that characterize the state of the dialogue system at a certain point in time. The set of actions describes what the system can do, i.e. the set of functions the system can invoke at any time (e.g. play a certain prompt, query a database, hang up, etc.). The strategy is a mapping between the state space and the action set. For any possible state the strategy prescribes what is the next action to perform. As a result of the action and its interaction with the external environment (e.g. user, database, etc.) the system gets some new observations (e.g. output of ASR, database tuples, etc.). The new observations are registered and modify the state of the system. This process continues until a final state is reached (e.g. the state after hang up in a telephone interaction). Following this formalization, the process of a dialogue system can be summarized by the algorithm in Fig. 1. The system starts in the initial state I S . t S denotes the system state at turn t. The function NextAction determines the next action t A to be invoked, and the function NextState updates the state variables with the external observations. The process is repeated until a final state F S is reached. 2. THE AMICA DIALOGUE ARCHITECTURE In this section we show how the sequential decision process formalization was implemented in the AT&T dialogue architecture and toolkit (AMICA [8]). 2.1 The Dialogue State The dialogue state in the AMICA architecture is represented by a recursive key/value data structure. We call this structure template. A template can be easily mapped to similar data structures such as the Galaxy frames [6] used by MIT and constituting the standard for the DARPA Communicator [9] architecture. 2.2 Dialogue Actions The action set of the dialogue system includes all possible actions it can perform, such as interactions with the user (e.g. asking the user for input, providing a user some output, confirmations, etc.), interactions with other external resources (e.g. querying a database), and internal processing. In our architecture an action is a function that reads a template, possibly interacts with the environment, and returns a modified template. Of course actions can be defined at different levels of granularity. For example an action corresponding to the interaction with a user can be broken into separate lower level actions, including generating the prompt, activating the speech synthesizer, activating the speech recognizer with appropriate grammars, getting input from the speech recognizer, and parsing it. It would be desirable to have a small set of generic high level parametric dialogue actions that could be used in any dialogue system. Indeed we can define a set of high-level abstract dialogue actions, or dialogue acts, such as confirmation, constraining,