Wiki Notes

Appearance

04. Evals 与评测体系详解 ​

版本：v1.2

最后更新：2026-07-09

适用对象：准备把 LLM 应用从“能跑 Demo”推进到“能持续迭代、能回归、能上线、能解释退化原因”的产品、算法、平台与工程同学

1. 为什么 AI 系统必须做评测 ​

传统软件很多时候是：

  • 输入边界相对明确
  • 输出结果相对确定

生成式 AI 不是这样。即便同一个任务、同一个模型、同一个 Prompt，结果也可能因为：

  • 上下文变化
  • 检索内容变化
  • 工具状态变化
  • 模型版本变化
  • 采样参数变化

而发生明显波动。

所以评测的目标，不是证明系统永远正确，而是建立一套：

  • 可持续比较
  • 可解释退化
  • 可指导优化
  • 可作为发布门禁

的工程机制。

如果没有评测，团队常见处境会变成：

  • 改了 Prompt，不知道到底变好还是变差
  • 换了模型，只能靠主观感觉判断
  • 线上出问题，只能看报错率，解释不了质量退化
  • 版本迭代很多，但没有办法稳定回归

2. Eval 到底是什么 ​

可以把 Eval 理解为：

  • 用一组样本
  • 配一套明确标准
  • 通过规则、人工或 grader 打分
  • 比较不同版本结果
  • 再把结果回流到系统优化里

它评测的对象不只可以是模型本身，还可以是完整系统：

  • Prompt
  • Structured outputs
  • RAG
  • Tool calling
  • Agent
  • Workflow
  • Guardrails
  • 人机协同链路

所以更准确地说：

  • Eval 是 AI 系统的质量回路，而不是某个单点打分脚本

2.1 “评测”这个词在工程里经常指三种不同东西 ​

OpenAI 当前 Evaluation best practices 官方文档里给出的分类很有用。你看到“evals”这个词时，它可能指：

  1. 行业 benchmark 例如 MMLU 这类模型横向比较基准
  2. 通用分数或指标 例如 ROUGE、BERTScore、准确率这类数值
  3. 面向你自己业务实现的具体测试

真正对业务最有价值的，通常是第 3 类。

2.2 Eval 不是只看“最后答案对不对” ​

在 LLM 系统里，最后答案经常只是现象层。

真正需要评估的可能是：

  • 检索是否命中正确证据
  • Tool 是否选对
  • 参数是否填对
  • JSON 是否满足 schema
  • Agent 是否在该停的时候停下
  • 高风险动作是否进入审批

也就是说，成熟评测一定会从“最终结果”往“中间链路”下钻。

3. 先判断你的系统属于哪种架构，再决定 eval 怎么做 ​

OpenAI 当前 Evaluation best practices 官方文档明确建议，先识别系统里“哪里开始出现非确定性”，再决定评测点。一个很实用的分法是四类：

  1. Single-turn model interaction
  2. Workflow
  3. Single-agent
  4. Multi-agent

3.1 单轮模型调用 ​

典型特征：

  • 输入一次
  • 输出一次
  • 中间没有复杂状态和外部工具

评测重点通常是：

  • 输出质量
  • 结构化稳定性
  • 风格约束
  • 安全约束

3.2 Workflow ​

典型特征：

  • 多步骤串联
  • 某些步骤是固定逻辑
  • 某些步骤调用模型

评测重点通常是：

  • 每个节点的局部正确率
  • 节点间衔接是否稳定
  • 哪个节点引入退化

3.3 单 Agent ​

典型特征：

  • 会规划
  • 会调用工具
  • 会根据上下文继续多轮执行

评测重点通常是：

  • 任务完成率
  • Tool 选择和参数正确率
  • 回合控制
  • 停止条件
  • 人工接管率

3.4 多 Agent ​

典型特征：

  • specialist 分工
  • handoff
  • 工具面和权限面不同

