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 --> 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 --> solutions

• Forward chaining is not directly supported in Prolog

(but is easy to implement, because Prolog is a great language)

B. Ross Cosc 4f79 1

 Backward chaining

Initial Q' Q'' Q''' ....... null (solved)

Query

Knowledge base Facts in working

database

Forward chaining

...

Initial facts Final

facts

Knowledge base
B. Ross Cosc 4f79 2
 Forward chaining algorithm

Productions having form

conditions ==> actions

where conditions are tests (simple facts, or relations eg. X > 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.

B. Ross Cosc 4f79 3
 • 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)

B. Ross Cosc 4f79 4

 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 use that one

if A then R

- 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
B. Ross Cosc 4f79 5
 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

B. Ross Cosc 4f79 6

 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!

B. Ross Cosc 4f79 7

 Mixed mode

p.185-187 Ignizio

B. Ross Cosc 4f79 8