Đừng chỉ mải mê chạy các bài benchmark mô hình mới, hãy bắt đầu quan sát agent của bạn khi nó cố gắng hủy một gói đăng ký. Khoảng cách giữa hai hoạt động đó chính là nơi các hệ thống production sụp đổ. Một bài kiểm tra đơn bước (single-turn test) có thể cho bạn biết liệu một câu trả lời nghe có vẻ dễ chịu hay không. Nhưng nó không thể cho bạn biết liệu agent vừa hoàn tiền nhầm cho khách hàng, lặp lại vô hạn mười bốn lần đối với một API lịch, hay quyết định bỏ qua bước kiểm tra gian lận. Văn bản là thứ ít nguy hiểm nhất mà một agent tạo ra. Những rủi ro thực sự ẩn giấu trong các công cụ mà nó chạm tới, dữ liệu mà nó làm thay đổi, và những khoảnh khắc lẽ ra nó phải yêu cầu trợ giúp nhưng lại tiếp tục tự làm.

Tại sao các bài Benchmark văn bản thất bại trong môi trường Production

Điểm số cao trên các bài benchmark tiêu chuẩn đã trở thành một sự an tâm giả tạo. Một agent có thể viết văn phong mượt mà nhưng vẫn có thể là một mối nguy hiểm về mặt vận hành. Khi hệ thống của bạn đặt lịch hẹn, chỉnh sửa bản ghi cơ sở dữ liệu hoặc gửi phiếu hỗ trợ, văn bản được tạo ra chỉ là bề mặt hiển thị của quy trình làm việc. Bên dưới bề mặt đó, agent đang đưa ra các quyết định cụ thể về việc gọi endpoint nào, gửi payload gì và khi nào nên dừng lại. Nó có thể đứng đầu bảng xếp hạng về khả năng đọc hiểu nhưng lại khiến bạn tốn tiền do đặt trùng lịch, làm sai lệch hàng dữ liệu, hoặc làm rò rỉ trạng thái nhạy cảm vào tệp log. Bạn cần xác minh cơ chế thực hiện công việc, chứ không chỉ là sự trau chuốt của đầu ra. Nếu một agent có thể đạt điểm cao trong một bài kiểm tra QA ngoại tuyến nhưng vẫn làm hỏng quy trình làm việc của bạn do lặp vô hạn hoặc sử dụng sai công cụ, thì việc đánh giá của bạn đang nhìn vào những tín hiệu sai lệch.

Lập bản đồ năm yếu tố phụ thuộc

Đội ngũ tại Van Data Team bắt đầu mọi quy trình đánh giá bằng cách lập bản đồ năm điểm kiểm soát cụ thể. Điều này thay đổi hoàn toàn câu hỏi đặt ra. Bạn ngừng hỏi liệu mô hình này có thông minh hơn mô hình kia không. Bạn bắt đầu hỏi liệu agent có thực sự hoàn thành được một tác vụ production dưới các ràng buộc thực tế của bạn hay không.

Kết quả kinh doanh. Xác định thế nào là "hoàn thành" dựa trên giá trị tiền tệ và tác động đến khách hàng. Một tác vụ không được coi là hoàn thành chỉ vì agent đã đưa ra một bản tóm tắt. Nó chỉ hoàn thành khi bản ghi kho hàng chính xác, lịch hẹn đã được xác nhận và khách hàng đã nhận được mã theo dõi hợp lệ.

Trạng thái có thể thay đổi (Mutable state). Biết chính xác những gì agent được phép thay đổi. Những bảng nào, trạng thái nào, các cờ (flags) tài khoản nào? Nếu agent có thể thực hiện hoàn tiền, thay đổi lịch làm việc hoặc cập nhật địa chỉ thanh toán, bạn cần kiểm kê mọi trường dữ liệu mà nó chạm tới.

Quyền hạn của công cụ. Hãy nêu rõ các endpoint API và các hàm nào nằm trong phạm vi cho phép. Một agent có quyền truy cập vào công cụ tìm kiếm, công cụ ghi và công cụ thông báo sẽ làm xáo trộn chúng nếu các ranh giới không rõ ràng. Hãy ánh xạ mỗi quyền hạn với một nhu cầu vận hành cụ thể.

