Planning and task decomposition

6.2.4 · AI-ML › AI Agents & Tool Use

Task Decomposition Kya Hai?

WHY zaroorat hai iske?

1. Complexity management: Ek single LM call ki fixed context window hoti hai aur har forward pass mein limited effective reasoning depth hoti hai—jab ki chain-of-thought prompting ek model ko kai steps mein reason karne deta hai, ek agent jo external tools (search, code, APIs) call karta hai woh saari interactions ek pass mein fit nahi kar sakta. Decomposition kaam ko multiple grounded steps mein spread karta hai.
2. Failure isolation: Agar subtask 3 fail ho, tum scratch se restart nahi karte—bas us branch ko retry karo.
3. Parallelization: Independent subtasks concurrently run ho sakte hain (jaise, 3 APIs se simultaneously fetch karo).
4. Interpretability: Plan human-readable hota hai; tum dekh sakte ho kyun agent ne har step liya.

HOW kaise kaam karta hai? Agent teen strategies mein se ek use karta hai:

• Hierarchical planning: Top-down recursion (goal → subgoals → primitive actions).
• Forward chaining: Current state se shuru karo, actions apply karo jab tak goal reach na ho.
• Backward chaining: Goal se shuru karo, backward work karo required preconditions dhundhne ke liye.

Derivation: Kyun Decomposition Search Space Reduce Karta Hai

Problem: Goal $G$ aur har step par $n$ possible actions diye hain, depth $d$ par naive search ki complexity $O(n^d)$ hai.

Insight: Agar hum $G$ ko $k$ independent subgoals $\{G_1,G_2,\dots ,G_k\}$ mein decompose karein, jisme har ek depth $d/k$ require karta hai, complexity ban jaati hai:

Derivation:

1. Decomposition ke bina: Depth $d$ tak saare $n^d$ paths explore karo.
2. Decomposition ke saath:
   • $G_1$ ko $n^{d/k}$ paths mein solve karo.
   • $G_2$ ko independently $n^{d/k}$ paths mein solve karo.
   • Total: $k\cdot n^{d/k}$ paths.
3. Ye better kyun hai? $n=10,d=6,k=3$ ke liye:
   • Naive: $10^6=1,000,000$ paths.
   • Decomposed: $3\cdot 10^2=300$ paths.

Exponential $k$ mein linear ban jaata hai jab subgoals independent hon.

Planning Strategies Detail Mein

1. Hierarchical Task Network (HTN) Planning

HTN planning tasks ko methods ki hierarchy use karke decompose karta hai: har complex task ke multiple refinement rules hote hain.

Algorithm:

function HTN-Plan(task, state):
    if task is primitive:
        return [action(task)]
    else:
        for each method m that decomposes task:
            subtasks = m.decompose(task, state)
            subplans = [HTN-Plan(st, state) for st in subtasks]
            if all subplans succeed:
                return concatenate(subplans)
        return FAIL

Example: Goal: "Coffee banao"

• Method 1: [Paani ubalo, Beans piso, Brew karo]
• Method 2 (agar grinder nahi hai): [Paani ubalo, Instant coffee use karo]

Agent state.has_grinder check karta hai aur ek method chunता hai.

Ye step kyun? State check karna ensure karta hai ki plan current resources ke hisaab se feasible hai.

Decomposition (forward chaining):

1. Earthquake data API ke liye Search karo → USGS API milta hai.
2. 2023 ka data Fetch karo → HTTP GET request.
3. JSON Parse karo → magnitude field extract karo.
4. Histogram Plot karo → matplotlib call karo.
5. Image user ko Return karo.

Har step ka output agla feed karta hai. Agar step 2 fail ho (API down), retry karo ya CSV fallback switch karo.

2. ReAct: Reasoning + Acting

ReAct thought (kya karna hai ye reasoning) aur action (tool use) ko interleave karta hai.

Pattern:

Thought: Mujhe Tokyo ki current population dhundhni hai.
Action: search("Greater Tokyo Area population 2026")
Observation: ~37 million (Greater Tokyo Area, world's largest metro)
Thought: Ab New York metro area se compare karo.
Action: search("New York metropolitan area population 2026")
Observation: ~19.5 million
Thought: Tokyo ~17.5 million zyada bada hai.
Answer: Greater Tokyo Area (~37M) New York metro area (~19.5M) se roughly 90% bada hai.

"Thought" kyun? Ye next action ko current subgoal mein grounded banata hai, random tool spam nahi. Units ke baare mein note: hamesha specify karo ki tum kaunsi boundary mean kar rahe ho—city proper (Tokyo ~14M) vs. metro area (Greater Tokyo ~37M)—warna comparison meaningless hai.

Plan (backward chaining):

1. Chahiye: Grammy winner year $Y$ mein.
2. $Y$ paane ke liye: 1989 ka release year.
3. Action 1: search("1989 Taylor Swift release year") → 2014.
4. Action 2: search("Grammy Album of the Year 2015") → Beck ka Morning Phase (2015 mein awarded, 2014 albums ke liye).
5. Answer: Beck.

Ye order kyun? Hum Grammy winner nahi pooch sakte jab tak hum year nahi jaante.

3. LM-Modulo Framework

LLM ki creativity ko external verifiers (solvers, simulators) ke saath combine karta hai.

Loop:

1. LM ek plan $P$ propose karta hai.
2. Verifier $P$ check karta hai (jaise, code run karo, constraints check karo).
3. Agar valid hai, $P$ execute karo. Warna, LM error feedback ke basis par refine karta hai.

Example: Kitchen mein robot actions plan karna.

• LLM: "Mug uthao, coffee daalo, mug table par rakho."
• Verifier (physics sim): "Collision! Mug table ke andar hai."
• LLM (revision): "Mug uthao, table ke upar position par lo, mug niche karo, release karo."

Ye step kyun? Verifier infeasible plans ko real execution se pehle pakadta hai (robots ke liye safety-critical).

Common Mistakes

Example:

• Bad: "2+2 add karo" → [Input parse karo, Operation identify karo, Addition execute karo, Output format karo]
• Good: Bas calculate(2+2) call karo.

Example:

• Goal: "Paper X summarize karo aur paper Y se compare karo."
• Subtasks:
  • $S_1$: Paper X fetch karo.
  • $S_2$: Paper Y fetch karo.
  • $S_3$: X summarize karo ($S_1$ par depend karta hai).
  • $S_4$: Y summarize karo ($S_2$ par depend karta hai).
  • $S_5$: Summaries compare karo ($S_3,S_4$ par depend karta hai).
• Correct order: $S_1\parallel S_2$ run karo, phir $S_3\parallel S_4$, phir $S_5$.

Example:

• Plan: [Wikipedia search karo, Info extract karo, Source cite karo]
• Failure: Wikipedia "Page not found" return karta hai.
• Replan: [Google Scholar search karo, PDF download karo, Info extract karo, Source cite karo]

Active Recall Flashcards

#flashcards/ai-ml

AI agents mein task decomposition kya hai? :: Ek complex goal ko simpler, executable subtasks ke DAG mein todna jisme clear dependencies hon.

1. Todo: "Pehle base banaunga, phir diwaaren, phir towers, phir chhat."
2. Order matters: Tum chhat nahi laga sakte pehle diwaaren hone se! Toh tum sequence mein karte ho.
3. Chalte chalte check karo: Base banane ke baad, check karo—theek dikh raha hai? Kya ye mazboot hai? Nahi toh, aage badhne se pehle theek karo.
4. Agar kuch toot jaaye: Maan lo ek tower gir jaata hai. Tum poora castle nahi phenkte! Bas us tower ko rebuild karo.

Yahi AI agents bade tasks ke saath karte hain. Ye inhe steps mein split karte hain, order mein karte hain, apna kaam check karte hain, aur galtiyan theek karte hain. Bina plan ke, AI bas randomly guess karta aur shayad fail ho jaata. Plan ke saath, ye LEGO instructions hone jaisa hai—use exactly pata hai next kya karna hai.

Connections

• 6.2.01-Tool-augmented-LMs: Task decomposition decide karta hai kab aur kaunse tools call karne hain.
• 6.2.03-Multi-agent-systems: Har agent ka apna planner ho sakta hai; coordination ke liye team level par planning chahiye.
• 5.3.02-Chain-of-thought-prompting: CoT single-call multi-step reasoning hai; agent planning external actions ko reasoning ke saath interleave karke add karta hai.
• 6.2.05-Memory-in-agents: Long-term memory past plans aur outcomes store karta hai future decomposition improve karne ke liye.
• 8.1.03-Reasoning-under-uncertainty: Plans ko uncertain outcomes account karne chahiye (actions par probability use karo).
• Classical AI: HTN planning STRIPS (1971) se, means-ends analysis Newell & Simon (1961) se.

Key Takeaway: Planning ek intractable search problem ko ek structured, verifiable process mein transform karta hai. Agent ki intelligence sirf act karne mein nahi hai, balki decide karne mein hai ki next kya karna hai aur recognize karne mein hai ki kab revise karna hai.

Concept Map