<?xml version="1.0" standalone="yes"?>
<Paper uid="E87-1031">
  <Title>PLANNING FOR PROBLEM FORMULATION IN ADVICE-GIVING DIALOGUE</Title>
  <Section position="1" start_page="0" end_page="0" type="metho">
    <SectionTitle>
PLANNING FOR PROBLEM FORMULATION
IN ADVICE-GIVING DIALOGUE
</SectionTitle>
    <Paragraph position="0"/>
  </Section>
  <Section position="2" start_page="0" end_page="186" type="metho">
    <SectionTitle>
Abstract
</SectionTitle>
    <Paragraph position="0"> We distinguish three main, overlapping activities in an advice-giving dialogue: problem formulation, resolution, and explanation. This paper focuses on a problem formulation activity in a dialogue module which interacts on one side with an expert problem solver for financial investing and on the other side with a natural language front-end. Several strategies which reflect specific aspects of person-machine advice-giving dialogues are realized by incorporating planning at a high-level of dialogue.</Paragraph>
    <Paragraph position="1"> Introduction As performances and scope of intelligent systems increase and the interaction of a system with a user gains in complexity, it becomes desirable to provide an easy initial access to a system for the novice user. Natural language is a medium presumably known by most users. For the system however, it not only requires understanding natural language &amp;quot;utterances&amp;quot; (on a keyboard) but also recogni~.ing the intentions behind these utterances. It leads to a full-fledged dialogue involving much reasoning at the pragmatic level of the communication process. The competence of most intelligent systems is usually bound to a restricted application domain and we can imagine that part of a dialogue is domain-dependent while another is domain-independent. Our efforts aim at designing a dialogue module making these different aspects explicit and interacting with other knowledge-based agents. This work contributes to Esprit Project 816 EsteamX: An architecture for distributed problem solving by cooperating data and knowledge bases. Advice-giving systems for financial investment have been chosen as a first testbed application.</Paragraph>
    <Paragraph position="2"> This paper describes preliminary research on the dialogue module of such a system and the resulting prototype.</Paragraph>
    <Paragraph position="3"> An advice-giving dialogue comprises three main activities, which may overlap: - l~wblsm form,dug/on, where the various needs and capabilities of the user are elicited; - reso/uh'on, in which a possible solution to the problem is determined; - ezpla~;tion, which aims at convincing the user that IThe project is supported in part by the Commission of the European Communities the solution is in fact what she/he needs.</Paragraph>
    <Paragraph position="4"> Our work concentrates on a problem formulation activity in a dialogue module which cooperates with a problem solver and a natural language front-end. The problem solver selects adequate securities for basic investment situations of a private investor and is being developed as part of the same Esprit project \[Bruffaerts 1986\]. The natural language front-end based on functional grammars is the result of separate research at Cap Sogeti Innovation \[Fimbel 1985, Lancel 1986\].</Paragraph>
    <Section position="1" start_page="0" end_page="186" type="sub_section">
      <SectionTitle>
