Massively Parallel Support for Case-based Planning - CiteSeerX

Massively Parallel Support for Case-based Planning



Brian P. Kettler, James A. Hendler, William A. Andersen, and Matthew P. Evett Department of Computer Science University of Maryland College Park, MD 20742

Abstract

In case-based planning (CBP), previously generated plans are stored as cases in memory and can be reused to solve similar planning problems in the future. CBP can save considerable time over planning from scratch (generative planning), thus oering a potential (heuristic) mechanism for handling intractable problems. One drawback of CBP systems has been the need for a highly structured memory that requires signi cant domain engineering and complex memory indexing schemes to enable ecient case retrieval. In contrast, our CBP system, CaPER, is based on a massively parallel frame-based AI language and can do extremely fast retrieval of complex cases from a large, unindexed memory. The ability to do fast, frequent retrievals has many advantages: indexing is unnecessary; very large casebases can be used; and memory can be probed in numerous alternate ways, allowing more speci c retrieval of stored plans that better t a target problem with less adaptation.

Preliminary version of an article appearing in IEEE Expert, February 1994, pp. 8-14. This paper is an extended version of [1]. 

1 Introduction The CaPER system is a case-based planner which is being developed to take advantage of the eciency of plan reuse. It also addresses some of the problems and limitations of case-based planners that use serial retrieval procedures on an indexed memory (casebase). CaPER makes use of the massive parallelism of the Connection Machine (CM)[2] to provide fast retrieval of cases and plans from a large, unindexed memory. Given the ability to access memory quickly, CaPER can aord to go often to memory to retrieve multiple plans which can be merged and adapted to solve the target problem. Because memory is unindexed, there is high

exibility in the kinds of queries that may be issued. The same casebase can be shared by multiple reasoning systems. In addition, the parallel retrieval procedures used can scale to very large casebases of hundreds or thousands of cases | a size typical of many real-world domains. This paper describes the components of CaPER used for retrieving cases. Examples are presented from the planning domains being used to test CaPER's retrieval mechanisms: a simpli ed automobile assembly domain and a transportation logistics domain. The remainder of this section describes case-based planning (CBP) and problems with the approach to case retrieval taken by most CBP systems. Section 2 describes CaPER's memory and the PARKA system used to implement it. Section 3 describes CaPER's Plan Retriever component. Section 4 describes some promising empirical results for case retrieval. Section 5 describes some other systems that make use of massive parallelism for memory retrieval. Section 6 brie y describes future work.

1.1 Case-based Planning

