27%

1.6 Task Decomposition Strategies

Task Decomposition คืออะไร

Task Decomposition คือการแตก task ใหญ่ออกเป็น subtasks ย่อยที่จัดการง่ายกว่า — เป็นทักษะสำคัญของ AI architect เพราะ agent ตัวเดียวทำงานได้ดีที่สุดเมื่อ task ชัดเจนและ scope เหมาะสม task ที่ใหญ่เกินไปทำให้ agent หลงทิศ ใช้ tokens เยอะ และได้ผลลัพธ์ไม่ดี

หลักการคือ: ถ้า task ต้องใช้ความรู้หลาย domain, ต้อง access ข้อมูลมาก, หรือมี steps ที่ independent กัน — decompose มัน ถ้า task ทำจบใน 1-2 tool calls — ไม่ต้อง decompose

เมื่อไหร่ควร Decompose

ควร Decompose

  • Task ต้องการ > 10 tool calls
  • ต้องอ่านไฟล์มากกว่า 5 ไฟล์
  • มี subtasks ที่ independent (ทำ parallel ได้)
  • ต้องการ expertise ต่าง domain (code + design + writing)
  • Context window จะเต็มถ้าทำทั้งหมดใน agent เดียว

ไม่ควร Decompose

  • Task ง่าย ทำจบใน 1-2 steps
  • Subtasks มี dependency แน่น (ต้องรอผลลัพธ์กันตลอด)
  • Overhead ของ decomposition > benefit
  • Task ต้องการ context เดียวตลอด (เช่น long conversation)

Decomposition Patterns

1. Horizontal Decomposition (By Scope)

แบ่งตาม scope ของงาน — แต่ละ subtask ครอบคลุม area ต่างกัน:

# Task: "Review entire codebase for security issues"
subtasks = [
    "Review authentication code in src/auth/",
    "Review API endpoints in src/routes/",
    "Review database queries in src/models/",
    "Review file upload handling in src/uploads/",
]

# Execute in parallel — independent scopes
results = await parallel([
    lambda: agent(task, {label: f"reviewer-{i}"})
    for i, task in enumerate(subtasks)
])

2. Vertical Decomposition (By Stage)

แบ่งตามขั้นตอน — pipeline ที่ output ตัวหนึ่งเป็น input ตัวถัดไป:

# Task: "Write a technical blog post about MCP"
# Stage 1: Research
research = await agent("Research MCP protocol - features, use cases, examples")

# Stage 2: Outline
outline = await agent(f"Create blog post outline based on: {research}")

# Stage 3: Draft
draft = await agent(f"Write full draft following this outline: {outline}")

# Stage 4: Edit
final = await agent(f"Edit and polish this draft: {draft}")

3. Recursive Decomposition

Agent ตัว orchestrator decompose task เอง แล้วแต่ละ subtask อาจถูก decompose ต่อ:

DECOMPOSE_SCHEMA = {
    "type": "object",
    "properties": {
        "subtasks": {
            "type": "array",
            "items": {
                "type": "object",
                "properties": {
                    "description": {"type": "string"},
                    "depends_on": {"type": "array", "items": {"type": "integer"}},
                    "complexity": {"type": "string", "enum": ["simple", "complex"]}
                }
            }
        }
    }
}

# Let the orchestrator decompose
plan = await agent(f"""
Decompose this task into subtasks:
Task: {complex_task}

Rules:
- Each subtask should be completable by one agent
- Mark dependencies between subtasks
- Mark complexity (simple = one agent, complex = needs further decomposition)
""", {schema: DECOMPOSE_SCHEMA})

# Execute — further decompose complex ones
for subtask in topological_sort(plan.subtasks):
    if subtask.complexity == "complex":
        result = await decompose_and_execute(subtask)
    else:
        result = await agent(subtask.description)

4. Dependency Graph

ใช้ dependency graph เพื่อหา subtasks ที่ทำ parallel ได้:

# Task dependencies
#   A (research) → C (design)
#   B (analyze)  → C (design)
#   C (design)   → D (implement)
#   C (design)   → E (test plan)

# Round 1: A and B are independent → parallel
a, b = await parallel([
    lambda: agent("Research requirements"),
    lambda: agent("Analyze existing system")
])

# Round 2: C depends on A and B
c = await agent(f"Design solution based on: {a} and {b}")

# Round 3: D and E depend on C but not each other → parallel
d, e = await parallel([
    lambda: agent(f"Implement design: {c}"),
    lambda: agent(f"Write test plan for: {c}")
])

Key Concepts

  • Granularity Sweet Spot — subtask ที่ดีคือ 3-8 tool calls ต่อ subtask; เล็กเกินมี overhead มากเกินทำไม่ดี
  • Topological Sort — เรียงลำดับ execution ตาม dependencies; independent tasks ทำ parallel
  • Decomposition Overhead — การ decompose เองก็ใช้ tokens/time ถ้า task ง่ายอย่า overthink
  • Context Loss — ทุกครั้งที่ decompose จะ lose context; ต้อง pass ข้อมูลสำคัญ explicitly

Exam Tips

  • ข้อสอบจะให้ scenario แล้วถามว่าควร decompose อย่างไร — ดูว่ามี independent parts ไหม (parallel), มีลำดับไหม (pipeline)
  • Recursive decomposition เหมาะเมื่อไม่รู้ล่วงหน้าว่า task ซับซ้อนแค่ไหน
  • Dependency graph ช่วยหา critical path — bottleneck อยู่ที่ longest chain
  • เสมอ trade-off: decompose มาก = parallism ดี แต่ context loss + overhead มาก
  • ตอบคำถาม “เมื่อไหร่ไม่ควร decompose” ได้ด้วย — ง่าย, dependent, context-heavy tasks