Kế 17: Kế liên hoàn — Prompt chaining nối nhiều prompt

Kế 17 Binh pháp AI: Tách nhiệm vụ phức tạp thành chuỗi prompt nối tiếp, mỗi bước refine output, tránh lỗi lan truyền và tăng độ chính xác qua các giai đoạn.

Định nghĩa

Kế liên hoàn (Prompt Chaining) là chiến thuật tách một nhiệm vụ AI phức tạp thành chuỗi các prompt đơn lẻ nối tiếp nhau, trong đó output của bước trước trở thành input của bước sau. Thay vì "đánh một trận quyết định" bằng single-shot prompting, ta thiết lập "trạm dịch" để thông tin được xử lý, tinh chế, và kiểm chứng từng chặng trước khi đến đích.

Giải thích chi tiết

Câu chuyện dịch trạm thời Trần

Thời nhà Trần chống quân Nguyên Mông, hệ thống dịch trạm được thiết lập dọc đường từ Thăng Long ra biên giới. Một tin báo khẩn không do một kỵ sĩ cưỡi ngựa gầy chạy 300 dặm liền một mạch — mà được chuyển tiếp qua các trạm: người thứ nhất chạy 10 dặm đến trạm A, trạm A kiểm lại tin tức rồi chuyển cho người thứ hai chạy đến trạm B... Mỗi chặng, người đưa tin luôn tươi mới, ngựa luôn khỏe, và thông tin được lọc rác trước khi truyền đi.

Trong thế giới AI, Kế liên hoàn chính là đạo lý này: Không giao trọng trách phức tạp cho một "lời nhắc duy nhất" (single-shot), mà tách thành chuỗi trạm dịch — mỗi prompt xử lý một biến đổi cụ thể, kiểm tra lỗi, rồi chuyển output cho prompt tiếp theo.

Vấn đề của "đánh úng một phát"

Người dùng AI hiện đại thường mắc chứng "tham công tiếc việc": muốn giải quyết cả quy trình phức tạp trong một câu hỏi duy nhất. Ví dụ thực tế:

"Phân tích hợp đồng 50 trang này, tóm tắt rủi ro pháp lý, so sánh với template chuẩn, rồi viết báo cáo đề xuất sửa đổi bằng tiếng Anh 2000 từ, kèm bảng thống kê."

Kết quả thường là: Model bắt đầu tốt ở đoạn 1, đến đoạn 3 thì quên cả yêu cầu ban đầu (lost in the middle), đoạn 5 bắt đầu bịa ra điều khoản không có trong hợp đồng (hallucination cascade), và kết luận thì sai format vì "token budget" đã cạn khi đến phần cuối.

Đây là autoregressive trap: LLM dự đoán token tiếp theo chỉ dựa trên chuỗi token trước đó, không có khả năng "nhìn lại" toàn cục hay plan-ahead. Khi forced generation dài, lỗi tích lũy theo cấp số nhân — sai ở đoạn 2 sẽ kéo theo sai lầm chuỗi ở đoạn 3-10, giống như domino.

Kiến trúc pipeline thành trạm dịch

Kế liên hoàn tách nhiệm vụ thành các giai đoạn độc lập, mỗi giai đoạn có "ngữ cảnh riêng" (context window) tập trung:

Stage 1: Trích xuất (Extract)
Chỉ tập trung lọc thông tin thô, không cần phân tích.

Bạn là chuyên viên trích xuất hợp đồng. Hãy đọc tài liệu dưới đây và liệt kê 
CÁC MẬU: 
- Điều khoản thanh toán (số tiền, hạn, phạt trễ)
- Điều khoản bảo mật (cam kết, thời hạn)
- Điều khoản chấm dứt (điều kiện, thông báo)

Input: [Paste nội dung hợp đồng]

Output mẫu:
• Thanh toán: 30% trong 7 ngày, phạt 0.5%/ngày trễ...
• Bảo mật: 5 năm kể từ ngày ký...

Stage 2: Phân tích (Analyze)
Nhận output của Stage 1, chuyển vai trò sang "luật sư rủi ro".

Bạn là luật sư phân tích rủi ro. Dựa trên DANH SÁCH điều khoản sau đây:
[Output từ Stage 1]

Hãy đánh giá mức độ rủi ro (Cao/Trung bình/Thấp) cho từng điều khoản, 
giải thích lý do và đề xuất sửa đổi cụ thể.

Stage 3: Tổng hợp (Synthesize)
Nhận bảng phân tích rủi ro, chuyển sang "cố vấn chiến lược".

Bạn là cố vấn chiến lược. Dựa trên PHÂN TÍCH RỦI RO sau:
[Output từ Stage 2]

Hãy viết báo cáo đề xuất 3 điểm cần đàm phán lại, ưu tiên theo tác động tài chính.
Giới hạn 500 từ, giọng văn chuyên nghiệp.

Stage 4: Format (Polish)
Nhận bản nháp báo cáo, chuyển sang "trình bày".

Chuyển bản tổng hợp sau thành bảng Markdown so sánh 3 cột: 
Điều khoản gốc | Rủi ro | Đề xuất sửa đổi.
Thêm giới thiệu ngắn và kết luận.

Input: [Output từ Stage 3]

That's it. Mỗi bước xử lý một biến đổi duy nhất, giảm tải cho context window, và tạo "checkpoint" để bạn kiểm tra logic trước khi chuyển tiếp.

