Agent Evaluation
Agent Evaluation
Phương pháp luận đo agent có hoạt động tốt trước khi người dùng thật gặp vấn đề. 7 thuật ngữ cốt lõi (Task/Trial/Grader/Transcript/Outcome/Harness/Suite), 3 loại Grader, roadmap 8 bước, và 2 chỉ số pass@k (tăng theo k) vs pass^k (giảm theo k).
Nắm vững nguyên lý và khái niệm nền tảng trước khi đi vào công cụ thực tế.
Áp dụng quy trình từng bước, case study thực chiến và template mẫu có sẵn.
Kiểm tra checklist hoàn thành, né tránh các sai lầm kinh điển để vận hành bền vững.
Nắm vững các khái niệm nền tảng, cơ chế hoạt động và mô hình tư duy cốt lõi.
1. Khái niệm cốt lõi
Agent Evaluation (eval) là “1 bài test cho hệ thống AI: đưa input, áp dụng logic chấm điểm cho output để đo mức độ thành công” — thường chạy tự động trong lúc phát triển, trước khi người dùng thật gặp phải vấn đề.
7 thuật ngữ cốt lõi:
- Task — 1 bài test đơn lẻ, có input và tiêu chí thành công rõ ràng.
- Trial — 1 lần thử 1 task (chạy nhiều trial vì output agent không cố định giữa các lần).
- Grader — logic chấm điểm hiệu năng theo 1 khía cạnh cụ thể.
- Transcript — bản ghi đầy đủ mọi tương tác/tool call/suy luận trong 1 trial.
- Outcome — trạng thái cuối cùng đạt được sau khi trial kết thúc.
- Evaluation Harness — hạ tầng chạy test từ đầu tới cuối, ghi lại từng bước, tổng hợp kết quả.
- Evaluation Suite — tập hợp task liên quan, đo 1 nhóm năng lực cụ thể.
2. Tại sao nội dung này quan trọng
Không có eval, đội ngũ “kẹt trong vòng lặp phản ứng — chỉ phát hiện lỗi khi đã ở production, nơi sửa 1 lỗi có thể tạo ra lỗi khác”. Eval giúp bạn nhìn thấy vấn đề trước khi người dùng thật gặp phải, đúng nguyên tắc “phòng hơn chữa” áp dụng cho hệ thống agent.
3. Cơ chế hoạt động — 3 loại Grader
- Code-Based Graders — so khớp chuỗi, test nhị phân, phân tích tĩnh — nhanh, khách quan, tái lập được; điểm yếu: cứng nhắc với biến thể hợp lệ.
- Model-Based Graders — chấm theo rubric, đánh giá ngôn ngữ tự nhiên, so sánh cặp — linh hoạt, xử lý được sắc thái; điểm yếu: không xác định (kết quả có thể đổi giữa các lần), cần hiệu chuẩn.
- Human Graders — chuyên gia review, kiểm tra ngẫu nhiên, đo độ đồng thuận giữa người chấm — chất lượng chuẩn vàng; điểm yếu: tốn kém, khó mở rộng quy mô.
2 chỉ số cho agent không xác định (non-deterministic):
- pass@k — xác suất agent thành công ở ít nhất 1 trong k lần thử (tăng khi thử nhiều hơn) — phù hợp khi chỉ cần 1 lần đúng là đủ.
- pass^k — xác suất agent thành công ở cả k lần thử (giảm khi thử nhiều hơn) — phù hợp khi cần độ tin cậy nhất quán.
4. Visual hoặc diagram cần thiết
(Visual Brief đầy đủ còn mô tả 1 panel thứ 2: 2 đường cong đối lập trên cùng 1 trục k — pass@k đi lên, pass^k đi xuống khi k tăng.)
Quy trình thực thi từng bước, case study cụ thể và bộ prompt/template áp dụng ngay.
5. Hướng dẫn từng bước — Roadmap 8 bước xây eval
(Theo)
Giai đoạn 1 — Xây Task:
- Bắt đầu sớm với 20-50 task đơn giản từ lỗi thật đã gặp, không cần hàng trăm task ngay từ đầu.
- Tận dụng test thủ công/báo lỗi đã có, chuyển thành test case.
- Viết task rõ ràng, không mơ hồ, kèm “reference solution” chứng minh task giải được.
Giai đoạn 2 — Thiết kế & Triển khai: 4. Xây môi trường ổn định — mỗi trial bắt đầu sạch, cô lập để tránh nhiễu trạng thái chung. 5. Thiết kế grader cẩn thận, khớp đúng loại agent, tránh chấm điểm cứng nhắc theo từng bước, có “partial credit” (điểm 1 phần).
Giai đoạn 3 — Bảo trì & Tiến hóa: 6. Đọc transcript định kỳ, xác nhận việc chấm điểm công bằng. 7. Theo dõi “saturation” — khi 1 eval đạt 100% pass rate, làm mới bằng task khó hơn. 8. Duy trì lâu dài — giao người phụ trách, cho phép đội sản phẩm đóng góp task mới.
6. Ví dụ thực tế
Áp dụng cho Customer Support Agent (bài 79, 84):
- Task: “khách hỏi về chính sách hoàn tiền cho đơn hàng quá 30 ngày” — có reference solution rõ ràng (từ chối kèm giải thích chính sách).
- Trial: chạy agent 5 lần với cùng task này (vì câu trả lời có thể diễn đạt khác nhau mỗi lần).
- Grader: kết hợp Code-Based (kiểm tra agent có nhắc đúng chính sách 30 ngày không) + Model-Based (rubric: câu trả lời có lịch sự, đầy đủ không).
- pass@k vs pass^k: nếu chỉ cần agent từng trả lời đúng để rút kinh nghiệm → dùng pass@k; nếu cần agent luôn luôn trả lời đúng vì đây là chính sách quan trọng → dùng pass^k (tiêu chí khắt khe hơn).
4 cách tiếp cận theo loại agent (chỉ nêu tên, không đào sâu):
- Coding agent: test xác định (code chạy được không) + phân tích transcript.
- Conversational agent: xác minh trạng thái + đánh giá đa lượt + rubric LLM, thường cần mô phỏng người dùng.
- Research agent: kiểm tra tính có căn cứ, độ bao phủ, chất lượng nguồn.
- Computer use agent: test trong môi trường thật/sandbox.
7. Prompt/template/workflow
Task: [input cụ thể] → [tiêu chí thành công rõ ràng, có referencesolution]Grader phù hợp: [ ] Code-Based [ ] Model-Based [ ] Human (có thể chọnnhiều)Số trial cần chạy: [k]Chỉ số: [ ] pass@k (chỉ cần 1 lần đúng) [ ] pass^k (cần luôn đúng)8. Bài tập thực hành
Chọn agent bạn đã thiết kế xuyên suốt bài 82-85. Viết ra 3 task đơn giản (bước 1, mục 5) dựa trên tình huống thật bạn có thể hình dung agent gặp phải. Với mỗi task, xác định: loại grader nào phù hợp, và nên dùng pass@k hay pass^k.
Checklist kiểm tra mức độ sẵn sàng, nhận diện các bẫy sai lầm và nguyên tắc vàng vận hành.
9. Checklist
10. Lỗi thường gặp
(Suy luận từ nguyên tắc, không phải quan sát độc lập.)
- Xây eval quá lớn ngay từ đầu (hàng trăm task) thay vì bắt đầu nhỏ từ lỗi thật — dễ bỏ cuộc vì quá tải trước khi có giá trị đầu tiên.
- Chấm điểm cứng nhắc theo từng bước thay vì đo Outcome — phạt agent vì đi đường khác nhưng vẫn đạt đúng kết quả.
- Không đọc lại transcript định kỳ — không phát hiện được khi grader chấm sai/không công bằng.
- Không theo dõi saturation — 1 eval đạt 100% mãi mãi không còn cho biết agent có thực sự tốt hơn hay không.
- Nhầm eval với giám sát production — eval chạy có kiểm soát trước khi triển khai; giám sát production (bài 88) theo dõi hành vi thật khi đã có người dùng thật.
11. Nội dung nâng cao (không bắt buộc)
Nguồn nhấn mạnh: eval tự động không thay thế mà cần kết hợp với giám sát production, A/B testing, phản hồi người dùng, và nghiên cứu hiệu chuẩn con người có hệ thống. Ranh giới quan trọng: phần “giám sát production” chỉ được nhắc như 1 phương pháp bổ sung ở đây — nội dung đầy đủ về giám sát/observability khi agent đã triển khai thật là phạm vi bài 88, không đào sâu ở đây.
📚 12. Nguồn tham khảo
Demystifying Evals for AI Agents, Anthropic (anthropic.com/engineering) — định nghĩa cốt lõi, 3 loại grader, roadmap 8 bước, pass@k/pass^k, cách tiếp cận theo loại agent · Dẫn chiếu (không trích dẫn mới): bài 79 (Customer Support Agent, ví dụ mục 6); bài 87 (Guardrails); bài 88 (Production Agent/Monitoring).