Adaptive Mixed-Initiative Dialogue Management

Transcription

1 Adaptive Mixed-Initiative Dialogue Management Gert Veldhuijzen van Zanten IPO, Center for Research on User-System Interaction, P.O. Box 213, 5600 MB Eindhoven, the Netherlands ABSTRACT This paper describes an architecture that supports adaptive mixed-initiative dialogue. It is based on a generalisation of the form-filling paradigm. Rather than a flat slot structure, we use a hierarchy that contains slots at various levels of abstraction. Along with the slot hierarchy, a question hierarchy is defined that allows for adaptive mixed-initiative dialogue. Depending on the success or failure of certain questions, the system can zoom-in to more detailed questions, or zoom-out to higherlevel questions. The distribution of initiative in dialogue is closely related to the granularity of the information that is asked for. To determine the right granularity level for system questions we have to take into account the influences on user freedom, predictability and the knowledge of the user. Giving the user initiative is suitable in situations where the user knows what to do. In such cases, the user may give all relevant information in one turn. However, giving the user more initiative tends to make his behaviour less predictable and therefore increases the chance on speech-understanding errors. The system should switch to lower-level questions when higher-level ones fail, and when the user supplies unsolicited information, the system can switch to higher-level questions. INTRODUCTION Many practical dialogue systems are based on the formfilling paradigm. To perform some action on behalf of the user, the system needs information from the user. This information is represented as a fixed set of slots, and questions can be asked for each slot. One of the merits of the slot-filling paradigm is that it allows a clear distinction between the dialogue task (exchanging information) and the dialogue strategy. The task is described by the slots themselves and the possible values that they may get. The strategy is concerned with the order in which slots are discussed, and with grounding of slot values, i.e. with inconsistencies, ambiguities and uncertainties that can arise when the dialogue participants attempt to build a common ground. Dialogue strategies can be reused for many different domains, so that developing a dialogue system for a new domain is limited to specifying a new set of slots and their semantics. A drawback of the slot-filling paradigm as it stands, is that it results in rather rigid dialogues. The model dialogue within the slot-filling paradigm is one in which a number of system questions are interleaved with answers from the user, each answer answering just the question that was asked by the system. In spoken human-human dialogues, this kind of dialogue is very rare; People ask questions that refer to concepts that involve more than one slot, and they are often overinformative and say things which they believe are relevant, even when they aren t asked for. More so, they use these devices intelligently, using high-level concepts to open the dialogue, and zooming into details when problems arise. Many systems (for instance, the one described by Aust et al. [[1]]) are able to ask questions involving more than one slot and to process overinformative answers. However, there is no way to control this dimension intelligently within these systems. The expectations that users have about the capabilities of the system influence their behaviour. Given the state of technology that most users are familiar with, the expectations will generally not be very high, and consequently users will only assume capabilities that the system itself presents to the user. By asking very specific questions like On which date do you want to travel? a system does not give a clue that it might be able to process over-informative answers, and as a result its users hardly ever give over-informative answers to such systems, even though this could make the dialogue considerably more efficient. Another drawback of using a fixed set of slots is that problems that arise in the understanding of parts of slot values cannot be discussed. To alleviate some of the problems mentioned above, we will present a dialogue-management framework that is based on a hierarchically structured set of slots. The hierarchy contains slots at various levels of abstraction. These slots give rise to questions from relatively general ones like When do you want to travel? to very specific questions like Do you want to travel on September 30th? and several levels in between. The hierarchy serves several purposes: One is the representation of partial information. This is needed when speech-understanding errors occur, or when the user gives incomplete answers. The information that is sup-

