EXPERT SYSTEMS


References

Table of Contents


Introduction

The Human-Machine Contrast
Human intelligence consists of fact,concepts,rules and heuristic knowledge. Facts and concepts can be thought of as structures that house symbols. Rules and heuristic knowledge can be thought of as manipulators of the symbols. Mental models are formed using facts,concepts, rules, and heuristic knowledge in ever-changing arrays.
Human thinking can be viewed in term of categories of thinking. These categories are cognitive, associative, and philosophical.

Human cognitive thinking involves the gathering of input data and the manipulation of symbols. the manipulation of symbols take place through mental models. Machine thinking does an admirable emulation of the cognitive process. Both the human and machine are able to process input to reach decisions for action of project future events from that input.

Associative thinking consists of the concepts of vertical and lateral thinking. According to deBono (1973) there are two basic thinking styles, vertical and lateral. Vertical or logical, thinking involves movement from state to state through a series of justified steps. Lateral thinking uses information not for its own sake, but for its side effects. Vertical thinking is selective and lateral thinking is generative. Human are able to think laterally and machine cannot. Lateral thinking is associative with creativity and the ability of the mind to be self-organizing and self-maximizing.

Maximally efficient problem-solving uses both vertical and lateral thinking to address and resolve problem situations. While machine systems are adequate for certain tasks, there is still room for improvement in their capability for this kind of reasoning.

Philosophical thinking involves rhetorical query. It can encompass a patter-matching attempt such as, "Is there a correspondence between the breadth of a tree's branches and the breadth of its root system?, If so, is this correspondence consistent across species? What could I do with this information?". Philosophical thinking can also involve pondering one's existence. It is the realm of original thought and involves self-consciousness. At this time, philosophical thought is the sole domain of humans.

Human Reasoning

Artificial intelligence
Artificial intelligence is the branch of computer science that focuses on the development of computer systems to simulate the processes of problem solving and duplicate the functions of human brain. According to Elaine Rich (1983), "Artificial intelligence is the study of how to make computers do things at which, at moment, people are better". This simple, but eloquent, statement captures the essence of the pursuit.

Artificial intelligence comprises hardware and software systems and thechniques that attempt to emulate human mental and physical processes. The mental processes emulated include thinking, reasoning, decision making, data storage and retrieval, problem-solving, and learning. The physical processes include human senses and motor skills. Artificial is also called machine intelligence. Artificial intelligence is a serous pursuit, but most of its components are currently limited to the status of research and theory-based laboratory goals.


More detail

Expert Systems
An expert system is a narrow slice of computer intelligence and knowledge-based application. Its program are designed to emulate human decision-making expertise in a particular domain. Expert systems belong to a group of systems known as knowledge-based systems. Knowledge-based systems contain the facts and procedures representing the rule of thumb (heuristic) decision-making processes of an expert. That collection is kept in a knowledge base that is separate from a control program.

Natural Language Processing
Natural language processing is the most commonly explored branch of AI. A natural language is a spoken or written human language. Natural language are designed to accept language input, interpret and process the input, and output natural language result.
Natural language processing is divided into two sub-branches: understanding and output. Natural language understanding explores methods of computer comprehension of human language stimuli. Natural language output is the ability of computer to communicate verbally with a human.

Speech Recognition
Whereas natural language processing receives commands in text format, speech recognition allows a computer to respond to voice input. The goal of speech recognition research is to simplify the process of interactive communication between human and computers.
Speech recognition is accomplished by use of an electronic process which converts analog voice input into signals that can be understood by the NLP system. A process involving search and pattern recognition, and pattern matching is used. The speech recognition ability accomplished through hardware, although the use of software processes is gaining. By using a software approach, speech recognition and NLP can be combined.

Robotics
In contrast to AI efforts to emulate human mental abilities, robotics is concerned with engineering attempts to duplicate human physical attributes. Robot are electromechanical machines that are programmable and perform manipulative tasks. These task range from delicate to heavy-duty. A typical robot is a manipulator arm used in manufacturing to weld, paint, insert screws, lift, and move parts.

Artificial neural networks


What is Expert Systems (ES)?

Currently, the most common form of expert system

Structure of a Rule-based Expert System

Classification of Expert Systems
In an attempt to classify expert system for discussion purpose, schemas have been devised that are based on the number of rules. These classification systems suggest that there are three basic classes of expert system : small, medium, and large. A small systems has been defined as one that uses a knowledge base comprising fewer than 500 rules. A medium system consists of up to 10,000 rules, and large system has in excess of 10,000 rules.

Classification based on number of rules

Classification Number of Rules
Small < 500 rules
Medium 10,000 rules
Large > 10,000 rules

Human professionals are classified in term of their level of performance, ranging from novice to expert. The proposed schema is based on function and performance rather than rule quantity. Each level of system provide the functionality of its preceding level or levels.

Level 0
The base-level system is self-contained. This system makes no call outside its knowledge base, but can display explanations. A Level 0 system has restricted reasoning methods such as backward chaining, forward chaining, inductive reasoning, a rule-based method, or example-based reasoning.

Level 1
Level 1 systems can make use of external program calls. These systems are used for a wide variety of popular applications such as intelligent databases, diagnostic systems, and other application that can effect a two-way flow of communication. These system have a free exchange of data between the user an peripherals.
In addition, level 1 systems have the following options: forward and backward chaining selection, math ability, control over peripherals, data interface option, an explanation sub-system that describes the line of reasoning upon request, inference cut-off, window definition, import of text, leaner control, line positioning option, and user interface control.

