Construction of an Expert System: 4 Tools | Artificial Intelligence

The expert system tools are programming systems which simplify the job of constructing an expert system. They range from very high-level programming language to low-level support facilities. We divide expert system tools into four major categories as shown in Fig. 12.12. We will describe these tools and explain briefly how they are used.

Type # 1. Programming Languages:

Most important programming languages used for expert system applications are generally either problem-oriented languages, such as FORTRAN and PASCAL, or symbol-manipulation languages, such as LISP and PROLOG. Problem oriented languages are designed for particular classes of problems; e.g., FORTRAN has convenient features for performing algebraic calculations and is most applicable to scientific, mathematical and statistical problem area.

Symbol-manipulation languages are designed for artificial intelligence applications; e.g., LISP has mechanism for manipulating symbols in the form of list structures. A list is simply a collection of items enclosed by parenthesis, where each item can be either a symbol or another list. List structures are useful building blocks for representing complex concepts.

The most popular and widely used programming language for expert system applications is LISP, although PROLOG has also gained popularity. Symbol- manipulation languages like these are more suitable for work in artificial intelligence, although a few expert systems have been written in problem-oriented languages like FORTRAN and PASCAL.

E.S. are typically written in languages like LISP and PROLOG or even CLIPS (C language Integrated Production System Developed in mid 1980s). The use of these languages in the development of an e.s. simplifies the coding process. The major advantages of these languages as compared to conventional programming languages, is the simplicity of the addition, elimination or substitution of new rules and memory management capabilities.

Some of the distinguishing characteristics of programming languages needed for e.s. development are:

i. Efficient mix of integer and real variables

ii. Good memory-management procedures

iii. Extensive data-manipulation routines

iv. Incremental compilation

v. Tagged memory architecture

vi. Optimization of system’s environment

vii. Efficient search procedures.

Knowledge engineers can tailor LISP programs to their exact needs, if they can only figure out what their exact needs are and which of the many ways of representing and accessing information in these programmes LISP best meets these needs.

Programming languages, like LISP, CLIPs etc. offer the greatest flexibility to the expert-system builder but fail to provide guidance on how to represent knowledge or mechanisms for accessing the knowledge base. On the other hand, knowledge engineering languages, like KAS, offer little flexibility since the system builder must use the control scheme defined by the readymade inference engine. They do, however, provide representation guidelines and readymade inference engines for controlling the use of the knowledge base.

Type # 2. Knowledge Engineering Languages:

A knowledge engineering language is a sophisticated tool for developing expert systems, consisting of an expert system building language integrated into an extensive support environment. A programming language is an artificial language development to acquire knowledge, accept/reject knowledge to control and direct the operation of a computer.

A knowledge engineering language is a type of programming language designed to construct and debug expert system K.E. language provide certain faculties for building expert system; they are flexible than less programming languages with regard to how knowledge can be represented and manipulated. Knowledge engineering languages can be categorized as either skeletal systems or general-purpose systems. AI researchers developed these languages expressly for building expert systems.

A skeletal knowledge engineering language is simply a stripped down expert system-that is, an expert system with its domain-specific knowledge removed (shell), leaving only the inference engine and support facilities. The general-purpose knowledge engineering language can handle many different problem areas such as knowledge extraction, giving inference or making user interface though its use is rather tedious. These languages have a range of generality and flexibility.

The designers of PROSPECTOR stripped it of knowledge about geology to turn it into KAS, a skeletal system for diagnosis and classification. Similarly, the MYCIN system for diagnosing and treating bacterial infections became the skeletal system EMYCIN, and the CASNET consultation system for glaucoma became the skeletal system EXPERT.

Skeletal systems provide structure and built in facilities which make system development easy and fast. But they lack generality and flexibility; they only apply to a restricted class of problems and greatly reduce the expert- system builder’s design options. 

A few knowledge engineering languages are given in the table 12.1 and are discussed in detail below:

a. EMYCIN:

This skeletal knowledge engineering language is essentially MYCIN with the domain knowledge removed as illustrated in Fig. 12.13.