2 plied and understood can be stored in lower level slots (for a description of this process see [[2]]). Another purpose is the interpretation of user utterances in which information is given that was not asked for. When this happens, it is assumed that the user utterance answers some higher-level question. This is essential for mixedinitiative dialogue. And finally, it allows for adaptive mixed-initiative. Depending on the success of failure of certain questions, the system can zoom-in to more detailed questions, or zoom-out to higher-level questions. We will claim that initiative in dialogue has to do with the granularity of the information that is asked for. Users, especially naïve ones, tend to answer the system question and are not inclined to give information that was not asked for. So, when the system asks general questions the user may take the initiative in deciding which details to mention. While by asking specific questions the system takes the initiative. Determining the right level of initiative is finding some optimum in the trade-off between user-freedom and user-predictability. User-initiative is suitable in situations where the user knows better than the system what is going on. When given initiative, the user may give all relevant information in one turn. However, giving the user more initiative tends to make his behaviour less predictable and therefore increases the chance of speech-understanding errors. We propose a dialogue-management strategy in which initiative is adaptively given away when appropriate, but where the system takes the initiative when errors are detected. We will give an example of the kind of dialogue we envisage. 1. S: This is the train-information system of the Dutch Railways. How can I help you? 2. U: I want to visit my aunt, she lives opposite the city hall. 3. S: Sorry, I don't understand your request. Do you want information about train connections or about prices? 4. U: About a train connection. 5. S: Which train connection? 6. U: From Utrecht to Amsterdam. 7. S: When do you want to travel from Utrecht CS to Amsterdam CS? 8. U: I need to be there at eleven o'clock tomorrow morning. 9. S: Eleven o'clock tomorrow morning? 10. U: Yes. 11. S: You can leave at half past ten at Utrecht CS. Your train will arrive at Amsterdam CS at eleven o'clock. Do want any other information? 12. U: Yes, at what platform does my train leave? 13. S: Sorry, I don't understand your request. Do you want information about earlier or later trains, the return trip or about the price? 14. U: No thanks. 15. S: OK, thank you for using our service. In utterance (1), the initiative is completely left to the user. The advantage is that the user may directly state all relevant information for his or her request, as in I'd like to travel tomorrow morning from Amsterdam to Utrecht and I need to be there at 11 o'clock. In this example, it leads to a request that cannot be understood, and therefore a more specific question is asked (3), summing up all alternatives that the system can understand. In utterance (5), the system asks the most general question that is still appropriate given the current state. In section I., we discuss the structure of the information exchange task. It is based on a hierarchical value model, which can be seen as a generalisation of a form with slots. In section II., we describe how the dialogue manager makes use of the value hierarchy to define goals that must be fulfilled in the dialogue. In section III., we describe a hierarchy of questions, and in section IV., we show how this question hierarchy can be used as a dimension along which the initiative in the dialogue can be adaptively controlled. I. TASK STRUCTURE Before we look at how a dialogue can be managed, we will first look at the structure of the task that we want to accomplish with the dialogue. The kind of task that we are interested in, in this paper, is the information exchange task. In such a task, the system has information about a set of values, called the value domain. In the case of a train information system, this set represents the set of all train connections. The goal of the information exchange task can be modelled as giving information about a particular subset of the value domain that the user is interested in. The task can be divided into two sub-tasks: In the first sub-task the subset of the value domain that the user is interested in is determined, and in the second sub-task the information is presented to the user. For both subtasks dialogue is needed, so that the user and the system engage can co-ordinate their activity to ensure mutual understanding. In the first sub-task, the user' s interests are matched to the set of values that the system has knowledge about. Pieraccini, Levin and Eckert [[3]] describe a model in which the subset of the value domain is determined by means of constraining and relaxing sub-dialogues. The dialogue starts with the full domain, and by getting constraints from the user, a subset is determined. In this process, the subset may become empty, for instance, when the user says I want to take a train from Amsterdam to Maastricht and want to leave at 15:00 this afternoon, while there is no train that leaves at that time. Then the system enters a relaxation sub-dialogue in order to give some information that is nevertheless relevant, such as There is a train that leaves at 14:58. In the second sub-task, the dialogue deals with making sure that the user understood the information correctly.

