Mở đầu — vì sao bài này quan trọng
Khi bạn viết spec cho một tính năng thông thường — ví dụ nút "Thêm vào giỏ hàng" — bạn biết chính xác đúng/sai. Bấm nút thì sản phẩm vào giỏ. Không vào giỏ là bug. Acceptance criteria rõ ràng, QA test xong là ship.
Nhưng với tính năng AI/LLM, mọi thứ khác hẳn. Hỏi một chatbot "Áo này còn size M không?" — model có thể trả lời đúng, đúng một nửa, đúng nhưng cộc lốc, hoặc bịa ra một câu nghe rất thuyết phục mà sai hoàn toàn. Output không phải là một giá trị duy nhất, nó là một phân phối các câu trả lời có thể có. Bạn không thể viết "kết quả phải bằng X" rồi để QA bấm thử vài lần là xong.
Đây chính là lý do mục Eval Criteria & Test Set tồn tại trong spec AI. Nó trả lời câu hỏi sống còn: "Làm sao chúng ta BIẾT tính năng AI này đủ tốt để ship? Và sau khi ship, làm sao biết nó không xấu đi?" Nếu PRD của bạn cho tính năng AI mà thiếu phần này, đội kỹ sư sẽ build model, prompt, RAG pipeline... rồi đến lúc demo cả phòng ngồi đọc 5 ví dụ may rủi và "cảm thấy ổn" — đó không phải kỹ thuật, đó là mê tín.
Là PM, bạn không cần biết train model. Nhưng bạn bắt buộc phải định nghĩa được: chất lượng nghĩa là gì, đo bằng cách nào, ngưỡng nào thì pass, và lấy dữ liệu nào ra đo. Đó là nội dung của bài này. Hãy lưu ý: bài này chỉ tập trung vào tiêu chí đánh giá và bộ test. Các phần khác của AI spec — input/output contract, fallback, latency, hallucination guard — nằm ở những bài riêng (29, 31, 32, 33).
Khái niệm cốt lõi
Eval (evaluation) là gì trong spec AI
Eval là quy trình đo lường có hệ thống chất lượng output của model trên một tập dữ liệu cố định, theo các tiêu chí đã định trước. Khác với "test thử cho vui", một eval đúng nghĩa phải:
- Reproducible — chạy lại cho ra kết quả so sánh được.
- Đo trên test set cố định — cùng một bộ câu hỏi, để so sánh giữa các phiên bản.
- Có ngưỡng pass/fail rõ ràng — ví dụ "accuracy ≥ 85%".
Ba loại eval — đây là phần xương sống
1. Auto eval (đánh giá tự động bằng thuật toán)
Máy so sánh output của model với đáp án chuẩn (reference) bằng công thức cố định. Phổ biến:
- Exact match — output có trùng khít đáp án không. Hợp với bài toán có đáp án duy nhất: phân loại intent, trích xuất số tiền, trả về mã đơn hàng.
- BLEU / ROUGE — đo độ trùng lặp từ/cụm từ giữa output và reference. BLEU vốn dùng cho dịch máy (đo precision của các n-gram), ROUGE dùng cho tóm tắt (thiên về recall — câu tóm tắt có "phủ" được nội dung gốc không).
- F1, accuracy, precision/recall — cho các bài toán phân loại.
2. LLM-as-judge (model chấm model)
Dùng một model mạnh (thường là model lớn hơn, ví dụ một GPT-4 class hoặc Claude class) làm "giám khảo" để chấm điểm output của model đang test, dựa trên một rubric bạn viết. Ví dụ rubric: "Cho điểm 1–5 về độ chính xác thông tin; 1–5 về độ lịch sự; câu trả lời có bịa thông tin ngoài context không (có/không)."
Ưu điểm: bắt được sắc thái mà auto eval bỏ qua — giọng điệu, mức độ hữu ích, có lan man không. Chạy được ở quy mô lớn, rẻ hơn người nhiều. Nhược điểm: judge cũng có thiên kiến (ví dụ thiên vị câu dài, thiên vị câu do chính nó sinh ra), và rubric mơ hồ thì điểm cũng nhiễu. Cần "căn chỉnh" judge với vài chục mẫu người đã chấm trước.
3. Human eval (người đánh giá — gold standard)
Con người thật đọc output và chấm. Đây là tiêu chuẩn vàng — đáng tin nhất, đặc biệt cho các yếu tố chủ quan và rủi ro cao. Nhược điểm rõ: đắt, chậm, không chạy được mỗi lần deploy. Vì vậy human eval thường dùng để: (a) xây gold set ban đầu, (b) căn chỉnh LLM-judge, (c) kiểm tra spot-check định kỳ và trước các mốc lớn (ship v1, mở thị trường mới).
> Công thức thực dụng mà các đội hay dùng: auto eval chạy mỗi lần CI (gác cổng cơ bản), LLM-judge chạy hằng ngày/mỗi PR lớn (đo chất lượng tinh tế), human eval chạy theo mốc (chốt quyết định ship). Ba lớp này bổ sung nhau, không thay thế nhau.
Test set (golden dataset) — phần PM hay bỏ quên
Eval criteria mà không có test set tốt thì vô nghĩa. Test set là tập câu hỏi/tình huống cố định mà bạn đo model trên đó. Một test set tốt cần:
- Đại diện cho thực tế — phản ánh đúng tỷ lệ các loại câu hỏi người dùng thật sự hỏi (lấy từ log nếu có).
- Phủ edge case — câu hỏi mơ hồ, tiếng Việt không dấu, chen tiếng Anh, câu hỏi ngoài phạm vi, câu có ý đồ xấu (prompt injection).
- Đủ lớn để có ý nghĩa thống kê — 20 mẫu thì một mẫu sai đã làm điểm rớt 5%; thường tối thiểu 100–300 mẫu cho v1, càng nhiều càng ổn định.
- Có nhãn/đáp án chuẩn (gold label) — do người làm, là "sự thật" để đối chiếu.
- Được "đóng băng" và versioned — không sửa test set giữa chừng rồi so điểm, vì như vậy là so hai thước đo khác nhau.
Tình huống thực tế
Ví dụ 1: Tiki — chatbot chăm sóc khách hàng trả lời sai cỡ áo
Giả định một đội tại sàn TMĐT lớn như Tiki build chatbot trả lời câu hỏi về sản phẩm và đơn hàng. Bản demo đầu tiên ai cũng khen "thông minh". PM cho ship pilot 5% traffic. Hai tuần sau, support nhận khiếu nại: chatbot khẳng định "Áo này còn đủ size từ S đến XXL" trong khi kho chỉ còn mỗi size S — model bịa cho "đẹp lời".
Vấn đề gốc: đội không hề có eval criteria. Họ đo "cảm tính" trên vài chục câu dễ. Sau sự cố, PM viết lại mục eval trong spec:
- Auto eval: với câu hỏi tồn kho, trích xuất danh sách size model nói ra, so exact match với dữ liệu kho thật. Ngưỡng: accuracy ≥ 98% (đây là thông tin sự thật, không được sai).
- LLM-judge: chấm 1–5 độ hữu ích và độ lịch sự trên 200 câu mẫu hằng ngày. Ngưỡng trung bình ≥ 4.0.
- Human eval: mỗi tuần 1 chuyên viên CS đọc 50 câu ngẫu nhiên, đánh dấu mọi trường hợp bịa thông tin. Ngưỡng: tỷ lệ bịa < 1%.
Ví dụ 2: MoMo — tính năng tóm tắt lịch sử chi tiêu, dùng ROUGE rồi nhận ra chưa đủ
Giả định đội ví điện tử MoMo làm tính năng AI tóm tắt chi tiêu tháng ("Tháng này bạn chi 4.2 triệu, nhiều nhất là ăn uống 1.8 triệu..."). Ban đầu họ chỉ dùng ROUGE so với bản tóm tắt mẫu do team viết. Điểm ROUGE cao, ai cũng yên tâm.
Khi human eval, họ phát hiện một lớp lỗi mà ROUGE không bắt: model đôi khi tóm tắt trôi chảy nhưng sai con số — ghi "1.8 triệu" thành "1.6 triệu". ROUGE thấy từ ngữ trùng nhiều nên vẫn cho điểm cao, dù con số sai là lỗi chí mạng với app tài chính.
Họ bổ sung tầng eval mới: tách riêng các con số trong output và đối chiếu chính xác với dữ liệu giao dịch gốc (auto eval theo kiểu trích xuất + so khớp số), đặt ngưỡng 100% — sai một số là fail. ROUGE giữ lại để đo độ mạch lạc của văn phong, nhưng không còn là tiêu chí gác cổng duy nhất.
Bài học: chọn metric phải khớp với cái thật sự quan trọng. Một metric "có vẻ học thuật" như ROUGE không tự động phù hợp. Hãy tách bài toán thành các thuộc tính (độ chính xác con số, độ trôi chảy, độ đầy đủ) và gán cho mỗi thuộc tính một cách đo riêng.
Ví dụ 3: Startup edtech — LLM-judge bị "thổi điểm" vì rubric mơ hồ
Một startup giáo dục ở TP.HCM làm AI chấm bài luận tiếng Anh của học viên. Họ dùng LLM-judge để đánh giá xem feedback của model có chất lượng không, rubric ghi vỏn vẹn: "Feedback có tốt không? Cho điểm 1–10."
Kết quả eval đẹp tuyệt: trung bình 8.7/10. Nhưng học viên phàn nàn feedback chung chung, sáo rỗng. Khi điều tra, đội nhận ra rubric quá mơ hồ khiến judge mặc định cho điểm cao mọi câu trả lời dài và "nghe có vẻ chuyên nghiệp".
Họ viết lại rubric thành các tiêu chí cụ thể, mỗi tiêu chí có mô tả từng mức điểm: "Feedback có chỉ ra ÍT NHẤT 2 lỗi cụ thể kèm vị trí câu không? (0/1). Có đề xuất cách sửa chứ không chỉ nói 'sai' không? (0/1). Có khen điểm mạnh cụ thể không? (0/1)." Đồng thời họ căn chỉnh judge bằng 40 mẫu đã được giáo viên thật chấm, kiểm tra judge có khớp với người không trước khi tin nó.
Bài học: LLM-judge chỉ tốt bằng rubric bạn viết. Rubric mơ hồ tạo ra điểm số ảo. Luôn căn chỉnh (calibrate) judge với một mẫu nhỏ do người chấm trước khi dùng nó ở quy mô lớn.
Hướng dẫn từng bước
Đây là quy trình để bạn viết mục Eval Criteria & Test Set trong spec AI:
Bước 1 — Liệt kê các thuộc tính chất lượng (quality dimensions). Tự hỏi: tính năng này "tốt" nghĩa là gì? Thường gồm: độ chính xác thông tin, độ liên quan, độ an toàn (không bịa, không độc hại), giọng điệu, độ đầy đủ, độ ngắn gọn. Viết ra danh sách cụ thể cho tính năng của bạn.
Bước 2 — Gán phương pháp đo cho từng thuộc tính. Thuộc tính có đáp án khách quan (con số, phân loại, thông tin sự thật) → auto eval. Thuộc tính tinh tế (giọng điệu, độ hữu ích) → LLM-judge. Thuộc tính rủi ro cao hoặc rất chủ quan → human eval. Một thuộc tính có thể dùng nhiều tầng.
Bước 3 — Đặt ngưỡng pass/fail cho từng metric. Ngưỡng phải là con số. "Accuracy ≥ 90%", "tỷ lệ bịa < 1%", "điểm hữu ích trung bình ≥ 4.0/5". Phân biệt ngưỡng gác cổng (chặn ship nếu không đạt) và ngưỡng theo dõi (chỉ để quan sát).
Bước 4 — Xây test set. Lấy câu hỏi thật từ log (nếu có), bổ sung edge case có chủ đích. Gán gold label do người làm. Đảm bảo phủ các nhóm câu hỏi theo đúng tỷ lệ thực tế. Đặt tên và version cho test set (vd: cs-chatbot-eval-v1, 250 mẫu).
Bước 5 — Định nghĩa nhịp chạy eval. Auto eval chạy ở đâu (CI mỗi PR?), LLM-judge bao lâu một lần, human eval ở những mốc nào. Ghi rõ ai chịu trách nhiệm và kết quả lưu ở đâu.
Bước 6 — Định nghĩa baseline và quy tắc regression. Phiên bản hiện tại đạt bao nhiêu? Quy tắc: phiên bản mới không được tụt dưới baseline ở bất kỳ metric gác cổng nào. Đây là cách bạn đảm bảo "không xấu đi" sau mỗi lần đổi prompt/model.
Lỗi thường gặp & mẹo
Lỗi 1 — "Vibe check" thay cho eval. Demo vài câu, cả phòng gật gù, ship. Đây là lỗi phổ biến nhất. Vài câu may rủi không nói lên gì về phân phối thật. Mẹo: ép buộc có một test set tối thiểu 100 mẫu trước khi cho phép ship bất kỳ tính năng AI nào.
Lỗi 2 — Test set quá nhỏ hoặc toàn câu dễ. 15 câu hỏi "đẹp" không phản ánh thực tế hỗn loạn. Mẹo: lấy log thật, cố tình nhồi vào các câu khó — tiếng Việt không dấu, viết tắt, câu ngoài phạm vi, câu mơ hồ.
Lỗi 3 — Tin LLM-judge mù quáng. Judge cũng sai, cũng thiên kiến. Mẹo: luôn calibrate judge với 30–50 mẫu người đã chấm; nếu judge lệch người quá nhiều, sửa rubric trước khi dùng.
Lỗi 4 — Chỉ đo điểm trung bình. Trung bình 4.2/5 nghe đẹp, nhưng có thể che giấu 5% câu trả lời thảm họa. Mẹo: luôn nhìn thêm phân phối và tỷ lệ "câu tệ nhất" (vd % câu dưới 2 điểm), đặc biệt với rủi ro an toàn.
Lỗi 5 — Sửa test set giữa chừng rồi khoe điểm tăng. Nếu thay đổi thước đo thì điểm không so sánh được. Mẹo: đóng băng và version test set; muốn cải tiến thì tạo v2 và báo cáo song song cả hai.
Lỗi 6 — Một ngưỡng cho mọi thứ. Thông tin tài chính và lời chào hỏi không thể cùng một ngưỡng. Mẹo: phân tầng rủi ro — thông tin sự thật đặt ngưỡng gần tuyệt đối, yếu tố trải nghiệm có thể nới lỏng hơn.
Bài tập thực hành
Chọn một tính năng AI cụ thể (gợi ý: chatbot trả lời câu hỏi sản phẩm cho một shop thời trang trên Shopee, hoặc tính năng tóm tắt review khách hàng). Viết mục Eval Criteria & Test Set dài khoảng 1 trang, gồm:
- Bảng quality dimensions: liệt kê 4–6 thuộc tính chất lượng, mỗi thuộc tính ghi rõ phương pháp đo (auto / LLM-judge / human) và ngưỡng pass/fail bằng con số.
- Mô tả test set: bao nhiêu mẫu, lấy nguồn từ đâu, liệt kê ít nhất 5 nhóm edge case bạn cố tình đưa vào, ai gán gold label.
- Một rubric LLM-judge cụ thể: viết rubric cho MỘT thuộc tính tinh tế (vd "độ hữu ích"), chia rõ từng mức điểm 1–5 nghĩa là gì.
- Nhịp chạy & regression rule: ghi rõ eval nào chạy lúc nào, baseline hiện tại (giả định), và quy tắc chặn ship khi tụt điểm.
Tóm tắt
- Tính năng AI cho ra một phân phối output chứ không phải một giá trị đúng duy nhất, nên không thể đánh giá bằng acceptance criteria thông thường — phải có eval criteria riêng.
- Ba loại eval bổ sung nhau: auto eval (exact match, BLEU, ROUGE — rẻ, nhanh, khách quan, cho thứ có đáp án rõ); LLM-as-judge (model chấm model theo rubric — bắt được sắc thái, cần calibrate); human eval (gold standard — đắt, chậm, dùng cho mốc lớn và xây nền).
- Eval criteria phải đi cùng một test set tốt: đại diện thực tế, phủ edge case, đủ lớn, có gold label, được version và đóng băng.
- Mỗi metric phải có ngưỡng pass/fail bằng con số, phân tầng theo rủi ro; có baseline và quy tắc regression để đảm bảo không xấu đi.
- Quy trình PM nên theo: liệt kê quality dimensions → gán phương pháp đo → đặt ngưỡng → xây test set → định nhịp chạy → định baseline.
- Tránh các bẫy: vibe check, test set nhỏ/dễ, tin judge mù quáng, chỉ nhìn điểm trung bình, sửa test set giữa chừng, một ngưỡng cho mọi thứ.