MA2: Recent Advances in AI Planning: A Unified View Subbarao Kambhampati 2/7: Knowledge-based...

MA2: Recent Advances in AI Planning: A Unified View Subbarao Kambhampati

2/7: Knowledge-based Planning

2

Life must be lived forward, but can only be understood backward.--Kierkegaard

Lp relaxation

3

Should we bother with Proof-based encodings?

• Clearly Graphplan-based encodings are better than backward-proof based encodings

– Because Graphplan does Mutex propagation– And mutex propagation is harder to do on direct

SAT• And yet, it is useful to know how to set up encodings directly—since if we

don’t know how to do directed consistency enforcement, then we at least know how to solve the problem

– Particularly useful for non-classical problems, where we haven’t yet found really effective mutex propagation procedures.

– If “neural networks are often the second best way of solving any problem”, you can say that direct SAT(or other) encodings are the second best way of solving planning problems

• Which is better than “no way at all”

Connections to Refinement Planning Framework

5

Disjunctive Planning• Idea: Consider Partial plans with disjunctive step, ordering, and auxiliary

constraints

• Motivation: Provides a lifted search space, avoids re-generating the same failures multiple times (also, rich connections to combinatorial problems)

– The “solution check” now involves searching through the space of all (exponentially many) minimal candidates of the plan to see if any of them is a solution

• Issues:

– Refining disjunctive plans• Graphplan (Blum & Furst, 95)

– Solution extraction in disjunctive plans• Direct combinatorial search• Compilation to CSP/SAT/ILP

6

Disjunctive Representations--Allow disjunctive step, ordering and auxiliary constraints in partial plans

< 1,In(A), > V < 1 ,In(B), >

1: Load(A)0

1: Load(B)0

1: Fly(R)0

1: Load(A)

2 : Load(B)0

3 : Fly(R)

or

or

1: Load(A)0

1: Load(B)0

In(x)@

In(x)@

In(B)

In(A)

Load(A)0

1: or

Load(B)

At(A,E)@1 V At(B,E)@1

7

Refining Disjunctive Plans (1)

1: Load(A)

2 : Load(B)0

3 : Fly(R)

or

or

1: Load(A)0

1: Load(B)0

1: Fly(R)0

1: Load(A)0

1: Load(B)0

1: Fly(R)0

2: Load(B)

2: Load(A)

1: Load(A)0

1: Load(B)0

2: Unload(A,E)

2: Unload(B,E)

1: Load(A)0

1: Load(B)0

2: Fly(R)

2: Fly(R)

1: Load(A)

2 : Load(B)0

3 : Fly(R)

or

or

1: Load(A)

2 : Load(B)

3 : Fly(R)or

or

or

4 : Unload(A,E)or

5 : Unload(B,E)

+ Maximum pruning power- Exponential refinement cost

INFEASIBLE

Indirect unioned approach

8

Refining Disjunctive plans (2)

1: Load(A)

2 : Load(B)0

3 : Fly(R)

or

or

1: Load(A,E)

2 : Load(B,E)

3 : Fly(R)or

or

or

4 : Unload(A,E)or

5 : Unload(B,E)

7 : Unload(B,M)

9 : load(B,M)

1: Load(A)

2 : Load(B)0

3 : Fly(R)

or

or

union of states

In(A)

In(B)

At(R,M)

At(R,E)At(A,E)At(B,E)

At(A,M)At(B,M)

+ Trivial to construct - Loss of pruning power (progressivity) => too many (minimal) candidates

=> Costlier solution extraction

Direct naive approach Put all actions at all levels --Proposition list contains all conditions

USED in S

ATPLA

N

6 : Unload(A,M)

8 : load(A,M)

9


1: Load(A)

2 : Load(B)0

3 : Fly(R)

or

or

1: Load(A)

2 : Load(B)

3 : Fly(R)or

or

or

4 : Unload(A,E)or

5 : Unload(B,E)

or

6 : Unload(A,M)or

7 : Unload(B,M)