评测重点通常是：

  • handoff 是否合理
  • 路由是否稳定
  • specialist 是否各自完成边界内职责
  • 多 agent 协作是否真的比单 agent 更好

4. 一个完整评测体系通常分四层 ​

一个成熟评测体系，通常至少由四层组成。

4.1 样本层 ​

回答：

  • 用哪些输入来测
  • 这些样本代表哪些业务场景

4.2 标准层 ​

回答：

  • 什么叫通过
  • 什么叫退化
  • 哪些错误不可接受

4.3 打分层 ​

回答：

  • 用规则判断
  • 用人工判断
  • 还是用 grader 模型判断

4.4 决策层 ​

回答：

  • 这次结果能不能上线
  • 哪类退化必须拦截
  • 哪些样本要回流成新的回归集

如果只做前两层，没有形成上线决策，评测还停留在“看报告”。

如果只做打分，没有高质量样本和标准，打分也不可靠。

5. OpenAI 2026 年的评测产品心智：Datasets、Evals、Traces、Agent evals ​

这一部分特别需要按当前时间理解。

根据 OpenAI 当前官方资料，在 2026-07-09 可访问状态下：

  • Datasets 适合更轻量、更快开始的评测构建
  • Evals 仍然可用，但已经进入弃用迁移阶段
  • Trace grading 和 Evaluate agent workflows 更适合 agent / workflow 级问题

5.1 先说最重要的时间线 ​

根据 OpenAI 官方 Deprecations 页面：

  • 2026-06-03：Evals 平台宣布弃用
  • 2026-10-31：现有 Evals 变为只读
  • 2026-11-30：Evals dashboard 和 API 计划关闭

这意味着你今天还可以参考和使用这套能力，但不能再把它当成长期唯一依赖。

5.2 如果你是新团队，官方现在更推荐从 Datasets 起步 ​

OpenAI 当前 Working with evals 和 Getting started with datasets 官方文档都在强调：

  • 如果你是刚开始做评测
  • 或者想更迭代式地尝试

可以优先从 Datasets 开始。

它更适合：

  • 快速组织样本
  • 尝试 Prompt 或模型变更
  • 用较轻的成本搭建评测起点

5.3 如果你需要大规模、程序化、外部模型比较，Evals 仍然有现实价值 ​

虽然 Evals 处于弃用阶段，但在过渡窗口里它仍然适合这些事情：

  • 通过 API 程序化运行
  • 批量执行
  • 跑外部模型对比
  • 用 grading 配置做系统化比较

工程上更稳的理解通常是：

  • Datasets 更适合起步和快速迭代
  • Evals 更适合程序化运行和大规模实验
  • Trace grading 更适合 agent/workflow 问题定位

5.4 Agent 系统不要只看 final answer，要尽快上 traces ​

OpenAI 当前 Evaluate agent workflows 和 Trace grading 官方文档给出的结论很明确：

  • Trace grading 是定位 workflow 级问题最快的方法

Trace 记录的是：

  • 模型调用
  • 工具调用
  • guardrails
  • handoffs
  • 决策路径

它不是只看“最后答得像不像”，而是直接看“系统一路怎么走到这里”。

6. Evals 在 LLM 系统里到底评什么 ​

评测维度通常不是单一总分，而是一组多目标组合。

常见维度包括：

  • 正确性
  • 完整性
  • 一致性
  • 结构化输出合法性
  • 引用准确性
  • 安全性
  • 成本
  • 延迟

不同系统的重点不同：

  • 分类系统更看准确率、召回率、误判率
  • RAG 更看证据覆盖、引用正确率、回答与证据一致性
  • Agent 更看任务完成率、工具调用正确率、人工接管率
  • Structured extraction 更看字段齐全率、枚举合法率、格式有效率

所以评测设计第一步不是问“总分怎么算”，而是先问：

  • 这条业务最怕哪类错

7. 离线评测是起点，不是终点 ​

离线评测的优点很明显：

  • 可重复
  • 成本可控
  • 适合回归
  • 适合做版本间对比

