Demystifying evals for AI agents

[parallelarc]

Demystifying evals for AI agents

来源: Demystifying evals for AI agents | Anthropic Engineering

---

评估体系的核心概念

• 评估(Eval)：给AI输入，应用评分逻辑测量输出的测试系统
• 单轮评估：一次提示、一次响应、一次评分—适用于早期LLM测试
• 多轮评估：Agent跨越多个轮次调用工具、修改状态、适应中间结果
• Task（任务）：具有定义输入和成功标准的单个测试用例
• Trial（试验）：对任务的单次尝试—多次试验产生更一致的结果
• Grader（评分器）：对Agent性能某方面进行评分的逻辑
• Transcript（记录）：试验的完整记录—包含输出、工具调用、推理、中间结果
• Outcome（结果）：试验结束时环境的最终状态—区别于Agent声称的状态
• Evaluation Harness：端到端运行评估的基础设施
• Agent Harness：使模型能够作为Agent运行的系统（如Claude Code）
• Evaluation Suite：为测量特定能力而设计的任务集合

关键洞察：Agent评估的核心复杂性来自多轮交互—错误会传播和累积，且前沿模型可能找到超越静态评估限制的创造性解决方案

---

构建评估的时机与价值

• 早期构建：在原型阶段即可开始，20-50个简单任务即可起步
• 效应量原理：早期Agent开发的每个系统变更都有明显影响，小样本量足够检测
• 明确成功定义：评估迫使产品团队明确定义Agent的成功标准
• 避免反应式循环：无评估时团队陷入"等待投诉→手动重现→修复→祈祷无回归"的循环
• 加速模型采用：有评估的团队可在数天内确定新模型优势并升级，无评估团队需数周测试
• 免费获得基线：一旦建立评估，自动获得延迟、Token使用、每任务成本、错误率的跟踪基准
• 产品-研究沟通：评估成为产品与研究团队之间最高带宽的沟通渠道

关键洞察：评估的价值随时间复合—成本前期可见，收益后期累积，容易被低估

---

评分器类型与选择框架

代码评分器

• 适用场景：确定性测试、单元测试、静态分析、状态验证
• 优势：快速、廉价、客观、可重现、易于调试
• 局限：对不符合精确模式的有效变体脆弱、缺乏细微差别
• 方法：字符串匹配（精确/正则/模糊）、二元测试、Lint/类型/安全检查

模型评分器

• 适用场景：开放式任务、自由形式输出、需要细微差别的判断
• 优势：灵活、可扩展、捕捉细微差别、处理开放性输出
• 局限：非确定性、比代码昂贵、需要与人工评分器校准
• 方法：基于量表的评分、自然语言断言、成对比较、参考基准评估、多评委共识

人工评分器

• 适用场景：校准模型评分器、主观性强的任务、最终质量验证
• 优势：金标准质量、匹配专家用户判断
• 局限：昂贵、缓慢、需要大规模专家访问
• 方法：SME审查、众包判断、抽样检查、A/B测试

选择原则：代码评分器优先→模型评分器补充→人工评分器校准

---

不同Agent类型的评估策略

编程Agent

• 核心方法：确定性测试为主—单元测试通过即成功
• SWE-Bench Verified：从GitHub仓库获取issue，通过运行测试套件评分
• Terminal-Bench：测试端到端技术任务（如从源码构建Linux内核）
• 评分维度：测试通过性+代码质量规则+工具调用行为
• 关键实践：稳定测试环境+完善测试用例+生成代码的静态分析

对话Agent

• 核心挑战：交互质量本身是评估对象
• 多维成功：工单解决（状态检查）+<10轮对话（记录约束）+语气适当（LLM量表）
• τ-Bench/τ²-Bench：模拟多轮交互—一个模型扮演用户角色
• 评分方法：LLM量表评估任务完成+交互质量+第二LLM模拟用户
• 注意：许多任务有多种"正确"解决方案，避免刚性路径评分

研究Agent

• 核心挑战：质量只能相对于任务判断—"全面"、"有据"、"正确"标准因场景而异
• 评分组合：基础性检查（声明有来源支持）+覆盖检查（必须包含的关键事实）+来源质量检查
• BrowseComp：测试Agent能否在开放网络中找到"大海捞针"式答案
• 关键实践：LLM量表需频繁与专家人工判断校准
• 客观答案：对有客观正确答案的任务使用精确匹配

计算机使用Agent

• 评估环境：真实或沙箱环境中运行Agent，检查是否达到预期结果
• WebArena：基于浏览器的任务—URL和页面状态检查+后端状态验证
• OSWorld：完整操作系统控制—检查文件系统状态、应用配置、数据库内容、UI元素属性
• 效率权衡：DOM交互快但Token密集，截图交互慢但Token高效
• 实践案例：Claude for Chrome开发评估检查Agent是否选择正确工具

