ABSTRACT: An expert system is a computer program that contains stored knowledge and solves problems in a specific field in much

the same way that a human expert would. The knowledge typically comes from a series of conversations between the developer of the expert system and one or more experts. The completed system applies the knowledge to problems specified by a user. One is to use expert systems as the foundation of training devices that act like human teachers, instead of like the sophisticated page-turners that characterize traditional computer-aided instruction. The idea is to combine one expert system that provides domain knowledge with another expert system that has the know-how to present the domain knowledge in a learnable way. The system could then vary its presentation style to fit the needs of the individual learner.

Expert Systems Evolution.

3.1Timeline. The expert systems technology is based on a wide background. Fig. 2. 1 presents the major milestones in the development of the expert systems.

As one can see, the Expert Systems history starts at around 1943 with the Post production rules. The initial trend was towards intelligent systems that relied on powerful methods of reasoning rather than making use of domain knowledge. They were also designed to cover any domain rather than a specialised area. The shortcoming of this approach was that the machine had to discover everything from first principles in every new domain. In contrast, a human expert would rely on domain knowledge for high performance.

3.2

Milestones.

3.2.1 The Beginning. It all started in the late 50s and early 60s, when several programs aimed at general problem solving were written. Post (Ref 3) was the first to use the production systems in symbolic logic, proving that any system of mathematics or logic could be written as a certain type of production rule system. The basic idea was that any mathematic /logic system is just a set of rules specifying how to change a string of symbols into another set of symbols. The major difference between a Post production system and a human is that the manipulation of strings is only based on syntax and not on any semantics or understanding of the underlying knowledge. A Post production system consists of a group of production rules. The limitation of the Post production system is that, if two or more rules apply, there is no control specifying whether to apply one, some or all rules, and in what order. The Post production rules are not adequate for writing practical programs because of the lack of a control strategy. At the same time (around 1943), McCulloch and Pitts developed a mathematical modelling of neurons, which later gave birth to the connectionist programming paradigm. Hebb gave an explanation of the learning process of the neurons in 1949. The next step happened around 1954, with the introduction of a control structure for the Post production system, by Markov. A so-called Markov algorithm is an ordered group of productions, applied in order of priority to an input string. The termination of the Markov algorithm is triggered by either a production not applicable to the string or by the application of a

ruleterminated with a period. The Markov algorithm as a definite control strategy. The higher priority rules are used first. If not applicable, the algorithm tries the lower priority rules. Although applicable to a real expert system, the Markov algorithm may take a long time to execute on a system with many rules. If the response time is too long, the system will not be used no matter how good it is. The possible improvement to Markov's approach of always trying all the rules, was of course to be able to apply any rule, in a non-sequential order. This would be possible if the algorithm already knew about all the rules. This was to happen later on, around 1977 - 1979. 3.2.2 The human problem solving model. An outstanding example of a problem solving program was to be the General Problem Solver, described in the published work Human Problem Solving (Ref 2), by Newell and Simon. Their work demonstrated that much of the human problem-solving (cognition) could be expressed as IF..THEN production rules. Newell and Simon regarded the knowledge as modular, each rule corresponding to a small module of knowledge called a chunk. In this model, the human memory is organised chunks loosely arranged, with links to other related chunks. Sensory input would provide stimuli to the brain and trigger appropriate rules of long term memory, which then produce the suitable response. The long term memory is where the knowledge is stored; the short term memory however, is used for temporary knowledge storing during problem solving. Human problem solving must also include a so-called cognitive processor. This is the equivalent of the inference engine in a modern expert system. The cognitive processor will try to find the rules to be activated by the appropriate stimuli. If more than one rule is to be activated, then a conflict resolution must be performed in order to decide which rule will be activated first (priority assignment). Newell and Simon have not only managed to create a credible model of human problem solving, but have also set the basis of the modern rule-based expert systems. The concept of knowledge chunks brings with it the problem of granularity in the design of expert systems. More granularity means several chunks of knowledge are blended together in one rule; less granularity makes an isolated rule difficult to understand.

A. A change of concept.
The General Problem Solver reflected the current trend of the sixties to attempt producing general-purpose systems that heavily relied on reasoning and not on domain knowledge. Both approaches have their advantages and disadvantages though.

Domain knowledge may be powerful, but it is limited to a particular domain. Applying it to another domain involves skill rather than genuine expertise. In the early seventies it was already obvious that the only way to achieve machines comparable in performance with human counterparts was to use domain knowledge. In many cases, human experts rely less on reasoning and a lot more on a vast knowledge of heuristics (practical knowledge) and experience. When a human expert is confronted with a substantially different problem, he/she must use reasoning from the first principles and they are no better in this respect than any other person. Therefore, expert systems relying solely on reasoning are doomed to failure. The factors that contributed to the creation of the modern rule-based systems are presented in Fig. 2. 2.

