Đánh giá tác nhân AI: kiểm thử chấp nhận trước khi ra mắt

Đánh giá tác nhân AI cần xác định liệu trợ lý có hoàn thành nhiệm vụ kinh doanh đã thống nhất hay không, thay vì chỉ xem thông điệp cuối cùng có thuyết phục hay không. Nếu tác nhân nói đã cập nhật hồ sơ khách hàng, bằng chứng chấp nhận phải nằm trong cả hệ thống đích lẫn cuộc trò chuyện.

Đánh giá tác nhân AI bằng các nhiệm vụ đại diện, quy tắc chấp nhận rõ ràng và kết quả được kiểm tra độc lập. Đưa cả tình huống từ chối, không chắc chắn, gián đoạn và chuyển giao cho con người vào bộ kiểm thử cùng với các ca thành công. Gắn quyết định ra mắt với quy trình và phiên bản đã kiểm thử, thay vì một điểm tổng hợp duy nhất.

Hãy xét một trợ lý chuẩn bị thay đổi địa chỉ giao hàng. Một buổi trình diễn hữu ích có thể hiển thị đúng địa chỉ trong cửa sổ chat. Một đánh giá hữu ích xác định đơn hàng nào đã thay đổi, ai cho phép, việc giao hàng đã bị khóa hay chưa và điều gì xảy ra khi phản hồi từ hệ thống đích không chắc chắn. Đó là những câu hỏi khác nhau.

Các ví dụ dưới đây là thiết kế đánh giá được đề xuất, không phải kết quả của khách hàng hay bộ chuẩn so sánh đã công bố. Chúng giúp người phụ trách kinh doanh đặt hàng bằng chứng trước khi cho phép tác nhân thực hiện thêm công việc.

Xác định kết quả cho việc đánh giá tác nhân AI

Bắt đầu bằng nhiệm vụ mà đồng nghiệp vận hành có thể nhận biết. Mô tả trạng thái ban đầu, hành động được phép và trạng thái kết thúc được chấp nhận. Trong ví dụ đổi địa chỉ, điều kiện chấp nhận có thể yêu cầu đơn hàng đủ điều kiện, địa chỉ đề xuất đã được xác minh, phê duyệt và hồ sơ khớp trong hệ thống đơn hàng.

Giải thích của Anthropic về đánh giá tác nhân phân biệt dấu vết cuộc trò chuyện với trạng thái cuối cùng của môi trường. Phân biệt này vẫn hữu ích khi hệ thống của bạn dùng nhà cung cấp khác. Lời tường thuật trôi chảy về thành công là bằng chứng về phản hồi, không phải bằng chứng độc lập về kết quả kinh doanh.

Không yêu cầu mọi lần chạy hợp lệ phải dùng cùng cách diễn đạt hoặc một chuỗi công cụ duy nhất. Các đường đi khác nhau có thể tạo ra kết quả chấp nhận được. Thay vào đó, phân biệt ràng buộc bắt buộc với chi tiết triển khai có thể thay đổi. Việc sửa hồ sơ bị cấm phải khiến kiểm thử thất bại ngay cả khi câu trả lời cuối cùng thân thiện.

Chỉ định người phụ trách các ca có tranh luận. Nếu bộ phận bán hàng, tài chính và vận hành không thống nhất kết quả đúng, bộ đánh giá tự động không thể giải quyết chính sách kinh doanh thay họ. Ghi lại bất đồng đó như yêu cầu chưa được giải quyết trước khi dùng ca này làm điều kiện ra mắt.

Xây dựng bộ ca đại diện

Thu thập ví dụ từ quy trình thực tế, rồi loại bỏ thông tin cá nhân không cần thiết. Bao gồm yêu cầu thông thường, giá trị khó xử lý nhưng hợp lệ và tình huống hệ thống nên hỏi lại để làm rõ. Tránh bộ kiểm thử chỉ gồm những ví dụ gọn gàng do chính lập trình viên xây dựng tác nhân viết ra.