3 Connection = { origin: Event, Price Event Place Town via: LIST OF Event, destination: Event, price: Price } = { guilders: Integer, cents: ( ) } = { place: Place, moment: Moment } = { town: Town, Suffix = cs... Moment suffix: Suffix } VALUES asd... = amsterdam... rotterdam = { date: Date, time: Time } VALUES now... RELATIONS after, before Date = { year: ( ), month: (jan feb... dec), day: ( ), day_of_week: (sun mon... sat) } VALUES today tomorrow... Time = { clock_hour: ( ), hour: ( ); minute: ( ); part_of_day: (night morning afternoon figure 1: types from the train domain A. The Hierarchical Slot Structure For the representation of information in the dialogue, we use a formalism, whose expressive power is rather weak when compared, for instance, to that of first order logic; Disjunctions of values cannot be represented. Yet it is sufficient for our purposes, and it is still stronger than the expressive power of slot-filling formalisms that use a unstructured set of slots. The basis of the formalism is a set of together with a set of constraints. Each slot has a set of possible values. The constraints limit the number of values that a slot can have. A constraint has one of the four following forms f ( x) = y, f ( x) y, x r y or evening) } x ~ y where f is a partial function called a feature, r is a relation and x and y are slots or values. The first two forms are functional constraints, the first one positive and the second one negative. The third form is a relational constraint between slots or values of the same type. And the fourth form represents that one slot or value dominates another through one or more (unknown) positive functional constraints. The slots and values in a domain are typed, and for each type only a limited number of features and relations is defined. A connection value, for instance, has features that return that connection s origin and destination, but these features are not defined for date values. An overview of the types and features in the train domain is shown in figure 1. Here, we can see, for instance, that a value of type moment, has date and time features, which in turn can be further divided with year, month, day, week and day of the week, hour, and minute features. We can also see that now is a value of type moment, and that moments can be related to each other through after and before relations. The set of all features of the domain constitutes a hierarchy over the values of the domain. It is defined as the smallest relation that satisfies the following equations. f ( a) = b a b a b and b c a c The functional character of features constitutes a hierarchy where the value in the argument position of a feature stands higher in the hierarchy than the result. Relations, on the other hand, have no bearing on the hierarchy; They are only allowed to stand between values of the same type, so that here both related values stand at the same level in the hierarchy. Relations are needed to represent the constraints that are expressed by an utterance such as I need to be there before 10 pm. The semantics of a set of constraints P is defined as a set of mappings m from the slots that are mentioned in the constraints, to the values in the domain. These mappings need to satisfy the constraints. [ P] = { m:( X D) D a D m( a) = a, ( f ( x) = y) P f ( m( x)) = m( y), ( f ( x) y) P f ( m( x)) m( y), ( x r y) P ( m( x), m( y)) r and ( x ~ y) P m( x) m( y) } Here, X is the set of all slots, and D is the set of all values in the domain. For our application, it consists of all possible train connections, together with their subvalues, such as train stations, dates, years, months and integers. B. Updates, Belief Revision Utterances of the user and the system are interpreted as updates of an information state, that consists of a set of constraints with associated modalities. The modalities define whether some constraint is in the common ground, a default assumption, or whether one of the participants has requested to know whether the constraint holds or not. We keep track of the reasons why certain constraints have been added to the information state. This is needed in order to do belief revisions, which are needed when corrections or denials occur, or when inconsistencies are detected. Inconsistencies that cannot be removed by dropping assumptions have to be dealt with in the dialogue. The details of the update and belief revision algorithm are beyond the scope of this paper, and are discussed in [[4]]. C. Grounding The predications in the information state are associated with justifications. These justifications may be either utterances or inferences. The justifications are needed for belief revision, but also for a process called ground-

