A Model-Based Approach to the Constructionof Adaptive Case-Based Planning SystemsLawrence Birnbaum, Gregg Collins,Matthew Brand, Michael Freed, Bruce Krulwich, and Louise PryorNorthwestern UniversityThe Institute for the Learning SciencesEvanston, Illinois1 Chicken and water chestnutsA case-based planner devises new plans by retrieving and adapting old ones from mem-ory (see, e.g., Kolodner, Simpson, and Sycara, 1985; Hammond, 1989; Riesbeck andSchank, 1989). Ideally, the plan it retrieves from memory should be one that requiresthe least adaptation to �t the current circumstances. Finding this plan in a cost-e�ectiveway is thus a key issue in case-based reasoning (see, e.g., Bareiss and King, 1989; Kolod-ner, 1989; Kambhampati, 1990). The approach that is generally taken to this problem issimply to use the goals that the planner is attempting to achieve as indices into its planlibrary, as exempli�ed by the CHEF system (Hammond, 1989). In fact CHEF uses not onlythe goals themselves but also features of those goals that predict interactions that shouldbe avoided.Consider how CHEF uses goals to construct a plan (i.e., recipe) for beef with broccoliby adapting the plan for beef with green beans. The beef with green beans recipe consistsessentially of preparing the ingredients, stir-frying the beef with some of the other ingre-dients, then adding the green beans and stir-frying a bit longer. In order to adapt thisrecipe to prepare beef with broccoli, CHEF must alter the basic plan outline, introducinga split-and-reform process that avoids an undesirable interaction between the beef, whichsweats and produces liquid in the pan when cooked, and broccoli, a crispy vegetable thatbecomes soggy if cooked in liquid. To avoid this interaction, the broccoli is stir-fried andremoved from the pan before the meat and other ingredients are cooked, and then addedagain just before the dish is �nished. When CHEF stores this plan, one of the indicesto the plan is that it achieves the goal of avoiding soggy vegetables. At the same time,an anticipation rule is also built so that the planner will generate the goal to avoid soggyvegetables whenever it has the goals to cook a stir-fry dish involving both a meat and acrispy vegetable.Consider now what happens when CHEF is subsequently required to produce a recipefor chicken and snow peas. Because chicken is a meat and snow peas are a crispy vegetable,the anticipation rule acquired earlier generates a goal to avoid soggy vegetables. Usingthis goal in conjunction with the originally speci�ed goals, CHEF retrieves the beef andbroccoli plan, and adapts it by substituting the required ingredients. The resulting planincludes the split-and-reform process, and it too is indexed under the goal of avoiding soggyvegetables, as well as under the goals to cook a stir-fry dish, to use chicken, and to usesnow peas.Finally, suppose now that CHEF must create a recipe for chicken and water chestnuts.It happens that water chestnuts are not adversely a�ected by excess liquid, so no goalto avoid soggy vegetables will be generated. Assuming that the only plans in memory

