Prompt không rách — playbook cho production

Prompt không rách — playbook cho production

Năm kỹ thuật prompting có hệ thống giúp team builder chuyển từ "viết rồi cầu nguyện" sang prompt đáng tin trên production.

Bao nhiêu lần prompt của bạn chạy ngon trên playground rồi vỡ trận ở đúng edge case mà khách hàng gặp đầu tiên?

Mình ngồi với một team 4 dev ở Đà Nẵng tuần trước — họ đang build chatbot tư vấn sản phẩm. Prompt trên playground mượt mà. Lên staging, 3 trên 10 response trả JSON thiếu field. Cả team ngồi sửa bằng cảm tính — thêm "please", thêm "you must", thêm ví dụ — mỗi lần sửa lại lòi lỗi mới. Hai tuần, prompt dài gấp ba mà vẫn không ổn.

Vấn đề không phải prompt viết dở. Vấn đề là team đang vá víu thay vì khâu có hệ thống.

Playbook này giúp gì

Bài này dành cho developer và tech lead đang đưa LLM vào production — những người cần prompt đáng tin, không chỉ prompt hay. Sau khi đọc xong, bạn sẽ có:

Checklist: 5 failure mode → 5 kỹ thuật

Dán bảng này lên wiki nội bộ trước khi đọc tiếp:

| Lỗi output bạn gặp | Kỹ thuật cần dùng | Một dòng giải nghĩa |
|---|---|---|
| Output chung chung, không đúng domain | Role prompting | Gán vai chuyên gia cụ thể cho model |
| Model cứ làm điều bạn KHÔNG muốn | Negative prompting — ràng buộc phủ định | Nói rõ điều CẤM, không chỉ điều MUỐN |
| Response không parse được, thiếu field | JSON prompting | Ép cấu trúc output bằng schema tường minh |
| Lập luận hời hợt, bỏ sót góc nhìn | ARQ — truy vấn lập luận có chủ đích | Buộc model tự đặt câu hỏi kiểm tra trước khi kết luận |
| Kết quả bất ổn, mỗi lần chạy mỗi khác | Verbalized sampling — lấy mẫu có diễn giải | Model tạo nhiều phương án rồi tự chọn phương án tốt nhất |

Mỗi kỹ thuật xử lý một sợi lỗi khác nhau. Dùng sai kỹ thuật cho sai lỗi giống cầm kéo đi vá — cắt thêm chứ không chữa.

Từng bước: áp dụng vào workflow thật

Bước 1 — Phân loại lỗi trước, chọn kỹ thuật sau

Đừng vội mở prompt lên sửa. Lấy 20–30 output lỗi gần nhất, xếp vào 5 nhóm ở bảng trên. Nếu 70% lỗi là "thiếu field JSON" thì việc thêm role prompting chẳng giúp gì — bạn cần JSON prompting.

Ví dụ thực tế: Giả sử team bạn 3 dev đang build API tóm tắt đơn hàng cho app thương mại điện tử. Output cần JSON với summary, sentiment, action_items. Lỗi phổ biến nhất: model trả markdown thay vì JSON, hoặc JSON nhưng mất action_items. → Rõ ràng là bài toán JSON prompting, không liên quan gì đến role hay reasoning.

Bước 2 — Viết constraint trước, instruction sau

Phần lớn team viết prompt theo hướng "model hãy làm X". Nhưng trên production, điều model KHÔNG được làm quan trọng không kém.

Negative prompting thường hiệu quả hơn mong đợi. Thay vì chỉ viết "Trả lời ngắn gọn", thêm block rõ ràng:

KHÔNG được:
- Thêm lời chào hoặc kết thúc kiểu "Hy vọng giúp ích"
- Đưa thông tin ngoài dữ liệu được cung cấp
- Trả lời dài hơn 3 câu

Hai cách diễn đạt cùng một ý, nhưng bản có ràng buộc phủ định giảm rõ rệt tỷ lệ output "lạc đề".

