Forward chaining backward chaining systems take highlevel goal

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 4 f 79 1

Backward chaining Initial Query Q' Knowledge base Q''' . . . . null (solved) Facts in working database Forward chaining. . . Final facts Initial facts B. Ross Cosc 4 f 79 Knowledge base 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 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 4 f 79 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 4 f 79 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 4 f 79 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 4 f 79 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 4 f 79 7

Mixed mode p. 185 -187 Ignizio B. Ross Cosc 4 f 79 8