FIGURE 22-2 Summary of conclusions drawn by VM based on four hours of patient data. Current and optimal patient therapy stages are represented by their first letter: V -- VOLUME, A ASSIST, C controlled mandatory ventilation,/ changing. A double bar () is printed for each ten-minute interval in which the conclusion on the left is made.

We have found that the feature is therefbre seldom used. It would, of course, be preferable if the system "knew" on its own when such a summary is appropriate.

Representing knowledge in an AI program means choosing a set of conventions tor describing objects, relations, and processes in the world. One first chooses a conceptual framework for thinking about the world--symbolically or numerically, statically or dynamically, centered around objects or around processes, and so forth. Then one needs to choose conventions within a given computer language tor implementing the concepts. The former is difficult and important; the latter is both less difficult and less important because good programmers can find ways of working with almost any concept within almost any programming language. In one respect finding a representation for knowledge is like choosing a set of data structures for a program to work with.

A computer program that models an expert in a given domain is more likely to be accepted by experts in that domain, and by nonexperts seeking its advice, if the system can explain its actions. This chapter discusses the general characteristics of explanation capabilities for rule-based systems: what types of explanations they should be able to give, what types of knowledge they will need in order to give these explanations, and how this knowledge might be organized (Figure 18-1). The explanation facility in MYCIN is discussed to illustrate how the various problems can be approached. A consultative rule-based system need not be a psychological model, imitating a human's reasoning process. The important point is that the system and a human expert use the same (or similar) knowledge about the domain to arrive at the same (or similar) answers to a given problem. The system's knowledge base contains the domain-specific knowledge of' an expert as well as facts about a particular problem under consideration. When a rule is used, its actions make changes to the internal data base, which contains the system's decisions or deductions. The process of trying rules and taking actions can be compared to reasoning, and explanations require displays of how the rules use the information provided by the user to make various intermediate deductions and finally to arrive at the answer. If the information contained in these rules adequately shows why an action was taken (without getting into programming details), an explanation can simply entail printing each rule or its free-text translation. This chapter is a revised version of a paper originally appearing in American Journal of Computational Linguistics, Microfiche 62, 1977. The three components of a rule-based system (a rule interpreter, a set of production rules, and a data base) are augmented by an explanation capability. The data base is made up of general facts about the system's domain of expertise, facts that the user enters about a specific problem, and deductions made about the problem by the system's rules. These deductions form the basis of the system's consultative advice. The explanation capability makes use of the system's knowledge base to give the user explanations. This knowledge base is made up of static domain-specific knowledge (both factual and judgmental) and dynamic knowledge specific to a particular problem. Pertbrmance Characteristics of an Explanation Capability The purpose of an explanation capability (EC) is to give the user access as much of the system's knowledge as possible. Ideally, it should be easy for a user to get a complete, understandable answer to any sort of question about the system's knowledge and operation--both in general terms and 340 Methods for Generating Explanations with reference to a particular consultation.

The development of expert systems is plagued with a well-known and crucial bottleneck: in order for these systems to perform at all the domainspecific knowledge must be engineered into a form that can be embedded in the program. To this end the purpose and structure of two quite dissimilar rule-based systems are reviewed. Both systems were constructed using the EMYCIN system after interviewing an expert. The first, SACON (Bennett et al., 1978), meant to assist an engineer in selecting a method to perform a structural analysis; the second, CLOT (Bennett and Goldman, 1980), is meant assist a physician in determining the presence of a blood clotting disorder. The presentation of the details of these two systems is meant to accomplish two functions. The first is to provide an indication of the scope and content of these rule-based systems. The reader need not have any knowledge of the specific application domain; the chapter will present the major steps and types of inferences drawn by these consultants. This conceptual framework, what we term the inference structure, forms the basis for the expert's organization of the domain expertise and, hence, the basis for successful acquisition of the knowledge base and its continued maintenance. The second purpose of this chapter is to indicate the general form and function of these inference structures.

FIGURE 15-1 The major roles of EMYCIN: acquiring a knowledge base from the system designer, and interpreting that knowledge base to provide advice to a client.

One of the reasons for undertaking the original MYCIN experiment was to test the hypothesis that domain-specific knowledge could successfully be kept separate from the inference procedures. We felt we had done just that in the original implementation; specifically, we believed that knowledge of a new domain, when encoded in rules, could be substituted for MYCIN's knowledge of infectious diseases and that no changes to the inference procedures were required to produce MYCIN-like consultations. In the fall of 1974 Bill van Melle began to investigate our claim seriously. He wrote (van Melle, 1974): The MYCIN program for infectious disease diagnosis claims to be general. One ought to be able to take out the clinical knowledge and plug in knowledge about some other domain.

Questioning of the expert gradually reveals, however, that despite the apparent similarity to a statement regarding a conditional probability, the number 0.7 differs significantly from a probability. The expert may well agree that P(hl]sl & s2 & s:0 0.7, but he becomes uneasy when he attempts to follow the logical conclusion that therefore P( hllS 1 & s 2 & s) 0.3. He claims that the three observations are evidence (to degree 0.7) in favor of the conclusion that the organism is a Streptococcus and should not be construed as evidence (to degree 0.3) against Streptococcus. We shall refer to this problem as Paradox 1 and return to it later in the exposition, after the interpretation of the 0.7 in the rule above has been introduced. It is tempting to conclude that the expert is irrational if he is unwilling to follow the implications of his probabilistic statements to their logical conclusions.

The builders of a knowledge-based expert system must ensure that the system will give its users accurate advice or correct solutions to their problems. The process of verifying that a system is accurate and reliable has two distinct components: checking that the knowledge base is correct, and verifying that the program can interpret and apply this information correctly. The first of these components has been the focus of the research described in this chapter; the second is discussed in Part Ten (Chapters 30 and 31). Knowledge base debug, ng, the process of checking that a knowledge base is correct and complete, is one component of the larger problem of knowledge acquisition. This process involves testing and refining the system's knowledge in order to discover and correct a variety of errors that can arise during the process of transferring expertise from a human expert to a computer system. In this chapter, we discuss some common problems in knowledge acquisition and debugging and describe an automated assistant for checking the completeness and consistency of the knowledge base in the ONCOCIN system (discussed in Chapters 32 and 35).

In this chapter MYCIN's implementation is presented in considerable detail. Our goals are to explain the data and control structures used by the program and to describe some of the complex and often unexpected problems that arose during system implementation. In Chapter 1 the motivations behind many of MYCIN's capabilities were mentioned. The reader is encouraged to bear those design criteria in mind throughout this chapter. This chapter specifically describes the Consultation System. This subprogram uses both system knowledge from the corpus of rules and patient data entered by the physician to generate advice for the user. Furthermore, the program maintains a dynamic data base, which provides an ongoing record of the current consultation. As a result, this chapter must discuss both the nature of the various data structures and how they are used or maintained by the Consultation System. Section 5.1 describes the corpus of rules and the associated data structures. It provides a formal ...