Eliciting Knowledge and Transferring it Effectively to a Knowledge-Based System

Brian R. Gaines and Mildred L. G. Shaw
Knowledge Science Institute
University of Calgary
Alberta, Canada T2N 1N4
gaines@cpsc.ucalgary.ca, mildred@cpsc.ucalgary.ca

Index Terms: Knowledge acquisition, expert systems, expertise transfer, empirical induction

Abstract

The knowledge acquisition bottleneck impeding the development of expert systems is being alleviated by the development of computer-based knowledge acquisition tools. These work directly with experts to elicit knowledge, and structure it appropriately to operate as a decision support tool within an expert system. However, the elicitation of expert knowledge and its effective transfer to a useful knowledge-based system is complex and involves a diversity of activities. This paper illustrates the complete development of a decision support system using knowledge acquisition tools. The example is simple enough to be completely analyzed but exhibits enough real-world characteristics to give significant insights into the processes and problems of knowledge engineering.

1 Introduction

Knowledge acquisition for expert system development has come to be termed knowledge engineering, following Feigenbaum's (1980) use of the term to describe the reduction of a large body of knowledge to a precise set of facts and rules. The term knowledge engineer has come to be used for the person responsible for such system development, and concise job descriptions for knowledge engineers have been given:

"Knowledge acquisition is a bottleneck in the construction of expert systems. The knowledge engineer's job is to act as a go-between to help an expert build a system. Since the knowledge engineer has far less knowledge of the domain than the expert, however, communication problems impede the process of transferring expertise into a program. The vocabulary initially used by the expert to talk about the domain with a novice is often inadequate for problem-solving; thus the knowledge engineer and expert must work together to extend and refine it. One of the most difficult aspects of the knowledge engineer's task is helping the expert to structure the domain knowledge, to identify and formalize the domain concepts." (Hayes-Roth, Waterman & Lenat, 1983)

Thus, the basic model for knowledge engineering has been that the knowledge engineer mediates between the expert and knowledge base, eliciting knowledge from the expert, encoding it for the knowledge base, and refining it in collaboration with the expert to achieve acceptable performance. Figure 1 shows this basic model with manual acquisition of knowledge from an expert followed by interactive application of the knowledge with multiple clients through an expert system shell:

However, the knowledge engineer in the role of an intermediary between the expert and the knowledge-based systems may create as many problems as he or she solves (Gaines, 1987a). The computer itself is an excellent tool for helping the expert to structure the knowledge domain, and, in recent years research on knowledge acquisition has focused on the development of computer-based acquisition tools (Boose & Gaines, 1988; Gaines & Boose, 1988; Boose, 1989). Many such tools are designed to be used directly by the expert with the minimum of intervention by the knowledge engineer, and emphasize facilities for visualizing the domain concepts. The objective of systems such as PLANET (Shaw & Gaines, 1983, 1986, 1987a), ETS (Boose, 1984, 1986), MOLE (Eshelman, Ehret, McDermott & Tan, 1987), SALT (Marcus, 1987), KITTEN (Shaw & Gaines, 1987b), KNACK (Klinker Bentolila, Genetet, Grimes & McDermott, 1987), KRITON (Diederich, Ruhmann & May, 1987), OPAL (Musen, Fagan, Combs & Shortliffe, 1987), AQUINAS (Boose & Bradshaw, 1987) and KSS0 (Gaines, 1987b; Gaines & Shaw, 1987) is to expedite the process of acquiring knowledge and transferring it to knowledge-based systems.

Figure 1 Basic knowledge engineering

Interactive knowledge acquisition and encoding tools can greatly reduce the need for the knowledge engineer to act as an intermediary but, in most applications, they leave a substantial role for the knowledge engineer. As shown in Figure 2, knowledge engineers have responsibility for:

Figure 2 Knowledge engineering with interactive tools

This use of interactive elicitation can be combined with manual elicitation and with the use of the interactive tools by knowledge engineers rather than, or in addition to, experts. Knowledge engineers can:

Figure 2 specifies multiple knowledge engineers since the tasks above may require the effort of more than one person, and some specialization may be appropriate. Multiple experts are also specified since it is rare for one person to have all the knowledge required, and, even if this were so, comparative elicitation from multiple experts is itself a valuable knowledge elicitation technique (Boose, 1987; Shaw & Woodward, 1987; Shaw & Gaines, 1988; Gaines & Shaw, 1989). Validation is shown in Figure 2 as a global test of the shell in operation with the knowledge base, that is of overall inferential performance. However, validation may also be seen as a local feature of each step of the knowledge engineers' activities: the experts' proper use of the tools needs validation; the operation of the tools themselves needs validation; the resultant knowledge base needs validation; and so on. Attention to quality control through validating each step of the knowledge acquisition process is key to effective system development.


Abstract, 1 Introduction, 2 A Knowledge Acquisition Tool, 3 A Sample Dataset, 4 Analyzing the Contact Lens Dataset, 5 Transferring the Contact Lens Dataset, 6 Consulting the Contact Lens Dataset, 7 Eliciting a Dataset for the Contact Lens Problem, 8 Conclusions, References, KSI Page

gaines@cpsc.ucalgary.ca 19-Sep-95