Làm thế nào để đánh giá một tác tử AI? Nhiệm vụ, tiến trình thực hiện, độ tin cậy và chi phí

Đánh giá một tác tử AI là kiểm tra xem tác tử đó có hoàn thành đáng tin cậy các nhiệm vụ tiêu biểu, tuân theo những quy trình phù hợp, tôn trọng các giới hạn của mình và mang lại giá trị tương xứng với chi phí hay không. Chỉ xem xét câu trả lời cuối cùng là chưa đủ, vì tác tử có thể đạt được kết quả có vẻ hợp lý bằng những hành động không an toàn, các khẳng định thiếu căn cứ, việc thử lại quá nhiều lần hoặc chỉ nhờ may mắn.

Việc đánh giá tác tử khó khăn vì hệ thống hành động theo thời gian. Mô hình lựa chọn công cụ, quan sát các môi trường luôn thay đổi và có thể đi theo lộ trình khác nhau ở mỗi lần chạy. Vì vậy, các bài đánh giá hiệu quả đo lường kết quả và tiến trình thực hiện qua nhiều lần thử.

Thuật ngữ trong đánh giá tác tử

Hướng dẫn của Anthropic về việc làm sáng tỏ công tác đánh giá tác tử cung cấp một số thuật ngữ hữu ích:

• Nhiệm vụ: một trường hợp kiểm thử gồm mục tiêu, môi trường, dữ liệu đầu vào và tiêu chí thành công.
• Lần thử: một lần tác tử cố gắng hoàn thành nhiệm vụ.
• Bản ghi hội thoại hoặc tiến trình thực hiện: chuỗi thông điệp, quyết định, lệnh gọi công cụ, quan sát và hành động trong lần thử.
• Bộ chấm điểm: quy tắc, chương trình, mô hình hoặc người đánh giá một phần hiệu suất.
• Bộ khung đánh giá: hệ thống chuẩn bị môi trường, chạy các lần thử, thu thập dấu vết, gọi bộ chấm điểm và báo cáo kết quả.

Tách biệt các khái niệm này giúp tránh một sai lầm thường gặp: xem một lần trình diễn thành công là bằng chứng cho thấy tác tử sẽ hoạt động đáng tin cậy.

Bắt đầu bằng đặc tả nhiệm vụ rõ ràng

Một nhiệm vụ đánh giá hữu ích mô tả trạng thái ban đầu, các công cụ sẵn có, những ràng buộc, kết quả mong đợi và các hành vi quan trọng bị cấm. Bài kiểm thử nên mô phỏng công việc thực tế mà không tiết lộ một lộ trình được viết sẵn duy nhất.

Với một tác tử hỗ trợ, yêu cầu “giải quyết phiếu hỗ trợ” quá mơ hồ. Một nhiệm vụ được mô tả chặt chẽ hơn sẽ nêu rõ hồ sơ khách hàng, chính sách áp dụng, biện pháp xử lý được phép, nội dung trao đổi bắt buộc và những thay đổi phải được ghi nhận trong hệ thống lưu trữ dữ liệu chính thức. Khi đó, nhiệm vụ có thể được chấm điểm một cách khách quan.

Bốn lớp đánh giá tác tử

Khi báo cáo, cần giữ riêng các lớp này. Gộp chúng thành một điểm trung bình có thể che khuất những hành vi không thể chấp nhận được — chẳng hạn, điểm hoàn thành nhiệm vụ cao nhưng lại che giấu việc thường xuyên cố gọi các công cụ trái phép. Trước tiên, các nhóm có thể đặt ra những điều kiện an toàn bắt buộc; sau đó, họ so sánh chất lượng kết quả và hiệu quả giữa các lần chạy đáp ứng những điều kiện đó.

1. Chất lượng kết quả

Tác tử có đạt được mục tiêu không? Bộ chấm điểm kết quả có thể kiểm tra các thay đổi trạng thái chính xác, những trường bắt buộc, kết quả kiểm thử, độ chính xác của thông tin, căn cứ hỗ trợ trích dẫn hoặc chất lượng dựa trên thang tiêu chí.