Level 2
Level 2 systems can serve as closed-loop or modified closed-loop systems. They are typically used to perform such as diagnosis and prescription and then to effect the prescription through communication links. For example, a system could be located in a manufacturing facility. This system would be designed to monitor a control process and detect out-of-range limits through sensors. Once an out-of-range situation is detected, the system send messages that modify operations by shutting valves, altering a flow, etc.

Level 3
Level 3 systems offer higher-level functioning across a variety of application. In addition, these system operate in a variety of operating systems and environments such as OS/2 or UNIX, and they can execute on mainframe or Pcs. The developer has control over the type of output code generated such as LISP, Prolog, C, or Pascal. Level 3 system developers also have control over search selection: Hierarchical search, depth-first, breadth-first, etc. Level 3 systems are found in applications that typically involve over six person-years to develop.

Level 4
A level 4 system is a system that can automatically add to and thereafter alter its knowledge base. This is a system that can learn. Level 4 system are found in research labs and are not available for commercial use at this time.

Classification based on performance

Feature Level 0 Level 1 Level 2 Level 3 Level 4
Explanation facility

External program call  

Inference selection  

Serve as closed-loop    

Variety of OS      

Can learn        


Knowledge Representation

Knowledge representation is a method used to encode the knowledge for use by the expert system, and putting the knowledge into rules or cases or other representations.

COMPONENTS OF KNOWLEDGE IN EXPERT SYSTEMS

The knowledge that is contained within an expert system consists of :

Our concern will be with the manner in which these types of knowledge. and in particular knowledge of the first type, may be represented within the digital computer. In particular, our attention will be focused on the use of rule bases for the representation of expert knowledge.

(1) Actually. rules are generated during a consultation session only if our expert system is capable of learning. In general. inferred knowledge consists simply of new facts, or conclusions.

In the brief introduction to expert systems, it was noted that knowledge is contained within both the expert system's knowledge base and its working memory. The knowledge within the knowledge base is that of the first type, that is, a priori facts and rules about the specific domain. The knowledge within the working memory is dynamic as it changes for each problem addressed and is of the second type. that is, inferred knowledge about the particular problem under consideration. To clarify these concepts, consider the following example in which we are concerned with the knowledge base of a loan officer at a bank.

THE KNOWLEDGE BASE OF AN EXPERT LOAN OFFICER.

Let us introduce Dan Smith. Dan has been one of the senior loan officers for a bank in Houston for nearly 20 years, and he is generally considered to be the most capable of the loan officers at the bank. Thus, in the specific domain of bank loans, Dan is an expert.

As a loan officer, it is Dan's job to decide the disposition of loan applications received by the bank. Specifically, he must evaluate each application to determine whether or not a loan should be granted and, if granted, the rate and duration (and any other pertinent terms) of the loan.

There are two basic types of mistakes that a loan officer can (and will, regardless of his or her expertise) make. First, a loan may be denied to a person who might actually have made all the payments. Denial of such a loan represents, on the part of the bank. a lost opportunity. Second, a loan may be granted to someone who later defaults on the payments. In this instance, the granting of this type of loan results in reduced revenue. The loan officer must thus establish some sort of policy to balance off these two events in order to attempt to maximize the bank's profits, minimize its risks, and still maintain good customer relations.

The policy ultimately arrived at will be one that combines two sources of knowledge. That is, the loan officer will use what he or she has been taught through formal course work and training. The knowledge obtained through formal study, or available in the public domain (e.g., in books, manuals) is termed deep knowledge and forms just one part of the expert's knowledge base. However, in addition to this deep knowledge, an expert develops, through experience, his or her own set of heuristic rules. These heuristic rules are termed shallow knowledge: and they are the rules that we particularly wish to include in the knowledge base. Through the use of the expert's heuristic rule set. and in conjunction with the facts that are accessible, he or she is able to obtain better results, and in less time, than that of a novice.

Returning to the specific case of Dan Smith. Let us consider the portion of the knowledge base which is stored within his memory. Irrespective of the applicant under consideration. Dan has somehow accumulated a set of heuristic rules and facts concerning the granting of loans. For example, some of the facts that may be stored might include the following:

Also stored in Dan's memory are the heuristic rules he uses in the disposition of any loan application. For example. one such rule may be "whenever the bank expresses particular concern about bad loans. place additional emphasis on the applicant's long-term employment prospects.'' This might be represented by the following statement, or rule:

If the bank is particularly worried about bad loans

Then emphasize the applicant's employment prospects

Remember that the above facts and rules are those appropriate for any case. Let us now turn to the actual decision making process for a specific loan applicant. Our applicant, Pete Jones. first fills out an application form on which he is asked to list the values for such attributes as his age, annual income, employer, length of time with employer. education, address, marital status, number of dependents, previous credit history, home ownership status (i e., does the applicant own or rent his or her residence and what are the monthly payments), number of automobiles (and monthly payments). and so on.

The information on this form represents facts about a particular individual (i.e., Pete Jones in our example). While Dan Smith will certainly consider these facts during his decision making process. they most likely will be forgotten once the decision has been reached. And there is, in .act, no point in remembering all the details of every loan application. Thus, we can consider the facts derived from Pete Jones' application form to be in Dan's working memory, where this working memory is physically represented by the application form itself. Some of the facts that may become available through Pete Jones' application are that he works for the XYZ Corporation and makes S50.000 per year, or