Fig. 2. 2 Creation of the modern rule-based expert system (Ref.1, p.15) In 1965, work has begun on DENDRAL, the first expert system, aimed at identifying chemical constituents. However, DENDRAL was an unique system in which the knowledge base was mixed together with the inference engine. This made the task of reusing it to build a new expert system almost impossible. 1972-73 brought the development of the MYCIN system, intended to diagnose illnesses. MYCIN was a step forward because: The Evolution of Expert Systems Expert Systems Evolution

 it has demonstrated that AI may be used in real-life situations; MYCIN was used to test and prototype the explanation facility, the automatic knowledge acquisition (bypassing the explicit knowledge coding) and even intelligent tutoring (found in the GUIDON system); the concept of expert system shell was demonstrated to be viable. MYCIN explicitly separated the knowledge base from the inference engine, making the core of the system reusable. Emptying out the knowledge base of the MYCIN system for example, and reusing the inference and explanation modules could therefore build a new expert system. The shell produced by removing the medical knowledge from the MYCIN system produced EMYCIN (Empty MYCIN). Back to the improvements in the control algorithms. In 1979 Charles R. Forgy, at the Carnegie-Mellon University developed a fast pattern matcher algorithm, which stores information about rules in a network. The RETE algorithm is fast because it does not match facts against every rule on every recognise-act cycle. Instead, it looks for changes in matches. Because the static data does not change, it can be ignored and the processing speed increases dramatically. This algorithm was used to develop the OPS (Official Production System) language and shell. The foundations of the modern rule-based expert systems are shown in Fig. 2.3. A variation of the DENDRAL system was developed in 1978, called METADENDRAL. This program used induction to infer new rules of chemical structure. METADENDRAL has been one of the most important attempts to defeat the acquisition bottleneck, where the knowledge has to be extracted from a human expert and explicitly coded into the knowledge database. Another example of meta-reasoning was the TEIRESIAS knowledge acquisition program for MYCIN. In case of an erroneous diagnosis, TEIRESIAS would interactively lead an expert through the reasoning MYCIN has accomplished, until the point where the mistake was made is discovered. The acquired rule would first be tested for compatibility with the existing rules, and if no conflicts found, added to the knowledge base. Otherwise, TEIRESIAS would query the user about the conflict. Meta-knowledge in TEIRESIAS can be either a control strategy (on how the rules

must be applied), or validation-and-verification meta-knowledge (whether the rule is in the correct form so it can to be added to the knowledge base).

14

The Evolution of Expert Systems Expert Systems Evolution

Fig. 2. 3 The foundation of the rule based expert systems (Ref.1, p.32) 3.2.3 A new trend. Around 1980, companies start producing commercial expert systems, accompanied by powerful software for expert system development. An example is the Automated Reasoning Tool (ART, released later on in 1985). Also in 1980, new specialised hardware was developed, optimised to run the expert system software faster. The LISP machines were specially designed to run the most used expert system development base language of the period, LISP. The native assembly language, operating system, etc were actually created in LISP (LISt Processing language). As one can imagine, this type of dedicated technology came to a price. While being more efficient and faster at running LISP code, the dedicated machines had price tags around $100000. Obviously there was a need for more affordable software that could run on common machines. 1985 is another milestone to the development of expert systems, with the introduction of CLIPS by NASA. Written in C, CLIPS is portable (i.e. suitable for a large number of platforms), fast (it uses the RETE pattern matching algorithm developed by Forgy in 1979) and cheap or free for some users. CLIPS can run on any machine that can run the standards C language. CLIPS had actually made expert system development and study accessible to large groups of potential users. This is always vital in promoting the acceptance of new technologies. 1990 sees the revival of the neural networks with the Artificial Neural Systems (ANS, refer section E, part 1). In 1992, 11 shell programs were available for Macintosh, 29 for MS-DOS programs, 4 for UNIX platforms and 12 for dedicated mainframe applications (Ref.7). By 1994, commercial ANS are being offered (refer section E, part 3) by various companies at different levels of price and features. The number of expert systems patents in the US has grown steadily from 20 in 1998 to over 900 in 1996.(Ref.7). The GUESS system (Generically Used Expert Scheduling System) , by Liebovitz et al, was devised in 1997, using an object oriented, constraint-based AI toolkit approach to perform scheduling.

The current (1997-) trend cannot escape the influence of the Internet. Envisaged applications are: intelligent customer and vendor agents for use on the web in E-commerce; intelligent search engines; interagent communications methods relating to AI in E-commerce.

1. INTRODUCTION: Within the last ten years, artificial intelligence-based computer programs called expert systems have received a great deal of attention. The reason for all the attention is that these programs have been used to solve an impressive array of problems in a variety of fields. Well-known examples include computer system design, locomotive repair, and gene cloning. How do they do it? An expert system stores the knowledge of one or more human experts in a particular field. The field is called a domain. The experts are called domain experts. A user presents the expert system with the specifics of a problem within the domain. The system applies its stored knowledge to solve the problem. Conventional programming languages, such as FORTRAN and C, are designed and optimized for the procedural manipulation of data (such as numbers and arrays). Humans, however, often solve complex problems using very abstract, symbolic approaches which are not well suited for implementation in conventional languages. Although abstract information can be modeled in these languages, considerable programming effort is required to transform the information to a format usable with procedural programming paradigms. One of the results of research in the area of artificial intelligence has been the development of techniques which allow the modeling of information at higher levels of abstraction. These techniques are embodied in languages or tools which allow programs to be built that closely resemble human logic in their implementation and are therefore easier to develop and maintain. These

10

programs, which emulate human expertise in well defined problem domains, are called expert systems. The availability of expert system tools, such as CLIPS, has greatly reduced the effort and cost involved in developing an expert system. The goal of expert systems research was to program into a computer the knowledge and experience of an expert. Expert systems are used in medicine, business management, for searching for natural resources and much more. Randal Davis, of MIT is quoted as saying, "Expert systems can be experts - you come to them for advice. Or they can be coworkers, on a more equal footing. Or they could be assistants to an expert. All along the spectrum there are very useful systems that can be built."

Expert Systems came at a time when AI research was shifting "from a powerbased strategy for achieving intelligence to a knowledge based-approach." Where formerly researchers were aiming at making more powerful systems that used clever techniques and tricks, they instead began to look at programming more knowledge into-machines.

The rise in expert systems research brought with it a new type of engineering: knowledge engineering. It was the job of a knowledge engineer to take the knowledge of an expert and convert that knowledge into a form that could be understood by computers. This was a quite a long process. In the case of Mycin, several physicians were presented with cases and asked to diagnose the patient, propose a treatment and explain the reasoning behind their decisions. From these interactions with the experts, knowledge

