Wiki Notes

Appearance

评测基准与基线管理专题 ​

版本：v1.4

最后更新：2026-07-09

适用对象：正在做模型升级、Prompt 迭代、RAG 优化、Agent 工作流发布和多版本比较，需要把“这次好像更好了”变成“可以稳定比较”的产品、评测与平台同学

很多团队开始做 eval 之后，会很快遇到第二个问题：

  • 这次分数比上次高，到底算不算真的进步

如果没有基准和基线，评测就很容易变成：

  • 每次都在看一个孤立分数
  • 无法判断退化
  • 无法确认提升是否可靠
  • 无法知道是能力变强了，还是尺子换了

这篇专题真正关心的是：

  • 如何建立评测基准
  • 如何维护可比较的基线
  • 如何避免“看似进步，实际漂移”

根据 2026-07-09 可访问的 OpenAI Evaluation best practices / Evaluate agent workflows / Trace grading / Production best practices 与 Google SRE 关于 SLO 和基线决策的资料，一个很重要的共识是：

评测不是一次性跑分，基准是尺子，基线是当前参考系，两者都稳定，版本比较才有意义。

1. 先分清评测基准和基线 ​

可以先做一个简单但实用的区分：

  • 评测基准：一组固定的任务、样本、评分规则和运行方式
  • 基线：当前拿来比较的参考结果、参考版本或参考系统

例如：

  • 一套客服 eval 数据集，是评测基准的一部分
  • 当前线上版本在这套数据集上的结果，是一个基线

如果团队只有“数据集”没有“基线”，你只能跑分，不能比较。

如果只有“基线分数”没有“稳定基准”，你也不知道这条分数是否可靠。

2. 为什么 AI 系统尤其需要基线管理 ​

OpenAI 当前 Evaluation best practices、Evaluate agent workflows 都在强调：

  • 应尽早写 eval
  • 要用和生产接近的数据
  • 要持续记录并比较版本变化

这在 AI 系统里尤其关键，因为变化来源特别多：

  • 模型版本变化
  • prompt 改动
  • 检索配置变化
  • 工具 schema 变化
  • 安全规则变化
  • grader / rubric 变化

所以如果没有基线，你很难回答：

  • 这次到底退没退
  • 提升是全面提升，还是只是某个子场景提升
  • 成本和延迟是否为了质量被打穿

3. 一个好的评测基准到底要解决什么问题 ​

好的评测基准，至少要回答四件事：

  1. 测的是谁。
  2. 测的是哪些场景。
  3. 哪些场景最重要。
  4. 哪些场景最危险。

如果基准和真实业务不匹配，再严谨的比较也会失真。

3.1 最常见的基准失真 ​

  • Demo 样本过多
  • 高风险场景过少
  • 样本都太干净
  • 只测平均情况，不测极端样本

这会导致一种典型幻觉：

  • 线下总分提升了，但线上关键任务更差了

4. 更实用的基准分层方式 ​

更适合落地的方式通常不是一个总基准，而是分层基准。

4.1 核心业务基准 ​

关注：

  • 最常见、最有价值的请求

4.2 高风险基准 ​

关注：

  • 容易造成错误动作、越权、误审、误判的请求

4.3 回归故障基准 ​

关注：

  • 历史上出过事故或已知脆弱的 case

4.4 对抗或红队基准 ​

关注：

  • prompt injection
  • 越权尝试
  • 规避 guardrails 的输入

4.5 成本与性能基准 ​

关注：

  • token
  • latency
  • cache hit
  • retry

如果只保留一个总分，团队几乎一定会被“平均数”误导。

5. 什么才是“好基线” ​

好基线通常满足：

  • 稳定
  • 可复现
  • 记录完整
  • 代表当前可接受水平

基线不一定是“最强版本”，但一定要是：

  • 清楚知道它是谁、在什么条件下跑出来、为什么被选来做比较对象。

6. 一条基线至少要记录哪些内容 ​

如果你只记录：

  • “这个版本 82 分”

后面几乎一定会出问题。

建议至少记录：

  • 模型版本
  • prompt 版本
  • workflow 版本
  • tool 配置
  • 检索配置
  • 数据集版本
  • grader / rubric 版本
  • 运行日期

这样当分数变化时，团队才知道到底哪一层变了。

6.1 基线对象最好同时带上“冻结口径”和“生效范围” ​