但离线评测天然有边界：

  • 样本永远不可能覆盖全部线上分布
  • 用户行为会变化
  • 知识库会变化
  • 工具、策略、模型会持续变化

因此更现实的体系通常是：

  • 离线评测做门禁
  • 在线观测做验证
  • 线上失败样本回流补充离线集

7.1 线上失败不回流，离线集迟早会失真 ​

这是很多团队一开始最容易忽略的一点。

如果线上真实失败样本从来不回流，离线评测集就会越来越像：

  • 老版本问题集
  • 人工想象场景集

而不再像真实生产分布。

8. 最小可行评测闭环该怎么搭 ​

对多数团队来说，起步并不需要先上复杂平台。更推荐先把这个最小飞轮跑通：

  1. 收集代表性样本
  2. 为每类样本定义成功标准
  3. 跑当前系统，保留输入、输出和关键中间证据
  4. 用规则、人工或 grader 打分
  5. 分类失败原因
  6. 修改系统
  7. 对同一批样本再次运行并比较

只要这套闭环能持续跑，你就已经开始做真正的 Eval 了。

8.1 最小闭环的关键不在平台，而在可重复性 ​

你至少要保证：

  • 同一批样本能重复跑
  • 同一套标准能重复打分
  • 同一版本结果能被保存和比较

否则“评测”很快会退化成：

  • 看几条日志
  • 手工试一试
  • 大家感觉还可以

9. 样本集不是越大越好，而是越代表越好 ​

一个可用的评测集，至少要覆盖三类样本：

9.1 正常样本 ​

代表主流业务分布，用来判断系统是否稳定满足日常质量。

9.2 边界样本 ​

代表长度极端、上下文不完整、输入模糊、脏数据等场景。

9.3 高风险失败样本 ​

代表过去真实翻车、投诉、事故、误判、越权或幻觉案例。

如果评测集只包含“最好回答”的题，结论通常会过度乐观。

9.4 还可以再加一类：迁移样本 ​

当你在做：

  • 模型切换
  • Prompt 大改
  • 工具协议迁移
  • 输出 schema 迁移

更稳的做法通常是单独维护一组：

  • 迁移敏感样本

它们不一定是最常见样本，但很适合暴露兼容性问题。

10. 样本版本化为什么很重要 ​

很多团队一开始做评测，最大问题不是不会打分，而是每次都悄悄改样本。

建议至少版本化这些对象：

  • 数据集本身
  • 样本标签
  • 评分规则
  • grader 提示词
  • 基线结果

否则你很容易陷入这种局面：

  • 分数看上去变高了
  • 但其实只是题库换了、grader 变了、标准松了

这也是为什么 baseline 和 benchmark 应该被当作正式资产治理。

10.1 Dataset version、grader version、baseline version 最好分开 ​

评测体系里至少有三套可能变动的东西：

  • 数据
  • 评分器
  • 被测系统基线

把这三者拆开版本化，你才能回答：

  • 这次上升到底是系统变好了
  • 还是 grader 变松了
  • 还是数据集变简单了

11. 成功标准必须从模糊口语变成可执行规则 ​

差的标准通常长这样：

  • 回答得不错
  • 看起来更自然
  • 好像更像人工

好的标准应该尽量可执行，例如：

  • JSON 是否合法
  • 字段是否齐全
  • 枚举值是否在允许集合内
  • 摘要是否覆盖至少 3 个关键点
  • 回答是否引用了检索证据
  • 是否出现明确禁止内容
  • 是否在预算内完成

标准越具体，系统越能被持续优化。

11.1 最好先写失败标准，再写成功标准 ​

这是很实用的一条经验。

很多时候团队对“优秀答案”分歧很大，但对“绝对不能接受的失败”反而更一致。

例如：

  • 编造引用
  • 漏关键字段
  • 误触发写工具
  • 越权回答

先把这些写清，评测门禁会更容易落地。

12. 三种最常见的打分方式 ​

