Giải mã đánh giá (evals) cho các tác nhân AI

Đánh giá tốt giúp các nhóm phát triển AI agent một cách tự tin hơn. Nếu không có chúng, rất dễ rơi vào vòng lặp phản ứng—chỉ phát hiện vấn đề khi đã đưa vào sản xuất, nơi việc sửa một lỗi lại tạo ra những lỗi khác. Đánh giá (evals) giúp làm rõ các vấn đề và thay đổi hành vi trước khi chúng ảnh hưởng đến người dùng, và giá trị của chúng tăng dần theo vòng đời của một agent.

Như chúng tôi đã mô tả trong bài viết "Xây dựng agent hiệu quả", các agent hoạt động qua nhiều lượt: gọi công cụ, thay đổi trạng thái và thích ứng dựa trên kết quả trung gian. Chính những khả năng khiến AI agent hữu ích—tự chủ, thông minh và linh hoạt—cũng khiến chúng khó đánh giá hơn.

Thông qua công việc nội bộ và hợp tác với các khách hàng tiên phong trong phát triển agent, chúng tôi đã học được cách thiết kế các đánh giá chặt chẽ và hữu ích hơn cho agent. Dưới đây là những gì đã hiệu quả trên nhiều kiến trúc agent và trường hợp sử dụng trong triển khai thực tế.

Một "đánh giá" (eval) là một bài kiểm tra cho hệ thống AI: đưa cho AI một đầu vào, sau đó áp dụng logic chấm điểm cho đầu ra của nó để đo lường mức độ thành công. Trong bài viết này, chúng tôi tập trung vào các đánh giá tự động có thể chạy trong quá trình phát triển mà không cần người dùng thực.

Đánh giá một lượt (single-turn evaluations) rất đơn giản: một prompt, một phản hồi và logic chấm điểm. Đối với các LLM đời đầu, đánh giá một lượt, không có agent là phương pháp đánh giá chính. Khi khả năng AI tiến bộ, đánh giá nhiều lượt (multi-turn evaluations) ngày càng phổ biến.

Đánh giá agent (agent evaluations) thậm chí còn phức tạp hơn. Agent sử dụng công cụ qua nhiều lượt, thay đổi trạng thái trong môi trường và thích ứng khi chúng hoạt động—điều này có nghĩa là sai lầm có thể lan truyền và chồng chất. Các mô hình tiên tiến cũng có thể tìm ra giải pháp sáng tạo vượt quá giới hạn của các đánh giá tĩnh. Ví dụ, Opus 4.5 đã giải quyết một bài toán 𝜏2-bench về đặt vé máy bay bằng cách phát hiện một lỗ hổng trong chính sách. Nó "thất bại" trong đánh giá như đã viết, nhưng thực tế lại đưa ra giải pháp tốt hơn cho người dùng.

Khi xây dựng đánh giá agent, chúng tôi sử dụng các định nghĩa sau:

Khi các nhóm lần đầu bắt đầu xây dựng agent, họ có thể tiến xa một cách đáng ngạc nhiên thông qua sự kết hợp giữa kiểm thử thủ công, dogfooding và trực giác. Đánh giá chặt chẽ hơn thậm chí có thể giống như một gánh nặng làm chậm quá trình phát hành. Nhưng sau giai đoạn tạo mẫu ban đầu, khi agent đã được đưa vào sản xuất và bắt đầu mở rộng quy mô, việc xây dựng mà không có đánh giá bắt đầu đổ vỡ.

Điểm bùng phát thường đến khi người dùng báo cáo rằng agent cảm thấy tệ hơn sau các thay đổi, và nhóm "bay mù" mà không có cách nào để xác minh ngoài việc đoán và kiểm tra. Thiếu đánh giá, việc gỡ lỗi chỉ mang tính phản ứng: chờ đợi khiếu nại, tái tạo thủ công, sửa lỗi và hy vọng không có gì khác bị suy giảm. Các nhóm không thể phân biệt sự suy giảm thực sự với nhiễu, tự động kiểm tra các thay đổi trên hàng trăm kịch bản trước khi phát hành, hoặc đo lường cải tiến.

