Download
1 / 8
140 likes | 454 Views
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.
E N D
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)
Backward chaining ....... (solved) Initial Query Q'' null Q''' Q ' Facts in working database Knowledge base Forward chaining ... Final facts Initial facts Knowledge base
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.
• 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)
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 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 use that one
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
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!
Mixed mode p.185-187 Ignizio
