Evals như là Tiêu chí Chấp thuận (Acceptance Criteria): Xây dựng chất lượng ngay từ khâu phát triển

Evals trước khi Code: Vì sao thứ tự lại quan trọng?

Một eval là một bài kiểm tra có cấu trúc nhằm xác minh xem hệ thống có trả về kết quả đúng như kỳ vọng và chính xác hay không. Nghe có vẻ đơn giản, nhưng thời điểm thực hiện lại vô cùng quan trọng. Cách tiếp cận truyền thống là xây dựng hệ thống xong, xem nó chạy có vẻ ổn không, rồi mới tiến hành test sau. Đây không phải lúc nào cũng là cách tốt nhất đối với AI.

Việc viết bộ eval suite trước khi viết code production sẽ ép bạn làm 3 việc mà bình thường rất dễ bị trì hoãn:

1. Định nghĩa rõ thế nào là thành công bằng các tiêu chí có thể đo lường được.

2. Phơi bày các giả định thiết kế từ sớm, khi việc thay đổi chúng vẫn còn ít tốn kém.

3. Tạo ra một chốt chặn (gate) để xác định xem liệu việc đổi model, đổi prompt, hay chiến lược truy xuất (retrieval) mới có thực sự cải thiện hệ thống hay không.

Một bộ eval suite phải thuộc về giai đoạn đầu của quá trình phát triển, được định nghĩa trước khi viết code, chứ không phải một bước QA ở cuối chu trình. Thực tế, nếu bạn không thể viết một eval cho một hành vi, bạn không có cách nào đáng tin cậy để đo lường xem hành vi đó có thực sự tồn tại hay không. Đồng nghĩa với việc mọi thay đổi bạn đưa vào hệ thống đều không thể kiểm chứng. Xây dựng eval từ đầu cho phép bạn liên tục xác thực chất lượng xuyên suốt toàn bộ quá trình build.

Luồng làm việc của Eval: Từ định nghĩa tác vụ đến kết quả

Một luồng eval được cấu trúc tốt sẽ chạy tuần tự qua 5 giai đoạn dưới đây. Mỗi giai đoạn tạo ra một tài sản đầu vào cho giai đoạn tiếp theo:

Phân biệt Code-based Evals vs. Model-based Evals: Khi nào dùng loại nào?

Không phải hành vi nào cũng có thể kiểm tra bằng cùng một cách.

• Một số hành vi có đáp án tuyệt đối: đầu ra có phải chuẩn JSON hay không.

• Một số hành vi khác lại thuộc về cảm nhận: đầu ra có đúng tông giọng hay văn phong hay không. Hai nhóm này cần các công cụ đánh giá khác nhau. Chọn đúng công cụ giúp đảm bảo độ chính xác và tiết kiệm chi phí.

3 loại evals mang lại các sự đánh đổi khác nhau giữa tốc độ và tính linh hoạt:

1. Code-based evals: Chạy kiểm tra định tính (deterministic) trong vài mili-giây và gần như không tốn chi phí.

2. Model-based evals: Dùng một model làm giám khảo để chấm điểm các đầu ra cần sự diễn giải; tốn kém tương đương với một lần gọi model bình thường.

3. Human-review evals: Phụ thuộc vào con người cho các hành vi mới lạ hoặc có rủi ro quá cao, nơi cả code lẫn model judge đều không đủ độ tin cậy. Đây là cách chậm nhất và đắt đỏ nhất.

Thang bậc chấm điểm (The grading ladder)

Không phải mọi hành vi đều được chấm điểm như nhau. Việc lựa chọn phương pháp tuân theo một "thang bậc" có tính toán: luôn chọn phương pháp rẻ nhất, đáng tin cậy nhất và chỉ leo lên bậc cao hơn khi bản chất hành vi bắt buộc phải thế.

1. Chấm bằng Code (Code-based grading): Ưu tiên ở bất cứ đâu có thể. Rẻ, chạy mili-giây, không bao giờ bị trôi (drift).

2. LLM làm giám khảo (LLM-as-judge): Khi cần diễn giải. Hãy làm cho nó chặt chẽ bằng cách: dùng rubrics chi tiết, giới hạn kết quả (cho label cố định thay vì điểm số tự do), hiệu chuẩn bằng con người, và đừng dùng chính model vừa tạo ra câu trả lời làm giám khảo chấm điểm câu trả lời đó (để tránh tự thiên vị - self-preference).

3. Con người chấm (Human grading): Phương sách cuối cùng. Dành cho các tính năng mới toanh hoặc rủi ro cực lớn.

Hiệu chuẩn Giám khảo (Judge calibration): Bước mà nhiều team thường bỏ qua

Bản thân một LLM judge cũng là một hệ thống có thể mắc sai lầm. Trước khi tin tưởng nó, bạn phải hiệu chuẩn (calibrate). Bằng cách cho nó chạy qua một tập dữ liệu đã được con người chấm, bạn so sánh xem độ tương đồng giữa phán quyết của AI và con người có đủ cao không. Một giám khảo chưa được hiệu chuẩn sẽ đưa ra các điểm số vô cùng tự tin nhưng hoàn toàn lệch chuẩn. Điều này còn nguy hiểm hơn cả việc không có điểm số nào, vì nó tạo ra ảo giác về sự an toàn.