Khi có thể, hãy dựa vào trạng thái cuối cùng của môi trường thay vì lời tự khẳng định của tác tử. Tác tử lập trình không thể được xem là đã thành công chỉ vì nó nói rằng lỗi đã được sửa; các bài kiểm thử liên quan và hành vi thực tế phải xác nhận điều đó.

2. Chất lượng tiến trình thực hiện

Tác tử có đi theo một lộ trình hợp lý không? Việc đánh giá tiến trình thực hiện có thể phát hiện hành vi truy cập dữ liệu không cần thiết, sử dụng công cụ bị cấm, thất bại lặp đi lặp lại, bỏ qua bước xác minh, bịa đặt quan sát hoặc vi phạm yêu cầu phê duyệt.

Không phải mọi sai khác so với lộ trình tham chiếu đều là lỗi. Tác tử có thể tìm ra những giải pháp hợp lệ mà người đánh giá chưa dự liệu. Bộ chấm điểm nên thực thi các yêu cầu thực sự, đồng thời cho phép những cách tiếp cận khác hiệu quả tương đương.

3. An toàn và tuân thủ chính sách

Tác tử có hoạt động trong phạm vi thẩm quyền của mình không? Bài kiểm thử nên bao gồm các cuộc tấn công chèn câu lệnh, chỉ dẫn mâu thuẫn, dữ liệu nhạy cảm, ý định người dùng không rõ ràng và những yêu cầu cần bị từ chối hoặc chuyển cấp xử lý.

Các bài đánh giá an toàn cần mô phỏng những hậu quả thực tế trong môi trường thử nghiệm biệt lập. Một câu trả lời tuân thủ chính sách là chưa đủ nếu tác tử đã gửi thông điệp, thay đổi hồ sơ hoặc làm lộ dữ liệu.

4. Hiệu quả vận hành

Để đạt được thành công cần bao nhiêu thời gian và tiền bạc? Hãy theo dõi số token mô hình, số lần gọi công cụ, độ trễ thực tế, số lần thử lại, số lần con người can thiệp và chi phí dịch vụ bên ngoài. Một tác tử chỉ thành công sau 100 hành động không cần thiết có thể kém hữu ích hơn một quy trình đơn giản hơn.

Sử dụng nhiều loại bộ chấm điểm

Các bộ đánh giá tất định kiểm tra những thuộc tính chính xác: liệu một bài kiểm thử có đạt hay không, tệp có được thay đổi đúng cách hay không, trường dữ liệu trong cơ sở dữ liệu có giá trị bắt buộc hay không, hoặc một điểm cuối bị cấm có bị gọi hay không. Chúng hoạt động nhanh và nhất quán, nhưng chỉ bao quát những gì nhà phát triển đưa vào mã.

Các bộ đánh giá dựa trên mô hình đánh giá những yếu tố như độ rõ ràng, tính đầy đủ, mức độ liên quan và sự tuân thủ các tiêu chí tinh tế. Chúng có thể mở rộng quy mô tốt hơn so với đánh giá của con người, nhưng cần được kiểm định riêng vì có thể thiên lệch hoặc thiếu nhất quán.

Người đánh giá đóng vai trò quan trọng trong việc đưa ra nhận định chuyên môn, xử lý các trường hợp mơ hồ và kiểm định các bộ đánh giá tự động. Vì quá trình này chậm hơn và tốn kém hơn, các nhóm thường chỉ áp dụng cho một số mẫu, các trường hợp bất đồng và những lĩnh vực có tác động lớn.

Các bộ đánh giá hiệu quả nhất kết hợp những phương pháp này. Tương tự, nền tảng Evals của OpenAI xem việc đánh giá là một quy trình có cấu trúc để xác định các bài kiểm thử, bộ đánh giá và thí nghiệm lặp lại, thay vì chỉ kiểm tra không chính thức.

Độ tin cậy cần được kiểm tra qua nhiều lần thử

Chạy mỗi tác vụ đủ số lần để quan sát mức độ biến thiên do lấy mẫu, thay đổi công cụ và trạng thái môi trường. Báo cáo cả hiệu suất trung bình lẫn tần suất xảy ra lỗi nghiêm trọng. Với các quy trình gồm nhiều bước phụ thuộc lẫn nhau, độ chính xác ở từng bước có thể trông cao, trong khi độ tin cậy từ đầu đến cuối vẫn thấp, bởi chỉ một lỗi cũng đủ làm hỏng toàn bộ tác vụ.