Xem ma trận này là điểm khởi đầu, không phải tuyên bố bao phủ mọi trường hợp. Trợ lý tính lương, công cụ nghiên cứu nội bộ và tác nhân hỗ trợ khách hàng cần bằng chứng khác nhau. Điểm quan trọng là mỗi ca phải có ý nghĩa kinh doanh mong đợi trước khi được chạy.

Tách ca khám phá khỏi ca chấp nhận

Một ca khám phá có thể phát hiện lỗi mới khi chưa có quy tắc chấm được thống nhất. Đó là bài học có giá trị, nhưng không nên âm thầm thay đổi định nghĩa đạt đã được thỏa thuận. Duy trì bộ chấp nhận ổn định và hàng đợi riêng cho những ca cần điều tra hoặc quyết định chính sách.

Giữ lại các ca đã phát hiện lỗi thực tế. Sau khi sửa lỗi, ca đó trở thành kiểm thử hồi quy. Thêm ví dụ mới khi phạm vi vận hành mở rộng, thay vì liên tục viết lại bộ cũ để khớp đầu ra mới nhất.

Chọn cách kiểm tra từng kết quả

Dùng kiểm tra xác định cho những sự kiện thực sự có tính xác định. Mã định danh ở đích, trường được bảo vệ không thay đổi hoặc việc không có thao tác ghi trái phép thường có thể kiểm tra trực tiếp. Mô hình chấm có thể giúp đánh giá chất lượng giải thích, nhưng không nên là cơ quan duy nhất xác nhận tiền đã chuyển hay hồ sơ đã thay đổi.

Ghi rõ lý do tồn tại của từng phép kiểm tra. So khớp chuỗi thưởng cho một lời xin lỗi cụ thể có thể loại bỏ câu trả lời hoàn toàn hữu ích. Lược đồ chấp nhận tên trường mong đợi vẫn có thể chấp nhận sai khách hàng. Hướng dẫn đối tượng của JSON Schema giải thích xác thực cấu trúc; tính đúng đắn về nghiệp vụ cần thêm các phép khẳng định.

Với câu trả lời mang tính chủ quan, yêu cầu người rà soát mô tả lỗi thay vì chỉ chọn điểm. Phản hồi thiếu căn cứ, khó hiểu, chưa đầy đủ hay vượt quyền người dùng? Nhãn phân biệt giúp dễ giải thích lý do thay đổi kỹ thuật tiếp theo và lặp lại lần rà soát sau.

Kiểm soát môi trường kiểm thử và phiên bản

Ca có thể lặp lại cần nhiều hơn một prompt đã lưu. Ghi lại cách triển khai tác nhân, hướng dẫn liên quan, định nghĩa công cụ, cấu hình mô hình và dữ liệu ban đầu. Nếu hồ sơ ở hệ thống nguồn thay đổi giữa các lần chạy, kết quả có thể khác vì lý do hợp lệ không liên quan đến thay đổi của tác nhân.

Dùng hệ thống đích được kiểm soát cho thao tác tạo tác động kinh doanh. Chủ động đặt lại hoặc tái tạo trạng thái ban đầu. Lần chạy thứ hai trên hồ sơ đã được lần đầu sửa là kiểm thử khác, ngay cả khi yêu cầu bằng ngôn ngữ tự nhiên giống hệt nhau.

Kiểm tra nhiều hơn một lần thử

Hành vi của tác nhân có thể khác giữa các lần thử. Quyết định trước cách các lần thử lặp lại đóng góp vào chấp nhận và giữ toàn bộ kết quả. Chỉ báo cáo lần chạy tốt nhất khiến người phụ trách không hiểu được tính thiếu nhất quán. Tương tự, không khẳng định chắc chắn từ một bộ ví dụ thành công nhỏ.

Thống nhất ngân sách đánh giá thực tế. Một số ca có thể chạy mỗi khi hợp đồng công cụ thay đổi; các ca khác cần người rà soát chuyên môn hoặc môi trường tích hợp đắt tiền. Bộ kiểm thử nhiều lớp có thể cung cấp kiểm tra thường xuyên trong giới hạn rõ ràng, đồng thời giữ đánh giá ra mắt rộng hơn khi phạm vi vận hành thay đổi.

