Identifying Relevant Prior Explanations

IDENTIFYING RELEVANT PRIOR EXPLANATIONS James A. Rosenblum Department of Computer Science University of Pittsburgh Pittsburgh, PA 15260, USA Internet: jr@cs.pitt.edu Abstract When human tutors engage in dialogue, they freely exploit all aspects of the mutually known context, including the previous discourse. Utterances that do not draw on previous discourse seem awkward, unnatural, or even incoherent. Previous discourse must be taken into account in order to relate new information effectively to recently conveyed mate- rial, and to avoid repeating old material that would distract the student from what is new. Producing a system that displays such behavior involves finding an efficient way to identify which previous explanations (if any) are relevant to the current explanation task. Thus, we axe implement- ing a system that uses a case-based reasoning ap- proach to identify previous situations and expla- nations that could potentially affect the explana- tion being constructed. We have identified heuris- tics for constructing explanations that exploit this information in ways similar to what we have ob- served in human-human tutorial dialogues. Introduction and Motivation We are building an explanation component for an existing intelligent training system, SHERLOCK (Lesgold ei al., 1992), which trains avionics tech- nicians to troubleshoot electronic equipment. Us- ing SHERLOCK, trainees solve problems with min- imal tutor interaction and then review their trou- bleshooting in a post-problem reflective follolz-up (RFU) session where the tutor replays each stu- dent action and assesses it as "good" (<+>) or as "could be improved" (<->). After a step is re- played, the student can ask the tutor to justify its assessment. As an example of the way in which human tutors exploit previous discourse, consider the dialogue in Figure 1, taken from our data. Even though the student has made the same mistake twice, the second explanation looks quite different from the first. Yet the two explanations are related to one another in an important way. In the second expla- nation the tutor simply reminds the student that she has not determined the status of the main con- trol data signals and that she should do so before testing the secondary control data signals. The tutor expects the student to be able to make use of the previous explanation once he has indicated that it is relevant to the current situation ("for the same reasons given ..." serves this purpose). Ac- cordingly, the tutor does not repeat the detailed explanation of why the main control data signals should be tested first. By generating the second explanation in such a way that it 'meshes' with the first, not only has the tutor corrected the testing mistake of the student, but has forced the student to consider how the two situations are similar. In pointing out this similarity, he has given the stu- dent a better understanding of the domain. We call an explanation that is later referred to (explic- itly or implicitly) or is integrated into a subsequent explanation the anchor. Clearly it is desirable for a system to produce text that is …

Content truncated to 500 words