Notes for CS3310
Artificial Intelligence
Part 6: Control structures and
expert systems
Prof. Neil C. Rowe
Naval Postgraduate School
Version of January 2009
Control structures for rule-based systems
= your policy about what to do next at any time; or
= different procedural interpretations of the rules.
Prolog's usual control structure is "backward
chaining" or "goal-directed reasoning", reasoning
from query to data.
But there are other control structures.
Modus ponens: Given A is true and A implies B,
conclude B is true.
Modus ponens can be used as the basis of a control
structure, what is called "forward chaining" or
"data-directed reasoning".
CLIPS, JESS, and SOAR are examples of forwardchaining systems.
There are also hybrids of backward and forward
chaining.
Rule-cycle hybrid chaining
Finds conclusions that follow by modus ponens from a set of facts.
Requires: a set of facts and a set of rules that could work in
backward chaining if called with arguments all unbound.
1. Apply subroutine "one-cycle" to the list of all rules without
negations
2. Apply "one-cycle" to the list of all rules.
Subroutine "one-cycle":
1. Take the rules in order (one "cycle"):
(a) Find every way to get the rule to succeed by matching to the
current set of facts (taking facts in order). Backtrack to ensure
you try all possible bindings. Execute arithmetic and listprocessing expressions as subroutine calls.
(b) Add each new fact you prove at the bottom of the set of facts.
2. If no new facts were proved from any rule, stop. Else go to
step 1.
Example rule-based system without variables
m :- b, c, r.
u :- a, \+ e.
r :- s, b.
s :- c.
a.
b.
c.
Example rule-based system with variables
c(X) :- f(X).
goal2(X) :- c(X), d(Y).
f(X,Y) :- h(X), d(Y), g(X).
b :- \+ e.
goal1 :- \+ c(X).
a(X) :- b, c(X).
c(X) :- g(X).
d(7).
g(3).
g(5).
Problems with negations in forward and hybrid
chaining
a :- \+ c.
c :- \+ d.
Assume no "d" facts. If you follow the forward or
hybrid chaining algorithm with the above, you will
prove "a", then "c". But:
c :- \+ d.
a :- \+ c.
will prove only "c". That is correct!
The problem: a negation can be evaluated incorrectly if:
(1) its argument is provable; and
(2) its argument is proved only after you evaluate the
negation.
3 solutions to evaluating negations
1. Don't use any negations in your program: Define
certain predicates to be opposites of certain other
predicates, and have facts for the new predicates. This
can require many more facts, plus changes to rules.
2. Evaluate the negations in some order, not necessarily
the order in which they occur in rules, in which no
negation is evaluated until all ways to prove its
argument have been tried. This isn't always possible,
as with recursive rules.
3. Use negations, but never on something that appears on
a left side. To ensure this, expand and rewrite negation
expressions as necessary, using DeMorgan's Laws.
But: this only can be done in Prolog when no local
variables are created inside that negation. See next
page for examples.
Using DeMorgan's Laws to avoid negation problems
Example 1:
a :- b, \+ c.
c :- d, e.
Substitute "c" definition
in first rule:
a :- b, (\+ d; \+ e).
Then rewrite as two
equivalent rules:
a :- b, \+ d.
a :- b, \+ e.
Keep the "c" rule too if
needed elsewhere.
Example 2:
a :- b, \+ c.
c :- d, \+ e.
c :- f.
e :- g, h.
a :- b, \+ c.
c :- d, \+ g.
c :- d, \+ h.
c :- f.
a :- b, \+ (d, \+ g), \+ (d, \+ h), \+ f.
a :- b, \+ d, \+ d, \+ f.
a :- b, g, \+ d, \+ f.
a :- b, \+ d, h, \+ f.
a :- b, g, h, \+ f.
Building of expert systems, "knowledge engineering”
• Rule-based systems are often good for initial development of
“expert systems”.
• Expert systems try to duplicate human expertise.
• Building them requires an expert or experts and a "knowledge
engineer".
• Later the rules can be “compiled” into a more efficient form.
• It’s best to first define terms with the expert, then define rules.
• The knowledge engineer should check for errors like missing
definitions, inconsistent terminology, and inconsistent rule
patterns.
• Expect that development will require several cycles of writing
rules, generating output, and showing output to the expert.
• Automatic explanation facilities are very helpful (explaining
why the system gives particular answers or not).
Implementing rule-based expert systems
• Use codes to represent questions.
• Implement virtual facts by a user-input
subroutine.
• Cache user answers to questions (in Prolog,
with asserta).
• Identify appropriate top-level conclusions.
• Use intermediate predicates to chunk
knowledge.
• Hash facts to find relevant rules quickly.
Diagnosis of malfunctions of simple appliances
diagnosis('Fuse blown') :- power_problem, askif(lights_out).
diagnosis('Fuse blown') :- power_problem, askif(hear(pop)).
diagnosis('Break in cord') :- power_problem, askif(cord_frayed).
diagnosis('Short in cord') :- diagnosis('Fuse blown'),
askif(cord_frayed).
diagnosis('Device not turned on') :- power_problem, klutz_user,
askif(has('an on-off switch or control')), askifnot(device_on).
diagnosis('Cord not in socket properly') :- power_problem,
klutz_user, askif(just_plugged), askifnot(in_socket).
diagnosis('Foreign matter caught on heating element') :heating_element, not(power_problem), askif(smell_smoke).
diagnosis('Appliance wet--dry it out and try again') :power_problem, klutz_user, askif(liquids).
diagnosis('Controls adjusted improperly') :- klutz_user,
askif(has('knobs or switches')).
Appliance program, page 2
diagnosis('Kick it, then try it again') :- mechanical_problem.
diagnosis('Throw it out and get a new one').
/* Definitions of intermediate predicates */
power_problem :- askif(device_dead).
power_problem :- askif(has('knobs or switches')),
askifnot(knobs_do_something).
power_problem :- askif(smell_smoke), \+ heating_element.
klutz_user :- askifnot(handyperson).
klutz_user :- askifnot(familiar_appliance).
mechanical_problem :- askif(hear('wierd noise')),
askif(has('moving parts')).
heating_element :- askif(heats).
heating_element :- askif(powerful).
questioncode(device_dead, 'Does the device refuse to do
anything').
questioncode(knobs_do_something, 'Does changing the
switch positions or turning the knobs change anything').
Appliance diagnosis program, page 3
questioncode(lights_out, 'Do all the lights in the house seem to be
off').
questioncode(cord_frayed, 'Does the outer covering of the cord
appear to be coming apart').
questioncode(handyperson,'Are you good at fixing things').
questioncode(familiar_appliance, 'Are you familiar with how this
appliance works').
questioncode(device_on,'Is the ON/OFF switch set to ON').
questioncode(just_plugged, 'Did you just plug the appliance in').
questioncode(in_socket, 'Is the cord firmly plugged into the socket').
questioncode(smell_smoke,'Do you smell smoke').
questioncode(liquids,'Have any liquids spilled on the appliance just
now').
questioncode(heats,'Does the appliance heat things').
questioncode(powerful,'Does the appliance require a lot of power').
questioncode(has(X),X) :- write('Does the appliance have ').
questioncode(hear(X),X) :- write('Did you hear a ').
The spectrum of inference methods
flexible and uncompiled
Mathematical modeling
Predicate-calculus inference
Rule-based systems
logical
Heuristic search
numeric
Decision graphs
Neural networks
Case-based reasoning
Signatures
rigid and compiled
Control structures for rule-based systems
Standard algorithms:
--Backward chaining: what
Prolog does automatically
--Forward chaining: reasoning
by modus ponens
--Rule-cycle hybrid: forward
chaining on rules in a cycle,
backtracking within rules
Variations on the algorithms :
--Virtual facts: prompt user for a
fact only when needed
--Caching of facts: add timeconsuming conclusions as facts
to the database (in Prolog,
"asserta" does this), a form of
learning from experience
--Partitioning of rules:
modularity of objects (in
Prolog, "consult" loads files
dynamically)
"Compiled" algorithms (fast
but inflexible):
--Inference networks (and-ornot graphs): discrete neural nets
--Decision graphs: asking
yes/no questions in a hierarchy
--Signatures: hash tables
implementing decision trees
--Parallelism: partition, AND,
OR, and variable-matching
--Meta-rules: generalized
control
Inference networks ("and-or-not graphs")
Example rules:
a :- b, c. f :- b, \+ c.
c :- d.
c :- \+ e.
You can represent these with "and" gates, "or" gates, and
inverters, and create a combinatorial-logic integrated
circuit that corresponds to the rules.
"and" gate:
"or" gate:
inverter:
a
b
d
e
c
f
Decision graphs
Ask questions whose answers must be "yes" or "no” about the
facts. Continue until you establish all applicable
conclusions.
A graph can summarize the situations. Branches can
converge after diverging, so in general it's a decision
graph, not a tree.
“d” true?
yes
conclude “a”
and “c”
“d” true?
no
“e” true?
no
no
“b” true?
yes
yes
yes
no
“e” true?
conclude “f”
yes
stop
conclude “c”
no
Decision graph example
Given these rules, construct a decision graph that asks first
about “fever” and “coughing”.
virus :- cold, \+ severe.
bacterium :- cold, severe.
cold :- fever, coughing.
cold :- fever, sneezing.
cold :- coughing, sneezing, red_eyes.
Rule-based systems versus compiled graphs
Advantages of rules:
1. Very modular: you can add and remove rules without
changing other rules.
2. Easy to understand since rules are like how people think.
3. Easy to debug since what program is doing can usually be
explained declaratively.
Advantages of inference networks and decision graphs
1. Often much faster than rule-based systems.
2. Can be put in VLSI chips or very simple computers
3. Good for partitioned rule-based systems.
Disadvantages of inference networks and decision graphs
1. Variables are difficult to handle.
2. Modification is difficult once built.
3. Explaining what they're doing is hard.
4. Optimal decision lattices require work to build.
Signatures
A way to make decision trees even faster. Works best when most
questions must be asked in any circumstance; important for
fast-response systems like intrusion-detection systems and
object recognition by robots.
1. Make a list of all N possible questions and number them.
2. For each leaf node of the decision tree:
a. Make a list of questions answered positively along the path
here, and a list of the those answered negatively.
b. Hash (apply a complicated deterministic function to) this
vector, store at that location the conclusions at the leaf node.
3. When a new situation is encountered:
a. Make list of all question answers for this situation.
b. Find every hash entry corresponding to every subset of the
question answers. (Shortcuts may eliminate some subsets.)
Signatures are a good explanation for human behavior in timecritical applications like firefighting (as per G. Klein).
Possible parallelisms in rule-based systems
Assume you have several processors and a shared memory to
hold all facts. You can do 4 kinds of parallel processing:
1. Data parallelism: Make copies of rules, apply each set to
different data. Good for "information filtering"; good for
agent-based simulation where each copy is an agent.
(Google does huge amounts of this.)
2. Partition parallelism: Divide the rules into groups, execute
each group simultaneously. Good for forward and hybrid
chaining on some "partionable" rule-based systems. Often
uses a “blackboard” or global set of inferred facts.
3. Or-parallelism: For a set of rules with the same left side,
execute each rule on a different processor.
4. And-parallelism: For a rule right side of "and"ed
expressions, execute each expression on a different
processor. (This is harder to do than or-parallelism
because of side effects of variable binding.)
Example (automatic aircraft fuel management)
Consider a military aircraft that has redundant
systems (extra fuel tanks, extra engines, extra
control wiring). For survivability it must
automatically choose which to use when damage
occurs.
A processor can exploit sensors scattered throughout
the aircraft.
Assume: hybrid chaining, several processors, shared
memory. Where are some good opportunities for
parallelism?
Agents
"Agents" is a popular term in artificial intelligence
these days.
It usually means a set of mostly-autonomous rulebased systems that communicate like a society.
The main applications:
• "Distributed problems solvers" that work on
problems simultaneously by each addressing
different data or methods
• "Simulation agents" that that model people in a
game or simulation
• "Knowledge brokers" that find information for
you on the Internet
Example multi-agent rule-based system
Agent type R rule 1: If no enemy fire, advance toward target.
Agent type R rule 2: If see enemy and either you are concealed or
enemy is blocking your route, fire with small guns.
Agent type R rule 3: If enemy fires, return to staging area.
Agent type R rule 4: If major equipment malfunction, return to
staging area.
Agent type S rule 1: If no enemy fire, advance straight toward target.
Agent type S rule 2: If enemy advancing, shoot at it.
Agent type S rule 3: If enemy retreating, block them.
Agent type S rule 4: If enemy fire is encountered, use big guns.
Create some terrain, staging areas, and targets for each agent.
• Model effects of movement.
• Let there be a probability of seeing something given that there is a
line of sight.
• For many agents of both types, simulate what happens.
• Change probabilities to test situational effectiveness.
• Change, delete, or add rules to test policy effectiveness.
Issues for rule-based agents in a simulation
• Each agent can have its own set of rules. E.g., a cautious agent
will act differently to threats than an aggressive agent. Together
these rules model an agent's "personality".
• Each agent can have its own set of beliefs. It should reason about
its own beliefs only. E.g., it may know the positions other units
are supposed to take in a battle.
• Agents can acquire new beliefs by exploring the world and
observing. E.g., an agent sees another agent in the world and
hence knows its location. But they won't notice everything.
• Agents can also acquire new beliefs by being told them by other
agents (but they need not believe everything they are told). E.g.
an agent may be lied to in order to manipulate it.
• Agents must follow "social protocols" to communicate to one
another, and cannot just send facts to one another. They must
initiate "speech acts" in the proper format and sequence.
• Agents can search hypothetical worlds states.
Meta-rules
= Rules that tell you what order in which to use other
rules. They provide a higher-level kind of control
structure.
Examples:
1. Prefer the most recently used rule next.
2. Prefer the shortest rule.
3. Prefer the rule with the highest-priority
conclusion.
4. Prefer the rule with the highest-priority premises.
In general, a set of meta-rules is necessary to get a
unique recommended rule.