Now, based on the data (i.e.. facts) on the application form, there are typically certain formal policies that the bank follows with regard to the evaluation process. They may, for example, have a policy that a loan should not be granted if the monthly payments associated with that loan exceed some percentage of the applicant's take-home income. Such rules are those associated with deep knowledge in that they are in the public domain (i.e., available to all key bank personnel) Consequently, if Dan examines the form and finds that Pete is in clear violation of several such rules, he may immediately conclude that no loan should be made Such clear-cut cases are not. however. situations in which expertise is most valuable. Rather. it is quite often in the marginal cases where an expert can make significant difference.

For the purpose of discussion, let us assume that the facts available through Pete's application form are such that, while marginal, they do not serve to rule out the granting of a loan However. since the application is marginal, this is a signal to Dan to give it even more attention than usual.

For example, Dan might first look at Pete's address. which happens to be in a section of town that is in somewhat of a state of decline. Dan recalls that it is taking longer and longer to sell houses in that area, and that house prices there have declined relative to the rest of the housing market. Further. Pete has been with his present employment for only two years, and that particular employer {i e., the XYZ corporation). is not noted for employment stability. Coupled with this is the fact that Pete's present mortgage payments are relatively high and the amount paid for his house now seems somewhat on the high side. Dan concludes that there is good reason to expect that the applicant might soon be placed in a position that would result in a default on the loan. And he has made this decision based on the rules and facts in his knowledge base coupled with the facts in working memory (i.e., the application form). At this point, a loan investigator might well conclude that the loan should be denied. However, Dan has learned that a personal interview is often of prime importance to his decision (and this is yet another heuristic rule in his memory. or knowledge base). Thus. he decides that even though the situation appears bleak, it may be worthwhile to talk directly with Pete.

During the interview, Dan asks a number of carefully calculated questions: questions that are intended to draw out additional information from the applicant. However, Dan has also learned, through his experience, to first relax the applicant by making small talk. In doing so in the past, he has found that quite often some unexpected, but pertinent information may result. In fact, when chatting with Pete, Dan discovers that he is married to the daughter of the vice president of the XYZ Corporation. This vice president, in turn, is a major shareholder and very securely positioned in the company. Dan concludes that Pete's loan should be granted. He also adds a new heuristic to his knowledge base; that is, if the applicant is married to the child of one of the executives of the firm at which the applicant is employed. then the loan application is to be given additional weight.

CONSIDERATION IN KNOWLEDGE REPRESENTATION

In the above example, a large part of Dan's knowledge base (i.e.. including some portion of the deep knowledge available in the public domain) is retained within his memory. Somehow. some way. the facts and heuristic rules that he employs have been transformed into a format that can be both stored and retrieved from his brain. Investigators in artificial intelligence and psychology (among others) are keenly interested in just how this is achieved. and several theories have been proposed.

Our concern, however, shall be more immediate and far more pragmatic. We wish to store the knowledge base of an expert system in the memory of a digital computer, using means presently at hand. We are not, in fact, really concerned about whether or not the method of storage we employ has some analogy to the manner in which knowledge is stored in the human brain. We simply seek a fast, effective procedure for use with the computer. This is not at all meant to imply that we should consider the study of the brain and human memory to be unimportant. It most definitely is; but until that study provides results that may be used to refine or replace existing methods. we shall simply remain interested observers.

Thus, our major concerns deal with how to represent the facts and rules within the knowledge base to :

Elaborating further on the last two points, it would be highly desirable to use a format that is transparent, that is, a representation scheme that may be easily read and understood by humans.

Several modes of knowledge representation have been proposed. As we have emphasized, the primary focus will be on rule-based systems for knowledge representation. since it is through this process that the knowledge bases of the expert systems to be described in this text will be developed. However, before we cover rule-based systems in detail, let us first discuss certain alternative modes of knowledge representation.

ALTERNATIVE MODES OF REPRESENTATION

In this section, briefly described will be the pertinent features of such modes of knowledge representation as OAV (or object attribute value) triplets, semantic networks, frames, logic programming. and neural networks. To begin, OAV triplets will be addressed. Not only are they a mode of knowledge representation in themselves. they also form the building blocks of virtually any other approach to knowledge representation.

1. OAV Triplets

Object attribute value triplets provide a particularly convenient way in which to represent certain facts within a knowledge base and may be extended (as we shall see) to provide the basis for the representation of heuristic rule. Each OAV triplet is concerned with some specific entity. or object. For example, our object of interest might be an airplane. Associated with every object is a set of attribute that serve to characterize that object. Using the airplane as an example (i.e., a the object), some of its attributes include the following:

FIGURE 4.1 OAV Network

For each attribute, there is an associated value, or set of values. For instance, in the case of the C:130 military cargo aircraft (known as the Hercules), the number of engines is four, the type of engine is prop, and the wing design is conventional. Notice in particular that values in OAV triplets may be numeric or symbolic. We may list these facts as shown below:

Observe that, in this list, the object itself (i.e., the C130 aircraft) is never explicitly stated. Actually, the above statements represent AV (attribute value) pairs.

However, associated with any AV pair in some object. Thus, any pair implies an OAV triplet.

Yet another way to represent an OAV triplet would be through the use of a network representation as indicated in Fig. 4.1. The basic building blocks of a network are its nodes (i.e., the circles) and branches, or edges (i.e., the lines connecting two nodes). In Fig. 4. 1, the object is Pete Jones, the attribute is his income, and the specific value of his income is $50,000.

2. Semantic Networks