4 ing. Traum [[5]] discusses a computational theory of grounding, in which participants in a dialogue engage in co-operative behaviour that involves maintenance of a common ground. Participants check and acknowledge utterances to ensure that both participants agree upon what has been said and establish mutual beliefs. In our system, an important act in the grounding process is the verification act. Each value that was recognised by the speech recogniser is verified, by means of either an implicit or an explicit verification act. An implicit verification is done as in When do you want to travel to Amsterdam Central Station?, where Amsterdam Central Station is implicitly verified. An explicit verification can be done with a yes/no-question, as in Do you want to go to Amsterdam Central Station?. Implicit verification is quite risky, because it depends on the assumption that the user will rectify presuppositions in system utterances. The choice for explicit or implicit verification can be done adaptively, depending on confidence scores [[6]], or on the success of the dialogue so far [[7]]. II. DIALOGUE GOALS For the kind of dialogues we are discussing in this paper, it is safe to assume that participants are engaged in the dialogue because they want to achieve specific goals. The dialogue manager has to select actions that are likely to be effective in achieving these goals. In our framework, goals can be expressed in terms of knowledge that both participants have about certain slots. The more we know about a slot x, i.e. the more constraints it is involved in, the lower the number of values will be that the slot can contain. We call this number the cardinality of x given the set of constraints P. { m [ P] } cardinality( x, P) = a ( m( x) = a) When we know everything about a slot, the cardinality will be one. We distinguish three kinds of goals: Firstly, to get to know what slot(s) the user is interested in. Secondly, to get constraints on a certain slot in order to lower the cardinality of that slot. And thirdly, to get the user to know everything about a certain slot. Assuming that the slot hierarchy is well-designed, these three kinds of goals will be sufficient to model all relevant goals in the dialogue. A. Getting to know the user' s concern Actions that may be effective in achieving the first kind of goal are questions like How may I help you? or Do you want information about prices or about a train connection?. To represent the questions and answers about the user concern, we add a special slot, whose value can be a set of slot, namely those slots that the user is interested in. With this additional slot, we can treat the topic of the user' s concern in just the same way as other topics in the dialogue. B. Getting to know the relevant values When the first kind of goal is fulfilled, the system knows the user s concern. This concern is represented by a (possibly singleton) set of slots. Each slot in this set serves as a goal of the second kind. The cardinality of each concern slot must be lowered. Obviously, this cannot be done by asking questions about that slot itself or about sub-ordinated slots, because the user will not know about these. E.g., when the user wants to know when a train to Amsterdam leaves, she will not know at how many minutes after the hour it will leave. Therefore, the system sets up as a constraining goal a slot that dominates all user-concern slots. Due to the functional character of the features, a low cardinality for the dominating slot will also lead to a low cardinality for the subordinated slots. This dominating slot and, in particular, slots sub-ordinated to it that are not also sub-ordinated to the user-concern slots are called parameters to the user-concern. Suppose, for instance, that the user is concerned with the price of a connection. Then the system cannot ask for how many guilders, or how many cents, but instead has to inquire about other sub-slots of the connection, for instance, the origin and destination sub-slots. When the system knows about the origin and the destination, the cardinality of the connection slot (that dominated the price slot) will be lowered, and therefore, probably also the cardinality of the price slot. In general, the problem of selecting the best sub-slot to inquire about in order to lower the cardinality of a sub-slot is a difficult one, that requires further study. For now, we use a fixed set of rules that is tailored to the application. There are several actions that may lead to the fulfilment of a constraining goal for a given slot x: firstly, we can ask a question, such as Which connection are you interested in? that asks directly for a value of x or, secondly, we can ask a number of questions that query subslots of x. In our case, for instance, From where to where do you want to travel? and When do you want to travel?. Each of these indirect questions can again be expressed as the identification of some slots, in this case an origin, a destination and a date/time slot. These slots stand in relation to the original connection slot through functional predications. origin( c) = o destination( c) = a datetime( c) = m where c is the connection slot, o the origin slot, a the destination slot and m the date/time slot. Each of these slots can again be fulfilled directly or indirectly. For instance, m could be queried indirectly by asking for a date d and then a time t. date( m) = d time( m) = t When the dialogue manager determines that a direct question for some goal slot x is not appropriate, it will set up new goals for slots below x.

