怎么设计 eval

如果你指的是 LLM / Agent 的 eval，我建议从“什么叫把事办成了”倒推，而不是先选评测框架。 拿“客服退款 Agent”举例：用户说“帮我退掉昨天买的耳机”。不能只检查回复是不是“退款成功”，而要检查订单有没有选对、退款规则是否满足、需要确认时有没有确认，以及系统里是否真的生成退款记录。话说得漂亮，不代表任务完成了。 一套能落地的设计可以这样做。 第一步：明确评测对象和成功条件 你是测模型的某个能力，还是测包含 prompt、检索、工具、记忆在内的整个产品？先固定边界。 对退款任务，成功条件可以是：退款对象正确、金额正确、没有重复退款、没有越权操作。表达是否清楚可以另外评分，但不能用“语气很好”抵消“退错订单”。 第二步：用真实场景构造测试集 起步可以先做几十条高质量用例，不必一上来攒几千条。这是起步建议，不是统一标准。 除了正常退款，还要覆盖：有两个同名订单、订单已退款、用户没权限、工具超时、多轮对话里用户改了主意。也要覆盖“不该退款”和“应该退款”，否则一个永远拒绝的 Agent 可能看起来很安全，却毫无用处。 每条用例至少记录：用户输入、必要的历史上下文、环境初始状态、可用工具、预期结果、禁止发生的行为。不一定要有唯一的标准回复。 第三步：不同指标用不同裁判 能程序判定的就用程序：退款金额是否一致、数据库状态是否正确、是否调用禁用工具、输出格式是否符合要求。 语义质量再用 LLM-as-Judge：解释是否准确、是否遗漏关键条件、回复是否切题。评分规则要具体，比如“是否说明退款到账时间”，不要只写“给回答质量打个分”。 人工负责抽检和校准裁判。先让人标一批答案，再检查模型裁判是否与人一致；对比两个版本时隐藏版本信息、交换答案顺序，减少位置偏差。Judge 自己也需要评测。 第四步：同时看最终结果和执行过程 结果回答“做成了吗”，过程帮助定位“为什么失败”。 例如退款没完成，可能是找错订单、工具参数错，也可能是工具本身故障。记录工具调用、返回结果、可观察的中间输出、耗时和成本，才有办法定位。 但不要把某一条工具调用顺序当唯一标准路径：只要满足约束，合理的替代路径也应通过。 第五步：让新旧版本在可比条件下跑 固定测试数据和环境，每次运行重置状态，避免上一次退款影响下一次。关键用例重复运行，别凭一次成功就断言能力提升。 报告里分别看任务成功率、违规率、各类场景表现、延迟和成本，别全压成一个平均分。正常退款进步了，但越权退款变多了，不能算整体变好。 保留一部分不参与日常调 prompt 的测试用例，避免只是在“针对考题优化”。 第六步：把 eval 接进发布流程 每次改模型、prompt、检索或工具逻辑，都跑回归；明确哪些失败必须阻止上线。上线后继续监控、抽样人工检查，必要时做 A/B 测试，并把真实失败案例脱敏后补进测试集。 最小闭环就是：真实任务 → 明确成功条件 → 跑 Agent → 检查结果与约束 → 对比版本 → 把失败变成回归用例。先把这个闭环跑通，比先搭一个复杂评测平台更重要。 参考 Anthropic 的 Agent eval 工程文章： https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents 你具体是在做 RAG 问答、代码 Agent，还是会调用工具执行任务的助手？这几类的成功条件和判分方式差别挺大。