Learning by induction

6.2.1 Overview

Rule induction involves generating from specific examples a general rule of the type:

IF <general circumstance> THEN <general conclusion>

Since it is based on trial-and-error, induction can be said to be an empirical approach. We can never be certain of the accuracy of an induced rule, since it may be shown to be invalid by an example that we have not yet encountered. The aim of induction is to build rules that are successful as often as possible, and to modify them quickly when they are found to be wrong. Whatever is being learned — typically rules and relationships — should match the positive examples but not the negative ones.

The first step is to generate an initial prototype rule that can subsequently be refined. The initial prototype may be a copy of a general-purpose template, or it can be generated by hypothesizing a causal link between a pair of observations. For instance, if a specific valve valve_1 in a particular plant is

open and the flow rate through it is 0.5m3s1, we can propose two initial prototype rules:

IF valve_1 is open

THEN flow rate through valve_1 is 0.5 IF flow rate through valve_1 is 0.5 THEN valve_1 is open

The prototype rules can then be modified in the light of additional example data or rejected. Rule modifications can be classified as either strengthening or weakening. The condition is made stronger (or specialized) by restricting the circumstances to which it applies, and conversely it is made weaker (or generalized) by increasing its applicability. The pair of examples above could be made more general by considering other valves or a less precise measure of flow. On the other hand, they could be made more specific by specifying the necessary state of other parts of the boiler. A rule needs to be generalized if it fails to fire for a given set of data, where we are told by the teacher that it should have fired. Conversely, a rule needs to be specialized if it fires when it should not.

Assume for the moment that we are dealing with a rule that needs to be generalized. The first task is to spot where the condition is deficient. This is easy when using pattern matching, provided that we have a suitable representation. Consider the following prototype rule:

IF ?x is open AND ?x is a Gas_valve THEN flow rate through ?x is high

This rule would fire given the scenario:

valve_1 is open

valve_1 is a Gas_valve

The rule is able to fire because valve_1 is open matches ?x is open and

valve_1 is a Gas_valve matches ?x is a Gas_valve. The conclusion flow rate through valve_1 is high would be drawn. Now consider the following scenario:

valve_2 is open

valve_2 is a Water_valve

The rule would not fire. However, the teacher may tell us that the conclusion

flow rate through valve_2 is high should have been drawn. We now look for matches as before and find that valve_1 is open matches ?x is

open. However, there is no match to ?x is a Gas_valve, so this part of the

condition needs to be generalized to embrace the circumstance ?x is a Water_valve.

We can therefore recognize where a rule is deficient by pattern-matching between the condition part of the rule and the scenario description. This is analogous to means–ends analysis, which is used to determine a plan for changing the world from its current state to a goal state (see Sections 5.3 and 13.3). Means–ends analysis typically uses pattern-matching to determine which rules can lead to such a change.

6.2.2 Learning viewed as a search problem

The task of generalizing or specializing a rule is not straightforward, as there are many alternative ways in which a rule can be changed. Finding the correctly modified rule is a search problem, where the search field can be enormous. Figure 6.1 shows a possible form of the search tree, where each branch represents a generalization or specialization that would correctly handle the most recently encountered input. Subsequent inputs may reveal an incorrect choice (indicated by a dot at the end of a branch). The system must keep track

solution

Initial form

= no solution: backtracking required

of its current position in the search tree, as it must backtrack whenever an unsuitable choice is found to have been made.

Recording all of the valid options (or branches) that make up a search tree is likely to be unwieldy. The Lex system [2] offers a neat solution to this problem. Rather than keeping track of all the possible solutions, it simply records the most general and the most specific representations that fit the examples. These boundaries define the range of acceptable solutions. The boundaries move as further examples are encountered, converging on a smaller and smaller choice of rules, and ideally settling on a single rule.

There are other difficulties associated with the search problem. Suppose that a rule-based system is controlling a boiler. It makes a series of adjustments, but ultimately the boiler overheats, i.e., the control objective has not been achieved. In this case, the feedback of the temperature reading to the learning system serves as the teacher. The system is faced with the difficulty of knowing where it went wrong, i.e., which of its decisions were good and which ones were at fault. This is the credit-assignment problem. Credit assignment applies not only to negative examples such as this (which could be termed “blame assignment”), but also to cases where the overall series of decisions was successful. For example, a boiler controller which succeeds in keeping the temperature within the specified range might do so because several good decisions compensate for poorer ones.

The frame problem (or situation-identification problem), introduced in Chapter 1, affects many areas of artificial intelligence, particularly planning (Chapter 13). It is also pertinent here, where the problem is to determine which aspects of a given example situation are relevant to the new rule. A system for control of a boiler will have access to a wide range of information. Suppose that it comes across a set of circumstances where it is told by the teacher that it should shut off valve_2. The current world state perceived by the system is determined by stored data and sensor values, for example:

valve_1: shut

valve_2: open

gas_flow_rate: high

gas_temperature: 300°C

water_temperature (pressurized): 150°C

fuel oil stored: 100 gallons

preferred supplier of fuel oil: ACME inc.

In order to derive a rule condition such as:

the system must be capable of deducing which parts of its world model to ignore — such as the information about fuel oil — and which to include. The ability to distinguish the relevant information from the rest places a requirement that the system must already have some knowledge about the domain.

6.2.3 Techniques for generalization and specialization

We can identify at least five methods of generalizing (or specializing through the inverse operation):

(i) universalization;

(ii) replacing constants with variables;

(iii) using disjunctions (generalization) and conjunctions (specialization); (iv) moving up a hierarchy (generalization) or down it (specialization); (v) chunking.

Universalization

