Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn vừa ship một tính năng chatbot tư vấn sản phẩm cho một sàn thương mại điện tử ở Việt Nam. Trong demo nội bộ, nó trả lời mượt mà, ai cũng gật gù. Nhưng ba tuần sau khi lên production, bộ phận chăm sóc khách hàng gửi cho bạn một loạt ảnh chụp màn hình: chatbot khẳng định một chiếc nồi chiên không dầu "có chế độ hấp" (sai), khuyên khách "đổi trả trong 60 ngày" trong khi chính sách chỉ là 7 ngày, và một lần nó trả lời một câu hỏi về bảo hành bằng tiếng Anh dù khách hỏi tiếng Việt.
Câu hỏi nhức nhối là: tại sao những lỗi này không bị phát hiện trước khi lên production? Câu trả lời nằm ở chỗ phần lớn các PM khi làm AI vẫn dùng tư duy kiểm thử của phần mềm truyền thống — viết vài test case, chạy qua, thấy "ổn" là ship. Nhưng AI không vận hành theo cách đó. Một hệ thống AI không có khái niệm "pass/fail" rạch ròi như một hàm tính tổng. Nó có thể đúng 95% số lần và sai 5% còn lại theo những cách bạn không bao giờ ngờ tới.
Bài học hôm nay đặt nền móng cho toàn bộ cụm bài về đánh giá AI (các bài tiếp theo sẽ đi sâu vào hallucination, guardrails, A/B testing, drift detection). Ở đây, chúng ta trả lời câu hỏi gốc rễ: vì sao đánh giá AI khó hơn nhiều so với phần mềm truyền thống, và một AI Evaluation Framework đúng nghĩa gồm những gì? Nắm vững khung này, bạn sẽ không bao giờ "ship rồi cầu nguyện" nữa.
Khái niệm cốt lõi
Vì sao eval AI khó hơn phần mềm truyền thống
Với phần mềm truyền thống, kiểm thử dựa trên một giả định nền tảng: tính xác định (deterministic). Cùng một input luôn cho ra cùng một output. Hàm tinh_thue(1000000) luôn trả về đúng một con số. Bạn viết test, so sánh kết quả thực tế với kết quả kỳ vọng, và biết chắc chắn đúng hay sai. Với AI — đặc biệt là các mô hình ngôn ngữ lớn (LLM) — bốn đặc tính sau phá vỡ giả định đó:
1. Output không xác định (non-deterministic). Cùng một câu hỏi, hỏi hai lần, mô hình có thể trả lời khác nhau về từ ngữ, độ dài, thậm chí cả nội dung. Điều này đến từ cơ chế sampling (lấy mẫu xác suất) khi sinh chữ. Bạn không thể viết một test kiểu assert output == "câu trả lời chính xác" vì không tồn tại một câu trả lời "chính xác" duy nhất.
2. "Đúng" thường mang tính chủ quan. Với câu hỏi "Tóm tắt giúp tôi hợp đồng này", thế nào là một bản tóm tắt tốt? Ngắn gọn hay đầy đủ? Giữ thuật ngữ pháp lý hay diễn giải dễ hiểu? Hai chuyên gia có thể chấm điểm khác nhau cho cùng một output. Cái "đúng" ở đây không phải đúng/sai nhị phân mà là một phổ chất lượng, phụ thuộc ngữ cảnh và kỳ vọng người dùng.
3. Edge case ở phần đuôi dài (long-tail). Người dùng thật sẽ gõ những thứ bạn không bao giờ tưởng tượng nổi: viết tắt teen code, trộn tiếng Việt không dấu với tiếng Anh, hỏi ngoài phạm vi, cố tình lừa mô hình. Với phần mềm truyền thống, không gian input hữu hạn và có thể liệt kê. Với AI, không gian input gần như vô hạn — và lỗi thường nằm chính ở những trường hợp hiếm gặp mà bạn không có trong tập test.
4. Trôi dạt theo thời gian (drift). Một phần mềm đã đúng thì đúng mãi (trừ khi bạn sửa code). Một hệ thống AI có thể tốt hôm nay nhưng tệ dần đi: nhà cung cấp âm thầm cập nhật model, hành vi người dùng thay đổi, dữ liệu thực tế lệch khỏi dữ liệu lúc bạn test. Chất lượng AI không phải hằng số — nó là một biến cần theo dõi liên tục.
Bốn trụ cột của một AI Evaluation Framework
Một khung đánh giá AI đầy đủ không chỉ là "chạy test trước khi ship". Nó là một hệ thống có bốn trụ cột:
Trụ cột 1 — Eval dataset (bộ dữ liệu đánh giá). Một tập hợp các input đại diện kèm theo "ground truth" (đáp án/kỳ vọng) hoặc tiêu chí chấm. Đây là xương sống. Eval dataset tốt phải bao phủ cả happy path lẫn edge case, được cập nhật liên tục từ lỗi production.
Trụ cột 2 — Metrics (thước đo). Cách quy chất lượng thành con số để so sánh được. Có ba nhóm:
- Metric tự động dựa trên tham chiếu: so output với đáp án mẫu (ví dụ exact match, BLEU, ROUGE cho dịch/tóm tắt).
- Metric dựa trên mô hình (model-based / LLM-as-judge): dùng một LLM khác để chấm điểm output theo tiêu chí (độ chính xác, độ liên quan, giọng điệu).
- Metric con người (human eval): chuyên gia trực tiếp chấm — đắt nhưng đáng tin cậy nhất, dùng làm chuẩn vàng.
Trụ cột 4 — Vòng lặp liên tục (continuous loop). Eval không phải việc làm một lần trước launch. Bạn cần đo offline (trước ship), online (trên production), thu thập feedback, đưa lỗi mới vào eval dataset, và lặp lại.
Offline eval vs online eval
Đây là phân biệt then chốt mà nhiều PM bỏ qua. Offline eval chạy trên eval dataset cố định, trong môi trường kiểm soát, trước khi ship — giúp bạn so sánh phiên bản A với B, prompt cũ với prompt mới. Online eval đo chất lượng trên lưu lượng thật ở production — qua proxy metrics (tỷ lệ người dùng bấm "không hữu ích", tỷ lệ chuyển sang nhân viên thật, thời gian hội thoại) và qua sampling một phần traffic để con người chấm. Bạn cần cả hai. Offline cho tốc độ và khả năng so sánh; online cho sự thật về hành vi người dùng thực.
Tình huống thực tế
Tình huống 1 — Tiki và chatbot tư vấn sản phẩm
Giả sử đội sản phẩm tại một sàn TMĐT lớn như Tiki xây chatbot tư vấn. Lần đầu, họ test bằng cách... cả team ngồi chat thử mỗi người vài câu, thấy ổn rồi ship. Sau hai tuần, tỷ lệ "escalate sang nhân viên" tăng 18%. Họ không hiểu vì sao cho đến khi dựng eval framework đúng nghĩa.
Họ làm thế này: lấy 500 hội thoại thật từ production, gán nhãn mỗi câu trả lời theo 3 tiêu chí (đúng thông tin sản phẩm, đúng chính sách, đúng ngôn ngữ). Kết quả phơi bày: 12% câu trả lời bịa thông số kỹ thuật, 8% trích sai chính sách đổi trả. Họ biến 500 hội thoại này thành eval dataset cố định, mỗi lần đổi prompt là chạy lại toàn bộ và đo tỷ lệ lỗi trước/sau.
Bài học: demo "ngồi chat thử" không phải eval. Eval cần dataset đại diện, tiêu chí lượng hóa, và đo trên số lượng đủ lớn. Một con số "12% bịa thông tin" cho bạn thứ để cải thiện; cảm giác "nó cũng ổn" thì không.
Tình huống 2 — Startup fintech và LLM-as-judge
Một startup fintech ở TP.HCM xây trợ lý trả lời câu hỏi về sản phẩm vay tiêu dùng. Họ có 2.000 câu hỏi mẫu nhưng không đủ nhân lực để con người chấm tay từng câu mỗi lần đổi model. Giải pháp: dùng LLM-as-judge. Họ viết một prompt chấm điểm yêu cầu một mô hình mạnh (đóng vai giám khảo) đánh giá mỗi câu trả lời trên thang 1–5 theo tiêu chí "chính xác về lãi suất và điều kiện vay", kèm yêu cầu giải thích lý do.
Để LLM-judge đáng tin, họ làm một bước quan trọng: lấy 200 câu cho cả con người và LLM-judge cùng chấm, đo độ tương đồng. Khi LLM-judge khớp với con người ~88%, họ mới tin dùng nó để chấm tự động ở quy mô lớn, chỉ giữ con người để chấm mẫu kiểm tra định kỳ. Nhờ vậy, mỗi lần thử model mới, họ có điểm chất lượng trong 30 phút thay vì 3 ngày.
Bài học: LLM-as-judge là vũ khí để eval ở quy mô lớn với chi phí thấp, nhưng phải hiệu chuẩn (calibrate) với con người trước khi tin tưởng. Đừng dùng LLM chấm mù quáng — judge cũng có thể thiên lệch (thích câu dài, thích văn phong giống nó).
Tình huống 3 — Drift âm thầm sau khi nhà cung cấp cập nhật model
Một công ty SaaS dùng API của một nhà cung cấp LLM để phân loại email khách hàng vào các nhóm (khiếu nại, hỏi giá, hỗ trợ kỹ thuật). Hệ thống chạy ổn định nhiều tháng với độ chính xác ~94%. Rồi một ngày, không ai đụng vào code, nhưng tỷ lệ phân loại sai bỗng tăng. Điều tra ra: nhà cung cấp đã cập nhật phiên bản model phía sau, và cách nó "hiểu" prompt thay đổi nhẹ.
May mắn là họ có một eval dataset 300 email gán nhãn sẵn, chạy tự động hằng tuần như một "canary". Khi điểm rớt từ 94% xuống 86%, cảnh báo nổ ngay, họ kịp ghim phiên bản model (pin version) và điều chỉnh prompt.
Bài học: chất lượng AI có thể trôi mà bạn không làm gì cả. Một eval dataset chạy định kỳ theo lịch chính là "hệ thống cảnh báo cháy" — không có nó, bạn chỉ biết khi khách hàng phàn nàn.
Hướng dẫn từng bước
Đây là quy trình dựng một AI Evaluation Framework tối thiểu nhưng đầy đủ cho sản phẩm của bạn:
Bước 1 — Định nghĩa "tốt" trước khi đo bất cứ thứ gì. Ngồi với team viết ra 3–5 tiêu chí cụ thể cho output. Tránh tiêu chí mơ hồ như "trả lời hay". Thay vào đó: "không bịa thông tin ngoài knowledge base", "trả lời đúng ngôn ngữ người dùng", "đúng chính sách công ty". Mỗi tiêu chí phải chấm được.
Bước 2 — Xây eval dataset đại diện. Bắt đầu với 50–200 case. Lấy từ ba nguồn: câu hỏi thật từ user/CSKH, edge case team nghĩ ra (input lạ, tấn công, ngoài phạm vi), và happy path. Gán "ground truth" hoặc tiêu chí chấm cho từng case. Đây là tài sản quý nhất — đầu tư nghiêm túc.
Bước 3 — Chọn phương pháp chấm phù hợp. Với task có đáp án rõ (phân loại, trích xuất): dùng metric tự động như accuracy, F1. Với task mở (tóm tắt, tư vấn): dùng LLM-as-judge có rubric rõ ràng, cộng human eval trên mẫu nhỏ để hiệu chuẩn.
Bước 4 — Chạy offline eval và thiết lập đường cơ sở (baseline). Chạy hệ thống hiện tại trên eval dataset, ghi lại điểm. Đây là baseline. Mọi thay đổi sau này (đổi prompt, đổi model) phải so với baseline này để biết tốt lên hay tệ đi.
Bước 5 — Thiết lập online eval trên production. Chọn proxy metrics đo được tự động (tỷ lệ "không hữu ích", tỷ lệ escalate, độ dài hội thoại) và sampling một phần traffic cho con người chấm định kỳ.
Bước 6 — Đóng vòng lặp. Mỗi lỗi phát hiện ở production phải được đưa vào eval dataset để lần sau không tái diễn. Lên lịch chạy eval định kỳ (mỗi tuần, hoặc mỗi lần deploy) như canary chống drift.
Lỗi thường gặp & mẹo
Lỗi 1 — Coi demo là eval. "Cả team chat thử thấy ổn" không phải đánh giá. Vài chục lượt chat ngẫu nhiên không bao phủ được long-tail và không cho con số so sánh được.
Lỗi 2 — Eval dataset quá nhỏ hoặc thiên lệch. Nếu dataset chỉ toàn happy path do chính team nghĩ ra, bạn sẽ có điểm đẹp nhưng vẫn vỡ trận ngoài thực tế. Luôn đưa edge case và dữ liệu thật vào.
Lỗi 3 — Tin LLM-as-judge mù quáng. Judge có thiên lệch riêng. Luôn hiệu chuẩn với con người trên một mẫu trước khi dùng đại trà, và kiểm tra lại định kỳ.
Lỗi 4 — Eval một lần rồi quên. Không có eval định kỳ thì drift sẽ âm thầm ăn mòn chất lượng. Hãy biến eval thành cron job, không phải việc làm một lần trước launch.
Lỗi 5 — Đo cái dễ đo thay vì cái quan trọng. Đừng vì BLEU/ROUGE dễ tính mà bỏ qua thứ thực sự quyết định trải nghiệm (như "có bịa chính sách không"). Metric phải phục vụ tiêu chí kinh doanh.
Mẹo: Bắt đầu nhỏ. Một eval dataset 50 case có tiêu chí rõ ràng còn giá trị hơn nhiều một kế hoạch hoành tráng không bao giờ chạy. Mẹo khác: lưu lại mọi output cùng input ở production (logging) — đó là mỏ vàng để xây và mở rộng eval dataset.
Bài tập thực hành
- Định nghĩa tiêu chí. Chọn một tính năng AI bạn đang làm hoặc tưởng tượng (ví dụ chatbot CSKH, trợ lý tóm tắt). Viết ra đúng 4 tiêu chí "tốt" cụ thể, mỗi tiêu chí phải chấm được trên thang điểm hoặc nhị phân.
- Dựng mini eval dataset. Tạo 15 case: 7 happy path, 5 edge case (input lạ, ngoài phạm vi, tiếng Việt không dấu, cố tình lừa), 3 case lấy cảm hứng từ lỗi thực tế bạn từng thấy. Gán ground truth hoặc tiêu chí chấm cho mỗi case.
- Phân loại phương pháp chấm. Với tính năng đó, quyết định mỗi tiêu chí nên dùng metric tự động, LLM-as-judge, hay human eval. Giải thích lý do.
- Thiết kế vòng online. Liệt kê 3 proxy metrics bạn có thể đo tự động trên production để phát hiện chất lượng giảm mà không cần con người chấm từng câu.
- Tình huống drift. Viết một đoạn ngắn mô tả: nếu nhà cung cấp model cập nhật phiên bản và chất lượng tụt 8%, hệ thống eval của bạn sẽ phát hiện điều đó như thế nào và trong bao lâu?
Tóm tắt
Đánh giá AI khó hơn phần mềm truyền thống vì bốn lý do gốc: output không xác định, "đúng" thường chủ quan, edge case ở phần đuôi dài, và chất lượng trôi dạt theo thời gian. Vì vậy, tư duy "viết test, pass là ship" không còn dùng được.
Một AI Evaluation Framework đúng nghĩa đứng trên bốn trụ cột: eval dataset đại diện, metrics lượng hóa được (tự động / LLM-as-judge / con người), tiêu chí rõ ràng, và một vòng lặp liên tục kết hợp offline eval (trước ship, để so sánh) với online eval (trên production, để biết sự thật). Ba tình huống — chatbot TMĐT, trợ lý fintech dùng LLM-as-judge, và drift sau khi nhà cung cấp cập nhật model — cho thấy: chỉ cần một eval dataset 300–500 case kèm chạy định kỳ là đã đủ chuyển từ "ship rồi cầu nguyện" sang "ship với bằng chứng".
Hãy bắt đầu nhỏ, định nghĩa "tốt" trước khi đo, hiệu chuẩn judge với con người, và biến eval thành thói quen liên tục chứ không phải việc làm một lần. Các bài tiếp theo sẽ đi sâu vào từng mảnh của khung này — phát hiện hallucination, dựng guardrails, A/B testing và giám sát drift — nhưng tất cả đều đứng trên nền tảng tư duy bạn vừa xây hôm nay.