My investigations fall on the experimental psychology side of expert system engineering, specifically the problem of generating methods for extracting the knowledge of experts. I do not review the relevant literature on the cognition of experts.l I want to share a few ideas about research methods that I found worthwhile as I worked with expert interpreters of aerial photographs and other remotely sensed data [Hoffman 1984) and on a project involving expert planners of airlift operations (Hoffman 1986). These ideas should be useful to knowledge engineers and others who might be interested in developing an expert system. In generating expert systems, one must begin by characterizing the knowledge of an expert.

This article discusses several effective techniques for expert system knowledge acquisition based on the techniques that were successfilly used to develop the Central Office Maintenance Printout Analysis and Suggestion System (COMPASS) Knowledge acquisition is not a science, and expert system developers and experts must tailor their methodologies to fit their situation and the people involved. This knowledge is then implemented to form an expert system. The essential part of an expert system is its knowledge, and therefore, knowledge acquisition is probably the most important task in the development of an expert system. In this article, several effective techniques for expert system knowledge acquisition are discussed based on the techniques that were successfully used at GTE Laboratories to develop the COMPASS expert system. Knowledge acquisition for expert system development is still a new field and not (yet?) a science.

Expert system projects arc often based on collaboration with a single domain expert. This article is based on work performed in collaboration with many other colleagues and it is a pleasure to acknowledge their influence on the ideas plescnted here The MDX pro,ject was a collahorat,ion between the first ant,hor, B Chandrasekaran, and J W Smith at Ohio State Solnc of the key people in the DARN project were Daniel Bohrow, Johann dcKlcer, and Mark Stefik at Xerox PARC and Milt Mallory and Ron Brown at Xerox OSD. The approach described here is an empirical one based on our experience with different expert, systems. Anecdotes from various prqjects illustrate the issues. Judging the Suitability of an Expert Systems Task Before cvcn bcginuing to build an expert, system, you must decide if the domain is suitable, given the current statcof-the-art of both the t,cchnology of knowledge eugineering and the art, of acquiring knowledge.

The First National Aeronautics and Space Administration (NASA) Workshop on Monitoring and Diagnosis was held in Pasadena, California, from 15 to 17 January 1992. The workshop brought together individuals from NASA centers, academia, and aerospace who have a common interest in AIbased approaches to monitoring and diagnosis technology. The workshop was intended to promote familiarity, discussion, and collaboration among the research, development, and user communities. The First National Aeronautics and Space Administration (NASA) Workshop on Monitoring and Diagnosis was held in Pasadena, California, from 15 to 17 January 1992. The workshop was hosted by the Jet Propulsion Laboratory (JPL) and took place at the Ritz-Carlton Huntington Hotel.

Department of Computer Science Carnegae-Mellon Unaverszty P&burg, PA 15213 Editors' Note: Many expert systems require some means of handling heuristic rules whose conclusions are less than certain Baysian techniques and other numerical scoring methods have been developed to combine and propagate certainty measures as the expert system draws inferences in solving different problems. Doyle's paper argues that it is difficult for a human expert to produce reliable probabilities or numerical scoring factors for an inference rule, and that a radically different approach to the problem should be considered He essentially suggests that the expert be encouraged to think in terms of specific instances which would conflict with the general rule and to encode this knowledge explicitly. Methodologically this seems to be very appealing, and helps to make both explicit and rigorous some of the techniques currently used by knowledge engineers whm they encode and refine the expert's knowledge We would welcome comments and criticisms of this approach from those steeped in the practical issues of constructing large rule-based expert systems. Probabilistic rules and their variants have recently supported several successful applications of expert systems, in spite of the difficulty of committing informants to particular conditional probabilities or "certainty factors," and in spite of the experimentally observed insensitivity of system performance to perturbations of the chosen values Here we survey recent developments concerning reasoned assumptions which offer hope for avoiding the practical elusiveness of probabilistic rules while retaining theoretical power, for basing systems on the information unhesitatingly gained from expert informants, and reconstructing the entailed degrees of belief later @

In the short history of expert systems, a variety of approaches have been used to tackle the difficult problem of knowledge acquisition, among which are the following common types: consulting a library of models; using automatic induction from cases; and using triadic differentiation, which is repeated contrasting of two of the expected output of an expert system with a third. To be topical, all this knowledge-acquisition research has been done in the name of constructing expert systems in an easier, faster, and more maintainable manner because there is a growing consensus that expert systems are stuck on a productivity plateau in light of first-generation tools still being used without an effective knowledge-acquisition and knowledge-structuring front end. Contrary to many prevailing approaches to knowledge acquisition, Laps, our expert-interviewing software, begins by soliciting cases from the expert, but it does not end there. Its uniqueness lies in the fact that it interweaves knowledge gathering, organizing, and testing. Laps begins with a case in the form of a sample solution path elicited from the domain expert.

