Task Decomposition #37

Trả lời ngắn: Task Decomposition là cách biến một goal lớn thành task graph gồm các subtask có đầu vào, đầu ra, dependency và acceptance test rõ. Mỗi phần phải tạo deliverable dùng được cho phần sau. Kết quả chỉ hoàn tất khi bước join kiểm đủ, nhất quán và đúng goal ban đầu.

Đọc xong, bạn sẽ hiểu:

• Task Decomposition khác planning và checklist ở đâu.
• Một subtask chạy được cần input/output contract nào.
• Cách tách goal thành DAG có phần tuần tự và song song.
• Khi nào đang tách quá ít, quá nhiều hoặc sai ranh giới.

Lưu ý giáo dục: Bài dùng task và dữ liệu giả, không gửi email hay ghi lịch thật. Decomposition không bảo đảm agent đúng. Hệ production vẫn cần giới hạn quyền, chi phí, concurrency, phép kiểm ở điểm ghép và người phê duyệt cho hành động nhạy cảm.

1. Task Decomposition là gì?

a. Goal lớn thường che mất nhiều loại công việc

Bạn giao agent: “Tạo bản tin workshop tuần này.” Câu này nghe như một việc, nhưng bên trong có thu thập sự kiện, xác minh ngày, hiểu người đọc, chọn nội dung, viết, kiểm link và duyệt trước khi gửi. Nếu model làm tất cả trong một lượt, một nguồn sai có thể chui thẳng vào bản cuối.

Task Decomposition tách goal thành các subtask. Subtask là đơn vị công việc tạo ra một đầu ra quan sát được. Các subtask nối với nhau thành task graph; cạnh nối biểu diễn dependency, tức phần nào cần kết quả của phần nào.

Hình 1 — Goal chỉ trở nên chạy được khi mỗi node tạo deliverable và bước join có phép kiểm.

b. Task graph không chỉ là danh sách đánh số

Danh sách 1→2→3 ép mọi việc chạy tuần tự. Task graph cho thấy node nào độc lập, node nào phải chờ. Graph không có vòng phụ thuộc được gọi là DAG.

Ví dụ “xác minh lịch” và “tóm tắt nhu cầu độc giả” có thể chạy song song. “Chọn workshop” phải chờ cả hai. Đây là thông tin vận hành mà một checklist đơn giản không thể hiện đủ.

c. Planning và decomposition khác nhau

Planning có thể chứa graph; decomposition thiết kế node và ranh giới.

2. Một subtask chạy được cần contract nào?

a. Sáu trường của Subtask Card

Hình 2 — Card trả lời ai cần đầu ra này, thay vì chỉ ghi một động từ mơ hồ.

Một node chạy được nên có:

• Goal: node phải tạo thay đổi gì.
• Input contract: dữ liệu, format và nguồn được phép dùng.
• Output contract: deliverable, schema hoặc cấu trúc phải trả.
• Dependency: node nào phải hoàn tất trước.
• Acceptance test: điều kiện pass/fail quan sát được.
• Consumer: node hoặc người nào dùng output tiếp theo.

“Nghiên cứu workshop” chưa phải subtask tốt. “Trả bảng title/date/source/status từ ba nguồn cho node Selection” rõ hơn vì có output và consumer.

b. Tách theo deliverable, không tách theo động từ

Hai node “tìm thông tin” và “đọc thông tin” thường không có ranh giới hữu ích; cả hai cùng đụng một nguồn và không tạo handoff rõ. Ngược lại, “Event Table” và “Audience Criteria” là hai deliverable độc lập, có thể kiểm riêng rồi ghép.

Ranh giới tốt giảm bất định hoặc phạm vi lỗi, giúp retry đúng phần fail.

c. Dependency phải nói rõ dữ liệu được truyền

Edge A → C không chỉ nghĩa là A chạy trước C. Nó phải nói C nhận gì từ A. Nếu C cần verified_events[] nhưng A chỉ trả đoạn văn, graph có cạnh mà contract vẫn gãy.