EMYCIN uses a rule-based knowledge representation scheme with a rigid backward chaining control mechanism which limits its application to diagnosis and classification-type problems. However, the system provides sophisticated explanation and knowledge acquisition facilities which clearly speed expert system development.

Emycin is useful K.E. language for diagnostic properties so it has been used to build expert systems in medicine, geology, engineering, agriculture, and other areas. Fig. 12.14 shows some of these EMYCIN applications.

An EMYCIN rule has the form IF antecedent THEN consequent. A context tree organises EMYCIN objects in a simple hierarchy and provides some of the inheritance characteristics of a frame system. EMYCIN associates a certainty value ranging from -1 (false) to +1 (true) with every expression in an antecedent.

The IF portion of a rule is considered to be true if its certainty is greater than some threshold (say 0.2) and false if below some other threshold (say – 0.2). EMYCIN uses special evidence- combining formulas to decide how to combine the certainties in the antecedent and update the certainty of the consequent.

In the Fig. 12.15 is given a simple EMYCIN rule written from SCON, an expert system to advise a structural engineer regarding the use of a structural analysis program called MARC. This program uses mathematical analysis to simulate mechanical behaviour of objects. The actual rules are in the form of premise-action expression (like the one shown at the bottom of the fig.). The EMYCIN stores and executes them in LISP-like code and outputs the English version of each rule.

b. EXPERT:

This skeletal knowledge engineering language uses a rule based knowledge representation scheme and has a limited forward chaining control mechanism which makes it suitable for diagnosis and classification type problems. EXPERT has built-in explanation, knowledge acquisition, and consistency checking facilities to speed system development.

The consistency checking module works by storing a data base of representative examples with known conclusions and using it to test the expert system after the knowledge engineer adds new rules. If a case (example) does not produce correct conclusion EXPERT displays the reasoning for that case so that the knowledge engineer can understand how the new rules led to the unexpected results.

EXPERT has been used to build diagnostic programs in medicine, geology, and other areas. Figure 12.16 shows some of these applications.

Since EXPERT was designed to handle consultation problems in medicine, it structures knowledge to facilitate medical interpretation. Rules in EXPERT distinguish between findings and hypotheses. Findings are observations like a patient’s age or blood pressure, while hypotheses are conclusions inferred from findings or other hypotheses. In EXPERT, findings have the form if finding-name, truth-value), while hypotheses have the form h(hypothesis-name, certainty-interval).

The truth value is t if the finding is true and f if false. The certainty interval represents the confidence the expert has in the hypothesis, for example, h (mtrl, 0.2:1) means conclude hypothesis matrl with a confidence of 0.2 to 1. Confidence values range from -1 (complete denial) to 1 (complete confirmation).

c. OPS5:

This general-purpose knowledge engineering language uses a rule-based representation scheme which works via forward chaining. The system generality supports diverse data representation and control structures within a single program. OPS5 has a powerful pattern-matcher and an efficient interpreter for matching rules against the data but lacks a sophisticated support environment.

It has no built-in explanation or acquisition mechanisms and has only minimal facilities for program editing and debugging. OPS5 is the latest in a succession of similar rule-based languages (for examples, OPS, OPS4) which evolved from work at Carnegie-Mellon University in developing programming languages for modeling human cognition and memory.

OPS5 and the earlier languages in the OPS series have been used for many cognitive psychology, AI, and expert system applications. Figure 12.18 shows some of these applications.

An OPS5 rule has the form antecedent consequent, where the antecedent describes data elements and the consequent specifies the actions to take if the antecedent matches the data base. Data elements in OPS5 are objects described by a set of attribute-value pairs.

They look a bit like LISP expressions, as illustrated below:

The object (for example, WOMAN, JES-Q) comes first followed by the attribute- value pairs. Attributes are marked with a caret (↑) to distinguish them from values. One thing which makes OPS5 (and LISP) so difficult to read is the use of one-word terms which stand for complex concepts.

In the JES example shown above, the OPS5 code literally says- “The mode of the job entry system queue = panic”. Only the programmer would ever know that this means space in the queue is critically low.