engineers came up with a set of rules to be programmed into the computer. Then the computer was tested on several cases and its conclusions matched

11

with those of human experts. When necessary, rules were added or modified to fix errors in the computer's program.

However, expert systems still had their limitations. It took a lot of time to build the system with many hours of testing and debugging. Also expert systems lacked what Douglas Hofstadter called "the more subtle things that constitute human intelligence such as intuition."
3

Sometimes we know

things, but can't really explain exactly why we know it. We often make decisions on this type of intuition. Since engineers didn't have any defined rules for how intuition worked, they couldn't program intuition into computers.

Also lacking in expert systems was the ability to learn from its mistakes. If a human expert came to an incorrect conclusion, she would be able to understand and learn from her mistake in order to avoid making the same or similar mistakes in the future. An expert system, however, could not learn from its mistakes and would not be able to avoid making the same mistake in the future. Once an expert system was found to have an error, the only way to fix that error was to have it reprogrammed by an engineer. 2. EXPERT SYSTEM COMPONENTS: The part of the expert system that stores the knowledge is called the knowledge base. The part that holds the specifics of the to-be-solved problem is (somewhat misleadingly) called the global database (a kind of "scratch pad"). The part that applies the knowledge to the problem is called the inference engine.

12

As is the case with most contemporary computer programs, expert systems typically have friendly user interfaces. A friendly interface doesn't make the system's internals work any more smoothly, but it does enable inexperienced users to specify problems for the system to solve and to understand the system's conclusions. 3. BUILDING AN EXPERT SYSTEM: Expert systems are the end-products of knowledge engineers. To build an expert system that solves problems in a given domain, a knowledge engineer starts by reading domain-related literature to become familiar with the issues and the terminology. With that as a foundation, the knowledge engineer then holds extensive interviews with one or more domain experts to "acquire" their knowledge. Finally, the knowledge engineer organizes the results of these interviews and translates them into software that a computer can use. The interviews take the most time and effort of any of these stages. They often stall system development. For this reason, developers use the term knowledge acquisition bottleneck to characterize this phase. Anyway, expert systems are meant to solve real problems which normally would require a specialized human expert (such as a doctor or a mineralogist). Building an expert system therefore first involves extracting the relevant knowledge from the human expert. Such knowledge is often heuristic in nature, based on useful ``rules of thumb'' rather than absolute certainties. Extracting it from the expert in a way that can be used by a computer is generally a difficult task, requiring its own expertise. 13

A knowledge engineer has the job of extracting this knowledge and building the expert system knowledge base.

The core components of expert system are the knowledge base and inference engine. 1. Knowledge base: A store of factual and heuristic knowledge. An ES tool provides one or more knowledge representation schemes for expressing knowledge about the application domain. Some tools use both frames (objects) and IF-THEN rules. In PROLOG the knowledge is represented as logical statements. 2. Inference engine: Inference mechanisms for manipulating the symbolic information and knowledge in the knowledge base to form a line of reasoning in solving a problem. The inference mechanism can range from simple modus ponens backward chaining of IF-THEN rules to case-based reasoning.

14

3. Knowledge acquisition subsystem: A subsystem to help experts build knowledge bases. Collecting knowledge needed to solve problems and build the knowledge base continues to be the biggest bottleneck in building expert systems. 4. Explanation subsystem: A subsystem that explains the system's actions. The explanation can range from how the final or intermediate solutions were arrived at to justifying the need for additional data. 5. User interface: The means of communication with the user. The user interface is generally not a part of the ES technology, and was not given much attention in the past. However, it is now widely accepted that the user interface can make a critical difference in the perceived utility of a system regardless of the system's performance. A first attempt at building an expert system is unlikely to be very successful. This is partly because the expert generally finds it very difficult to express exactly what knowledge and rules they use to solve a problem. Knowledge acquisition for expert systems is a big area of research, with a wide variety of techniques developed. However, generally it is important to develop an initial prototype based on information extracted by interviewing the expert, then iteratively refine it based on feedback both from the expert and from potential users of the expert system. In order to do such iterative development from a prototype it is important that the expert system is written in a way that it can easily be inspected and modified. The system should be able to explain its reasoning (to expert, user and knowledge engineer) and answer questions about the

15

solution process. Updating the system shouldn't involve rewriting a whole lot of code - just adding or deleting localized chunks of knowledge. The most widely used knowledge representation scheme for expert systems is rules (sometimes in combination with frame systems). Typically, the rules won't have certain conclusions - there will just be some degree of certainty that the conclusion will hold if the conditions hold. Statistical techniques are used to determine these certainties. Rule-based systems, with or without certainties, are generally easily modifiable and make it easy to provide reasonably helpful traces of the system's reasoning. These traces can be used in providing explanations of what it is doing. Expert systems have been used to solve a wide range of problems in domains such as medicine, mathematics, engineering, geology, computer science, business, law, defense and education. Within each domain, they have been used to solve problems of different types. Types of problem involve diagnosis (e.g., of a system fault, disease or student error); design (of a computer systems, hotel etc); and interpretation (of, for example, geological data). The appropriate problem solving technique tends to depend more on the problem type than on the domain. 4. REPRESENTING THE KNOWLEDGE: The format that a knowledge engineer uses to capture the knowledge is called a knowledge representation. The most popular knowledge representation is the production rule (also called the if-then rule). Production rules are intended to reflect the "rules of thumb" that experts use in their day-

16

to-day work. These rules of thumb are also referred to as heuristics. A knowledge base that consists of rules is sometimes called a rule base. To clarify things a bit, imagine that we have set out to build an expert system that helps us with household repairs. Toward this end, we have held lengthy interviews with an experienced plumber. Here are two if-then rules that the plumber has told us. (Bear in mind that a working expert system can contain tens of thousands of rules.)