are those so far mentioned, CHEF would retrieve the recipe for chicken and snow peas asthe plan in memory that achieves more of the speci�ed goals|namely, to make a stir-frydish, to include chicken, and to include water chestnuts|than any other. In this case,however, the retrieved plan includes a great deal of unnecessary complexity, introducedby the split-and-reform transformation in order to avoid soggy vegetables. CHEF includesa number of heuristics to detect and remove unnecessary complexity of this sort. Twooutcomes are possible: Either these heuristics will notice the wasted e�ort in this case, orthey won't. If the latter, then the resulting plan, while it achieves all of the speci�ed goals,is ine�cient. If the former, then as CHEF adapts the plan, it will remove the steps thatcarry out the split-and-reform process. In other words, the resulting plan will then specifythat the chicken and water chestnuts be stir-fried together.Notice that this plan is closer in structure to the original plan for beef with green beansthan to the plan for chicken and snow peas, since like the former it does not involve asplit-and-reform operation. In fact the only adaptations that would have been required toderive the recipe for chicken and water chestnuts from that for beef with green beans aresimple ingredient substitutions, rather than the more complex transformations requiredto eliminate the split-and-reform process from the chicken and snow peas recipe. We cantherefore see that the case retrieval process has failed to perform optimally in this instance,since the plan it retrieved was not the most easily adapted plan.It should be clear that the failure to perform optimally in this instance is neither anindictment of CHEF in particular, nor of case-based reasoning in general: The goal toretrieve the most easily adapted case in all circumstances must be traded o� against theneed for e�cient indexing and retrieval. However, the fact that we must live with thistrade-o� in general does not mean that a given source of sub-optimal performance, oncedetected, cannot be ameliorated. Rather, our aim should be the development of case-basedreasoning systems that are capable of detecting sub-optimal performance, determining itscauses, and making improvements. In this instance, for example, such a system would becapable, �rst, of noticing that the plan it had retrieved required more adaptation e�ort tomeet current circumstances than another plan in its memory, second, of recognizing howits indexing and retrieval were sub-optimal, and third, of modifying them in order to avoidsuch problems in the future (see, e.g., Sycara and Navinchandra, 1989).There are any number of ways that a case-based planner might notice such a problemin its indexing and retrieval. For example, the planner might index newly-created plansin terms of their temporal structure, in order to, among other things, recognize instancesof similar plans being carried out by other agents. In the course of indexing a new planin memory in this way, the additional cost of examining similarly indexed plans wouldbe relatively low on almost any model of retrieval. We can take advantage of this bychecking whether any other plan so retrieved would have formed a better starting point forgenerating the current plan than the one that was originally chosen. Although there is noguarantee that a better starting point would be found in every case where one existed|forexample, there is no guarantee that such a process would �nd beef with green beans inthe course of storing chicken with water chestnuts|it would nevertheless be a relativelye�cient way of �nding at least some instances where a better starting point could havebeen retrieved.Once an instance of sub-optimal performance has been recognized, the next steps mustbe to determine the cause of the problem, and to e�ect a repair. Our approach to diagnosingand repairing planning failures of this sort involves the use of model-based reasoning (see,e.g., Davis, 1984; deKleer and Williams, 1987; Simmons, 1988). In our approach, explicit

models of the planning and plan execution processes are used to generate expectationsabout the desired performance of the planning system. The failure of such an expectationtherefore indicates a need to modify the system in some way so that it can more closelyapproximate the desired behavior. Diagnosis of the underlying problem is made possible bylinking these expectations to relevant aspects of the model by means of explicit justi�cationstructures (see, e.g., Stallman and Sussman, 1977; Doyle, 1979). By tracing back throughsuch justi�cation structures, it is possible to pinpoint exactly where the actual systemdeviates from the model, and thereby identify what aspects of the system need to bealtered in order to achieve the expected performance. We have previously applied thisparadigm to the development of self-debugging planners in competitive domains (see, e.g.,Birnbaum and Collins, 1988; Collins, Birnbaum, and Krulwich, 1989; Birnbaum, Collins,Freed, and Krulwich, 1990). In this paper, we show how the paradigm can be applied tocase-based planning in particular.2 Modelling case-based planningIn order to build a case-based planner capable of using a model-based approach to improvingits performance, we must �rst develop an explicit model of case-based planning.At the most general level, case-based planning is a cycle of three steps: Anticipatingproblems that are likely to arise in achieving a given set of goals, retrieving from memorythe case that comes closest to satisfying the given goals while avoiding these problems,and adapting the plan suggested by this case to meet the current circumstances. Figure 1contains an explicit representation of this top-level description of the case-based planningprocess. 8goal9bugs;case;solutionbugs = anticipate(goal)^ case = retrieve(goal; bugs)^ solution = tweak(plan(case); bugs)To plan for a goal, anticipate planning problems, retrieve an appropriate case from memory,and adapt it to �t the current situation.Figure 1: Top-level rule for case-based planningAnticipation is modelled as a recognition process, in which a set of rules character-ize combinations of goals that are known to be problematic, and generate goals to avoidsuch problems when detected. Anticipating problems is thus a matter of evaluating theseanticipation rules over the features of the current goal. Figure 2 expresses this model ofanticipation.Case retrieval is modelled as the process of selecting the case in memory that achievesmore of the current goals than any other. The behavior of the retriever is described bythe rule given in �gure 3. The description provided by this rule makes no commitmentto the details of the search process by which the desired case is located. Plan adaptation

