Bỏ qua để đến nội dung

1.6 Task Decomposition Strategies

Phân rã tác vụ là cách bạn bẻ một khối công việc phức tạp thành những mảnh mà hệ agentic xử lý nổi. Đề thi hỏi hai mô hình và yêu cầu bạn chọn đúng cái hợp với tác vụ trước mặt. Chọn sai thì kết quả hỏng theo những cách đoán trước được. Đề cũng hỏi một chế độ lỗi cụ thể — attention dilution — xuất hiện khi phân rã quá nông.

Mô hình 1: fixed sequential pipeline (prompt chaining)

Phần tiêu đề “Mô hình 1: fixed sequential pipeline (prompt chaining)”

Fixed sequential pipeline chia công việc thành các bước định sẵn, chạy theo thứ tự. Mỗi bước lấy output của bước trước làm input.

Cách chạy: workflow được định nghĩa từ trước. Bước 1 chạy, output của nó vào bước 2, output bước 2 vào bước 3, và cứ thế. Trình tự không đổi theo kết quả trung gian.

Ví dụ — pipeline review code:

  1. Với mỗi file, chạy một lượt phân tích cục bộ (style, bug, độ phức tạp).
  2. Sau khi mọi lượt cục bộ xong, chạy một lượt tích hợp xuyên file (luồng dữ liệu, tính nhất quán API, chuỗi import).
  3. Gom kết quả thành một báo cáo review thống nhất.

Hợp với: tác vụ có cấu trúc, đoán trước được, các bước biết sẵn từ đầu. Review code, xử lý tài liệu, pipeline trích xuất dữ liệu, kiểm tra tuân thủ đều hợp mô hình này.

Ưu điểm: nhất quán và đáng tin. Cùng một input luôn đi cùng một đường. Dễ debug — biết chính xác bước nào tạo ra output nào. Dễ giám sát — log được output của từng bước.

Hạn chế: không thích ứng được với phát hiện bất ngờ. Nếu bước 2 phát hiện thứ gì đó lẽ ra nên đổi cách làm ở bước 3, pipeline không điều chỉnh được. Các bước cố định bất kể dọc đường lòi ra chuyện gì.

Dynamic adaptive decomposition sinh ra các subtask dựa trên thứ phát hiện được ở từng bước. Kế hoạch tiến hóa theo mức độ hiểu bài toán của agent.

Cách chạy: agent bắt đầu từ một mục tiêu ở mức cao, khảo sát ban đầu, rồi lập kế hoạch dựa trên thứ nó tìm thấy. Khi thực thi, nó phát hiện thông tin mới có thể làm thay đổi các bước còn lại. Agent điều chỉnh kế hoạch theo.

Ví dụ — thêm test vào một legacy codebase:

  1. Vẽ bản đồ cấu trúc codebase (thư mục, module, phụ thuộc).
  2. Xác định các vùng tác động cao (module được dùng nhiều nhất, module nhiều bug nhất, critical path chưa có test).
  3. Lập kế hoạch test ưu tiên dựa trên bản đồ đó.
  4. Bắt đầu viết test. Phát hiện Module A phụ thuộc Module B, mà Module B chưa có test nào.
  5. Đảo ưu tiên: test Module B trước để test của Module A dựa vào được.
  6. Tiếp tục điều chỉnh khi các phụ thuộc và vấn đề mới lộ ra.

Hợp với: tác vụ khảo sát mở, chưa biết hết phạm vi từ đầu. Khám phá hệ thống cũ, security audit, dự án nghiên cứu, debug một codebase lạ đều hưởng lợi từ mô hình này.

Ưu điểm: thích ứng theo bài toán. Phát hiện và phản ứng được với độ phức tạp bất ngờ. Cho kết quả kỹ hơn với tác vụ mở, vì nó không ép bài toán vào một kế hoạch định sẵn.

Hạn chế: khó đoán hơn. Thời gian chạy dao động tùy theo thứ phát hiện được. Khó ước lượng thời điểm hoàn thành hay lượng tài nguyên. Khó debug hơn khi có sự cố.

Đề thi kiểm tra khả năng khớp mô hình với tác vụ:

Đặc điểm tác vụ Mô hình Lý do
Biết sẵn các bước, input có cấu trúc Fixed pipeline Tính nhất quán và độ tin cậy quan trọng hơn khả năng thích ứng
Mở, chưa biết phạm vi Dynamic decomposition Khả năng thích ứng là thiết yếu khi bài toán chưa được định nghĩa hết
Review code nhiều file Fixed pipeline Phân tích từng file rồi tích hợp xuyên file là quy trình đoán trước được
Khám phá legacy codebase Dynamic decomposition Phụ thuộc và vấn đề lộ dần trong lúc khảo sát
Trích xuất dữ liệu tài liệu Fixed pipeline Trường dữ liệu và định dạng đã định sẵn
Debug một hệ thống lạ Dynamic decomposition Chưa biết nguyên nhân gốc; việc điều tra phải thích ứng