Rule 1: If you have a leaky faucet And If the faucet is a compression faucet And If the leak is in the handle

17

Then tighten the packing nut. Rule 2: If you've tightened the packing nut And If the leak persists Then replace the packing. (A compression faucet has two handles, one for hot water, and the other for cold. The "packing" and the "packing nut" are two items that sit under a faucet handle.) In each rule, the lines that specify the problem situation (the lines That begin with "if" and "and") are called the antecedent of the rule. The line that specifies the action to take in that situation (the line that begins with "then") is called the consequent. 5. WORKING WITH THE KNOWLEDGE: In the two rules in the preceding section, note that the consequent of Rule 1 appears (slightly changed) in the first line of the antecedent of Rule 2. This kind of inter-rule connection is crucial to expert system operation. An inference engine uses one of two strategies to examine interconnected rules. In one strategy, the inference engine starts with a possible solution and tries to gather information that verifies this solution. Faced with a leaky faucet (and knowing our two rules), an inference engine that follows this strategy would try to prove that the packing should be replaced. In order to do this, the

18

inference engine looks first at Rule 2 (because its consequent contains the conclusion that the inference engine is trying to prove), then at Rule 1 (because its consequent matches a statement from Rule 2's antecedent). This process is called backward chaining. When the inference engine needs information about the problem that isn't in the knowledge base, the system questions the user (the questionanswer type of interaction typifies backward-chaining systems). The user's answers become part of the problem specification in the global database. Because backward chaining starts with a goal (the solution it tries to verify), it is said to be goal-driven. In the other strategy, the user begins by entering all the specifics of a problem into the system, which the system stores in its global database. After this, the system usually does not question the user further. The inference engine inspects the problem specifications and then looks for a sequence of rules that will help it form a conclusion. In our leaky faucet example, the system user might specify the problem as a leaky compression faucet with a leak in the handle. The inference engine examines Rule 1 (because its antecedent matches the specifics of the problem), and then Rule 2 (because its antecedent contains a statement from Rule 1's consequent). In our example, Rule 2's consequent is the conclusion. This process is called forward chaining. Because this process starts with data (specification of a problem), it is said to be data-driven. 6. DEVELOPMENT TOOLS:

19

One of the first expert system development tools was a by-product of one of the first expert systems. In the 1970s, Stanford researchers developed a system called MYCIN. MYCIN contains a multitude of rules (coded in the computer language LISP) that represent medical knowledge and enable the system to perform medical diagnoses. MYCIN's developers reasoned that removing the medical diagnosis rules should not affect the workings of the system's inference engine and global database. With the medical knowledge gone (resulting in a system they named EMYCIN-"E" for "empty"), they also reasoned that they could insert knowledge from other domains into the knowledge base and thus build a fully functioning expert system. Because they were right on both counts, the expert system shell was born. An expert system shell contains pre-coded expert system components (including backward chaining, forward chaining, or both). The knowledge engineer just adds the knowledge. Mycin was one of the earliest expert systems, and its design has strongly influenced the design of commercial expert systems and expert system shells. Its job was to diagnose and recommend treatment for certain blood infections. To do the diagnosis ``properly'' involves growing cultures of the infecting organism. Unfortunately this takes around 48 hours, and if doctors waited until this was complete their patient might be dead! So, doctors have to come up with quick guesses about likely problems from the available data, and use these guesses to provide a ``covering'' treatment where drugs are given which should deal with any possible problem.

20

Mycin was developed partly in order to explore how human experts make these rough (but important) guesses based on partial information. However, the problem is also a potentially important one in practical terms there are lots of junior or non-specialized doctors who sometimes have to make such a rough diagnosis, and if there is an expert tool available to help them then this might allow more effective treatment to be given. In fact, Mycin was never actually used in practice. This wasn't because of any weakness in its performance - in tests it outperformed members of the Stanford medical school. It was as much because of ethical and legal issues related to the use of computers in medicine - if it gives the wrong diagnosis, who do you sue?? Anyway Mycin represented its knowledge as a set of IF-THEN rules with certainty factors. The following is an English version of one of Mycin's rules: IF AND the the site of infection the culture is is one pimary-bacteremia of the sterile sites

AND the suspected portal of entry is the gastrointestinal tract THEN there is suggestive evidence (0.7) that infection is bacteria. The 0.7 is roughly the certainty that the conclusion will be true given the evidence. If the evidence is uncertain the certainties of the bits of evidence will be combined with the certainty of the rule to give the certainty of the conclusion. Mycin was written in Lisp, and its rules are formally represented as Lisp expressions. The action part of the rule could just be a conclusion about the problem being solved, or it could be an arbitrary lisp expression. This 21

allowed

great

flexibility

, but removed some of the modularity and clarity of rule-based systems, so using the facility had to be used with care. Anyway, Mycin is a (primarily) goal-directed system, using the basic backward chaining reasoning strategy that we described above. However, Mycin used various heuristics to control the search for a solution (or proof of some hypothesis). These were needed both to make the reasoning efficient and to prevent the user being asked too many unnecessary questions. One strategy is to first ask the user a number of more or less preset questions that are always required and which allow the system to rule out totally unlikely diagnoses. Once these questions have been asked the system can then focus on particular, more specific possible blood disorders, and go into full backward chaining mode to try and prove each one. These rules out allot of unnecessary search, and also follow the pattern of human patientdoctor interviews. The other strategies relate to the way in which rules are invoked. The first one is simple: given a possible rule to use, Macon first checks all the premises of the rule to see if any are known to be false. If so there's not much point using the rule. The other strategies relate more to the certainty factors. Macon will first look at rules that have more certain conclusions, and will abandon a search once the certainties involved get below 0.2. A dialogue with Macon is longer and somewhat more complex. There are three main stages to the dialogue. In the first stage, initial data about the case is gathered so the system can come up with a very broad diagnosis. In the 22