1: Load(A)

2 : Load(B)0

3 : Fly(R)

or

or

union of states

In(A)

In(B)

At(R,M)


At(A,M)At(B,M)

+ Trivial to construct - Loss of pruning power (progressivity) => too many (minimal) candidates

=> Costlier solution extraction

Direct naive approach Put all actions at all levels --Proposition list contains all conditions

USED in S

ATPLA

N

10


1: Load(A)

2 : Load(B)0

3 : Fly(R)

or

or

+ Polynomial refinement time-- Loss of pruning power (progressivity)

Enforce partial 1-consistency Proposition list avoids unsupported conditions

In(A)

In(B)

At(R,M)


At(A,M)At(B,M)

1: Load(A)

2 : Load(B)0

3 : Fly(R)

or

or

1: Load(A,E)

2 : Load(B,E)

3 : Fly(R)or

or

or

4 : Unload(A,E)or

5 : Unload(B,E)

7 : Unload(B,M)

9 : load(B,M)

6 : Unload(A,M)

8 : load(A,M)

11


1: Load(A)

2 : Load(B)0

3 : Fly(R)

or

or

In(A)

In(B)

At(R,M)

At(R,E)

At(A,E)

At(B,E)

+ Polynomial refinement time higher pruning power+ Better balance between refinement cost and solution extraction cost

Enforce (partial) 2-consistency Proposition list maintains interactions between pairs of conditions

1: Load(A)

2 : Load(B)0

3 : Fly(R)

or

or

1: Load(A,E)

2 : Load(B,E)

3 : Fly(R)or

or

or

4 : Unload(A,E)or

5 : Unload(B,E)

7 : Unload(B,M)

9 : load(B,M)

6 : Unload(A,M)

8 : load(A,M)

Can do higher level consistency, but

it is rarely worth the cost


Digression: Domain-Independent vs. Domain Specific vs. Domain Customized

Domain independent planners only expect as input the description of the actions (in terms of their preconditions and effects), and the description of the goals to be achieved

Domain dependent planners make use of additional knowledge beyond action and goal specification – Domain dependent planners may either be stand alone programs

written specifically for that domain OR domain independent planners customized to a specific domain

– In the case of domain-customized planners, the additional knowledge they exploit can come in many varieties (declarative control rules or procedural directives on which search choices to try and in what order)

– The additional knowledge can either be input manually or in some cases, be learned automatically

Unless noted otherwise, we will be talking about domain-independent planning

Rev

iew


Improving Performancethrough Customization

Biasing the search with control knowledge acquired from experts– Non-primitive actions and reduction schemas – Automated synthesis of customized planners

» Combine formal theory of refinement planning and domain-specific control knowledge

Use of learning techniques– Search control rule learning– Plan reuse


User-Assisted Customization(using domain-specific Knowledge)

Domain independent planners tend to miss the regularities in the domain

Domain specific planners have to be built from scratch for every domain

An “Any-Expertise” Solution: Try adding domain specific control knowledge to the domain-independent planners

ACME

all p

urpos

e

planner

Ronco

Block

s world

Planner Ronco

logist

ics

Planner

Ronco

jobsh

op

Planner

AC-RO

Custom

izab

le

planner

Domain SpecificKnowledge


Domain Knowledge—Prescriptive or Suggestive?

One big question is whether the additional domain knowledge given to the planner – suggestive? (soft constraint on the search and solution)– OR– Prescriptiive? (hard constraint on the search and solution)

At the outset, it would seem like either way should be fine. However, handling soft-constraints correctly is harder than handling hard-constraints..

So, most knowledge-based planners use the domain knowledge as “prescriptive”


Task Decomposition (HTN) Planning The OLDEST approach for providing domain-specific

knowledge– Most of the fielded applications use HTN planning

Domain model contains non-primitive actions, and schemas for reducing them

Reduction schemas are given by the designer– Can be seen as encoding user-intent

» Popularity of HTN approaches a testament of ease with which these schemas are available?

