![]() |
|||
![]()
|
![]() |
![]() |
![]() |
3. CBR CONCEPTSThe reasoning paradigm behind CBR is very simple: "past" cases closest (in characteristics) to the current problem situation are retrieved or recalled, and the best matching case's corresponding solution is transformed to solve the new one. The advantage here is that much effort is saved since one can re-derive lessons, explanations, plans, or solutions (e.g., treatment regimen for a new patient) by simply reusing the results from previous (patient) cases, which is close enough to how a human expert might carry out problem-solving. Of course, the catch to using CBR is that there must be a sufficiently large "database of cases" from which to draw from, but for practical and ethical reasons (say, in medicine), sometimes such a database may be hard to come by. The domain must also be well understood, i.e., not new medical areas where there is incomplete information or incorrect or controversial knowledge. The traditional AI approach builds a system from scratch; attempting to solve problems by constructing solutions based on general principles (or rules) and substantial in-depth problem-solving knowledge. The pitfalls of acquiring knowledge from a human expert through interviews, for example, have been well documented, and have led to the term "knowledge acquisition bottleneck" being coined by Feigenbaum. In contrast, CBR recalls "past" cases similar to the current problem situation and transforms the corresponding solution to solve the new one. Just as a doctor treats a new patient by recalling his experiences in diagnosing and treating previous patients, a CBR system retrieves from its library of cases, the most "similar" (in characteristics, problem description, etc.) old case, adapts the results to the new case, and hence proposes a solution to the new problem. In this way, the effort involved in solving a new problem is substantially reduced simply by reusing previous results, instead of from scratch. The major steps in case-based reasoning are as in Figure 1.
3.1. REPRESENTING A CASEA case could resemble a database entry, with a list of characteristics or features describing a particular situation. A case is usually complete by itself, or may be connected to a set of subcases, forming a hierarchical structure of the problem-solving task. Cases are usually represented in the form of predicates, frames, or even database-like records. A case is usually made up of three components: (1) the description of the problem, (2) the description of the solution to the problem mentioned in (1), and (3) the outcome as a result of applying the solution. The description in (1) would contain all descriptive information needed to achieve the goal of the CBR system. For example, if the goal of the system is to diagnose the cause of the patient's illness, and hence provide the appropriate treatment, then the descriptive information in (1) would contain the patient's symptoms, laboratory test results, etc. for diagnosis of the disease; and the patient's medical history, drug allergies, etc. for the treatment. It is essential that as much relevant information as possible to the problem-solving goal is captured since a case is only as useful as the information it holds. The description of the solution to the problem essentially allows the user, once a similar case has been retrieved, to reuse a previous solution without starting from scratch. Hence, if a match on the patient's problem has been found (i.e., diagnosed the disease-causing agent of the patient), then whatever treatment that worked before would have been stored in the solution description. Obviously, a patient that died as a result of a particular treatment would not be stored, but it may be stored with a different objective, i.e., to avoid such failures in the future. Hence, an explanation of why a particular failure occurred, and the remedy, may be stored and used as a guide to avoid or anticipate such a failure in future. Some CBR systems may also store the reasoning steps used to solve the problem, justifications for decisions made, and acceptable or alternative solutions as part of the description of the solution. The outcome as the result of applying the solution refers to the results derived from feedback after the solution has been carried out. The outcome description may contain explanations of what was carried out, whether the outcome was a success or failure, the repair strategy (in the case of failure) and what could have been done to avoid the failure, and the results after applying the repair. The outcome component of a case is useful for predicting potential failures and how to avoid them.
|
![]() |
|
Use of this site is subject certain Terms & Conditions. Copyright (c) 1996-1999 EarthWeb, Inc.. All rights reserved. Reproduction in whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Please read our privacy policy for details. |