Backward-chaining (a goal-driven strategy) 1 The backward-chaining mechanism

Backward-chaining is an inference strategy that assumes the existence of a goal that needs to be established or refuted. In the boiler control example, our goal might be to establish whether it is appropriate to replace the outlet pipe, and we may not be interested in any other deductions that the system is capable of making. Backward-chaining provides the means for achieving this. Initially, only those rules that can lead directly to the fulfillment of the goal are selected for examination. In our case, the only rule that can achieve the goal is Rule 2.3, since it is the only rule whose conclusion is replace outlet pipe. The

condition part of Rule 2.3 is examined but, since there is no information about a steam outlet blockage in the fact base, Rule 2.3 cannot be fired yet. A new goal is then produced, namely steam outlet blocked, corresponding to the

condition part of Rule 2.3. Two rules, 2.4 and 2.6, are capable of fulfilling this goal and are therefore antecedents of Rule 2.3. What happens next depends on whether a depth-first or breadth-first search strategy is used. These two methods for exploring a search tree were introduced in Chapter 1, but now the nodes of the search tree are rules.

For the moment we will assume the use of a depth-first search strategy, as this is normally adopted. The use of a breadth-first search is discussed in Section 2.9.3. One of the two relevant rules (2.4 or 2.6) is selected for examination. Let us suppose that Rule 2.6 is chosen. Rule 2.6 can fire only if steam is escaping from the drum. This information is not in the fact base, so

steam escaping becomes the new goal. The system searches the rule base for

a rule which can satisfy this goal. Rule 2.9 can satisfy the goal, if its condition is met. The condition part of Rule 2.9 relies only on the status of the release valve. If the valve were found to be open, then 2.9 would be able to fire, the goal steam escaping could be satisfied, Rule 2.6 would be fireable and the

Let us suppose, on the other hand, that the release valve is found to be closed. Rule 2.9 therefore fails, with the result that Rule 2.6 also fails. The system backtracks to the last place where a choice between possible rules was made and will try an alternative, as shown in Figure 2.7. In the example shown here, this means that Rule 2.4 is examined next. It can fire only if the release valve is stuck but, because this information is not yet known, it becomes the new goal. This process continues until a goal is satisfied by the information in the fact base. When this happens, the original goal is fulfilled, and the chosen path through the rules is the solution. If all possible ways of achieving the overall goal have been explored and failed, then the overall goal fails.

The backward-chaining mechanism described so far has assumed a depth- first search for rules. This means that whenever a choice between rules exists, just one is selected, the others being examined only if backtracking occurs.

The inference mechanism built into the Prolog language (see Chapter 10) is a depth-first backward-chainer, like that described here. There are two sets of circumstances under which backtracking takes place:

Rule 2.3 Rule 2.4 Rule 2.5 Rule 2.7 Goal: replace outlet pipe search Failure Rule 2.6 Rule 2.9 search Success backtrack

Figure 2.7 Backward-chaining applied to the boiler control rules: the search for rules proceeds in a depth-first manner

Start

Goal G1 satisfied? Goal is G1

Rule X1 exists that satisfies

G1?

Condition part of rule X1 is goal G2 Another solution

wanted?

Stop

Backtrack

Backtrack

Choose new rule X1

Stop Success Goal failed yes no yes no yes no Backtrack etc Goal G2 satisfied? Goal is G2 Rule X2 exists that satisfies

G2?

Condition part of rule X2 is goal G3 Another solution

wanted?

Stop

Backtrack

Choose new rule X2

Success yes no yes no yes no Goal G3 satisfied? Goal is G3 Rule X3 exists that satisfies

G3?

Condition part of rule X3 is goal G4 Another solution

wanted?

Stop

Backtrack

Choose new rule X3

Success yes no yes no yes no Backtrack etc

(i) when a goal cannot be satisfied by the set of rules currently under consideration; or

(ii) when a goal has been satisfied and the user wants to investigate other ways of achieving the goal (i.e., to find other solutions).

2.9.2 Implementation of backward-chaining

