Việc agent chạy được chỉ là bước đầu tiên.Tác giả bài viết: elune
Bài dịch, nguồn: ME News
Việc agent chạy được chỉ là bước đầu tiên.
Điều khó thực sự là xác định: nó có ổn định không, có chính xác không, hay có đang suy giảm âm thầm do một lần nhắc nhở hoặc cập nhật mô hình không.
10 phương pháp đánh giá sau đây, mỗi kỹ sư AI đều nên biết.
1. Bộ thử nghiệm vàng | Golden Set
Chuẩn bị một bộ các trường hợp kiểm thử cố định và bị khóa.
Sau mỗi lần chỉnh sửa prompt, mô hình, công cụ hoặc quy trình làm việc, hãy chạy lại bộ trường hợp này để xác định hệ thống có trở nên tốt hơn hay đang âm thầm thất bại trong một số tình huống.
Đây là mức cơ sở cơ bản nhất trong hệ thống đánh giá Agent.
Công cụ được đề xuất: OpenAI Evals
Có thể sử dụng để xây dựng bộ kiểm tra chuẩn có thể chạy lặp lại và so sánh hiệu suất của các mô hình hoặc phiên bản hệ thống khác nhau.
2. Trọng tài LLM | LLM làm trọng tài
Sử dụng một mô hình ngôn ngữ lớn khác để đánh giá các câu trả lời mở theo các tiêu chí chấm điểm đã được lập sẵn.
Phương pháp này đặc biệt hiệu quả khi nhiệm vụ không có câu trả lời duy nhất và không thể xác định đúng sai thông qua khớp chuỗi hoặc đầu ra cố định.
Ví dụ: có thể sử dụng mô hình giám khảo để đánh giá câu trả lời có chính xác, đầy đủ, liên quan và tuân thủ yêu cầu của người dùng hay không.
Công cụ được đề xuất: OpenEvals
Cung cấp các trình đánh giá sẵn sàng cho các ứng dụng LLM, giúp xây dựng nhanh quy trình đánh giá tự động.
3. Đánh giá theo tiêu chí | Rubric Scoring
Đừng chỉ cung cấp cho Agent một “điểm chất lượng” chung chung.
Nên đánh giá riêng biệt:
- Correctness
- Integrity
- Expression style
- Security
- Response speed
- Chi phí gọi
Một điểm tổng hợp có thể che giấu những vấn đề thực sự.
Ví dụ: điểm tổng giảm có thể không phải do câu trả lời sai, mà do chi phí gọi công cụ tăng đột ngột; điểm tổng tăng cũng có thể dựa trên sự giảm sút về tính bảo mật.
Công cụ được đề xuất: DeepEval
Hỗ trợ tạo chỉ số tùy chỉnh và đánh giá độc lập các chiều chất lượng khác nhau.
4. Đánh giá quỹ đạo | Trajectory Eval
Đừng chỉ đánh giá câu trả lời cuối cùng mà Agent đưa ra, mà còn phải đánh giá toàn bộ quá trình nó hoàn thành nhiệm vụ.
Bao gồm:
- Bạn đã chọn đúng công cụ chưa?
- Có gọi công cụ theo thứ tự hợp lý không
- Có đang lặp lại thao tác không hiệu quả không
- Có bỏ sót bước nào cần thiết không
- Có điều chỉnh quyết định dựa trên kết quả công cụ không
Agent có thể cuối cùng đạt được câu trả lời đúng, nhưng quy trình trung gian kém hiệu quả, dễ bị tổn thương và thậm chí tiềm ẩn rủi ro.
Công cụ được đề xuất: AgentEvals
Có thể kiểm tra các hành động, quyết định và gọi công cụ của Agent trong toàn bộ chuỗi thực thi.
5. Kiểm thử đơn vị công cụ｜Tool Unit Tests
Viết bài kiểm tra riêng biệt cho từng công cụ mà Agent sử dụng.
Use fixed input to verify fixed output, without involving the model.
Như vậy có thể tách riêng vấn đề:
Là do Agent suy luận sai, hay do công cụ nền tảng, giao diện hoặc MCP Server gặp sự cố?
Chỉ khi đảm bảo rằng công cụ本身 đáng tin cậy, thì mới có ý nghĩa đánh giá xem Agent có gọi công cụ đúng cách hay không.
Công cụ được đề xuất: MCP Inspector
Có thể sử dụng để kiểm tra và thử nghiệm MCP Server, các tham số công cụ và kết quả trả về.
6. Bộ kiểm thử hồi quy | Regression Suite
Save past real execution cases and re-run after each update to prompts, models, or toolsets.
Sau đó so sánh kết quả giữa phiên bản mới và cũ, kiểm tra:
- Whether the originally correct task has failed
- Định dạng đầu ra có thay đổi không
- Có tăng cường gọi công cụ không?
- Latency và chi phí có tăng không
- Some edge cases are degenerating
Phiên bản mới có hiệu suất trung bình tốt hơn không có nghĩa là nó không làm hỏng các chức năng cũ.
Công cụ được đề xuất: Promptfoo
Hỗ trợ chạy bộ đánh giá có thể lặp lại, phát hiện các vấn đề hồi quy và tích hợp quy trình kiểm tra vào CI.
7. Kiểm thử A/B trong môi trường sản xuất｜A/B Testing in Production
Phân bổ ngẫu nhiên lưu lượng người dùng thực tế cho hai phiên bản khác nhau để so sánh hiệu suất của chúng trong môi trường thực tế.
Có thể thử nghiệm:
- Hai bộ hướng dẫn
- Hai mô hình
- Hai luồng làm việc Agent
- Các tổ hợp công cụ khác nhau
- Các chiến lược phản hồi khác nhau
Phiên bản có điểm đánh giá ngoại tuyến cao hơn không nhất thiết mang lại tỷ lệ thành công cao hơn cho người dùng.
Điều quan trọng thực sự là các kết quả thực tế, chẳng hạn như tỷ lệ hoàn thành nhiệm vụ, tỷ lệ người dùng áp dụng, tỷ lệ chuyển đổi, tỷ lệ chuyển cho nhân viên và tỷ lệ giải quyết vấn đề.
Công cụ được đề xuất: GrowthBook
Cung cấp khả năng bật/tắt tính năng, thí nghiệm có kiểm soát và phân tích sản phẩm.
8. Xác minh thủ công｜Human Review
Các bản ghi hoạt động thực tế được lấy mẫu định kỳ và được đánh giá bởi người kiểm duyệt con người.
Việc kiểm duyệt bằng tay không chỉ có thể phát hiện các vấn đề bị bỏ sót bởi đánh giá tự động, mà còn có thể được sử dụng để hiệu chỉnh người phán xét LLM.
Cần kiểm tra kỹ:
- Điểm mô hình có nhất quán với phán đoán của con người không
- Các tiêu chí đánh giá có đủ rõ ràng không
- Mô hình phán xét có thiên vị về các câu trả lời dài không?
- Tự động đánh giá xem có bỏ sót lỗi nghiêm trọng nào không
Đánh giá tự động không thể thay thế hoàn toàn phán đoán của con người.
Công cụ được đề xuất: Argilla
Hỗ trợ đội ngũ thu thập phản hồi từ con người, kiểm duyệt đầu ra của mô hình và tổng hợp kết quả thành bộ dữ liệu chất lượng cao.
9. Shadow Run
Chạy phiên bản ứng cử song song trên lưu lượng thực, nhưng không hiển thị đầu ra của nó cho người dùng.
Môi trường sản xuất vẫn sử dụng phiên bản cũ, trong khi phiên bản mới chỉ được thực thi ở nền, nhằm so sánh hiệu suất của cả hai.
Cách này phù hợp với các bản cập nhật rủi ro cao, ví dụ:
- Đổi mô hình cốt lõi
- Rewrite system prompt
- Connect new external tools
- Sửa đổi logic ra quyết định của Agent
- Mở rộng quyền công cụ
Shadow running helps teams identify issues in real traffic before official release, while avoiding direct impact on users.
Công cụ được đề xuất: Langfuse
Theo dõi quá trình sản xuất, so sánh các phiên bản ứng cử và giám sát kết quả đánh giá.
10. Kiểm thử đội đỏ | Red Teaming
Chủ động tấn công hệ thống của chính mình trước khi kẻ tấn công thực hiện.
Phạm vi kiểm tra bao gồm:
- Jailbreak attack
- Prompt injection
- Rò rỉ dữ liệu nhạy cảm
- Bypass permissions
- Lạm dụng công cụ
- Tập tin hoặc nội dung trang web độc hại
- Hành động bên ngoài không mong muốn
Đối với các Agent có thể truy vấn cơ sở dữ liệu, gửi email, sửa đổi tệp tin, thực thi mã hoặc truy cập vào các hệ thống nội bộ, việc kiểm thử red team đặc biệt quan trọng.
Công cụ được đề xuất: Garak
Có thể quét các lỗ hổng bảo mật và hành vi không an toàn trong hệ thống LLM.
Offline evaluation tells you: the system works normally in the testing environment.
The online assessment tells you: the system will continue to function normally after going live.
Bạn có thể không cần phải thiết lập toàn bộ 10 cơ chế đánh giá ngay lập tức.
Cách thực tế hơn là:
Xem lại sự cố Agent gần nhất, sau đó ưu tiên triển khai hai phương pháp đánh giá có thể giúp phát hiện vấn đề sớm hơn.
Thường có thể tránh được rất nhiều sự cố cấp thấp bằng cách xây dựng bộ kiểm thử vàng trước, sau đó bổ sung kiểm thử hồi quy hoặc kiểm tra ngẫu nhiên bằng tay.
Đáng để lưu lại.