Nguyên tắc prompt bám cơ chế: cấu trúc, ví dụ, tách suy luận

TL;DR: Prompt tốt không phải sưu tầm câu thần chú — mẹo đó rot theo phiên bản model vì bám quirk huấn luyện, không bám cơ chế. Ba nguyên tắc bền vì bám đúng cơ chế: (1) cấu trúc rõ — vai trò, delimiter, tách instruction/data — cho attention chỗ bám; (2) ví dụ đúng dạng (few-shot) — model bắt chước pattern trong context, ví dụ sai dạng hại hơn không ví dụ nào; (3) tách bước suy luận trước kết luận — token sinh ra là context cho token sau, cho model chỗ tự sửa sai. Cả ba suy ra từ cách model hoạt động, nên bền qua nhiều thế hệ model.

1. Một prompt tưởng ổn — đoán trước khi xem vì sao sai

Bạn viết script kiểm thử cho một luồng giao dịch ở môi trường UAT ngân hàng: trích 4 trường (transaction_id, amount, status, timestamp) từ email thông báo dạng text để đưa vào bộ so khớp tự động. Bạn viết nhanh một prompt gọi LLM làm việc này:

Doc email giao dich duoi day va cho toi biet moi thong tin lien quan, giao dich thanh cong khong, so tien bao nhieu. Day la moi truong UAT nen du lieu khong phai that. Email: "Kinh gui quy khach, giao dich GD001238 da duoc xu ly luc 2026-07-20 14:32. So tien: 1.500.000 VND cho giao dich chinh, cong them phi 15.000 VND. Trang thai: THANH CONG." Tra loi ngan gon giup toi.

Analogy — giao việc cho thực tập sinh mới

Giao brief mơ hồ ("làm báo cáo giao dịch tuần này đi") cho một thực tập sinh mới ra kết quả may rủi: không mẫu, không ví dụ, không yêu cầu trình bày số liệu trước khi chốt. Giao brief có cấu trúc — mục cần có, một báo cáo mẫu đúng định dạng, yêu cầu liệt kê số liệu trước khi kết luận — ra kết quả ổn định hơn hẳn dù cùng một người làm. Ba nguyên tắc ở mục 2 map đúng ba khác biệt đó:

2. Ba nguyên tắc bám cơ chế

2.1 Cấu trúc rõ — vai trò, delimiter, phân vùng instruction/data

Vì attention tra cứu trên toàn bộ token không phân biệt nguồn gốc, lệnh và dữ liệu trộn chung một khối văn bản khiến model không có tín hiệu nào để biết đoạn nào là chỉ thị cần tuân theo, đoạn nào chỉ là nội dung xử lý. Delimiter — nhãn khối, thẻ ngoặc, tiêu đề section — không "dạy" model hiểu nghĩa, nó tạo ra token đặc biệt lặp lại nhất quán mà attention học được cách gán trọng số khác cho vùng theo sau. Đây là lý do prompt có vai trò rõ (ROLE:), chỉ thị rõ (INSTRUCTION:) và dữ liệu tách khối (<data>...</data>) ổn định hơn một đoạn văn xuôi trộn cả ba.

Quay lại prompt mở bài: lệnh và email nằm chung một câu, không nhãn phân tách — email ngắn thì model vẫn đoán đúng, nhưng thêm dòng phí giao dịch (một số tiền khác trong cùng khối) thì độ chính xác giảm không kiểm soát được.

2.2 Ví dụ đúng dạng (few-shot) — model bắt chước pattern

Brown và cộng sự chỉ ra rằng đưa vài ví dụ input–output đúng định dạng vào context (few-shot) giúp model tổng quát hoá sang input mới, không cần cập nhật trọng số (Brown et al., Language Models are Few-Shot Learners, arXiv:2005.14165). Cơ chế không huyền bí: model dự đoán token kế tiếp bằng cách nhận diện pattern lặp lại trong context — vài ví dụ đúng dạng tạo pattern rõ, model tiếp tục pattern đó cho input mới.

Hệ quả trực tiếp: ví dụ sai dạng hại hơn không có ví dụ nào. Nếu ví dụ mẫu viết amount dạng chuỗi ("1.500.000 VND") trong khi bạn cần số thuần, model bắt chước đúng pattern sai đó — nó không "biết" bạn muốn số, nó chỉ thấy pattern và tiếp tục.

Vì vậy nguyên tắc thực dụng là 1-3 ví dụ đúng dạng, đại diện đúng trường hợp khó (ví dụ: một email có cả phí giao dịch, để model thấy cách xử lý trường hợp nhiều số tiền) — không phải càng nhiều ví dụ càng tốt.

2.3 Tách bước suy luận trước kết luận

Wei và cộng sự cho thấy yêu cầu model trình bày bước suy luận trung gian trước kết luận cuối (chain-of-thought) cải thiện đáng kể độ chính xác trên tác vụ nhiều bước (Wei et al., Chain-of-Thought Prompting Elicits Reasoning in Large Language Models, arXiv:2201.11903). Lý do bám thẳng cách model sinh văn bản: mỗi token dựa trên toàn bộ token đã sinh trước đó làm context — kể cả token model vừa viết. Khi model viết "tien chinh 1.500.000, phi rieng 15.000" trước khi kết luận, hai con số đó thành context cho bước kết luận, giúp tránh cộng nhầm. Bị ép trả lời ngay, model mất hẳn chỗ tự đối chiếu.

Áp cả ba nguyên tắc vào đúng scenario mở bài — nhưng đừng đọc thẳng đáp án. Tự điền hai phần TODO dưới đây trước:

ROLE: Ban la he thong trich xuat du lieu giao dich cho moi truong UAT ngan hang.