Two notions of completeness:– Schema completeness

» (Partial Hierarchicalization)– Planner completeness

Travel(S,D)

GobyBus(S,D) GobyTrain(S,D)

Getin(B,S)

BuyTickt(B)

Getout(B,D)

BuyTickt(T)

Getin(T,S)

Getout(T,D)

Hitchhike(S,D)


Modeling Reduction Schemas

GobyBus(S,D)

t1: Getin(B,S)

t2: BuyTickt(B)

t3: Getout(B,D)

In(B)

Hv-Tkt

Hv-Money At(D)


(Thoroughly) Mixed Motivations for HTN Planning

To model Partial domain knowledge (when the domainWriter doesn’t haveFull domain model)

To provide a grammarFor desirable solutions

To allow for use of Abstraction/Hierarchy in modeling

Abstraction used mostly for speedup

HTNs provde a naturalSubstrate for this,But there has beenLittle formal use of HTNs this way

Unless we put strong restrictions on HTN schemas it is hard to connect any notion of abstraction—such as Downward refinability-- to HTN schemas. (Since HTNs can allow recursive subgoals— e.g. Empty Truck reduced to get a package out, Empty Truck, conditions may not have any real connection to abstraction

This is about the only thingThat we can say about HTNsIf we don’t put any restrictionsOn the schemas. However, the question of Validation of schemas then isExternal to the planner since Schemas are supposedly Capturing what kinds of solutionsUsers like. It is not very clear that HTNs are the best way to express preferences on solutions anyway


A concretization is a task network produced by repeatedly reducing a non-primitive task until all tasks are primitive


Modeling Action Reduction

GobyBus(Phx,Msn)Get(Money) Buy(WiscCheese)

At(Msn)

Hv-Money

t1: Getin(B,Phx)

t2: BuyTickt(B)

t3: Getout(B,Msn)

In(B)Hv-Tkt

Hv-MoneyAt(D)

Get(Money)

Buy(WiscCheese)

GobyBus(S,D)

t1: Getin(B,S)

t2: BuyTickt(B)

t3: Getout(B,D)

In(B)

Hv-Tkt

Hv-Money At(D)

Affi

nity

bet

wee

n re

duct

ion

sche

mas

and

plan

-spa

ce p

lann

ing


Dual views of HTN planning

Capturing hierarchical structure of the domain

– Motivates top-down planning» Start with abstract plans,

and reduce them Many technical headaches

– Respecting user-intent, maintaining systematicity and minimality

[Kambhampati et. al. AAAI-98]

» Phantomization, filters, promiscuity, downward-unlinearizability..

Capturing expert advice about desirable solutions

– Motivates bottom-up planning

» Ensure that each partial plan being considered is “legal” with respect to the reduction schemas

» Directly usable with disjunctive planning approaches

Connection to efficiency is not obvious

Relative advantages are still unclear... [Barrett, 97]


2/12


Changes to Plan-Space Refinement(in the presence of non-primitive tasks)


HTN vs. T-STN

Nau’s book talks about a “special” version of HTN called T-STN (Total-ordering STN)

T-STN schemas are HTN schemas where all the ordering relations between tasks are constrained to be “contiguity” constraints

– This means that the concretizations of different tasks cannot be interleaved– Bug or feature?

» From the planner’s point of view, it can be a feature Most of the difficulties in HTN planning come from the need to do plan-space refinement in the presence of non-primitive tasks (phantomization, conflict resolution etc..); eliminating that will make HTN planning a no-brainer

» BUT from the domain-writer’s point of view it is clearly a BUG Would have to write many more schemas

– Same is true of Yang’s unique main sub-action thing (although it is less drastic than T-STN)

(few cooking recipes are given with contiguity orderings—which means that you can’t do anything else while following the recipe)

The only HTN planners that use STN schemas are those from Nau’s group …

– SIPE and O-Plan use schemas with precedence orderings


HTN vs. STRIPS planning:Competing or Complementary?

Much of the discussion till now has been done with the assumption that HTN is just a way of doing STRIPS planning

HTN can also be seen as solving a different problem– Can develop plans at

various levels of abstraction

– Can model domains with partial domain knowledge

» What you consider “primitive” action may be changeable

What you thought was a correct plan may not be..


9/6


Full procedural control: The SHOP way

Travel by bus only if going by taxi doesn’t work outCan’t do any other actions between !hail and !ride

Shop provides a “high-level” programminglanguage in which the user can code his/herdomain specific planner

-- Similarities to HTN planning Uses T-STN schemas -- Order of use of reduction schemas can be specified The SHOP engine can beseen as an interpreterfor this language

[Nau et. al., 99]

Blurs the domain-specific/domain-independent divideHow often does one have this level of knowledge about a domain?


Non-HTN Declarative Guidance

Invariants: A truck is at only one location at(truck, loc1, I) & loc1 != loc2 => ~at(truck, loc2, I)

Optimality: Do not return a package to a location at(pkg, loc, I) & ~at(pkg,loc,I+1) & I<J => ~at(pkg,loc,j)

Simplifying: Once a truck is loaded, it should immediately move ~in(pkg,truck,I) & in(pkg,truck,I+1) & at(truck, loc, I+1) => ~at(truck, loc, I+2)

Once again, additional clauses first increase the encoding size but make them easier to solve after simplification (unit-propagation etc).

[Kautz & Selman, AIPS-98]


Case Study: SATPLAN with domain specific knowledge

Instantiate the domain specific rules as well, and then add them to the encoding.

Solve the full encoding…– Won’t the encoding size increase with domain spefic rules?

» Yes, but the new rules support a lot of simplification so that after simplification, the encoding size actually reduces!!

Example in Blocks world (from Kautz & Selman, AIPS-99)

BW-c:

Original: 4258 vars (10% increase) / 30986 clauses (300% increase)

Final (after simplification): 3526 vars 22535 clauses


SAT encodings of HTN planning Abstract actions can be seen as disjunctive constraints

– K-step encoding has each of the steps mapped to a disjunction of the non-primitive tasks

– If a step s is mapped to a task N, then one of the reductions of N must hold (**The heart of encoding setup**)

– + The normal constraints of primitive action-based encoding» Causal encodings seem to be a natural fit (given the causal

dependencies encoded in reduction schemas)

[Mali & Kambampati, AIPS-98]

Constraintsfrom action-based

encodings

HTN constraints

HTN

-com

plian

tS

olu

tion

s

Solu

tion

s f

or

acti

on

based

en

cod

ing

s


Solving HTN Encodings

[Kambhampati & Mali, AIPS-98]

# ClausesTIME

Puzzle: How can increasing encoding sizes lead to efficient planning?Abstract actions and their reductions put restrictions on the amount of step-action disjunction at the primitive level. --Reduction in step-action disjunction propagates e.g. Fewer causal-link variables, Fewer exclusion clauses…

Savings won’t hold if each non-primitive task has MANY reductions


Rules on desirable State Sequences: TLPlan approach

TLPlan [Bacchus & Kabanza, 95/98] controls a forward state-space planner

Rules are written on state sequences using the linear temporal logic (LTL)

LTL is an extension of prop logic with temporal modalities U until [] always O next <> eventually

Example:

If you achieve on(B,A), then preserve it until On(C,B) is achieved:

[] ( on(B,A) => on(B,A) U on(C,B) )


Keep growing “good” towers, and avoid “bad” towers

Good towers are those that do not violate any goal conditions

TLPLAN Rules can get quite boroque

How “Obvious”

are these ru

les?

The heart of TLPlan is the ability to incrementally and effectively evaluate the truth of LTL formulas.


Control rules for choice points

UCPOP developed a language in which user can write control rules that tell the planner what to do when it faces a specific sort of choice (e.g. between open conditions; establishers for open conditions etc.).

HSTS—a metric temporal planner that NASA used in its DeepSpace mission used similar control rule language.– The user needs to know the innards of the planner to write

these rules– The rules are hard to debug

» Learning such rules automatically is a way out


Folding the Control Knowledge into the planner: CLAY approach

Control knowledge similar to TLPlan’s

Knowledge is folded using KIDS semi-automated software synthesis tool into a generic refinement planning template– Use of program optimizations

such as » Finite differencing» Context-dependent &

independent simplification Empirical results demonstrate that

folding can be better than interpreting rules

Srivastava & Kambhampati, JAIR 97

Caveat: Current automated software

synthesis tools

have a very steep learning curve


Many User-Customizable Planners Conjunctive planners

– HTN planners » SIPE [Wilkins, 85-]» NONLIN/O-Plan [Tate et. al., 77-]» NOAH [Sacerdoti, 75]» Also SHOP (Nau et. al., IJCAI-99)

– State-space planners» TLPlan [Bacchus & Kabanza, 95; 99]» TALPlan [Kvarnstrom & Doherty, 2000]

– Customization frameworks

» CLAY [Srivastava & Kambhampati, 97] Disjunctive planners

– HTN SAT [Mali & Kambhampati, 98] – SATPLAN+Dom [Kautz & Selman, 98]

How do th

ey rela

te?

What a

re th

e tradeoffs?


With right domain knowledge any level of performance can be achieved...

HTN-SAT, SATPLAN+DOM beat SATPLAN…– Expect reduction schemas, declarative

knowledge about inoptimal plans TLPLAN beats SATPLAN, GRAPHPLAN

– But uses quite detailed domain knowledge

SHOP beats TLPLAN…(but not TALPlan)– Expects user to write a “program” for the

domain in its language » Explicit instructions on the order in

which schemas are considered and concatenated

Who g

ets

the c

redit

?

-The p

rovi

der

of dom

ain

know

ledge?

-The p

lanner

that

is c

apable

of usi

ng it?


Types of Guidance

Declarative knowledge about desirable or undesirable solutions and partial solutions (SATPLAN+DOM; Cutting Planes)

Declarative knowledge about desirable/undesirable search paths (TLPlan & TALPlan)

A declarative grammar of desirable solutions (HTN)

Procedural knowledge about how the search for the solution should be organized (SHOP)

Search control rules for guiding choice points in the planner’s search (NASA RAX)

Planner specific. Expert needs to understand the specific details of the planner’s search space

(largely) independent of the details of the specific planner[affinities do exist between specific types of guidance and planners)


Ways of using the Domain Knowledge As search control

– HTN schemas, TLPlan rules, SHOP procedures– Issues of Efficient Matching

To prune unpromising partial solutions– HTN schemas, TLPlan rules, SHOP procedures – Issues of maintaining multiple parses

As declartative axioms that are used along with other knowledge– SATPlan+Domain specific knowledge– Cutting Planes (for ILP encodings) – Issues of domain-knowledge driven simplification

Folded into the domain-independent algorithm to generate a new domain-customized planner– CLAY – Issues of Program synthesis


Conundrums of user-assisted cutomization

Which planners are easier to control?– Conjunctive planners are better if you have search control knowledge

» Forward State Space (according to TLPlan)

» Plan-space planners (according to HTN approaches)

– Disjunctive planners are better if your knowledge can be posed as additional constraints on the valid plans

» Which SAT encoding? HTN knowledge is easier to add on top of causal encodings

Which approach provides the best language for expressing domain knowledge for the lay user?– (Mine--no, no, Mine!)

What type of domain knowledge is easier to validate? When does it become “cheating”/ “wishful-thinking”

– Foolish not to be able to use available knowledge

– Wishful to expect deep procedural knowledge...


“Evaluating” KB-planners

Since the 2nd IPC, there has been a separate track for “knowledge-based planners” at the competition.– Basically only the TLPlan (and its variant TALPlan) and SHOP took

part (in comparison close to a dozen planners take part in the domain-independent track)

» In 2000, TALPlan won» In 2002, TLPlan won

– Quite controversial When SHOP does better than TLplan on Gizmo domain, what

does this mean?– That SHOP is a better planning algorithm than TLplan?– That Dana Nau knows Gizmo domain better than Faheim Bacchus?– That the easily available control knowledge in Gizmo domain is

more naturally representable as TLplan rules than SHOP schemas?


Are we comparing Dana & Fahiem or SHOP and TLPlan?

(A Critique of Knowledge-based Planning Track at ICP)

Subbarao KambhampatiDept. of Computer Science & Engg.

Arizona State UniversityTempe AZ 85287-5406

Click here to download TLPlan– Click here to download a

Fahiem

Click here to download SHOP– Click here to download a

Dana


The “I am not an anti-dentite”Disclaimers..

I think KB planning is a swell idea– I started my career with HTN planning…

I think the KB planning track at IPC is a swell idea– has done more to increase interest in KBplanning than the bi-annual polemics and laments about lack of

interest in “Knowledge-based planning”

I think Fahiem and Dana are REALLY swell – (in case they don’t buy that) I may already have a black-belt in Karate..

I’d rather learn from one bird how to singthan teach ten thousand stars how not to dance

--e.e. cummings


What are the lessons of KB Track?

If TLPlan did better than SHOP in ICP, then how are we supposed to interpret it?– That TLPlan is a superior planning technology over SHOP? – That the naturally available domain knowledge in the

competition domains is easier to encode as linear temporal logic statements on state sequences than as procedures in the SHOP language?

– That Fahiem Bacchus and Jonas Kvarnstrom are way better at coming up with domain knowledge for blocks world (and other competition domains) than Dana Nau?

We are NOT asking the right questions


Questions worth asking in KB planner comparisons (IMHO)

How easy/natural (for humans) is the language in which the planner accepts control knowledge?

How easy is it to “validate” the control knowledge being input to the planner?

Is the naturally available knowledge about a specific domain easily encoded in the language accepted by the planner?

Does the planner allow “any expertise” behavior—solving the problems even without any control knowledge, but improving performance with added control knowledge? (or is the control knowledge tightly intertwined with the domain physics?).


How/Why the competition is not asking the right questions…

The role of the knowledge-engineer is played by the same person(s) who wrote the planner. So, the question of how natural the specific language is for third-party knowledge engineers is largely unaddressed.

No reasonable time limits are placed on coming up with the control knowledge. So, we don’t learn much (or anything) about whether or not naturally available knowledge about a domain is easily representable in the language accepted by the planner.


Some suggestions for change…

Recruit third-party volunteers who will play the role of knowledge engineers for the KB planners.

– Ideally, we would like to have the same people writing the control knowledge for a given domain for all the competing approaches (so one knowledge engineer per domain rather than one knowledge engineer per planner).

(Alternative to above) Specify the control knowledge that is available, so all planners encode the same general knowledge.

– One idea might be to ask the designers of the domains (e.g. David Smith and his cohorts for the Satellite and Rovers domain) to provide, in english, what sort of control information they would like the planner to use.

Measure the time taken to write and validate the control knowledge. Analyze the knowledge encoded by the different KB planners for the

same domain– Characterize it in terms of (a) whether the knowledge is procedural or

declarative and (b) how hard would it be to “learn” the same knowledge.


Slides from here-on about “learning” domain knowledge were not used


Automated Customization of Planners

Domain pre-processing– Invariant detection; Relevance detection;

Choice elimination, Type analysis

» STAN/TIM, DISCOPLAN etc.

» RIFO; ONLP Abstraction

» ALPINE; ABSTRIPS, STAN/TIM etc. Learning Search Control rules

» UCPOP+EBL,

» PRODIGY+EBL, (Graphplan+EBL) Case-based planning (plan reuse)

» DerSNLP, Prodigy/Analogy

Mos

t of

the

wor

k ha

s be

en d

one

in the

cont

ext of

Con

junc

tive

Refi

nem

ent Pl

anne

rs

Read Terry Zimmerman’s “Learning assisted planning: Looking back, Taking Stock and Going Forward”


Symmetry & Invariant Detection

Generate potential invariants and test them – DISCOPLAN [Gerevini et. al.]

» Allows detection of higher-order mutexes

– Rintanen’s planner

» Uses model-verification techniques

– STAN/TIM

» Type analysis of the domain is used to generate invariants

– ONLP (Peot & Smith)

» Use operator graph analysis to eliminate non-viable choices


Abstraction

Idea– Abstract some details of the problem or actions. – Solve the abstracted version. – Extend the solution to the detailed version

Precondition Abstraction– Work on satisfying important preconditions first

» Importance judged by: Length of plans for subgoals [ABSTRIPS, PABLO] Inter-goal relations [ALPINE] Distribution-based [HighPoint]

– Strong abstractions (with downward refinement property) are rare– Effectiveness is planner-dependent

» Clashes with other heuristics such as “most constrained first”


Example: Abstracting Resources

Most planners thrash by addressing planning and scheduling considerations together

– Eg. Blocks world, with multiple robot hands

Idea: Abstract resources away during planning

– Plan assuming infinite resources

– Do a post-planning resource allocation phase

– Re-plan if needed

(with Biplav Srivastava)


Learning Search Control Rules with EBL

UCPOP+EBL

Explain leaf level failures Regress the explanationsto compute interior nodefailure explanations

Use failure explanations toset up control rules Problems: -- Most branches end in depth-limits >No analytical explanation >Use preference rules? -- THE Utility problem >Learn general rules >Keep usage statistics & prune useless rules

If Polished(x)@S & ~Initially-True(Polished(x)) Then REJECT Stepadd(Roll(x),Cylindrical(x)@s)

(Kambhampati, Katukam, Qu, 95)


Case-based Planning Macrops, Reuse, Replay

Structures being reused– Opaque vs. Modifiable

– Solution vs. Solving process (derivation) Acquisition of structures to be reused

– Human given vs. Automatically acquired Mechanics of reuse

– Phased vs. simultaneous Costs

– Storage & Retrieval costs; Solution quality


Case-study: DerSNLP

Modifiable derivational traces are reused Traces are automatically acquired during problem solving

– Analyze the interactions among the parts of a plan, and store plans for non-interacting subgoals separately

» Reduces retrieval cost– Use of EBL failure analysis to detect interactions

All relevant trace fragments are retrieved and replayed before the control is given to from-scratch planner

– Extension failures are traced to individual replayed traces, and their storage indices are modified appropriately

» Improves retrieval accuracy

( Ihrig & Kambhampati, JAIR 97)

Oldcases


DerSNLP: ResultsC

um

ula

tive

CP

U T

ime

0

5000

10000

15000

20000

25000

30000

35000

40000

45000

1 2 3 4 5 6

0

20

40

60120

% S

olv

ed

01020

30405060

708090

100

0

20 40 60 80

100

120

Lib

rary

Siz

e

0100200300400500600

0

20

40

60

80

100

120

Performance withincreased Training

% Solvability withincreased traning

(JAIR, 97)

Lib

rary

Siz

e

5 31

Problem size (#goals)


Reuse in Disjunctive Planning Harder to make a disjunctive planner commit to

extending a specific plan first Options:

– Support opaque macros along with primitive actions» Increases the size of k-step disjunctive plan» But a solution may be found at smaller k

– Modify the problem/domain specification so the old plan’s constraints will be respected in any solution (Bailotti et. al.)

– MAX-SAT formulations of reuse problem» Constrain the encoding so that certain steps may have

smaller step-action mapping and ordering choices» Causal encodings provide better support

[with Amol Mali]

MA2: Recent Advances in AI Planning: A Unified View Subbarao Kambhampati 2/7: Knowledge-based...

Documents

Transcript of MA2: Recent Advances in AI Planning: A Unified View Subbarao Kambhampati 2/7: Knowledge-based...