LLM Evals: Đo lường chất lượng AI trước khi nó âm thầm phá sản phẩm

Phần lớn team ra mắt tính năng LLM đầu tiên bằng cách nhìn output vài chục lần, thấy "ổn", rồi ship. Cách này nhanh, và trong tuần đầu tiên nó có vẻ hiệu quả. Vấn đề chỉ lộ ra khi prompt đổi, model nâng cấp, hoặc traffic thật bắt đầu đổ vào: không ai trong team trả lời được câu hỏi "phiên bản mới có tốt hơn phiên bản cũ không, hay chỉ là cảm giác vậy?"

Evals giải quyết đúng câu hỏi đó - bằng cách biến "có vẻ ổn" thành một con số có thể so sánh qua thời gian, qua từng lần đổi prompt, đổi model, hay đổi dữ liệu.

Vì sao LLM không thể test như phần mềm truyền thống

Test phần mềm truyền thống có một câu trả lời đúng duy nhất: hàm add(2, 3) phải trả về 5, không có cách diễn giải nào khác. LLM thì không vậy - hỏi cùng một câu hai lần, model có thể trả lời khác nhau, và cả hai câu trả lời đều có thể đúng. "Tóm tắt đoạn văn này" có hàng chục cách tóm tắt hợp lệ; "câu trả lời này có đồng cảm không" phụ thuộc vào người đọc; một câu trả lời mượt trên vài chục ví dụ demo vẫn có thể vỡ trận trước một câu hỏi lộn xộn, viết tắt, hoặc mang tính đối kháng mà người dùng thật gõ vào.

Vì output là xác suất chứ không tất định, một eval không phải bài kiểm tra chạy một lần rồi cất vào ngăn kéo. Xác suất một câu trả lời đúng dịch chuyển ngay khi prompt, model, hay dữ liệu thay đổi - nên eval phải chạy lại ở mỗi lần thay đổi đó, không phải chỉ một lần khi mới launch.

Evals thực chất là gì

Bóc tách nhỏ nhất, một eval gồm bốn phần: một task (input cụ thể kèm tiêu chí thành công), một trial (một lượt thử task đó - chạy nhiều lượt vì output có thể khác nhau giữa các lần), một grader (logic chấm điểm lượt thử đó), và một transcript (toàn bộ dấu vết của lượt thử: output, lệnh gọi tool, các bước suy luận trung gian). Với tác vụ đơn lượt như tóm tắt hay phân loại, transcript đơn giản chỉ là output cuối. Với agent gọi tool qua nhiều bước, transcript là cả chuỗi hành động - và đó là điểm khác biệt lớn nhất giữa eval cho một lệnh gọi model đơn lẻ và eval cho một agent.

Bậc thang ba cấp độ: từ Unit Test tới A/B Test

Hệ thống eval trưởng thành không chạy một loại kiểm tra duy nhất cho mọi thay đổi - nó có ba cấp độ, mỗi cấp một chi phí và một vai trò khác nhau.

Cấp 1 - Unit Test là assertion tất định: JSON có đúng schema không, code sinh ra có pass test không, câu trả lời có chứa field bắt buộc không. Chạy trong vài giây, gần như miễn phí, và chạy trên mọi commit. Đây là lớp bắt các regression đã biết trước khi chúng lên production.

Cấp 2 - Model & Human Eval vào cuộc khi câu hỏi không còn là đúng/sai máy móc mà là "câu trả lời này có tốt không". Team log lại transcript thật, một người có chuyên môn đọc và gán nhãn (nhị phân, không phải thang điểm), rồi dùng chính những nhãn đó để hiệu chỉnh một LLM judge chấm ở quy mô lớn hơn.

Cấp 3 - A/B Test chỉ nên bật khi sản phẩm đã đủ chín để tin vào cấp 1 và 2: chia traffic thật, đo hành vi người dùng thật, xác nhận rằng cải thiện trên eval set thật sự chuyển thành cải thiện trải nghiệm - không chỉ là con số đẹp trên một tập dữ liệu tĩnh.

Trước khi viết evaluator, hãy đọc trace thật

Sai lầm phổ biến nhất không phải là thiếu công cụ - mà là viết evaluator trước khi hiểu sản phẩm đang hỏng ở đâu. Cách đúng là ngược lại: đọc vài chục transcript thật, tự tay gán nhãn đạt/không đạt, và để chính quá trình đọc đó chỉ ra loại lỗi nào lặp lại - rồi mới viết assertion hay rubric nhắm đúng vào loại lỗi đó.

Vài quy tắc nhỏ nhưng tạo khác biệt lớn: nhãn nhị phân (đạt/không đạt) buộc người gán nhãn phải quyết đoán, còn thang điểm 1-5 chỉ tạo tranh cãi về ranh giới giữa điểm 3 và điểm 4. Nên có một người - không phải một uỷ ban - làm chủ định nghĩa "thế nào là tốt" cho từng tính năng, để tránh việc mỗi người gán nhãn theo một chuẩn khác nhau. Và việc đọc dữ liệu này không nên giao hẳn cho một đội ngoài: vòng lặp giữa "thấy lỗi thật" và "sửa sản phẩm" chính là thứ tạo ra tiến bộ, cắt nó ra khỏi người ra quyết định thì tiến bộ cũng đứt theo.

Ba loại giám khảo: code, model, và người

Sau khi đã biết cần chấm cái gì, câu hỏi tiếp theo là ai chấm.

