Agent Evals: Chấm Theo Outcome, Không Phải Đường Đi Của Agent
Một agent gọi tool qua nhiều bước phá vỡ giả định mà mọi eval đơn lượt dựa vào. Agent evals là lớp cuối cùng: chấm theo trạng thái thật agent để lại, chấp nhận nhiều đường đi hợp lệ, và chạy đủ trial để phân biệt tín hiệu thật với nhiễu.
Thuộc chuỗi bài: LLM Evals: Đo lường chất lượng AI trước khi nó âm thầm phá sản phẩm
Mọi eval đã nói tới trong pillar này - unit test, LLM judge, người review - đều chấm một output duy nhất: một bản tóm tắt, một câu trả lời, một phân loại. Agent phá vỡ giả định đó ngay lập tức. Nó đọc dữ liệu, gọi tool, tự quyết bước tiếp theo, và làm vậy qua nhiều lượt trước khi tạo ra thứ gì đó trông giống một câu trả lời cuối cùng. Chấm cả chuỗi đó theo cách chấm một output sẽ bỏ sót gần như mọi thứ thật sự sai - hoặc tệ hơn, gắn cờ một lượt chạy đúng là hỏng chỉ vì nó không khớp kịch bản grader kỳ vọng.
Từ Định Nghĩa Task Tới Một Tỷ Lệ Pass Tổng Hợp
Vì Sao Chấm Điểm Agent Nghĩa Là Chấm Một Chuỗi, Không Phải Một Câu Trả Lời
Một eval đơn lượt chỉ có một thứ để kiểm tra: output. Một eval agent phải kiểm tra cả transcript - mọi tool call, mọi quyết định trung gian - và quan trọng không kém, trạng thái thật sự agent để lại trong thế giới thật sau khi nó dừng lại. Một hệ thống đặt chỗ, một file, một dòng trong database, một email đã hoặc chưa được gửi: trạng thái đó là thứ gần nhất với ground truth mà một eval agent có, và một grader chỉ đọc câu trả lời cuối của agent đang chấm nội dung quảng cáo, không phải chấm công việc thật.
"Outcome" Thực Chất Nghĩa Là Gì: Trạng Thái Để Lại, Không Phải Transcript
Chấm theo outcome nghĩa là kiểm tra trạng thái bên ngoài thật sự mà task được yêu cầu thay đổi, không phải câu chữ agent dùng để mô tả nó đã làm gì. Một task như "đặt phòng" có một outcome sạch, kiểm tra được: query thẳng hệ thống lịch và xem có booking khớp tồn tại hay không. Ở bất cứ đâu task tạo ra loại tác dụng phụ kiểm tra được như vậy, một code-based outcome check là grader mạnh nhất có thể có - rẻ, tất định, và miễn nhiễm với một agent nói hay nhưng thực ra chưa làm việc gì. Không phải task nào cũng có trạng thái sạch như vậy; "giải thích rõ chính sách hoàn tiền" vẫn cần lớp LLM-as-judge hay người từ các bài trước trong pillar này. Kiểm tra theo trạng thái kết quả không thay thế những lớp đó - nó thêm một lớp ground-truth cho những task có sẵn trạng thái để kiểm.
Vì Sao Grader Không Nên Đòi Hỏi Một Chuỗi Bước Cố Định Duy Nhất
Agent thường xuyên giải cùng một task qua những thứ tự tool khác nhau nhưng đều hợp lệ - kiểm tra tồn kho trước khi xác nhận giá, hoặc ngược lại; đọc bản ghi hiện có trước khi ghi, hoặc ghi rồi đối chiếu sau. Một grader đòi hỏi đúng một chuỗi cố định sẽ phạt một lượt chạy đúng chỉ vì nó đi đường khác, và một team thấy con số eval của mình dao động theo những thay đổi đường đi chẳng liên quan gì tới chất lượng thật sẽ dần không còn tin vào eval nữa. Cách sửa không phải là bỏ hết cấu trúc - mà là kiểm tra trạng thái kết quả như tín hiệu chính, rồi xếp thêm một tập nhỏ assertion cứng dạng "tuyệt đối không được xảy ra" (không bao giờ gọi hành động xoá, không bao giờ bỏ qua bước xác nhận bắt buộc) thay vì ghim chết toàn bộ đường đi.
Cùng Một Task, Ba Cách Chấm Điểm Khác Nhau
Hành vi của agent không đổi qua ba cột này - thứ thay đổi là grader có phân biệt được lỗi thật với lỗi giả hay không.
Đặt phòng họp 2 giờ chiều cho buổi review thiết kế.
Kiểm tra lịch phòng trước, rồi mới xác nhận người tham dự rảnh - ngược thứ tự kịch bản grader kỳ vọng.
So chuỗi tool-call với một kịch bản viết cứng, gắn cờ bước 1/2 là sai thứ tự.
Phòng thực sự đã được đặt và cuộc họp đúng yêu cầu. Grader đánh fail một lượt chạy đúng chỉ vì nó đi đường khác nhưng vẫn hợp lệ.
Không cái nào trong số này trông như một grader hỏng rõ ràng - chúng hiện ra như những con số eval không ai thực sự tin.
Tính Không Tất Định: Vì Sao Một Trial Không Bao Giờ Đủ
Cùng một agent, cùng một input, có thể thành công ở lượt chạy này và fail ở lượt kế tiếp - biến thiên do sampling, thời điểm gọi tool, một lần retry giải quyết khác đi. Một trial duy nhất cho mỗi task tạo ra một con số trông có vẻ chính xác nhưng thực chất là nhiễu khoác áo kết quả. Chạy nhiều trial và báo cáo pass@k (agent được tính điểm nếu ít nhất một trong k trial thành công) đo trần năng lực - agent làm được gì khi gặp may. Báo cáo tỷ lệ nhất quán (agent phải thành công ở cả k trial) đo thứ thật sự có thể ship - agent làm được gì một cách đáng tin, mọi lần. Hai con số này trả lời hai câu hỏi khác nhau, và chọn nhầm cái nào sẽ tạo cảm giác an toàn giả: một task có pass@5 cao nhưng tỷ lệ nhất quán thấp trông như đã giải xong cho tới khi ship và fail một phần ba số lần ngoài production.
Cùng Một Tỷ Lệ Thành Công 80%, Hai Con Số Rất Khác Nhau
Kịch bản mẫu: cùng một task, cùng một agent, tỷ lệ thành công độc lập mỗi lượt là 80%, đo ở k = 1, 3 và 5 lượt thử.
Với 1 lượt thử duy nhất, pass@k và consistency rate là cùng một con số - một lượt chạy không phân biệt được may mắn với độ tin cậy.
pass@3 đã trông rất mạnh. Consistency@3 mới là chỗ tỷ lệ 80%/lượt bắt đầu lộ ra cái giá thật.
pass@5 làm tròn thành một con số gần như hoàn hảo. Consistency@5 mới là con số dự đoán đúng trải nghiệm người dùng thật.
Ngân Sách Eval Thực Sự Đổ Vào Đâu
Phần lớn team lập ngân sách cho bước chấm điểm rồi quên rằng việc chạy chính agent, nhiều lần cho mỗi task, trên toàn bộ task trong bộ eval, thường mới là dòng chi phí lớn nhất - mỗi trial là một lượt chạy agent đầy đủ nhiều bước, nhiều lệnh gọi, không phải một lệnh gọi model rẻ tiền. Chỉ lập ngân sách cho judge hay lớp review người mà bỏ qua chi phí compute của các trial tạo ra transcript ngay từ đầu là cách một ngân sách eval vượt dự tính cả chục lần.
Nếu Một Agent Frontier Fail Gần Như Mọi Trial, Hãy Nhìn Task Trước
Một task được đặc tả tốt mà một người có năng lực làm được hiếm khi khiến một agent frontier fail ở tất cả các trial. Khi điều đó xảy ra, task hoặc grader mới là nghi phạm nhiều khả năng hơn, không phải năng lực gốc của agent. Kiểm tra ba thứ trước khi đổ lỗi cho agent: mô tả task có mơ hồ, hay giả định một thông tin agent không có cách nào lấy được; grader có lỗi, như kiểm tra sai field hay sai trạng thái cuối; hay chính tool hoặc môi trường đang hỏng, trả về dữ liệu cũ hoặc sai định dạng mà không agent nào xử lý nổi. Tỷ lệ fail gần 100% là tín hiệu để audit lại eval, không phải một phán quyết về agent.
Bão Hoà Bộ Eval: Khi Benchmark Không Còn Phân Biệt Được
Một bộ eval bão hoà khi phần lớn các agent được so sánh đều đạt điểm sát trần - hoặc sát đáy - và các con số không còn phân biệt được một agent thật sự tốt hơn với một agent kém hơn. Dấu hiệu là chênh lệch điểm giữa các phiên bản model co lại về mức nhiễu, trong khi chất lượng thực tế rõ ràng vẫn khác nhau giữa chúng; team vẫn báo cáo cùng một benchmark qua từng bản release dù nó đã ngừng dịch chuyển theo cách có ý nghĩa từ nhiều tháng trước. Cách sửa lặp lại đúng kỷ luật từ error analysis: cho nghỉ hưu hoặc tăng độ khó của những task đã bão hoà, và thêm task mới lấy từ chính lỗi thật ngoài production thay vì tiếp tục chạy một bộ cũ chỉ vì nó đã có sẵn.
Cạm Bẫy Thường Gặp Khi Làm Agent Evals
Một vài kiểu lỗi lặp lại trong các setup eval agent. Chấm theo câu chữ của transcript thay vì trạng thái kết quả để một thành công ảo giác lọt qua như thật. Đòi hỏi một đường đi cố định duy nhất phạt những câu trả lời đúng chỉ vì chúng đi đường khác, và bào mòn niềm tin vào con số eval. Tin vào một trial duy nhất biến nhiễu thành tín hiệu và che giấu đúng kiểu bất ổn định sẽ ship ra production. Để chi phí compute của agent phình to mà không ai để ý xảy ra khi không ai lập ngân sách cho phép nhân trial với task. Và chạy đi chạy lại cùng một bộ eval đã bão hoà cho ra một con số trông ổn định nhưng chẳng nói lên điều gì thật về việc agent có thật sự tốt lên hay không.
Ghép cùng error analysis, code-based eval, LLM-as-judge, và human evaluation, agent evals hoàn thiện năm mảnh ghép của một hệ thống eval - lớp duy nhất phải chấm cả một chuỗi quyết định và trạng thái chúng để lại, thay vì một câu trả lời đơn lẻ, dễ kiểm tra.