second more directed questions are asked to test specific hypotheses. At the end of this section a diagnosis is proposed. In the third section questions are asked to determine an appropriate treatment, given the diagnosis and facts about the patient. This obviously concludes with a treatment

recommendation. At any stage the user can ask why a question was asked or how a conclusion was reached, and when treatment is recommended the user can ask for alternative treatments if the first is not viewed as satisfactory. Macon, though pioneering much expert system research, also had a number of problems which were remedied in later, more sophisticated architectures. One of these was that the rules often mixed domain knowledge, problem solving knowledge and ``screening conditions'' (conditions to avoid asking the user silly or awkward questions - e.g., checking patient is not child before asking about alcoholism). A later version called NEOMYCIN attempted to deal with these by having an explicit disease taxonomy to represent facts about different kinds of diseases. The basic problem solving strategy was to go down the disease tree, from general classes of diseases to very specific ones, gathering information to differentiate between two disease subclasses (i.e., if disease1 has subtypes disease2 and disease3, and you know that the patient has the disease1, and subtype disease2 has symptom1 but not disease3, then ask about symptom1.) There were many other developments from the MYCIN project. For example, EMYCIN was really the first expert shell developed from Macon. A new expert system called PUFF was developed using EMYCIN in the new domain of heart disorders. And system called NEOMYCIN was developed for

23

training doctors, which would take them through various example cases, checking their conclusions and explaining where they went wrong. 7. CONCEPTS IN KNOWLEDGE ACQUISITION: 7.1 DEFINITION: Knowledge acquisition is the process of adding a new knowledge to a Knowledge Base and refining or otherwise improving knowledge that was previously acquired. Acquisition is usually associated with some purpose such as expanding the capabilities of a system or improving its performance at some specified task. Acquired knowledge may consist of facts, rules, concepts, procedures, heuristics information. Sources of this knowledge may include one of the following: 1. Experts in domain of interest 2. Text books 3. Technical papers 4. Data Bases 5. Reports 6. The environments "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

24

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 & Leant, 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:

The knowledge engineer interviews the expert to elicit his or her knowledge;

The knowledge engineer encodes the elicited knowledge for the knowledge base;

The shell uses the knowledge base to make inferences about particular cases specified by clients;

The clients use the shell's inferences to obtain advice about particular cases. 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. Many such tools are designed to be used directly by the expert with the minimum of

25

intervention by the knowledge engineer, and emphasize facilities for visualizing the domain concepts.

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:

Advising the experts on the process of interactive knowledge elicitation; Managing the interactive knowledge acquisition tools, setting them up appropriately;

Editing the unencoded knowledge base in collaboration with the experts;

Managing

the

knowledge

encoding

tools,

setting

them

up

appropriately;

Editing the encoded knowledge base in collaboration with the experts; Validating the application of the knowledge base in collaboration with the experts;

26

Setting up the user interface in collaboration with the experts and clients;

Training the clients in the effective use of the knowledge base in collaboration with the expert by developing operational and training procedures.

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:

Directly elicit knowledge from the expert; Use the interactive elicitation tools to enter knowledge into the knowledge base.

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

27

elicitation from multiple experts is itself a valuable knowledge elicitation technique 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. 7.2 TYPES OF LEARNING: One can develop learning classifications based on the type of knowledge representation used (predicate calculus, rules, frames), the type of knowledge learned (concepts, game playing, problem solving), or by the area of application (medical diagnosis, scheduling, prediction and so on). The classification is independent of the knowledge domain and the representation scheme used. It is based on type of inference strategy employed or the methods used in the learning process. There are five different methods; 1. Memorization 2. Direct Instruction 3. Analogy 4. Induction 5. Deduction

At first learning by memorization is the simplest form of learning. It requires the least amount of inference and is accomplished by simply

28

copying the knowledge in the same form that it will be used directly into the Knowledge Base. We use this type of learning when we memorize multiplication tables. The second is the Direct Instruction which is slightly more complex form of learning. This type of learning requires more inference than memorization learning since the knowledge must be transformed into an operation form before being integrated into the Knowledge Base. We can use this type of learning when a teacher presents number of facts directly to us in a well organized manner. The third type listed is analogical learning is the process of learning a new concept through the use of similar known concepts. We use this type of learning when solving problems on an exam where previously learned examples serve as a guide or when we learn to drive a truck using our knowledge of car driving. We make frequent use of analogical learning. The fourth type of learning is also one that is used frequently by humans. It is a powerful form of learning which, it also requires more inferring than the first two methods. This form of learning requires the use of inductive inference a form of invalid but useful inference for example, we learn the concept of color or sweet taste after experiencing the sensation associated with several examples of colored objects or sweet foods. The last type of acquisition is Deductive learning. In this from the known facts, new facts or relationships are logically derived. 8. INTELLIGENT EDITORS: Expert Systems some times require hundreds or even thousands of rules to reach acceptable level of performance. 29

An intelligent editors act as an interface between a domain expert and an Expert System. They permit a domain expert to interact directly with the system without the need for an intermediate to code the knowledge. The Expert carries on a dialog with the editors in a restricted subset of English which includes a domain-specific vocabulary. The editor has direct access to the knowledge in the Expert System and knows the structure of that knowledge. Through the editors, an expert can create, modify and delete rules without knowledge of the internal structure of the rules. The editors assists the expert in building and refining a Knowledge Base by recalling rules related to same specific topic, and reviewing and modifying the rules, if necessary, to better feed the experts meaning and intent. When faulty or deficit knowledge is found, the problem can then be corrected. 8.1 Choosing a Problem: Writing an expert system generally involves a great deal of time and money. To avoid costly and embarrassing failures, people have developed a set of guidelines to determine whether a problem is suitable for an expert system solution: 1. The need for a solution must justify the costs involved in development. There must be a realistic assessment of the costs and benefits involved.