MUD is expert system, which assists an engineer in maintaining drilling fluid at installations such is oil rings. It is implemented in the production rule language OPS5 (a forebear of CLIPS). It does this by diagnosing problems with the fluid, based on a description of its properties and suggesting various causes and remedies.

Changes with fluid properties, such as sudden increase in viscosity during drilling, can be caused by a variety of factors, such as high temperature or a prior mix of chemicals. This is done by rules which changes in fluid properties (data abstraction) to possible cause of these changes (solution abstraction).

OPS5 rules can be somewhat verbose and unintelligible. Even worse, the OPS5 language has no provision for displaying English versions of the rules to the user the way EMYCIN does. Despite this OPS5 is one of the most widely used knowledge engineering languages available, and it has been used in many commercial expert system development efforts. Its widespread use is due partly to its execution efficiency and partly to its ready availability.

d. ROISE:

This general-purpose knowledge engineering language combines a rule-based representation scheme with a procedure-oriented language design. Thus ROSIE programs are typically nested procedures and functions, each defined as a set of rules.

ROSIE has a English-like syntax which makes its code quite readable, powerful pattern-matching routines for matching the rule premises against the data, and control over remote jobs via an interface to the local operating system. ROSIE’s support environment includes editing and debugging tools but no built-in explanation or acquisition facilities.

ROSIE has been used to build expert systems in a variety of problem domains, including law, crisis management, and the military. Fig. 12.18 shows some of these ROSIE applications.

ROSIE programs take the form of rule sets, each defined to be either a procedure, a generator, or a predicate. A procedure is like a subroutine: It performs some task and then returns control to the portion of the program which called it. A generator is like a function: It returns a value or set of values.

For example, a generator for determining medical costs would return a specific amount in rupees when given the name of an injured party. A predicate is a function which always returns either true or false, with which we have already become very familiar.

ROSIE’s efficient expressive power and lucid readability speed up the development of expert systems which use complex and detailed rules.

However, a few AI companies now sell commercial versions of knowledge engineering languages. These language lie somewhere between skeletal systems and general-purpose ones; many evolved from skeletal systems through enhancements aimed at increasing usability and generality.

Type # 3. System-Building Aids:

The system-building aids consist of programs which help acquire and represent the domain expert’s knowledge and programs which help design the expert system under construction. These programs address very difficult tasks; many are research tools just beginning to evolve into practical and useful aids, although a few are offered as full-blown commercial systems.

Compared with programming and knowledge engineering languages, relatively few system-building aids have been developed. Those which exist fall into two major categories; design aids and knowledge acquisition aids. The AGE system exemplifies design aids, while TEIRSIAS, MOLE and SALT exemplify knowledge acquisition, TIMM system construction and SEEK knowledge refinement aids.

A few of these are discussed below:

a. AGE:

This software tool helps the knowledge engineer design and build an expert system. AGE provides the user with a set of components which, like building blocks, can be assembled to form portions of an expert system. Each component, a collection of INTERLISP functions, supports an expert system framework, such as forward chaining, backward chaining, or a blackboard architecture.

The term blackboard refers to a central data base used by systems, to coordinate and, control the operation of independent groups of rules called knowledge sources. The knowledge sources communicate by writing messages on the blackboard and reading messages from other knowledge sources.

This architecture was first used in HEARSAY-II, a speech understanding system developed in the mid-1970s, and led to HEARSAY-III, a knowledge engineering language for controlling multiple knowledge sources. Blackboard systems are the foundations of modern user interface architecture.

Knowledge engineers have used AGE to design and build HANNIBAL, an expert system which performs situation assessment by interpreting enemy radio communication data. The system uses information about the location and signal characteristics of the data to identify enemy organisational units and their communications order of battle.

b. MOLE:

This is a knowledge acquisition system for heuristic classification problem, such as diagnosing diseases. In particular, it is used in conjunction with the cover-and- differentiate problem solving method. The expert-system-produced by MOLE accepts input data, comes up with a set of candidate explanations or classifications which cover the data, then uses differentiating knowledge to determine which one is best. The process is iterative, since explanations must themselves be justified, until ultimate causes are ascertained.

