Reasoning with IF..THEN

Although the IF..THEN rules of an expert systems knowledge base look a lot like the IF..THEN statements of a programming language they are very different.

In particular they can be used to reason a way to a solution and so they are more like the raw material of a logic argument or proof. This is of course the connection between expert systems and logic!

The type of reasoning that is used by an expert system depends on the exact details of the inference engine and this is another strength of the method. If you have gone to a lot of trouble creating a knowledge base then any improvements in the reasoning ability of inference engines shouldn't make your work obsolete.

Even so it has to be admitted that the sort of reasoning that expert systems use is particularly simple and crude. Indeed it is equivalent to taking the small rule fragments and joining them together to form larger complete rules.

For example, if you have the rules:

IF A THEN B
IF B THEN C

then an expert system will deduce:

IF A THEN C

and this is about as sophisticated as things get. In general all that happens is that as the expert system discovers facts it draws what conclusions it can and then uses these conclusions as facts to be used in other rules.

That is, if you tell it A then it concludes B from the first rule which it then uses as a fact to conclude C from the second rule. Notice that this means that it never actually produces the IF A THEN C rule from the other two but the results are the same.

Backwards and Forwards

That's more or less all there is to know about expert systems apart from the small matter of how the information is gathered.

If everything about a problem is already known before the consultation starts you could just add the facts to the rules "shake the bag" and see what conclusions fall out. In practice it is more common to expect that the expert system will ask for facts in an orderly fashion that mimics a human expert.

One method is to start from what facts are known and then ask the user to supply missing facts for rules that are likely to provide a relevant conclusion.

For example, if you already know A and B and you have a rule:

IF A AND B AND C THEN D

then you should ask the user for fact C because it is a good bet that you will be able to draw a conclusion D.

This method of asking for facts to prove conclusions and then using the conclusions in further rules is called forward chaining. It isn't a bad method but it tends to produce a sequence of questions that don't make much sense to the human being questioned.

For example, it might ask "Have you paid your electricity bill?" followed by "are all the other lights working?". The reason for this seemingly haphazard order of questions is that there is nothing guiding the selection of rules towards the final solution.

An alternative method is to find a rule that has the final solution as its conclusion and then try to discover the facts needed to draw that conclusion.

This is called backward chaining and it tends to produce a more natural order of questioning.

For example, going back to the three rules concerning the state of the light bulb backward chaining would work by first finding rule 3 which has a conclusion about light bulbs. To use this rule we need to know that the electricity is not cut off and the fuse is OK. Obviously rule 2 has the state of the fuse as its conclusion so it is worth asking the user "is everything else working?". If the answer is YES then we can conclude that the fuse is OK and this gives us a fact to use in rule 3.

This is an example of backward chaining to work from what we would like to conclude to what we need to know. In this case there is a need to use forward chaining as well because once we know that that everything else is working this information needs to be applied to rule 1 to conclude that the electricity hasn't been cut off.

Many expert system shells use backward chaining to determine the order that questions are asked and then use forward chaining to spread the newly acquired information to all of the rules that it applies to.

When is reasoning a tree?

The reasoning process that is used with the collection of IF..THEN  rules is trivial compared to the sort of reasoning processes that we looked at in The Greeks, George Boole and Prolog as part of logic.

Indeed they are so trivial that it can be said that they really don't exist. If you want to you can take a set of rules and process them to produce a set of large rules that require no reasoning when they are used.

For example, the three rules concerning the blown bulb can be combined together to form the single large rule given earlier. If you do this for all of the rules in a knowledge base the result is a decision tree which can be used not only to reach conclusions but also to govern the order in which questions are asked.

A decision tree is like a map of the route to the conclusion. For example in the case of the light bulb the decision tree would be something like:

          Is the power on
            /        \
           No         Yes
     (other        Is the fuse OK?
   conclusions)       /      \
                     No       Yes
                 (other        |
               conclusions) change the
                              bulb

Of course in a real case the decision tree would be very much larger. There are expert systems that use this method, for example, XpertRule, and they have significant advantages over the more traditional backward chaining based systems.

<ASIN:013138645X>

<ASIN:3540629718>

<ASIN:1432749366>