很多团队虽然记录了模型、Prompt、数据集版本，但还是会踩一个坑：

  • 不知道这条基线到底在哪些环境和哪些流量范围内有效

更稳的基线对象通常还应至少带上：

  • frozen window
  • applicable traffic
  • tenant scope
  • locale / region
  • tool availability

例如同一套 Agent：

  • 在英文客服流量上可能是一条稳定基线
  • 但在中文长尾流量上未必成立

同一套检索系统：

  • 在 SaaS 标准版租户上可能过线
  • 但在企业私有知识库租户上可能还没过线

如果不记录生效范围，后面就很容易出现：

  • 把一条“局部有效”的基线误当成“全局可用”的基线

6.2 更成熟的基线对象最好保留“比较策略”，不只是结果 ​

很多团队会把基线理解成：

  • 一组结果快照

但更成熟的做法通常会把“怎么比较”也固化下来。

例如：

  • 是和上一版本做绝对分数比较
  • 还是做 pairwise 对比
  • 是看平均分
  • 还是看关键桶最低分
  • 是按总量通过
  • 还是要求高风险桶零退化

OpenAI 当前 Evaluation best practices 和 Evaluate agent workflows 的实践心智都在强调：

  • 评测方法本身也要稳定

否则就算结果表看起来完整，你也可能每次都在换比较方式。

7. 多指标系统不要只保留一个总分 ​

OpenAI 当前 eval 文档里反复强调测试标准要明确，而在真实系统里，“标准明确”往往就意味着：

  • 不能只看一个总分

更实用的做法通常是同时记录：

  • 质量分
  • 安全分
  • 成本分
  • 延迟分
  • 任务完成率

因为一个版本很常见的真实变化是：

  • 质量提升了
  • 但成本和延迟一起暴涨

如果只看质量，决策会失真。

8. 怎么判断一次变化是否值得上线 ​

更稳妥的判断通常至少包含四个问题：

  1. 是否超过当前基线
  2. 是否在关键子场景上没有退化
  3. 是否没有打穿护栏指标
  4. 是否成本和延迟仍在可接受范围

8.1 为什么“总分高一点”通常不够 ​

因为很多系统真正的风险不在平均分，而在：

  • 一个高风险桶退化
  • 一个关键工具调用桶退化
  • 一个高价值租户场景退化

这就是为什么基线必须是分层的。

8.2 更适合上线判断的通常不是“单阈值”，而是“通过矩阵” ​

很多团队会把上线标准写成一句：

  • “总分提升 2 分即可上线”

这通常太粗。

更稳的上线判断更像一张通过矩阵：

维度通过条件
核心业务桶明显超过旧基线
高风险桶不允许退化
回归桶历史事故样例必须全绿
成本不得超预算阈值
延迟不得打穿 P95 / P99 门槛
轨迹质量tool / handoff / retry 不得异常膨胀

这样做的价值在于：

  • 团队不会被单一高分误导
  • 每个角色都知道自己关心哪一格
  • 发布门禁能直接和真实风险对齐

8.3 pairwise 基线特别适合处理“主观质量差一点点但很关键”的系统 ​

有些系统只看绝对分数很难判断：

  • 哪个回答更自然
  • 哪个总结更贴近用户意图
  • 哪个 agent 过程虽然都成功，但一个明显更稳

这时更稳的做法通常是补一层 pairwise 比较：

  • 新版本 vs 旧基线
  • 人审或 LLM grader 判断谁更好
  • 对平局、轻微差异和明显退化分别记账

尤其在：

  • 写作
  • 总结
  • 对话
  • 多步 agent 轨迹

这类场景里，pairwise 基线往往比孤立分数更贴近真实感受。

9. 基线漂移为什么危险 ​

如果团队每次都悄悄更新：

  • 数据集
  • 评分器
  • 模型版本
  • prompt

却不留记录，就会出现：

  • 历史分数无法比较
  • 团队以为进步了，其实只是尺子换了

这类问题比“分数低一点”更危险，因为它会直接误导版本决策。

一句话理解：

  • 没有版本化的基线，不是基线，只是瞬时快照。

10. 基线应该怎么升级 ​

基线不是永远不动，但更新要有条件。

10.1 更适合更新基线的情况 ​

  • 新版本已稳定上线
  • 核心业务与高风险桶都通过
  • 成本和延迟可接受
  • 旧基线已经不再代表当前真实系统

