Case-based reasoning in depth

The CBR cycle

Case-based reasoning solves a new problem with the most similar past one. Its four steps form a loop:

1. Retrieve the most similar stored case(s), using feature-based indexing.
2. Adapt the retrieved solution to the differences in the new situation (analytic or heuristic transformation).
3. Apply the adapted solution; if it fails, iterate.
4. Save the new case — *with* its success/failure outcome — and update the index, so the system learns.

Step 4 is what distinguishes CBR from a static rule base: every problem solved (or botched) enlarges the experience the system draws on next time.

Retrieval is the hard part

Getting the *right* case back is the crux, because adaptation is only as good as the case you start from. Kolodner's six preference heuristics rank candidate cases:

- Goal-directed — same high-level goal as now. - Salient-feature — match the most *important* features first. - Specificity — prefer exact matches over general ones. - Frequency — favour cases matched often. - Recency — favour recently used cases. - Ease-of-adaptation — favour cases easiest to adapt.

No single heuristic wins everywhere; real systems blend several into a weighted similarity score tuned to the domain — which is exactly the worked example below.

Worked example — weighted similarity retrieval

Give each feature a weight (its salience). A case's similarity to the query is the sum of the weights of the features it matches, divided by the total. With weights engine=0.5, lights=0.3, fuel=0.2 and a query engine=no_start, lights=dim, fuel=low, case#3 (engine=no_start, lights=dim, fuel=full) matches engine + lights = 0.5 + 0.3 = 0.8 and wins — even though no case matches *every* feature. That is the salient-feature heuristic in code: the two heavy features outvote the light one.