Appearance
03. 评测门禁、回放与版本基线
版本：
v1.1最后更新：
2026-07-08适用对象：已经知道“要做 eval”，但还没有把评测、回放、失败样例、版本基线和发布门禁连成闭环的团队
AI 系统最常见的一个工程错觉是：
- 大家都知道要评测
- 但真正变更时，还是靠主观体验决定上不上线
这通常会带来两个问题：
- 质量下降发现太晚
- 出问题后说不清到底哪层变差
OpenAI 当前 Evaluation best practices、Getting started with datasets 和 Prompt optimizer 都在强调：
- 先定义目标
- 先准备数据
- 再持续比较版本
这篇重点讲的就是怎么把这件事做成日常生产能力。
0.1 评测不是“测试替代品”，更像变更控制的一部分
OpenAI 当前 Working with evals、Evaluate agent workflows、Evaluation best practices 放在一起看，会很容易得出一个更稳的工程结论：
- eval 不是附属 QA
- 它更像 AI 变更控制面的核心资产
也就是说，真正成熟的团队不是在问：
- “我们有没有评测”
而是在问：
- “模型、prompt、检索、工具、状态和审批一改，靠什么证明这次变更还安全可发”
1. 评测门禁到底要挡住什么
评测门禁不是为了追求“绝对完美”，而是为了挡住下面这几类典型事故：
- 新 Prompt 让高频任务退化
- 新模型让成本暴涨但质量没涨
- 检索策略一改，引用错位增多
- 工具 schema 一改，结构化输出崩掉
- 长任务状态策略一变，恢复能力下降
所以门禁真正要回答的是：
这次变更有没有把我们最在意的关键能力打穿
2. 先区分三种不同层次的评测
2.1 能力层评测
看的是：
- 输出内容是否更接近目标
- 模型本身是否适合这个任务
2.2 系统层评测
看的是：
- 检索、工具、状态、审批是否协同工作
2.3 发布层评测
看的是：
- 和上一个生产基线比，这次变更能不能过线
很多团队只做能力层评测，结果一上线发现真正坏掉的是系统层。
3. 什么叫“版本基线”
一个更实用的基线，不是“曾经最好的一版”，而是：
- 当前生产流量上稳定可接受、已知风险可控、且可回退的那个版本快照
这个快照最好至少绑定：
- 模型
- Prompt
- tool schema
- retrieval config
- safety / approval policy
- eval dataset
这样你对比的就不是“印象里以前更好”，而是有明确对象。
3.1 baseline bundle 通常比单独“模型版本”更重要
很多团队嘴里说“和上个版本比”，实际比较的却只有：
- 模型名
但真实结果往往还受这些东西一起影响：
- prompt
- retrieval config
- rerank config
- tool schema
- guardrails
- approval policy
- timeout / retry
- cache strategy
更稳的做法通常是把这些冻结成：
baseline bundle
这样你在判断退化时，比较的才是：
- 一套完整运行快照
而不是单独某个模型 slug。
3.2 不同任务桶通常需要不同基线
很多团队只维护一条总基线，但真实系统里往往至少要分：
- 高频主任务基线
- 高风险任务基线
- 新能力试点基线
- 大客户 / 核心租户基线
因为这些桶关心的东西不一样：
- 有的桶更在意通过率
- 有的桶更在意引用正确率
- 有的桶更在意误放行率
如果所有任务共用一条总基线，很容易出现：
- 总分过线了
- 但关键桶已经掉穿
4. 回放为什么是评测闭环的中轴
没有回放，很多失败只能停留在描述层：
- 用户说今天变差了
- 但你没法稳定重现
回放的价值在于：
- 把真实线上输入、上下文、候选池、工具调用和最终输出重新跑一遍
这样你才能判断问题是：
- Prompt 变了
- 模型变了
- 检索变了
- 工具变了
- 状态拼装变了
4.1 回放最好区分“静态回放”和“环境回放”
不是所有回放都应该追求完全同态。
更实用的两种回放通常是：
静态回放- 重放输入、prompt、候选池、工具结果快照
- 更适合稳定定位 prompt / model / ranking 变化
环境回放- 复现更真实的在线依赖
- 更适合判断工具、权限、状态恢复是否受环境影响
这两者解决的不是同一个问题：
- 静态回放更适合找可重复退化
- 环境回放更适合找真实依赖抖动
4.2 高价值投诉和事故样本最好先冻结回放证据
很多团队线上出事后，会先忙着修。
但更稳的顺序通常是：
- 先冻结关键回放证据
- 再修问题
- 修完后用同一套证据回放验证
否则常见情况就是：
- 问题当下确实发生过
- 但证据没留住
- 后面只能靠印象争论
5. 至少要保留哪些回放证据
建议至少保留：
- raw input
- normalized / rewritten input
- model id
- prompt version
- retrieval config
- top-k candidate pool
- tool calls and results
- final output
- final citations
- release batch id
如果系统里没有这些字段，复盘时通常只能靠猜。
6. 失败样例不应该只是“坏案例收藏夹”
失败样例真正有价值，是因为它们能变成：
- 回归测试集
- 风险样例集
- 发布门禁的一部分
也就是说，一次失败如果只停留在复盘文档里，没有回流到门禁里，下次大概率还会再来。
6.1 失败样例最好带 root cause 和 fix status
更有治理价值的失败样例，通常不只记录：
- 输入是什么
- 输出错了什么
还应至少补上：
- 所属任务桶
- 失败层级：prompt / retrieval / tool / state / approval / routing
- 严重级别
- 是否已进入门禁
- fix status：待修 / 已修待验证 / 已纳入基线
这样它才更像：
- 版本治理资产
而不只是：
- 失败截图档案
7. 基线评测至少要分哪几桶
不要只看总分。
更稳的做法是至少按下面几类分桶：
7.1 高频主任务
- 用户最常做的事
7.2 高风险任务
- 一旦错了代价高的事
7.3 已知脆弱任务
- 过去经常翻车的桶
7.4 新增能力任务
- 这次改动重点想提升的桶
这样你才能避免一种常见误判：
- 平均分上涨了，但高风险任务其实退化了
7.5 门禁桶最好再区分“阻断桶”和“观察桶”
不是所有桶都应该拥有一样的发布权重。
更稳的分层通常是：
阻断桶- 只要明显退化就不能发
观察桶- 可以先带着风险灰度，但要明确观察窗口
例如：
- 高风险任务、监管相关任务、关键租户任务通常更适合阻断桶
- 新能力试点、低流量长尾场景可以先放在观察桶
这样门禁就不会变成：
- 要么所有事情都卡死
- 要么所有事情都随便放
8. OpenAI eval 指南给出的一个重要启发
OpenAI 当前评测最佳实践反复强调：
- 先定义什么叫成功
- 用有代表性的数据集持续比较
这对生产团队最大的启发是：
- 评测不应该从“有什么指标可看”出发
- 而应该从“这次变更最怕出什么事故”出发
8.1 graders 也应该分层，而不是只靠一个总分
按 OpenAI 当前 Working with evals、Evaluation best practices、datasets 相关资料来看，更稳的做法通常是同时准备几类 grader：
规则型 grader- 判断结构化字段、schema、引用格式、是否命中硬约束
模型型 grader- 判断答案相关性、是否覆盖关键点、是否符合风格要求
业务型 grader- 判断是否真的完成任务目标
这几类 grader 的价值不同：
- 规则型适合做硬门禁
- 模型型适合发现语义质量变化
- 业务型适合贴近真实上线价值
如果所有判断都压成一个总分，后面通常很难解释：
- 到底是哪一层退化了
9. 发布门禁应该怎样和评测基线绑定
一个更稳的方式通常是：
- 每次变更前声明影响范围。
- 选择对应评测桶。
- 与当前生产基线比较。
- 设置清晰过线条件。
- 记录结果并绑定发布批次。
这样一来，发布就有了可解释证据：
- 不是“大家觉得还行”
- 而是“对这几类关键任务，它确实没退化”
9.1 gate profile 最好也版本化
很多团队会版本化 prompt 和模型，但不会版本化门禁规则本身。
更稳的做法通常是把下面这些也一起版本化：
- 当前阻断桶定义
- 当前观察桶定义
- 每桶过线阈值
- 成本 / 延迟 / 风险阈值
- 对应 release type：全量 / 灰度 / 大版本切换
这样后面你才能回答：
- 是模型变了导致没过线
- 还是 gate profile 本身被收紧了
9.2 不同发布类型，应该匹配不同 gate profile
例如：
热修复- 更关注高风险阻断桶和回归稳定性
常规迭代- 质量、成本、延迟一起过线
大版本切换- 更强调 shadow、灰度和观察窗口
如果所有发布都走同一套门禁，很容易：
- 小改太重
- 大改太轻
10. 评测门禁不要只卡质量
还建议同时看：
10.1 成本门禁
- 单请求成本是否超预算
10.2 延迟门禁
- P95 是否明显恶化
10.3 稳定性门禁
- 工具成功率是否下降
- 超时率是否上升
10.4 风险门禁
- 高风险误放行率是否上升
- 安全回归样例是否通过
10.5 恢复与状态门禁
对 Agent / workflow 系统来说，还建议单独观察：
- 长任务恢复成功率
- 审批后恢复成功率
- run 中断后上下文一致性
- handoff 后任务完成率
很多系统离线看答案没问题，但一进长工作流，真正坏掉的是：
- 恢复链路
- 状态拼装
- 人机接力
11. 一个更实用的回放链路
建议把回放拆成下面四层：
11.1 请求回放
- 复现原始输入和上下文
11.2 检索回放
- 复现候选池和过滤条件
11.3 工具回放
- 复现工具入参、出参与异常
11.4 输出回放
- 对比最终结构化结果、引用和文本输出
这样做能帮你快速缩小问题范围。
11.5 发布回放
除了单条请求回放，更成熟的团队通常还会做：
发布回放
也就是拿一组冻结样本，直接比较：
- 当前基线 bundle
- 候选 bundle
- fallback bundle
这样你判断的就不只是：
- 某条 case 会不会坏
而是：
- 一整次发布的证据是否足够支持上线
12. 哪些场景最值得优先做回放
- RAG 引用错位
- Agent 工具误调用
- 长任务恢复失败
- 高价值客户投诉样例
- 新模型切换后的异常请求
这些场景的共同点是：
- 一次事故的学习价值很高
13. 数据集应该如何持续更新
如果数据集只在项目启动时建一次，它很快就会过时。
更实用的维护节奏通常是：
- 从线上收集失败样例。
- 人工标注成高价值样本。
- 按任务桶回流到数据集。
- 周期性清理过时样本。
- 更新后重新定义基线。
这也是为什么数据集更像产品资产，而不是测试附件。
13.1 数据集最好显式区分“训练视角”和“门禁视角”
有些样本适合：
- 帮 prompt 或系统改得更好
但不一定适合直接做发布阻断。
更稳的区分通常是：
优化样本池- 用来发现改进机会
门禁样本池- 用来判断能不能发
事故样本池- 用来防止严重问题复发
这样团队就不会把：
- 还在探索中的新样本
直接混进：
- 必须稳定过线的发布门禁
14. 什么情况下应该重建基线
以下情况通常值得重建或刷新基线：
- 模型大版本切换
- Prompt 主骨架变化
- 检索链路重大改动
- 工具能力边界变化
- 业务目标或成功标准变化
否则你很可能拿旧时代的基线在判断新系统。
14.1 route bundle、lane 或 gating policy 大改时也该重建基线
不仅模型切换会让旧基线失效。
如果你改了：
- route bundle
- fallback 逻辑
- service lane
- approval / guardrail policy
- gate profile
旧基线同样可能失去解释力。
因为这时系统变的可能不是“回答内容”，而是：
- 整个运行控制方式
15. 常见反模式
- 没有失败样例回流，只反复跑“好看样本”。
- 只看总分，不按任务桶看。
- 只做离线评测，不做线上回放。
- 发布门禁只看质量，不看成本和风险。
- 评测结论没有和具体版本绑定。
16. 一个最小可用的门禁模板
发布前必须满足
- 关键任务桶不退化
- 高风险桶通过率不低于基线
- 成本、延迟没有明显越线
- 安全回归集没有新增严重失败
发布后必须观察
- 首批灰度流量真实表现
- 人工接管率变化
- 失败样例新增分布
需要保留的证据
- 评测报告
- 对比基线
- 发布批次
- 回滚目标
16.1 更像生产系统的 release evidence bundle 通常还应包括
- baseline bundle 版本
- gate profile 版本
- 关键阻断桶结果
- 观察桶风险说明
- shadow 或灰度结果摘要
- 主要退化点与接受理由
- 回滚入口和负责人
这样值班或复盘时，团队拿到的就不是：
- 一张“过了 / 没过”的结论
而是一份能解释：
- 为什么敢发
- 哪些风险被接受
- 出问题时往哪回
17. 推荐搭配阅读
18. 重点官方资料
以下资源已按 2026-07-08 复核可访问：