30

2. Human expertise is not available in all situations where it is needed . If the ``expert'' knowledge is widely available it is unlikely that it will be worth developing an expert system. However, in areas like oil exploration and medicine there may be rare specialized knowledge which could be cheaply provided by an expert system, as and when required, without having to fly in your friendly (but very highly paid) expert. 3. The problem may be solved using symbolic reasoning techniques . It shouldn't require manual dexterity or physical skill. 4. The problem is well structured and does not require (much) common sense knowledge. Common sense knowledge is notoriously hard to capture and represent. It turns out that highly technical fields are easier to deal with, and tend to involve relatively small amounts of well formalized knowledge. 5. The problem cannot be easily solved using more traditional computing methods. If there's a good algorithmic solution to a problem, you don't want to use an expert system. 6. Cooperative and articulate experts exist . For an expert system project to be successful it is essential that the experts are willing to help, and don't feel that their job is threatened! You also need any management and potential users to be involved and have positive attitudes to the whole thing. 7. The problem is of proper size and scope . Typically you need problems that require highly specialized expertise, but would only take a human expert a short time to solve.

31

8. It should be clear that only a small range of problems are appropriate for expert system technology. However, given a suitable problem, expert systems can bring enormous benefits. Systems have been developed, for example, to help analyze samples collected in oil exploration, and to help configure computer systems. Both these systems are (or were) in active use, saving large amounts of money.

8.2 A Simple Example: This is much better explained through a simple example. Suppose that we have the following rules: 1. IF:engine_getting_petrol AND:engine_turns_over THEN problem_with_spark_plugs 2. IFNOT:engine_turns_over ANDNOT:lights_come_on THEN problem_with_battery 3. IFNOT:engine_turns_over ANDlights_come_on THEN problem_with_starter 4. IF:petrol_in_fuel_tank THEN engine_getting_petrol Our problem is to work out what's wrong with our car given some observable symptoms. There are three possible problems with the car:

32

problem_with_spark_plugs, problem_with_battery, problem_with_starter. We'll assume that we have been provided with no initial facts about the observable symptoms. In the simplest goal-directed system we would try to prove each hypothesized problem (with the car) in turn. First the system would try to prove ``problem_with_spark_plugs''. Rule 1 is potentially useful, so the system would set the new goals of proving ``engine_getting_petrol'' and ``engine_turns_over''. Trying to prove the first of these, rule 4 can be used, with new goal of proving ``petrol_in_fuel_tank'' There are no rules which conclude this (and the system doesn't already know the answer), so the system will ask the user: Is it true that there's petrol in the fuel tank? Let's say that the answer is yes. This answer would be recorded, so that the user doesn't get asked the same question again. Anyway, the system now has proved that the engine is getting petrol, so now wants to find out if the engine turns over. As the system doesn't yet know whether this is the case, and as there are no rules which conclude this, the user will be asked: Is it true that the engine turns over? Lets say this time the answer is no. There are no other rules which can be used to prove ``problem_with_spark_plugs'' so the system will conclude that this is not the solution to the problem, and will consider the next hypothesis: problem_with_battery. It is true that the engine does not turn over (the user

33

has just said that), so all it has to prove is that the lights don't come one. It will ask the user Is it true that the lights come on?

Suppose the answer is no. It has now proved that the problem is with the battery. Some systems might stop there, but usually there might be more than one solution, (e.g., more than one fault with the car), or it will be uncertain which of various solutions is the right one. So usually all hypotheses are considered. It will try to prove problem_with_starter'', but given the existing data (the lights come on) the proof will fail, so the system will conclude that the problem is with the battery. A complete interaction with our very simple system might be: System: User: System: User: System User: Is it true that Is it true that Is it true that there's petrol in the fuel tank?

Yes. the No. the No. lights come on? engine turns over?

System: I conclude that there is a problem with battery.

34

9. Advantages and Disadvantages: 9.1 Advantages of Expert Systems:

Permanence - Expert systems do not forget, but human experts may Reproducibility - Many copies of an expert system can be made, but training new human experts is time-consuming and expensive

If there is a maze of rules (e.g. tax and auditing), then the expert system can "unravel" the maze

Efficiency - can increase throughput and decrease personnel costs

o

Although expert systems are expensive to build and maintain, they are inexpensive to operate

Development and maintenance costs can be spread over many users

The overall cost can be quite reasonable when compared to expensive and scarce human experts

Cost-savings: Wages (elimination of a room full of clerks)

Consistency - With expert systems similar transactions handled in the same way. The system will make comparable recommendations for like Humans are influenced by
o

situations.

recency

effects

(most

recent

information

having

disproportionate impact on judgment)

35

Primacy effects (early information dominates the judgment).

Documentation - An expert system can provide permanent documentation of the decision process

Completeness - An expert system can review all the transactions, a human expert can only review a sample

Timeliness - Fraud and/or errors can be prevented. Information is available sooner for decision making

Breadth - The knowledge of multiple human experts can be combined to give a system more breadth that a single person is likely to achieve

Reduce risk of doing business

o o o

Consistency of decision making Documentation Achieve Expertise

Entry barriers - Expert systems can help a firm create entry barriers for potential competitors

Differentiation - In some cases, an expert system can differentiate a product or can be related to the focus of the firm (XCON)

Computer programs are best in those situations where there is a structure that is noted as previously existing or can be elicited

