Expert System Notes
1. System-Building Aids
System-building aids are the tools, methodologies, and environments that help in
creating, testing, and maintaining expert systems. These aids support knowledge
engineers and domain experts in efficiently developing systems.
Types of System-Building Aids:
1. Expert System Shells
o Predefined software environments for building expert systems.
o Provide inference engine and knowledge representation schemes.
o Knowledge engineer only needs to fill in domain-specific rules and
facts.
o Examples: CLIPS, MYCIN Shell, EMYCIN
1a. CLIPS (C Language Integrated Production System)
Developed by NASA in the 1980s.
Rule-based expert system shell.
Uses if-then rules and a working memory (facts).
Example in CLIPS:
(deftemplate patient
(slot name)
(slot symptom))
(defrule diagnose-flu
(patient (symptom fever))
(patient (symptom cough))
(patient (symptom headache))
=>
(printout t "Diagnosis: The patient may have Flu." crlf))
(assert (patient (name Rajesh) (symptom fever)))
(assert (patient (name Rajesh) (symptom cough)))
(assert (patient (name Rajesh) (symptom headache)))
Output:
“Diagnosis: The patient may have Flu.”
1b. MYCIN Shell
Original expert system developed in the 1970s at Stanford.
Designed for diagnosing bacterial infections and recommending antibiotics.
It used a rule-based backward chaining system with certainty factors.
Example Rule in MYCIN:
IF
the infection is primary-bacteremia
AND the site of the culture is one of the sterile sites
AND the suspected portal of entry is the gastrointestinal tract
THEN
there is suggestive evidence (0.7)
that the organism is Bacteroides.
Output:
certainty factor = 0.7 means the system is 70% confident.
1c. EMYCIN (Essential MYCIN)
A general-purpose expert system shell derived from MYCIN.
Same inference engine and certainty factors as MYCIN, but without
medical-specific rules.
Users can define their own rules for other domains (e.g., engineering,
business).
Example in EMYCIN (Non-medical domain – Car Troubleshooting):
IF
the car does-not-start
AND the headlights are-dim
THEN
there is strong evidence (0.9)
that the battery is-dead.
Prolog (PROgramming in
Feature LISP (LISt Processing)
LOGic)
Functional language (with
Logic programming language
Paradigm recursion, symbolic
(rule-based, declarative).
computation).
Developed by John Developed by Alain Colmerauer &
Origin
McCarthy in 1958 at MIT. Robert Kowalski in early 1970s.
Prolog (PROgramming in
Feature LISP (LISt Processing)
LOGic)
Symbolic AI, natural
language processing, Knowledge representation, expert
Primary Use
machine learning, expert systems, theorem proving, NLP.
systems (early).
Based on functions and Based on facts, rules, and
recursive evaluation. queries. Programmer defines what
Execution Style
Programmer defines how to the problem is, Prolog figures out
solve the problem. how to solve.
Knowledge Uses lists, trees, symbolic Uses facts and rules in predicate
Representation expressions (S-expressions). logic (Horn clauses).
Functional style,
Example Syntax Declarative style, logical clauses.
parentheses-heavy.
Evaluation of functions,
Inference Method recursion, symbolic Backward chaining + unification.
computation.
Flexible for symbolic AI,
Natural for expert systems, logic
recursive structures,
Strengths reasoning, pattern matching, query
powerful for mathematical
answering.
computation.
Verbose parentheses, less Slower for numeric computation,
Weaknesses intuitive for rule-based less flexible for general-purpose
reasoning. programming.
🔹 Instead of medicine, EMYCIN can be used for diagnosing machines, legal
advice, etc.
2. Programming Languages
o Languages like LISP and Prolog are commonly used for expert
systems due to their symbolic processing and pattern-matching
abilities.
In LISP (factorial):
(defun factorial (n)
(if (<= n 1)
1
(* n (factorial (- n 1)))))
(print (factorial 5))
Output → 120
In Prolog (factorial):
factorial(0,1).
factorial(N,F) :-
N > 0,
N1 is N-1,
factorial(N1,F1),
F is N * F1.
Query:
?- factorial(5,F).
🔹 Output → F = 120
3. Knowledge Engineering Tools
o Editors, debuggers, consistency checkers, and explanation tools that
help organize and verify rules, facts, and frames.
4. Inference Engines
o Prebuilt reasoning modules (forward chaining, backward chaining,
hybrid reasoning) that can be reused.
5. Knowledge Representation Libraries
o Provide predefined data structures for rules, frames, semantic
networks(i.e. Graph), ontologies(what exist) etc.
6. User Interface Generators
o Help in quickly developing interactive dialogs, forms, or natural
language interfaces for communication with the system.
2. Support Facilities
Support facilities are the extra tools and features that make an expert system more
useful, user-friendly, and reliable.
1. Knowledge Acquisition Facility
What it does: Collects knowledge from domain experts and converts it into
rules/facts for the system.
Example: In a medical expert system, doctors provide information like:
o “If patient has fever and cough → possible flu.”
This is entered into the system using a rule editor or interviews.
2. Explanation Facility
What it does: Explains why the system asks a question or how it reached a
decision.
Example: In a loan approval system, the user asks:
o User: Why do you need my credit score?
o System: Because it affects the risk assessment for loan approval.
Or:
o User: How did you conclude the loan is rejected?
o System: You have low income and poor credit history → loan
rejected.
3. Knowledge Base Editor/Refiner
What it does: Allows modification, updating, and validation of rules.
Example: In a diagnosis expert system, if new research shows that
“symptom X is not always linked with disease Y”, the rule can be updated to
maintain accuracy.
4. Debugging and Testing Facility
What it does: Helps trace errors, simulate reasoning, and test the rules.
Example: In an engineering troubleshooting system, developers can test
inputs like “Engine overheating” to check if the rules trigger the correct
solutions.
5. Learning Facility
What it does: Allows the system to learn from past cases or user feedback.
Example: In a customer support chatbot, if it repeatedly fails to answer a
question but later gets corrected, it can learn to include the right response in
the future.
6. Integration Facility
What it does: Connects the expert system with external software, databases,
or real-time systems.
Example: An industrial expert system can integrate with sensors in a
factory machine to monitor conditions in real time and suggest maintenance.
3. Stages in the Development of Expert Systems
Developing an expert system is similar to software development but focuses more
on knowledge.
1. Identification
What it does: Identify whether the problem really needs an expert system.
Example: A hospital identifies that “diagnosing rare diseases” requires
expert reasoning → good candidate for an expert system.
2. Conceptualization
What it does: Define the scope and collect initial knowledge.
Example: For a crop disease diagnosis system, define:
o Concepts → “leaves,” “soil,” “pests”
o Relationships → “pests damage leaves”
3. Formalization
What it does: Decide how knowledge will be represented (rules, frames,
etc.).
Example: Use if-then rules like:
o If leaves turn yellow and soil is dry → nitrogen deficiency.
4. Implementation
What it does: Build the system using tools.
Example: Use an expert shell like CLIPS or programming languages like
Prolog to code rules and inference engine.
5. Testing and Validation
What it does: Test with real-world cases to check correctness.
Example: Give the medical expert system real patient data and see if it
gives the same diagnosis as a human doctor.
6. Deployment
What it does: Install and make it available for users.
Example: The loan approval expert system is deployed in a bank’s branch
for officers to use while processing applications.
7. Maintenance and Improvement
What it does: Update knowledge, remove outdated rules, refine reasoning.
Example: In a cybersecurity expert system, when new types of malware
appear, the rules are updated to detect and prevent them.
Monkey Banana Explanation:
at(monkey, floor).
at(box, floor).
at(banana, ceiling).
move(Object, Location) :-
write(Object), write(' moved to '), write(Location), nl.
climb :-
write('Monkey climbed the box'), nl.
grab :-
write('Monkey grabbed the banana'), nl.
plan :-
move(box, under_banana),
move(monkey, under_banana),
climb,
grab.
run :-
plan.
*Step 1: Define the Initial State*
- Monkey is on the floor.
- Box is on the floor.
- Banana is hanging from the ceiling.
*Step 2: Define the Goal State*
- Monkey has the banana.
*Step 3: Define the Actions*
1. *Move*: Monkey can move the box to a new location.
2. *Climb*: Monkey can climb onto the box (if it's under the banana).
3. *Grab*: Monkey can grab the banana (if it's on the box and under the banana).
*Step 4: Plan the Actions*
1. Move the box under the banana.
2. Move the monkey to the box.
3. Climb onto the box.
4. Grab the banana.
*Step 5: Execute the Plan*
--------------------------------------------------------------------
*1. `at(monkey, floor).`*
- This is a fact that defines the initial state of the monkey's location.
- `at` is a predicate that takes two arguments: the object (monkey) and its location
(floor).
*2. `move(Object, Location) :- ...`*
- This is a rule that defines the `move` predicate.
- `Object` and `Location` are variables that represent the object being moved and
its new location.
- The `:-` symbol is called the "neck" symbol, which separates the head of the rule
(the predicate being defined) from the body (the conditions that must be true for
the rule to apply).
- `write(Object), write(' moved to '), write(Location), nl.` is the action that will be
executed when the `move` predicate is called. It prints a message indicating that
the object has been moved to the new location.
*3. `climb :- ...`*
- This is a rule that defines the `climb` predicate.
- The `climb` predicate has no arguments.
- `write('Monkey climbed the box'), nl.` is the action that will be executed when the
`climb` predicate is called. It prints a message indicating that the monkey has
climbed the box.
*4. `grab :- ...`*
- This is a rule that defines the `grab` predicate.
- The `grab` predicate has no arguments.
- `write('Monkey grabbed the banana'), nl.` is the action that will be executed when
the `grab` predicate is called. It prints a message indicating that the monkey has
grabbed the banana.
*5. `plan :- ...`*
- This is a rule that defines the `plan` predicate.
- The `plan` predicate has no arguments.
- The body of the rule defines the sequence of actions that the monkey will take to
achieve the goal state (grabbing the banana).
- The actions are:
1. `move(box, under_banana)`: Move the box under the banana.
2. `move(monkey, under_banana)`: Move the monkey to the box.
3. `climb`: Climb onto the box.
4. `grab`: Grab the banana.
*6. `run :- plan.`*
- This is a rule that defines the `run` predicate.
- The `run` predicate has no arguments.
- When the `run` predicate is called, it will execute the `plan` predicate, which will
in turn execute the sequence of actions defined in the `plan` rule.