5 C. Satisfying the user Once the first and second kinds of goal have been fulfilled, the system must report about the slots that the user wanted to know about. For this purpose, the database is queried, and when successful, the results are matched to the slots that the user was interested in. Then a number of constraints is determined that is sufficient to explain the unit cardinality of the user-concern slot(s). These constraints involve the user-concern slots and slots that are sub-ordinated to it. Through a process of grounding, these constraints are transferred to the user. When the database query is unsuccessful, the cardinality of the concern slots will become zero. The constraints then must be relaxed, so that the cardinality becomes greater than zero. Selecting the right constraints for relaxation is difficult, and depends very much on the task that the user is involved in. In our system, we have selected time slots for relaxation, so that if the system cannot find a connection that arrives or departs at the user specified time, it will give information about a connection that arrives or depart somewhere near the specified time. III. QUESTION HIERARCHY We can distinguish three kinds of questions: open questions, alternatives questions and yes/no questions. An example of an open question is: On which day of the week do you want to travel?, of an alternatives question is: Do you mean 10 o' clock in the morning or in the evening? and a yes/no question is: Do you want to travel to Baarn?. An alternatives question should only be asked when the number of alternatives is rather small, and when it can be expected that the user does not know which alternatives are available. Yes/no questions are appropriate when one alternative is much more likely than the others, or when the speech recogniser has a high probability of mixing up two alternatives. When the system wants information about a slot, it has to chose between these three kinds of questions. A fourth option that the system has is to divide the question into several lower level questions. For instance, when an open question for a date fails, an alternatives question mentioning all possible dates is out of the question. So the system could start asking for the year, month and the day of the month. On closer examination yes/no questions are not a separate category. They can be treated as if they concern boolean sub-slots. For instance, a day-of-the-week slot with values sun through sat, can have features su n- day through saturday that lead to a slot that can co n- tain either the value yes or no. Semantic rules must ensure that only one of the slots can contain yes. The fact that yes/no questions can be treated by sub-slots suggests that we can ask two different kinds of yes/no questions, namely, open yes/no questions and alternatives yes/no questions. This can indeed be useful. When an open yes/no-question like Do you want to travel on Sunday? is not answered by Yes or No, and speech recognition errors occur, we could add a phrase Please answer yes or no, to obtain an alternatives yes/no question. Open and alternatives questions differ only in the amount of information that they give to the user. Therefore, open questions should be used when we have reason to believe that the user knows which kinds of answer the system expects. Otherwise, an alternatives question can be used to inform the user of the possible answers that the system is expecting. Given these observations about questions, we can conclude that the slot hierarchy can be used as a hierarchy of questions. The most general question is How can I help you? that asks about the user concern slot, and lower level questions can be asked for sub-slots. A complication is that not every kind of question can easily be expressed in natural language. For instance, a question like? is not very natural. So in some cases, the system may need to fall back on lower level questions instead. IV. ADAPTIVE INITIATIVE In section II., we discussed the goals that the system can pursue. To pursue a constraining goal for a certain slot, a question can be asked for that slot. But whether this should be an open or an alternatives question depends on the situation. And it also depends on the situation whether we should ask a question for that particular slot, or whether we should ask questions about slots higher-up or lower-down in the hierarchy. In this section, we will discuss the circumstances in which certain kinds of questions are appropriate. In general, the right kind of question depends on the user that is calling the system. A user that knows what she wants, and knows what the system can and cannot do is best helped with a high-level open questions like How can I help you?. In response to it, the user may give all relevant information in one go, e.g. I would like to know, how much is a ticket from Maastricht to Den Helder?, thus telling the system both her concern (ticket price) and the relevant parameters (origin: Maastricht, destination: Den Helder). However, a more naïve user may not know the systems limitations and ask something that the system is incapable of understanding, let alone answering. In that case, it would have been better if the system had told the user what its capabilities are, for instance, by asking an alternatives question like Do you want information about prices, or about a train connection?. Open high-level questions give the user a lot of initiative, whereas low-level alternatives questions take away the initiative from the user. The right level of initiative is the level that corresponds to the level of knowledge that the user has about the application. The problem is that we never know beforehand what kind of user we are dealing with. Therefore, we should construct a user model on the fly, making assumptions