Attention dilution là một chế độ lỗi cụ thể, xảy ra khi agent xử lý quá nhiều mục trong một lượt duy nhất. Kết quả là độ sâu không đồng đều — agent phân tích rất kỹ vài mục rồi bỏ lọt lỗi hiển nhiên ở các mục khác.

Triệu chứng đặc trưng:

  • Vài file đầu được nhận xét chi tiết, các file sau càng lúc càng hời hợt.
  • Một pattern bị gắn cờ là có vấn đề ở file này, trong khi đoạn code y hệt lại được duyệt ở file khác.
  • Bug hiển nhiên bị bỏ sót ở một số file, trong khi lỗi style vặt lại bị bắt ở file khác.

Vì sao xảy ra: model phân bổ attention cho toàn bộ các mục trong context. Khi số mục quá nhiều, attention cho mỗi mục giảm xuống. Mục đầu được ưu ái quá mức; mục sau bị đọc lướt.

Cách sửa: kiến trúc multi-pass. Chia việc thành hai tầng:

  1. Lượt phân tích cục bộ cho từng mục: phân tích riêng từng file (hoặc tài liệu, hoặc module) trong lượt của chính nó. Mỗi lượt dồn toàn bộ ngân sách attention vào một mục duy nhất.
  2. Lượt tích hợp xuyên mục: sau khi mọi lượt cục bộ xong, chạy một lượt riêng nhìn xuyên tất cả các mục để bắt các vấn đề cắt ngang (lỗi luồng dữ liệu, dùng pattern không nhất quán, phụ thuộc xuyên file).

Các lượt cục bộ bắt lỗi địa phương một cách nhất quán vì mỗi mục được cấp attention riêng. Lượt tích hợp bắt lỗi xuyên mục vì nó tập trung đúng vào quan hệ giữa các mục thay vì cố làm mọi thứ cùng lúc.

Một agent review code xử 14 file trong một lượt. Kết quả:

  • File 1–5: nhận xét chi tiết, dẫn số dòng cụ thể, chỉ ra bug, đề xuất cải thiện.
  • File 6–9: nhận xét vừa phải, có chỉ ra vài vấn đề nhưng phân tích kém kỹ hơn.
  • File 10–14: nhận xét hời hợt, bỏ sót cả bug null pointer hiển nhiên lẫn lỗ hổng SQL injection.
  • Một vòng forEach bị chê là kém hiệu quả ở File 3, trong khi đoạn code y hệt ở File 11 không bị nói gì.

Đây là attention dilution. Cách sửa không phải là model mạnh hơn, context window to hơn, hay prompt chi tiết hơn. Cách sửa mang tính cấu trúc: tách thành 14 lượt phân tích theo từng file (mỗi lượt tập trung một file) cộng thêm một lượt tích hợp xuyên file (kiểm tra luồng dữ liệu và tính nhất quán của pattern trên toàn bộ).

Cách multi-pass bắt được các bug null pointer ở File 10–14 (vì mỗi file có lượt riêng) và phát hiện sự đánh giá mâu thuẫn về forEach (vì lượt tích hợp kiểm tra đúng tính nhất quán pattern xuyên file).

Một agent review code xử 14 file, cho nhận xét chi tiết ở 5 file đầu nhưng bỏ sót bug hiển nhiên ở file 10–14. Nó cũng chê một vòng forEach là kém hiệu quả ở file này trong khi duyệt đoạn code y hệt ở file khác. Nguyên nhân gốc là gì và giải pháp phù hợp nhất là gì?

  • A. Context window của model quá nhỏ để chứa cả 14 file — nâng lên model có context window lớn hơn
  • B. Tách review thành các lượt phân tích cục bộ theo từng file cộng một lượt tích hợp xuyên file riêng, để tránh attention dilution
  • C. Thêm system prompt gắt hơn, nhấn mạnh phải review mọi file với cùng độ kỹ lưỡng
  • D. Giảm số file mỗi lượt review xuống 5 và xử tuần tự theo từng nhóm 5 file
Đáp án & giải thích