Biến thất bại và chuyển giao thành kết quả hữu ích

Từ chối có thể là kết quả đúng. Tác nhân dừng lại khi đơn hàng mơ hồ có thể hữu ích hơn tác nhân hoàn thành thay đổi sai. Xác định cách làm rõ, chuyển cấp và tiếp tục thủ công được chấp nhận để bộ đánh giá không thưởng cho việc hoàn thành bằng mọi giá.

Kiểm tra hồ sơ chuyển giao kỹ như thao tác đã hoàn thành. Chúng phải xác định yêu cầu gốc, tham chiếu đích liên quan, câu hỏi chưa được giải quyết và hàng đợi chịu trách nhiệm. Chỉ dẫn chung chung về việc liên hệ hỗ trợ có thể khiến đồng nghiệp phải điều tra lại từ đầu.

Tách đánh giá khỏi hoạt động đánh giá bảo mật rộng hơn. OWASP ASVS cung cấp cơ sở xác minh yêu cầu bảo mật ứng dụng. Hướng dẫn bảo mật tác nhân AI của chúng tôi đề cập quyền và đầu vào thù địch. Đánh giá quy trình cần bao gồm các ranh giới này, nhưng kết quả hoàn thành nhiệm vụ tốt không phải bảo đảm bảo mật toàn diện.

Quyết định điều gì sẽ ngăn việc ra mắt

Viết điều kiện dừng trước buổi trình diễn. Tiết lộ dữ liệu giữa khách hàng hoặc ghi trái phép có thể đủ để dừng bất kể tỷ lệ hoàn thành trung bình. Giải thích khó hiểu nhưng có thể khắc phục có thể cần phạm vi hẹp hơn hoặc thử nghiệm được giám sát. Mức độ nghiêm trọng đến từ tác động kinh doanh.

Báo cáo kết quả theo nhóm ca cũng như kết quả chung. Tổng hợp tốt có thể che giấu khả năng khôi phục yếu khi đa số ví dụ là tra cứu thông thường. Nêu số lượng và tính chất ca đã kiểm thử, lỗi chưa xử lý, bất đồng khi rà soát và loại trừ đã biết cùng mọi điểm tổng hợp.

Chấp nhận phải áp dụng cho phạm vi và phiên bản cụ thể. Vượt qua câu hỏi chỉ đọc về đơn hàng không chứng minh sẵn sàng sửa đơn hàng. Thêm hệ thống đích, nhóm người dùng hoặc công cụ ghi mới làm thay đổi ranh giới vận hành và phải dẫn đến việc chủ động rà soát bộ ca.

Giữ hồ sơ ra mắt mà thành viên khác trong nhóm có thể hiểu. Hồ sơ cần giải thích đã kiểm thử gì, điều gì thất bại, điều gì thay đổi và vì sao người phụ trách chấp nhận giới hạn còn lại. Bảng điều khiển xanh không có giải thích là hình thức bàn giao kém khi người đánh giá ban đầu không có mặt.

Dự trù ngân sách cho bằng chứng và bảo trì liên tục

Yêu cầu đề xuất theo GBP với phạm vi rõ ràng cho thiết kế kiểm thử, môi trường kiểm soát, triển khai, rà soát và báo cáo. Tách công việc ban đầu khỏi các lần đánh giá định kỳ và bảo trì ca sau khi quy tắc kinh doanh thay đổi. Không có mức giá chung cho mỗi đánh giá có thể bảo vệ được nếu chưa biết quy trình.

Khoản đầu tư đầu tiên hữu ích thường là bộ kiểm thử hẹp phát hiện một nhóm sai sót đắt giá. Giá trị đến từ quyết định mà nó hỗ trợ, không phải số prompt trong bảng tính. Tránh mua bộ chuẩn tổng hợp lớn mà không ai liên hệ được với vận hành hằng ngày.

Đặt hàng thử nghiệm đánh giá có giới hạn