8goal;bug2anticipate(goal)9features2goal anticipator rule fires(features; bug)To anticipate bugs in planning for a goal, see if any anticipation rule applies to any com-bination of the features in the goal.Figure 2: Anticipating possible bugs8goal;bugs9casecase = retrieve(goal; bugs)^ 8case0 overlap(goal; goal(case)) < overlap(goal; goal(case0))To retrieve a case to plan for a set of goals, �nd the case which overlaps with more goalsthan any other case in memory.Figure 3: Retrieving a caseis modelled as a transformational process, in which a sequence of plan transformations isapplied to the retrieved plan. It is assumed that there will in every case exist a sequence oftransformations that will successfully adapt the retrieved plan to achieve all of the currentgoals. Our model of the adaptation process states that the �nal plan is the result of theapplication of one such sequence to the current plan. This is expressed in �gure 4. Noticeonce again that there is no speci�c model of the search process involved in the computation.8plan;bugs9solutionsolution = tweak(plan; bugs)^ 8feature2goal9tweak2tweak settweak rule applies(tweak; feature; plan)^ solution = apply tweaks(plan; tweak set)To tweak a plan to satisfy a goal, retrieve tweak rules appropriate to the goal features andretrieved plan, and then apply the tweaks.Figure 4: Tweaking a plan3 Modelling performance assumptionsThe basic model of case-based planning described in the last section is obviously incompletein a number of important ways. It is incomplete as a structural model because it does not

specify the actual mechanisms employed in retrieving cases, searching through the spaceof plan transformations, applying adaptation rules, and the like. It is incomplete as afunctional model because it does not completely specify the desired behavior of the system.For example, every planner must, at least implicitly, have the goal of generating plansthat perform as e�ciently as possible. Similarly, every planner must strive to itself be ase�cient as possible in producing such plans. In this section we specify a set of constraintsthat characterize, in part, what it means for a case-based planning system to performe�ciently.The �rst, and most obvious, constraint on the e�ciency of a case-based planner is thatit must, in general, be more e�cient than planning from scratch. In other words, the costof retrieving a base plan, �nding an appropriate sequence of adaptation rules, and thenapplying those rules to the retrieved plan must be less than the cost of directly constructinga sequence of operators that achieves the goal. This assumption is stated in �gure 5.18goals; operators=foperator1;...;operatorkg9plan2memory; tweaks=ftweak1 ;...;tweakng jplan = Retrieve(goal)^ Satisfies(Execution(tweakn(� � � tweak1(plan) � � �)); goal)^ Satisfies(Execution(operatork + � � �+ operator1); goal)^ 0@ Cost(Find(plan) + Find(tweaks) + Sequence(tweaks)+tweakn(� � � tweak1(plan) � � �))< Cost(Find(operators) + Sequence(operators)) 1AThe basic assumption of case-based planning is that retrieval and adaptation is cheaper thanplanning from scratch. Figure 5: The planning-cost assumptionIn order to develop adequate performance speci�cations for each of the individual com-ponents of a case-based planner, we must identify where the major costs lie. Potentially,the most expensive element of case-based planning is the adaptation process, since thisrequires roughly the same sort of complex reasoning that is required to plan from scratch.Since the point of case-based planning is precisely to avoid this sort of computationallyexpensive reasoning, our goal must therefore be to minimize the number of adaptation ruleapplications necessary to produce an adequate plan. Clearly, this requirement imposesconstraints on the adaptation process itself. What may be less clear is that it also imposesconstraints on the retrieval process, namely, that the case retrieved from memory must beone that requires the minimal amount of adaptation to meet the current circumstances.Given that case-based planners like CHEF index plans in memory by the goals that theyserve, this amounts to an assertion that the plan in memory that already achieves thegreatest number of current goals is also the plan that is most easily adapted to ful�ll all ofthose goals in the current situation. This aspect of the model is expressed in �gure 6.1The rule as stated actually asserts that case-based planning will be more e�cient than planning fromscratch in all instances, rather than (more realistically) that it will on average be more e�cient over the setof problems encountered. However, from the perspective of learning this simpli�cation can be justi�ed, inthat it will cause the planner to attempt to improve its performance whenever the assumption is violated.

