Efecto de la tasa de liberación de calor en el rendimiento efectivo

The design of intelligent systems is often inspired by attempts to emulate the characteristics of human intelligence. One such characteristic is the ability to recall previous experience whenever a similar problem arises. This is the essence of case-based reasoning (CBR). Consider the example of diagnosing a fault in a refrigerator, an example that will be revisited in Chapter 11. If an expert system has made a successful diagnosis of the fault, given a set of symptoms, it can file away this information for future use. If the expert system is subsequently presented with details of another faulty refrigerator of exactly the same type, displaying exactly the same symptoms in exactly the same circumstances, then the diagnosis can be completed simply by recalling the previous solution. However, a full description of the symptoms and the environment would need to be very detailed, and the chances of it ever being exactly reproduced are remote. What we need is the ability to identify a previous case, the solution to which can be modified to reflect the slightly altered circumstances. Thus case-based reasoning involves two difficult problems:

• determining which cases constitute a similar problem to the current one; • adapting a case to the current circumstances.

6.3.1 Storing cases

The stored cases form a case base. An effective way of representing the relevance of cases in the case base is by storing them as objects. Riesbeck and Schank [5] have defined a number of types of link between classes and instances in order to assist in locating relevant cases. These links are described below and examples of their use are shown in Figure 6.3.

Abstraction links and index links

The classes may form a structured hierarchy, in which the different levels correspond to the level of detail of the case descriptions. Riesbeck and Schank [5] distinguish two types of link between classes and their specializations: abstraction links and index links. A subclass connected by an abstraction link provides additional detail to its superclass, without overriding any information. An index link is a specialization in which the subclass has an attribute value that is different from the default defined in its superclass. For example, the class Refrigerator_fault might have an index link to the class

Electrical_fault, whose defaults relate to faults in vacuum cleaners (Figure 6.3(a)).

Suppose that we wish to save an instance of fixing a refrigerator, where the refrigerator exhibited the following symptoms:

• failed to chill food; • made no noise;

• the light would not come on.

This case might be stored as an instance of the class Refrigerator fault, which, as already noted, has an index link to the class Electrical fault.

Domestic_equipment_fault

Repairable_fault Catastrophic_fault

Refrigerator_ fault Washing_

machine_fault Toaster_fault

Electrical_fault Mechanical_fault Plumbing_fault

Abstraction links Index links (a) fitting new bearings removing compressor housing fixing a noisy

refrigerator washing machinefixing a noisy case where replacement

motor caused electrical interference Motor_fault instance-of link scene link exemplar link failure link scene link Case class Case instance (b)

Figure 6.3 Classifying case histories: (a) abstraction links and index links between classes;

Instance-of links

Each case is an instance of a specific class of cases (see Chapter 4 for a discussion of object classes and instances). Thus, each case has an instance-of relation with its parent class, as shown in Figure 6.3(b).

Scene links

These are used to link a historical event to its subevents. For example, removing the outer casing of a refrigerator’s compressor is a subevent of the “changing compressor bearings” event. Both the event and subevent are stored as case instances, with a scene link between them (Figure 6.3(b)).

Exemplar links

These are used to link instances to other similar instances. Suppose that a refrigerator motor fault was diagnosed by referring to a previous case involving a failed washing machine motor. This new case could have an exemplar link to the case from which it was adapted (Figure 6.3(b)).

Failure links

A failure link is a special type of class–instance relation, where the instance represents a specific case where things did not turn out as expected. This is a convenient way of storing cases that form exceptions to their general category. For example, the class Motor fault might have a failure link to a case in which a replacement motor created a new problem, such as radio interference (Figure 6.3(b)).

6.3.2 Retrieving cases

The problem of retrieving cases that match a new case, termed the probe case, is eased if the case base is carefully indexed using links as described above. Such links are often used as a basis for the first stage of a two-stage interrogation of the case base. The second stage involves ranking the matched cases according to a measure of similarity to the probe case [6].

For a given probe case, a suitable similarity measure Si for case i in the case bases could be:

¦

where P is the number of parameters considered, wj is an importance weighting applied to parameter j, and mij is a degree of match between case i and the probe case for the parameter j. For some parameters, such as the presence or