MOLE interacts with a domain expert to produce a knowledge base which a system, called MOLE-p (for mole performance) uses to solve problems.

The acquisition proceeds through several steps:

i. Initial knowledge base construction. MOLE asks the expert to list common symptoms or complains which might require diagnosis. For each symptom, MOLE prompts for a list of possible explanations. MOLE then interactively seeks out higher-level explanations until it comes up with a set of ultimate causes. During this process, MOLE builds an influence network similar to the belief network.

Whenever an event has multiple explanations, MOLE tries to determine the conditions under which one explanation is correct. The expert provides covering knowledge, that is, the knowledge that a hypothesised event might be the cause of a certain symptom MOLE then tries to infer anticipatory knowledge, which says that if the hypothesised event does not occur, then the symptom will definitely appear. This knowledge allows the system to rule out certain hypothesis on the basis that specific systems are absent.

ii. Refinement of the knowledge base. MOLE now tries to identify the weakness of the knowledge base. One approach is to find holes and prompt the expert to fill them. It is difficult, in general to know whether a knowledge base is complete, so instead MOLE lets expert watch MOLE-p solving sample problems. Whenever MOLE-p makes an incorrect diagnosis, the expert adds new knowledge.

There are several ways in which MOLE-p can reach the wrong conclusions. It may incorrectly reject a hypothesis because it does not feel that the hypothesis is needed to explain any symptom. It may advance a hypothesis because it is needed to explain some otherwise inexplicable hypothesis. Or it may lack differentiating knowledge for choosing between alternative hypotheses.

For example, a doctor has a patient with symptoms A and B. Further, suppose at symptom A could be caused by events X and Y and that symptom B could be caused by Y and Z. MOLE-p might conclude Y, since it explains both A and B. If the expert indicates that this decision was incorrect, then MOLE will ask which evidence should be used to prefer X and/or Z over Y.

MOLE has been used to build systems which diagnose problems with car engines, problems in steel rolling mills, and inefficiencies in coal-burning power plants. For MOLE to be applicable, coding of knowledge in terms of covering and differentiating should be done before hand. This tool fails in cases such as designing of an elevator system, wherein propose-and-revise type of techniques are used.

The SALT program provides mechanisms for elucidating this type of knowledge from the expert. This system based on propose- and-revise method of problem solving works incrementally. First, the system proposes an extension to the current design.

Then it checks whether the extension violates any global or local constraints. Constraint violations are then fixed, and the process repeats. It turns out that domain experts are good at listing overall design constraints and at providing local constraints on individual parameters, but not so good at explaining how to a arrive at global solutions.

SALT builds dependency-directed network as it converses with the expert. Each node stands for a value of a parameter which must be acquired or generated.

There are three kinds of links:

Contributes_ to

Constraints

Suggested_revision of

Node A contributes to node B if the value at A appears in the computation of the value at B, while node A constraints B if the value A forbids B to take on certain values. Associated with the first type of link are procedures which allow SALT to generate a value for one parameter based on the value of another. The second type of link, constraints, rules out certain parameter values. The third link, suggested- revision-of, points to ways in which a constraint violation can be fixed.

SALT uses the following heuristics in the eliciting process:

i. Every non-input node in the network needs at least one contributes-to link coming into it. If links are missing, the expert is prompted to fill them in.

ii. No contributes-to loops are allowed in the network, without a value for at least one parameter in the loop, it is impossible to compute values for any parameter in that loop. If a loop exists, SALT tries to transform one of the contributes-to links into a constraints.

iii. Constraining links should have suggest-revision-of links associated with them. These include constraints links which are created when dependency loops are broken.

Control knowledge is also important. It is critical that the system proposes extensions and revision which lead towards a design solution. SALT allows the expert to rate revisions in terms of how much trouble they tend to produce.

SALT compiles its dependency network into a set of production rules. An expert can watch the production system solve problems and can override the system’s decision. At that point, the knowledge base can be changed or override can be logged for future inspection.

c. TEIRESIAS:

TEIRESIAS was developed by Davis in the mid-1970s as a vehicle for exploring new ideas in knowledge acquisition and data base maintenance rather than as a tool for building expert systems, at the university of Stanford (USA).