8goals9plan2memory; solution; tweak1;...;tweakn jplan = Retrieveg(goal)^ solution = tweakn(� � � tweak1(plan) � � �)^ Satisfies(Execution(solution); goal)^ plan = Retrievep(tweakn(� � � tweak1(plan) � � �))^8plan02memoryDistancep(plan; solution) � Distancep(plan0; solution)Retrieval based on goal indices should return the plan best suited to adaptation.Figure 6: Retrieving the closest planThe �nal clause of this assumption, that the retrieved plan would be the closest match inplan space|where distance is measured by the amount of adaptation required to transformone plan into another|is itself justi�ed by the assumption that distance in plan space canbe estimated by distance in goal space|i.e., where distance is measured by the number ofshared goals. This is given more concretely in �gure 7.Distanceg(plan; solution) � Distanceg(plan0; solution)^ #(ProblemsAnticipated(plan))> #(ProblemsAnticipated(plan0))^ 0BBB@ :9pai0/2Anticipate(goal); plan02memory jplan0 = Retrieveg(goal;Anticipate(goal)+ pai0)^ Describes(pai0; goal)^ Distancep(plan; solution) � Distancep(plan0; solution) 1CCCAThe retrieved plan is closest in goal space to the solution, handles the greatest number ofanticipated goal interactions, and the ANTICIPATOR won't miss any goal interactions.Figure 7: Why the plan is closest in plan spaceIt should be clear that, in general, there is no reason to believe that the above constrainton retrieval would actually be true. The point is that the set of goals used in indexing mustbe tailored so as to make it true; and in fact CHEF, and similar systems, incorporate amechanism, in the form of their anticipation rules, to do just that. These rules anticipateproblematic interactions among the initially given set of goals, and generate new goals toavoid these interactions. The purpose of generating such goals is to enrich the set of indicesso as to re ect just those aspects of the situation that have led to the need for extensiveadaptation in the past. This increases the likelihood that the retrieved plan will not requiresuch extensive adaptation.

4 Model-based diagnosisThe basic premise of our model-based approach to learning is that when a planner failsto achieve expected performance goals, an analysis of the failure should be used as thebasis of a modi�cation intended to prevent the system from failing again for the samereason. In particular, this analysis is aimed at locating the component of the systemthat is responsible for the observed failure. In order to carry out such an analysis, thesystem must understand how its performance expectations follow from the design of itsplanning and plan execution components. The necessary knowledge is captured in thesystem's model of these components (as distinct from the system's model of elements ofits domain; see e.g., Goel and Chandrasekaran, 1988). The dependency of the system'sperformance expectations on particular aspects of the design is represented in the form ofexplicit justi�cation structures. In e�ect, these express the system's reasons for believingits performance expectations.When a performance expectation fails, the system uses these justi�cation structures asa means of attributing the failure to a particular component's deviation from its intendedfunctioning. More speci�cally, by tracing back from a failed expectation, it is possible todetermine which element of the model described above is at fault. By localizing the causeof failure in the model in this way, the system is able to focus its repair process on theparticular aspects of its behavior that were relevant to the observed failure.Let's consider how this process would be applied to the example described at the begin-ning of the paper. By hypothesis, when storing the plan for chicken and water chestnutsin memory, the system notices that the case closest to the new solution in memory is notthe plan the system originally retrieved (beef and broccoli), but rather a di�erent plan(beef and green beans). This violates the system's expectation that the plan it originallyretrieved will be the closest plan in memory to the desired one. This expectation, in turn,is justi�ed by assumptions concerning the three factors that determine the quality of re-trieval: di�erences between the goals presented to the system in the current situation andthe goals achieved by the plans in memory, di�erences in the goal interactions to whichthese plans are immune, and the system's ability to anticipate all of the goal interactionswhich a�ect the plan being sought. More speci�cally, when the system is storing the planback in memory it notices a failure of the performance expectation shown in �gure 6:8goals9plan2memory; solution; tweak1;...;tweakn jplan = Retrieveg(goal)^ solution = tweakn(� � � tweak1(plan) � � �)^ Satisfies(Execution(solution); goal)^ plan = Retrievep(tweakn(� � � tweak1(plan) � � �))^8plan02memoryDistancep(plan; solution) � Distancep(plan0; solution)The diagnosis engine will then examine each of the assumptions underlying this belief,which is shown in �gure 7, to �nd a possible cause of the failure. The �rst and the secondof these Distanceg(plan; solution) � Distanceg(plan0; solution);

