Đánh giá AI Agent: đo kết quả thật trước khi đổi model

TL;DR: Đánh giá AI Agent cần kiểm tra trạng thái cuối của công việc, những hành động nó đã thực hiện và các giới hạn không được vượt qua. Một bộ kiểm tra ổn định giúp quyết định đổi model dựa trên bằng chứng thay vì vài câu trả lời gây ấn tượng.

Một Agent có thể viết “đã hoàn tất” rất thuyết phục trong khi kết quả chưa tồn tại ở nơi cần có. Với SME, sự khác biệt ấy có thể là một file chưa được lưu, một yêu cầu chưa tới người phụ trách hoặc một bản nháp chưa đạt tiêu chuẩn. Tôi coi đây là điểm bắt đầu của đánh giá AI Agent: doanh nghiệp phải định nghĩa “xong” bằng công việc của mình. Bài khi nào AI Workflow cần người giám sát bàn về trách nhiệm khi hệ thống chạy; bài này bổ sung cách kiểm chứng trước khi đưa một thay đổi vào vận hành.

Đánh giá AI Agent khác chấm câu trả lời thế nào?

Đánh giá Agent phải kiểm tra kết quả trong môi trường và hành động dẫn tới kết quả đó. Chấm văn bản trả lời chỉ bao phủ một phần của tác vụ.

Trong bài Demystifying evals for AI agents, Anthropic phân biệt transcript của lần chạy với outcome, tức trạng thái cuối trong môi trường. Tôi dùng sự phân biệt này để đặt hai câu hỏi: hệ thống nói đã làm gì và bằng chứng nào cho thấy việc đó xảy ra?

Ví dụ gần với kho nội dung: file tồn tại là điều kiện kỹ thuật; file có ngày hợp lệ, ảnh tồn tại và nội dung đạt tiêu chí mới là điều kiện nghiệm thu. Không cần một thang điểm phức tạp để thấy sự khác biệt đó.

Một tác vụ cũng có thể tạo ra kết quả đúng bằng hành động không được phép. Vì vậy, bộ kiểm tra cần bao gồm ranh giới quyền: không gửi tin ra ngoài khi mới được giao soạn nháp, không sửa phần khác chỉ để một kiểm tra dễ vượt qua.

Chọn tình huống và tiêu chí đạt như thế nào?

Chọn tình huống từ công việc có thật và các ngoại lệ đã được ghi nhận. Với mỗi tình huống, xác định kết quả mong đợi và điều kiện buộc thất bại trước khi chạy Agent.

Tôi đề xuất bắt đầu với một workflow, thay vì cố chấm toàn bộ hệ thống bằng một điểm tổng. Một bộ kiểm tra cho xử lý nội dung cần khác một bộ kiểm tra cho điều phối yêu cầu hỗ trợ.

Nếu dữ liệu không đủ để đưa ra quyết định, hành vi đúng có thể là yêu cầu làm rõ. Đừng biến “trả lời mọi câu hỏi” thành tiêu chí thành công khi doanh nghiệp thực sự cần một ranh giới chắc chắn.

Bộ dùng để sửa prompt cần được tách khỏi bộ dùng để nghiệm thu thay đổi. Nếu liên tục chỉnh theo đúng những tình huống sẽ dùng để báo cáo, kết quả đẹp hơn có thể chỉ phản ánh việc học thuộc bài kiểm tra.

Đo lỗi, độ trễ và chi phí trên cùng cơ sở ra sao?

Giữ tập tác vụ, quyền công cụ và cách chấm ổn định giữa các cấu hình. Ghi từng lần chạy, gồm cả retry và kết quả bị loại, để không mất mẫu số.

Tôi sẽ lưu phiên bản model, prompt, công cụ và dữ liệu cùng một mã chạy. Nếu nhiều yếu tố thay đổi cùng lúc, kết quả vẫn có thể hữu ích nhưng chưa đủ để quy lợi ích riêng cho việc đổi model.

Một bản ghi đơn giản có thể dùng cấu trúc:

Mã tác vụ | phiên bản cấu hình | kết quả nghiệm thu
Lỗi buộc dừng | thời gian hoàn tất | số lần thử
Chi phí ghi nhận | công sửa | liên kết bằng chứng

Không phải mọi tiêu chí đều nên giao cho một model khác chấm. Sự tồn tại của file hoặc giá trị bắt buộc có thể kiểm tra bằng quy tắc xác định. Sự phù hợp của lập luận cần người có chuyên môn đọc. Nếu dùng model chấm chất lượng, phải kiểm tra nó có đồng ý với người nghiệm thu trên các tình huống thực tế không.

Tôi cũng sẽ giữ riêng những lỗi nghiêm trọng. Một điểm trung bình cao không bù được một hành động vượt quyền hay một kết quả nghiệp vụ không thể phục hồi.

Khi nào đủ bằng chứng để đưa thay đổi vào vận hành?

Đủ bằng chứng khi thay đổi đạt tiêu chí đã thống nhất, không làm hỏng tác vụ cũ cần giữ và có phương án quay lại. Phạm vi kết luận phải khớp phạm vi được kiểm tra.

Nếu mới đo một loại bản nháp, hãy kết luận về loại bản nháp đó. Không chuyển nó thành khẳng định model phù hợp mọi công việc của doanh nghiệp. Nếu chưa ghi công sửa, cũng chưa nên tuyên bố tổng chi phí giảm.

Trước khi mở rộng, tôi sẽ cho thay đổi chạy trong phạm vi có thể quan sát và đảo ngược. Người nghiệm thu cần biết đang dùng cấu hình nào, đầu ra nào cần kiểm tra và dấu hiệu nào buộc chuyển về phương án cũ.

Đánh giá không kết thúc sau lần triển khai đầu tiên. Những ngoại lệ mới có thể trở thành tình huống kiểm tra cho lần thay đổi tiếp theo, miễn là được lưu với bối cảnh và tiêu chí rõ ràng.

Kết luận

Tôi không xem bộ kiểm tra như thủ tục để chứng minh Agent thông minh. Nó là cách doanh nghiệp nói rõ công việc nào cần hoàn tất, bằng chứng nào cần giữ và quyền nào không được vượt qua.

Nếu đội ngũ chưa thống nhất được tiêu chí “xong”, hãy quay về audit hệ thống AI theo bài toán nghiệp vụ. Đổi model sẽ có ý nghĩa hơn khi doanh nghiệp đã biết chính xác mình muốn giữ điều gì.