Figure 2.8 shows a generalized flowchart for backward-chaining from a goal G1. In order to simplify the chart, it has been assumed that each rule has only one condition, so that the satisfaction of a condition can be represented as a single goal. In general, rules have more than one condition. The flowchart in Figure 2.8 is an attempt to represent backward-chaining as an iterative process. This is difficult to achieve, as the length of the chain of rules cannot be predetermined. The flowchart has, of necessity, been left incomplete. The flowchart contains repeating sections that are identical except for the variable names, an indication that while it is difficult to represent the process iteratively, it can be elegantly represented recursively. A recursive definition of a function is one that includes the function itself. Recursion is an important aspect of the artificial intelligence languages Lisp and Prolog, discussed in Chapter 10, as well as many other computer languages. Box 2.1 shows a recursive definition of backward-chaining, where it has again been assumed that rules have only one condition. It is not always necessary to write such a function for yourself as backward-chaining forms an integral part of the Prolog language and most expert system shells and artificial intelligence toolkits (see Chapter 10).

2.9.3 Variations of backward-chaining

There are a number of possible variations to the idea of backward-chaining. Some of these are:

(i) depth-first or breadth-first search for rules;

(ii) whether or not to pursue other solutions (i.e., other means of achieving the goal) once a solution has been found;

(iii) different ways of choosing between branches to explore (depth-first search only);

(iv) deciding upon the order in which to examine rules (breadth-first search only);

(v) having found a succession of enabling rules whose lowest-level conditions are satisfied, whether to fire the sequence of rules or simply to conclude that the goal is proven.

Breadth-first backward-chaining is identical to depth-first, except for the mechanism for deciding between alternative rules to examine. In the example described in Section 2.9.1 (and in Figure 2.7), instead of choosing to explore either 2.4 or 2.6, both rules would be examined. Then the preconditions of each (i.e., Rules 2.5 and 2.9) would be examined. If either branch fails, then the system will not need to backtrack, as it will simply carry on down those branches which still have the potential to fulfill the goal. The process is illustrated in Figure 2.9. The first solution to be found will be the one with the shortest (or joint-shortest) chain of rules. A disadvantage with the breadth-first approach is that large amounts of computer memory may be required, as the system needs to keep a record of progress along all branches of the search tree, rather than just one branch.

define function backwardchain(G);

/* returns a boolean (i.e., true/false) value */ /* G is the goal being validated */

variable S, X, C; result:= false;

/* ‘:=‘ represents assignment of a value to a variable */

S:= set of rules whose conclusion part matches goal G; if S is empty then

result:= false; else

while (result=false) and (S is not empty) do X:= rule selected from S;

S:= S with X removed; C:= condition part of X; if C is true then

result:=true elseif C is false then

result:=false

elseif (backwardchain(C)=true) then result:=true;

/* note the recursive call of ‘backwardchain’ */ /* C is the new goal */

endif; endwhile; endif; return result;

/* ‘result’ is the value returned by the function */ /* ‘backwardchain’ */

enddefine;

The last item (v) in the above list of variations of backward-chaining is important but subtle. So far our discussion of backward-chaining has made limited reference to rule firing. If a goal is capable of being satisfied by a succession of rules, the first of which is fireable, then the goal is assumed to be true and no rules are actually fired. If all that is required is validation of a goal, then this approach is adequate. However, by actually firing the rules, all of the intermediate deductions such as water level low are recorded in the fact base and may be used by other rules, thereby eliminating the need to re- establish them. Therefore, in some implementations of backward-chaining, once the path to a goal has been established, rules are fired until the original goal is fulfilled. In more complex rule-based systems, rules may call up and run a procedurally coded module as part of their conclusion. In such systems, the firing of the rules is essential for the role of the procedural code to be realized. Rule 2.3 Rule 2.4 Rule 2.5 Rule 2.7 Goal: replace outlet pipe search failure Rule 2.6 Rule 2.9 success

Figure 2.9 A variation of backward-chaining applied to the boiler control rules; here the search for rules proceeds in a breadth-first manner

Finally, it should be noted that in some backward-chaining systems the rule syntax is reversed, compared with the examples that we have discussed so far. A possible syntax would be:

DEDUCE <conclusion> IF <condition>

The placing of the conclusion before the condition reflects the fact that in backward-chaining systems it is the conclusion part of a rule that is assessed first, and only if the conclusion is relevant is the condition examined.