and #(ProblemsAnticipated(plan))> #(ProblemsAnticipated(plan0))are easily shown to be true, and are in fact tautologically true if the retriever is functioningcorrectly. By a process of elimination, then, the source of the expectation failure lies in theremaining assumption::9pai0/2Anticipate(goal); plan02memory jplan0 = Retrieveg(goal;Anticipate(goal) + pai0)^ describes(pai0; goal)^ Distancep(plan; solution) � Distancep(plan0; solution)The diagnosis module thus concludes that the bug that led to the expectation failure isthat there should have existed a problem anticipation index (pai) for the anticipator toreturn, which it didn't. This pai would indicate that retrieving a plan to achieve the goalof avoiding soggy vegetables is unnecessary, and thus direct the retriever towards a planwhich does not address this goal. An anticipation rule would then be added which, giventhe goals to cook a meat dish and to include a vegetable which does not su�er from cookingin liquid, would generate such a \don't handle meat-sweats" pai. This pai would then directthe retriever to the closer case, namely the plan to make beef and green beans, and awayfrom the chicken and snow peas recipe.Intuitively, what is going on in this example is that having discovered that there is a casein its memory that should have been deemed closer than the one it actually retrieved, ourcase-based planner should add a new feature in common between the current situation andthe case that should have been retrieved, index both cases by this new feature, and builda new anticipation rule that will generate this feature in similar situations in the future(see, e.g., Sycara and Navinchandra, 1989). Attributing the problem to the anticipator inthis way, although one solution, is not the only possible analysis: One might also decideto fault the retriever. In fact, this alternative leads to a somewhat more general repair.However, the models of retrieval and adaptation that we developed above are not detailedenough to support such a diagnosis.In particular, the model of retrieval described above does not re ect the sophisticationof the procedure actually employed by CHEF, in that CHEF's metric for determining whichcase in memory will be retrieved considers not only the number of goals shared betweenthe current situation and cases in memory, but also the relative importance of those goalsas determined by a simple priority scheme. CHEF distinguishes three levels of importancein goals for the purposes of retrieval:1. A plan of the desired dish type is closer than a plan not of the desired dish type.2. A plan which handles more anticipated problems is closer than one which handlesfewer anticipated problems.3. A plan with more of the desired ingredients is closer than one with fewer.

