Xây hệ thống AI Eval cho đội nhỏ: golden set, LLM-as-a-judge, regression, chi phí và cổng phát hành
Hướng dẫn đội nhỏ xây AI Eval thực dụng: xác định failure mode, tạo golden set, human review, LLM-as-a-judge, regression suite, cost-quality dashboard và release gate.
Phần lớn đội sản phẩm AI không thất bại vì thiếu model mạnh, mà vì không biết phiên bản mới thực sự tốt hơn hay chỉ tạo cảm giác tốt hơn trong vài prompt mẫu. Một thay đổi nhỏ ở system prompt, model, retrieval, tool schema hoặc temperature có thể cải thiện nhóm câu hỏi này nhưng làm hỏng nhóm khác. Nếu không có hệ thống đánh giá lặp lại, quyết định release dễ dựa vào demo đẹp, trực giác của người viết prompt và phản hồi rời rạc từ người dùng.
AI Eval là quy trình biến chất lượng vốn mơ hồ thành tập tiêu chí, dữ liệu kiểm thử, phương pháp chấm, ngưỡng và quyết định phát hành. Đội nhỏ không cần xây phòng nghiên cứu hay benchmark hàng triệu mẫu. Một hệ thống tốt có thể bắt đầu bằng vài chục tình huống quan trọng, được chọn từ lỗi thật, chấm bằng rubric rõ và chạy tự động mỗi khi prompt, model hoặc pipeline thay đổi.
Bài viết này hướng dẫn xây eval từ đầu cho chatbot, RAG, AI agent và workflow tự động hóa. Trọng tâm là những phần tạo giá trị thực: failure taxonomy, golden set, pairwise comparison, human review, LLM-as-a-judge, tool-call eval, adversarial test, chi phí, latency, release gate và vòng phản hồi từ production.
1. Eval không phải benchmark chung trên internet
Benchmark công khai hữu ích để hiểu khả năng tổng quát của model, nhưng không trả lời liệu hệ thống của bạn có trích đúng chính sách hoàn tiền, tạo đúng draft trong CMS hay từ chối thao tác vượt quyền. Product eval phải phản ánh task, dữ liệu, ngôn ngữ, người dùng và rủi ro của sản phẩm cụ thể.
Một hệ thống dùng cùng model vẫn có kết quả khác nhau vì prompt, context window, retrieval, chunking, tool, policy và post-processing. Vì vậy, không thể dùng điểm model công bố thay cho đánh giá end-to-end. Eval cần đo cả thành phần và hành trình hoàn chỉnh.
Đội nên tách ba lớp: model capability eval; component eval cho retrieval, classifier hoặc tool selection; và system eval cho kết quả cuối. Khi lỗi xảy ra, cấu trúc này giúp biết nên sửa prompt, dữ liệu, tool hay policy.
2. Bắt đầu từ failure mode, không bắt đầu từ metric
Trước khi chọn exact match hay LLM judge, hãy liệt kê cách hệ thống có thể thất bại. Với RAG: không tìm được nguồn, chọn nguồn cũ, trích sai, suy diễn quá mức hoặc không nêu thiếu dữ liệu. Với agent: chọn sai tool, truyền sai tham số, vượt quyền, retry vô hạn, báo thành công khi mutation thất bại. Với content: sai sự kiện, lặp ý, giọng máy móc, thiếu nguồn, nội dung quá ngắn hoặc vi phạm quyền ảnh.
Mỗi failure mode cần severity, detectability và business impact. Lỗi câu chữ nhẹ không ngang với gửi email nhầm người hay publish dữ liệu sai. Có thể dùng risk score để ưu tiên test. Nhóm lỗi nghiêm trọng cần hard gate; nhóm phong cách có thể dùng score và human review theo mẫu.
Failure taxonomy nên được version hóa. Khi có incident mới, thêm category và test case. Eval không phải dự án một lần; nó là bộ nhớ vận hành về những cách hệ thống từng sai.
3. Viết rubric có thể chấm nhất quán
Rubric tốt mô tả điều quan sát được. Thay vì “câu trả lời hay”, dùng các tiêu chí như: trả lời đúng câu hỏi; mọi claim quan trọng có nguồn; không bịa dữ liệu; nêu rõ bất định; tuân thủ độ dài; dùng giọng phù hợp; và CTA đúng mục tiêu. Mỗi tiêu chí có thang điểm cùng ví dụ đạt, chưa đạt và lỗi nghiêm trọng.
Không nên gom tất cả thành một điểm duy nhất quá sớm. Một output có thể trôi chảy nhưng sai fact. Nếu trung bình hóa, điểm phong cách che lỗi factual. Hãy giữ dimension riêng, sau đó định nghĩa rule: factuality dưới ngưỡng thì fail bất kể tổng điểm.
Rubric phải phù hợp với người chấm. Human reviewer cần hướng dẫn ngắn, ví dụ biên. LLM judge cần prompt chấm chỉ dựa trên input, reference, output và rubric; không được tự bổ sung kiến thức không có trong gói đánh giá nếu mục tiêu là groundedness.
4. Xây golden set từ dữ liệu thật
Golden set là tập tình huống đại diện được duyệt kỹ. Nguồn tốt nhất gồm ticket hỗ trợ, query phổ biến, task doanh thu cao, incident, edge case và yêu cầu nhạy cảm. Không chỉ chọn câu dễ mà model thường làm đúng. Tập dữ liệu cần bao phủ normal, difficult, adversarial và out-of-scope.
Mỗi case nên có ID, input, context, expected behavior, reference facts, rubric, tags, severity, source và owner. Với tác vụ có nhiều đáp án hợp lệ, không ép exact text; mô tả các thuộc tính bắt buộc và điều cấm. Với tool-call, lưu expected tool, parameter constraints, side effect và trạng thái cuối.
Golden set không nên thay đổi tùy tiện để phiên bản mới pass. Khi cập nhật reference vì chính sách hoặc dữ liệu thay đổi, lưu version và chạy lại baseline. Tách immutable regression cases từ exploratory cases để tránh đánh mất lịch sử.
5. Bao nhiêu test case là đủ cho đội nhỏ?
Không có con số cố định. Có thể bắt đầu 40–80 case được chọn tốt, miễn bao phủ các luồng trọng yếu. Mỗi tuần thêm case từ lỗi mới. Độ bao phủ theo failure mode quan trọng hơn tổng số. Một nghìn câu lặp cùng pattern không hữu ích bằng hai trăm case đa dạng có severity.
Dùng ma trận feature × user type × language × risk. Ví dụ hệ thống hỗ trợ Việt và Anh, có người dùng mới và admin, có tác vụ đọc và ghi. Đảm bảo mỗi ô quan trọng có case. Với feature mới, thêm test trước hoặc cùng lúc phát triển.
Khi suite lớn, tạo tầng smoke nhỏ chạy trên mỗi commit, regression đầy đủ chạy trước release và shadow eval chạy trên production sample. Điều này cân bằng tốc độ và độ tin cậy.
6. Exact match, rule-based và semantic scoring
Exact match phù hợp ID, enum, số, code hoặc output có format chặt. Rule-based phù hợp kiểm tra JSON schema, field bắt buộc, citation tồn tại, độ dài, forbidden phrase, quyền và số tool call. Đây là các evaluator rẻ, ổn định và dễ debug; nên dùng trước khi gọi judge model.
Semantic similarity hữu ích khi có reference answer nhưng diễn đạt khác nhau. Tuy nhiên, similarity cao không bảo đảm đúng fact. Một câu sai chỉ một số vẫn rất giống. Vì vậy cần kết hợp extraction, claim check hoặc judge theo rubric.
Thiết kế eval pipeline theo tầng: validate cấu trúc; kiểm tra policy; kiểm tra factual hoặc groundedness; chấm usefulness và style. Nếu fail hard constraint, không cần tốn chi phí chấm phần còn lại.
7. Human evaluation vẫn là chuẩn quan trọng
Human review cần cho tiêu chí tinh tế, hiệu chỉnh judge và quyết định case tranh cãi. Người chấm nên được huấn luyện trên cùng rubric và chấm blind khi so sánh hai phiên bản. Không cho biết output nào đến từ model mới để giảm thiên kiến.
Đo inter-rater agreement để biết rubric có rõ không. Nếu người chấm thường bất đồng, vấn đề có thể nằm ở tiêu chí chứ không phải output. Tổ chức calibration session: cùng chấm một nhóm case, thảo luận khác biệt, cập nhật ví dụ.
Không yêu cầu human đọc mọi output. Dùng sampling có chủ đích: lỗi severity cao, judge confidence thấp, disagreement, distribution shift và một tỷ lệ ngẫu nhiên. Human feedback sau đó trở thành dữ liệu hiệu chỉnh.
8. LLM-as-a-judge: lợi ích và giới hạn
LLM judge giúp chấm nhanh các tiêu chí ngôn ngữ hoặc pairwise comparison. Nhưng judge có bias theo độ dài, phong cách, vị trí A/B, model family và cách prompt. Nó có thể bị output đánh lừa hoặc tự suy diễn. Vì vậy judge không nên là nguồn sự thật duy nhất cho tác vụ rủi ro cao.
Để giảm bias, dùng rubric cụ thể, yêu cầu trích bằng chứng từ output, randomize vị trí, chạy nhiều lần khi cần và hiệu chỉnh với human-labeled set. Có thể dùng pairwise vì dễ hơn chấm tuyệt đối: output nào đáp ứng yêu cầu tốt hơn và vì sao. Tuy nhiên vẫn phải có tiêu chí hard fail độc lập.
Theo dõi precision và recall của judge đối với lỗi quan trọng. Nếu judge bỏ sót hallucination, không được dùng điểm tổng để release. Judge version cũng phải được cố định; đổi model chấm có thể thay metric dù system không đổi.
9. Eval cho RAG
RAG cần tách retrieval và generation. Retrieval eval đo recall@k, precision@k, relevance, freshness, access control và source diversity. Generation eval đo groundedness, citation correctness, completeness, abstention và usefulness. Nếu chỉ chấm câu trả lời cuối, khó biết retrieval hay model gây lỗi.
Mỗi case cần gold sources hoặc ít nhất evidence set. Kiểm tra liệu nguồn đúng có nằm trong top-k, citation có trỏ đúng đoạn và claim có được hỗ trợ. Khi không có nguồn, hệ thống phải biết từ chối hoặc yêu cầu thêm dữ liệu thay vì bịa.
Test cả document conflict, phiên bản cũ, quyền khác tenant, query mơ hồ, câu hỏi ngoài kho và prompt injection trong tài liệu. Đây là các failure mode production thường bỏ sót trong demo.
10. Eval cho AI agent và tool use
Agent eval không chỉ nhìn final answer. Cần chấm kế hoạch, tool selection, argument, sequence, permission, retry và state cuối. Một agent có thể trả lời đúng nhưng gọi thừa tool tốn tiền hoặc đọc dữ liệu không cần thiết. Một agent khác có câu trả lời đẹp nhưng mutation thất bại mà vẫn báo thành công.
Dùng sandbox và fixture có thể reset. Mỗi case định nghĩa initial state, allowed tools, forbidden actions và expected final state. Sau run, query database hoặc mock service để xác nhận. Tool output phải được giữ trong trace để debug.
Test duplicate request, timeout, stale version, permission denial, malformed output, tool unavailable và prompt injection. Với thao tác nguy hiểm, tiêu chí quan trọng là agent dừng đúng lúc, xin xác nhận và không vòng qua policy.
11. Adversarial và safety eval
Red-team case phải phản ánh tài sản và boundary thật: yêu cầu tiết lộ prompt, secret, PII, nội dung tenant khác, thực hiện hành động không được phép, làm theo instruction trong tài liệu không tin cậy hoặc tạo nội dung vi phạm chính sách. Không chỉ dùng jailbreak phổ biến chung chung.
Phân biệt refusal đúng và over-refusal. Hệ thống quá chặt có thể từ chối tác vụ hợp lệ. Dataset cần cặp gần nhau: một yêu cầu hợp lệ và một yêu cầu vi phạm để đánh giá boundary. Score cả safe completion, escalation và explanation.
Safety eval phải chạy khi thay prompt, tool, auth, retrieval hoặc model. Một thay đổi tăng helpfulness có thể giảm refusal. Hard gate cho lỗi rò rỉ dữ liệu, vượt quyền hoặc side effect nguy hiểm.
12. Chi phí và latency là một phần của chất lượng
Phiên bản tốt hơn 1% nhưng tốn gấp năm và chậm gấp ba có thể không phù hợp. Mỗi eval run cần ghi input/output token, tool calls, retrieval calls, latency p50/p95, timeout và estimated cost. Chấm cost per successful task, không chỉ cost per request.
Tạo Pareto frontier giữa quality, cost và latency. Routing có thể dùng model nhỏ cho case đơn giản, model mạnh cho case khó. Eval routing policy bằng cùng dataset và đo cả sai phân loại. Nếu router chọn model yếu cho case nghiêm trọng, quality trung bình có thể vẫn đẹp nhưng risk tăng.
Đặt budget regression: release không được tăng cost quá ngưỡng nếu quality không cải thiện tương xứng. Với agent, giới hạn step và retry; theo dõi vòng lặp không tiến triển.
13. Pairwise comparison và A/B offline
Khi so phiên bản hiện tại với ứng viên, chạy cùng case, seed và environment. Randomize output A/B cho judge hoặc human. Báo cáo win, tie, loss theo dimension và cohort, không chỉ tổng. Một prompt mới có thể thắng ở tiếng Anh nhưng thua ở tiếng Việt hoặc thắng FAQ nhưng thua mutation.
Thống kê cần kèm sample size và confidence. Với suite nhỏ, một vài case có thể làm dao động lớn. Xem diff từng failure severity cao. Không release chỉ vì win rate tổng dương nếu có regression critical.
Lưu artifacts: prompt version, model ID, parameters, dataset hash, evaluator version, code commit và timestamp. Kết quả không reproducible không đủ để làm release evidence.
14. Thiết kế release gate
Release gate nên có hard và soft criteria. Hard: không có critical safety failure; tool permission đúng; schema pass; factuality trên ngưỡng; không regression ở top business flows. Soft: style, verbosity, user preference. Ứng viên phải vượt baseline theo rule đặt trước, không đổi rule sau khi thấy kết quả.
Cho phép exception nhưng phải có owner, lý do, phạm vi và ngày hết hạn. Ví dụ chấp nhận regression nhẹ ở một cohort nếu có mitigation và feature flag. Không dùng ngoại lệ để hợp thức hóa mọi release gấp.
Sau offline gate, canary production nhỏ. Theo dõi complaint, fallback, escalation, conversion, latency và cost. Có kill switch và rollback. Offline eval không bao phủ toàn bộ phân phối thực.
15. Production feedback loop
Thu sample có mục đích từ production: thumbs down, user correction, abandoned flow, repeated query, tool error, support ticket và high-cost session. Bảo vệ PII và quyền dữ liệu. Gán failure tag và đưa case đại diện vào regression suite sau review.
Không đưa nguyên dữ liệu production vào golden set mà không làm sạch. Deduplicate, redact, xác nhận quyền và tách train/eval. Nếu prompt được tối ưu trực tiếp trên toàn golden set, đội sẽ overfit. Giữ holdout set chỉ dùng trước release lớn.
Dashboard production phải liên kết eval metric với business outcome. Groundedness tăng có giảm complaint không? Tool accuracy tăng có giảm manual correction không? Nếu metric không liên quan outcome, cần xem lại rubric.
16. Kiến trúc eval tối thiểu
Một stack đơn giản gồm dataset repository, runner, system adapter, evaluator library, result store, artifact store và dashboard. Dataset có version trong Git. Runner gọi phiên bản hệ thống trong môi trường cô lập. Evaluator chạy rule, judge và human queue. Result store giữ score và metadata.
Không cần nền tảng phức tạp từ ngày đầu. CSV hoặc JSONL có schema tốt, script reproducible và CI job đã tạo giá trị. Khi suite lớn, thêm experiment tracking, distributed run và review UI. Ưu tiên contract dữ liệu trước giao diện.
Secrets và production access phải tách. Eval environment dùng fixture, mock hoặc dữ liệu đã ẩn danh. Không để test agent gửi email thật, publish thật hoặc charge thật.
17. Kế hoạch 30 ngày
Tuần 1: định nghĩa top use case, failure taxonomy và rubric; chọn 40 case. Tuần 2: xây runner, rule evaluator, baseline và artifact metadata. Tuần 3: thêm human review, judge calibration, RAG hoặc tool final-state checks. Tuần 4: tích hợp CI gate, canary, production sampling và quy trình thêm case sau incident.
Trong tháng đầu, mục tiêu không phải score hoàn hảo mà là tạo vòng lặp đáng tin: thay đổi nào cũng có bằng chứng, lỗi mới trở thành test, và release decision không phụ thuộc một người demo.
18. Quy trình xử lý một regression từ phát hiện đến rollback
Khi suite báo regression, đội không nên chỉ nhìn điểm trung bình rồi chạy lại cho tới khi xanh. Trước hết khóa đúng artifact: commit, prompt, model snapshot, tool schema, retrieval index và tham số sampling. So sánh case thất bại với baseline để xác định lỗi đến từ dữ liệu, evaluator hay hệ thống được đánh giá. Một judge thay đổi hành vi cũng có thể tạo báo động giả, vì vậy các case critical cần rule hoặc nhãn người độc lập.
Mỗi failure được phân loại theo mức độ ảnh hưởng và độ tin cậy của phép chấm. Lỗi làm lộ dữ liệu, gọi sai tool có side effect hoặc đưa ra quyết định không thể đảo ngược phải chặn release ngay. Lỗi phong cách nhỏ có thể đi vào backlog nếu KPI cốt lõi không giảm. Owner ghi giả thuyết, phép thử phân biệt và quyết định; không sửa prompt hàng loạt khi chưa biết failure mode.
Sau khi có bản sửa, chạy lại tập case bị ảnh hưởng, toàn bộ regression suite và một tập holdout chưa dùng khi tối ưu. Nếu pass, canary với giới hạn traffic, ngân sách và quyền tool; theo dõi error, override của người dùng, latency và chi phí. Nếu tín hiệu xấu, rollback model hoặc prompt phải là thao tác đã diễn tập, không phải thay đổi thủ công trong lúc incident. Case production gây ra sự cố sau đó được làm sạch dữ liệu nhạy cảm, thêm vào golden set và gắn với post-mortem để lỗi không quay lại dưới tên khác.
Checklist AI Eval
- Failure taxonomy phản ánh rủi ro thật.
- Rubric có ví dụ pass, fail và critical.
- Golden set có normal, edge và adversarial.
- Dataset, prompt, model và evaluator được version hóa.
- Rule-based check chạy trước judge.
- Human calibration được thực hiện.
- LLM judge được đo với nhãn người.
- RAG tách retrieval và generation.
- Agent kiểm tra final state và permission.
- Chi phí, latency, step và retry được ghi.
- Release gate có tiêu chí đặt trước.
- Canary và rollback hoạt động.
- Lỗi production trở thành regression case.
Câu hỏi thường gặp
Có thể dùng một model để tự chấm chính nó không?
Có thể cho thử nghiệm thấp rủi ro, nhưng dễ bias. Nên dùng rubric, randomization, human calibration và evaluator khác khi có thể. Lỗi critical cần rule hoặc human độc lập.
Golden set có phải đáp án hoàn hảo không?
Không nhất thiết là một đoạn văn duy nhất. Nó có thể là reference facts, thuộc tính bắt buộc, tool sequence hoặc final state. Điều quan trọng là đủ rõ để chấm nhất quán.
Khi nào cần hàng nghìn case?
Khi sản phẩm có nhiều phân phối, ngôn ngữ, tác vụ hoặc rủi ro và đội cần power thống kê cao hơn. Trước đó, vài trăm case được quản lý tốt thường có giá trị hơn kho dữ liệu lớn nhưng không có rubric.
Đọc thêm trên VietBoost
- Quy trình test và security review cho AI coding agent
- Thiết kế cổng phê duyệt và audit log cho AI Agent
Nguồn tham khảo
Kết luận
AI Eval tốt không cố biến mọi phẩm chất thành một con số duy nhất. Nó tạo bằng chứng đủ để biết thay đổi nào cải thiện, lỗi nào nghiêm trọng và khi nào không nên release. Đội nhỏ nên bắt đầu từ failure mode và golden set, kết hợp rule, human cùng judge, sau đó nối eval với CI và production. Khi mỗi incident làm suite mạnh hơn, chất lượng AI sẽ trở thành năng lực vận hành thay vì may rủi theo model.