Đúng: B

  • A — Kích thước context window không phải vấn đề. Attention dilution xảy ra vì xử quá nhiều mục trong một lượt, cho độ sâu không đồng đều, bất kể model chứa được bao nhiêu context. Context to hơn không sửa được việc phân bổ attention lệch.
  • B — Kiến trúc multi-pass giải quyết attention dilution. Lượt theo từng file đảm bảo mỗi file được phân tích riêng và nhất quán. Lượt tích hợp xuyên file bắt lỗi luồng dữ liệu và pattern không nhất quán. Cách này xử cả hai triệu chứng: bug bị bỏ sót ở file sau và đánh giá pattern mâu thuẫn.
  • C — Cải thiện prompt không giải quyết attention dilution. Vấn đề gốc là xử quá nhiều mục trong một lượt — một vấn đề kiến trúc, đòi giải pháp cấu trúc chứ không phải giải pháp prompt.
  • D — Chia nhóm gần đúng hướng và xử được attention dilution trong từng nhóm, nhưng bỏ sót vấn đề giữa các nhóm. Không có lượt tích hợp xuyên file riêng thì lỗi luồng dữ liệu giữa các nhóm và tính nhất quán pattern trên cả 14 file vẫn không được xử lý.

Năm câu trắc nghiệm theo format đề thi về Task Decomposition Strategies. Chọn đáp án trước, rồi mở phần giải thích.

Một agent review code xử 14 file, cho nhận xét chi tiết ở 5 file đầu nhưng bỏ sót bug hiển nhiên ở file 10–14. Nó cũng chê một vòng forEach là kém hiệu quả ở file này trong khi duyệt đoạn code y hệt ở file khác. Nguyên nhân gốc và giải pháp phù hợp nhất là gì?

  • A. Context window của model quá nhỏ để chứa cả 14 file — nâng lên model có context window lớn hơn
  • B. Tách review thành các lượt phân tích cục bộ theo từng file cộng một lượt tích hợp xuyên file riêng, để tránh attention dilution
  • C. Thêm system prompt gắt hơn, nhấn mạnh phải review mọi file với cùng độ kỹ lưỡng
  • D. Giảm số file mỗi lượt review xuống 5 và xử tuần tự theo từng nhóm 5 file
Đáp án & giải thích

Đúng: B

  • B đúng vì kiến trúc multi-pass giải quyết attention dilution. Lượt theo từng file đảm bảo mỗi file được phân tích riêng và nhất quán. Lượt tích hợp xuyên file bắt lỗi luồng dữ liệu và pattern không nhất quán. Cách này xử cả hai triệu chứng.
  • A sai vì kích thước context window không phải vấn đề. Attention dilution xảy ra do xử quá nhiều mục trong một lượt, bất kể model chứa được bao nhiêu context.
  • C sai vì cải thiện prompt không giải quyết attention dilution. Vấn đề gốc mang tính kiến trúc và đòi giải pháp cấu trúc.
  • D sai vì chia nhóm xử được attention dilution trong từng nhóm nhưng bỏ sót vấn đề giữa các nhóm. Thiếu lượt tích hợp xuyên file, lỗi luồng dữ liệu giữa các nhóm và tính nhất quán pattern trên cả 14 file vẫn bị bỏ qua.

Một team cần thêm test vào legacy codebase với các phụ thuộc không có tài liệu. Mô hình phân rã nào phù hợp nhất?

  • A. Dynamic adaptive decomposition: vẽ bản đồ cấu trúc, phát hiện phụ thuộc, đảo ưu tiên khi độ phức tạp mới lộ ra
  • B. Fixed sequential pipeline: phân tích từng module, viết test, chạy test, báo cáo kết quả
  • C. Fixed sequential pipeline kèm context window lớn hơn để gánh độ phức tạp
  • D. Xử từng module độc lập, không cần chiến lược phân rã nào
Đáp án & giải thích

Đúng: A

  • A đúng vì thêm test vào legacy codebase với phụ thuộc không có tài liệu là tác vụ khảo sát mở. Chưa biết hết phạm vi từ đầu — phụ thuộc lộ dần trong lúc khảo sát. Dynamic decomposition điều chỉnh kế hoạch khi có thông tin mới.
  • B sai vì fixed pipeline giả định các bước đã biết trước. Với phụ thuộc không có tài liệu, agent không định sẵn được nên test module nào trước. Nó có thể phát hiện Module A phụ thuộc Module B và phải đổi kế hoạch.
  • C sai vì kích thước context window không giải quyết nhu cầu thích ứng. Vấn đề là kế hoạch phải tiến hóa theo phát hiện, không phải model không chứa đủ dữ liệu.
  • D sai vì xử từng module độc lập là bỏ qua phụ thuộc. Test cho Module A có thể fail nếu Module B (một phụ thuộc) chưa có test. Vẫn cần một chiến lược điều phối.