Chúng tôi đã thấy quá trình này diễn ra nhiều lần. Ví dụ, Claude Code bắt đầu với việc lặp lại nhanh dựa trên phản hồi từ nhân viên Anthropic và người dùng bên ngoài. Sau đó, chúng tôi thêm các đánh giá—đầu tiên cho các lĩnh vực hẹp như sự súc tích và chỉnh sửa tệp, sau đó cho các hành vi phức tạp hơn như thiết kế quá mức. Những

Các bài đánh giá (evals) đã giúp xác định vấn đề, định hướng cải tiến và tập trung các hợp tác nghiên cứu-sản phẩm. Kết hợp với giám sát sản xuất, thử nghiệm A/B, nghiên cứu người dùng và hơn thế nữa, evals cung cấp các tín hiệu để tiếp tục cải thiện Claude Code khi nó mở rộng quy mô.

Viết evals hữu ích ở bất kỳ giai đoạn nào trong vòng đời của agent. Ban đầu, evals buộc các nhóm sản phẩm phải xác định rõ thành công có nghĩa là gì đối với agent, trong khi về sau, chúng giúp duy trì một tiêu chuẩn chất lượng nhất quán.

Agent của Descript giúp người dùng chỉnh sửa video, vì vậy họ đã xây dựng evals xoay quanh ba khía cạnh của một quy trình chỉnh sửa thành công: không làm hỏng việc, làm những gì tôi yêu cầu và làm tốt. Họ đã phát triển từ chấm điểm thủ công sang chấm điểm bằng LLM với các tiêu chí do nhóm sản phẩm xác định và hiệu chuẩn con người định kỳ, và hiện tại thường xuyên chạy hai bộ riêng biệt để đánh giá chất lượng và kiểm tra hồi quy. Nhóm TheBoltAI bắt đầu xây dựng evals muộn hơn, sau khi họ đã có một agent được sử dụng rộng rãi. Trong 3 tháng, họ đã xây dựng một hệ thống eval chạy agent của mình và chấm điểm đầu ra bằng phân tích tĩnh, sử dụng các agent trình duyệt để kiểm tra ứng dụng và sử dụng các bộ đánh giá LLM cho các hành vi như tuân theo hướng dẫn.

Một số nhóm tạo evals ngay từ đầu quá trình phát triển; những nhóm khác thêm chúng khi đã mở rộng quy mô, khi evals trở thành nút thắt cổ chai để cải thiện agent. Evals đặc biệt hữu ích khi bắt đầu phát triển agent để mã hóa rõ ràng hành vi mong đợi. Hai kỹ sư đọc cùng một bản đặc tả ban đầu có thể có những cách hiểu khác nhau về cách AI nên xử lý các trường hợp ngoại lệ. Một bộ eval giải quyết sự mơ hồ này. Bất kể chúng được tạo ra khi nào, evals đều giúp tăng tốc độ phát triển.

Evals cũng định hình tốc độ bạn có thể áp dụng các mô hình mới. Khi các mô hình mạnh hơn xuất hiện, các nhóm không có evals phải đối mặt với hàng tuần thử nghiệm trong khi các đối thủ có evals có thể nhanh chóng xác định điểm mạnh của mô hình, tinh chỉnh prompt của họ và nâng cấp trong vài ngày.

Khi đã có evals, bạn sẽ có sẵn các đường cơ sở (baselines) và kiểm tra hồi quy: độ trễ, mức sử dụng token, chi phí mỗi tác vụ và tỷ lệ lỗi có thể được theo dõi trên một ngân hàng tác vụ tĩnh. Evals cũng có thể trở thành kênh giao tiếp băng thông cao nhất giữa nhóm sản phẩm và nhóm nghiên cứu, xác định các chỉ số mà các nhà nghiên cứu có thể tối ưu hóa. Rõ ràng, evals có những lợi ích rộng rãi vượt xa việc theo dõi hồi quy và cải tiến. Giá trị tích lũy của chúng dễ bị bỏ qua vì chi phí hiện hữu ngay từ đầu trong khi lợi ích tích lũy về sau.

