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).

From early experience building the DENDRAL system, it was obvious to us that putting domain-specific knowledge into a program was a bottleneck in building knowledge-based systems (Buchanan et al., 1970). In other systems of" the 1960s and early 1970s, items of knowledge were cast as LISP functions. For example, in the earliest version of DENDRAL the fact that the atomic weight of carbon is 12 was built into a function, called WEIGHT, which returned 12 when called with the argument C. The function "knew about" several common chemical elements, but when new elements or new isotopes were encountered, the function had to be changed. Because we wanted to keep our programs "lean" to run in 64K of working memory, we gave our programs only as much knowledge as we thought they would have to know. Thus we often encountered missing items in running new test cases. It was very quickly seen that LISP property lists (data structures) were a superior alternative to LISP code as a way of storing ...

A program that is designed to provide sophisticated expert advice must cope with the needs of naive users who may find the advice puzzling or difficult to accept. This chapter describes additions to MYCIN that provide for explanations of its therapy decisions, the lack of which was a shortcoming of the original therapy recommendation code described in Section 5.4 of Chapter 5. It deals with an optimization problem that seeks to provide "coverage" for organisms while minimizing the number of drugs prescribed. There are many factors to consider, such as prior therapies and drug sensitivities, and a person often finds it hard to juggle all of the constraints at once. When the optimal solution is provided by a computer program, its correctness may not be immediately obvious to the user. This motivates our desire to provide an explanation capability to justify the program's results. The explanation capability derives from two basic programming considerations.

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 ...

It is important to cover for the following probable infection(s) and associated organism(s): INFECTION-1 is BACTEREMIA ITEM-l E.COLI [ORGANISM-I] ITEM-2 KLEBSIELLA [ORGANISM-I] ITEM-3 ENTEROBACTER [ORGANISM-I] ITEM-4 KLEBSIELLA-PNEUMONIAE [ORGANISM-I]

There is little doubt that the decision to use rules to encode infectious disease knowledge in the nascent MYCIN system was largely influenced by our experience using similar techniques in DENDRAL. However, as mentioned in Chapter 1, we did experiment with a semantic network representation before turning to the production rule model. The impressive published examples of Carbonell's SCHOLAR system (Carbonell, 1970a; 1970b), with its ability to carry on a mixed-initiative dialogue regarding the geography of South America, seemed to us a useful model of the kind of rich interactive environment that would be needed for a system to advise physicians. Our disenchantment with a pure semantic network representation of the domain knowledge arose for several reasons as we began to work with Cohen and Axline, our collaborating experts. First, the knowledge of infectious disease therapy selection was ill-structured and, we found, difficult to represent using labeled arcs between nodes. Unlike South American geography, our domain did not have a clear-cut hierarchical organization, and we found it challenging to transfer a page or two from a medical textbook into a network of sufficient richness for our purposes. Of particular importance was our need for a strong inferential mechanism that would allow our system to reason about complex relationships among diverse concepts; there was no precedent for inferences on a semantic net that went beyond the direct, labeled relationships between nodes.1 Perhaps the greatest problem with a network representation, and the greatest appeal of production rules, was our gradually recognized need to deal with small chunks of domain knowledge in interacting with our expert collaborators.

Since production systems (PS's) were first proposed by Post (1943) general computational mechanism, the methodology has seen a great deal of development and has been applied to a diverse collection of problems. Despite the wide scope of goals and perspectives demonstrated by the various systems, there appear to be many recurrent themes. We present an analysis and overview of those themes, as well as a conceptual framework by which many of the seemingly disparate efforts can be viewed, both in relation to each other and to other methodologies. Accordingly, we use the term production system in a broad sense and show how most systems that have used the term can be fit into the framework. The comparison to other methodologies is intended to provide a view of PS characteristics in a broader context, with primary reference to procedurally based techniques, but also with reference to more recent developments in programming and the organization of data and knowledge bases.

Artificial Intelligence (AI) is that branch of computer science dealing with symbolic, nonalgorithmic methods of problem solving. Several aspects of this statement are important for understanding MYCIN and the issues discussed in this book. First, most uses of computers over the last 40 years have been in numerical or data-processing applications, but most of a person's knowledge of a subject like medicine is not mathematical or quantitative. It is symbolic knowledge, and it is used in a variety of ways in problem solving. Also, the problem-solving methods themselves are usually not mathematical or data-processing procedures but qualitative reasoning techniques that relate items through judgmental rules, or heuristics, as well as through theoretical laws and definitions.

Artificial intelligence, or AI, is largely an experimental science--at least as much progress has been made by building and analyzing programs as by examining theoretical questions. MYCIN is one of several well-known programs that embody some intelligence and provide data on the extent to which intelligent behavior can be programmed. As with other AI programs, its development was slow and not always in a forward direction. But we feel we learned some useful lessons in the course of nearly a decade of work on MYCIN and related programs. In this book we share the results of many experiments performed in that time, and we try to paint a coherent picture of the work.

Addison-Wesley Publishing Company Reading, Massachusetts Menlo Park, California London Amsterdam Don Mills, Ontario Sydney This book is in The Addison-Wesley Series in Artificial Intelligence. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of the publisher.