9.2 Disadvantages of Rule-Based Expert Systems:

Common sense - In addition to a great deal of technical knowledge, human experts have common sense. It is not yet known how to give expert systems common sense.

36

Creativity - Human experts can respond creatively to unusual situations, expert systems cannot.

Learning - Human experts automatically adapt to changing environments; expert systems must be explicitly updated. Case-based reasoning and neural networks are methods that can incorporate learning.

Sensory Experience - Human experts have available to them a wide range of sensory experience; expert systems are currently dependent on symbolic input.

Degradation - Expert systems are not good at recognizing when no answer exists or when the problem is outside their area of expertise.

10. EXPERT SYSTEMS AND ARTIFICIAL INTELLIGENCE: Expert Systems are computer programs that are derived from a branch of computer science research called Artificial Intelligence (AI). AI's scientific goal is to understand intelligence by building computer programs that exhibit intelligent behavior. It is concerned with the concepts and methods of symbolic inference, or reasoning, by a computer, and how the knowledge used to make those inferences will be represented inside the machine. Of course, the term intelligence covers many cognitive skills, including the ability to solve problems, learn, and understand language; AI addresses all

37

of those. But most progress to date in AI has been made in the area of problem solving -- concepts and methods for building programs that reason about problems rather than calculate a solution. AI programs that achieve expert-level competence in solving problems in task areas by bringing to bear a body of knowledge about specific tasks are called knowledge-based or expert systems. Often, the term expert systems is reserved for programs whose knowledge base contains the knowledge used by human experts, in contrast to knowledge gathered from textbooks or nonexperts. More often than not, the two terms, expert systems (ES) and knowledge-based systems (KBS) are used synonymously. Taken together, they represent the most widespread type of AI application. The area of human intellectual endeavor to be captured in an expert system is called the task domain. Task refers to some goal-oriented, problem-solving activity. Domain refers to the area within which the task is being performed. Typical tasks are diagnosis, planning, scheduling, configuration and design. Building an expert system is known as knowledge engineering and its practitioners are called knowledge engineers. The knowledge engineer must make sure that the computer has all the knowledge needed to solve a problem. The knowledge engineer must choose one or more forms in which to represent the required knowledge as symbol patterns in the memory of the computer -that is, he (or she) must choose a knowledge representation. He must also ensure that the computer can use the knowledge efficiently by selecting from a handful of reasoning methods. We first describe the components of expert systems.

38

10.1 The Building Blocks of Expert Systems: Every expert system consists of two principal parts: the knowledge base; and the reasoning, or inference, engine.

The knowledge base of expert systems contains both factual and heuristic knowledge. Factual knowledge is that knowledge of the task domain that is widely shared, typically found in textbooks or journals, and commonly agreed upon by those knowledgeable in the particular field. Heuristic knowledge is the less rigorous, more experiential, more judgmental knowledge of performance. It is the knowledge of good practice, good judgment, and plausible reasoning in the field. It is the knowledge that underlies the "art of good guessing." Knowledge representation formalizes and organizes the knowledge. One widely used representation is the production rule, or simply rule. A rule consists of an IF part and a THEN part (also called a condition and an action).

39

The IF part lists a set of conditions in some logical combination. The piece of knowledge represented by the production rule is relevant to the line of reasoning being developed if the IF part of the rule is satisfied; consequently, the THEN part can be concluded, or its problem-solving action taken. Expert systems whose knowledge is represented in rule form are called rule-based systems. Another widely used representation, called the unit (also known as frame, schema, or list structure) is based upon a more passive view of knowledge. The unit is an assemblage of associated symbolic knowledge about an entity to be represented. Typically, a unit consists of a list of properties of the entity and associated values for those properties. Since every task domain consists of many entities that stand in various relations, the properties can also be used to specify relations, and the values of these properties are the names of other units that are linked according to the relations. One unit can also represent knowledge that is a "special case" of another unit, or some units can be "parts of" another unit. The problem-solving model, or paradigm, organizes and controls the steps taken to solve the problem. One common but powerful paradigm involves chaining of IF-THEN rules to form a line of reasoning. If the chaining starts from a set of conditions and moves toward some conclusion, the method is called forward chaining. If the conclusion is known (for example, a goal to be achieved) but the path to that conclusion is not known, then reasoning backwards is called for, backward chaining. These problem-solving methods are built into program modules called inference engines or inference procedures that manipulate and use knowledge in the knowledge base to form a line of reasoning.

40

The knowledge base an expert uses is what he learned at school, from colleagues, and from years of experience. Presumably the more experience he has, the larger his store of knowledge. Knowledge allows him to interpret the information in his databases to advantage in diagnosis, design, and analysis. Though an expert system consists primarily of a knowledge base and an inference engine, a couple of other features are worth mentioning: reasoning with uncertainty, and explanation of the line of reasoning. Knowledge is almost always incomplete and uncertain. To deal with uncertain knowledge, a rule may have associated with it a confidence factor or a weight. The set of methods for using uncertain knowledge in combination with uncertain data in the reasoning process is called reasoning with uncertainty. An important subclass of methods for reasoning with uncertainty is called "fuzzy logic," and the systems that use them are known as "fuzzy systems." Because an expert system uses uncertain or heuristic knowledge. When an answer to a problem is questionable, we tend to want to know the rationale. If the rationale seems plausible, we tend to believe the answer. So it is with expert systems. Most expert systems have the ability to answer questions of the form: "Why is the answer X?" Explanations can be generated by tracing the line of reasoning used by the inference engine. The most important ingredient in any expert system is knowledge. The power of expert systems resides in the specific, high-quality knowledge they contain about task domains. AI researchers will continue to explore and add to the current repertoire of knowledge representation and reasoning methods. But in

41