---

非确定性评估的度量指标

• pass@k：k次尝试中至少一次成功的概率
  • k增加时pass@k上升—更多射门机会提高至少一次成功几率
  • 适用场景：工具类Agent，一次成功即有价值
• pass^k：所有k次试验都成功的概率
  • k增加时pass^k下降—要求更多次一致成功是更高门槛
  • 计算：单次75%成功率，3次试验全部成功概率=0.75³≈42%
  • 适用场景：面向客户的Agent，用户期望每次都可靠
• 指标选择：根据产品需求选择—pass@k用于一次成功重要，pass^k用于一致性关键

关键洞察：k=1时两者相同（等于单次成功率）；k=10时两者讲述相反故事—pass@k接近100%而pass^k趋近0%

---

从零到一的评估构建路线图

收集初始任务

1. 从20-50个简单任务开始—团队误以为需要数百个任务而延迟构建
2. 已有手动检查优先：开发中手动验证的行为+最终用户尝试的常见任务
3. 从失败收集：生产环境中查看Bug跟踪器和支持队列，将用户报告的失败转为测试用例
4. 明确任务规格：两个领域专家应能独立达成相同通过/失败判断
5. 创建参考解决方案：证明任务可解+验证评分器正确配置

构建平衡问题集

• 双向测试：同时测试行为应该发生和不应该发生的场景
• 避免类别不平衡：单向评估导致单向优化
• 实战案例：Claude.ai网络搜索评估—应搜索查询（如天气）+不应搜索查询（如"谁创立了Apple"）
• 避免模糊规格：评分器检查的所有内容应从任务描述中清晰可见

设计评估Harness与评分器

• 环境隔离：每次试验从干净环境开始—避免共享状态导致的相关失败
• 生产一致性：评估中的Agent功能应与生产环境中的Agent大致相同
• 评分稳定：环境本身不应引入额外噪声
• 优先结果评分：评估Agent产出了什么，而非采取的路径—Agent经常找到评估设计者未预期的有效方法
• 部分信用：对多组件任务建立部分信用机制
• LLM校准：LLM评委应与专家人工判断密切校准

长期维护与使用

• 阅读记录：投资工具查看评估记录，定期阅读以验证评分器工作良好
• 公平失败：失败应显得公平—清楚Agent哪里出错及为何出错
• 监控饱和：100%通过率的评估只跟踪回归，不提供改进信号
• 持续迭代：评估套件是需要持续关注的活体工件
• 领域专家贡献：最接近产品要求和用户的人最适合定义成功

---

评估与其他方法的协同

方法	最佳使用阶段	核心价值
自动化评估	发布前/CI/CD	无用户影响快速迭代、每次提交运行、大规模测试场景
生产监控	发布后	揭示真实用户行为、捕捉合成评估遗漏的问题
A/B测试	有足够流量时	衡量真实用户结果（留存、任务完成）、控制混杂因素
用户反馈	持续	揭示未预期问题、附带真实用户案例
手动记录审查	持续	建立失败模式直觉、捕捉自动化检查遗漏的微妙质量问题
系统性人工研究	校准阶段	LLM评分器校准、主观输出评估

瑞士奶酪模型：没有单一评估层能捕获所有问题，多层结合使通过一层的失败被另一层捕获

---

评估框架选择

• Harbor：容器化环境运行Agent，跨云提供商大规模运行试验，标准化任务和评分器格式
• Promptfoo：轻量灵活开源框架，声明式YAML配置，断言类型从字符串匹配到LLM量表
• Braintrust：离线评估与生产可观测性结合的平台，autoevals库包含预建评分器
• LangSmith：跟踪、离线/在线评估、数据集管理，与LangChain生态系统紧密集成
• Langfuse：自托管开源替代方案，适合有数据驻留要求的团队

框架建议：快速选择适合工作流程的框架，将精力投入迭代高质量测试用例和评分器

---

核心决策要点

• 评估是核心组件而非事后补充：投资早期开发加速，投资延迟导致反应式循环
• 小样本起步：20-50个简单任务足以开始，效应量原理支持早期小样本量
• 明确成功标准：评估是产品需求的压力测试，定义评估任务是验证要求是否足够具体的最佳方式
• 阅读记录：不阅读记录无法知道评分器是否工作良好，这是Agent开发的关键技能
• 组合评分器：代码评分器优先，模型评分器灵活补充，人工评分器校准
• 评估驱动开发：先构建评估定义计划能力，然后迭代直到Agent表现良好
• 监控饱和：接近饱和的评估需要扩展—高通过率的能力评估可"毕业"成为回归套件
• 多方法验证：自动化评估+生产监控+定期人工审查提供最完整的图景