Bước 3 — Khóa output bằng schema, không chỉ bằng lời

Đừng viết "trả về JSON" rồi cầu nguyện. Đưa schema mẫu ngay trong prompt:

{
  "summary": "string — tóm tắt dưới 50 từ",
  "sentiment": "positive | negative | neutral",
  "action_items": ["string"]
}

Kèm dòng: "Nếu không có action item, trả [], KHÔNG bỏ field."

Nếu dùng OpenAI API, tận dụng response_format: { type: "json_object" } — nhưng flag này chỉ ép format, không ép schema. Prompt vẫn cần schema tường minh bên trong.

Bước 4 — Buộc model tự audit bằng ARQ

ARQ khác chain-of-thought (suy luận chuỗi) ở chỗ: thay vì "hãy suy nghĩ từng bước", bạn đặt câu hỏi kiểm tra cụ thể.

Ví dụ, sau khi model phân tích hợp đồng:

Trước khi trả lời cuối cùng, tự hỏi:
1. Có điều khoản phạt nào mình bỏ sót không?
2. Kết luận có mâu thuẫn với dữ kiện đã nêu không?

Kỹ thuật này đặc biệt hữu ích cho task phân tích phức tạp — nơi lỗi không phải sai format mà sai logic.

Bước 5 — Verbalized sampling khi cần consistency

Yêu cầu model tạo 2–3 phương án, tự đánh giá ưu nhược từng phương án, rồi chọn. Prompt kiểu:

Tạo 3 cách trả lời cho câu hỏi sau.
Mỗi cách, ghi ưu và nhược điểm.
Chọn cách tốt nhất, giải thích vì sao.

Token tốn hơn, nhưng variance (độ dao động giữa các lần chạy) giảm đáng kể. Phù hợp khi consistency quan trọng hơn speed — ví dụ: tạo mô tả sản phẩm cho catalog, tóm tắt báo cáo tài chính.

Ba cái bẫy team nào cũng từng dẫm

Bẫy 1 — Nhồi hết kỹ thuật vào một prompt. Mình từng thấy prompt 800 token gồm role + negative + JSON + ARQ. Kết quả: model bắt đầu hallucinate (bịa) chính instruction của bạn. Prompt cũng giống tấm vải — dệt quá nhiều sợi vào cùng một chỗ thì không bền hơn, mà rối. Quy tắc: tối đa 2–3 kỹ thuật mỗi prompt. Cần cả 5? Tách thành pipeline nhiều bước.

Bẫy 2 — Optimize trên playground, ship thẳng. Playground chạy temperature mặc định, input sạch. Production thì messy — tiếng Việt có typo, context dài ngắn bất thường. Luôn test với dữ liệu thật từ staging.

Bẫy 3 — Prompt không có version control. Prompt thay đổi liên tục nhưng không ai track. Hai tuần sau lỗi quay lại, không biết commit nào gây ra. Coi prompt như code — tag version, viết changelog.

Chiều nay: audit prompt của team trong 5 bước

  1. Thu thập 30 output lỗi gần nhất từ production hoặc staging
  2. Phân loại theo 5 nhóm failure mode ở bảng trên
  3. Chọn 1–2 kỹ thuật phù hợp nhóm lỗi chiếm đa số
  4. Viết lại prompt với kỹ thuật đó — chạy A/B với prompt cũ
  5. Đo tỷ lệ output hợp lệ trước/sau, commit prompt mới vào repo

Các kỹ thuật này hoạt động ở tầng prompt, không phụ thuộc provider — OpenAI, Anthropic, open-source model qua Ollama hay vLLM đều áp dụng được.

---

Prompt production-grade không cần viết dài hơn hay hoa mỹ hơn — chỉ cần biết đúng chỗ nào cần khâu mũi nào.

---

Bụi Wire — nghiện đọc release notes lúc 2 giờ sáng

Nguồn tham khảo