Node thiếu input phải ở trạng thái blocked_dependency, không tự bịa dữ liệu để tiếp tục.

d. Join contract khóa bước ghép kết quả

Join là bước ghép kết quả nhiều nhánh. Nó phải kiểm đủ phần, không mâu thuẫn, mỗi dữ kiện có nguồn và kết quả cuối trả lời đúng mục tiêu. Ví dụ: mỗi workshop được chọn phải có một dòng trong bảng sự kiện, phù hợp ít nhất một tiêu chí người học và còn đường dẫn nguồn.

Nếu hai node cho ngày khác nhau, join phải báo conflict. Không được chọn ngày nghe hợp lý hơn rồi giấu mâu thuẫn.

3. Ví dụ: tách goal thành task graph

a. Goal và acceptance criteria giả

Goal: tạo bản nháp bản tin gồm đúng hai workshop trong bảy ngày tới cho người mới học AI. Chưa gửi. Bản nháp phải có tên, ngày, một câu lý do chọn và link nguồn; mọi ngày phải được xác minh.

Ta tạo năm node:

1. A — Event Collection: trả Event Table từ danh sách giả.
2. B — Audience Criteria: trả ba tiêu chí phù hợp người mới.
3. C — Selection: chọn hai workshop từ output A theo B.
4. D — Draft: viết bản tin từ output C.
5. E — Join & Verify: kiểm số lượng, ngày, source và goal coverage.

b. Dependency và phần chạy song song

A và B không phụ thuộc nhau nên có thể fan-out song song. C cần cả A và B. D cần C. E cần A, C và D để so bản cuối với nguồn.

Graph là A + B → C → D → E, thêm cạnh A → E để verifier đối chiếu dữ liệu gốc.

c. Trace một handoff

A trả ba event, trong đó một event có status=UNVERIFIED. B trả tiêu chí: nội dung nhập môn, không yêu cầu code, thời lượng dưới hai giờ. C chỉ được chọn event VERIFIED; nó chọn hai dòng và ghi criterion ID.

D viết đúng hai mục. E phát hiện mục thứ hai ghi “Thứ Năm” trong khi Event Table là “Thứ Sáu”. E không viết lại toàn bộ; nó tạo Error Packet cho field ngày và chuyển sang Self Correction #36. Sau repair, E chạy lại join assertions.

d. Khi nào graph hoàn tất?

Graph hoàn tất khi E pass mọi assertion và không còn dependency chưa giải quyết. Thiếu hai event verified thì trả blocked_insufficient_input, không bù event tưởng tượng.

4. Lỗi phổ biến, guardrail và điều kiện dừng

a. Tách quá ít, đúng mức và quá nhiều

Hình 3 — Ranh giới tốt tạo deliverable kiểm được; số node nhiều không tự làm graph tốt hơn.

• Quá ít: một node vừa research, quyết định, viết và gửi; lỗi lan rộng.
• Đúng mức: mỗi node có deliverable, acceptance và consumer rõ.
• Quá nhiều: tách từng câu hoặc từng field thành node; overhead handoff lớn hơn công việc.

Theo Decomposed Prompting, tính module cho phép tối ưu hoặc thay thế handler theo subtask. Nhưng module chỉ hữu ích khi ranh giới có ý nghĩa.

b. Bốn lỗi graph thường gặp

• Hidden dependency: node dùng dữ liệu chưa khai báo từ node khác.
• Circular dependency: A chờ B trong khi B cũng chờ A.
• Orphan output: node tạo artifact nhưng không consumer nào dùng.
• Lossy handoff: output bỏ source, version hoặc trạng thái chưa biết.

Join by prose ghép đoạn văn không schema hay assertion; thiếu một nhánh vẫn khó bị phát hiện.

c. Guardrail cho fan-out và side effect

Song song chỉ dành cho node độc lập. Đặt concurrency, budget và rate limit. Mỗi worker nhận quyền tối thiểu; side effect nằm sau verify và human approval để giảm rủi ro.