INSTRUCTION:
-- TODO: tu dien theo 2.1 - liet ke 4 truong can trich (transaction_id, amount,
-- status, timestamp), quy tac khi thieu truong, va yeu cau lam gi truoc khi
-- tra loi (goi y: 2.3).

VI DU:
-- TODO: tu dien theo 2.2 - viet MOT vi du input/output dung dang, chon dung
-- truong hop kho (email co ca tien chinh lan phi).

<data>
"Kinh gui quy khach, giao dich GD001238 da duoc xu ly luc 2026-07-20 14:32. So
tien: 1.500.000 VND cho giao dich chinh, cong them phi 15.000 VND. Trang thai:
THANH CONG."
</data>

Đáp án tham khảo:

INSTRUCTION:
Doc noi dung email trong the <data>. Trich 4 truong: transaction_id (chuoi),
amount (so, CHI tinh giao dich chinh, KHONG cong phi), status ("SUCCESS" hoac
"FAILED"), timestamp (ISO 8601). Neu thieu truong nao, dien null. KHONG suy dien
gia tri khong xuat hien trong email. Truoc khi tra loi, liet ke tung truong va
cau/cum tu dung de suy ra no, sau do tra loi dung JSON theo dinh dang vi du.

VI DU:
<data>
"Giao dich GD000901 thanh cong luc 2026-06-01 09:10. So tien: 500.000 VND, phi
5.000 VND."
</data>
Suy luan:
- transaction_id: "GD000901"
- amount: 500000 (khong tinh phi 5.000)
- status: "SUCCESS"
- timestamp: "2026-06-01T09:10:00"
Tra loi:
{"transaction_id": "GD000901", "amount": 500000, "status": "SUCCESS", "timestamp": "2026-06-01T09:10:00"}

Đáp án khớp ba nguyên tắc: INSTRUCTION tách khỏi <data> (2.1); ví dụ đúng trường hợp khó — có cả tiền chính lẫn phí (2.2); bước "Suy luận" bắt buộc trước "Trả lời" (2.3). Model không còn cộng nhầm phí vào amount, và output luôn đúng shape JSON để parse được.

3. Vì sao nguyên tắc thì bền, còn "mẹo câu chữ" thì rot?

Mẹo kiểu "hứa tip 20 đô", "đóng vai chuyên gia 20 năm kinh nghiệm" từng lan truyền vì tăng nhẹ chất lượng trên một model, một thời điểm huấn luyện cụ thể — hiệu ứng tới từ cách model đó được RLHF/fine-tune, không phải quy luật kiến trúc. Đổi vòng huấn luyện, hiệu ứng biến mất hoặc đảo chiều.

Ba nguyên tắc ở mục 2 thì khác: attention luôn tra cứu có trọng số (2.1), model luôn bắt chước pattern (2.2), sinh văn bản luôn autoregressive (2.3). Câu hỏi phân biệt nguyên tắc thật với mẹo đang rot: nó suy ra được từ cách model hoạt động, hay chỉ quan sát từ một lần thử?

4. Pitfall tổng hợp

❌ Nhầm 1 — càng nhiều ví dụ few-shot càng tốt: nhồi 10 ví dụ "cho chắc" đẩy dữ liệu thật ra xa, không tăng pattern mới đáng kể sau ví dụ thứ 2-3. ✅ Chọn 1-3 ví dụ đại diện đúng trường hợp khó thay vì nhiều ví dụ dễ giống nhau.

❌ Nhầm 2 — delimiter càng nhiều thẻ càng an toàn: bọc mọi câu bằng thẻ XML lồng nhiều tầng khiến prompt dài gấp đôi mà không rõ hơn. ✅ Một cặp delimiter rõ ràng mỗi vùng (ROLE/INSTRUCTION/<data>) đủ để attention phân vùng.

❌ Nhầm 3 — yêu cầu suy luận nhưng không giới hạn output cuối: chỉ nói "suy nghĩ từng bước" mà không nói rõ định dạng cuối, model dễ lan man, quên kết luận. ✅ Luôn kèm cấu trúc output ngay sau yêu cầu suy luận — tách bước không có nghĩa bỏ ràng buộc định dạng.

5. 📚 Đào sâu

6. Liên hệ các bài khác

• Bài tiếp theo — Fine-tune khi nào — khi ba nguyên tắc ở bài này vẫn không đủ, fine-tune mới đáng chi phí.
• Context window — bộ nhớ làm việc hữu hạn — vì sao thêm ví dụ few-shot không phải luôn miễn phí.
• Sampling — temperature và top-p — cơ chế chọn token mà nguyên tắc tách suy luận khai thác.
• Attention — phép truy vấn có trọng số — cơ chế nền cho cấu trúc/delimiter có tác dụng.

7. Tóm tắt

• Mẹo câu chữ (câu thần chú, hứa tip) rot theo model version vì chỉ ăn theo quirk huấn luyện của một model cụ thể.
• Ba nguyên tắc bền vì suy ra trực tiếp từ cơ chế: cấu trúc rõ, ví dụ đúng dạng, tách bước suy luận.
• Cấu trúc rõ cho attention chỗ bám, tránh lẫn lệnh với dữ liệu; ví dụ few-shot hoạt động vì model bắt chước pattern.
• Tách bước suy luận tận dụng tính autoregressive: token sinh ra là context cho token sau, cho model chỗ tự sửa sai.
• Thêm ví dụ hay thêm delimiter không phải luôn tốt hơn — cả hai tốn chỗ trong context window có hạn.
• Yêu cầu suy luận vẫn phải kèm ràng buộc định dạng output cuối, không thì model lan man.

8. Tự kiểm tra

Bài tiếp theo: Fine-tune — khi nào xứng đáng