A semantic network may be thought of as a network that is composed of multiple OAV triplets in network form as illustrated in Fig. 4.1. However, rather than pertaining to just one attribute for a single object, semantic networks may be used to represent several objects, and several attributes per object. Returning to our aircraft illustration of the previous section. we might develop a partial semantic network as illustrated in Fig. 4.2. Here, we note that the C5A is a special type of aircraft (i.e., a large military cargo plane). Further, since the C5A is an aircraft, it inherits the properties associate with aircraft in general (e.g., it flies. has wings, carries people). Such an inheritance property can prove to be of considerable value in the reduction of memory storage requirements. That is, since a C5A is an airplane. there is no need to store at the C5A node, the fact that it can fly, has wings, and can carry people. Thus, the semantic network scheme provides for a convenient approach for the representation of associations between entities.

We might also note that the OAV triplet is actually just a restricted subset of semantic networks wherein the only relationships that may be used are those of "is-a" and "has-a " OAV nodes, in turn, may be any of three types: objects, attributes, or values.

FIGURE: 4.2 Semantic network.

 

3. Frames

While semantic networks provide a relatively versatile means for knowledge representation, the use of frames represents an alternative approach that serves to capture most of the frames of the semantic network while providing certain additional aspects. In fact, we may think of a semantic network as being a subset of the concept of frames.

The employment of frames represents a particularly robust way in which to present knowledge. A frame contains an object plus slots for any and all information related to the object. The contents of such slots are typically the attributes and attribute values of the particular object However, in addition to storing values for each attribute, slots may contain default values, pointers to other frames. and sets of rules or procedures that may be implemented

Figure 4.3 illustrates a frame based representation for the object dog. Note that the slots within this frame include values (e.g., Beagle), defaults (e.g., four legs). and procedures (e.g.. for a medical examination). The procedures, in turn, could well point to other frames. The versatility of the frame based mode of knowledge representation should be obvious.

The primary drawback to the use of frames is. ironically, caused by the very robustness of such a mode of representation. Frames have so many capabilities as to make their use a rather complex matter. Jackson [19861 states that "many people are unhappy with frame and object based systems because they seem to depart from logic and because their flexibility in matters of context and control can make their behavior both hard to predict and difficult to understand." As a result, to obtain any reasonable proficiency in the use of frame based tools in expert systems, a lengthy training period is required. Despite such drawbacks, frames can prove quite useful, if not essential, in the design of large scale, complex expert systems particularly those involving a large amount of a priori facts (i.e., data) and multiple object. While fame are not focused on in this text, it is strongly encouraged that serious student investigate this topic after he or she has attained a reasonable level of competence in the use of rule bases.

FIGURE 4.3 A Frame based representation

 

4. Representation via Logic Statements

The most common form of logic is that known as prepositional logic. A Proposition, in turn, is a statement that may be either true or false. Propositions may be linked together with various operators (termed logical connectives) such as AND, OR. NOT, and EQUIVALENT. Linked propositions are termed compound statements. To demonstrate, consider the statement X, Y, and Z where the first two statements (X and Y) are true while Z is false. Thus we may conclude that

Predicate calculus represents an extension of prepositional logic. The fundamental element of predicate calculus are the object and the predicate. A predicate is simply a statement about the object, or a relationship that the object possesses. Predicate may address more than one object and may be combined by use of logical connectives. Some examples of the use of predicate calculus follow:

The first of these statements is true. the second is in general true, and the third is definitely false. Unless we know Joan and Jack personally, the validity of the fourth statement is unknown. Using predicate calculus, we can then represent such compound statements as "Joan is Jack's sister and Fred's cousin" as

Sister(joan, jack) AND cousin(joan, fred)

We can also represent various relationships, or rules, by means of predicate calculus. For example, consider the heuristic that states that, if interest rates a: rising, bond prices will fall: Using predicate calculus, and the logical IF statement we can represent this heuristic as

fall(bond prices) if rises interest_rates)

where we have used a format similar to that employed in PROLOG, a computer programming language popular in artificial intelligence.

One major advantage of the use of logic for knowledge representation that logic-based languages. such as PROLOG, do exist. However, such language have been criticized for a certain lack of flexibility: a criticism that is becoming less valid with recent enhancements to their procedures. A more immediate are pragmatic drawback of the use of logic for knowledge representation is the fact that one must learn some logic programming language (e.g., PROLOG) in order to develop expert systems.

5. Neural Networks

Obviously, somehow, some way, the human brain stores knowledge. What is r. so obvious is the precise manner in which this is accomplished. Neural network represent mankind's attempt to replicate, in hardware. theories pertaining to the brain. Specifically, it is thought that knowledge is stored in neurons (or, actually. the connections between neurons). Figure 4.4 depicts a simplified representation of only two neurons within the neural network of the human brain.

In the human brain there are more than 10 billion neurons, and each neuron is connected to one or more other neurons, resulting in a massively interconnecting network. At each neuron, impulses are received by the dendrites and transmit by the axons. If the output of the axon is at a high enough level, the signal X jump the synaptic junction and trigger the connected neuron (or neurons). It believed that knowledge might then be represented by the weightings on e. neuron to neuron interconnection, which in turn influence the level of strength the interconnecting impulses.

The attempts to duplicate the neural network structure of the brain has been. at best, extremely modest. Typically, electronic amplifiers are used to represent the neurons and resistors to correspond to the interconnecting weights. And existing systems have but a few layers of relatively few neurons. Despite this. neural networks can be used to accomplish some intriguing tasks, including some

FIGURE 4 4 A portion of a neural network

