如何构建一个针对特定业务场景的 Agent 评估集
1️⃣ 考察意图
考察从 0 到 1 构建评估集的能力。刁钻点：不是收集数据就行，需要考虑覆盖度、难度分级、防泄漏、可维护性。
2️⃣ 标准答
构建流程（5 步）：
Step 1: 定义评估维度
- 根据业务场景定义能力维度。如客服 Agent：意图理解(30%)、知识检索(25%)、工具调用(20%)、多轮对话(15%)、安全拒绝(10%)
- 每个维度设定目标准确率（如意图理解 >95%）
Step 2: 收集任务样本
- 来源：真实用户日志（脱敏后）+ 人工构造 + 边界场景
- 数量：每个维度 30-50 个任务，总计 200-300 个
- 难度分级：P0（常见场景，60%）、P1（复杂场景，30%）、P2（边界场景，10%）
Step 3: 标注 Expected Behavior
- 每个任务标注：(1) 期望输出（精确答案或可接受答案列表）；(2) 评估标准（精确匹配/语义匹配/人工评分）；(3) 评分维度（如"是否正确理解意图"、"是否调用了正确工具"）
- 标注人员：业务专家 + 标注团队交叉验证
Step 4: 设计评估 Pipeline
- 自动化评估：精确匹配 + 语义相似度（如 BERTScore）+ 规则检查（如是否包含必填信息）
- LLM-as-Judge：用 GPT-4 对开放性输出打分（1-5分）
- 人工评估：抽 20% 数据人工审核，校准自动化评估
Step 5: 防泄漏与维护
- 防泄漏：评估集不进入训练数据。定期更新（每季度新增 10% 任务，淘汰过时任务）
- 版本管理：每次评估记录 Agent 版本、评估日期、结果，支持回溯对比
- 持续优化：分析 Agent 失败案例，将高价值失败案例加入评估集
3️⃣ 答题模板
"五步构建评估集。定义维度（按业务分5-6维度，设目标准确率）→ 收集样本（真实日志+人工构造+边界场景，200-300个，P0/P1/P2分级）→ 标注期望行为（精确答案+评估标准+评分维度）→ 设计pipeline（自动匹配+LLM-as-Judge+人工抽检20%）→ 防泄漏维护（不进训练数据、季度更新、版本管理）。核心：评估集是活的资产，持续更新。"
4️⃣ 高频追问
追问 1：评估集多大才够？
经验值：200-300 个任务覆盖主要场景。太少（<50）统计不显著，太多（>1000）标注成本高且边际收益递减。关键不是数量而是覆盖度——每个能力维度至少 30 个任务，每个难度等级至少 20 个。如果某个维度的准确率波动大（如工具调用），可以增加到 50 个。
追问 2：怎么防止 Agent 在评估集上过拟合？
三个措施：(1) 评估集不进训练数据——严格执行数据隔离，评估集只有评估团队可访问；(2) 定期更新——每季度新增 10-20% 新任务，淘汰 Agent 已经能解决的过时任务；(3) Holdout 集——保留 20% 数据作为"秘密评估集"，只在版本发布前使用，日常迭代不用。如果 Agent 在公开评估集上 95% 但在 holdout 上只有 70%，说明过拟合。
追问 3：LLM-as-Judge 在业务评估中怎么用？有什么坑？
使用方式：对每个 Agent 输出，用 GPT-4 按 5 个维度打分（1-5分）：正确性、完整性、简洁性、安全性、用户体验。坑：(1) 位置偏见——GPT-4 倾向给第一个选项高分，需要随机打乱顺序；(2) 长度偏见——倾向给长回答高分，需要用"长度归一化"评分；(3) 领域知识不足——GPT-4 可能不理解业务术语，打分不准。解法：在 judge prompt 中加入业务知识上下文，并用人工抽检校准（Cohen's Kappa >0.7）。
5️⃣ 避坑
- ❌ "评估集越大越好" → ✅ "200-300个任务足够。关键是覆盖度（每个维度30+任务）和难度分级，而非总量。"
- ❌ "用真实用户数据做评估集就行" → ✅ "真实数据有偏差（只覆盖常见场景），需要人工构造边界场景和对抗场景。"
6️⃣ 简历呼应
- 有评估集构建经验：从"业务评估集设计"切入，描述你构建的评估集规模、维度和效果
- 校招无项目：为一个简单 Agent（如天气查询）构建 50 题评估集，包含意图理解、工具调用、多轮对话维度
- "Evaluating LLM-based Agents: A Survey" (Wang et al., 2024) / "AgentBench: Evaluating LLMs as Agents" (Liu et al., 2023)