Reasoning System Reasoning System Reasoning with rules Forward

  • Slides: 20
Download presentation
Reasoning System

Reasoning System

Reasoning System ¬Reasoning with rules ¬Forward chaining ¬Backward chaining ¬Rule examples ¬Fuzzy rule systems

Reasoning System ¬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

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:

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

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

An example of simple rule if num_wheel =4 and motor=yes then vehicle =automobile Antecedent Clause Consequent Clause

An example of simple rule A rule states a relationship between clauses (assertions or

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

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

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

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

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 vehicle. TYpe = cycle – Rule 2: if num_wheel =3 then vehicle. TYpe = cycle – Rule 3: if (num_wheel =2 or num_wheel =3 ) then vehicle. TYpe = 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 <,

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 vehicle. TYpe = cycle

Rule representation confidence or certainty factor ¬ Another common enhancement to rule syntax is

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

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

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

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

Example of Sensor and Effector action ¬ An intelligent agent that processes e-mail might contain the following rule: – Rule 6: if sensor(mail. Arrived) then effector(process. Mail) – where mail. Arrived and process. Mail 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

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

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

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.