knowledge resides the power. Because of the importance of knowledge in expert systems and because the current knowledge acquisition method is slow and tedious, much of the future of expert systems depends on breaking the knowledge acquisition bottleneck and in codifying and representing a large knowledge infrastructure. 10.2 Knowledge engineering: It is the art of designing and building expert systems, and knowledge engineers are its practitioners. We stated earlier that knowledge engineering is an applied part of the science of artificial intelligence which, in turn, is a part of computer science. Theoretically, then, a knowledge engineer is a computer scientist who knows how to design and implement programs that incorporate artificial intelligence techniques. The nature of knowledge engineering is changing, however, and a new breed of knowledge engineers is emerging. We'll discuss the evolving nature of knowledge engineering later.

42

Today there are two ways to build an expert system. They can be built from scratch, or built using a piece of development software known as a "tool" or a "shell." Before we discuss these tools, let's briefly discuss what knowledge engineers do. Though different styles and methods of knowledge engineering exist, the basic approach is the same: a knowledge engineer interviews and observes a human expert or a group of experts and learns what the experts know, and how they reason with their knowledge. The engineer then translates the knowledge into a computer-usable language, and designs an inference engine, a reasoning structure, that uses the knowledge

appropriately. He also determines how to integrate the use of uncertain knowledge in the reasoning process, and what kinds of explanation would be useful to the end user. Next, the inference engine and facilities for representing knowledge and for explaining are programmed, and the domain knowledge is entered into the program piece by piece. The discovery and cumulation of techniques of machine reasoning and knowledge representation is generally the work of artificial intelligence research. The discovery and cumulation of knowledge of a task domain is the province of domain experts. Domain knowledge consists of both formal, textbook knowledge, and experiential knowledge -- the expertise of the experts. 10.3 Tools, Shells, and Skeletons: Compared to the wide variation in domain knowledge, only a small number of AI methods are known that are useful in expert systems. That is, currently there are only a handful of ways in which to represent knowledge, or

43

to make inferences, or to generate explanations. Thus, systems can be built that contain these useful methods without any domain-specific knowledge. Such systems are known as skeletal systems, shells, or simply AI tools. Building expert systems by using shells offers significant advantages. A system can be built to perform a unique task by entering into a shell all the necessary knowledge about a task domain. The inference engine that applies the knowledge to the task at hand is built into the shell. If the program is not very complicated and if an expert has had some training in the use of a shell, the expert can enter the knowledge himself. Many commercial shells are available today, ranging in size from shells on PCs, to shells on workstations, to shells on large mainframe computers. They range in price from hundreds to tens of thousands of dollars, and range in complexity from simple, forward-chained, rule-based systems requiring two days of training to those so complex that only highly trained knowledge engineers can use them to advantage. They range from general-purpose shells to shells custom-tailored to a class of tasks, such as financial planning or realtime process control. Although shells simplify programming, in general they don't help with knowledge acquisition. Knowledge acquisition refers to the task of endowing expert systems with knowledge, a task currently performed by knowledge engineers. The choice of reasoning method, or a shell, is important, but it isn't as important as the accumulation of high-quality knowledge. The power of an expert system lies in its store of knowledge about the task domain -- the more knowledge a system is given, the more competent it becomes.

44

11. APPLICATION OF EXPERT SYSTEM: 1. Different types of medical diagnosis.

2. Identification of chemical component structure. 3. Diagnosis of complex electronic and electro-mechanical. 4. Diagnosis of software development projects. 5. Forecasting crop damage. 6. Numerous applications related to space planning and exploration. 7. The design of very large scale integration (VLSI) systems. 8. Numerous military applications, from battle field assessment to ocean surveillance. 9. Teaching students specialized tasks. 10. Location of faults in computers and communication systems. 12. IMPORTANCE OF EXPERT SYSTEM: A good example which illustrate the example of expert system is the diagnostic system developed by the Compbell Soup Company. Compbell Soup uses large sterilizers or cookers to cook soups and other canned products at the eight plants located throughout the country. Some of the larger cookers hold up to 68000 cans of food for short periods of cooking time. When difficult maintenance problems occur with the cookers, the fault must be found and corrected quickly or the batch of the foods being prepared will spoil. The company was dependent on a single expert to diagnose and cure the more difficult problems occurred. Since this individual expert will retire in a few years taking his expertise with him. The company decided to develop an expert system to diagnose these difficult problems. After some months of development with assistance from Texas Instruments, the company developed expert systems 45

which ran on a PC. The system has about 150 rules in its knowledge base with which to diagnose more complex cooker problems. The system has also been used to provide training to the new maintenance personnel. Cloning multiples copies for each of the eight locations cost the company only a few pennies per copy. Further mote system cannot retire and its performance continued. It has proven to be a real asset to the company.

14. CONCLUSION: One is to use expert systems as the foundation of training devices that act like human teachers, instead of like the sophisticated page-turners that characterize traditional computer-aided instruction. The idea is to combine one expert system that provides domain knowledge with another expert system that has the know-how to present the domain knowledge in a learnable way. The system could then vary its presentation style to fit the needs of the individual learner. While this concept is not new, today's powerful PCs are starting to put such trainers, called ICAI (Intelligent Computer Assisted Instruction) systems, within everybody's reach. Tomorrow's shells will routinely allow developers to embed inference engines into other kinds of programs. Embeddable inference engines set up a number of fascinating potential breakthroughs. Will word processors become so intelligent that they grasp the gist of what we want to write and then write it better than we can? Will 46

databases comprehend the information we need, help us find it, and then suggest a search for supplementary information? Will smart spreadsheets tell us the kinds of models we should use in our projections and then build them for us? The possibilities are limited only by the knowledge bases and inference engines that reside in our heads.

47