Tại sao kế này hiệu quả?

1. Attention Budget Allocation
Transformer có ngân sách attention cố định. Trong prompt dài 2000 token, token thứ 1000 phải "chia sẻ" attention với 999 token trước nó — độ phân giải bị loãng. Prompt chaining cho phép mỗi stage có full attention budget (4k-128k token) cho input ngắn gọn, súc tích — tương đương việc dùng kính hiển vi thay vì nhìn từ xa mờ ảo.

2. Linearization of Error Surface
Trong single-shot generation, lỗi tại token 50 sẽ lan truyền đến token 500 (snowball effect). Chaining tách lỗi thành các khối riêng biệt: nếu Stage 2 sai, bạn chỉ cần sửa Stage 2, không cần regenerate cả chuỗi 2000 từ từ đầu. Đây là "debuggable by design".

3. Compression-Expansion Cycle
Stage 1 (Extract) nén 50 trang thành 10 bullet points. Stage 2 (Analyze) mở rộng 10 bullets thành phân tích chi tiết. Stage 3 lại nén thành đề xuất ngắn gọn. Chu kỳ này tương đương "outline → draft → edit" trong quy trình viết lách của con người, cho phép model "nghỉ ngơi" và tái cấu trúc logic giữa các bước.

4. Mode Switching
Mỗi stage có system prompt riêng: Stage 1 là "kỹ sư trích xuất" (cắt bớt, lạnh lùng), Stage 2 là "luật sư thận trọng" (phân tích, nghi ngờ). Chuyển vai trò trong cùng một prompt dài gây "mode interference" — model quên mình đang là ai. Tách stage cho phép mỗi persona được thể hiện trọn vẹn.

Ví dụ thực tế

Phân tích báo cáo tài chính dài hạn

Cách thông thường: Paste cả báo cáo 100 trang vào ChatGPT, yêu cầu "tóm tắt điểm mạnh yếu". Kết quả: model tóm tắt được 3 trang đầu rồi bỏ qua phần còn lại.

Áp dụng Kế liên hoàn:

Trạm 1: Trích xuất chỉ số tài chính (Revenue, EBITDA, Margin) từng quý → bảng CSV
Trạm 2: Phân tích biến động từng chỉ số (tính % YoY, trend) → bảng phân tích
Trạm 3: So sánh với competitor (cần tìm kiếm bổ sung) → nhận xét cạnh tranh
Trạm 4: Tổng hợp thành bản ghi chú đầu tư 300 từ cho CEO

Viết code phần mềm phức tạp

Cách thông thường: "Viết cho tôi app quản lý kho hàng bằng Python, có API, database, và giao diện web". Kết quả: code dài 500 dòng, đầy lỗi import, quên cả viết hàm chính.

Áp dụng Kế liên hoàn:

Trạm 1 (Architect): Thiết kế schema database và API endpoints → JSON spec
Trạm 2 (Backend): Viết Python models và API routes dựa trên spec → code module
Trạm 3 (Frontend): Viết React components dựa trên API đã định nghĩa → JSX
Trạm 4 (QA): Review code tìm lỗi bảo mật và logic → báo cáo sửa lỗi
Trạm 5 (Refactor): Sửa code theo báo cáo → final commit

Tạo nội dung marketing

Pipeline: Brief → Outline → Draft → Edit → Format

Trạm 1: Từ brief sản phẩm, trích xuất 3 USP chính
Trạm 2: Viết 5 tiêu đề (headlines) khác nhau dựa trên 3 USP
Trạm 3: Chọn tiêu đề tốt nhất, viết body copy 300 từ
Trạm 4: Edit cho đúng tone of voice (chuyên nghiệp nhưng gần gũi)
Trạm 5: Chuyển thành HTML cho email marketing

Ứng dụng

Đối tượng	Ứng dụng điển hình	Tool Stack gợi ý
Nhân viên pháp lý	Rà soát hợp đồng đa điều khoản	Claude Projects, Claude Artifacts
Lập trình viên	Code generation đa file	Claude Code, Cursor, GitHub Copilot Workspace
Content Creator	Viết bài dài >2000 từ	ChatGPT + Custom GPTs (chained qua output/input)
Data Analyst	Phân tích dữ liệu nhiều bước	LangChain, Python notebook (chaining qua cells)
Doanh nghiệp	Tự động hóa báo cáo	n8n, Make, OpenAI Assistants API (thread state)

So sánh: Single-shot vs Chaining

Tiêu chí	Single-shot Prompt	Kế liên hoàn (Chaining)
Thời gian	1 API call, nhanh	Nhiều API calls, chậm hơn
Chi phí token	Thấp (1 lần)	Cao hơn 2-4x (trùng lặp context)
Độ chính xác	Giảm theo độ dài output	Cao, ổn định qua từng stage
Debug	Khó (tìm lỗi trong 2000 từ)	Dễ (isolate stage, sửa stage 2 không ảnh hưởng 1)
Kiểm soát	Thấp (black box)	Cao (checkpoint tại mỗi trạm)
Phù hợp	Task đơn giản, output ngắn	Task phức tạp, đa bước logic

Quy tắc vàng: Nếu output yêu cầu >3 bước logic liên tiếp (tìm kiếm → phân tích → tổng hợp → trình bày), hãy dùng chaining. Chi phí token tăng 3x nhưng giảm 80% thời gian sửa lỗi sau cùng.