If our model of retrieval were elaborated to include a priority scheme of this sort, thenthere would be an alternative to the method described in the last section for improvingperformance in situations where the optimal case was not retrieved from memory. In ad-dition to constructing additional anticipation rules that supply new features for indexing,as described above, the system would also have the option of changing the prioritizationscheme used to weight these features in the retriever. However, the prioritization schemeused must somehow re ect the cost of adaptation associated with the presence or absenceof a given goal, as in fact CHEF's scheme roughly does. Thus ascertaining how such aprioritization scheme must be altered in order to improve performance requires that themodel make explicit how the priority scheme should re ect the cost of adaptation. A suf-�ciently elaborated model along these lines would permit a model-based reasoning systemto diagnose an instance of sub-optimal initial case retrieval as being due to a mismatchbetween the prioritization scheme being used and the actual costs of adaptation.5 ConclusionsThis paper constitutes an initial foray into the application of model-based reasoning to thedetection, diagnosis, and repair of sub-optimal performance in a case-based planner. Thisparadigm has previously been applied to learning in competitive planning situations withsome success: Within the domain of chess, our model is capable of diagnosing planningfailures due to incomplete knowledge of the rules, improper or overly optimistic focusof attention, faulty projection, and insu�cient lead time for warning about threats, andis therefore able to learn about such concepts as discovered attack and the fork. Weare currently elaborating the more detailed models of retrieval and adaptation suggestedabove, and constructing an implementation in our test-bed system for investigating modelsof diagnosis and repair in planning.Acknowledgments: We would like to thank Ray Bareiss, Kris Hammond, Chris Ries-beck, and Roger Schank for many useful discussions. This work was supported in partby the Defense Advanced Research Projects Agency, monitored by the Air Force O�ce ofScienti�c Research under contract F49620-88-C-0058, and by the O�ce of Naval Researchunder contract N00014-89-J-3217. The Institute for the Learning Sciences was establishedin 1989 with the support of Andersen Consulting, part of The Arthur Andersen World-wide Organization. The Institute receives additional support from Ameritech, an InstituteSponsor, and from IBM.6 ReferencesBareiss, R., and King, J. 1989. Similarity assessment in case-based reasoning. Proceed-ings of the 1989 DARPA workshop on case-based reasoning, Morgan Kaufman, PensacolaBeach, FL, pp. 67-71.Birnbaum, L., and Collins, G. 1988. The transfer of experience across planning domainsthrough the acquisition of abstract strategies. In J. Kolodner, ed., Proceedings of the 1988Workshop on Case-Based Reasoning, Morgan Kaufmann, San Mateo, CA, pp. 61-79.Birnbaum, L., Collins, G., Freed, M., and Krulwich, B. 1990. Model-based diagnosis ofplanning failures. Proceedings of the 1990 AAAI Conference, Boston, MA, pp. 318-323.

Collins, G., and Birnbaum, L. 1990. Problem-solver state descriptions as abstract indicesfor case retrieval. Working Notes of the 1990 AAAI Spring Symposium on Case-BasedReasoning, Palo Alto, CA, pp. 32-35.Collins, G., Birnbaum, L., and Krulwich, B. 1989. An adaptive model of decision-makingin planning. Proceedings of the Eleventh IJCAI, Detroit, MI, pp. 511-516.Davis, R. 1984. Diagnostic reasoning based on structure and behavior. Arti�cial Intelli-gence, vol. 24, pp. 347-410.deKleer, J., and Williams, B. 1987. Diagnosing multiple faults. Arti�cial Intelligence, vol.32, pp. 97-130.Doyle, J. 1979. A truth maintenance system. Arti�cial Intelligence, vol. 12, pp. 231-272.Goel, A. and Chandrasekaran, B. 1988. Integrating model-based reasoning with case-based reasoning for design problem solving. Proceedings of the 1988 AAAI workshop onAI and design, St. Paul, MN.Hammond, K. 1989. Case-Based Planning: Viewing Planning as a Memory Task. Aca-demic Press, San Diego.Kambhampati, S. 1990. Mapping and retrieval during plan reuse: A validation structurebased approach. Proceedings of the 1990 AAAI Conference, Boston, MA, pp. 170-175.Kolodner, J. 1989. Selecting the best case for a case-based reasoner. Proceedings of theEleventh Annual Conference of the Cognitive Science Society, Ann Arbor, MI, pp. 155-162.Kolodner, J., Simpson, R., and Sycara, K. 1985. A process model of case-based reasoningin problem solving. Proceedings of the Ninth IJCAI, Los Angeles, CA, pp. 284-290.Riesbeck, C., and Schank, R., eds. 1989. Inside Case-Based Reasoning. Erlbaum, Hills-dale, NJ.Simmons, R. 1988. A theory of debugging plans and interpretations. Proceedings of the1988 AAAI Conference, St. Paul, MN, pp. 94-99.Stallman, R., and Sussman, G. 1977. Forward reasoning and dependency-directed back-tracking in a system for computer-aided circuit analysis. Arti�cial Intelligence, vol. 9, pp.135-196.Sycara, K., and Navinchandra, D. 1989. Index transformation and generation for case re-trieval. Proceedings of the 1989 DARPA workshop on case-based reasoning, Morgan Kauf-man, Pensacola Beach, FL, pp. 324-328.