Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn vừa viết xong một prompt cho chatbot chăm sóc khách hàng. Bạn thử 5 lần, thấy câu trả lời "ổn áp", gật gù hài lòng rồi đẩy lên production. Ba ngày sau, sếp gọi: 12% khách hàng phàn nàn bot trả lời sai giá sản phẩm. Chuyện gì đã xảy ra?
Vấn đề nằm ở cách bạn đánh giá prompt. Trong suốt các bài trước, chúng ta đã học cách viết prompt — từ zero-shot, few-shot, chain-of-thought, cho đến structured output. Nhưng viết được một prompt và biết chắc nó tốt là hai chuyện hoàn toàn khác nhau. Bài này tập trung vào câu hỏi tưởng đơn giản mà cực kỳ khó: Làm sao bạn biết prompt của mình thật sự tốt?
Đây là kỹ năng phân biệt người nghiệp dư với người làm prompt engineering nghiêm túc. Người nghiệp dư dừng lại ở cảm giác. Người chuyên nghiệp có số liệu, có phương pháp so sánh, có quy trình để trả lời câu hỏi "prompt A hay prompt B tốt hơn, và tốt hơn bao nhiêu phần trăm?". Nếu bạn định đưa prompt vào một sản phẩm thực sự — nơi có hàng nghìn, hàng vạn lượt gọi mỗi ngày — thì đánh giá prompt không phải tùy chọn, mà là bắt buộc.
Khái niệm cốt lõi
"Vibes-based testing" không mở rộng được
Cách phổ biến nhất — và nguy hiểm nhất — để đánh giá prompt là "test bằng cảm giác" (vibes-based testing). Bạn thử vài lần, thấy hài lòng, kết luận prompt ổn. Vấn đề của cách này là:
- Mẫu quá nhỏ. 10 lần thử "cảm thấy đúng" hoàn toàn không đảm bảo 1.000 lần chạy trong thực tế đều đúng. LLM có tính ngẫu nhiên (đặc biệt khi temperature > 0), và các trường hợp biên (edge case) hiếm khi xuất hiện trong vài lần bạn thử tay.
- Thiên kiến xác nhận. Bạn viết prompt, bạn muốn nó đúng, nên não bạn tự động nhìn thấy cái đúng và bỏ qua cái sai.
- Không so sánh được. Khi bạn chỉnh prompt từ phiên bản A sang B, làm sao biết B thật sự tốt hơn A hay chỉ là bạn "cảm thấy" vậy?
Ba trụ cột của một hệ thống đánh giá
Một quy trình đánh giá prompt tử tế cần ba thành phần:
1. Bộ dữ liệu kiểm thử (test set / eval set). Đây là tập hợp các đầu vào (input) đại diện cho những gì prompt sẽ gặp trong thực tế, kèm theo kết quả mong đợi hoặc tiêu chí đánh giá. Ví dụ với bot chăm sóc khách hàng: 50–200 câu hỏi thật của khách, mỗi câu kèm câu trả lời "chuẩn". Test set là nền móng — không có nó, mọi thứ còn lại đều vô nghĩa.
2. Tiêu chí đánh giá (metrics / rubric). Bạn đo cái gì? Độ chính xác? Độ đúng định dạng? Giọng văn? Độ dài? Mỗi loại tác vụ cần tiêu chí khác nhau, và bạn phải định nghĩa rõ ràng trước khi chạy.
3. Phương pháp chấm điểm (scoring method). Ai chấm, chấm bằng cách nào? Có ba nhóm chính, sẽ nói kỹ ở dưới.
Ba phương pháp chấm điểm
Chấm bằng luật máy (code-based / deterministic). Dùng cho các tác vụ có đáp án đúng/sai rõ ràng: phân loại (đúng nhãn không?), trích xuất dữ liệu (đúng con số không?), output JSON (parse được không, đủ trường không?). Ưu điểm: nhanh, rẻ, khách quan tuyệt đối. Ví dụ: output == expected_label hoặc kiểm tra json.loads() không lỗi.
Chấm bằng LLM (LLM-as-a-judge). Dùng một LLM khác (hoặc chính nó) để chấm điểm những tiêu chí khó lập trình như "câu trả lời có lịch sự không", "bản tóm tắt có trung thực với gốc không". Bạn viết một prompt chấm điểm, đưa cho model đầu vào + đầu ra + rubric, yêu cầu nó trả về điểm số. Ưu điểm: mở rộng được, đo được thứ trừu tượng. Nhược điểm: bản thân LLM-judge cũng cần được kiểm định, có thể thiên vị (ví dụ ưu tiên câu dài hơn).
Chấm bằng người (human evaluation). Chuyên gia con người đọc và chấm. Chính xác nhất về mặt phán đoán chất lượng, nhưng chậm và đắt. Thường dùng để kiểm định lại LLM-judge, hoặc cho những trường hợp rủi ro cao (pháp lý, y tế, tài chính).
Các metric hay dùng
- Accuracy (độ chính xác): tỷ lệ output đúng, dùng cho phân loại/trích xuất.
- Pass rate: tỷ lệ output vượt qua một ngưỡng chất lượng.
- Format compliance: tỷ lệ output đúng định dạng yêu cầu (đặc biệt quan trọng với JSON/XML).
- Consistency: chạy cùng một input nhiều lần, kết quả có ổn định không.
- Latency & cost: một prompt "hoàn hảo" nhưng tốn 8 giây và 3.000 token mỗi lần gọi có thể không dùng được trong production.
Tình huống thực tế
Ví dụ 1 — Tiki và bài toán phân loại đánh giá sản phẩm
Giả định một đội dữ liệu tại Tiki cần phân loại 50.000 review sản phẩm mỗi ngày thành ba nhãn: tích cực, tiêu cực, trung tính, để đội vận hành ưu tiên xử lý phản hồi xấu. Bạn viết một prompt phân loại và thấy nó chạy "khá ổn" trên vài chục ví dụ tự thử.
Nhưng thay vì tin cảm giác, đội xây một test set 500 review đã được nhân viên gắn nhãn thủ công. Chạy prompt phiên bản 1 trên 500 review này, chấm tự động bằng cách so output == nhãn_chuẩn, kết quả: accuracy 82%. Nghe có vẻ tốt? Nhưng khi bóc tách, họ phát hiện phần lớn lỗi rơi vào nhóm "trung tính" — model hay nhầm review mỉa mai ("sản phẩm tuyệt vời, dùng một ngày là hỏng") thành tích cực.
Họ chỉnh prompt phiên bản 2, thêm 3 ví dụ few-shot về câu mỉa mai. Chạy lại trên đúng 500 review đó: accuracy lên 91%. Vì dùng cùng một test set, họ biết chắc phiên bản 2 tốt hơn 9 điểm phần trăm, không phải phỏng đoán.
Bài học: Test set cố định biến việc so sánh prompt thành một phép đo khách quan. Và việc phân tích lỗi theo nhóm (error analysis) chỉ ra chính xác chỗ cần sửa, thay vì sửa mò.
Ví dụ 2 — Startup fintech và LLM-as-a-judge cho tư vấn
Một startup fintech ở TP.HCM xây trợ lý AI tư vấn kế hoạch tiết kiệm cho người dùng. Ở đây không có "đáp án đúng" duy nhất — một câu tư vấn có thể diễn đạt nhiều cách. Chấm bằng luật máy không dùng được.
Đội dựng một LLM-as-a-judge với rubric ba tiêu chí, mỗi tiêu chí chấm thang 1–5:
- Chính xác về tài chính: con số, lãi suất có đúng không?
- An toàn: có tránh hứa hẹn lợi nhuận hay đưa lời khuyên đầu tư rủi ro không?
- Rõ ràng: người dùng phổ thông có hiểu được không?
Bài học: LLM-as-a-judge mở rộng được và rẻ, nhưng bản thân nó là một prompt cần được đánh giá. Luôn kiểm định judge bằng một mẫu người chấm trước khi tin tưởng nó ở quy mô lớn.
Ví dụ 3 — Prompt "tốt hơn" nhưng lại tệ hơn về chi phí
Một công ty SaaS B2B dùng LLM để tóm tắt ticket hỗ trợ. Phiên bản prompt mới cho chất lượng tóm tắt cao hơn rõ rệt theo điểm LLM-judge (4.6 so với 4.1 trên thang 5). Đội định triển khai ngay.
May thay, dashboard đánh giá của họ đo cả latency và token. Prompt mới dài hơn, thêm chain-of-thought, khiến mỗi lần gọi tốn trung bình 2.100 token thay vì 900, và mất 5,2 giây thay vì 1,8 giây. Với 30.000 ticket/ngày, chi phí token tăng gấp hơn 2 lần và người dùng phải chờ lâu hơn đáng kể. Đội quyết định giữ phiên bản cũ cho luồng real-time, chỉ dùng phiên bản mới cho báo cáo tổng hợp cuối ngày (nơi độ trễ không quan trọng).
Bài học: "Tốt" không chỉ là chất lượng đầu ra. Một hệ đánh giá hoàn chỉnh luôn cân nhắc chất lượng cùng với chi phí và tốc độ — ba thứ này phải được nhìn cùng nhau khi ra quyết định.
Hướng dẫn từng bước
Bước 1 — Định nghĩa "tốt" là gì cho tác vụ của bạn. Trước khi đo, viết ra bằng lời: một output tốt trông như thế nào? Đúng định dạng? Đúng sự thật? Đúng giọng thương hiệu? Càng cụ thể càng tốt. Đây là rubric của bạn.
Bước 2 — Xây test set đại diện. Thu thập 30–200 input thật (hoặc gần thật). Cố ý bao gồm cả trường hợp thường gặp lẫn trường hợp biên, trường hợp khó. Nếu có thể, gắn nhãn/đáp án chuẩn cho mỗi input. Đừng lấy test set từ chính những ví dụ bạn đã dùng để viết prompt — sẽ bị "học tủ".
Bước 3 — Chọn phương pháp chấm. Nếu có đáp án đúng/sai rõ ràng → chấm bằng luật máy. Nếu là chất lượng chủ quan → LLM-as-a-judge (kèm kiểm định bằng người). Rủi ro cao → thêm người chấm.
Bước 4 — Chạy baseline. Chạy prompt hiện tại trên toàn bộ test set, ghi lại điểm số cho từng metric. Đây là mốc để so sánh mọi thay đổi sau này.
Bước 5 — Phân tích lỗi (error analysis). Đừng chỉ nhìn con số tổng. Đọc các ca sai. Chúng có gom thành nhóm không? (Ví dụ: "toàn sai ở câu mỉa mai" hoặc "toàn quên trường ngày tháng".) Đây là bước giá trị nhất — nó chỉ cho bạn chính xác phải sửa gì.
Bước 6 — Thay đổi một biến, đo lại. Chỉnh prompt (thêm ví dụ, đổi hướng dẫn...), chạy lại trên đúng test set đó, so điểm với baseline. Mỗi lần chỉ đổi một thứ để biết cái gì gây ra khác biệt.
Bước 7 — Theo dõi cả cost & latency. Ghi lại token và thời gian mỗi phiên bản. Đảm bảo bạn không "được chất lượng, mất túi tiền".
Bước 8 — Lặp lại và lưu kết quả. Ghi từng phiên bản prompt kèm điểm số vào một bảng (Google Sheet cũng được). Đây là nền tảng để làm prompt versioning nghiêm túc.
Lỗi thường gặp & mẹo
- Test set quá nhỏ hoặc thiên lệch. 5 ví dụ không nói lên gì. Tối thiểu nên có vài chục, và phải phản ánh phân bố thực tế — kể cả những ca xấu, khó, hiếm.
- Trộn lẫn dữ liệu viết prompt và dữ liệu đánh giá. Nếu bạn tinh chỉnh prompt dựa trên chính test set, điểm sẽ đẹp giả tạo. Giữ một tập "giữ kín" (holdout set) chỉ để đánh giá cuối.
- Tin LLM-judge mù quáng. Judge cũng là một prompt, cũng sai, cũng thiên vị (thích câu dài, thích văn hoa). Luôn kiểm định nó bằng một mẫu người chấm.
- Chỉ nhìn điểm trung bình. Accuracy 90% nghe hay, nhưng nếu 10% sai đều rơi vào ca nghiêm trọng nhất (ví dụ báo sai giá) thì vẫn là thảm họa. Hãy nhìn phân bố lỗi, không chỉ con số gộp.
- Quên đo tính ổn định. Với temperature > 0, chạy cùng input hai lần có thể ra kết quả khác. Chạy mỗi input 2–3 lần để biết prompt có ổn định không.
- Mẹo: Bắt đầu nhỏ và thủ công. Một bảng tính 30 dòng với cột input, output, điểm đã tốt hơn vô hạn so với không có gì. Đừng chờ đến khi có công cụ xịn mới bắt đầu đánh giá.
- Mẹo: Khi so hai prompt, dùng đúng cùng test set, cùng tham số (temperature, model). Chỉ đổi bản thân prompt. Đây là "thí nghiệm có đối chứng" phiên bản prompt.
Bài tập thực hành
- Xây test set đầu tiên. Chọn một tác vụ bạn đang làm (phân loại email, tóm tắt, trích xuất...). Thu thập 20 input thật và viết đáp án/tiêu chí mong đợi cho mỗi cái. Cố ý thêm 3–4 ca khó.
- Chạy baseline và ghi điểm. Chạy prompt hiện tại qua 20 input đó. Tự chấm bằng luật (đúng/sai) hoặc thang 1–5. Ghi vào bảng tính. Tính điểm trung bình.
- Phân tích lỗi. Đọc kỹ mọi ca bị điểm thấp. Chúng có gom thành nhóm không? Viết ra một câu chẩn đoán: "Prompt của tôi hay sai khi __________."
- Cải tiến và đo lại. Dựa trên chẩn đoán, chỉnh một thứ trong prompt. Chạy lại trên đúng 20 input đó. So điểm mới với baseline. Nó tốt hơn bao nhiêu điểm phần trăm?
- Nâng cao — dựng LLM-as-a-judge. Viết một prompt chấm điểm output theo rubric của bạn (thang 1–5, kèm lý do). Cho nó chấm 20 output, rồi tự bạn chấm tay 5 trong số đó. Điểm máy và điểm bạn có khớp không? Nếu lệch, judge cần sửa gì?
Tóm tắt
Đánh giá prompt là ranh giới giữa nghịch chơi và làm sản phẩm thật. "Vibes-based testing" — thử vài lần rồi tin cảm giác — không mở rộng được: 10 lần đúng không đảm bảo 1.000 lần đúng. Muốn biết prompt tốt hay không, và tốt hơn phiên bản cũ bao nhiêu, bạn cần ba trụ cột: một test set đại diện, tiêu chí rõ ràng, và phương pháp chấm điểm — dù là bằng luật máy (nhanh, khách quan), bằng LLM-as-a-judge (mở rộng được, nhưng phải kiểm định), hay bằng người (chính xác, đắt đỏ).
Quy trình cốt lõi: định nghĩa "tốt", xây test set, chạy baseline, phân tích lỗi để biết sửa gì, rồi thay đổi từng biến một và đo lại trên cùng test set. Đừng quên cân nhắc chất lượng cùng với chi phí và độ trễ — như ví dụ công ty SaaS cho thấy, một prompt "chất lượng hơn" có thể lại là lựa chọn tồi khi tính cả token và thời gian. Khi bạn đã có số liệu để trả lời "prompt A hay B tốt hơn", bạn không còn đoán mò nữa — và đó chính là lúc bạn thật sự làm chủ prompt engineering.