10.2 不适合随便更新的情况 ​

  • 只是为了让图表更好看
  • 版本尚未稳定
  • 高风险场景还没复核

10.3 更好的更新流程 ​

  1. 先保留旧基线。
  2. 明确新基线的生效日期和原因。
  3. 记录此次升级关联的版本与评测结果。
  4. 在一段时间内允许回看旧基线。

11. 为什么 grader 和 rubric 也要版本化 ​

OpenAI Evaluate agent workflows 明确把：

  • traces
  • graders
  • datasets
  • eval runs

作为一整套评测对象。

这意味着很多团队容易忽略的一点是：

  • grader 自己也会变

如果 grader 或 rubric 变化了，却不记录：

  • 你可能不是模型变强了
  • 而是评分器放宽了

11.1 grader 变更最好单独跑“grader baseline”，不要和模型升级混在一轮 ​

很多团队会同时改：

  • 模型
  • Prompt
  • grader

然后一起跑一次 eval。

这会让你几乎无法判断：

  • 到底是谁导致了变化

更稳的做法通常是：

  1. 先冻结模型和样本，只比较 grader 新旧版本。
  2. 确认 grader 输出差异、稳定性和偏好变化。
  3. 只有 grader 自己过线后，再拿它评模型升级。

这一步的价值非常大，因为很多“模型突然大幅提升”的喜讯，本质上可能只是：

  • grader 更宽松了

11.2 rubric 最好显式区分“可退让项”和“不可退让项” ​

很多评分 rubric 写得过于平均化，最后会出现：

  • 一个高风险错误被几个小优点抵消

更稳的 rubric 通常会显式区分两类项：

  • non-negotiable checks
  • quality preference checks

前者例如：

  • 是否越权
  • 是否捏造引用
  • 是否错误执行高风险动作

后者例如：

  • 语言是否更自然
  • 表达是否更简洁
  • 结构是否更清晰

这样做的价值在于：

  • 高风险红线不会被总分平均掉

12. 为什么回归基准特别重要 ​

很多基线退化不是新场景带来的，而是历史问题又回来了。

所以比总分更重要的一类基准往往是：

  • 历史事故样例
  • 历史高投诉样例
  • 历史越权与风险样例

这类回归基准对发布门禁特别有价值。

13. 为什么基准一定要和生产数据靠近 ​

OpenAI 当前 eval best practices 反复强调：

  • 用生产数据、日志、用户反馈和边界样例不断扩展评测集

这给基准管理一个很直接的要求：

  • 样本不是越漂亮越好，而是越贴近真实越有用

否则你测出来的很可能只是：

  • 模型对理想题目的表现

13.1 样本补集最好按“新增故障来源”而不是“想到什么加什么” ​

很多评测集越做越乱，不是因为样本太多，而是因为扩充方式太随意：

  • 看到一个坏 case 就直接丢进去
  • 没有标记它属于哪类故障
  • 也没有说明它为什么进入基准

更稳的扩充方式通常是按故障来源分桶补样本，例如：

  • 新模型升级引入的问题
  • 新 Prompt 策略引入的问题
  • 新工具接入引入的问题
  • 新租户 / 新语言 / 新渠道引入的问题
  • 线上投诉和人工复审发现的问题

这样你的基准集才会越来越像：

  • 一套“真实失效地图”

而不是：

  • 一堆零散 case 的堆积

14. 为什么基线不能只在评测团队内部维护 ​

基线看起来像评测对象，但实际会影响：

  • 产品是否上线
  • 平台是否切模型
  • 运营是否放量
  • 安全是否批准

所以更成熟的做法通常是：

  • 评测团队负责维护
  • 但基线升级要和产品、平台、安全一起对齐

15. 一个更可执行的基线对象模板 ​

建议一条基线至少能回答：

  • 它属于哪个场景
  • 它对应哪个版本
  • 用哪套样本跑的
  • 用哪套评分逻辑评的
  • 结果能不能作为上线判断依据

如果这些答不上来，这条基线就不够成熟。

16. 常见反模式 ​

  • 每次只看新的分数，不看旧基线
  • 更新 grader 却不记版本
  • 用平均值替代高风险场景结果
  • 样本全是漂亮 demo，不贴近生产
  • 基线升级过于随意
  • 只有“最好成绩”，没有“当前稳定参考”

17. 一个最小但能落地的基线方案 ​