6 and changing them when evidence comes to light. The assumptions can be based on user studies, or on educated guesses. The important thing is that the system adapts when things go wrong. There are two important questions: What does a user model consist of? and What kind of evidence can be used to adapt the user model? The user model consists of a function that tells for each slot whether the user is familiar with its relevance to the overall dialogue goal, with the values that it may contain, and with its sub-slots. Speech recognition errors (or very low confidence scores) are a strong form of evidence that something is wrong with the user model. We propose that in case of speech recognition errors, the highest level user model assumption is dropped. This causes the dialogue manager to switch from an open question to an alternatives questions, or to a number of questions about sub-slots. When the user gives an over-informative answer, this is evidence that the user is aware of the relevance of the slots that have been volunteered, and thus the system can adapt its user model and ask the next question at a higher level. V. CONCLUDING REMARKS We have proposed an adaptive mixed-initiative dialogue management strategy that is based on a hierarchical slot structure. The hierarchy is used to divide the application domain into slots of various levels of abstraction. We have argumented that the granularity of information influences the distribution of initiative in dialogues. Conclusive results must come from experiments with an actual system, that is currently being developed. We use a user model to determine the right generality level for asking questions, and adapt the model when evidence comes to light that the assumptions in the model are at fault. This kind of adaptivity is essential for efficient dialogues, because it allows maximum freedom for the user to express herself in a way that she believes is the most efficient for her specific task. Furthermore, and this is an important point, the uncertainty that is inherent in spoken communication makes perfection an unattainable goal, and adaptivity is the next best thing. Train Timetable Information System, in: Proceedings of the IVTTA ' 94 2nd IEEE workshop on interactive voice technology for telecommunications applications, Kyoto, Japan, pp [2] G.E. Veldhuijzen van Zanten (1996) Pragmatic Interpretation and Dialogue Management in Spoken-Language Systems, In: LuperFoy, S., Nijholt, A. and Veldhuijzen van Zanten, G.E., TWLT11: Dialogue Management in Natural Language Systems, Proceedings of the Twente Workshop on Language Technology 11, pp [3] R. Pieraccini, E. Levin and W. Eckert (1997), AMICA: the AT&T Mixed Initiative Convers a- tional Architecture, Eurospeech 97, pp [4] G.E. Veldhuijzen van Zanten (1998), An Efficient Dialogue Module for OVIS2, Document 52, Priority Programme Language and Speech Technology (TST), January 1998, pp [5] David R. Traum (1994), A computational Theory of Grounding in Natural Language Conversation, PhD Thesis, Univ. of Rochester, Rochester, New York, pp [6] A.G.G. Bouwman and J. Hulstijn (1998), Di a- logue Strategy (Re-)Design with Reliability Measures, in proceedings of the first International Conference on Language Resources and Evaluation, Granada, Spain.. [7] W. Eckert (1996), Gesprochener Mensch- Machine-Dialog, PhD thesis, Shaker Verlag, Aachen, ISBN , ISSN , (in German). ACKNOWLEDGEMENT This research is carried out within the framework of the Priority Programme Language and Speech Technology (TST). The TST-Programme is sponsored by NWO (Dutch Organisation for Scientific Research). REFERENCES [1] H. Aust, M. Oerder, F. Seide and V. Steinbiss (1994), Experience with the Philips Automatic