Chúng tôi thấy một số loại agent phổ biến được triển khai ở quy mô lớn hiện nay, bao gồm agent viết mã, agent nghiên cứu, agent sử dụng máy tính và agent hội thoại. Mỗi loại có thể được triển khai trên nhiều ngành công nghiệp khác nhau, nhưng chúng có thể được đánh giá bằng các kỹ thuật tương tự. Bạn không cần phải phát minh ra một phương pháp đánh giá từ đầu. Các phần dưới đây mô tả các kỹ thuật đã được kiểm chứng cho một số loại agent. Sử dụng các phương pháp này làm nền tảng, sau đó mở rộng chúng sang lĩnh vực của bạn.

Đánh giá agent thường kết hợp ba loại bộ đánh giá: dựa trên mã, dựa trên mô hình và con người. Mỗi bộ đánh giá đánh giá một phần nào đó của bản ghi (transcript) hoặc kết quả. Một phần thiết yếu

Một thành phần quan trọng trong thiết kế đánh giá hiệu quả là chọn đúng người chấm điểm cho từng nhiệm vụ.

Đối với mỗi tác vụ, việc chấm điểm có thể được tính trọng số (điểm tổng hợp từ các giám khảo phải đạt ngưỡng), nhị phân (tất cả giám khảo phải đạt yêu cầu), hoặc kết hợp cả hai.

Đánh giá năng lực hay "chất lượng" đặt câu hỏi: "Tác nhân này làm tốt việc gì?" Chúng nên bắt đầu với tỷ lệ đậu thấp, nhắm vào các nhiệm vụ mà tác nhân gặp khó khăn và tạo ra một thử thách để các nhóm vượt qua.

Đánh giá hồi quy đặt câu hỏi: "Tác nhân có còn xử lý tốt tất cả các nhiệm vụ trước đây không?" và nên có tỷ lệ đậu gần 100%. Chúng bảo vệ khỏi sự suy giảm hiệu suất, vì điểm số giảm là dấu hiệu cho thấy có điều gì đó bị hỏng và cần được cải thiện. Khi các nhóm leo dốc trên các đánh giá năng lực, điều quan trọng là cũng phải chạy các đánh giá hồi quy để đảm bảo các thay đổi không gây ra vấn đề ở nơi khác.

Sau khi một tác nhân được triển khai và tối ưu hóa, các đánh giá năng lực với tỷ lệ đậu cao có thể "tốt nghiệp" để trở thành bộ đánh giá hồi quy, được chạy liên tục để phát hiện bất kỳ sai lệch nào. Các nhiệm vụ từng đo lường "Chúng ta có thể làm được điều này không?" sau đó đo lường "Chúng ta vẫn có thể làm điều này một cách đáng tin cậy chứ?"

Các tác nhân viết mã viết, kiểm tra và gỡ lỗi mã, điều hướng cơ sở mã và chạy lệnh giống như một lập trình viên con người. Các đánh giá hiệu quả cho các tác nhân viết mã hiện đại thường dựa vào các nhiệm vụ được xác định rõ ràng, môi trường kiểm tra ổn định và các bài kiểm tra kỹ lưỡng cho mã được tạo ra.

Người chấm điểm xác định là lựa chọn tự nhiên cho các tác nhân viết mã vì phần mềm thường dễ đánh giá: mã có chạy và các bài kiểm tra có đạt không? Hai chuẩn đánh giá tác nhân viết mã được sử dụng rộng rãi, SWE-bench Verified và Terminal-Bench, tuân theo cách tiếp cận này. SWE-bench Verified cung cấp cho các tác nhân các vấn đề GitHub từ các kho lưu trữ Python phổ biến và chấm điểm giải pháp bằng cách chạy bộ kiểm tra; một giải pháp chỉ đạt yêu cầu nếu nó sửa các bài kiểm tra thất bại mà không làm hỏng các bài kiểm tra hiện có. LLM đã tiến bộ từ 40% lên hơn 80% trên đánh giá này chỉ trong một năm. Terminal-Bench đi theo một hướng khác: nó kiểm tra các nhiệm vụ kỹ thuật từ đầu đến cuối, chẳng hạn như xây dựng một nhân Linux từ mã nguồn hoặc huấn luyện một mô hình ML.

Khi bạn đã có một bộ