EXPERT SYSTEM
An expert system is software that attempts to provide an answer to a problem, or clarify uncertainties where normally one or more human experts would need to be consulted. Expert systems are most common in a specific problem domain, and is a traditional application and/or subfield of artificial intelligence. A wide variety of methods can be used to simulate the performance of the expert however common to most or all are 1) the creation of a so-called "knowledgebase" which uses some knowledge representation formalism to capture the Subject Matter Expert's (SME) knowledge and 2) a process of gathering that knowledge from the SME and codifying it according to the formalism, which is called knowledge engineering. Expert systems may or may not have learning components but a third common element is that once the system is developed it is proven by being placed in the same real world problem solving situation as the human SME, typically as an aid to human workers or a supplement to some information system.
As a premiere application of computing and artificial intelligence, the topic of expert systems has many points of contact with general systems theory, operations research, business process reengineering and various topics in applied mathematics and management science.
ADVANTAGES AND DISADVANTAGES
Advantages:
* Provides consistent answers for repetitive decisions, processes and tasks
* Holds and maintains significant levels of information
* Encourages organizations to clarify the logic of their decision-making
* Never "forgets" to ask a question, as a human might
* Can work round the clock
* Can be used by the user more frequently
* A multi-user expert system can serve more users at a time
Disadvantages:
* Lacks common sense needed in some decision making
* Cannot make creative responses as human expert would in unusual circumstances
* Domain experts not always able to explain their logic and reasoning
* Errors may occur in the knowledge base, and lead to wrong decisions
* Cannot adapt to changing environments, unless knowledge base is changed
Types of problems solved by expert systems
Expert systems are most valuable to organizations that have a high-level of know-how experience and expertise that cannot be easily transferred to other members. They are designed to carry the intelligence and information found in the intellect of experts and provide this knowledge to other members of the organization for problem-solving purposes.
Typically, the problems to be solved are of the sort that would normally be tackled by a medical or other professional. Real experts in the problem domain (which will typically be very narrow, for instance "diagnosing skin conditions in human teenagers") are asked to provide "rules of thumb" on how they evaluate the problems, either explicitly with the aid of experienced systems 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. Generally, expert systems are used for problems for which there is no single "correct" solution which can be encoded in a conventional algorithm — one would not write an expert system to find shortest paths through graphs, or sort data, as there are simply easier ways to do these tasks.
Simple systems use simple true/false logic to evaluate data. 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.
Expert systems versus 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; no problem-specific information is encoded in the program structure. This organization has several benefits.
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.
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 and supplies the knowledge base providing the domain expertise, and a knowledge engineer who assists the experts in determining the representation of their knowledge, enters this knowledge into an explanation module and who defines the inference technique required to obtain useful problem solving activity. Usually, the knowledge engineer will represent the problem solving activity in the form of rules which is referred to as a rule-based expert system. When these rules are created from the domain expertise, the knowledge base stores the rules of the expert system.
RULE BASED EXPERT SYSTEMS
A rule-based expert system is an expert system (see intro) which works as a production system in which rules encode expert knowledge.
Most expert systems are rule-based. Alternatives are
frame-based - knowledge is associated with the objects of interest and reasoning consists of confirming expectations for slot values. Such systems often include rules too.
model-based, where the entire system models the real world, and this deep knowledge is used to e.g. diagnose equipment malfunctions, by comparing model predicted outcomes with actual observed outcomes
case-based - previous examples (cases) of the task and its solution are stored. To solve a new problem the closest matching case is retrieved, and its solution or an adaptation of it is proposed as the solution to the new problem.
Typical Expert System Architecture(from Luger and Stubblefield)
Data-driven Rule-based Expert Systems
Use Forward Chaining:
Given a certain set of facts in WM, use the rules to generate new facts until the desired goal is reached.
To forward chain the inference engine must:
1. Match the condition patterns of rules against facts in working memory.
2. If there is more than one rule that could be used (that could "fire"), select which one to apply (this is called conflict resolution)
3. Apply the rule, maybe causing new facts to be added to working memory
4. Halt when some useful (or goal) conclusion is added to WM (or until all possible conclusions have been drawn.)
Goal-driven Rule-based Expert Systems
Use Backward Chaining:
Work backwards from a hypothesised goal, attempting to prove it by linking the goal to the initial facts.
To backward chain from a goal in WM the inference engine must:
1. Select rules with conclusions matching the goal.
2. Replace the goal by the rule's premises. These become sub-goals.
3. Work backwards till all sub-goals are known to be true -
either they are facts (in WM)
or the user provides the information.
Example
A production system IDENTIFIER, which identifies animals.
R1 IF the animal has hair
THEN it is a mammal
R2 IF the animal gives milk
THEN it is a mammal
R3 IF the animal has feathers
THEN it is a bird
R4 IF the animal flies
the animal lays eggs
THEN it is a bird
R5 IF the animal is a mammal
the animal eats meat
THEN it is a carnivore
R6 IF the animal is a mammal
the animal has pointed teeth
the animal has claws
the animal's eyes point forward
THEN it is a carnivore
R7 IF the animal is a mammal
the animal has hooves
THEN it is an ungulate
R8 IF the animal is a mammal
the animal chews cud
THEN it is an ungulate AND
it is even-toed
R9 IF the animal is a carnivore
the animal has a tawny colour
the animal has dark spots
THEN it is a cheetah
R10 IF the animal is a carnivore
the animal has a tawny colour
the animal has black stripes
THEN it is a tiger
R11 IF the animal is an ungulate
the animal has long legs
the animal has a long neck
THEN it is a giraffe
R12 IF the animal is an ungulate
the animal has a white colour
the animal has black stripes
THEN it is a zebra
R13 IF the animal is a bird
the animal does not fly
the animal has long legs
the animal has a long neck
the animal is black and white
THEN it is an ostrich
R14 IF the animal is a bird
the animal does not fly
the animal swims
the animal is black and white
THEN it is a penguin
R15 IF the animal is a bird
the animal is a good flier
THEN it is an albatross
PROBLEM:
Given these facts in working memory initially:
the animal gives milk
the animal chews its cud
the animal has long legs
the animal has a long neck
Establish by forward chaining that the animal is a giraffe.
Given the facts that:
the animal has hair
the animal has claws
the animal has pointed teeth
the animal's eyes point forward
the animal has a tawny colour
the animal has dark spots
Establish by backward chaining that the animal is a cheetah.
[HINT: start with R9, first subgoal : the animal is a carnivore etc.]
Goal-driven search is suggested if:
A goal or hypothesis is given in the problem statement or can be easily formulated
(theorem-proving, diagnosis hypothesis testing).
There are a large number of rules that match the facts, producing a large number of conclusions - choosing a goal prunes the search space.
Problem data are not given (or easily available) but must be acquired as necessary (e.g. medical tests).
Data-driven search is suggested if:
All or most of the data is given in the problem statement (interpretation problems)
Large number of potential goals but few achievable in a particular problem instance.
It is difficult to formulate a goal or hypothesis.
Data-driven search can appear aimless but produces all solutions to a problem (if desired)
Mixed reasoning is also possible - facts get added to the WM and sub-goals get created until all the sub-goals are present as facts.
Explanation Facility in Expert Systems
Rule-based systems can be designed to answer questions like
WHY do you want to know this fact ? (i.e. where is the reasoning going?)
HOW did you deduce this fact ? (i.e. how did we get here?)
Explanation facilities are useful for debugging a rulebase but also for instilling confidence in users of the ES.
A tracer module records the rules that have been used. To answer HOW questions these rules are searched for one where the fact in question is a consequent (action/then part).
(see MYCIN case study)
The production system architecture provides the essential basis for explanation facility, and the facility contributes to the success and popularity of rule-based ES.
Handling Uncertainty in Expert Systems
Uncertainty arises from abductive rules, heuristic rules or missing or unreliable data.
ABDUCTION: ES rules are frequently not sound logically, but are abductive. The abductive rule
if the engine does not turn over and
the lights do not come on
then the problem is battery or cables.
is not always right, but would be typical of a car diagnosis system. Its converse, while not so useful is logically sound :
if the problem is battery or cables
then the engine does not turn over and
the lights do not come on
Abductive reasoning is very important in diagnosis - diseases cause symptoms, but we have sympoms and want to work back to the cause.
To reason with uncertainty, we attach confidence measures to facts and to rules. We need mechanisms to combine these measures.
Handling uncertainty in rule-based expert systems
Three situations need to be handled.
(1) If A and B and C then …
If my confidence in A is x and in B is y and in C is z how confident am I about their conjunction (A and B and C)?
(2) If D then E
If my confidence in D is x how confident can I be in E?
(3) If the same fact F is deduced from (two) separate rules with confidences x and y, how confident am I in F?
A. Simple (Conservative) Rules
(1) Confidence in the conjunction is
min (x, y z) a chain is as strong as its weakest link
(2) Confidence in rule conclusion is
x . a a is the rule's attenuation factor
(3) Confidence in the multiply derived fact is
max (x, y) a conclusion is no more certain than the strongest supporting argument.
B. Bayesian Probability Theory Based
Confidence measures are probabilities.
(1) Confidence in conjunction is = x . y . z
(2) Confidence in a rule is based on Bayes theorem
(there should be a summation symbol on the bottom line)
which relates
P(Di|S) the probability of having disease i if you have the symptom S,
to measures of
P(Di) the probability of having disease i in general,
P(S|Di) the probability of having the symptom S if you have disease i, and
P(S|Dk) for all possible diseases Dk, the probability of having symptom S if you have diseases Dk.
(Diseases are hypotheses; symptoms are evidence.)
Difficulties with Bayes' Theorem:
Bayes theorem assumes that relationships between evidence and hypotheses are independent of one another. (e.g. the probability of someone who has flu having a sore throat and the probability of someone who has flu having a temperature, should be independent. But are they ?)
Probabilities should be collected statistically, and kept up to date with all new discoveries about diseases and their symptoms. This is impractical.
Bayes-based probability is not a good way to model uncertainty in medical diagnosis systems.
Nonetheless, doctors feel that they can make informed assessment of their confidence in their heuristic rules.
C. Stanford Certainty Factor Algebra
(See also MYCIN notes.)
CF (H|E) is the certainty factor of hypothesis H given evidence E.
-1 < CF (H|E) < 1
strong evidence strong evidence
against the hypothesis for the hypothesis
(1) Confidence in the conjunction is
min (x, y, z)
(2) Confidence in rule conclusion is
x . CF (R) CF (R) is certainty factor associated with this conclusion of the rule.
(3) Confidence in the multiply derived fact is
x + y - (x * y) if both are positive
x + y + (x * y) if both are negative
? = x + y . otherwise
1 - min (|x|, |y|)
Note: These formulae leave -1 < CF < 1
Combining contradictory rules cancels out the CF
CFs increase montonically as we add evidence
Other theories for handling uncertainty
Zadeh's Fuzzy Sets - a theory of possibility that tries to measure the vagueness of English statements (e.g. "Ann is tall")
Dempster-Schafer Belief Functions
All these theories are numeric which does not seem to be the way humans reason with uncertainty.
Non-monotonic reasoning is a completely different approach which allows you to proceed with the most reasonable assumption based on uncertain information and to change the assumption (and conclusions that have arisen from it) if the assumption becomes unreasonable. (Truth maintenance systems.)
(Monotonic reasoning systems only allow knowledge/info to be added, whereas humans delete information that is found tobe untrue.)
Expert System Shells
An expert system shell is an expert system with an empty knowledge base, i.e.
An inference engine
User interface module
Tracer/explanation module
Knowledge base (rule) editor
Etc.
EXSYS is a shell, KEE, OPS5, KAS, …
EMYCIN is the shell of MYCIN
It is important to start with a shell with a suitable control strategy.
Recent trends are towards shells that include multiple engines, making them more flexible.
Case Study : MYCIN
An example Goal-driven Medical Diagnostic Expert System
(taken from Luger and Stubblefield section 8.4)
Purpose:
Diagnose and recommend treatment for meningitis and bacteremia (more quickly than definitive lab tests).
Explore how human experts reason with missing and incomplete information.
History
mid-late '70s
50 person years
Stanford medical school
Comprehensively evaluated
Never used clinically
Widely documented ("Rule-based expert systems" Buchanan and Shortliffe, Stanford 1984, a collection of publications on MYCIN).
Representation
Facts:
(ident organism-1 klebsiella .25)
there is evidence (.25) that the identity of organism-1 is klebsiella
(sensitive organism-1 penicillin -1.0)
it is known that org-1 is NOT sensitive to penicillin.
Rules: condition-action pairs
Condition is a conjunction (AND) of facts
IF: (AND (same-context infection
primary-bacteremia)
(membf-context site sterilesite)
(same-context portal GI))
THEN: (conclude context-ident bacteroid
tally .7)
If the infection is primary bacteremia and the site of the culture is a sterile one and the suspected portal of entry is GI tract then there is suggestive evidence (.7) that infection is bacteroid.
Consequent (then-part) can
Add facts to database
Write to terminal
Change a value in a fact, or its certainty
Lookup a table
Execute a LISP procedure
Operation:
Routine questions
Specific questions about symptoms
Depth-first goal driven consideration
of each "known" organism
Terminates "depth-search" when certainty measures get too low.
Selection criterion is to maximise certainty - if a rule can prove a goal with certainty 1 then no more rules need be considered.
Goal-driven so that questions appear to be directed - less frustrating, more confidence building for the user.
English-like interaction (see handout).
Answers WHY by printing the rule under consideration.
Exhaustive consideration of possible infections - patient may have more than one.
Uncertainty in MYCIN
If A: stain is gram positive
and B: morphology is coccus
and C: growth conformation is chains
then there is suggestive evidence (0.7) that
H: organism is streptococcus
0.7 is the measure of increase of belief (MB) of H given evidence A and B and C.
MB ranges 0 to 1.
Assigned by subjective judgement usually.
As a guide:
1 if P(H)=1
MB(H|E) = max[P(H|E),P(H)] - P(H) otherwise
max[1,0] - P(H)
Measures of disbelief also allowed. These also range 0 to 1.
1 if P(H)=1
MD(H|E) = min[P(H|E),P(H)] - P(H) otherwise
min[1,0] - P(H)
Note if E and H are independent, E does not change the belief in H:
P(H|E) = P(H), so MB = MD = 0.
MB(H|E) should only be 1 if E logically implies H.
Initially each hypothesis has MB=MD=0.
As evidence is accumulated these are updated.
At the end a certainty factor CF = MB-MD is computed for each hypothesis.
The largest absolute CF values used to determine appropriate therapy. Weakly supported hypotheses |CF| < 2 are ignored.
MYCIN's handling of uncertainty is an ad-hoc method (based on probability). But it seems to work as well as more formal approaches.