success in speech recognition. In particular. they provide a robust approach to the general problem on pattern recognition. Probably the biggest single disadvantage of the neural network approach to knowledge representation is the fact that any knowledge that exists is almost tonally opaque. (2)

Since neural networks are often excellent choices for problems of classification, they may be combined with an expert system to perform certain tasks. That is, the neural network may be used to classify and, based upon this class, the expert system may then be used to determine the specific course or courses of action to take.

 

(2).One of the major areas now being addressed and funded in neural network research is , in fact, the development of rules for representation of the process employed by the neural network.

6. REPRESENTATION VIA RULE-BASED SYSTEMS

Undoubtedly, the most popular mode of knowledge representation within expert systems, at least at this time, is the mode obtained through the use of rules, or rule-based systems. Alternatively, such rules are referred to as IF THEN, or production rules. We have selected rule based expert systems as our approach to knowledge representation for a number of reasons, including their popularity and widespread use. however, it should be stressed that this decision does not imply that rule based systems are necessarily the best approach or. in particular, the best approach for every situation. There are those who present quite persuasive arguments for other approaches; in particular for the employment of frame-based representation. Our choice of rule-based knowledge representation has been made for the following reasons:

The majority of existing expert systems development packages (and this is especially true for expert systems shells) employ rule bases.

Rule-based expert systems development packages are normally much less expensive (in terms of both the initial cost of the package as well as the overall cost of using the package) than those employing alternative modes of representation.

Specifically, they cost less to purchase, normally do not require any expensive hardware (most run on inexpensive, general purpose personal computers), and require minimal expenditures toward training.(3)

The widespread availability (if rule based expert systems shells permits the knowledge engineer to focus his or her attention on the most critical phase of the development of an expert system, that is. on the knowledge base.

Rules represent a particularly natural mode of knowledge representation. Consequently, the time required to learn how to develop rule bases is minimized.

The learning curve for rule-based expert systems is much steeper than for any alternative mode of representation (i.e., it takes less time to learn how to use and implement rule-based expert systems).

Rules are transparent, and are certainly far more transparent than the modes of knowledge representation employed by rule-based systems' two major competitors: frames and neural networks. Further. such transparency often leads to an increased willingness, on the part of management. to accept the solutions obtained. And the importance of this last factor should not be underestimated.

Rule bases can be relatively easily modified. In particular, additions, deletions, and revisions to rule bases are relatively straightforward processes. And this is particularly so in the case of well designed rule bases.

Rule-based expert systems can be employed to mimic most features of frame-based representation schemes (the amount of work that may be needed to accomplish this, however. is not necessarily trivial).

Validation of the content of rule-based systems (i.e., the determination of the completeness and consistency of the representation) is a relatively simple process. Similar validation of frames or neural networks, on the other hand, is normally difficult to impossible. .

Finally, it is our opinion that the rule-based approach provides the most appropriate introduction to the topic of expert systems. With the rationale for our selection of rule-based knowledge representation behind us, let us now address the topic of the development of rule bases.

(3) The costs of training are all too often grossly underestimated by firms considering the in-house development and maintenance of expert systems. In particular, the cost associated with the employment of frame-based systems can be on the order of ten to a hundred times that of the initial investment in the systems. Such expenditures may be minimized through the employment of rule-based expert systems.


Knowledge Acquisition

Knowledge acquisition  is the process of acquiring the knowledge from human experts or other sources (e.g. books, manuals) to solve the problem.

Knowledge acquisition and knowledge representation are phases of expert systems development that proceed virtually hand in hand. And both phases are absolutely vital to the integrity of the rule base for the expert system ultimately constructed.

Knowledge Acquisition Via Domain Expert

The knowledge acquisition phase of development is also one that can be extremely frustrating as well as time consuming. Some have termed it the; bottleneck of expert systems development, Here, we are often dealing directly and intimately with domain experts. While dealing with people in general can be difficult, interfacing with domain experts can be many times as frustrating.

Knowledge acquisition and the domain expert

There are a number of good papers that discuss the conduct of the knowledge acquisition phase. Prerau ll987] and Surko [1989]. in particular, have provided some excellent guidelines for knowledge acquisition. Here, we have attempted to summarize our own thoughts on knowledge acquisition, where the influence of numerous other authors is acknowledged. These guidelines are presented in the list that follows. While it may not be possible to abide by each and every point, the guidelines should at least be considered in the planning of the knowledge acquisition effort.

Selection of the Domain

The domain should be one for which the expert systems approach is truly appropriate, and for which an expert system would provide some distinct advantage over any alternative methods.

Good decision making within the domain should be of sufficient importance to management that they are willing to commit the time and resources necessary to support the development and implementation of the expert system.

Management must recognize both the costs and risks of expert systems development. Any nontrivial expert system is going to require the employment of competent knowledge engineers, over a reasonable period of time. If management has totally unrealistic expectations (e.g. in terms of time, cost, or capabilities), make an attempt to clarify the process. If their expectations remain unrealistic, there is probably no point whatsoever in pursuing the project.

The domain should be relatively stable; in particular. dramatic changes over the period of the development effort should not be foreseen.

Selection of the Knowledge Engineers

The Role of the Knowledge Engineer

Ideally. two knowledge engineers should be used, where at least one of these is experienced in the development and implementation of (successful) expert systems .

Selection of the Expert

Ask the organization to provide you with the names of candidate domain experts, that is, those individuals who are believed to have significant expertise within the domain in question.

The Initial Meeting

Prior to this meeting. the knowledge engineers should make an all out effort to familiarize themselves with the problem, the domain. and the terminology used within the domain.