12.1 规则打分 ​

适合：

  • JSON 合法性
  • 长度限制
  • 字段缺失
  • 枚举合法性
  • 正则或 schema 校验

优点：

  • 快
  • 便宜
  • 稳定

限制：

  • 很难覆盖复杂语义质量

12.2 人工打分 ​

适合：

  • 高价值样本
  • 模糊语义判断
  • 新任务冷启动
  • 校准 grader 标准

优点：

  • 质量高
  • 能发现意外问题

限制：

  • 慢
  • 贵
  • 扩展性差

12.3 模型 grader ​

适合：

  • 复杂语义判断
  • 大规模评测
  • 一致性要求较高的批量比较

优点：

  • 可扩展
  • 比纯人工更高效

限制：

  • grader 本身也会有误差
  • 需要定期和人工标注校准

最稳妥的策略通常不是三选一，而是组合使用。

13. OpenAI 当前官方 grader 能力，最该怎么理解 ​

OpenAI 当前 Graders 官方文档把 grader 类型写得比较清楚。常见类型包括：

  • string_check
  • text_similarity
  • score_model
  • python code execution

在更复杂场景里，还可以做：

  • multi grader 组合

13.1 string_check 最适合做强约束对齐 ​

适合：

  • 枚举值是否一致
  • 工具名是否一致
  • 参数字符串是否一致

尤其适合结构化输出和 tool calling 场景。

13.2 text_similarity 更像软匹配 ​

当你不要求逐字相等，而更关心语义接近时，这类 grader 更合适。

但也要小心：

  • 软匹配更容易放过错误细节

13.3 score_model 更适合复杂语义 rubric ​

当你想评估：

  • 回答是否完整
  • 是否忠于证据
  • 是否满足风格要求

这类复杂标准时，score model grader 更实用。

但它不是“万能裁判”，后面还需要人工校准。

13.4 Python grader 适合确定性程序校验 ​

当规则本身可以被程序明确表达时，Python grader 往往更可靠，例如：

  • 自定义计算逻辑
  • 数值比对
  • 组合规则

13.5 多 grader 组合通常比单总分更稳 ​

OpenAI 当前官方文档里明确支持多 grader 组合。

工程上这很有意义，因为你可以拆开看：

  • 结构化正确率
  • 语义质量
  • 工具参数正确率
  • 安全项

而不是只看一个平均分。

14. grader 不是“万能裁判” ​

OpenAI 官方关于 graders 和 evaluation best practices 的资料一直在强调一个现实：

  • grader 自己也会错
  • grader 提示词、rubric 和样本分布都会影响结果

因此生产上更稳妥的做法通常是：

  • 先用规则收掉结构性错误
  • 再用 grader 处理复杂语义判断
  • 最后抽样人工校验 grader 的一致性

14.1 grader 校准不是一次性动作 ​

随着这些东西变化：

  • 业务目标
  • 模型
  • Prompt
  • 数据分布

grader 本身也会漂移。

所以校准最好长期保留：

  • 人工 gold set
  • grader vs human 差异集
  • 定期抽检节奏

14.2 partial credit 比二元判断更适合复杂任务 ​

OpenAI 当前 grader 文档里也明确提到：

  • 有时给 partial credit 比只给 0/1 更有用

这尤其适合：

  • 多字段抽取
  • 多步骤推理
  • 多证据覆盖

因为复杂任务里“完全错”和“差一点对”对优化方向完全不同。

15. Tool calling、JSON 输出和结构化任务要单独评 ​

OpenAI 当前 grader 官方文档里专门解释了：

  • sample.output_json
  • sample.output_tools

这些变量如何被 grader 消费。

这对工程落地很重要，因为它说明：

  • 工具调用不是只能看最终自然语言
  • JSON 输出也不是只能看 output_text

15.1 Tool calling 评测通常至少拆成两层 ​

一个很常见、也很稳的做法是分别评：

  • 工具名是否正确
  • 参数是否正确