Toward thi: end, knowledge acquisition is sometimes considered a nccessary burden, carried out under protest so that one can gel on with t,he study of cognitive processes in problem solving In this article we argue that, t,he two activities-knowledge acqisitSion and cognitive modeling-are necessarily interwoven, and provide interesting opportunities when t,akcr Logether. Knowledge acquisition shapes cognit,ive modeling because operatzonnl knowledge cont,ains assurnpt,ions nnc directions for its use, t,hat, is, a.11 implicit, processing model In return, problem solving models can profoundly shape knowledge acquisition by providing a framework for the articulation and creation of domain expertise This int,rodllces the theme of this article, t,hat, one can engzneer bodie: of knowledge for various purposes, such as learnability, To the knowledge engineering slogan "knowledge is power," we add "knowledge is an artifact,, worthy of design " The organization of this article is as follows: We first consider the pract,ice of "cognitive advantage " III the t,hird section we suggest some A Shift in Viewpoint from Experts to Clans Over the past decade t,hcrc have been trcmcndous advances in the fabrication of integrated circuits (Robinson, 1980a). Circuits have become smaller and manufacturing costs have dropped dramatically. Design is becoming the dominant cost (Robinson, 19801) with the current round of miniaturization, which goes by the name of VLSI for very large scale integration. This is leading to a substantial int,crest in undcrst,anding design processes.

Designing Expert Systems relate expert system research to that findings are abstracted into problem categories (they call them only "intermediate hypotheses") or that hypotheses are refined into subtypes (they say that hypotheses can be organized in a taxonomy, but give no examples). Most importantly, they miss the idea that expert systems often solve a sequence of problems by classification. Common examples are: making a diagnosis and then selecting a repair, characterizing a patient stereotypically and matching this to diseases, and modeling a user's needs and satisfying them (see (Clancey, 1984) for further discussion). Beyond this, Weiss and Kulikowski perpetuate the confusion that classification is a property of problems, rather than a problem solving method. Diagnosis is not inherently a "classification problem."

For several decades, there has been another face to the field, a technological one that provides tools for solving practical problems in various domains. Of these domains, engineering and medicine have had the closest interaction with AI. AI ideas in representation and reasoning have been especially relevant to diagnosis and corrective action planning in both domains, and in engineering, design has been another area of very fruitful collaboration. These disciplines have not been mere consumers of AI ideas and technology, however. They have had a deep effect on the theoretical side of AI. Complex real-world reasoning tasks, such as those in engineering and medicine, bring out the inadequacy of purely theoretical conceptions about the nature of intelligence. The enormous amounts and types of knowledge often required for carrying out practical reasoning, and the variety of inference techniques that are displayed by practitioners, and the need to arrive at conclusions rapidly--these ...

Among the difficulties in evaluating AItype medical diagnosis systems are: the intermediate conclusions of the AI system need to be looked at in addition to the "final" answer; the "superhuman human" fallacy must be resisted; both pro-and anti-computer biases during evaluation must be guarded against; and methods for estimating how the approach will scale upwards to larger domains are needed We propose a type of Turing test for the evaluation problem, designed to provide some protection against the problems listed above We propose to measure both the accuracy of diagnosis and the structure of reasoning, the latter with a view to gauging how well the system will scale up A staple of many of the evaluations of AI systems that have so far been conducted (Colby, Hilf, Weber, 81 Kraemer, 1972; Yu et al, 1979) is a central idea from a well-known proposal to evaluate AI systems: The Turing Test (Turing, 1963) The meat of the idea is to see if a neutral observer, given a set of performances on a task, some by a machine and others by humans, but unlabelled as to authorship, could identify, better than chance, which were machine and which were human-produced. Note that this really attempts to answer the question, "DO we know how to design a machine to perform a task which until now required human intelligence?", The latter question subsumes the former in a sense: because the machine not performing well in comparison to a human would presumably increase the cost significantly. In this paper I follow tradition and consider the evaluation of AI systems for medical diagnosis from the viewpoint of the first question above. The proposed procedure is also a variant of Turing's Test.