Forward chaining

1
Forward chaining
backward chaining systems take high-level
goal, and prove it by reducing it to a null
goal - to reduce it to null, the KB facts
input from user are used at some point
top-down strategy Solution --gt facts
forward chaining or production systems take
all the facts, and use them to fire rules
until a high-level rule is proved true This
is a good strategy for when there are many
feasible solutions, and you want to find one
of them Forward-chaining is a "bottom-up"
strategy. Facts --gt solutions Forward
chaining is not directly supported in Prolog
(but is easy to implement, because Prolog is a
great language)
2
Backward chaining
.......
(solved)
Initial Query
Q''
null
Q'''
Q '
Facts in working database
Knowledge base
Forward chaining
...
Final facts
Initial facts
Knowledge base
3
Forward chaining algorithm
Productions having form conditions
gt actions where conditions are tests
(simple facts, or relations eg. X gt Y)
actions are assert(X) - assert a new
fact
retract(N) - retract fact for condition N
retract(all) -
retract all facts referenced in conditions
arithmetic
assignment, unification, IO, etc Algorithm 1.
Initial facts are input from user, put into
working database 2. Examine LHS of the
productions. If all the conditions are
satisfied for a rule, then "fire" it
- execute RHS actions -
retract old conditions/facts
- input new conditions/facts
- do other IO actions, unifications, etc 3.
Continue until no rules can be fired.
4
instead of a computation tree, what is
occurring is that the "state" of the inference
is represented by the set of facts in the working
database, - each fired rule updates the
computation state by changing the current
facts - a final state occurs when no more
productions can be fired Example
implementation (from Merritt text)
5
Enhancements
More efficient control - use heuristics
when choosing which rule to fire when more than
one is valid - refraction check
that same rule isn't firing over and over
- recency choose rules which use most
recently added elements in
the database or least recently used
- specificity choose a rule which
employs more conditions, or subsumes
another rule
eg. if A B C then Q
if A then Q - above
require the use of a conflict set set of rules
that are ready to fire - may require rules to
be time stamped in order to show when they
were added to KB - can apply these ideas to
backward chaining as well
use that one
6
Forward chaining
explanation - more difficult than
backward chaining, because there is no easy way
to save image of the computation - only
thing one can do is keep track of which rules
fired, and which facts were modified,
during the computation
7
Mixed mode
Many commercial shells combine forward and
backward chaining "opportunistic inference"
gives much more control to user however, can be
complicated to control Note that the general
problem is a theorem proving one example
mixed mode with backward-chaining priority -
separate rules into backward and forward groups
- use backward chaining until no backward
group rule is applicable - then resort to
forward chaining until a goal is solved (or
perhaps a backward rule becomes
invocable) - if both forward and backward
chaining stuck, can apply forward chaining
inference to backward group - the above is
system dependent of course. Many possible
variations!
8
Mixed mode
p.185-187 Ignizio