Khôi phục sau lỗi. Quyết định điều gì sẽ xảy ra khi API lịch bị hết thời gian chờ (timeout), trả về lỗi 500, hoặc trả về JSON không đúng định dạng. Agent không được phép hoảng loạn, tự bịa ra thông báo thành công hoặc thử lại mãi mãi. Nó cần một lộ trình dự phòng (fallback path) rõ ràng.

Các chốt kiểm duyệt của con người. Xác định những thời điểm mà một người phải phê duyệt trước khi agent tiếp tục thực hiện. Đây không phải là dấu hiệu của sự yếu kém trong tự động hóa. Đó là một van an toàn cho các thay đổi có tác động lớn và là nguồn cung cấp nhãn dữ liệu chuẩn (ground-truth labels) cho các tiêu chí đánh giá của bạn.

Một kế hoạch đánh giá thực thụ trông như thế nào

Sau khi các yếu tố phụ thuộc đã được lập bản đồ, bạn cần một kế hoạch đánh giá tương xứng với sự phức tạp của môi trường production. Các chỉ số trình bày trên slide thuyết trình sẽ không giúp ích gì cho bạn ở đây.

Xây dựng các bộ kiểm thử từ những lỗi thực tế trong production, thay vì từ các ngân hàng câu hỏi tổng hợp. Nếu agent của bạn đã thất bại vào thứ Ba tuần trước do nhầm lẫn giữa hai mã SKU tương tự nhau, thì chính sự nhầm lẫn đó phải trở thành một trường hợp kiểm thử vĩnh viễn. Bộ công cụ đánh giá của bạn nên lớn dần lên mỗi khi một sự cố dạy cho bạn một điều gì đó mới.

Viết các tiêu chí đánh giá (rubrics) định nghĩa sự hoàn thành thành công theo các thuật ngữ vận hành. Các tiêu chí mơ hồ như "hữu ích" hoặc "chính xác" là vô dụng. Một tiêu chí hữu ích sẽ quy định rằng một tác vụ hoàn tiền chỉ thành công nếu ID thanh toán gốc được tham chiếu, số tiền khớp với yêu cầu, một email xác nhận đã được đưa vào hàng đợi và ID giao dịch đã được ghi lại.

Xác định thông số truy vết (trace specs) cho các lệnh gọi công cụ và việc thử lại (retries). Bạn cần khả năng quan sát (observability) vào những gì agent đã lập kế hoạch, những gì nó thực sự đã gọi, số lần nó thử lại và liệu chiến lược thử lại đó có phù hợp hay không. Một bản truy vết mà không có độ chi tiết ở cấp độ công cụ thì cũng chỉ là một câu chuyện hay mà thôi.

Thiết lập các chính sách về khi nào cần cảnh báo cho con người. Agent nên biết các ranh giới của chính nó. Nếu một yêu cầu vượt quá ngưỡng tiền tệ, tham chiếu đến một tài khoản VIP hoặc gặp phải một trạng thái mà nó chưa từng thấy trước đây, nó nên báo cáo lên cấp trên thay vì tự đoán.

Cài đặt các cổng phát hành (release gates) để ngăn chặn các bản nâng cấp mô hình kém chất lượng. Một mô hình mới chỉ được coi là bản nâng cấp nếu nó cải thiện các kết quả cụ thể của bạn. Nếu nó gặp hiện tượng ảo giác (hallucinate) các tham số công cụ thường xuyên hơn, làm tăng độ trễ, hoặc tạo ra các rủi ro an toàn mới, nó sẽ không được triển khai. Cổng này giúp duy trì sự ổn định cho môi trường production ngay cả khi nhà cung cấp mô hình nền tảng phát hành một phiên bản mới.

Đánh giá trong thời gian chạy (Runtime Grading): Theo dõi Agent làm việc