Mang theo mô tả nhiệm vụ, ví dụ đại diện đã che thông tin nhạy cảm và trạng thái đích chứng minh hoàn thành. Xác định thao tác tác nhân không bao giờ được thực hiện và đồng nghiệp sẽ đánh giá các ca mơ hồ. Ví dụ sự cố có sẵn hữu ích khi chi tiết nhạy cảm được xử lý phù hợp.

Thử nghiệm tích hợp AI có phạm vi của chúng tôi có thể bắt đầu bằng nhiệm vụ đó và bằng chứng chấp nhận của nó. Phạm vi ban đầu giúp xác định liệu tác nhân, công cụ và hệ thống đích có phối hợp đáng tin cậy trước khi mở rộng truy cập hay không.

Gửi chúng tôi quy trình và quyết định ra mắt bạn cần đưa ra . Yêu cầu bộ đánh giá có thể lặp lại, mô tả điểm mù và bàn giao rõ ràng. Sản phẩm cần giúp bạn quyết định tiếp theo có thể tin tưởng giao việc gì cho tác nhân một cách an toàn.

Câu hỏi thường gặp

Đánh giá tác nhân AI là gì? Đánh giá tác nhân AI kiểm tra tác nhân theo nhiệm vụ xác định và quy tắc chấp nhận. Nó xem xét trạng thái hệ thống sau thực hiện, thao tác được phép và chất lượng của mọi giải thích hoặc chuyển giao, thay vì xem thông điệp cuối thuyết phục là bằng chứng hoàn thành.

Điểm chuẩn so sánh có đủ để phê duyệt tác nhân kinh doanh không? Không. Bộ chuẩn chung có thể hỗ trợ so sánh kỹ thuật, nhưng chấp nhận ra mắt cần ca phản ánh hồ sơ, quyền, dạng lỗi và quy tắc kinh doanh của bạn. Báo cáo phạm vi đã kiểm thử và giới hạn chưa giải quyết.

Chúng tôi cần bao nhiêu ca kiểm thử? Không có số lượng chung. Bắt đầu với kết quả riêng biệt và đường lỗi quan trọng trong quy trình đề xuất. Thêm ca khi công cụ mới, nhóm người dùng hoặc ngoại lệ chính sách tạo ra hành vi khác biệt đáng kể. Bộ prompt lớn gần giống nhau không tương đương phạm vi bao phủ vận hành rộng.

Mô hình khác có thể chấm câu trả lời không? Có, cho phần rà soát phù hợp. Hiệu chỉnh nó bằng ví dụ đã được người am hiểu kiểm tra và giữ phép khẳng định xác định về đích cho sự kiện như hồ sơ nào đã thay đổi. Phán đoán của mô hình không nên thay thế bằng chứng về thao tác kinh doanh.

Từ chối đúng có nên được tính là thành công không? Có, khi từ chối là kết quả mong đợi. Xác định nội dung từ chối hữu ích và xác nhận không xảy ra thao tác hoặc tiết lộ bị cấm.

Chúng tôi có cần dữ liệu khách hàng trong môi trường sản xuất không? Thông thường nên bắt đầu bằng ví dụ có kiểm soát giữ cấu trúc liên quan và tình huống khó xử lý mà không có thông tin cá nhân không cần thiết. Mọi việc dùng dữ liệu thực cần mục đích rõ ràng, quyền truy cập phù hợp và chính sách xử lý. Hành vi đại diện quan trọng hơn việc sao chép cả cơ sở dữ liệu sản xuất vào bộ đánh giá.

Nhà cung cấp đánh giá cần bàn giao gì? Bộ ca, kết quả mong đợi, hướng dẫn trạng thái ban đầu, quy tắc chấm, hồ sơ phiên bản và bằng chứng lỗi. Bao gồm lệnh hoặc quy trình cần để lặp lại đánh giá và người phụ trách cập nhật.

Khi nào chúng tôi nên chạy lại bộ kiểm thử? Lặp lại kiểm tra liên quan sau thay đổi mô hình, hướng dẫn, công cụ, quyền hoặc hành vi hệ thống đích. Rà soát phạm vi bao phủ khi nhiệm vụ kinh doanh mở rộng. Kết quả chấp nhận trước đó thuộc về phạm vi đã kiểm thử trước đó.