因为这两类错误的根因通常不同：

  • 工具名错更像路由问题
  • 参数错更像 schema、Prompt 或上下文问题

15.2 JSON 输出不要只看“能 parse” ​

结构化输出至少要继续检查：

  • 字段齐全率
  • 枚举合法率
  • required 字段命中率
  • 值域是否合理

15.3 Tool 和 JSON 评测非常适合规则 + grader 组合 ​

例如：

  • 规则层检查 schema、字段、枚举
  • grader 层检查语义是否符合业务预期

这种组合比只看文本相似度稳定很多。

16. 一个成熟评测体系会把失败样本做分类 ​

失败样本不是只拿来算分，更重要的是拿来定位优化方向。

建议至少按这些维度分类：

  • Prompt 设计问题
  • 上下文装配问题
  • 检索问题
  • 工具问题
  • 模型能力问题
  • 输出格式问题
  • 安全与护栏问题

一旦分桶清楚，后续优化会快很多，因为团队不再只是看到“错了”，而是知道“错在哪一层”。

16.1 失败分桶最好能反向映射 owner ​

更成熟的做法通常是让每个失败桶都能映射到：

  • Prompt owner
  • 检索 owner
  • 平台 owner
  • Agent owner
  • 安全 owner

这样评测报告才能真的推动行动，而不是停在观察层。

17. 为什么复杂系统要分层评测 ​

对于 Prompt、RAG、Agent 这类系统，只看最终答案通常不够。

17.1 Prompt 系统 ​

重点看：

  • 输出质量
  • 结构化稳定性
  • 拒答和约束执行

17.2 RAG 系统 ​

重点看：

  • 检索命中质量
  • rerank 是否把好证据顶上来
  • 生成是否忠于证据

17.3 Agent 系统 ​

重点看：

  • 任务完成率
  • 工具选择正确率
  • 参数填写正确率
  • 人工接管是否合理
  • 停止条件是否正常

分层评测的意义在于，系统退化时你能更快定位：

  • 是检索坏了
  • 是工具坏了
  • 还是最终生成坏了

18. Trace grading 和 Agent evals 为什么特别重要 ​

OpenAI 当前 Evaluate agent workflows 和 Trace grading 官方文档里给出的主线非常明确：

  • Start with traces when you are still debugging behavior

原因很简单：

  • final answer 只能告诉你结果不好
  • trace 才能告诉你是哪里开始走偏

18.1 什么是 trace ​

Trace 通常包含：

  • 模型调用
  • 工具调用
  • guardrails
  • handoffs
  • 状态推进
  • 最终输出

18.2 Trace grading 最适合回答什么问题 ​

例如：

  • planner 有没有反复重试无意义工具
  • handoff 是否发生在正确时机
  • 高风险动作前是否进入了审批
  • 哪一步开始引入幻觉或越权风险

18.3 Agent eval 不该只看 final answer ​

一个成熟 agent eval 至少应该同时看：

  • 终态结果
  • 路径质量
  • 工具质量
  • 审批与安全边界
  • 成本与延迟

19. 评测体系要同时看质量、成本和延迟 ​

很多团队会犯一个经典错误：

  • 只追求质量提升

但真实系统里，常见情况是：

  • 质量提升了一点
  • 延迟翻倍
  • 成本暴涨
  • 安全护栏变弱

所以建议至少保留这些指标组：

  • 质量分
  • 任务完成率
  • 延迟
  • token 成本
  • 工具调用次数
  • 安全失败率

否则上线决策会被“单一高分”误导。

20. 在线评测和离线评测怎么衔接 ​

更成熟的团队通常会形成这样一条链路：

text
线上请求
 -> 失败样本沉淀
 -> 标注与分桶
 -> 进入数据集新版本
 -> 离线回归评测
 -> 新版本比较
 -> 再上线观察

这条链路的关键不在平台，而在闭环。

如果线上失败样本从来不回流，离线集迟早会和真实业务脱节。