Theo Anthropic, parallelization phù hợp khi các phần có thể chạy đồng thời hoặc cần nhiều góc nhìn; orchestrator-workers phù hợp khi số subtask không biết trước. Cấu trúc phải phục vụ loại task, không phải để trông “agentic”.

d. Khi nào dừng tách?

Dừng khi node có một deliverable rõ, một owner/handler, input vừa context, acceptance test đủ kiểm và retry có thể cô lập. Gộp lại nếu hai node luôn dùng cùng input, luôn chạy cùng nhau và không thể kiểm riêng.

Escalate khi dependency mâu thuẫn, thiếu ground truth, graph vượt budget hoặc join cần quyết định trách nhiệm con người.

5. Bài tập 15 phút: điền Subtask Card

a. Công cụ và dữ liệu

Dùng giấy, Markdown hoặc bảng tính miễn phí. Goal giả: “Tạo bản tin workshop tuần này.” Không dùng dữ liệu cá nhân, không ghi lịch và không gửi email thật.

b. Vẽ graph năm node

Viết A Event Collection, B Audience Criteria, C Selection, D Draft và E Join & Verify. Nối A+B→C→D→E, thêm A→E. Khoanh A/B là phần có thể song song.

c. Mẫu đối chiếu: Subtask Card đã điền

d. Tự kiểm graph

• Mỗi node có deliverable, không chỉ có động từ chưa?
• Mỗi output có consumer chưa?
• Dependency có nói dữ liệu truyền qua không?
• Join có kiểm đủ, nhất quán, provenance và goal chưa?
• Node side effect có nằm sau verify và approval chưa?

Nếu không chỉ ra được output của một node, hãy gộp hoặc viết lại node đó. Nếu graph có hơn mười node cho bài tập nhỏ này, kiểm tra dấu hiệu over-decomposition.

6. Tổng kết: tách theo deliverable, nối bằng contract

a. Năm ý chính

• Task Decomposition tạo task graph, không chỉ tạo danh sách việc nhỏ.
• Subtask tốt có input, output, dependency, acceptance và consumer rõ.
• Ranh giới nên đi theo deliverable kiểm được và phạm vi lỗi cô lập.
• Fan-out chỉ an toàn khi node độc lập, quyền tối thiểu và có budget.
• Join phải kiểm completeness, consistency, provenance và goal coverage.

b. Câu hỏi tự kiểm tra

• Planning và decomposition khác nhau ở artifact nào?
• Vì sao “nghiên cứu workshop” chưa phải subtask tốt?
• Node A và B có thể chạy song song vì sao?
• Khi nào phải gộp node hoặc dừng graph?

c. Gợi ý đáp án

Xem gợi ý câu 1

Planning tạo đường đi và next step; decomposition thiết kế task graph cùng contract của từng node. → Xem mục 1.

Xem gợi ý câu 2

Nó không nói output, schema, acceptance hoặc consumer nên không tạo handoff kiểm được. → Xem mục 2.

Xem gợi ý câu 3

Event Collection và Audience Criteria không cần output của nhau; Selection mới cần cả hai. → Xem mục 3.

Xem gợi ý câu 4

Gộp khi hai node luôn dùng cùng input và không kiểm riêng; dừng khi deliverable, handler và acceptance đã rõ. → Xem mục 4.

d. Thuật ngữ cần nhớ

e. Nguồn tham khảo

• Zhou et al. — Least-to-Most Prompting
• Wang et al. — Plan-and-Solve Prompting
• Khot et al. — Decomposed Prompting
• Anthropic — Building effective agents

f. Học tiếp gì?

Xem lại Self Correction #36 nếu chưa rõ cách sửa một node fail mà không chạy lại cả graph. Bài tiếp theo là Long-running Agent #38: cách giữ state, checkpoint, lease và khả năng resume cho task kéo dài qua nhiều phiên.

Nhắc lại giáo dục: Graph đẹp không thay được evidence và quyền kiểm soát. Khi input thiếu, dependency xung đột hoặc side effect khó hoàn tác, dừng và hỏi người là kết quả đúng.