Background

Organization of Follow-on Meetings

Conduct of the Follow-on Meetings

Documentation

Document the results of the meeting as soon as possible after the meeting (preferably, immediately after the meeting).

Documentation for each meeting should include such facts as:

Documentation in support of still production rules thus far developed should include such facts as:

While there will obviously be exceptions to such guidelines. they do provide an overall basis for the systematic and efficient conduct of the knowledge acquisition phase of expert systems development. Those who follow such a procedure will most likely reach their goal in less time and with greater efficiency.

However, one word of warning. Examine once again the last element of the list under the "Conduct of the Follow-on Meetings" guidelines. Sometimes, we can get so involved in the problem. and in procedures in general, that we lose sight of just what it is that we are there for. Remember, your goal is to develop a rule base that represents, as closely as possible the heuristics used by the domain expert. This must always be the focus of the effort.

In order to establish a (good) rule base, there are certain things to look for. in particular:

The expert may not understand the concept of rules and heuristics. It is generally best to ask him or her about any neat little tricks or shortcuts that are employed to reach a decision. Usually, these represent pruning, or filtering, heuristics (i.e., heuristics used to reduce the number of paths searched in the inference network) .

Ask the expert about those instances in which he or she can come to a really quick conclusion. That is. just when are decisions easy? For example. the example may note that, under certain circumstances he or she can immediately determine that outside help is needed. or that the problem is trivial. Associated With these situations are rules that need to be incorporated at the very top of the knowledge base. We want to identify these easy decisions as soon as possible in the inferencing process. in order to reduce both the time required to find a solution and the number of .questions presented to the user.

Is the problem one of classification or construction? If it appears to be a classification (i.e., diagnosis) problem. then try, in particular. to determine

The symptoms the expert uses in classification.

The treatments that the expert recommends the relationships between symptoms and treatments (i.e., how are they matched)

If the problem faced is one of construction (e.g., the development of a schedule. loading scheme), then look; especially for:

The data employed by the expert

The list of alternatives (i.e. final conclusions), and whether or not this list may be preenumerated

The heuristics used to prune the list of alternatives

Determine, as soon as possible in the effort, the data used (and its source) by the expert in reaching his or her conclusions. If your expert system is to reach conclusions similar to those of the domain expert. it will require access to the same data.

Multiple Domain Experts

Surko addresses. in her paper 11989], one additional consideration in knowledge-base development: the existence of more than one domain expert. Some authors have noted that this situation can be particularly frustrating if not properly and delicately handled. Surko. however. advises that the knowledge engineer need not be particularity concerned about multiple experts. That is. using a rule base cloned from an expert. we build a prototype expert system and then let the other cloning experts critique the results. She states: if two experts disagree, then you'd probably better just quiet choose the version you feel is right. Your aim is to get the best knowledge. but !you must do so with the minimum discord...." In a(additional. she notes that getting experts together to air their differences is usually too risky for the potential gains.

Our own experiences in dealing with multiple experts has followed a similar approach. We have always selected one domain expert as the individual from whom the rules were to be acquired, that is. as the key expert. And, as Surko suggests. we have presented the prototypes to the remaining experts for a critique. III doing this. we have tried to discourage the key expert from attending such presentations. We feel that his or her attendance may cause the other experts to feel less free in making their comments and criticisms. From the suggestions, comments. and criticisms received from the other experts. we have then attempted to identify those that seemed to be both constructive and important. We then presented these to the key expert for his or her comments. Rather surprisingly, at least to us. we have almost always found the key expert to be responsive and objective in such situations.

There is yet another situation in which multiple experts may be encountered. However. rather than having mastery across the entire domain of interest, these experts may each have expertise in various portions of the domain. One approach to this situation is to develop a set of expert systems. one for each subdomain. Another is to utilize separate knowledge bases (i.e., one for each expert) and to coordinate these through a single expert systems package by means of the blackboarding approach. And this is precisely the approach used in HEARSAY, an expert system described in Chap. 8.

KNOWLEDGE ACQUISITION: AN EXAMPLE

In the August 12, 1988 issue of The Wall Street Journal [Rose, 1988], a front page story described one recent, and somewhat less than successful attempt at knowledge acquisition. Since there are lessons to be learned through both success and failure, let us consider this particular situation. While reading the summary of this effort (as extracted from the referenced article), compare if you will what was done with the guidelines that we have presented earlier.

Mr. Thomas Kelly was, at the time of the publication of this story, a 5.5 year-old civil engineer working for Southern California Edison. Over a period of 20 years he had become an expert in the diagnosis and treatment of problems of a massive and troublesome earthen dam high in the Sierra Nevada mountain range of central California. For example, from supposedly just a trickle, Mr. Kelly is able to determine if the dam is bleeding or just breathing.

Mr. Kelly's expertise was considered too valuable to risk losing. Thus, the company spent two years and roughly S300,000 in an attempt to create an expert system that cloned his knowledge of earthen dams. One particular dam under consideration is named Vermilion. It is a trouble-plagued, 24-year-old dam that spans Mono Creek, a tributary of the San Joaquin River. The dam is 165 feet high and about a mile in length and can hold as much as 40 billion gallons of water, It is particularity prone to water seeping through its foundation and Mr. Kelly's expertise has been a major factor in keeping the dam and the population in the valley below safe. An expert system was proposed to achieve a level of problem solving comparable to the human expert, for application to any earthen dam.