absence of a given observation, mij is binary i.e., it is either 0 or 1. Other parameters may concern continuous variables such as temperature, or nearly continuous variables such as cost. These can still yield binary values for mij if the measure is whether the parameter is within an acceptable range or tolerance. Alternatively, a sliding scale between 0 and 1 can be applied to mij. This is akin to using a fuzzy membership value rather than a crisp one (see Chapter 3).

6.3.3 Adapting case histories

There are two distinct categories of techniques for adapting a case history to suit a new situation, namely, structural and derivational adaptation. Structural adaptation describes techniques that use a previous solution as a guide and adapt it to the new circumstances. Derivational adaptation involves looking at the way in which the previous solution was derived, rather than the solution itself. The same reasoning processes are then applied to the set of data describing the new circumstances, i.e., the probe case. Four structural techniques and one derivational technique are outlined below.

Null adaptation

This is the simplest approach and, as the name implies, involves no adaptation at all of the previous solution. Instead, the previous solution is given as the solution to the new case. Suppose that the case history selector decides that a failed refrigerator is similar to the case of a failed washing machine. If the washing machine failure was found to be due to a severed power lead, then this is offered as the solution to the refrigerator problem.

Parameterization

This is a structural adaptation technique that is applicable when both the symptoms and the solution have an associated magnitude or extent. The previous solution can then be scaled up or down in accordance with the severity of the symptoms. Suppose, for example, that a case history was as follows:

symptom: fridge cabinet temperature is 15°C, which is too warm; solution: reduce thermostat setting by 11°C.

If our new scenario involves a fridge whose cabinet temperature is 10°C, which is still warmer than it should be, the new solution would be to turn down the thermostat, but by a modified amount (say 6°C).

Reasoning by analogy

This is another structural adaptation technique. If a case history cannot be found in the most appropriate class, then analogous case histories are considered. Given a hierarchically organized database of case histories, the search for analogous cases is relatively straightforward. The search begins by looking at siblings, and then cousins, in a class hierarchy like the one shown in Figure 6.3(a). Some parts of the historical solution may not applicable, as the solution belongs to a different class. Under such circumstances, the inapplicable parts are replaced by referring back to the class of the current problem.

As an example, consider a refrigerator that is found to be excessively noisy. There may not be a case in the database that refers to noisy refrigerators, but there may be a case that describes a noisy washing machine. The solution in that case may have been that the bearings on the washer’s drum were worn and needed replacing. This solution is not directly applicable to the refrigerator, as a refrigerator does not have a drum. However, the refrigerator has bearings on the compressor, and so it is concluded that the compressor bearings are worn and are in need of replacement.

Critics

The use of critics has stemmed from work on a planning system called HACKER [7], which can rearrange its planned actions if they are found to be incorrectly ordered (see Chapter 13). The ideas are also applicable to other problems, such as diagnosis (see Chapter 11). Critics are modules that can look at a nearly correct solution and determine what flaws it has, if any, and suggest modifications. In the planning domain, critics would look for unnecessary actions, or actions that make subsequent actions more difficult. Adapting these ideas to diagnosis, critics can be used to “fine-tune” a previous solution so that it fits the current circumstances. For instance, a case-based reasoner might diagnose that the compressor bearings in a refrigerator need replacing. Critics might notice that most compressors have two sets of bearings and that, in this particular refrigerator, one set is fairly new. The modified solution would then be to replace only the older set of bearings.

Reinstantiation

The above adaptation techniques are all structural, i.e., they modify a previous solution. Reinstantiation is a derivational technique, because it involves replaying the derivation of the previous solution using the new data. Previously used names, numbers, structures, and components are reinstantiated to the corresponding new ones. Suppose that a case history concerning a

central heating system contained the following abduction to explain from a set of a rules why a room felt cold:

IF thermostat is set too low THEN boiler will not switch on

IF boiler is not switched on

THEN radiators stay at ambient temperature

IF radiators are at ambient temperature THEN room will not warm up

Abductive conclusion: thermostat is set too low

By suitable reinstantiation, this case history can be adapted to diagnose why food in a refrigerator is not chilled:

IF thermostat is set too high THEN compressor will not switch on

IF compressor is not switched on

THEN cabinet stays at ambient temperature

IF cabinet is at ambient temperature THEN food will not be chilled

Abductive conclusion: thermostat is set too high

6.3.4 Dealing with mistaken conclusions