Hành vi của tác tử mang tính xác suất. Cùng một tác vụ có thể tạo ra những kế hoạch, lần gọi công cụ và kết quả khác nhau. Hãy chạy mỗi tác vụ quan trọng nhiều lần và báo cáo tỷ lệ đạt hoặc phân bố điểm số, chứ không chỉ nêu ví dụ tốt nhất.

Hai thước đo độ tin cậy trả lời những câu hỏi khác nhau:

• Pass@k: xác suất có ít nhất một trong k lần thử thành công. Chỉ số này hữu ích khi có thể chấp nhận thử nhiều lần.
• Pass^k: xác suất cả k lần thử đều thành công. Chỉ số này phản ánh tính nhất quán khi mọi lần chạy đều phải đạt yêu cầu.

Một hệ thống có thể đạt pass@k hấp dẫn nhưng vẫn không phù hợp để vận hành tự động vì từng lần chạy riêng lẻ không đáng tin cậy.

Xây dựng bộ tác vụ đại diện

Bắt đầu với những lỗi thực tế và các yêu cầu phổ biến trong môi trường vận hành. Đưa vào các tác vụ đơn giản, tình huống biên khó, đầu vào mơ hồ, lỗi công cụ, dữ liệu lỗi thời, thông tin thiếu và nội dung đối kháng.

Phân nhóm kết quả theo loại tác vụ và mức độ rủi ro. Điểm trung bình tổng thể có thể che giấu điểm yếu nghiêm trọng trong các thao tác tài chính, tác vụ kéo dài hoặc một ứng dụng cụ thể. Giữ lại một tập dữ liệu chưa dùng để đánh giá, nhằm tránh việc tinh chỉnh câu lệnh lặp đi lặp lại biến bộ đánh giá thành tập huấn luyện.

Đánh giá môi trường, không chỉ riêng mô hình

Hiệu suất của một tác tử phụ thuộc vào định nghĩa công cụ, quyền truy cập, bộ nhớ, cách quản lý ngữ cảnh, giao diện người dùng, hoạt động mạng và cơ chế điều phối. Nâng cấp mô hình có thể giảm một loại lỗi nhưng lại làm lộ ra lỗi khác.

Ghi lại phiên bản của toàn bộ ngăn xếp được sử dụng trong mỗi lần chạy. Lưu lại mô hình, câu lệnh, công cụ, ảnh chụp dữ liệu, môi trường, ngân sách và phiên bản bộ đánh giá. Nếu không, sẽ không thể xác định thay đổi điểm số bắt nguồn từ nguyên nhân thực sự nào.

Những lỗi đánh giá thường gặp

Rò rỉ dữ liệu cũng là một rủi ro. Nếu các tác vụ chuẩn đối sánh, câu trả lời dự kiến hoặc mẫu chấm điểm xuất hiện trong dữ liệu huấn luyện hay ngữ cảnh lời nhắc của mô hình, điểm số có thể phản ánh khả năng nhận diện thay vì khả năng khái quát hóa. Hãy duy trì các tác vụ kiểm thử kín, cập nhật tình huống khi hệ thống thay đổi, đồng thời ghi lại chính xác mô hình, lời nhắc, phiên bản công cụ và môi trường được sử dụng trong mỗi lần chạy.

• Đánh giá dựa trên bản trình diễn: chọn tác vụ sau khi đã thấy tác tử làm tốt những gì.
• Chỉ chấm điểm câu trả lời cuối cùng: bỏ qua các quỹ đạo thực hiện không an toàn hoặc lãng phí.
• Kết luận từ một lần chạy: xem một lần thành công nhờ may mắn là năng lực ổn định.
• Bài kiểm thử bị lộ: đưa câu trả lời hoặc quỹ đạo tham chiếu vào ngữ cảnh của tác tử.
• Bộ chấm điểm bằng mô hình chưa được kiểm định: mặc định rằng hệ thống đánh giá tự động là chính xác mà không kiểm tra mức độ đồng thuận với chuyên gia.
• Môi trường tĩnh: chỉ kiểm thử một giao diện, trạng thái tài khoản hoặc cách sắp xếp dữ liệu.
• Không có kiểm thử tình huống tiêu cực: đo lường mức độ hoàn thành tác vụ mà không kiểm tra liệu tác tử có từ chối hoặc chuyển cấp đúng cách hay không.
• Bỏ qua khía cạnh kinh tế: tối ưu hóa tỷ lệ thành công trong khi chi phí và độ trễ trở nên không thể chấp nhận được.