Nguyên tắc chung: Ưu tiên Số lượng thay vì Sự hoàn hảo (Volume over perfection). Một bộ eval tự động có thể chấm liên tục trên diện rộng và bắt được nhiều lỗi hồi quy (regression) hơn là một tập dữ liệu nhỏ xíu chỉ đợi con người cặm cụi chấm bằng tay.

Định nghĩa Tiêu chí thành công: Từ yêu cầu kinh doanh đến ranh giới đo lường

Một yêu cầu kinh doanh kiểu như "tóm tắt hồ sơ bồi thường chính xác" không cung cấp cho bạn thông số nào để đo lường. Quá trình chuyển hóa nó thành tiêu chí eval gồm các bước:

1. Xác định hành vi cụ thể: Câu trên cần đổi thành "Trích xuất được Tên người gửi, Mã hồ sơ, Ngày xảy ra sự cố, và Số tiền bồi thường từ mỗi tài liệu."

2. Thiết lập ngưỡng (Threshold): Quyết định thế nào là Đạt. (Ví dụ: chính xác 100% các trường cấu trúc, tỷ lệ bịa đặt/hallucination < 2%, chuẩn schema 99.5%). Đừng lấy số liệu từ bản prototype chạy hên xui, hãy lấy từ yêu cầu kinh doanh thực tế.

3. Nhận diện các mẫu thất bại (Failure modes): Kế thừa ví dụ trên, đầu ra không chấp nhận được bao gồm: mã hồ sơ giả mạo (hallucinated), thiếu ngày tháng, hoặc lấy nhầm số liệu từ một hồ sơ khác bị lẫn vào. Mỗi failure mode trở thành một danh mục trong eval dataset của bạn.

4. Bao gồm cả Dữ liệu nhiễu (Adversarial inputs): Phải đưa vào các tài liệu bị thiếu trường thông tin, viết tay xấu xí, định dạng dị biệt, layout lộn xộn. Nếu Golden dataset của bạn chỉ chứa dữ liệu sạch bong, điểm số eval sẽ không bao giờ phản ánh đúng thực tế trên production.

Evals như là chốt chặn (Gating mechanism) cho mọi thay đổi

Bất kỳ thay đổi nào đưa lên production — đổi model, sửa prompt, đổi chiến lược context, cập nhật cơ chế retrieval — đều bắt buộc phải chạy qua eval suite trong môi trường phát triển trước. Đây là cách duy nhất để biết thay đổi đó có thực sự làm hệ thống tốt lên hay không.

(Lưu ý đối với hội thoại dài): Một eval set đơn lượt (single-turn) sẽ không cho bạn biết hệ thống chịu tải thế nào qua một cuộc trò chuyện dài. Multi-turn evals là một hạng mục riêng biệt để kiểm tra xem hệ thống có nhớ context cũ không, có bịa đặt thông tin khi trả lời câu hỏi phụ không, và chất lượng có giảm khi đoạn chat kéo dài không. Loại này cần một Golden dataset riêng gồm toàn bộ lịch sử đoạn chat dài để mô phỏng chính xác.

Bài học thực tế: Một team làm tính năng tóm tắt tài liệu đã sửa prompt nhưng quên không cập nhật eval suite. Eval chạy pass 100%. Hai ngày sau khi lên production, khách hàng báo lỗi các điều khoản pháp lý phức tạp bị tóm tắt sai lệch hoàn toàn. Nguyên nhân: Bộ eval được tạo từ trước khi sửa prompt nên không bắt được hành vi mới.Tóm lại: Chạy eval trước mọi thay đổi là cách duy nhất để giữ cho bộ eval đồng bộ với chính hệ thống mà nó đang đo lường.

Chi phí · Độ phức tạp · Rủi ro

• Chi phí (Cost): Mọi model-based eval đều tốn một lượt gọi API. Hãy để tâm đến chi phí, nhưng đừng vì thế mà bóp nghẹt kích thước bộ eval. Rủi ro lớn nhất là đánh giá hời hợt (under-evaluating): một lỗi nghiêm trọng lọt lên production do bộ eval quá nhỏ sẽ tốn kém hơn gấp ngàn lần so với tiền trả cho vài lượt gọi API.

• Độ phức tạp (Complexity): Có một hạ tầng eval đồng nghĩa với việc bạn phải duy trì một hệ thống song song thứ hai. Golden dataset phải luôn được cập nhật, Judge prompts phải được tinh chỉnh liên tục, và ngưỡng Pass/Fail phải được cân chỉnh khi nghiệp vụ thay đổi.

• Rủi ro (Risk): Một bộ eval suite lỗi thời mang lại sự tự tin giả tạo (false confidence). Nó tạo ảo giác rằng một bản cập nhật là an toàn, trong khi thực tế nó đang đo lường một hành vi đã không còn tồn tại trong hệ thống. Thời điểm rủi ro xảy ra lỗi hồi quy (regression) cao nhất chính là lúc bạn có eval nhưng bộ eval đó lại bị lỗi thời.