Suppose that a system has diagnosed that a particular component is faulty, and that this has caused the failure of an electronic circuit. If it is then discovered that there was in fact nothing wrong with the component, or that replacing it made no difference, then the conclusion needs repair. Repair is conceptually very similar to adaptation, and similar techniques can be applied so as to modify the incorrect conclusion to reach a correct one. If this fails, then a completely new solution must be sought. In either case, it is important that the failed conclusion be recorded in the database of case histories with a link to the correct conclusion. If the case is subsequently retrieved in a new scenario, the system will be aware of a possible failure and of a possible way around that failure.

6.4 Summary

Systems that can learn offer a way around the so-called “knowledge acquisition bottleneck.” In cases where it is difficult or impossible to extract accurate knowledge about a specific domain, it is clearly an attractive proposition for a computer system to derive its own representation of the knowledge from examples. We have distinguished between two categories of learning systems — symbolic and numerical — with this chapter focusing on the former. Inductive and cased-based methods are two particularly important types of symbolic learning.

Rule induction involves the generation and refinement of prototype rules from a set of examples. An initial prototype rule can be generated from a template or by hypothesizing a causal link between a pair of observations. The prototype rule can then be refined in the light of new evidence by generalizing, specializing, or rejecting it. Rule induction from numerical systems such as neural networks is also possible; discussion of this is deferred until Chapter 9 on hybrid systems.

Case-based reasoning involves storing the details of every case encountered, successful or not. A stored case can subsequently be retrieved and adapted for new, but related, sets of circumstances. This is arguably a good model of human reasoning. The principal difficulties are in recognizing relevant cases, which necessitates a suitable storage and retrieval system, and in adapting stored cases to the new circumstances. The concepts of CBR have been illustrated here with reference to fault diagnosis, but CBR has also found a wide range of other applications including engineering sales [8], help-desk support [9], and planning [10].

References

1. Minton, S., Carbonell, J. G., Knoblock, C. A., Kuokka, D. R., Etzioni, O., and Gil, Y., “Explanation-based learning: a problem-solving perspective,” Artificial Intelligence, vol. 40, pp. 63–118, 1989.

2. Mitchell, T. M., Utgoff, P. E., and Banerji, R., “Learning by experimentation: acquiring and refining problem-solving heuristics,” in Machine Learning: an artificial intelligence approach, vol. 1, Michalski, R., Carbonell, J. G., and Mitchell, T. M. (Eds.), pp. 163–190, 1983. 3. Laird, J. E., Rosenbloom, P. S., and Newell, A., “Chunking in SOAR: the

anatomy of a general learning mechanism,” Machine Learning, vol. 1, pp. 11–46, 1986.

4. Laird, J. E., Newell, A., and Rosenbloom, P. S., “SOAR: an architecture for general intelligence,” Artificial Intelligence, vol. 33, pp. 1–64, 1987. 5. Riesbeck, C. K. and Schank, R. C., Inside Case-Based Reasoning,

Lawrence Erlbaum Associates, 1989.

6. Ferguso, A. and Bridge, D., “Options for query revision when interacting with case retrieval systems,” Expert Update, vol. 3, issue 1, pp. 16–27, Spring 2000.

7. Sussman, G. J., A Computer Model of Skill Acquisition, Elsevier, 1975. 8. Watson, I. and Gardingen, D., “A distributed case-based reasoning

application for engineering sales support,” 16th International Joint Conference on Artificial Intelligence (IJCAI’99), Stockholm, Sweden, vol. 1, pp. 600–605, Morgan Kaufmann, 1999.

9. Kunze, M. and Hübner, A., “Textual CBR case studies of projects performed,” Lenz, M. and Ashley, K. (Eds.), AAAI’98 Workshop on Textual Case-Based Reasoning, Menlo Park, CA, pp. 58–61, 1998. 10. Marefat, M. and Britanik, J., “Case-based process planning using an

object-oriented model representation,” Robotics and Computer Integrated Manufacturing, vol. 13, pp. 229–251, 1997.

Further reading

• Kolodner, J., Case-Based Reasoning, Morgan Kaufmann, 1993. • Langley, P., Elements of Machine Learning, Morgan Kaufmann, 1995. • Mitchell, T. M., Machine Learning, McGraw-Hill, 1997.

• Watson, I. D., Applying Case-Based Reasoning: techniques for enterprise systems, Morgan Kaufmann, 1997.