AI Evals 阅读笔记

读《Demystifying evals for AI agents》

https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents

让 agents 牛逼的能力，同时也让评测变得复杂：自主性；智力；灵活度。（找维度）

These same capabilities that make AI agents useful—autonomy, intelligence, and flexibility—also make them harder to evaluate.

  • 单轮评估（Single-turn evaluations） vs 多轮评估（multi-turn evaluations）：后者逐渐常见了起来。
  • LLM 评估 vs Agent 评估：Agent 评估更复杂，agent 会调用工具、修改状态等。

几个常见的核心概念

  1. 任务（task）（a.k.a problem or test case）：定义输入和成功标准。
  2. 每一轮尝试叫做 trial。由于每一轮的结果都不一样，会执行多轮。
  3. 一个评分器（grader），一个任务可以有多个评分器，每个包晗多个断言。
  4. 一个抄本（transcript，也叫做 trace 或者 trajectory）是一个完整的 trial 记录。
  5. 结果（outcome） 是 trial 的最终结果。比如是否真的定了一张机票，而不是 AI 说自己定了一张。
  6. 评测框架（evaluation harness）是跑评测的基建。提供指令和工具，并负责记录结果等。

  7. 智能体工具（agent harness，或者叫做脚手架）。好奇和 agent 有啥区别？文章里面举了一个例子

    For example, Claude Code is a flexible agent harness, and we used its core primitives through the Agent SDK to build our long-running agent harness.

  8. 一个评测集（evaluation suite）是一系列 task 的集合。

有一个重点是，grader 的输入既包含 outcome，也包含 trajectory。

和数据库测试也没啥大的区别 :)

接着讲为什么需要评测。

从一个测试的角度，我觉得这个章节的前半部分在讲废话。中间往后有点有意思的东西。

说 Claude Code 一开始就遇到了“用户反馈问题 -> 修复 -> 其它地方又有问题”的这么一个循环。然后它们开始给局部功能加评测， 接着就给更大的范围加评测，比如 over-engineering。结合 “product monitoring”、“A/B tests”、“user research” 等等手段来保障持续迭代。然后说其它 AI 团队也搞了 evals，或早或晚。里面还提到几个评价维度： latency, token usage, cost per task, and error rates。

接着讲怎样评测。

上来就有个结论：说各类 agent 的评测方式差不多，并且不需要从0造轮子。先介绍 graders。

三类 graders：code-based，model-based，human。有效的评估就是为特定任务选择合适的评分器。 分别介绍了每类 grader 的常见方法、优劣势。很有用，可惜我暂时看不懂。

能力评测和回归评测：前者讲的能不能；后者讲的是能的基础上，好不好。

评估 coding agents：说白了，就是设计 task 和 grader。

评估 conversational agents： 一个不一样的挑战：the quality of the interaction itself is part of what you’re evaluating. 沟通过程和结果是否达成都很重要。说这里面通常要引入一个 LLM 来模拟用户。

评估 research agents： 评估维度有：“comprehensive,” “well-sourced,” or even “correct”。 难点：调研是否全面、不同的引用构建出来的基础事实不一样。

评估 Computer use agents：。。。

不确定 agent 评测的思考。 两个指标：pass@k 评估多少次成功1次。pass^k 评估k次都成功的概率。

从0到1构建牛逼评测的路线图

  1. 收集任务
    1. 尽可能早的构建数据集。早期直接把产品需求转换成用例即可。而后期则需要从线上逆向场景。
    2. 从手动测试过的开始。
    3. 编写有参考答案、没有歧义的任务
    4. 构建均衡的问题集：比如正反向都要断言。
  2. 设计 eval harness 和 graders
    1. 健壮的 eval harness 和稳定的测试环境。harness 要能模拟生产环境。还有评测环境隔离等问题。
    2. Grader 的设计要深思熟虑
      1. 评分器选择，确定性>LLM>人工。
      2. ‘过度’检查过程有可能破坏 AI 的创造力。
      3. 对于涉及多组件的任务，设置“部分得分机制”。
      4. 模型评分通常需要反复迭代才能验证准确性。要与人类专家密切校准；可以使用不同的LLM。
      5. 对 task 和 grader 要细心 review。一些评测会由于 harness 限制、或者评测设计不够合理，而导致分数不反应实际情况。
  3. 长期维护和使用 eval
    1. 人肉检查 transcripts
    2. 检测评估能力饱和度（比如 swebench 80% 通过率时，这个分数本身就不太容易变化了，但并不代表没有进步）
    3. 保持评测集的健康度：分工明确，infra + domain experts。推荐 eval-driven development。 让了解用户的人（产品经理，客户成功，销售）来贡献 eval task。

不仅要有评测，还要有监控、A/B测试、人工审核过程、系统性人工评测。

读后感

写得和论文一样，算是深入浅出。能感觉到 anthropic 这公司的工程搞得挺扎实的，工程文化应该不错。 最想记录的，还是从一个测试角度，来看这个 AI evals，看看异同点吧

  • 架构上：基本相似，由 test infra + test case 组成。不过这里提到说 test case 可以由产品、SA等人来产生。
    • test infra
      • Evaluation harness + agent harness 基本对应“测试框架”。
      • 评测环境：对应环境准备、产品部署、产品监控等一套业务逻辑绑定较弱的基建。
    • test case
      • task + grader + metrics：本质也就是用例。相当于场景+断言。
        • grader：这里和数据库测试也很像，需要不同的 checker。不同的在于 LLM grader 是这里重要的一环。
          • 面向 transcript 的 grader：有点像白盒观测点。
          • 面相最终结果的 grader：黑盒观测点。
        • metrics：grader 更像功能测试，metrics 会辅助评估性能、稳定性等。

Updated:

Comments