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.

When GENTAMICIN is given for MENINGITIS, the recommended dosage is: if age is 2 yrs then 1.7 mg/kg q8h IV plus consider giving 5 mg q24h IT, else 2.3 mg/kg q8h IV plus consider giving 2.5-4 rag/day IT. The normal dose for John Jones is: 119 mg (3.0 ml, 80mg/2ml ampule) q8h [calculated on the basis of 1.7 mg/kg] plus consider giving 5 mg q24h IT GENTAMICIN is excreted by the kidneys, so its dosage must be modified in renal failure. The following table shows how the patient's renal function was determined: Identifier Value Definition SCR1 1.9 the most recent serum creatinine (mg/100ml) SCR2 1.8 the previous serum creatinine (mg/100ml) CCr(f) 42.7 estimated creatinine clearance, adjusted for normal body surface area (ml/min/1.73

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.

In describing MYCIN's design considerations in Chapter 3, we pointed out that an ability of the program to explain its reasoning and defend its advice was an early major performance goal. It would be misleading, however, to suggest that explanation was a primary focus in the original conception. As was true for many elements of the system, the concept of system transparency evolved gradually during the early years. In reflecting on that period, we now find it impossible to recall exactly when the idea was first articulated. The SCHOLAR program (Carbonell, 1970a) was our working model of an interactive system, and we were trying to develop ways to use that model for both training and 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.

Whereas much early work in artificial intelligence was devoted to the search for a single, powerful, domain-independent problem-solving methodology [e.g., GPS (Newell and Simon, 1972)], subsequent efforts have stressed the use of large stores of domain-specific knowledge as a basis for high performance. The knowledge base for this sort of program [e.g., DENDRAL (Feigenbaum et al., 1971), MACSYMA (Moses, 1971)] is often assembled by hand, an ongoing task that may involve several person-years of effort. A key element in constructing a knowledge base is the transfer of expertise from a human expert to the program. Since the domain expert often knows nothing about programming, the interaction between the expert and the pertormance program usually requires the mediation of a human programmer. We have sought to create a program that could supply much the same sort of assistance as that provided by the programmer in this transfer of expertise. The result is a system called TEIRESIAS 1 ...