如果团队现在基线管理还比较弱，建议至少先做到下面这些事：

  1. 定义核心业务、高风险、回归三层基准。
  2. 为每条基线记录模型、Prompt、workflow、tool、retrieval、grader 版本。
  3. 保留旧基线，不要覆盖式更新。
  4. 基线升级必须附带理由和时间点。
  5. 在发布前同时看总分、关键桶、护栏指标。

18. 基线冻结窗口、灰度观察与基线切换 ​

很多团队的问题不是“不做基线”，而是：

  • 发布前还在改数据集
  • 灰度期间还在改 grader
  • 一边观察线上，一边偷偷替换参考尺子

这样最后即使分数好看，也很难证明：

  • 这次版本是真的更稳了

更稳妥的做法通常是把一次基线比较拆成三段：

  1. 冻结窗口：发布前固定数据集、grader、样本桶和护栏指标。
  2. 灰度观察：先让新版本在小流量或 shadow 结果上对照旧基线。
  3. 正式切换：确认关键桶、高风险桶、成本和延迟都过线后，再提升为新基线。

18.1 为什么冻结窗口很重要 ​

因为 AI 系统里最容易变的不只是模型，还有：

  • Prompt
  • 路由策略
  • 检索配置
  • grader
  • 样本集

如果这些对象在一轮发布里同时变化，却没有冻结比较口径，基线就很容易从“参考尺子”退化成“动态截图”。

18.2 哪些信号更适合拿来决定是否切换新基线 ​

  • 核心业务桶是否稳定超过旧基线
  • 高风险桶是否没有退化
  • 成本 / 延迟是否没有打穿门槛
  • 灰度与 shadow 观察是否没有出现新型失败模式

18.3 shadow 结果最好和旧基线做“同口径镜像对比” ​

很多团队做 shadow 时，只把新系统跑起来看个大概：

  • 好像也还行

这通常不够。

更稳的 shadow 观察通常要同时满足：

  • 同一批真实请求
  • 同一套冻结 grader
  • 同一套聚合规则
  • 同一套分桶口径

也就是：

  • 不只是“跑一下 shadow”
  • 而是“用旧基线口径对新版本做镜像评测”

这样 shadow 才真正能回答：

  • 如果切流，哪些桶会先出问题
  • 哪些退化是线下没测出来、但线上流量一来就暴露的

19. trace 基线为什么值得单独保留 ​

只保留“总分基线”，很多时候还是不够。

OpenAI Trace grading 和 Evaluate agent workflows 的思路很值得借鉴：

  • 有些版本最终分数接近
  • 但轨迹已经明显变差

例如：

  • 工具调用次数暴涨
  • handoff 次数异常
  • 审批等待显著变长
  • 轨迹更绕、更脆弱

这些问题在总分里不一定马上暴露，但对上线稳定性影响很大。

19.1 更值得保留的 trace 基线对象 ​

  • 核心高价值任务的标准轨迹
  • 高风险动作前后的审批轨迹
  • 历史故障样例的回归轨迹
  • 成本明显偏高样例的运行轨迹

19.2 trace 基线比普通分数更适合回答什么 ​

  • 这次到底是结果变差，还是过程先变脆了
  • 哪个步骤开始出现额外开销
  • 哪类请求虽然过线，但已经接近风险边界

19.3 trace 基线最好单独记录“正常轨迹上限”，不只记录事故轨迹 ​

很多团队保留 trace 时，只会留事故样例。

但更稳的做法通常还会保留：

  • 正常请求应该大致长什么样

例如：

  • 最多几次工具调用
  • 最多几次 handoff
  • 审批等待通常不超过多久
  • 哪些路由本来就不该出现

这样 trace 基线才能真正用来做：

  • 轨迹膨胀检测
  • 异常步骤检测
  • 成本异常预警

否则你只能在事故发生后复盘，不能在事故发生前预警。

20. 推荐搭配阅读 ​

21. 重点官方资源 ​

以下资源已按 2026-07-09 复核到当前正式入口；其中少数站点对脚本探测可能受限，但浏览器入口仍可正常打开：

22. 落地检查清单 ​

  • 是否区分了评测基准和参考基线
  • 是否为基线记录了完整版本上下文
  • 是否对核心业务、高风险、回归场景做了分层
  • 是否避免了 grader、样本、模型变化却不留痕的漂移
  • 是否让基线真正进入发布和放量决策