Hướng dẫn
Hướng dẫn OpenRouter: Tự động đánh giá đầu ra của AI Agent bằng phương pháp LLM-as-a-judge
(giờ Việt Nam)
Tóm tắt AI
OpenRouter chia sẻ cách sử dụng mô hình AI làm giám khảo để chấm điểm tự động cho các phản hồi của AI Agent, giúp kiểm soát chất lượng các câu trả lời mở mà phương pháp kiểm thử truyền thống không làm được.
Chính văn · Bản dịch AI

Một agent có thể vượt qua mọi bài kiểm tra mang tính xác định nhưng vẫn đưa ra câu trả lời kém chất lượng. Một agent hỗ trợ có thể gọi đúng công cụ tra cứu đơn hàng, truy xuất đúng chính sách, nhưng lại bỏ quên thời hạn hoàn tiền trong phản hồi của mình. Các khẳng định về công cụ đều đạt, nhưng không có gì kiểm tra xem câu trả lời cuối cùng có chính xác, đầy đủ và hữu ích hay không.
Đánh giá bằng LLM-as-a-judge (LLM đóng vai trò giám khảo) giúp lấp đầy khoảng trống đó. Một mô hình thứ hai sẽ xem xét kết quả đầu ra của agent ứng viên dựa trên các tiêu chí bạn viết bằng ngôn ngữ tự nhiên và trả về một điểm số. Điều này cung cấp cho bạn một cách thức có thể lặp lại để kiểm tra các phản hồi mở, vốn có thể diễn đạt theo nhiều cách hợp lệ khác nhau.
LLM-as-a-judge là gì
Bạn chạy một ứng viên, sau đó cung cấp kết quả đầu ra của nó cùng với bất kỳ kết quả công cụ liên quan nào cho một giám khảo. Giám khảo sẽ chấm điểm bằng chứng đó dựa trên một bộ tiêu chí (rubric) mà bạn đã soạn thảo. Nếu điểm số thấp hơn ngưỡng bạn đặt ra, quá trình đánh giá sẽ thất bại.
Giám khảo là một lệnh gọi mô hình giống như bất kỳ lệnh gọi nào khác. Nó đọc văn bản, áp dụng các tiêu chí của bạn và trả về một con số. Hãy coi con số đó là một phép đo được thực hiện với một thiết lập cố định, chứ không phải là chân lý tuyệt đối (ground truth).
Mô hình giám khảo so với mô hình ứng viên
Hãy giữ hai vai trò này trên các mô hình khác nhau khi có thể. Trong bài báo năm 2023 “Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena”, Zheng và cộng sự đã xác định các thiên kiến về tự nâng cao (self-enhancement), vị trí (position) và độ dài (verbosity). Một giám khảo có thể ưu ái câu trả lời do chính nó tạo ra, câu trả lời hiển thị ở vị trí ưu tiên, hoặc câu trả lời dài hơn bất kể chất lượng của nó.
Cung cấp cho giám khảo phản hồi hiển thị và chỉ những kết quả công cụ cần thiết để áp dụng bộ tiêu chí. Nếu giám khảo có thể thấy suy luận ẩn của ứng viên, điểm số sẽ không còn tính độc lập nữa.
Chấm điểm theo bộ tiêu chí (rubric) so với khớp chính xác (exact match) so với đánh giá của con người
Khớp chính xác kiểm tra một chuỗi hoặc một trường có cấu trúc so với một giá trị cố định. Hãy sử dụng nó khi chỉ có duy nhất một giá trị là đúng.
Nằm giữa khớp chính xác và một bộ tiêu chí đầy đủ là kiểm tra nội dung mang tính xác định, khẳng định rằng một cụm từ bắt buộc phải xuất hiện. Trong Ori Eval, đó là run.toMention. Nó phù hợp khi câu trả lời bắt buộc phải chứa một thuật ngữ cụ thể ngay cả khi cách diễn đạt xung quanh nó là tự do.
Bộ tiêu chí (rubric) là một tập hợp ngắn các quy tắc mà một người có thể áp dụng. “Trích dẫn thời hạn 14 ngày và không tự ý đưa ra các ngoại lệ” là một bộ tiêu chí. “Nghe có vẻ hữu ích” thì không phải.
Người đánh giá xác định tiêu chuẩn chất lượng, nhưng một người không thể chấm điểm mọi lượt chạy của một tập đánh giá lớn, và hai người đánh giá có thể đưa ra kết luận khác nhau trên cùng một kết quả đầu ra. Giám khảo là một phương án thay thế có thể lặp lại mà bạn có thể kiểm chứng dựa trên một tập dữ liệu nhỏ đã được con người gán nhãn.
Chấm điểm theo điểm (pointwise), theo cặp (pairwise) và dựa trên tham chiếu (reference-based)
Các giám khảo LLM được sử dụng trong ba chế độ đánh giá:
Hướng dẫn này sử dụng cách chấm điểm theo điểm (pointwise), vì mỗi lượt chạy hoặc là đáp ứng tiêu chuẩn yêu cầu hoặc là không đạt. Đối với đánh giá theo cặp (pairwise), hãy chấm điểm cả hai thứ tự câu trả lời để phát hiện thiên kiến vị trí. Đánh giá dựa trên tham chiếu (reference-based) hiệu quả khi tham chiếu chứa các dữ kiện mà phản hồi phải bảo toàn, thay vì cách diễn đạt mà nó phải sao chép.
Khi nào nên sử dụng giám khảo LLM
Sử dụng giám khảo LLM khi yêu cầu rõ ràng nhưng không có một kết quả đầu ra chính xác duy nhất. Ví dụ:
Giám khảo LLM không phù hợp khi kết quả có thể được kiểm tra trực tiếp. Hãy sử dụng trình xác thực lược đồ (schema validator) cho cấu trúc JSON, máy tính cho các phép toán số học, và kiểm thử đơn vị (unit tests) cho các đối số công cụ và tác dụng phụ. Các quy tắc bắt buộc phải chặn một hành động luôn luôn nên giữ ở dạng xác định. Giám khảo có thể kiểm tra chất lượng của phản hồi cuối cùng, nhưng nó không nên là lớp thực thi duy nhất cho một chính sách quan trọng.
Một bài kiểm tra gọi công cụ có thể khẳng định rằng agent đã gọi lookup_order một lần và không bao giờ gọi issue_refund mà không có sự phê duyệt. Sau đó, giám khảo sẽ chấm điểm xem câu trả lời cuối cùng của agent có giải thích chính xác những gì đã xảy ra hay không. Nếu bạn vẫn cần xây dựng lớp thực thi, hãy bắt đầu với hướng dẫn gọi công cụ của chúng tôi.
Chấm điểm agent với Ori Eval
Ori Eval chạy các đánh giá dựa trên các prompt và hành vi agent của riêng bạn. Một eval là một tệp TypeScript chạy với trình chạy kiểm thử của Bun. Ori giải quyết một harness và một mô hình cho một lượt chạy và giữ chúng cho mọi bài kiểm tra trong lượt chạy đó, vì vậy một prompt không thể thay đổi cấu hình giữa chừng. Một tệp so sánh mô hình vẫn có thể bắt đầu một lượt chạy riêng cho từng mô hình ứng viên.
Cách nhanh nhất để bắt đầu là thông qua coding agent của bạn. Hãy đưa cho nó chỉ dẫn này:
Kỹ năng spawn-ori-eval sẽ cài đặt Ori, đảm bảo bạn đã đăng nhập, hỏi bạn muốn đánh giá điều gì, viết eval, chạy các mô hình ứng viên và đề xuất một mô hình kèm theo điểm số, thời gian và chi phí đằng sau đề xuất đó. Nó hoạt động trong một thư mục tạm thời, vì vậy nó không thêm các tệp eval vào dự án của bạn. Hãy sử dụng các bước thủ công bên dưới khi bạn muốn giữ các tệp trong dự án của mình hoặc kiểm tra từng phần của quá trình đánh giá.
Hàm setupJudge của Ori tạo ra một agent chấm điểm riêng biệt trên mô hình của chính nó, và autoEvals chấm điểm một lượt chạy ứng viên dựa trên các tiêu chí của bạn. Ví dụ dưới đây kiểm tra một agent hỗ trợ trả lời các câu hỏi về hoàn tiền. Nó giả định rằng harness Ori hiện tại của bạn có thể kết nối với agent hỗ trợ và các công cụ của nó.
1. Cài đặt Ori và đăng nhập
Cài đặt Ori CLI, sau đó xác thực một lần:
Ori chạy các tệp đánh giá bằng Bun. Nếu Bun chưa được cài đặt, ori eval sẽ yêu cầu quyền cài đặt nó. Trong CI hoặc môi trường không tương tác khác, lệnh sẽ dừng lại và hiển thị cho bạn cách cài đặt Bun. Ứng dụng của bạn không cần phải là một dự án TypeScript.
2. Xác định một yêu cầu chất lượng có thể quan sát được
Bắt đầu với một lỗi mà bạn đã thấy hoặc muốn ngăn chặn. Đối với ví dụ này, agent phải trích dẫn thời hạn hoàn tiền 14 ngày và không được tự ý đưa ra các ngoại lệ chính sách.
Tiêu chí đó mạnh hơn “đưa ra câu trả lời hữu ích” vì bất kỳ ai cũng có thể áp dụng nó mà không cần đoán xem thế nào là hữu ích. Nó nêu rõ cả bằng chứng bắt buộc và điều kiện thất bại.
3. Tạo đánh giá
Tạo tệp evals/support/refund-quality.eval.ts:
Bài kiểm tra này sử dụng hai lớp đánh giá. Các khẳng định run.tool và run.toComplete kiểm tra các hành động có thể quan sát được, và autoEvals chấm điểm ý nghĩa của phản hồi đã hoàn thành. minScore đặt điểm số thấp nhất để vượt qua. Giá trị 0.8 ở đây là giá trị khởi đầu. Hãy hiệu chỉnh nó dựa trên các phản hồi đã được gán nhãn của riêng bạn, phần độ tin cậy bên dưới sẽ đề cập đến điều này.
setupJudge chấm điểm bằng mô hình của riêng nó, tách biệt với mô hình đang được kiểm tra. Để chấm điểm bằng một mô hình khác, hãy truyền agent của riêng bạn vào setupJudge. Tài liệu Ori Eval có hiển thị cách gọi này.
4. Chạy đánh giá
Chạy bài kiểm tra từ thư mục dự án của bạn:
Ori tìm các tệp *.eval.ts bên dưới thư mục hiện tại, chạy chúng bằng bun test, và thoát với mã thoát của bun test, vì vậy một đánh giá thất bại sẽ làm lệnh thất bại. Cờ --report sẽ viết một báo cáo Markdown mà bạn có thể xem xét cùng với phần còn lại của kết quả kiểm tra.
Các đánh giá LLM thực hiện các yêu cầu mô hình thực tế. Hãy giữ chúng trong một công việc CI riêng biệt chạy thủ công, theo lịch trình, hoặc trước khi phát hành thay vì thêm chúng vào mỗi lượt chạy kiểm thử đơn vị. Lưu trữ OPENROUTER_API_KEY dưới dạng bí mật của kho lưu trữ (repository secret). Với biến đó được thiết lập, Ori không cần ori login trong CI. Phần "Run an eval in CI" trong tài liệu Ori Eval bao gồm một ví dụ đầy đủ về GitHub Actions.
Bài viết được AI dịch và tổng hợp tự động từ OpenRouter: Announcements. Liên kết bài gốc ở phía trên. Dữ liệu đồng bộ qua API công khai được ghi nguồn tại AI HOT (canonical) ↗. AIHOT.vn luôn dẫn nguồn đầy đủ — nếu bạn thấy điểm cần chỉnh sửa, hãy gửi ý kiến tại trang phản hồi.