Từ đánh giá ngoại tuyến đến giám sát trong môi trường thực tế

Đánh giá ngoại tuyến được kiểm soát và có thể lặp lại. Đây là phương thức lý tưởng để so sánh lời nhắc, mô hình, công cụ và chính sách trước khi phát hành. Giám sát trong môi trường thực tế cho thấy những tình huống đa dạng và khó lường trong hành vi thực tế của người dùng cũng như những thay đổi của môi trường.

Một chương trình trưởng thành kết nối hai phương thức này. Sự cố và các quỹ đạo thực tế có độ tin cậy thấp trở thành những tác vụ ngoại tuyến mới. Các thay đổi được đề xuất phải vượt qua bộ kiểm thử hồi quy. Sau khi triển khai, các nhóm theo dõi tỷ lệ hoàn thành tác vụ, tỷ lệ cần can thiệp, sự kiện liên quan đến chính sách, lỗi công cụ, chi phí, độ trễ và phản hồi của người dùng.

Bảng điểm thực tiễn cho tác tử

Bảng điểm nên phân biệt các điều kiện bắt buộc với các chỉ số tối ưu hóa. Việc tuân thủ chính sách, phân quyền và cung cấp bằng chứng bắt buộc có thể là những điều kiện đạt hoặc không đạt; sau đó có thể so sánh độ chính xác, độ trễ, chi phí và công sức của người đánh giá giữa các lần chạy đạt yêu cầu. Cách này giúp các nhóm tránh đánh đổi an toàn để lấy một mức cải thiện hiệu suất nhỏ mà điểm trung bình có thể che khuất.

Một bảng điểm hữu ích có thể bao gồm:

• tỷ lệ hoàn thành tác vụ và điểm chất lượng;
• mức độ nhất quán qua các lần thử lặp lại;
• tỷ lệ vi phạm chính sách nghiêm trọng;
• độ chính xác trong việc chọn công cụ và cung cấp đối số;
• tỷ lệ khôi phục sau sự cố công cụ hoặc môi trường;
• tỷ lệ chuyển cấp cho con người và tỷ lệ con người ghi đè quyết định;
• độ trễ trung vị và độ trễ ở các trường hợp cực trị;
• chi phí cho mô hình, công cụ và nhân lực trên mỗi tác vụ hoàn thành;
• hiệu quả của quỹ đạo thực hiện so với một đường cơ sở hợp lý.

Hãy báo cáo chi phí trên mỗi tác vụ hoàn thành, không chỉ chi phí cho mỗi lần chạy. Một tác tử rẻ nhưng liên tục thất bại có thể tốn kém hơn một mô hình mạnh hơn hoàn thành tác vụ ngay lần đầu.

Những điều cần ghi nhớ về cách đánh giá một tác tử AI

Đánh giá tác tử là hoạt động kiểm thử một hệ thống hoàn chỉnh, hướng đến mục tiêu trong các điều kiện thực tế. Hoạt động này đo lường xem công việc có chính xác hay không, quy trình thực hiện có thể chấp nhận được không, hành vi có thể lặp lại ổn định không và các yếu tố kinh tế có hợp lý không.

Hãy bắt đầu với một nhóm nhỏ các tác vụ có hệ quả đáng kể, nhiều lần thử, các lớp chấm điểm và quỹ đạo thực hiện đầy đủ. Sau đó, biến mọi thất bại đáng kể trong môi trường thực tế thành một bài kiểm thử hồi quy. Năng lực của tác tử thay đổi nhanh chóng; một hệ thống đánh giá bền vững giúp các nhóm phân biệt tiến bộ thực sự với một bản trình diễn đầy sức thuyết phục.