Expert Systems
An expert system is a class of computer programs
developed by researchers in artificial
intelligence during the 1970s and applied commercially
throughout the 1980s. In essence, they are programs made
up of a set of rules that analyze information, (usually
supplied by the user of the system), about a specific class
of problems, as well as provide analysis of the problem(s),
and, depending upon their design, a recommended course of
user action in order to implement corrections.
1,Type of problems solved by expert systems
Typically, the problems to be solved are of the sort that
would normally be tackled by a human "expert" - a medical
or other professional, in most cases. Real experts in the
problem domain (which will typically be very narrow, for
instance "diagnosing skin diseases in human teenagers")
are asked to provide "rules of thumb" on how they evaluate
the problems, either explicitly with the aid of experienced
system developers, or sometimes implicitly, by getting such
experts to evaluate test cases and using computer programs
to examine the test data and (in a strictly limited manner)
derive rules from that.
Simple systems use simple true/false logic to evaluate
data, but more sophisticated systems are capable of performing
at least some evaluation taking into account real-world
uncertainties, using such methods as fuzzy logic. Such sophistication
is difficult to develop and still highly imperfect.
2,Application
While expert systems have distinguished themselves in AI
research in finding practical application, their application
has been limited. Expert systems are notoriously narrow
in their domain of knowledge - as an amusing example, a
researcher used the "skin disease" expert system to diagnose
his rustbucket car as likely to have developed measles,
and thus prone to making errors that humans would easily
spot. Additionally, once some of the mystique had worn off,
most programmers realized that simple expert systems were
essentially just slightly more elaborate versions of the
decision logic they had already been using. Therefore, some
of the techniques of expert systems can now be found in
most complex programs without any fuss about them.
3,Expert Systems vs. Problem Solving Systems
The principal distinction between expert systems and traditional
problem solving programs is the way in which the problem
related expertise is coded. In traditional applications,
problem expertise is encoded in both program and data structures.
In the expert system approach all of the problem related
expertise is encoded in data structures only. None is in
programs. Several benefits immediately follow from this
organization.
An example may help contrast the traditional problem solving
program with the expert system approach. The example is
the problem of tax advice. In the traditional approach data
structures describe the taxpayer and tax tables, and a program
in which there are statements representing an expert tax
consultant's knowledge, such as statements which relate
information about the taxpayer to tax table choices. It
is this representation of the tax expert's knowledge that
is difficult for the tax expert to understand or modify.
In the expert system approach, the information about taxpayers
and tax computations is again found in data structures,
but now the knowledge describing the relationships between
them is encoded in data structures as well. The programs
of an expert system are independent of the problem domain
(taxes) and serve to process the data structures without
regard to the nature of the problem area they describe.
For example, there are programs to acquire the described
data values through user interaction, programs to represent
and process special organizations of description, and programs
to process the declarations that represent semantic relationships
within the problem domain and an algorithm to control the
processing sequence and focus.
The general architecture of an expert system involves two
principal components: a problem dependent set of data declarations
called the knowledge base or rule base, and a problem independent
(although highly data structure dependent) program which
is called the inference engine. See more in How it Works
chapter.
4, Individuals Involved with Expert Systems
There are generally three individuals having an interaction
with expert systems. Primary among these is the end-user;
the individual who uses the system for its problem solving
assistance. In the building and maintenance of the system
there are two other roles: the problem domain expert who
builds the knowledge base, and a knowledge engineer who
assists the experts in determining the representation of
their knowledge and who defines the inference technique
required to obtain useful problem solving activity.
The End User
The end-user
usually sees an expert system through an interactive
dialog, an example of which follows:
- Q. Do you know to which restaurant
you want to go?
- A. No
- Q. Is there any kind of food
you would particularly like?
- A. Unknown
- Q. Do you like spicy food?
- A. No
- Q. Do you usually drink wine
with meals?
- A. Yes
- Q. When you drink wine, is it French
wine?
- A. Why
As can be seen from this dialog,
the system is leading the user through a set of questions,
the purpose of which is to determine a suitable set of restaurants
to recommend. This dialog begins with the system asking
if the user already knows the restaurant choice (a common
feature of expert systems) and immediately illustrates a
characteristic of expert systems; users may choose not to
respond to any question. In expert systems, dialogs are
not pre-planned. There is no fixed control
structure. Dialogs are synthesized from the current
information
and the contents
of the knowledge
base. Because of this, not being able to supply the
answer to a particular questions does not stop the consultation.
Another major distinction between expert systems and traditional
systems is illustrated by the following answer given by
the system when the user answers a question
with the question "why",
as occurred in the above example. The answer is:
- A. I am trying to determine the type of restaurant to
suggest. So far Chinese is not a likely choice. It is
possible that French is a likely choice. I know that if
the diner is a
wine drinker,
and the preferred wine
is French, then there is strong evidence
that the restaurant
choice should include French.
It is very difficult to implement a general explanation
system (answering questions like Why
and How) in traditional
systems. The response of the expert system to the question
WHY is an exposure
of the underlying knowledge
structure. It is a rule;
a set of antecedent
conditions which, if true, allow the assertion
of a consequent.
The rule references values, and tests them against various
constraints
or asserts constraints onto them. This, in fact, is a significant
part of the knowledge structure. There are values, which
may be associated with some organizing entity.
For example, the individual diner is an entity with various
attributes (values) including whether they drink wine and
the kind of wine. There are also rules, which associate
the currently known values
of some attributes
with assertions that can be made about other attributes.
It is the orderly processing of these rules that dictates
the dialog itself.
The Knowledge Engineer
The knowledge
engineer is concerned with the representation
chosen for the expert's knowledge declarations and with
the inference
engine used to process that knowledge.
There are several characteristics known to be appropriate
to a good inference
technique.
- 1. A good inference technique is independent of the
problem domain.
-
- In order to realize the benefits of explanation,
knowledge
transparency, and re-usability
of the programs in a new problem domain, the inference
engine must contain domain specific expertise.
- 2. Inference techniques may be specific to a particular
task, such as diagnosis
of hardware
configuration. Other techniques may be committed only
to a particular processing
technique.
- 3. Inference techniques are always specific to the knowledge
structures.
- 4. Successful examples of rule processing techniques
include:
-
- (a) Forward
chaining
-
- (b) Backward
chaining
5,The Inference Rule
An understanding of the "inference
rule" concept is important to understand expert systems.
An inference rule is a statement
that has two parts, an if-clause
and a then-clause.
An example of an inference rule is:
- If the restaurant
choice includes French,
and the occasion
is romantic,
- Then the restaurant choice is definitely Paul
Bocuse.
An expert system's rulebase is made up of many such inference
rules. They are entered as separate rules and it is the
inference engine that uses them together to draw conclusions.
Because each rule is a unit, rules may be deleted or added
without affecting other rules (though it should affect which
conclusions are reached). One advantage of inference rules
over traditional programming is that inference rules use
reasoning which
more closely resemble human reasoning.
Thus, when a conclusion
is drawn, it is possible to understand how this conclusion
was reached. Furthermore, because the expert system uses
knowledge in
a form similar to the expert,
it may be easier to retrieve this information
from the expert.
Chaining
There are two main methods of reasoning
when using inference rules: backward chaining and forward
chaining.
Forward
chaining starts with the data available and uses the
inference rules to conclude more data until a desired goal
is reached. An inference engine using forward chaining searches
the inference rules until it finds one in which the if-clause
is known to be true.
It then concludes the then-clause
and adds this information
to its data. It would
continue to do this until a goal is reached. Because the
data available determines which inference rules are used,
this method is also called `data driven.`
Backward
chaining starts with a list of goals and works backwards
to see if there is data which will allow it to conclude
any of these goals. An inference engine using backward chaining
would search the inference rules until it finds one which
has a then-clause that matches a desired goal. If the if-clause
of that inference rule is not known to be true, then it
is added to the list of goals. For example, suppose a rulebase
contains two rules:
- (1) If Fritz is green then Fritz is a frog.
- (2) If Fritz is a frog then Fritz hops.
Suppose a goal is to conclude that Fritz hops.The rulebase
would be searched and rule (2) would be selected because
its conclusion (the then clause) matches the goal. It is
not known that Fritz is a frog, so this "if" statement is
added to the goal list. The rulebase is again searched and
this time rule (1) is selected because its then clause matches
the new goal just added to the list. This time, the if-clause
(Fritz is green) is known to be true and the goal that Fritz
hops is concluded. Because the list of goals determines
which Rules are selected and used, this method is called
`goal driven.`
6, Confidences
Another advantage of expert systems over traditional methods
of programming is that they allow the use of confidences.
When a human reasons he does not always conclude things
with 100% confidence. He might say, "If Fritz is green,
then he is probably a frog" (after all, he might be a chameleon);
or, that Fritz's leg is broken, but not much). This type
of reasoning
can be imitated by using numeric values called Confidences.
For example, if it is known that Fritz is green, it might
be concluded with 0.85 Confidence that he is a frog; or,
if it is known that he is a frog, it might be concluded
with 0.95 Confidence that he hops. These numbers are similar
in nature to probabilities,
but they are not the same. They are meant to imitate the
Confidences humans use in reasoning rather than to follow
the mathematical definitions used in calculating probabilities.
The following general points about expert systems and
their architecture have been illustrated.
- 1. The sequence of steps taken to reach a conclusion
is dynamically synthesized with each new case. It is not
explicitly programmed when the system is built.
- 2. Expert systems can process multiple values for any
problem parameter. This permits more than one line of
reasoning to be pursued and the results of incomplete
(not fully determined) reasoning to be presented.
- 3. Problem
solving is accomplished by applying specific knowledge
rather than specific technique.
This is a key idea in expert systems technology. It reflects
the belief that human experts do not process their knowledge
differently from others, but they do possess different
knowledge. With this philosophy,
when one finds that their expert system does not produce
the desired results,
work begins to expand the knowledge
base, not to re-program the procedures.
There are various expert systems in which a "rulebase"
and an "inference
engine" cooperate to simulate the reasoning process
that a human expert pursues in analyzing a problem and arriving
at a conclusion. In these systems, in order to simulate
the human reasoning process, a vast amount of knowledge
needed to be stored in the knowledge base. Generally, the
knowledge base of such an expert system consisted of a relatively
large number of "if then" type of statements that were interrelated
in a manner that, in theory at least, resembled the sequence
of mental steps that were involved in the human reasoning
process.
Because of the need for large storage capacities and related
programs to store the Rulebase, most expert systems have,
in the past, been run only on large information handling
systems. Recently, the storage capacity of personal computers
has increased to a point where it is becoming possible to
consider running some types of simple expert systems on
personal
computers.
In some applications
of expert systems, the nature of the application and the
amount of stored information necessary to simulate the human
reasoning process for that application is just too vast
to store in the active memory
of a computer.
In other applications of expert systems, the nature of the
application is such that not all of the information is always
needed in the reasoning process. An example of this latter
type application would be the use of an expert system to
diagnose a data processing system comprising many separate
components, some of which are optional. When that type of
expert system employs a single integrated Rulebase to diagnose
the minimum system configuration of the data processing
system, much of the Rulebase is not required since many
of the components which are optional units of the system
will not be present in the system. Nevertheless, earlier
expert systems require the entire Rulebase to be stored
since all the Rules were, in effect, chained or linked together
by the structure of the Rulebase.
When the Rulebase is segmented, preferably into contextual
segments or units, it is then possible to eliminate portions
of the Rulebase containing data or knowledge that is not
needed in a particular application. The segmenting of the
Rulebase also allows the expert system to be run with systems
or on systems having much smaller memory capacities than
was possible with earlier arrangements since each segment
of the Rulebase can be paged into and out of the system
as needed. The segmenting of the Rulebase into contextual
segments requires that the expert system manage various
intersegment relationships as segments are paged into and
out of memory during execution of the program. Since the
system permits a Rulebase segment to be called and executed
at any time during the processing of the first Rulebase,
provision must be made to store the data that has been accumulated
up to that point so that at some time later in the process,
when the system returns to the first segment, it can proceed
from the last point or RULE node that was processed. Also,
provision must be made so that data that has been collected
by the system up to that point can be passed to the second
segment of the Rulebase after it has been paged into the
system and data collected during the processing of the second
segment can be passed to the first segment when the system
returns to complete processing that segment.
The user interface
and the procedure
interface are two important functions in the information
collection process.
The User Interface
The function of the user
interface is to present questions
and information
to the operator
and supply the operator's responses
to the inference
engine.
Any values entered by the user must be received and interpreted
by the user interface. Some responses are restricted to
a set of possible legal answers, others are not. The user
interface checks all responses to insure that they are of
the correct data type. Any responses that are restricted
to a legal set of answers are compared against these legal
answers. Whenever the user enters an illegal answer, the
user interface informs the user that his answer was invalid
and prompts him to correct it. As explained in the cross"
referenced application, communication between the user interface
and the Inference Engine is performed through the use of
a User Interface Control Block (UICB) which is passed between
the two.
Procedure Node Interface
The function of the Procedure
node interface is to receive information from the Procedures
coordinator and create the appropriate procedure
call. The ability to call a procedure
and receive information from that procedure can be viewed
as simply a generalization
of input from the
external world. While in some earlier expert systems external
information has been obtained, that information was obtained
only in a predetermined manner so only certain information
could actually be acquired. This expert system, disclosed
in the cross-referenced application, through the knowledge
base, is permitted to invoke any Procedure allowed on its
host system. This makes the expert system useful in a much
wider class of knowledge domains than if it had no external
access or only limited external access.
In the area of machine
diagnostics using expert systems, particularly self-diagnostic
applications, it is not possible to conclude the current
state of "health"
of a machine without
some information. The best source of information is the
machine itself, for it contains much detailed information
that could not reasonably be provided by the operator.
The knowledge that is represented in the system appears
in the Rulebase. In the Rulebase described in the cross-referenced
applications, there are basically four different types of
objects, with associated information present.
- 1. Classes--these are questions asked to the user.
- 2. Parameters--a Parameter is a place holder for a character
string which may be a variable that can be inserted into
a Class question at the point in the question where the
Parameter is positioned.
- 3. Procedures--these are definitions of calls to external
Procedures.
- 4. Rule Nodes--The inferencing in the system is done
by a tree structure which indicates the Rules or logic
which mimics human reasoning. The nodes of these trees
are called RULE nodes. There are several different types
of RULE nodes.
The Rulebase comprises a forest
of many trees. The
top node of the tree is called the Goal node, in that it
contains the conclusion. Each tree in the forest has a different
Goal node. The leaves of the tree are also referred to as
RULE nodes, or one of the types of RULE nodes. A leaf may
be an EVIDENCE node, an EXTERNAL node, or a REFERENCE node.
An EVIDENCE node functions to obtain information from
the operator by asking a specific question. In responding
to a question presented by an EVIDENCE node, the operator
is generally instructed to answer "yes" or "no" represented
by numeric values 1 and 0 or provide a value of between
0 and 1, represented by a "maybe."
Questions which require a response from the operator other
than yes or no or a value between 0 and 1 are handled in
a different manner.
A leaf that is an EXTERNAL node indicates that data will
be used which was obtained from a Procedure Call.
A REFERENCE node functions to refer to another tree or
subtree.
A tree may also contain intermediate or minor nodes between
the Goal node and the Leaf node. An intermediate node can
represent logical operations like And or Or.
The inference
logic has two functions. It selects a tree
to trace and then it traces that tree. Once a tree has been
selected, that tree is traced, depth-first, left to right.
The word "tracing" refers to the action the system takes
as it traverses the tree, asking Classes (questions), calling
Procedures, and calculating Confidences as it proceeds.
As explained in the cross-referenced applications, the
selection of a tree depends on the ordering of the trees.
The original ordering of the trees is the order in which
they appear in the Rulebase. This order can be changed,
however, by assigning an EVIDENCE node an attribute "initial"
which is described in detail in these applications. The
first action taken is to obtain values for all EVIDENCE
nodes which have been assigned an "initial" attribute. Using
only the answers to these initial Evidences, the Rules are
ordered so that the most likely to succeed is evaluated
first. The trees can be further re-ordered since they are
constantly being updated as a selected tree is being traced.
It has been found that the type of information that is
solicited by the system from the user by means of questions
or classes should be tailored to the level of knowledge
of the user. In many applications, the group of prospective
uses is nicely defined and the knowledge level can be estimated
so that the questions can be presented at a level which
corresponds generally to the average user. However, in other
applications, knowledge of the specific domain of the expert
system might vary considerably among the group of prospective
users.
One application where this is particularly true involves
the use of an expert system, operating in a self-diagnostic
mode on a personal computer to assist the operator of the
personal computer to diagnose the cause of a fault or error
in either the hardware or software. In general, asking the
operator for information is the most straightforward way
for the expert system to gather information assuming, of
course, that the information is or should be within the
operator's understanding. For example, in diagnosing a personal
computer, the expert system must know the major functional
components of
the system. It could ask the operator, for instance, if
the display is
a monochrome or color display. The operator should, in all
probability, be able to provide the correct answer 100%
of the time. The expert system could, on the other hand,
cause a test unit
to be run to determine the type of display. The accuracy
of the data collected by either approach in this instance
probably would not be that different so the knowledge
engineer could employ either approach without affecting
the accuracy of the diagnosis.
However, in many instances, because of the nature of the
information being solicited, it is better to obtain the
information from the system rather than asking the operator,
because the accuracy
of the data supplied by the operator is so low that the
system could not effectively process it to a meaningful
conclusion.
In many situations the information is already in the system,
in a form of which permits the correct answer
to a question to be obtained through a process of inductive
or deductive reasoning. The data previously collected by
the system could be answers provided by the user to less
complex questions that were asked for a different reason
or results returned from test units that were previously
run.
7, How it works
ES consists of
- knowledge base (facts)
- production rules ("if.., then..")
- inference engine (controls how "if.., then.." rules
are applied towards facts)
Actually there are two methods to make conclusions.
[Nice
& simple tutorial about backward and forward chaining]
8, Prominent expert systems
Other resources
What
Is An Expert System?
This article is licensed under the GNU
Free Documentation License. It uses material from the
Wikipedia.
|