TEIRESIAS acquires knowledge interactively from an expert. If a wrong diagnosis has been made by MYCIN, then TEIRESIAS will lead the expert back through the chain of incorrect reasoning until the expert states where the incorrect reasoning started. While going back through the reasoning chain, TEIRESIAS will also interact with the expert to modify incorrect rules or acquire new rules.

Knowledge about new rules is not immediately put into MYCIN. Instead TEIRSIAS checks to see if the new rule is compatible with similar rules. For example, if the new rules describes how an infection enters the body and other accepted rules have a conditional element stating the portal of entry to the body, then the new rule should also.

If the new rule does not state the portal of entry then TEIRESIAS will query the user about this discrepancy. TEIRESIAS has a rule model pattern of similar rules that it knows and tries to fit the new rule into its rule model. In other words, the rule model is the knowledge which TEIRESIAS has about its knowledge.

TEIRESIAS served as front-end for the MYCIN expert system. A fragment of a TEIRSIAS-MYCIN conversation with a user (a doctor) is given in Fig. 12.19. The program is about a piece of information which it needs in order to continue its reasoning. The doctor wants to know why the program wants the information as also asks how the program arrived at a conclusion which it claims to have reached.

An important premise underlying TEIRESIAS’S approach for explanation is that the behaviour of a program can be explained simply by referring to a trace of the program’s execution such as:

Is the patient’s illness with ORGANISM-I a hospital-acquired infection? ** Why?

[That is, why is it important to determine whether or not the infection with ORGANISM-I was acquired while the patient was hospitalised?]

Type # 4. Tool Support Environment Facilities (Fig. 12.20):

These are simply software packages which come with each tool to make it more user friendly and more efficient.

Environments which can be further categorised into:

(i) Those required during the development t of the expert system programs, such as debugging aids and knowledge base editors.

(ii) Those required to enhance the capabilities of the developed programs, such as input/output facilities and explanation mechanism. Although few expert system tools support all these tools, they all support some of them. These facilities are usually available as part of K.E. language and are designed to work specially with that language.

These are described below:

a. Debugging Aids:

Most programming and knowledge engineering languages contain tracing facilities and break packages. Tracing provides the user with a trace or display of system operation usual by listing the names (or numbers) of all rules fired or showing the names of all subroutines called. A break package lets the user tell the program, in advance, where to stop so the User can stop program execution just before some recurring error and examine the current values in the data base. All expert system tools should have these basic aids.

A few expert system tools incorporate automated testing, a somewhat more exotic debugging aid than trace facilities or break packages. This aid lets the user automatically test a program on a large number of benchmark problems to uncover errors or inconsistencies in the solutions.

b. Knowledge Base Editors:

Most expert system tools provide a mechanism for editing the knowledge base. In the simplest case, this is just a standard text editor for modifying rules and data by hand. But many tools include other facilities in their support environment. For example, EMYCIN uses automatic book-keeping.

The EMYCIN editor monitors the changes made by the user and records pertinent information about the event. If the user adds or changes a rule, the editor automatically stores the modification date and user name with the rule for later reference. Knowledge engineers find this particularly useful when a number of different experts modify or refine the knowledge base.

Another common facility in knowledge base editors is syntax checking, where the editor uses knowledge about the grammatical structure of the expert system language to help the user input rules with the correct spelling and format. When the user enters an ungrammatical rule or command, the editor catches it and explains what is wrong. Correcting mistakes of this sort during editing rather than during system testing can significantly reduce development time.

An extremely useful but generally unavailable facility for knowledge base editors is consistency checking where the system checks the semantics or meanings of the rules and data being entered to see if they conflict with existing knowledge in the system. When a conflict occurs, the editor helps the user resolve the conflict by explaining what caused it and describing ways to remove it.

Initially AI researchers had difficulty with consistency checking, but some research system-building aids (for example, TEIRESIAS) and some commercial system-building aids (for example, TIMM) have addressed the problem. To perform consistency checking in more than just a superficial way, the editor must understand what the various forms of rules and data actually mean.

