Reasoning with rules Forward chaining Backward chaining Rule examples Fuzzy rule systems Planning
Reasoning with rules Rule format: If-then-else rules The reasons for using rules –Easily understand –Easily read –Easily add –Easily modify
Reasoning with rules Rules are normally manipulated by reasoning systems: –Forward chaining: can generate new facts. –Backward chaining: can deduce whether statements are true or not.
Rule base system An expert system or knowledge-based system is the common term used to describe a rule-based processing system. It consists three elements: –A knowledge base (the set of if-then-else rules and known facts) –A working memory or database of derived facts and data –An inference engine which contains the reasoning logic used to process the rules and data.
An example of simple rule if num_wheel =4 and motor=yes then vehicle =automobile Antecedent ClauseConsequent Clause
An example of simple rule A rule states a relationship between clauses (assertions or facts) and, depending on the situation, can be used to generate new information or prove the truth of an assertion. A conclusion generated by the reasoning rule can be add that fact to our knowledge base. On the other hand, if we are trying to prove a fact is true( rhs), we need to find out the antecedent clauses have been presented (lhs).
Reasoning Engine Forward reasoning: –Using facts and rules to derive new facts Backward reasoning: –Trying to prove an assertion in the consequence of a rule by showing that the antecedent clauses are true.facts and rules to derive new facts
Triggered/Ready to Fired A rule whose antecedent clauses are all true is said to be triggered or ready to fired. We fire a triggered rule by asserting the consequence clause and adding it as a fact to our working memory. At any time, a rule base may contain several rules that are ready to fire. It is up to the control strategy of the inference engine to decide which one gets fired.
Identifying the Rules Most rule-based system allow rules to have names or labels such as Rule 1: or Automobile: to easily identify rules for editing or for tracing during inferencing.
Rule representation Some systems allow disjunctions (or) between antecedent clauses. This is a short-hand that reduces the size of a rule base. –Rule 1: if num_wheel =2 then vehicleTYpe = cycle –Rule 2: if num_wheel =3 then vehicleTYpe = cycle –Rule 3: if (num_wheel =2 or num_wheel =3 ) then vehicleTYpe = cycle Rule 3 could replace Rule 1 and Rule 2 in the rule base.
Rule representation Most rule systems also allow boolean condition operators such as, and !=, in addition to equality. –Rule 4: if (num_wheel >1) and (num_wheel <4 ) then vehicleTYpe = cycle
Rule representation confidence or certainty factor Another common enhancement to rule syntax is the addition of a confidence or certainty factor. If we only write rules which applied 100 percent of the time with 100 percent confidence, we would have a very small knowledge base. If we have little confidence in our predictive antecedent clauses, we may lower the certainty factor of the rule to 50 percent.
Rule representation confidence or certainty factor The certainty factor are commonly given by heuristics or rules of thumb. Example of rule with certainty factor: –Rule 5: if (whether_forcast= rain) and (whether_probability >80%) then (chance_of_rain =high) with CF:90
Rule representation - Sensor Many rule-based system allows functions to be called from the antecedent clause., These functions are called sensors, because they go out of the inference engine and test some condition in the environment. Sensors usually return boolean values, but they may also return data or facts to the working memory.
Rule representation - Effector When functions are allowed in the consequent, they are called effectors, which greatly expand the capability of the rule-based system. An effector returns a rule from a fact-generating mechanism into an action-generating device. These action rules allow intelligent agents to do things for us.
Example of Sensor and Effector action An intelligent agent that processes e-mail might contain the following rule: –Rule 6: if sensor(mailArrived) then effector(processMail) –where mailArrived and processMail are defined as functions which interface with the e-mail system, and sensor() and effector() are methods provided by the inferencing system for invoking those functions.
Rulebase Management In small numbers, rule can adequately represent many types of domain knowledge. However, as the number of rules grows, the intuitive aspects of if-then rules are diminished, and they lose their effectiveness from a readability perspective. Commercial rule-base systems often allow grouping or partitioning of rules so that they can be treated as logical blocks of knowledge in an attempt to overcome this weakness.
Rulebase Management As more complete information comes in, or as things change in the outside world, rules which may have been true before become false. The consequence is that we may have to “take back” some of the “facts” which were generated by the rules. –For example, if we see that the grass is wet, we may fire a rule that concludes it is raining. However, we may then get information that the sprinkler system is on. This may cause us to retract our assertion that it is raining or at least lower our confidence or certainty in making that conclusion.
Rulebase Management Dealing with changes and retracting facts or assertions is called nonmonotonic reasoning. Keeping a rule-base consistence by managing dependencies between inferred facts requires a truth maintenance system. Most reasoning systems, such as predicate logic, are monotonic, that is, they add information but do nor retract information from the knowledge base.