Computational Aspects
</SectionTitle>
      <Paragraph position="0"> Dialogue and communication theory are a broad field of studies drawing on several disciplines, among them philosophy, cognitive science, and artificial intelligence. The flurry of research devoted to these topics in recent years is largely enough to convince us we could not seriously hope to tackle the &amp;quot;general&amp;quot; problem. We have therefore limited our interest to person-machine advice-giving dialogue and we focus on two essential characteristics of this kind of dialogue: - the system has intentions and extensive knowledge about the domain which are a pr/or/unknown to the user; - the user's intentions must be interpreted in terms of the system's abilities or inabilities.</Paragraph>
      <Paragraph position="1"> We can see the first point as a manifestation of the &amp;quot;expertness&amp;quot; of the system, and the second as a manifestation of the Unoviceness~ of the user.</Paragraph>
      <Paragraph position="2"> We briefly recall some other research issues connected to our work and then elaborate on the specific aspects of person-machine advice-giving dialogue.</Paragraph>
      <Paragraph position="3"> Many efforts have been devoted to developing a general theory for speech act understanding \[Searle 1969, Allen 1980, Cohen 1979\]. Recognizing the illocutionary force of a speech act allows the system to reason about the intentions of the user and to behave accordingly. Most work in this field addresses only isolated speech acts or sometimes single utterances and is not concerned with a possible dialogue setting. Recent attempts, however, for reformulating speech act analysis inside a general theory of action {Cohen 1986\] or for applying default reasoning to speech act understanding \[Perrault 1986\] may yet facilitate an extension to a whole dialogue. Another line of research has taken into account the dialogue dimension \[Litman 1984, Wilensky 1984, Carberry 1986\] and shown the strong interrelation between dialogue and plans but has  been mostly concerned with information-seeking dialogues in which the user seems to have an implicit knowledge of what the system can or cannot do. These dialogues often produce patterns of the type &amp;quot;question from the user requiring adequate answer from the system&amp;quot; and seldom consider a possible initiative on the system's behalf. Dialogue parsing is yet another approach which attempts to formalize the surface structure of a dialogue \[Reichman 1984, Wachtel 1986 I. It could however lead to some rigidity in the interaction between the user and the system; for instance, it may not provide the adequate primitive elements to detect and repair communicative failures in the dialogue. A possible way out would be to account for this surface structure of dialogue within a theory of pragrnatics \[Airenti 1986\].</Paragraph>
      <Paragraph position="4"> In person-machine advice-giving dialogue the challenge we face is how to make the expertise of the system accessible to the user in order to satisfy her/his needs: the &amp;quot;expertness&amp;quot; of the system and the &amp;quot;novicenees&amp;quot; of the user force a compromise between the system controlling the dialogue and the user expressing her/himself freely. We chose to rely on the system for conducting the dialogue without however ignoring the initiative of the user, which is to be examined within the intentional framework of the system. In the course of our research, we have derived a few general strategies which typify our approach.</Paragraph>
      <Paragraph position="5"> * Whenever possible, the system should set a clear background to the conversation. This is particularly true of the beginning of a session, where the system should not leave the user in the dark but should at once define its own competence and suggest possible options to the user.</Paragraph>
      <Paragraph position="6"> This initial setting will reflect the global- purpose of the dialogue and its expected unfolding.</Paragraph>
      <Paragraph position="7"> * Each step of a dialogue takes place in a certain context. We must ensure a common perception of this context by the user and the system if we want a meaningful exchange between them.</Paragraph>
      <Paragraph position="8"> s It is worth taking advantage of what the system can expect from the user when the latter &amp;quot;takes the floor&amp;quot; to guide the search of a correct interpretation and quickly decide the best-suited reaction. We should make these expectations of the system apparent in our model of dialogue. Nevertheless, we want the system to allow for user digressions, such as the introduction of a new topic or the correction of a previous statement. It is important to note that a sophisticated dialogue management which would allow the system to react adequately to this unexpected behavior of the user should not impair the straightforward and most probable reaction described just before. It should rather be called upon as a second best choice when the first one has failed, thus defining a preference hierarchy among possible reactions of the system. (In other words, first the clear-minded and obedient user, then the muddle-minded onel) * The form of the interaction between a user and an advice-giver evolves with the experience they have of each other and the increase of their mutual knowledge, either in the course of a same session or through several sessions.</Paragraph>
      <Paragraph position="9"> The dialogue system should gradually lead the user toward a simpler and more e/~lcient interface by suggesting the adequate jargon and steps which would allow the user to quicker and better formulate her/his problem \[Slator 19861 .</Paragraph>
      <Paragraph position="10"> Description of the Prototype</Paragraph>
    </Section>
  </Section>
  <Section position="3" start_page="186" end_page="187" type="metho">
    <SectionTitle>
* World
</SectionTitle>
    <Paragraph position="0"> The World of our dialogue module consists of a set of objects among which several relations and inheritance mechanisms are defined. For instance, there are classical is-a links, part-of links (a cash-need is part of the investment plan) and specification links (an amount is &amp;quot;specified&amp;quot; by a number and a currency).</Paragraph>
    <Paragraph position="1"> Parts of this semantic network are shared with other agents than the dialogue agent, or at least have the same representation in other agents. This is the case between the dialogue module and the problem solver for the problem formulation phase: a model of the expected problem is represented in the World.</Paragraph>
    <Paragraph position="2"> For our application', the expected problem consists of an investment plan expressed in terms of the basic investment situations for which the problem solver is able to select the adequate securities. It may include an emergencyfund, i.e., an amount of money which should be available at random time within a given delay, or a cash-need, i.e., an amount of money which should be available at a given date. These financial objects in the problem model are related to objects describing goals and situations of the user's everyday world through rsqu/rvrn~nat links. For instance, buying a car in five years may necessitate a cashneed, while covering unexpected expenses may ask for an emergency-fund. These reqm'mment links will guide the recognition of the user plan when resolving references.</Paragraph>
    <Paragraph position="3"> Other domain knowledge for the problem formulation dialogue is encoded in terms of the problem model objects and includes preferred sequences for the interaction with the user and constraints on these objects.</Paragraph>
    <Paragraph position="4"> For the dialogue module, the user is considered as another agent and her/his intentions and mental states are represented in terms of positions toward objects of the dialogue. Examples of such positions are 'user understands X', 'system wants to know the value of X', or 'user wants X to take a certain value'. We can view the objects and positions as representing respectively static and dynamic information in the system and allowing the exchange of information between agents.</Paragraph>
    <Paragraph position="5"> * Focus-Stack and Agenda We can characterize each step of the dialogue by a given attentional focus and a given task for the system. In our dialogue module these correspond respectively to a partitular object -- or set of objects -- under discussion and to an action of the system.</Paragraph>
    <Paragraph position="6"> During the dialogue, the focus of attention obviously evolves along a chronological dimension: one subject at a time. But a deeper analysis (el., for example, \[Grosz 1985\]) reveals a layered structure . In the current prototype, these layers of foci come into play in refinement and digression. Refinement occurs when the treatment of a complex object is split into sub-dialogues about its parts: during such a sub-dialogue, the &amp;quot;parent&amp;quot; and &amp;quot;sibling&amp;quot; objects constitute background context layers. A typical digression takes place when the system suspends information-gathering to give an explanation and comes back to the suspended step of the dialogue. The system keeps track of the active layers of foci in the Focus-Stack. The sequence of actions the system has currently planned to perform are stored in the Agenda.</Paragraph>
  </Section>
  <Section position="4" start_page="187" end_page="187" type="metho">
    <SectionTitle>
* Architecture
</SectionTitle>
    <Paragraph position="0"> The dialogue module contains four sub-modules: the INTERPRETER and the GENERATOR are in charge of relating logical form expressions of the natural language front-end to meanings about the World, the EXECUTOR carries out communicative-games for interacting with the user, and the REACTOR activates metaplans for updating the Agenda and the Focus-Stack.</Paragraph>
    <Paragraph position="1"> The next sections of this paper investigates in greater detail how the metaplans and communicative-games model the possible actions and strategies of the system and enter into the dialogue planning process. An account on other aspects of this prototype may be found in a previous technical report \[Decitre 1986\].</Paragraph>
    <Paragraph position="2"> High-Level Planning in the REACTOR From the dialogue module's point of view, the entire conversation results from the goal, &amp;quot;Obtain an investment plan problem specification from the user&amp;quot;. The goal is expanded according to the problem model into appropriate subgoMs, which are pushed onto the Agenda for sequential execution. As each subgoal is considered, it may be further expanded as necessary. In other words, the decomposition of the communicative intentions (obtaining specifications) reflects the decomposition of the task intentions (investing). There exist two types of metaplans: the metaplans for expanding the Agenda and the meta, plans for revising it according to some initiative from the user.</Paragraph>
  </Section>
  <Section position="5" start_page="187" end_page="187" type="metho">
    <SectionTitle>
* Expansion
</SectionTitle>
    <Paragraph position="0"> As an illustration of the first type of metaplans, let us consider what happens at the beginning of an advice-giving session. When the dialogue starts, the Agenda consists solely of a single action t~atCinsest-plaa ). A treat action basically corresponds to a sequence of three steps: presentation of the object to the user, asking for values which specify this object, and finally asking for confirmation.</Paragraph>
    <Paragraph position="1"> But the expansion of treat actions can vary according to the type of their argument. For instance, an object may be either simple or complex, it may also be visible or transparent. A transparent object is part of the structure of the problem model but remains invisible to the user. This is the case for p~b~insest-p/an) which consists of the set of the parts of an investment plan, /.e., {emews~U-yum/, cadL-need*,/o~-term}. These transparent objects attempt to model the differences which may exist between how the problem model is organised and how it may be perceived by the user. For a complex object, the expansion introduces treatment~ for the parts of the complex object, whereas simple objects have only specifications.</Paragraph>
    <Paragraph position="2"> Let us just show how these expansion metaplans account for the first two of our general strategies.</Paragraph>
    <Paragraph position="3"> The expansion of the initial goal tvest(inee#t-plan~ posts a prcsent(ineest-plan) onto the Agenda. The presentation of a complex object such as in,eat-p/an reflects how it will be expanded, since the same source of information, i.e., the problem model, is used for presentation and expansion, and thus provides a background setting for the dialogue. The order -- in this case obligatory -- in which the sub-objects of in~eJt-plan are considered is: first, the tota/-amount for the plan; second, the pa~tion(in~est-plan).</Paragraph>
    <Paragraph position="4"> The latter is a transparent object for which adequate presentation rules are defined: the presentation of a partition simply entails a presentation of all parts. The natural language front-end actually generates the following description: null system-&amp;quot;investment-plan: An investment plan is characterized by a total amount and is usually composed of an emergency-fund, one or several cash-needs and a long-term investment.&amp;quot; Update of the Focus-Stack is also governed by the expansion, and a layer containing all the objects introduced in this presentation is pushed onto the stack. The present example gives \[toto3-amount, emergen~p-fun~l, co.h-need, Ion4- term\]. We see again the effect of transparency: the parts themselves are directly pushed onto the stack and not the partition. This layer will constitute the backup layer of the Focus-Stack associated to the overall dialogue setting.</Paragraph>
    <Paragraph position="5"> At this stage, the next action on the Agenda is t~at(totoi-~mount) which may be further expanded in pu~hfocua, o,~k-i~Jo-game, ckeek-com~ete, pop-focus. The ask-infogame is a communicative game which asks a question about the total-amount object: system -'What is the total amount of your plan of investment?&amp;quot; and waits for the response of the user. The communicative game is designed to induce the user to specialize her/his focus of attention toward the refined context total~mount, and pud~-Jocu~(total-~nount) places this object on the Focus-Stack, updating it correspondingly.</Paragraph>
  </Section>
class="xml-element"></Paper>