<?xml version="1.0" standalone="yes"?>
<Paper uid="A92-1040">
  <Title>Dialogue Management for Telephone Information Systems</Title>
  <Section position="3" start_page="0" end_page="0" type="metho">
    <SectionTitle>
2 Two Problems of Dialogue
</SectionTitle>
    <Paragraph position="0"/>
    <Section position="1" start_page="0" end_page="0" type="sub_section">
      <SectionTitle>
Management
</SectionTitle>
      <Paragraph position="0"> The SUNDIAL dialogue manager addresses two problems facing spoken dialogue systems. The first is that, for maxinmm usefulness, dialogue management needs to be generic: i.e. the dialogue manager module must be able to interpret and generate utterances in more  system.</Paragraph>
      <Paragraph position="1"> thai\] one language and across more than one task domain. The. second problem is that dialogue management must provide co-operative interaction with the user. To achieve this, the system needs to produce utterances which are perceived by the user as natural, coherent and helpful within the context of the dialogue. The purpose and modality of the dialogue forms part of this context: in our case, task-driven spoken dialogues. The system needs to deal with inconsistent task information, such as that obtained when the speech recognizer and parser yield a. plausible but incorrect interpretation; for exampie, the user said 1 want to fly to Lannion, but the system understands London rather than Lannion.</Paragraph>
    </Section>
  </Section>
  <Section position="4" start_page="0" end_page="245" type="metho">
    <SectionTitle>
3 A Distributed Solution
</SectionTitle>
    <Paragraph position="0"> The Sundial solution to these problems lies, in part, ill the distributed architecture of the dialogue manager. Tile dialogue manager is responsible for providing a co-operative interaction with the user (Gerlach and ttoracek, 1989). From the user's point of view, system utterances must be appropriate and helpful to the user iTi the cur'rel~t dialogue context. To achieve this, both interpretation of user utterances and planning of system utterances must. be informed by the past and current states of the interaction. Co-operative dialogue managemeut, therefore, requires the construction and maintenance of an interactional model: i.e. a model which specifies the layers of st.ructure which can be distinguished in dialogues. Following Grosz and Sidner (1986) we distinguish linguistic structure, attentional, or belief structure, and intelltionM structure. Intentional structure is further differentiated into dialogue structure and task structure (Bunt, 1989). tiowever, rather than using a unitary model where these layers are given as a single structured representation, we have adopted a distributed model where these layers are distributed across a. number of modules. Each rnodule consists of a partial model of the interaction, rules for updating the model as well as associated dialogue management flmctions. \[&amp;quot;urthern~ore, modules may need to collaborate with each other in order to determine how to update  their model: their update rules may depend upon information maintained in another module.</Paragraph>
    <Paragraph position="1"> The interactionM model is falsification definite since agents assume rather than infer that their belief model corresponds to that of the other agent. This places an obligation on agents to make explicit the state of their belief model so as to give the other agent the opportunity to correct or modify it. For example, if the system utters You want to. go to London in response to the user's request, the user has an opportunity to contest the current state of the system's belief model.</Paragraph>
    <Paragraph position="2"> The Sundial dialogue manager consists of five modules. The linguistic interface module interfaces the dialogue manager with the parser and is responsible for maintaining a linguistic model of system and user utterances. The dialogue module is responsible for maintaining a model of dialogue context, building an interpretation of user utterances and determining how the dialogue should continue. Dialogue structure is based on the framework of Roulet and Moeschler in which dialogue is hierarchically structured il/to exchanges, interventions and dialogue acts (Moeschler, 1989). In order to determine the appropriate contextual interpretation of user utterances, the dialogue module interacts with the belief module which maintains a model of belief containing not just concepts created directly as a result of user utterances, but also inferential extensions. For example, if the system initiated an exchange to determine tile departure date of a flight, this exchange can be closed if the belief model can interpret the user's utterance as refierencing a 'date' concept. The belief module requires context information from the dialogue module in order to guide the interpretation process. For example, the second can reference date or flight concepts (the second of May or the second flight) depending on the context. The belief module additionally eoopera.tes with the message plaT~ning module in order to provide selnantic descriptions of concepts referenced in the plan of system utterances.</Paragraph>
    <Paragraph position="3"> Finally, the task module is responsible for maintaining a model of the task structure of the dialogue, consulting domain-specific application databases and informing the dialogue module of the current state of t.he ta.sk.</Paragraph>
    <Paragraph position="4"> Typically, this involves deciding whether sufficient task information has been provided by the user and, if not, which additional parameters are required. 1,ess frequent are int~'ractions which arise when a user provides sulficient, but incorrect, information: for example, there is no flight to the stated destination city. Rather than simply informing the dialogue module that the task cannot be satisfied, the task module a.ttempts to relax task parameters and suggest, alternative vMues for them (Guyomard and Siroux, 1988). For example, if there are no flights available ill the morning of the given departure day, flights in the afternoon n-my be suggested. In such cases, system utterances are selected and formulated so as to make explicit to the user the fact that an alternative is being offered.</Paragraph>
  </Section>
  <Section position="5" start_page="245" end_page="245" type="metho">
    <SectionTitle>
4 hnplementation
</SectionTitle>
    <Paragraph position="0"> Tile Sundial dialogue manager has been implemented in Quintus Prolog and tested on a variety of differem hardware platforms. It has been integrated with the rest, of the Sundial system and successfully manages a range of English, French, and German spoken (public network) telephone dialogues relating to flight enquiries, flight reservations, and train enquiries. Language and task call be changed in the dialogue manager simply by resetting switches which govern the choice of static knowledge bases consulted during dialogue management.</Paragraph>
    <Paragraph position="1"> Current average response times for the entire Sundial system (including speech recognition and synthesis) are around 10 seconds, with the dialogue manager taking 1-2 seconds. However, a significant amount of optimization has still to be carried out, and it is expected that response times will approach real time within the next six months. The lexicon currently contains around 300 entries for each language.</Paragraph>
  </Section>
class="xml-element"></Paper>