Universalization involves inferring a new general rule from a set of specific cases. Consider the following series of separate scenarios:

valve_1 is open AND flow rate for valve_1 is high valve_2 is open AND flow rate for valve_2 is high valve_3 is open AND flow rate for valve_3 is high

From these we might induce the following general rule:

/* Rule 6.1 */

IF ?x is open THEN flow rate for ?x is high

Thus we have generalized from a few specific cases to a general rule. This rule turns out to be too general as it does not specify that x must be a valve. However, this could be fixed through subsequent specialization based on some negative examples.

Replacing constants with variables

Universalization shows how we might induce a rule from a set of example scenarios. Similarly, general rules can be generated from more specific ones by replacing constants with variables (see Section 2.6). Consider, for example, the following specific rules:

IF gas_valve_1 is open THEN flow rate for gas_valve_1 is high IF gas_valve_2 is open THEN flow rate for gas_valve_2 is high

IF gas_valve_3 is open THEN flow rate for gas_valve_3 is high IF gas_valve_4 is open THEN flow rate for gas_valve_4 is high IF gas_valve_5 is open THEN flow rate for gas_valve_5 is high

From these specific rules we might induce a more general rule:

/* Rule 6.1 */

IF ?x is open THEN flow rate for ?x is high

However, even this apparently simple change requires a certain amount of metaknowledge (knowledge about knowledge). The system must “know” to favor Rule 6.1 rather than, say:

/* Rule 6.2 */

IF ?x is open THEN flow rate for ?y is high

or:

/* Rule 6.3 */

IF ?x is open THEN ?y for ?x is high

Rule 6.2 implies that if any valve is open (we’ll assume for now that we are only dealing with valves) then the flow rate through all valves is high. Rule 6.3 implies that if a valve is open then everything associated with that valve (e.g., cost and temperature) is high.

Using conjunctions and disjunctions

Rules can be made more specific by adding conjunctions to the condition and more general by adding disjunctions. Suppose that Rule 6.1 is applied when the world state includes the information office_door is open. We will draw the nonsensical conclusion that flow rate through office_door is high. The rule clearly needs to be modified by strengthening the condition. One way to achieve this is by use of a conjunction (AND):

/* Rule 6.4 */

IF ?x is open AND ?x is a Gas_valve THEN flow rate for ?x is high

We are relying on the teacher to tell us that flow rate through office_door is high is not an accurate conclusion. We have already noted that there may be several alternative ways in which variables might be introduced. The number of alternatives greatly increases when compound conditions are used. Here are some examples:

IF valve_1 is open and valve_1 is a Gas_valve THEN ... IF valve_1 is open and ?x is a Gas_valve THEN ... IF ?x is open and valve_1 is a Gas_valve THEN ... IF ?x is open AND ?x is a Gas_valve THEN ... IF ?x is open AND ?y is a Gas_valve THEN ..

The existence of these alternatives is another illustration that learning by rule induction is a search process in which the system searches for the correct rule.

Suppose now that we wish to extend Rule 6.4 so that it includes water valves as well as gas valves. One way of doing this is to add a disjunction (OR) to the condition part of the rule:

/* Rule 6.5 */

IF ?x is open AND (?x is a Gas_valve OR ?x is a Water_valve) THEN flow rate for ?x is high

This is an example of generalization by use of disjunctions. The use of disjunctions in this way is a “cautious generalization,” as it caters for the latest example, but does not embrace any novel situations. The other techniques risk overgeneralization, but the risky approach is necessary if we want the system to learn to handle data that it may not have seen previously. Overgeneralization can be fixed by specialization at a later stage when negative examples have come to light. However, the use of disjunctions should not be avoided altogether, as there are cases where a disjunctive condition is correct. This dilemma between the cautious and risky approaches to generalization is called the disjunctive-concept problem. A reasonable approach is to look for an alternative form of generalization, only resorting to the use of disjunctions if no other form can be found that fits the examples.

Moving up or down a hierarchy

Rule 6.5 showed a cautious way of adapting Rule 6.4 to include both water valves and gas valves. Another approach would be to modify Rule 6.4 so that it dealt with valves of any description:

/* Rule 6.6 */

IF ?x is open AND ?x is a Valve THEN flow rate for ?x is high

Here we have made use of an is-a-kind-of relationship in order to generalize (see Section 4.5). In the class hierarchy for valves, Water_valve and

Chunking

Chunking is a mechanism for automated learning that is used in SOAR [3, 4]. SOAR is a production system (i.e., one that uses production rules — see Chapter 2) that has been modeled on a theory of human cognition. It works on the premise that, given an overall goal, every problem encountered along the way can be regarded as a subgoal. Problems are, therefore, tackled hierarchically — if a goal cannot be met at one level, it is broken down into subgoals. These automatically generated subgoals may be satisfied through the application of production rules stored in a long-term memory from previous runs of the system. However, the application of such rules may be slow, as several of them may need to be fired successively to satisfy the subgoal. Once SOAR has recognized the series of rules required to satisfy a subgoal, it can collapse them down into a single production rule. This is the process of chunking. The new rule, or chunk, is then stored so that it can rapidly solve the same subgoal if it should arise again in the future.

SOAR also offers a novel method of conflict resolution (see Chapter 2). The usual role of a production rule is to change some aspect of the system’s state, which models the problem being tackled. In SOAR, any rule that can fire does so, but the changes to the current state proposed by the rule are not applied immediately. Instead they are added to a list of suggested changes. A separate set of production rules is then applied to arrange conflicting suggestions in order of preference — a process known as search control. Once conflict has been resolved through search control, changes are made to the actual state elements.

Gas_valve

Valve

Water_valve Regulator