A case-based planning system solves planning problems by making use of stored plans that were used to solve analogous problems. CBP is a type of case-based reasoning (CBR), which involves the use of stored experiences (\cases"). There is strong evidence that people frequently employ this kind of analogical reasoning (e.g., [3] [4] [5]). CBP planners can be distinguished from generative planners, such as Nonlin [6], which generate a plan from scratch by searching a space of partial plans. These systems expand a partial plan by adding actions to it and then checking the plan for helpful and harmful interactions between actions in the expanded plan | a costly process. CBP systems, in contrast, do not 1

begin from scratch. They attempt to nd fully-instantiated plans with any harmful interactions already removed. CBP systems consist of a planner and a casebase. Cases typically include a description of a planning problem (an initial state and goals to be achieved) and the plan(s) used to solve it (a sequence of primitive, executable actions). When a CBP system solves a new planning problem, the new plan is added to its casebase for potential reuse in the future. Thus the system learns from experience. Since feedback from the new plan's execution is also typically stored as part of the new case, the system can avoid repeating any failures it encountered. Most CBP systems use a version of the following process when given a new planning problem to solve: 1. Retrieve cases from memory that are analogous to the current (\target") problem. 2. Select one or more of these candidate cases that are most similar to the target problem. 3. Adapt the selected case (plan) to a new plan for the target problem. 4. Evaluate the new plan by execution, simulated execution, or analysis. 5. Repair any faults found in the new plan. 6. Store the new plan (and feedback from its execution) as a new case in the casebase. To realize the bene ts of remembering and reusing past plans, a CBP system needs ecient methods for retrieving analogous cases and for adapting retrieved plans and a casebase of sucient size and coverage to yield useful analogues.

1.2 Case Retrieval in CBP Systems

Most case-based systems use serial procedures to retrieve from memory a case that is analogous to a target problem. Features of the target problem are used as a retrieval probe to match against stored cases. Features may include descriptions of objects, object attributes, and relations1 between objects in the target problem's initial situation and goals. 1

including higher-order relations

2

In order to provide more ecient case retrieval, the technique of indexing is used to restrict the kinds of features that may be used as part of a retrieval probe. It would be prohibitively expensive to sequentially compare a probe against each case in an entire casebase of realistic size (i.e., hundreds or thousands of cases). Indexing makes this approach more tractable by restricting the search for old cases to a subset of a casebase. Much of the eort in building CBP systems lies in choosing an indexing scheme that can enable ecient retrieval of relevant cases from memory. This is known as the \indexing problem" in the CBR/CBP literature. Many serial CBP systems use pre-indexing. Pre-indexing is the use of case features (\indices") which are xed at case storage time. For example, the CHEF system[7] stores a plan for cooking beef and broccoli stir-fry under the indices \beef" and \broccoli" and abstractions \meat" and \vegetable". Many CBP systems use more complex indices such as expectation failures encountered during plan execution. Pre-indexing often imposes a particular organization on the case memory. A common memory organization involves the use of a discrimination tree or network. There are several problems with pre-indexing case memory. First, indexing hinders exibility in case retrieval. When indexing is used, a case can only be eciently retrieved through features by which it has been indexed or through some abstraction of them. (The abstractions used need to be limited to a few for eciency's sake.) Cases that share unindexed features with the target problem will not be retrieved. For example, one might have limited time to devote to cooking and thus desire a cooking plan for cooking any dish that takes less than 15 minutes to prepare. CHEF could not cope with such a query since it does not index plans by the time they take. It therefore would have to resort to checking potentially all cases in its casebase. One could add an index for time to each case in CHEF's casebase, but to do this for many features would lead to a proliferation of indices and thus defeat the purpose of indexing, namely eciency. It is unlikely that the designer of an indexing scheme could anticipate and provide for many of the ways in which a case might usefully be retrieved in the future. Some recent research has been done on ways to automatically build indexing schemes. For example, in the Battle Planner system[8], the discrimination tree of indices was automatically induced, producing a betterbalanced tree that enabled more ecient case retrieval.2 The indices pro2

Worst case retrieval time from a balanced binary tree is O(log n), where n is the

3

duced by automated techniques, however, can be highly arti cial, and they still constrain case retrieval. Second, indexing schemes are often domain- and task-speci c and can thus limit the general-purpose utility of a case memory. A general-purpose organization of the knowledge base is desirable if it is to be used by multiple systems, which may use case-based or other reasoning mechanisms. For example, a casebase of computer equipment repair calls would be useful for both a diagnostic CBR system for repairing failures and a design CBR system for product redesign. Memory organizations used to support indexing can lack the exibility needed to support multi-purpose memory use. For example, a discrimination tree has a xed ordering of indexed features by salience: the more salient features are at higher levels of the tree. Finally, the psychological plausibility of indexing is questionable given evidence from psychological studies of human analogue retrieval (e.g., [4] [9] [10]). Human analogue retrieval is fast and highly associative, with many remindings being generated. Humans use a combination of semantic, structural, and pragmatic features of cases for retrieval, depending on the domain/task, and are capable of nding analogies within a single domain and between domains (\cross-domain" or metaphorical analogies).

2 CaPER's Memory CaPER's memory is unindexed. This section describes its general organization, a semantic network. Section 2.1 describes how this memory is implemented and accessed. CaPER's memory contains representations of episodic and conceptual knowledge. The kinds of concepts represented include objects (e.g., \Vehicle", \Car", \4 Cylinder Engine", \Airport") and actions (e.g., \P-InstallSunroof", \P-Fly-Airplane"3 ). Objects can have physical properties and actions can have roles, preconditions and eects. Concepts are organized in is-a, part/whole, and other relationships (e.g., \Car" is-a \Vehicle", \Airport" is-a-part-of \City"). Concepts may have instances which are termed \individuals". Individuals represent particular things (e.g., individual \Car1" is a particular car, \P-Fly-Airplane-1" is a particular occurrence of action number of cases. Worst case retrieval time from an unbalanced binary tree is O(n). 3 The pre x \P-" is used in the names of frames representing actions to distinguish them from frames representing plans and cases.

4

\P-Fly-Airplane").4 Episodic knowledge describes particular, dated experiences that the system has had (or has been told of). Every episode is associated with a particular date, time, place, and other features of the situation in which it occurred. Episodes include cases (previous planning problems), e-plans (previously executed plans), and e-actions (previously executed primitive actions). A case consists of a planning problem (initial situation and target goals), the e-plan(s) generated to solve it, and feedback on the e-plans executed. E-plans consists of a hierarchy of component e-plans (\subplans"), each solving a target goal/subgoal. These subplans can in turn have subplans of their own. At the bottom of a plan hierarchy are e-actions (which are individuals | instances of an action concept). In CaPER, nodes in the semantic network represent concepts, individuals, and episodes. Arcs represent relationships among these. Figureq 1 shows an sample piece of CaPER's memory from the simpli ed automobile assembly (car construction) domain. Plan Build-Car-1, the top-level (\root") plan used in Case-Build-Car-1, consists of subplans Build-Body-1, Install-Engine1, Install-Sunroof-1, etc. E-action P-Install-Sunroof-1 is a primitive action of subplan Install-Sunroof-1 (and its parent plan Build-Car-1).

2.1 CaPER's Memory Implementation

CaPER's memory is implemented using the massively-parallel, frame-based PARKA knowledge representation system.[11] [12] (See A for details). A node in the semantic network is implemented as a frame in PARKA. An arc for relation r connecting node1 to node2 is implemented as a slot r in the frame for node1 lled with the frame for node2 . CaPER makes use of PARKA's fast inheritance mechanisms for representational eciencies and retrieval. The PARKA Structure Matcher [13] used by CaPER to retrieve episodes from memory, takes advantage of this fast query processing speed. A knowledge base is viewed as a graph with vertices representing frames and edges representing slots, which relate two frames. The Structure Matcher returns all subgraphs in the knowledge base which match a speci ed probe, a graph consisting of frames or variables for vertices and relations for edges.5 Any frames and slots can be used a part of the probe graph. A sample probe (query) is shown in Figure 2. When used with the memory of Figure 1, this 4 5

Individuals are designated with a numerical sux to distinguish them from concepts. Currently only subgraphs which exactly match the probe graph are returned.

5

episode is-a

detroit-factory

case place

is-a

may-6-1992

is-a time

case-build-car-1

case-build-car-2

sedan-frame frame engine

4c-engine

goal

car-type-1

plan

top

hard-top

is-a

options

build-car-1

e-plan

subplans

sunroof

ac is-a

etc. is-a

install-sunroof-1

sunroof-1

actions

install-engine-1 build-body-1

e-action

object is-a

p-install-sunroof-1

Figure 1: Sample Piece of CaPER's Memory probe would result in a match of variable ?case to frame case-build-car-1 (and possibly other cases), variable ?plan to frame build-car-1, etc. Some empirical results for the operation of the Structure Matcher on CaPER casebases are given in Section 4.

3 Plan Retrieval in CaPER The design of CaPER's Plan Retriever component, described in this section, exploits CaPER's ability to do fast case/plan retrieval. The main rami cations of this ability are twofold. First, with its fast parallel retrieval procedures, CaPER does not need to use an pre-indexed memory, which is required for ecient serial retrieval. 6

detroit-factory

case place is-a

?case sedan-frame frame

4c-engine

engine

goal

?car

plan

top

hard-top

is-a

options

sunroof

?plan

e-plan

ac

Figure 2: Sample Structure Matcher Probe Graph Thus, unlike systems which use pre-indexing, CaPER can retrieve cases (and plans) from memory that share any features with target problem. Any features of the target problem can be included in the retrieval probe (described in the previous section). Abstractions of target features can also be included. By controlling which features are part of the target probe and their level of abstraction, a wide range of queries can be issued. By issuing highly speci c queries, CaPER can nd plans from cases in memory that are very similar to the target problem and which therefore require less adaptation. Second, CaPER can aord to do multiple plan retrievals to get dierent plans, each of which can be used to solve a dierent part of the target problem. CBP systems that use serial procedures typically go to memory infrequently because of the high cost of doing so. Often these systems retrieve only a single old case/plan to adapt to solve all of the goals of the target problem.6 In contrast, CaPER can quickly retrieve several plans (or subplans) to achieve dierent goals of the target problem and merge them with the result being a better- tting, composite plan that solves all (or most) of the target goals with less adaptation. 6

Some of these systems can retrieve pieces of cases (e.g. [14]).

7

3.1 The Plan Retrieval Process

This section describes the Plan Retrieval algorithm. An example of plan retrieval is given in the next section. The Plan Retriever is initially given a set of features (FT ) to use to nd an old plan that achieves the target goals. FT typically includes the target problem's goals (GT ) and any relevant features of the initial situation/state (ST ). The basic (recursive) process used by the Plan Retriever component is: 1. Probe memory using the set of target features F (initially FT ), which includes G (initially GT ), a nonempty set of goals, and S , a set of situational features (initially ST ). The probe is translated into a query to be processed by the PARKA Structure Matcher which returns a set of candidate plans (C ) that match the probe.7 Each plan returned must exactly match at least one goal in G. If C is nonempty, go to Step 3 else go to Step 2. 2. If C is empty, attempt to generalize one or more of the features in F using knowledge from the is-a hierarchy of concepts. If successful, repeat from Step 1 using as the probe F = F with one or more of its features generalized. If it is not possible to generalize any features, abort and add the goals in G to UT , the set of unachieved target goals. 3. Rank the members of C using a (domain-speci c) similarity metric (e.g., a weighted sum of the features in F matched). Choose plan P , the highest ranking member of C . 4. Compare the goals P achieves, with G. Let AP be the subset of goals in G that P achieves. If P achieves goal gP that is identical to (or an abstraction of) some goal g 2 G, and some source plan P 2 SP (the set of \source" plans) achieves gP 0 that is also identical to (or an abstraction of) g , then choose whichever plan achieves the goal (gP or gP 0 ) that is closest to g. Add (P; AP ) to SP . 5. Let U = G ? AP , the set of goals that P did not achieve directly. If U is empty, exit else for each goal in U , repeat from Step 1 using as the probe F = U [ S . 0

0

0

7 The probe may actually be translated into multiple queries. The initial probe (in Step 1) returns cases which contain complete plan(s). Subsequent probes return plans which may be component plans.

8

The process terminates with SP , the set of source plans selected. If SP is empty, no old plan was found to use as the basis for the new plan. In this event other (non-case-based) methods must be used to create the new plan. With a suciently large casebase, this should happen infrequently. Hence it is important that the retrieval methods used can scale up to very large casebases, as CaPER's parallel methods can (see Section 4). A large casebase with a range of cases also increases the chance of cases being found in memory that are highly similar to the target problem and thus requiring less adaptation. An important feature of CaPER's plan retrieval process is that memory may be accessed multiple times (i.e., for each execution of Step 1) at low cost using PARKA's parallel retrieval procedures. Many CBP systems with serial retrieval procedures can only aord to access memory once, retrieving only a single old plan. This plan may achieve only a subset of the goals in GT and thus require extensive adaptation to achieve the remaining goals. CaPER's plan retrieval process, in contrast, can return multiple old plans which, when merged, are the basis for the new plan. Thus there will likely be few goals not achieved (either directly or approximately) by some source plan in SP .8 The unachieved goals, those in UT , will need to be achieved by other, non-case-based means. The source plans retrieved by the Plan Retriever are merged into a single new plan by the Plan Merger. Some (domain-dependent) amount of work will be required for the Plan Adapter component to detect and handle interactions between the merged plans (see Section 6).

3.2 An Example of Plan Retrieval

In this example from our car construction domain, the target problem is to build a car with a sedan frame, hard top, 8 cylinder turbo engine, A/C, and a sunroof. One relevant feature of the initial situation is the place the car is to be made | the Detroit factory, in this case. The plan retrieval process is invoked with GT = fsedan frame, hard top, 8 cyl. turbo engine, A/C, sunroofg and ST = fplace Detroit-factoryg. In Step 1 memory is probed using FT = GT [ ST . No candidate cases are found with these features. In Step 2 the feature \8 cyl. turbo engine" is generalized to \8 cyl.

For each (P; AP ) in SP , plan P must be adapted if there is some goal g 2 AP for which P achieves some abstraction of, gP . P may also need to be adapted if it achieves goals that are not related to ones in GT . In this case, the parts of P that achieve these super uous goals may need to be removed. 8

9

engine" (using the knowledge from the concept taxonomy that an 8 cyl. turbo engine \is-a" 8 cyl. engine). CaPER uses a heuristic from the domain that states to generalize this feature rst since the type of engine is deemed the least important goal (i.e., has the least impact for the plan). Step 1 is repeated with the new probe F , which has the features of FT with \8 cyl. engine" replacing \8 cyl. turbo engine". This query also fails and the feature \8 cyl. engine" is generalized (maximally) to \engine". Step 1 is repeated and the candidate cases listed below are returned (as set C ).  Case: Case-Build-Car-1; E-plan: Build-Car-1; Car: Car-1 (sedan frame, hard top, 4 cyl. engine, A/C, sunroof, luggage rack); Place: Detroit-factory; Plan Status: Successfully executed; Similarity Score: 5 1=3.  Case: Case-Build-Car-4; E-plan: Build-Car-4; Car: Car-4 (sedan frame, hard top, 4 cyl. engine, A/C, sunroof, luggage rack); Place: Seattle-factory; Plan Status: Successfully executed; Similarity Score: 4 1=3.  Case: Case-Build-Car-8; E-plan: Build-Car-8; Car: Car-8 (sedan frame, hard top, 4 cyl. engine, A/C, luggage rack); Place: Seattlefactory; Plan Status: Successfully executed; Similarity Score: 3 1=3. In Step 3 these plans are ranked using a similarity metric for this domain. This is a weighted sum of how many target features in FT are present, in each retrieved source plan. A candidate source plan is awarded 1=(1 + d) points for each of its features that matches, at some level of abstraction, a feature in the retrieval probe | d is distance in the concept abstraction hierarchy (i.e., the number of is-a links) between the probe feature and its corresponding target feature. If the probe feature is the target feature, d = 0. For example, the above plans have the feature \4 cyl. engine" which is a child of the probe feature \engine". Recall that probe feature \engine" was generalized from the target feature \8 cyl. turbo engine". Because \8 cyl. turbo engine" is the grandchild of \engine" in the abstraction hierarchy, d = 2, and 1=(1 + 2) = 1=3 points are added to each case's similarity score. Dividing by (1 + d) gives more weight to more speci c matches. Ease of computation is the main advantage of using this simple static similarity metric, currently computed serially for each plan returned. The eectiveness of this similarity metric in selecting useful old plans for this and other domains remains an open, empirical question. 0

10

The highest ranking plan, Build-Car-1 (a complete plan from Case-BuildCar-1), is selected in Step 3 and contains the following primitive actions:9 1. 2. 3. 4. 5. 6. 7.

build-hard-top install-sunroof install-ac-compressor-4c install-4c-pistons build-4c-block assemble-4c-engine build-sedan-frame

8. build-body 9. paint-exterior 10. install-luggage-rack 11. install-engine 12. connect-ac 13. install-wiring

In Step 4 it is determined that this plan achieves all of the goals in GT except that it builds a car with a 4 cyl. engine, instead of the target 8 cyl. turbo engine. Plan Build-Car-1 is added to SP . In Step 5 it is determined that U =f8 cyl. turbo engineg so Step 1 is repeated with F = U [ ST . The probe is successful and Step 3 returns the plan Build-Engine-2 (a subplan of plan Build-Car-2 in Case-Build-Car-2), a plan for building an 8 cyl. turbo engine with primitive actions: 0

1. 2. 3. 4.

build-8c-block install-8c-pistons install-turbo assemble-8c-engine

Plan Build-Engine-2 will replace plan Build-Engine-1, the subplan for building the 4 cyl. engine in plan Build-Car-1. The Plan Merger combines these plans and produces the new plan: 1. build-8c-block 8. build-sedan-frame 2. install-8c-pistons 9. build-body 3. install-turbo 10. paint-exterior 4. assemble-8c-engine 11. install-engine 5. build-hard-top 12. connect-ac 6. install-sunroof 13. install-wiring 7. install-ac-compressor-8c Note that in this \toy" domain it is assumed that cars are being built individually (i.e., not on an assembly line), and thus the order of actions may vary from plan to plan. 9

11

One characteristic of our simplistic car construction domain is that a plan for building a car contains relatively modular (i.e., non-interacting) subplans for building the various components of the car. Because the interactions between them are few, component plans from dierent cases can be combined (as in the above example) with less eort required to handle interactions in the resulting plan. This modularity assumption, however, does not hold in other domains in which the component plans can be highly interleaved. Problems in the transport logistics domain have a wide range of goals and highly variable initial situations | i.e., the initial locations of vehicles and packages. The abstract relationships between the objects involved may be more important for retrieving analogous plans than the particular objects and locations themselves. The better analogies are often those in which the two analogues have underlying, or \structural", similarities[4]. CaPER is able to use relevant structural relationships between domain entities as part of the memory probe. Systems with pre-indexed memories, however, would require cases to have been indexed by all such relationships.

4 Empirical Results To test the eciency and scalability of CaPER's retrieval procedures, several sample queries in our transport logistics domain10 were processed. The purpose of these experiments was to determine the absolute time for retrieval probes (queries) and to determine the scalability of parallel retrieval methods to large casebases. The test queries, chosen to be representative of those issued by the planner, were (in their English equivalents): Q1: nd all top-level plans involving 2 or more packages Q2: nd all plans using a particular airport Q3: nd all top-level plans using 2 or more trucks Q4: nd all plans for getting an object between locations in the same city Q5: nd all plans for getting an object between locations in dierent cities Q6: nd all top-level plans where a truck and an object are in the same location in the initial situation 10

This domain was based on that used in [15].

12

For example, one query (Q2) was to nd all plans using a particular airport. This query might be useful in avoiding plans that used an airport that is closed in the current situation. The sample transport logistics queries are considerably more structurally and computationally complex than those used for the car construction domain. The added computational complexity is due to combinatorial eects in matching objects in the plans to probe variables.11 These queries were issued as probe graphs for the PARKA Structure Matcher. Unindexed casebases of the various sizes were used. The number of cases, plans, and frames for each is shown in Table 1.12 Cases consist of plans generated by the Nonlin planner on randomly generated problems. Cases E-plans Frames 20 296 3357 40 523 4660 60 740 5899 80 982 7280 100 1213 8616

Table 1: Casebases of Transport Logistics Plans Used Queries were run using PARKA running on a CM-2 with 32,000 virtual processors (16,000 physical processors) and also using a highly optimized serial implementation of PARKA13 . Note that we are not doing a direct comparison of the time for a particular query/casbase run in serial to the same query/casebase in parallel. The results are shown in Figures 3 and 4. These results show absolute parallel times ranging from 0.5 to 1.6 seconds, on the larger casebase. Clearly these times are fast and the cost of frequent memory accesses will be small. The cost of frequent memory accesses using the serial implementation, in contrast, would be fairly expensive. These results also show that parallel times scale much better to larger casebases than do the serial ones. The performance of the serial procedures For example, matching a probe for the query \ nd all plans in which two packages were delivered" against a stored plan involving ve packages produces 20 possible variable bindings of the two probe variables for packages. 12 Note that the number of plans is important because each plan can be retrieved independently and is the functional equivalent of a case in a CBP system that stores cases monolithically. 13 Written in Macintosh Common Lisp and running on a Macintosh IIcx. 11

13

100000000

20 cases 40 cases

time in milliseconds (log scale)

10000000

60 cases 1000000

80 cases 100 cases

100000 10000 1000 100 10 1 Q1

Q2

Q3 Q4 queries on each casebase

Q5

Q6

Figure 3: Serial Retrieval Times for Sample Transport Logistics Plan Queries (shown on a logarithmic scale) was clearly worse than linear in the size of the casebase. The parallel procedures, in contrast, exhibited times growing better than logarithmically in the size of the casebase. Thus, using parallel methods, casebases in the thousands of cases can be accessed eciently. Results similar to those above were also found for the automobile assembly domain [1]. While a serial implementation using an pre-indexed memory might perform better than our serial implementation O(log n) in the number of cases if a balanced discrimination tree were used, such a system would suer from the problems described in Section 1.2.

5 Related Work Closely related to work done in CBR is work done in memory-based reasoning (MBR). MBRTalk [16] is a MBR system for speech pronunciation that also uses massive parallelism to access a large, unindexed memory of cases residing on the CM. MBRTalk retrieves cases that are the shortest distance 14

100000000

20 cases 40 cases

time in milliseconds (log scale)

10000000

60 cases 1000000

80 cases 100 cases

100000 10000 1000 100 10 1 Q1

Q2

Q3 Q4 queries on each casebase

Q5

Q6

Figure 4: Parallel Retrieval Times for Sample Transport Logistics Plan Queries (shown on a logarithmic scale) from a probe. Each case, in parallel, computes its distance from the probe using a simple similarity metric. CaPER, in contrast, computes similarity scores for candidate cases in serial (due to a case's being distributed across CM processors). MBRTalk uses a at representation of cases. CaPER uses a highly structured, semantic network representation of cases and a stronger domain model than MBRTalk. PARADYME [17], like PARKA, was a frame system that used the massive parallelism of the CM. One application of PARADYME was an unindexed memory of cases. PARADYME provided dierent procedures for case retrieval than those of CaPER/PARKA. PARKA's query algorithms are more complete and signi cantly faster than those used by PARADYME [11].

15

6 Future work The Plan Retriever is currently being tested on the transport logistics domain, which requires more complex case retrieval probes and similarity metrics. To support this, the PARKA Structure Matcher is being extended to allow inexact matching. Currently if an exact match to a query is not found, the query is relaxed (using a static heuristic) by the Plan Retriever, and the new query is then processed by the Structure Matcher. The Structure Matcher could be modi ed to provide information about cases matching parts of the query. This information could then be used to dynamically determine the way in which a particular query is to be modi ed. Several adaptation techniques are being investigated for use by CaPER's Plan Adapter component. These include saving, as part of a case, plan validation structure information similar to that which is saved in the PRIAR system[19]. This information, which is produced by Nonlin when generating plans for seeding the initial casebase, could be used by a generative planner to adapt the plan. Another technique being investigated is the storage of adaptation episodes in memory. These would contain information about how old plans were adapted to achieve target goals and could be retrieved and reused when similar adaptations are required in the future. Finally, the use of CaPER's fast retrieval mechanisms are being explored in a system which plans scienti c experiments using derivational analogy[18].

7 Conclusion CBP systems can take advantage of plan reuse where possible. The success of this approach depends on the ability to retrieve old cases that are similar to the target problem and to adapt these cases appropriately. Using unindexed memory and massively parallel retrieval mechanisms, CaPER can do fast, frequent retrievals using any features of the target problem. The result of this is that CaPER can retrieve cases that better match the target problem and thus require less adaptation. Empirical results indicate that the often in exible, special-purpose pre-indexing schemes required for the serial retrieval methods of traditional CBP systems can be abandoned in favor of parallel methods. These parallel methods can scale up to casebases of hundreds or thousands of cases. Larger casebases can improve the plans a CBP system produces by providing more cases to drawn upon. 16

Acknowledgements

This research was supported in part by grants from NSF(IRI-8907890), ONR (N00014-J-91-1451), AFOSR (F49620-93-1-0065), the ARPA/Rome Laboratory Planning Initiative (F30602-93-C-0039 and by ARI (MDA-903-92-R0035, subcontract through Microelectronics and Design, Inc.). Dr. Hendler is also aliated with the UM Institute for Systems Research (NSF Grant NSFD CDR-88003012).

References [1] B.P. Kettler, J.A. Hendler, W.A. Andersen, and M.P. Evett, \Massively Parallel Support for Case-Based Planning," Proceedings of the Ninth Conference on Arti cial Intelligence Applications (IEEE). Los Alamitos, California: IEEE Computer Society Press: 1993, pp. 3-11. [2] W.D. Hillis, The Connection Machine. Cambridge, Massachusetts: The MIT Press, 1985. [3] S. Vosniadou and A. Ortony, \Similarity and analogical reasoning: a synthesis," Similarity and Analogical Reasoning, Cambridge: Cambridge University Press, 1989, pp. 1-17. [4] D. Gentner, \The mechanisms of analogical learning," Similarity and Analogical Reasoning, Eds. S. Vosniadou and A. Ortony. Cambridge: Cambridge University Press, 1989, pp. 199-241. [5] B.H. Ross, \Some Psychological Results on Case-based Reasoning," Proceedings: Case-Based Reasoning Workshop (DARPA). San Mateo, California: Morgan Kaufmann, 1989, pp. 144-147. [6] A. Tate, \Project Planning Using a Hierarchic Non-linear Planner", Research Report No. 25, Department of Arti cial Intelligence, University of Edinburgh, 1975. [7] K.J. Hammond, \Case-based planning: A framework for planning from experience," Cognitive Science, Vol. 14, 1990, pp. 384-443. [8] M. Goodman, \CBR in Battle Planning," Proceedings: Case-Based Reasoning Workshop (DARPA). San Mateo, California: Morgan Kaufmann Publishers, 1989, pp. 264-269. [9] P.R. Thagard and K.J. Holyoak, \Why Indexing is the Wrong Way to Think About Analog Retrieval", Proceedings: Case-Based Reasoning Workshop (DARPA). San Mateo, California: Morgan Kaufmann, 1989, pp. 36-40. [10] D. Waltz, \Is Indexing Used for Retrieval?" Proceedings: Case-Based Reasoning Workshop (DARPA), San Mateo, California: Morgan Kaufmann, 1989, pp. 41-45.

17

[11] M.P. Evett, J.A. Hendler, and L. Spector, \Parallel Knowledge Representation on the Connection Machine," Journal of Parallel and Distributed Computing, 1993, forthcoming. [12] L. Spector, J.A. Hendler, and M.P. Evett, \Knowledge Representation in PARKA", Technical Report 2410, Department of Computer Science, University of Maryland at College Park, 1990. [13] L. Spector, B. Andersen, J. Hendler, B. Kettler, E. Schwartzman, C. Woods, and M. Evett, \Knowledge Representation in PARKA - Part 2: Experiments, Analysis, and Enhancements", Technical Report 2837, Department of Computer Science, University of Maryland at College Park, 1992. [14] M. Redmond, \Distributed Cases for Case-Based Reasoning: Facilitating Uses of Multiple Cases," Proceedings of the Eighth National Conference on Arti cial Intelligence. American Association for Arti cial Intelligence, 1990, pp. 304-309. [15] M.M. Veloso, Learning by Analogical Reasoning in General Problem Solving, Ph.D. disseration, CMU-CS-92-174, Dept. of Computer Science, Carnegie Mellon University, 1992. [16] C. Stan ll and D. Waltz., \Toward Memory-Based Reasoning," Communications of the ACM, Vol. 29, No. 12, December 1986, pp. 1213-1228. [17] J.L. Kolodner and R. Thau, \Design and Implementation of a Case Memory", Technical Report RL88-1, Thinking Machines Corporation, Cambridge, Massachusetts, 1988. [18] B. Kettler and L.D. Darden, \Protein Sequencing Experiment Planning Using Analogy," Proceedings of the First International Conference on Intelligent Systems for Molecular Biology. Menlo Park, California: AAAI Press, 1993, forthcoming. [19] S. Kambhampati and J.A. Hendler, \A validation-structure-based theory of plan modi cation and reuse," Arti cial Intelligence, Vol. 55, 1992, pp. 193-258. [20] D.B. Lenat and R.V. Guha, Building Large Knowledge-Based Systems. Reading, Massachusetts: Addison Wesley, 1990.

18

A The PARKA System PARKA [11] is a frame-based knowledge representation system which uses the massive parallelism of the Connection Machine (CM) to perform certain inferences extremely rapidly. PARKA performs property inheritance, settheoretic inferences, and inferences on partonomic relations. To date, the system has been implemented both on CM-2 and CM-5 parallel supercomputers. The Connection Machine supports a SIMD (Single Instruction stream, Multiple Data stream) programming model in which each processor (the CM-2 has up to 65536 of them) either performs the same instruction or sits idle. PARKA computes property inheritance inferences using a version of Touretzky's inferential distance ordering algorithm (IDO). Examples of such inferences are \Where are all the tanks?" or \How many trucks are yellow?". This algorithm uses the SIMD model of the CM-2 to spread markers across the semantic network. The propagation of these markers is controlled so that property values are passed to the proper frames along the is-a hierarchy. Inheritance inferences can be performed in O(d) where d is the depth of the semantic network along the is-a relation (assuming the number of processors exceeds the number of frames, so d is approximately equal to log(n)). Queries for the values of individual properties can be assembled to provide a \recognition" capability. These queries are useful for identifying frames which are similar to a target description. Such queries have the form p1 (x; c1) ^ p2 (x; c2) ^


^ pm (x; cm), where pi is a slot relating frame x with value ci . PARKA can compute these queries in time O(d + m) by \pipelining" (a technique where as many as d property inheritance queries can be processed simultaneously). 14 PARKA has been tested on randomly constructed semantic networks with as many as 256,000 frames. Since PARKA's algorithms are very sensitive to the topology (shape) of the semantic network, we set out to test it on the largest existing real knowledge base we could nd. For this test we used a subset of the Cyc knowledge base[20] which was compatible with PARKA's representation language. This knowledge base contained about 32,000 frames and 120,000 links. PARKA was able to perform complex recognition queries (up to 22 properties) on this knowledge base in less than one second. 14 Most serial systems take time O (mbd ) for such queries (b is the average downward branching factor of the semantic network).

19

The Structure Matcher (described in Section 2.1) was built on top of the primitive functions provided by PARKA. It allows queries to be speci ed in the form of a set of constraints, containing variables and constant values. The Matcher nds all structures in the knowledge base which structurally \look like" the query and returns them in the form of bindings for the query variables.

20

B Author Biographical Information Brian Kettler is a Research Assistant and Ph.D. student in the Computer Science Department at the University of Maryland at College Park. His research interests include arti cial intelligence planning systems, case-based reasoning, A.I. for molecular biology, and cognitive science. He is currently on leave from his position at IBM, where he is a Senior Associate Programmer. He received his B.S. in computer science from the University of Massachusetts at Amherst. He is a member of the American Association for Arti cial Intelligence and the Cognitive Science Society. He can be reached at the Computer Science Department, University of Maryland, College Park, MD 20742 (Internet e-mail: [email protected]). James Hendler is an Associate Professor with a joint appointment in the Computer Science Department and the Institute for Systems Research at the University of Maryland. His research interests include planning systems, mobile robots, and the use of massive parallelism to support A.I. systems. He is currently working on a textbook entitled \A.I. Planning Systems", to be published by Morgan Kaufmann. He received his Ph.D. in computer science from Brown University. He can be reached at the Computer Science Department, University of Maryland, College Park, MD 20742 (Internet e-mail: [email protected]). William Andersen is a Research Assistant and Ph.D. student in the Computer Science Department at the University of Maryland at College Park. His research interests are parallel algorithms to support case-based reasoning, memory-based models of agency for autonomous robots, adaptive systems, and cognitive psychology. He received his B.A. in Russian area studies from the University of Maryland at College Park. He is a member of the American Association for Arti cial Intelligence and the Association for Computing Machinery. He can be reached at the Computer Science Department, University of Maryland, College Park, MD 20742 (Internet e-mail: [email protected]). Matthew Evett is an Assistant Professor in the Computer Science and Engineering Department at Florida Atlantic University. His current research centers on the use of massive parallelism in symbolic arti cial intelligence and in knowledge representation in particular. He will receieve his Ph.D. in computer science from the University of Maryland at College Park. He is a member of the American Association for Arti cial Intelligence and the Association for Computing Machinery. He can be reached at the Dept. of Computer Science and Engineering, Florida Atlantic University, Boca 21

Raton, FL 33431 (Internet e-mail: [email protected]).

22