Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn vừa nâng cấp prompt cho con chatbot chăm sóc khách hàng của mình. Bạn đọc thử vài câu trả lời, thấy "nghe có vẻ hay hơn", nên bạn deploy lên production. Ba ngày sau, tỷ lệ khách hàng bấm nút "chuyển gặp nhân viên" tăng 15%. Bạn không biết vì sao — có phải do prompt mới? Do model nhà cung cấp âm thầm cập nhật? Do một loại câu hỏi mới xuất hiện? Bạn quay lại prompt cũ, nhưng cũng chẳng chắc nó tốt hơn thật.
Đó chính là vibes-based shipping — ship theo cảm tính. Và nó là căn bệnh phổ biến nhất giết chết các sản phẩm AI trong giai đoạn từ demo đến production.
Trong toàn bộ khóa học này, nếu tôi phải chọn ra một bài mà tôi mong bạn nhớ nhất, thì đó chính là bài này. Vì sao? Vì với sản phẩm truyền thống, bạn có thể viết unit test khẳng định 2 + 2 = 4 và nó luôn đúng. Nhưng với sản phẩm AI, đầu ra mang tính xác suất — cùng một câu hỏi, model có thể trả lời theo mười cách khác nhau. Bạn không thể kiểm thử bằng cách so sánh chính xác từng chữ. Bạn cần một hệ thống hoàn toàn khác: evaluations (eval).
Eval là bộ khung đo lường chất lượng đầu ra của hệ thống AI một cách có hệ thống, lặp lại được, và ra quyết định dựa trên dữ liệu thay vì cảm giác. Không có eval, mỗi lần bạn đổi prompt, đổi model, thêm tính năng, bạn đang chơi trò may rủi. Có eval, bạn biết chính xác thay đổi nào làm sản phẩm tốt lên và tốt lên bao nhiêu phần trăm.
Và đây là điều quan trọng về mặt kinh doanh: eval chính là moat (lợi thế cạnh tranh). Đối thủ có thể copy prompt của bạn, copy tính năng của bạn, thậm chí dùng cùng foundation model. Nhưng họ không thể copy bộ eval dataset của bạn — được xây dựng từ hàng nghìn tình huống thực tế mà người dùng của bạn đã gặp. Bộ eval đó chính là thứ giúp bạn cải tiến nhanh hơn, an toàn hơn đối thủ.
Khái niệm cốt lõi
Eval là gì và khác gì so với test truyền thống
Eval là quá trình chạy hệ thống AI trên một tập dữ liệu đầu vào đã biết, rồi chấm điểm đầu ra theo các tiêu chí chất lượng đã định nghĩa. Khác biệt cốt lõi so với test phần mềm thông thường:
- Test truyền thống: pass/fail tuyệt đối, deterministic (luôn cho cùng kết quả).
- Eval AI: chấm theo thang điểm hoặc tỷ lệ, chấp nhận tính xác suất, và mục tiêu là theo dõi xu hướng (regression hay improvement) chứ không phải một con số tuyệt đối.
Ba tầng eval bạn cần xây
Tầng 1 — Unit eval (component-level): Đánh giá từng thành phần nhỏ. Ví dụ với hệ thống RAG, bạn eval riêng phần retrieval: "Với câu hỏi X, hệ thống có lấy đúng tài liệu chứa câu trả lời không?" Đây là eval rẻ, nhanh, chạy được hàng trăm case trong vài giây.
Tầng 2 — End-to-end eval (system-level): Đánh giá toàn bộ pipeline từ input đến output cuối cùng mà người dùng thấy. "Với câu hỏi của khách, câu trả lời cuối cùng có đúng, đủ, đúng giọng thương hiệu không?"
Tầng 3 — Production eval (online): Đo lường trên lưu lượng thật, sau khi đã deploy. Dùng các tín hiệu như tỷ lệ người dùng bấm thumbs-up/down, tỷ lệ chuyển sang nhân viên, thời gian giải quyết, tỷ lệ quay lại hỏi lại.
Ba phương pháp chấm điểm
1. Code-based / deterministic checks. Kiểm tra bằng luật cứng: đầu ra có phải JSON hợp lệ không? Có chứa số điện thoại không được để lộ không? Độ dài có nằm trong giới hạn không? Loại này rẻ và chắc chắn — hãy dùng bất cứ khi nào có thể.
2. LLM-as-judge. Dùng một model (thường là model mạnh hơn) để chấm điểm đầu ra theo một rubric bạn viết ra. Ví dụ: "Chấm câu trả lời này từ 1–5 về mức độ trung thực với tài liệu nguồn. Trả về JSON với điểm và lý do." Đây là phương pháp mạnh nhất cho các tiêu chí chủ quan, nhưng phải hiệu chỉnh cẩn thận vì bản thân judge cũng có thể sai.
3. Human eval. Con người chấm trực tiếp. Đắt và chậm, nhưng là ground truth — chuẩn vàng để hiệu chỉnh hai phương pháp trên. Bạn không chấm human cho mọi thứ, nhưng cần định kỳ để kiểm tra xem LLM-judge có còn khớp với đánh giá của con người không.
Rubric — trái tim của eval
Một rubric là bộ tiêu chí rõ ràng để chấm. Rubric kém: "câu trả lời có tốt không?" — quá mơ hồ. Rubric tốt tách thành các chiều đo cụ thể, mỗi chiều có định nghĩa và thang điểm:
- Faithfulness (trung thực): câu trả lời có bịa thông tin không có trong nguồn không?
- Relevance (liên quan): có trả lời đúng điều người dùng hỏi không?
- Completeness (đầy đủ): có bỏ sót thông tin quan trọng không?
- Tone/Safety: có đúng giọng, có vi phạm chính sách không?
Golden dataset — tài sản quý nhất
Đây là tập các cặp (input, đầu ra mong đợi hoặc tiêu chí) được tuyển chọn kỹ, đại diện cho các tình huống thật mà sản phẩm gặp phải. Golden dataset tốt bao gồm cả happy path (câu hỏi thường gặp), edge case (câu hỏi hiếm, khó), và adversarial case (người dùng cố tình phá). Chính bộ dữ liệu này mới là moat, chứ không phải đoạn code eval.
Tình huống thực tế
Ví dụ 1 — Chatbot ngân hàng số của một fintech Việt Nam
Một fintech ở TP.HCM (gọi là "MoneyGo") triển khai chatbot trả lời câu hỏi về sản phẩm vay tiêu dùng. Giai đoạn đầu, đội sản phẩm ship theo cảm tính: PM đọc thử 10 câu, thấy ổn thì cho lên. Kết quả sau một tháng: bộ phận pháp chế phát hiện chatbot đôi khi bịa lãi suất — nói "lãi suất chỉ 0.9%/tháng" trong khi biểu phí thật là 1.5%. Đây là rủi ro pháp lý nghiêm trọng theo quy định của Ngân hàng Nhà nước.
Đội xây golden dataset gồm 300 câu hỏi thật lấy từ log, mỗi câu gắn với con số/chính sách đúng. Họ thêm một LLM-judge chấm chiều faithfulness: so đầu ra với tài liệu biểu phí chính thức, cờ đỏ mọi con số không khớp. Chạy eval trên phiên bản đang chạy: 8% câu trả lời sai số liệu. Sau khi thêm guardrail buộc chatbot trích nguyên văn biểu phí và không được tự suy diễn, con số rớt xuống 0.3%.
Bài học: Với sản phẩm ở lĩnh vực nhạy cảm (tài chính, y tế, pháp lý), eval không phải "nice to have" — nó là hàng rào bảo vệ doanh nghiệp khỏi rủi ro pháp lý. Và bạn không thể phát hiện lỗi 8% bằng cách đọc thử 10 câu.
Ví dụ 2 — Startup edtech chấm luận văn tiếng Anh
Một startup edtech ở Hà Nội xây tính năng chấm bài viết tiếng Anh cho học sinh luyện thi IELTS. Câu hỏi lớn: khi họ đổi từ một model cũ sang model mới rẻ hơn 40%, chất lượng chấm có tụt không?
Không có eval, đây là canh bạc. Họ đã làm đúng: xây golden dataset gồm 150 bài luận đã được giám khảo IELTS thật chấm điểm. Với mỗi model, họ cho chấm 150 bài rồi so với điểm chuẩn của giám khảo, tính sai số trung bình (mean absolute error). Model cũ lệch trung bình 0.4 band; model mới rẻ hơn lệch 0.9 band — quá nhiều cho một sản phẩm luyện thi. Nhưng khi họ thử một model mới khác kèm rubric chi tiết hơn, sai số xuống còn 0.35 band, thấp hơn cả model cũ, mà chi phí vẫn rẻ hơn 25%.
Bài học: Eval biến quyết định "đổi model" từ đánh bạc thành phép so sánh có bằng chứng. Và đôi khi kết quả khiến bạn bất ngờ — kết hợp model rẻ + rubric tốt có thể vượt model đắt.
Ví dụ 3 — Grab và bài toán regression âm thầm
Bối cảnh giả định hợp lý dựa trên thực tế ngành: một đội làm trợ lý AI nội bộ tại một siêu ứng dụng Đông Nam Á cập nhật prompt để xử lý tốt hơn tiếng Việt có dấu. Prompt mới quả thật cải thiện tiếng Việt, nhưng vô tình làm giảm chất lượng câu trả lời tiếng Anh và tiếng Thái — một dạng regression mà không ai để ý vì họ chỉ test bằng câu tiếng Việt.
Nhờ có eval dataset phủ đủ ba ngôn ngữ, chạy tự động trong CI trước mỗi lần deploy, bảng điểm hiện rõ: tiếng Việt +12%, nhưng tiếng Anh −7%, tiếng Thái −9%. Đội chặn deploy, sửa prompt để không hy sinh ngôn ngữ khác, rồi mới ship.
Bài học: Cải thiện một chiều thường vô tình phá một chiều khác. Eval dataset đa dạng, chạy tự động trước mỗi lần release, chính là "lưới an toàn" bắt các regression âm thầm mà mắt người không thấy.
Hướng dẫn từng bước
Bước 1 — Thu thập dữ liệu thật. Đừng ngồi tưởng tượng câu hỏi. Lấy log thật từ production (hoặc từ giai đoạn beta). Nếu chưa có, hãy tự viết 30–50 case sát thực tế nhất để khởi động, rồi bổ sung dần bằng dữ liệu thật.
Bước 2 — Tuyển golden dataset. Chọn 100–300 case đại diện. Cân bằng ba nhóm: happy path (~60%), edge case (~30%), adversarial (~10%). Với mỗi case, ghi rõ tiêu chí "thế nào là đúng" — có thể là đáp án chuẩn, hoặc rubric mô tả.
Bước 3 — Định nghĩa rubric theo chiều. Đừng chấm một điểm tổng. Tách 3–5 chiều đo cụ thể (faithfulness, relevance, tone...), mỗi chiều có thang điểm và định nghĩa rõ ràng kèm ví dụ điểm cao/điểm thấp.
Bước 4 — Chọn phương pháp chấm cho từng chiều. Ưu tiên code-based cho những gì kiểm được bằng luật (định dạng, độ dài, lộ thông tin cấm). Dùng LLM-judge cho các chiều chủ quan. Giữ human eval cho việc hiệu chỉnh định kỳ.
Bước 5 — Hiệu chỉnh LLM-judge. Cho con người chấm 30–50 case, rồi cho LLM-judge chấm cùng số đó. So mức độ khớp (agreement). Nếu judge lệch nhiều, sửa rubric hoặc prompt của judge cho đến khi khớp trên ~85%. Chỉ khi đó bạn mới tin được điểm của judge.
Bước 6 — Đặt baseline và ngưỡng. Chạy eval trên phiên bản hiện tại để có điểm gốc. Đặt ngưỡng: "không được deploy nếu bất kỳ chiều nào tụt quá 3% so với baseline."
Bước 7 — Tự động hóa trong CI/CD. Biến eval thành một bước bắt buộc trong quy trình release. Mỗi lần đổi prompt/model, eval chạy tự động, in bảng so sánh, chặn deploy nếu vi phạm ngưỡng.
Bước 8 — Vòng lặp online. Sau khi lên production, thu tín hiệu thật (thumbs up/down, tỷ lệ escalate). Đưa các case xấu quay lại làm giàu golden dataset. Đây là vòng lặp cải tiến liên tục.
Lỗi thường gặp & mẹo
Lỗi 1 — Dataset quá nhỏ hoặc toàn happy path. Eval 10 câu dễ thì luôn "pass" nhưng vô dụng. Mẹo: cố tình săn tìm các case khó, các câu người dùng đã phàn nàn, và thêm chúng vào.
Lỗi 2 — Tin mù quáng vào LLM-judge. Judge cũng thiên vị — thường ưu ái câu trả lời dài, câu có giọng tự tin, hoặc câu do cùng "họ" model sinh ra. Mẹo: luôn hiệu chỉnh judge với human, và định kỳ kiểm tra lại vì model nhà cung cấp có thể thay đổi.
Lỗi 3 — Chấm một điểm tổng mơ hồ. "7/10" chẳng cho biết cần sửa gì. Mẹo: luôn tách theo chiều, và luôn yêu cầu judge trả về lý do, không chỉ điểm — lý do là vàng để debug.
Lỗi 4 — Eval không lặp lại được. Nếu chạy hai lần cho hai kết quả khác nhau, bạn không tin được. Mẹo: đặt temperature thấp cho judge, cố định version model, lưu lại toàn bộ input/output để tra cứu.
Lỗi 5 — Bỏ quên chi phí và độ trễ. Eval không chỉ đo chất lượng. Hãy log luôn token, chi phí, latency cho mỗi biến thể để quyết định cân bằng chất lượng — tiền — tốc độ.
Mẹo vàng: Bắt đầu nhỏ nhưng bắt đầu ngay. 30 case tốt hơn 0 case vô hạn. Bộ eval sẽ lớn dần cùng sản phẩm, và mỗi bug production là một case mới bạn thêm vào để không bao giờ tái phạm.
Bài tập thực hành
- Chọn một tính năng AI (của bạn hoặc một sản phẩm bạn dùng, ví dụ chatbot của một ngân hàng VN). Viết ra 20 case: 12 happy path, 5 edge case, 3 adversarial. Với mỗi case, ghi tiêu chí "thế nào là đúng".
- Thiết kế rubric gồm 3 chiều đo cho tính năng đó. Với mỗi chiều, viết định nghĩa và một ví dụ điểm cao, một ví dụ điểm thấp.
- Viết prompt cho LLM-judge chấm một trong ba chiều đó, yêu cầu trả về JSON gồm điểm (1–5) và lý do. Chạy thử trên 5 case và tự đánh giá xem điểm judge có hợp lý không.
- Mô phỏng regression: đổi prompt gốc thành một biến thể, chạy eval trên 20 case, lập bảng so sánh điểm trung bình từng chiều giữa hai phiên bản. Kết luận: nên ship hay không, và vì sao.
Tóm tắt
Không có eval, bạn ship theo cảm tính và không bao giờ biết thay đổi của mình làm sản phẩm tốt lên hay tệ đi. Có eval, mọi quyết định — đổi model, sửa prompt, thêm tính năng — đều dựa trên dữ liệu. Hãy nhớ:
- Xây ba tầng eval: unit (thành phần), end-to-end (hệ thống), production (online).
- Ba cách chấm: code-based (rẻ, chắc), LLM-as-judge (mạnh cho tiêu chí chủ quan, phải hiệu chỉnh), human (chuẩn vàng).
- Golden dataset phủ happy path, edge case, adversarial — chính là moat thật sự của bạn.
- Rubric tách theo chiều, luôn đòi lý do chứ không chỉ điểm số.
- Tự động hóa eval trong CI để chặn regression trước khi lên production.
- Bắt đầu nhỏ, bắt đầu ngay — mỗi bug là một case mới làm giàu bộ eval.