Southern California Edison called upon Texas Instruments, Inc. for the development of an earthen dam expert system. Texas Instruments sent two knowledge engineers to proceed with the knowledge acquisition phase. One was a 30-years old engineer and computer whiz and the other was a 30-year-old management systems expert. This was the first assignment for both.

To quote directly from The Wall Street Journal article:

Reprinted by permission of the Wall street Journal Dow Jones & Company. Inc.. 1988. All Rights Reserved worldwide.

The programmers were nervous when they first sat down With Mr. Kelly, who is almost twice their age They had boned up on books about dam safety and construction, but that was just a start. Before them was a professional engineer, with decades of experience that they needed to dissect....

Their first meeting was a marathon, 7-hour session in a windowless room, where the programmers grilled Mr. Kelly. Tell us about Vermilion's earth and gravel interior the pair asked. What about the drainage systems that riddle the dam? Every syllable was tape-recorded and transcribed for later study. When [they] left the meeting, everyone's eyes were bugging out....

As the sessions continued, Mr. Kelly began to find them more and more troubling. The knowledge engineers were equally frustrated. Mr. Kelly would listen to questions and reply with a simple "yes'' or 'no." When he provided explanations, which was evidently not too often, they were brief. While Mr. Kelly insisted that he was being cooperative, the knowledge engineers wondered if he was perhaps unconsciously reluctant to part with his expertise.

The knowledge engineers' first attempt at constructing a prototype expert System met with equally frustrating results. For almost every problem posed, the system would respond with the suggestion to pack the offending wet area of the dam with gravel and keep it under observation. Finally, the knowledge engineers visited the dam. And this visit provided them with what they termed a visual breakthrough, an enhanced appreciation of the elements of the problem.

However, even months later. the expert system's knowledge base consisted of only about 20 rules, and still produced trivial advice. After a year, and concerned now about the time and funds being expended, Southern California Edison decided to narrow the project's scope to consider only the Vermilion dam.

Texas Instruments assigned yet another employee to the project. Gradually, the group’s insight into the problem grew. as did the knowledge base. The number of rules increased to about 80. However. confidence in the system, on the part of Mr. Kelly. seemed lacking.

Ultimately, the project wound down. The Texas Instruments' team moved on to other projects. The expert system developed is not in regular use and Southern California Edison officials state that the system ''needs more work to be really useful.''

The less than satisfactory results of this particular effort are hardly unique. A formula for the lack of success in developing the earthen dam expert system can be noted in a host of other expert systems efforts. Analyzing the situation. One may note a number of factors that may have diminished the project's chance of success. These include:

To clarify the last point, it would seem, at least from reading the article, that the two novice knowledge engineers were in awe of the domain expert, On the other hand, Mr. Kelly may have perceived such a reaction as an indication of a lack of experience coupled with naivete. Mr. Kelly could point to a successful career as an earthen dam expert; the two knowledge engineers had yet to accomplish their first successful expert systems project. And this was evidently still the case at the conclusion of this $300.000, two-year effort.

THE KNOWLEDGE ENGINEER AS THE DOMAIN EXPERT

As mentioned earlier, the selection of an expert may be a problem in the knowledge acquisition phase. There may, in fact, be no practical access to a domain expert. The expert may have died. Left the company. or may simply refuse to participate in the development of an expert system. In such an instance, we have at least two options. One is to use (or generate) historical data through which a rule based expert system may be constructed. The second is to become our own expert. In this section we will focus on the latter approach.

Quite often in the expert systems literature there are warnings against becoming one's own expert. While we agree that such an approach is a matter of concern, we also believe that it may prove worthwhile if conducted properly. In fact, one of the most highly touted expert system, and one that is in actual use. is the Rl (or XCON) system for the configuration of VAX computers at the Digital Equipment Corporation (DEC) and the initial prototype of this system was developed primarily by knowledge engineer. Specifically. John McDermott of Carnegie Mellon University began this project with a meeting of the VAX configuration experts at DEC. This meeting simply provided McDermott with an overview of the task. He then took: two DEC configuration manuals back to his office and reviewed them in detail. Using this input, he developed a prototype expert system consisting of about 250 rules in about three person-months. The demonstration of the prototype indicated that it was able to satisfy all of the basic configuration problems provided by DEC. This success resulted in an extension of the project wherein an expert was used to evaluate the refine system. However, the initial prototype was developed primarily by the knowledge engineers. And this demonstrates that it is indeed possible to be one's own expert, at least in certain situations.

One argument against becoming one's own expert is the belief (as based on rather substantial empirical evidence) that it takes approximately 10 years to become an expert in a particular domain. Rather obviously, if this were the case, it would be very rare indeed to devote those 10 years to the development of our expertise simply for the purpose of constructing a single expert system. However, the 10-year figure is based on the belief, by psychologists, that a world-class expert (e.g., 3 chess grandmaster, a composer of classical music, or a Nobel laureate in a field of science) must store somewhere between 50.000 and 100,000 chunks of heuristic information prior to becoming an expert and that it takes at least 10 years to acquire 50,000 chunks [Harmon and King, 1985]. Such an estimate may be reasonable. However. most often the types and breadth of expertise that a knowledge engineer is concerned still are hardly in the same league as that of a Nobel laureate.

In some respects, there are certain benefits to he gained by such an approach That is, when knowledge engineers are their own experts, some aspects of the knowledge acquisition procedure are immediately simplified. For example. one can proceed directly to a statement of the rules in the IF-THEN format. Also, we do not have to worry about the expert's schedule, or the expert's reluctance (or inability) to describe the procedures used. Further, we may obtain a more objective view of the procedure since the knowledge engineer may have no vested interests in the organization under consideration. All too often, those who are dealing directly with a problem are unable to see the forest for the trees, and thus an outsider's perspective may represent a significant improvement. At any rate, there are advantages and disadvantages in being one's own expert and one should not dismiss, out of hand, such an approach.