21. 什么时候应该上自动化评测门禁 ​

只要系统开始进入以下任一阶段，就应该尽快引入自动化门禁：

  • 产品持续迭代
  • 多人协作
  • 多模型切换
  • 上线前需要比较多个版本
  • 线上更新频率高

更具体地说，可以先从这些门禁开始：

  • 结构化输出必过
  • 高风险样本不允许退化
  • 核心业务任务完成率低于基线时禁止上线
  • 成本或延迟超过阈值时告警

21.1 门禁阈值不该只看一个平均分 ​

OpenAI 当前 Evaluation best practices 一直强调先定义目标、数据集和指标，再持续比较版本。

这放到发布门禁里，通常意味着不要只看一个总分，而要至少同时看：

  • 总体通过率
  • 高风险样本通过率
  • 结构化输出成功率
  • 成本和延迟是否越界

如果只是“平均分过线就发布”，很容易出现：

  • 高频正常样本把整体均值拉高
  • 边界样本和高风险样本已经明显退化

21.2 不同任务，门禁强度也应该不同 ​

更现实的做法通常是按任务分层：

  • 低风险问答：可以允许更高探索空间
  • 结构化抽取：更看字段正确率和格式稳定性
  • RAG 问答：同时看检索质量和答案忠实度
  • Agent / tool calling：更看工具正确率、参数正确率和安全边界

22. 2026 年做评测时，官方迁移趋势该怎么理解 ​

按 2026-07-09 可访问的 OpenAI 官方资料看，一个更现实的理解方式是：

  • 继续用 Evals 的思路和能力搭体系，但不要把新建设计完全绑死在旧平台对象上
  • 新团队优先学会用 datasets、traces、graders 和回流闭环
  • 老团队则要准备迁移窗口，特别是 2026-10-31 与 2026-11-30 这两个时间点

22.1 你真正该保留下来的不是某个产品名，而是这四类资产 ​

无论底层平台如何变化，真正应该长期保留的是：

  • 数据集
  • 评分 rubric
  • grader 配置
  • baseline 与回放证据

只要这些资产是版本化和可迁移的，平台变化不会把体系整体打散。

22.2 评测平台会迁移，但评测方法不会过时 ​

即便 Evals 平台进入弃用，以下方法论仍然有效：

  • 先定义目标
  • 设计样本集
  • 组合 evaluator
  • 做离线回归
  • 让线上失败回流
  • 用门禁控制发布

这才是评测体系真正的长期价值。

23. 一个更现实的建设顺序 ​

如果你现在要从零搭评测体系，一个很稳的顺序通常是：

  1. 先收 50 到 200 条有代表性的真实样本
  2. 定义最重要的 3 到 5 个指标
  3. 先做规则校验和少量人工校准
  4. 再引入 grader
  5. 建立样本版本和 baseline
  6. 接入线上失败回流
  7. 再做自动化门禁
  8. 最后再补 trace grading 和 agent eval 深度治理

这个顺序能避免一开始就被平台复杂度拖住。

24. 六个最常见的评测误区 ​

24.1 只看最终答案，不看中间链路 ​

结果是：

  • 退化原因永远很难定位

24.2 只看平均分，不看高风险样本 ​

结果是：

  • 真实事故样本被均值掩盖

24.3 数据集不版本化 ​

结果是：

  • 分数变化失去可解释性

24.4 把 grader 当绝对真理 ​

结果是：

  • 误把 grader 偏差当模型退化

24.5 线上失败不回流 ​

结果是：

  • 离线集越来越脱离真实生产

24.6 把评测当“发布前最后一关” ​

结果是：

  • 没有形成持续优化飞轮

25. 推荐搭配阅读 ​

26. 重点官方资源 ​

27. 一句话总结 ​

评测体系真正要解决的，不是“给模型打一个分”，而是把：

  • 数据集
  • rubric
  • grader
  • 版本比较
  • 发布门禁
  • 线上失败回流

连成一条可持续运行的工程闭环。