Prompt chaining thời model biết tự suy luận: khi nào vẫn cần?

Model hiện đại có thinking và có thể tự điều phối subagent, nên phần lớn việc nhiều bước nó tự xử lý trong một lần gọi. Vậy còn cần prompt chaining (chia việc thành chuỗi lời gọi API nối tiếp) không? Theo hướng dẫn prompting mới nhất của Anthropic: vẫn cần, khi bạn muốn kiểm tra kết quả trung gian hoặc ép một quy trình cố định. Mẫu phổ biến nhất là tự sửa lỗi: nháp → review theo tiêu chí → sửa.

Khi nào nên chain, khi nào không?

Mẫu tự sửa lỗi ba bước

# Bước 1: nháp
draft = call("Viết email thông báo tăng giá gói Pro. Bối cảnh: <context>…</context>")

# Bước 2: review theo tiêu chí (lời gọi riêng, context mới)
review = call(f"""Đánh giá email trong <draft> theo tiêu chí:
1. Nêu rõ mức giá mới và ngày áp dụng
2. Giải thích lý do, không xin lỗi quá mức
3. Có lựa chọn cho khách không muốn tiếp tục
Liệt kê từng vấn đề, không viết lại email.
<draft>{draft}</draft>""")

# Bước 3: sửa dựa trên review
final = call(f"Sửa <draft> theo <review>. Chỉ trả về email.\n<draft>{draft}</draft>\n<review>{review}</review>")

Vì mỗi bước là một lời gọi riêng, bạn có thể ghi log, chấm điểm hoặc dừng lại ở bất kỳ điểm nào, ví dụ không gửi email nếu review phát hiện vấn đề nghiêm trọng.

Nguyên tắc thiết kế chuỗi

• Mỗi bước một mục tiêu: bước review chỉ liệt kê vấn đề, không viết lại; trộn hai việc làm cả hai kém đi.
• Chuyển giao bằng thẻ XML: bọc output bước trước trong thẻ có tên rõ (<draft>, <review>) để bước sau biết đâu là dữ liệu.
• Tiêu chí review cụ thể: "kiểm tra chất lượng" quá mơ hồ; liệt kê 3–5 tiêu chí đo được.
• Chọn model theo bước: nháp và review có thể dùng model khác nhau để cân bằng chi phí.
• Song song khi được: các bước độc lập (ví dụ review pháp lý và review giọng văn) chạy song song rồi gộp.

Rủi ro và lưu ý

• Độ trễ và chi phí cộng dồn: ba lời gọi là ba lần chờ và ba lần tính tiền; chỉ chain khi giá trị kiểm soát lớn hơn chi phí.
• Review "dễ dãi": model review chính output của nó có xu hướng hài lòng; tiêu chí rõ ràng và yêu cầu liệt kê vấn đề giúp giảm hiện tượng này.
• Sửa quá tay: bước sửa có thể làm mất ý tốt của bản nháp; yêu cầu chỉ sửa đúng vấn đề được nêu.
• Lỗi lan truyền: bước đầu sai thì các bước sau làm đẹp một nội dung sai; kiểm tra sớm.

Áp dụng thế nào?

• Dev: Bắt đầu với một lời gọi; chỉ tách thành chuỗi khi bạn chỉ ra được bước nào cần kiểm tra riêng.
• Tech Lead: Lưu output từng bước vào log để eval từng khâu, tìm ra khâu yếu nhất thay vì đoán.
• PM: Với nội dung gửi khách hàng, chuỗi nháp–review–sửa kèm điểm dừng duyệt bởi người là quy trình an toàn và dễ giải thích.