<?xml version="1.0" standalone="yes"?>
<Paper uid="C90-3062">
  <Title>Repair Work in Human-Computer Dialogue</Title>
  <Section position="3" start_page="0" end_page="327" type="metho">
    <SectionTitle>
2. Repair in Human Interaction
</SectionTitle>
    <Paragraph position="0"> In human conversation there are continual implicit acknowledgements that communication is proceeding smoothly. The speaker is monitoring the hearer in different ways to see if they understand (for example, using checking moves such as 'Do you know what I mean?'), and the 'hearer' is often giving verbal acknowledgement to the speaker (e.g., 'yes', 'uhuh'). If the hearer takes over the conversation, she may acknowledge the last utterance implicitly by, for example, continuing the topic \[2\]. However, if the utterance is not understood, ~ repair may be initiated. We can examine this repair from several perspectives: Sequencing: A typicalrepair sequence may consist of a repair initiator by the hearer, a repair by the original speaker, and an acknowledgement by the hearer. However, repair sequences in general may be much more complex. For example, the speaker may do a third turn  repair on realising, from the hearer's response that her original utterance was not understood. These different types of repair have been discussed in \[7\].</Paragraph>
    <Paragraph position="1"> ttepalr Initiators: Repair initiators may take many forms in human interaction, including: facial expression; verbal signals ('huh?') and clarification questions. In human dialogue, the speaker may frequently selfcorrect without hearer intervention.</Paragraph>
    <Paragraph position="2"> Source of Trouble: Communication may break down for many reasons, such as from lack of hearing, reference failure or from general misunderstanding of complex material. Although the form of the repair initiator may indicate the source of the trouble, this is not always the case. It may therefore be necessary to guess at the likely source of trouble, possibly using discourse context or assumptions about the hearer's knowledge to reason about likely problems \[3\]. Repair work both relies on, and shapes the context of the interaction. However, whatever the source of the problem, the basic interactional mechanism is the same \[6\].</Paragraph>
  </Section>
  <Section position="4" start_page="327" end_page="328" type="metho">
    <SectionTitle>
3. Example Repair Work
</SectionTitle>
    <Paragraph position="0"> In order to illustrate some of these different aspects of repair, this section will give a number of examples of types of repair work in an interactive explanation system (the EDGE system, described further in \[1\]). These include repairs when the user fails to understand the explanation, as well as repairs when the system fails to understand the user. These latter are adapted from \[4\].</Paragraph>
    <Paragraph position="1"> The EDGE system plans explanations of the behaviour of simple circuits, depending on assumptions about the user's knowledge. These are interactive, with many opportunities for repair work when the user fails to understand the explanation. The user input to the system consists of one or two word commands or questions, rather than arbitrary natural language utterances. However, even with this restricted input there in an obvious need for repair work which addresses the systems lack of 'understanding' as well as the users.</Paragraph>
    <Section position="1" start_page="327" end_page="328" type="sub_section">
      <SectionTitle>
3.1 User Misunderstandings
</SectionTitle>
      <Paragraph position="0"> First, we will illustrate how the system may repair user misunderstandings. We must consider both how to structure the dialogue, and how to plan the content of a specific repair sequence.</Paragraph>
      <Paragraph position="1"> Clarification Questions: Whenever the system pauses the user may ask a clarification question (using a restricted command language). The system will normally reply to this question, then try and get back to what it was in the middle of explaining. This is achieved using discourse 'plans' to structure the clarification sub-dialogue, and a simple notion of focus to attempt to resume the previous discussion in such a way that it follows on from the topic introduced by the user. The following example illustrates this: S: The light detector circuit's components are: A light-dependent-resistor and a fixed-resistor.</Paragraph>
      <Paragraph position="2"> U: What-is-a light-dependent-resistor? S: A light-dependent-resistor is a kind of resistor. Its function is to provide an output resistance which depends on the input light intensity.</Paragraph>
      <Paragraph position="3"> S: Anyway, when its input light intensity is high, its output resistance is quite low ....</Paragraph>
      <Paragraph position="4"> In this example the system was planning to describe the detailed behaviour of the light detector circuit's components. Because of the interruption/clarification, the system chooses to first describe the behaviour of the light dependent resistor.</Paragraph>
      <Paragraph position="5"> Signalling Misunderstanding: The user may also signal that they are not following without mentioning the exact problem -- maybe they don't know why they  don't understand. The system must then 'guess' at the likely source of trouble. This is done by maintaining a model of the discourse so far which includes any assumptions made about the user's knowledge. In attempting a repair the system identifies an assumption which may have been mistaken, then tries to fill in missing knowledge or explain something another way. For example: U: Huh? S: Don't you know what sort of circuit a light-detector-circuit is? U: No.</Paragraph>
      <Paragraph position="6"> S: OK, A light-detector-circuit is a kind of  potential-divider circuit. Anyway..</Paragraph>
      <Paragraph position="7"> System initiated remediation: Sometimes the system can deduce that the user has a misunderstanding from the user's utterances (e.g., replies to questions). Then a remediation sequence is initiated by the system using strategies based on work on tutorial dialogues (e.g., \[8\]). For example: S: What's the output voltage of the light-detectorcircuit? null U: High.</Paragraph>
      <Paragraph position="8">  S: No, a light-detector-circuit is like a heatdetector.circuit except its output voltage depends on the input \]ight-intentity instead of hearintensity. So, what's the output voltage of the light-detector-circuit? 'Fhese examples illustrate different ways repairs may be iniated, how repair sequences may be structured w:ithin an ongoing dialogue, and how the system may tress at problems or use standm'd remediation strategies. null</Paragraph>
    </Section>
    <Section position="2" start_page="328" end_page="328" type="sub_section">
      <SectionTitle>
3.2 System ~Misunderstandlng ~
</SectionTitle>
      <Paragraph position="0"> Within the dialogue there are also places where the user may ask a question, but the system may not be able to in~;erpret it. (\['he system must then choose an app,'opri.at~ repair initiator. In these examples the user's input is in the form of a simple command hmguage --- for naturnl language input it is even more important to give helpful repair initiators.</Paragraph>
      <Paragraph position="1"> Object mimmderstood: If the object of the question is misunderstood, the repair initiator stmuld direct attention to that ~missing' object: U: What-is-a light-circuit ? S: What.d,~-~ what? U: light-detector-circuit.</Paragraph>
      <Paragraph position="2"> S: OK, A light-detector-circuit is a kind of ..</Paragraph>
      <Paragraph position="3"> Ql:mstion type misunderstood: If the question type is misunderstood, attention should be directed to that: U: Whatisa light-detector-circuit ? S: What about the light-detector-circuit? U: What-is-a light-detector-circuit.</Paragraph>
      <Paragraph position="4"> Both misunderstood: If the question is of the right form but both parts are not understood, the system simply says 'what?'.</Paragraph>
      <Paragraph position="5"> Wrong form: If the utter~nce is not of a recognisable form (e.g., it cannot be. 'parsed')j the system informs the user of acceptable forms (e.g., question-type questionobj). null Repeated errors: Repair initiators for repeated errors give: further information, such ~ lists of relevant object and question types.</Paragraph>
      <Paragraph position="6"> These simple examples illustrate tile importance of nshtg an appropriate repair initiator when the system fails to understand. This is important for both command and natural language based input.</Paragraph>
    </Section>
  </Section>
class="xml-element"></Paper>