Tác vụ nào hợp nhất với fixed sequential pipeline (prompt chaining)?

  • A. Điều tra nguyên nhân gốc của một bug production xuất hiện chập chờn
  • B. Khảo sát tính năng sản phẩm của đối thủ cho một bản phân tích thị trường
  • C. Thực hiện security audit trên một hệ thống lạ
  • D. Trích xuất dữ liệu có cấu trúc từ hóa đơn với định dạng đã biết
Đáp án & giải thích

Đúng: D

  • D đúng vì trích xuất dữ liệu hóa đơn có cấu trúc đã biết: các trường và định dạng định sẵn. Các bước đoán trước được: đọc hóa đơn, trích trường, kiểm tra định dạng, xuất dữ liệu có cấu trúc. Fixed pipeline lý tưởng cho tác vụ có cấu trúc, đoán trước được.
  • A sai vì điều tra nguyên nhân gốc là tác vụ mở. Nguyên nhân chưa biết, và việc điều tra phải thích ứng theo manh mối. Dynamic decomposition phù hợp hơn.
  • B sai vì phân tích thị trường là đi khám phá thông tin chưa biết. Phạm vi tính năng của đối thủ không biết hết từ trước, nên dynamic decomposition hợp hơn.
  • C sai vì security audit trên hệ thống lạ đòi khám phá và thích ứng. Một lỗ hổng có thể lộ ra thêm bề mặt tấn công khác, làm đổi kế hoạch điều tra.

Điều gì phân biệt attention dilution với giới hạn năng lực của model?

  • A. Attention dilution chỉ xảy ra với model nhỏ; model lớn không gặp
  • B. Attention dilution do context window không đủ lớn
  • C. Dilution làm độ sâu dao động, còn giới hạn năng lực thì tệ đều
  • D. Attention dilution chỉ ảnh hưởng tác vụ review code, không ảnh hưởng dạng phân tích khác
Đáp án & giải thích

Đúng: C

  • C đúng vì attention dilution đặc trưng bởi sự thiếu nhất quán: phân tích kỹ ở mục này, hời hợt ở mục kia, và đánh giá mâu thuẫn với cùng một pattern. Giới hạn năng lực sẽ cho kết quả tệ đồng đều trên mọi mục. Chính sự thiếu nhất quán là dấu hiệu nhận diện.
  • A sai vì attention dilution xảy ra với model ở mọi cỡ. Đó là vấn đề cấu trúc do xử quá nhiều mục trong một lượt, không phải vấn đề sức mạnh model.
  • B sai vì attention dilution nói về phân bổ attention, không phải kích thước context window. Context to hơn không làm attention phân bổ đều hơn.
  • D sai vì attention dilution xảy ra ở bất kỳ tác vụ nào xử quá nhiều mục trong một lượt: review code, phân tích tài liệu, kiểm tra dữ liệu, và nhiều thứ khác.

Một developer chia 14 file thành các nhóm 5 file để review nhưng không thêm lượt tích hợp xuyên file. Cách này bỏ sót loại vấn đề nào?

  • A. Lỗi luồng dữ liệu xuyên file và pattern không nhất quán giữa các file nằm ở nhóm khác nhau
  • B. Bug bên trong từng file — chia nhóm không giúp gì cho phân tích cục bộ
  • C. Nghẽn hiệu năng do xử theo nhóm thay vì xử trong một lượt
  • D. Lỗi định dạng bên trong từng file mà ranh giới nhóm vô tình cắt đôi
Đáp án & giải thích

Đúng: A

  • A đúng vì chia nhóm xử được attention dilution bên trong từng nhóm nhưng không chạm tới vấn đề giữa các nhóm. Thiếu lượt tích hợp xuyên file, lỗi luồng dữ liệu giữa các module ở nhóm khác nhau và đánh giá pattern mâu thuẫn giữa các nhóm sẽ lọt lưới.
  • B sai vì chia nhóm thực ra cải thiện phân tích cục bộ, nhờ mỗi nhóm có ngân sách attention tập trung hơn. Phân tích theo từng file hoặc từng nhóm bắt lỗi địa phương tốt hơn một lượt duy nhất.
  • C sai vì câu hỏi nói về chất lượng review, không phải hiệu năng. Chia nhóm thậm chí có thể tăng throughput nhờ giảm tải mỗi lượt.
  • D sai vì lỗi định dạng bên trong từng file là vấn đề cục bộ mà chia nhóm xử đủ tốt. Thứ bị bỏ sót đúng ra là các vấn đề xuyên file.