Giám khảo code-based kiểm tra được thứ có câu trả lời đúng/sai rõ ràng - định dạng, sự tồn tại của một field, một test case pass hay fail. Rẻ, nhanh, không bao giờ đổi ý giữa hai lần chạy trên cùng một input. Nhưng nó chỉ xác nhận hình dạng đúng, không xác nhận nội dung có đúng hay không.

Giám khảo model-based (LLM-as-judge) vào cuộc khi tiêu chí mang tính chủ quan - tông giọng, mức độ hữu ích, có bám sát hướng dẫn thương hiệu không. Một model được prompt bằng đúng rubric mà người review dùng có thể chấm hàng nghìn lượt mỗi ngày. Nhưng một judge chưa được hiệu chỉnh chỉ là một phỏng đoán tự động hoá: trước khi tin nó, cần đối chiếu phán quyết của nó với 100-200 nhãn người trên cùng dữ liệu, đo xem tỷ lệ đồng thuận có đủ cao không.

Giám khảo con người vẫn là lớp cuối cùng cho những case mơ hồ, rủi ro cao, hoặc quá mới để có đủ dữ liệu huấn luyện judge. Nó không scale được tới mọi request - và không cần phải scale tới mọi request, chỉ cần scale tới đúng phần mẫu mà một quyết định sai thật sự tốn kém.

Bài toán kinh tế đằng sau việc pha trộn ba loại giám khảo

Không đội nào đủ sức cho người review 100% lượt eval, và cũng không đội nào nên tin tưởng 100% vào một judge chưa hiệu chỉnh cho mọi loại lỗi. Bài toán kinh tế nghiêng hẳn về phía pha trộn: để phần lớn lượt eval đi qua lớp rẻ nhất mà vẫn đủ tin cậy, dành lớp giữa cho quy mô, và chỉ dùng lớp đắt nhất - con người - cho đúng phần nhỏ nơi cái giá của một câu trả lời sai đủ lớn để đáng trả.

Khi agent bước vào cuộc chơi, eval khác đi thế nào

Với một lệnh gọi model đơn lẻ, chấm điểm nghĩa là chấm một output. Với một agent gọi tool, đọc dữ liệu, và tự quyết bước tiếp theo qua nhiều lượt, chấm điểm phải nhìn vào cả transcript lẫn outcome cuối - trạng thái thật sự để lại trong hệ thống, chẳng hạn một booking có thật sự tồn tại đúng trong database hay không, không chỉ là văn bản agent nói ra.

Đặc thù này kéo theo hai điều dễ bị bỏ sót. Một, grader không nên đòi hỏi agent đi đúng từng bước theo một kịch bản cố định - chấm cái agent tạo ra, không chấm con đường nó đi, vì có nhiều con đường hợp lệ dẫn tới cùng một outcome đúng. Hai, nếu một agent frontier fail gần như toàn bộ trial trên một task, nhiều khả năng task đó đang được đặc tả sai hoặc chính bản thân grader có lỗi - chứ không phải agent thật sự bất lực; nên đọc lại task trước khi kết luận agent kém.

Năm mảnh ghép của một hệ thống eval hoàn chỉnh

Xâu chuỗi lại, một hệ thống eval hoàn chỉnh cần năm mảnh ghép, mỗi mảnh là một quyết định riêng đáng được đào sâu:

Error analysis. Quy trình đọc trace và gán nhãn trước khi viết bất kỳ evaluator nào, cùng với việc ai là người có quyền quyết định "thế nào là đạt".

Unit-test / code-based eval. Cách viết assertion đủ chặt để bắt regression mà không quá cứng nhắc tới mức từ chối những cách giải đúng nhưng khác kịch bản.

LLM-as-judge. Cách thiết kế rubric, chọn giữa chấm theo tiêu chí đơn lẻ hay so sánh cặp, và quy trình hiệu chỉnh judge với nhãn người.

Human evaluation. Cách xây công cụ xem trace không gây khó chịu, và nhịp độ spot-check hợp lý khi sản phẩm đã có judge tự động.

Agent evals - cách định nghĩa outcome, xử lý tính không tất định giữa các trial, và nhận diện dấu hiệu bão hoà khi eval suite không còn phân biệt được agent tốt với agent kém nữa.

Cạm bẫy thường gặp và hình dạng của một hệ thống eval hoạt động tốt

Vài cạm bẫy lặp lại ở hầu hết các team: coi eval là một lần chạy rồi thôi thay vì một quy trình chạy lại ở mỗi thay đổi; tối ưu quá tay trên chính eval set cho tới khi con số đẹp nhưng sản phẩm thật không khá lên; dùng metric chung chung như "độ hữu ích" thay vì xây tiêu chí riêng cho đúng thất bại của sản phẩm mình; và tin một LLM judge ngay từ đầu mà chưa từng đối chiếu với một người.

Bỏ qua từng kỹ thuật cụ thể, một hệ thống eval hoạt động tốt chỉ làm đúng ba việc: bắt buộc nhìn vào dữ liệu thật trước khi đoán, chọn đúng giám khảo rẻ nhất mà vẫn đáng tin cho từng loại câu hỏi, và chạy lại đều đặn mỗi khi có gì đó thay đổi. Làm đúng ba việc này, một team không còn phải đoán liệu bản cập nhật mới nhất có tốt hơn - họ có số để trả lời.