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

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 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 power-based 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 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 We often make

can't really explain exactly why we know it.

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

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

10

Rule 1: If you have a leaky faucet And If the faucet is a compression faucet And If the leak is in the handle Then tighten the packing nut. Rule 2: If you've tightened the packing nut And If the leak persists

11

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

12

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 question-answer type of interaction typifies backwardchaining 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.

13

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

14

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

15

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 of pimary-bacteremia 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 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

16

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 second more directed questions are asked to test specific hypotheses. At the end of this

17

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

18

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

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

20

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 intervention by the knowledge engineer, and emphasize facilities for visualizing the domain concepts.

Figure 1 Basic knowledge engineering

21

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;

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.

22

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

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

24

At first learning by memorization is the simplest form of learning. It requires the least amount of inference and is accomplished by simply 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

25

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.

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

26

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

27

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

28

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: 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''. 29 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 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?

30

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: System: I conclude that there is a problem with battery. Is it true that the lights come Is it true that the engine turns Is it true that there's petrol in the fuel tank? Yes. over? No. on? No.

31

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

o

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

32

recommendations Humans are influenced by

o

for

like

situations.

recency effects (most recent information having a disproportionate impact on judgment)

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)

33

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.

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.

34

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

35

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.

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.

36

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). The IF part lists a set of conditions in

37

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

38

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

39

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

40

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.

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

41

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 to make inferences, or to generate explanations. Thus, systems can be built that contain these useful

42

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, forwardchained, 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 real-time 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

43

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.

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 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. applications related to space planning and

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

44

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

45

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

46

47