For example, suppose the knowledge base had in it the fact:

(i) Acid is stored in tank 23, and the user added a new fact which stated:

(ii) Hydraulic oil is stored in tank 23.

The editor would have to know something about the storage of liquids in tanks to realise that since two liquids are seldom stored in the same container at the same time, this new fact conflicts with one already in the knowledge base. Even if the editor recognised the inconsistency, it couldn’t easily correct it.

There are at least three possibilities:

(i) Acid used to be stored in the tank 23 but it was replaced with hydraulic oil.

(ii) The hydraulic oil is actually stored in some other tank, perhaps tank 32 is typographical error.

(iii) An accident occurred, violating normal operating procedures, and somehow both liquids ended up in the tank at the same time.

Since the editor would have difficulty choosing between the alternatives, it would probably have to ask the user for help.

Another potentially useful but generally unavailable facility for knowledge base editors is knowledge extraction where the editor helps the user enter new knowledge into the system. It combines syntax and consistency checking with sophisticated prompting and explanation to let even naive users add or modify rules. A knowledge extraction facility in the editor would shorten system development time and training time for new system users. Some system-building aids(for example, TEIRESIAS, TIMM and EXPERT-EASE) use knowledge extraction mechanisms.

Difference Between Research and Commercial Building Aid:

All the expert system tools, like the expert systems are not developed overnight, the development continues to progress over a period of time. They often start in research environment as an experimental system created for a specific task. The development applies it to that task but seldom tests it on other problems in any exhaustive or systematic way. They are quite slow and rather not quite efficient. The users give feedback to the developer in this stage.

The next stage of development is a research system. This system is extensively tested by the developer, but the system remains to be still slow and inefficient, despite the tiring efforts of the developer.

The final stage of development of tools is of a commercial system. These tools are usually polished, streamlined and well-supported and fast. They have been specifically designed and engineered for meeting the user’s needs and ease to user- machine interaction problem.

The three stages of development are shown in the Fig. 12.21.

When judging whether a shell is suitable or not for an application, a number of factors have to be taken into account, such as handling of uncertainty, reasoning, control, representational power, external connections, KE interface, user interface facilities, and explanation facilities. There are covered in the companion book by author, on expert systems.

c. I/O Facilities:

Different tools deal with input/output in different ways. Some provide run-time knowledge acquisition where mechanisms in the tool itself let the user converse with the running expert system. For example, EMYCIN programs ask the user for needed information whenever they cannot find it in the knowledge base. EXPERT programs not only ask for such information, but also provide menus for the user to select from when inputting the requested information.

They also allow the user to input volunteered information as the expert system runs. Since a knowledge engineer building a system in EMYCIN or EXPERT does not have to write code for runtime knowledge acquisition, system development is easier, but flexibility is reduced. I/O must be handled the way the tool designer decrees. Expert system tools may also handle I/O by providing a set of powerful commands or procedures which make writing I/O routines easy.

For example, ROSIE has special commands which let a ROSIE expert system talk to the local operating system just as if it were a user on the system. This feature of operating system accessibility allows the expert system to monitor and control other jobs while it is running for example, it can run a simulation program written in another language to obtain needed information.

d. Explanation Facilities:

Almost all expert systems can explain to users how they reach particular conclusions, though not all provide the same degree of software support for explanation. Some, like EMYCIN, have a complete explanation mechanism built into the tool itself, so that any expert system written in that language can automatically access the mechanism. Others have no built-in explanation mechanism, thus forcing the knowledge engineer to write one when building the expert system.

The most common type of explanation mechanism deals with retrospective reasoning; it explains how the system reached a particular state. For example, the user may wish to know why the system needed the answer to the question it just asked or how the system arrived at a certain conclusion.

Here the system may describe the rules which led to the question or display part of the chain or sequence of rules that led to the conclusion. Explanation mechanisms may also handle hypothetical reasoning, where the system explains what would have happened differently if a particular fact or rule had been different, and counterfactual reasoning, where the system explains what would have happened differently if a particular fact or rule had been different, and counterfactual reasoning, where the system explains why an expected conclusion was not reached.