Anthropic đang thúc đẩy ngành công nghiệp chuyển dịch từ các bài kiểm tra ngoại tuyến (offline tests) sang đánh giá trong thời gian chạy (runtime grading). Thay vì đánh giá một bản ghi chép sau khi sự việc đã rồi, runtime grading cho phép hệ thống đánh giá công việc của agent ngay khi tác vụ vẫn đang được thực hiện. Điều này tạo cơ hội để phát hiện lỗi trước khi chúng trở thành những vấn đề thực sự nghiêm trọng.

Việc thêm một bộ đánh giá (grader) sẽ tiêu tốn token và làm tăng độ trễ. Bạn không thể đánh giá mọi bước nhỏ nhặt. Vị trí của mỗi grader là một quyết định thiết kế. Hãy đặt chúng ở những nơi mà sai lầm sẽ gây tốn kém. Các điểm kiểm soát (checkpoints) giá trị nhất nằm ngay trước khi thực hiện thay đổi trạng thái vào cơ sở dữ liệu, ngay trước khi thực hiện thanh toán, và ngay trước khi gửi tin nhắn cho khách hàng. Đây là những thời điểm mà một quyết định sai lầm sẽ trở thành một hành động không thể đảo ngược.

Hãy cẩn thận với một điểm mù cụ thể. Nếu cùng một mô hình vừa thực hiện công việc vừa đánh giá công việc đó, nó có thể bỏ lỡ chính những lỗi mà nó đã mắc phải. Lập luận tạo ra lỗi có thể dễ dàng tự hợp lý hóa lỗi đó trong quá trình xem xét. Đối với các tác vụ có tác động lớn, hãy duy trì sự tham gia của con người (human-in-the-loop). Hãy để con người xác thực phán đoán của chính grader, đặc biệt là khi tiền bạc hoặc lòng tin của khách hàng đang bị đe dọa.

Mục tiêu ở đây là kiểm soát vận hành. Hãy kết nối dữ liệu sự cố, các tiêu chí đánh giá (rubrics) tác vụ và các vết truy vết thời gian chạy (runtime traces) của bạn thành một chu trình phản hồi duy nhất. Hãy đánh giá toàn bộ lộ trình: kế hoạch, việc sử dụng công cụ, hành vi phục hồi và kết quả cuối cùng. Sử dụng các bài kiểm tra ngoại tuyến để bắt các lỗi đã biết và có thể tái lập trước khi phát hành. Sử dụng runtime traces để tìm ra các lỗi mới mà bạn không lường trước được. Sử dụng sự xem xét của con người để phát hiện ra những điểm mà tiêu chí đánh giá của bạn còn quá đơn giản và cần được thắt chặt.

Vì vậy, hãy tự hỏi: bạn sẽ đặt một runtime grader ở đâu trong quy trình làm việc của mình? Trước một lệnh gọi công cụ (tool call), sau một lệnh gọi công cụ, hay chỉ trước một thay đổi rủi ro? Hầu hết các nhóm đều bắt đầu quá rộng, đánh giá mọi thứ, và sau đó bị đình trệ do chi phí. Hãy bắt đầu một cách hẹp. Chọn một hành động duy nhất mà nếu nó sai sót sẽ gây thiệt hại lớn nhất. Hãy đặt một grader ở đó trước tiên.

Bắt đầu với một sai lầm đắt giá

Đánh giá vận hành không phải là một bài tập nghiên cứu. Đó là cách để bạn có thể ngủ ngon hơn sau khi agent đi vào hoạt động. Bạn không cần một khung làm việc hoàn hảo ngay từ ngày đầu tiên. Bạn cần một quy trình làm việc duy nhất, được xác định rõ ràng, một bộ tiêu chí được viết bằng các thuật ngữ kinh doanh bình dị, và một grader được đặt chính xác vào thời điểm mà một lỗi trở nên đắt giá. Làm đúng điều đó, và bạn sẽ có một nền tảng mà bạn thực sự có thể tin tưởng.

Nếu bạn muốn tìm hiểu sâu hơn về đánh giá agent và runtime grading cùng với cộng đồng những người thực hành, bạn có thể tìm thấy cộng đồng học tập GyaanSetu tại https://t.me/GyaanSetuAi.