THE DOMAIN EXPERT AS THE KNOWLEDGE ENGINEER

Now, if the knowledge engineer can act as the domain expert, why not employ the domain expert as the knowledge engineer? Actually, the ultimate goal of expert systems is to provide a development package that interacts directly with the domain expert, and thus supposedly eliminates the need for the knowledge engineer. However, this goal has yet to be reached and it is unlikely, despite certain claims in this area. that it will be at least in the foreseeable future.

There has been, however, a certain amount of success in training domain experts to develop small-to-modest sized rule bases, and to implement these rule bases on various expert systems development packages particularly on some of the more user friendly expert systems shells that are now available. Several firms have, in fact, reported significant improvement in overall productivity through the development of numerous small (rule-based) expert systems by their domain experts.

Our reaction to such an approach is mixed. We are all for the increased involvement on the part of everyone in the organization in expert systems development and implementation. Further, it is not inconceivable that many domain experts can, through proper training, become competent knowledge engineers. As just one example, in the case of Mr. Kelly, our expert on earthen dams for Southern California Edison, such an approach may have well proved fruitful. However, there are certain drawbacks. These include:

Each of these drawbacks may be alleviated, to some degree, by providing access to an in-house or external group of knowledge engineers. The knowledge engineers may provide the training and assist in rule base development. This is, in fact, the approach that has been taken by a number of firms.

KNOWLEDGE ACQUISITION VIA RULE INDUCTION

An alternative to the acquisition of knowledge through the interface with a human (i.e., an expert or a knowledge engineer assuming the role of the expert) is to convert an existing (and appropriate) database into a set of production rules [Carter and Catlett, 1987; Quinlan, 1983, 1987a; Thompson and Thompson, 1986]. The appropriate database, in turn, must consist of data that encompass examples pertaining to the type of problem under consideration where the examples selected should represent desirable outcomes (i.e., it makes little sense to use examples which reflect poor judgment). More specifically, one needs examples of good decision making. In some cases, this approach may provide adequate results while, in others, it may at least lead to the development of a credible prototype system. Several commercial expert systems shells, in fact, incorporate means (actually, supporting programs) for the accomplishment of such a process. We will, in fact, present the results of the application of two commercial software packages (i.e., for the development of rules from a database) later in this chapter. However, one should most definitely first understand precisely how this is done, as well as the scope and limitations of this approach.

Before describing one popular approach to rule generation from data, let us first reflect upon the components of a knowledge base consisting of production rules. To clarify our discussion, let us return to the simplified aircraft identification problem. Our problem is concerned with the identification of various types of aircraft, where we will limit the number of aircraft under consideration to just the C130 (Lockheed Hercules), C141 (Lockheed Starlifter), CSA (Lockheed Galaxy), and B747 (Boeing jumbo Jet). Note carefully that, for purpose of illustration, these four aircraft will be the only inhabitants of our universe of airplanes.

Identification of Objects, Attributes, and Values

Rather obviously, the objects in our knowledge base are the four different types of aircraft. Our next step is to consider the attributes that serve to distinguish these aircraft from one another. For example, some of the many attributes exhibited by these aircraft include

Having identified a candidate set of attributes and their values, we should next consider filtering out those attributes that do not serve to support our decision making process. For example, the number of engines is obviously not necessary since each of the four aircraft under consideration has exactly four engines. (However, in a more realistic aircraft identification model, we would extend our concern to all possible aircraft and there the number of engines does. of course, serve to distinguish one aircraft from another.)

We might also be able to drop the last three attributes since, at the distance we expect to see the aircraft, we will not be able to distinguish colors and markings or estimate size and dimensions, speed and altitude. We are then left with the second through the sixth set of attributes, which may or may not be enough to permit precise aircraft identification. Actually, as we will see, these five attributes (i.e, engine type, wing position, wing shape. tail shape, and bulges) will be more than sufficient under the rigid assumptions of a strictly deterministic rule base and a completely stable system.

Before we proceed, let us repeat our warning, with regard to the avoidance of false economics. Realize that, by eliminating attributes, we are eliminating premise clauses in the rule base, as well as knowledge about the situation. Thus, one must always be careful that the attributes dropped from consideration are not a part of the necessary knowledge for the problem under consideration. This guideline can, however, create a dilemma. That is, should we seek the minimal set of attributes or, to be safe, should we try to incorporate every conceivable attribute? Unfortunately. there is no clear cut answer. Too many attributes may make the knowledge base unwieldy and require an inordinate amount of data and/or responses from the user. As a result. the expert system will appear to be plodding. if not outright dumb. Too few attributes can limit the usefulness of the expert system, as well as make future modifications more difficult. Thus, when all is said and done, we normally seek some acceptable compromise .

Assuming that we feel relatively confident with the filtered set of attributes, we may list these and their associated values.

    Aircraft type    
Attribute C130 C141 C5A B747
Engine type Prop Jet Jet Jet
Wing position High High High Low
Wing shape Conventional Swept back Swept back Swept back
Tail Conventional T-tail T-tail Conventional
Bulges Under wings Aft wings None Aft cockpit

Developing Knowledge Base



Inference Engine



Advantages and Disadvantages

Advantages of Expert Systems

Disadvantages of Rule-Based Expert Systems