Wiki Notes

Appearance

评测运营与案例 ​

版本：v1.3

最后更新：2026-07-08

这一组内容聚焦的是：

  • 系统上线以后，怎么把评测、运营、告警、失败样例、指标和真实案例串成闭环，而不是把“评测”停留在一次性验收。

如果说 LLM专题 / 04-Evals与评测体系详解 更偏评测方法论，这一组更偏生产现场，关注的是：

  • 基线怎么设
  • 指标怎么分层
  • 回放怎么做
  • 告警怎么设计
  • 漂移怎么监控
  • 成本怎么归因
  • 复盘怎么沉淀

1. 这一组内容主要解决什么 ​

很多 AI 系统上线后会出现一种错觉：

  • 离线评测看起来不错
  • 但线上问题仍然不停冒出来

常见原因通常有这些：

  • 评测集没有覆盖真实分布和长尾失败样例
  • 指标只看模型输出，不看业务结果、人工审批和工具链环节
  • 告警只能发现系统挂了，发现不了质量退化和成本漂移
  • 失败案例没有分桶、回放、归因和回灌

OpenAI 当前 Evaluation best practices、Getting started with datasets、Graders、Evaluate agent workflows 和 Trace grading 的官方资料都在强调一件事：

  • 评测不是一次动作，而是一条持续运行的系统能力

2. 这组内容应该怎么读 ​

2.1 想先建立一套最小评测闭环 ​

  1. 评测基准与基线管理专题
  2. 评测样例治理专题
  3. 失败样例分桶专题
  4. 真实告警样例专题
  5. 多通道告警设计专题

2.2 想把指标从“模型视角”拉到“业务视角” ​

  1. AI产品指标体系专题
  2. 业务指标回放专题
  3. 审批指标体系专题
  4. 任务级成本归因专题
  5. AI成本治理案例专题

2.3 想看真实生产案例怎么复盘 ​

  1. AI项目复盘案例专题
  2. 真实项目案例集专题
  3. 模型输出漂移检测专题
  4. 真实告警样例专题

3. 这组专题之间的关系 ​

3.1 基线层 ​

这一层回答的是：

  • 什么叫变好
  • 什么叫变坏
  • 上线门槛是什么
  • 人工流程怎么计入系统质量

3.2 样例层 ​

这一层更偏数据经营。没有样例治理，很多评测都会逐渐变成：

  • 形式上跑了
  • 实质上没覆盖风险

3.3 运行层 ​

这一层关注的是：

  • 问题发生后能不能及时发现
  • 能不能分级告警
  • 能不能知道是质量漂移、策略变更、工具失败还是成本异常

3.4 复盘层 ​

这部分更偏：

  • 把事故和迭代经验沉淀成组织资产

4. 为什么这一组对 AI 系统尤其重要 ​

4.1 线上质量退化通常先体现在样例、trace 和业务指标上 ​

OpenAI Evaluate agent workflows 当前官方资料明确建议：

  • 在还没完全看清行为时，先看 trace

这对 Agent、RAG、工具链系统尤其重要，因为最终失败经常不是模型一句话答错，而是：

  • 链路中间某个环节先偏了

4.2 自动评测一定要和人工校准绑在一起 ​

OpenAI Evaluation best practices 和 cookbook 资料都强调：

  • 自动 graders 本身也会有误差

更稳的做法是：

  • 把自动评分当成放大器
  • 把人工评审当成标尺

4.3 评测平台要和供应商能力解耦 ​

OpenAI Working with evals 官方文档目前写明：

  • 现有 Evals 平台将在 2026-10-31 进入只读
  • 计划在 2026-11-30 关闭

这件事的工程启发很直接：

  • 数据集、评分标准、样例分桶和回放口径最好做成自有资产，不要只依赖某一个托管入口

4.4 成本、质量和业务结果必须一起看 ​

如果只看通过率，很容易把“昂贵但稳定”的策略误判为最优。

如果只看成本，又可能把真正关键的质量退化压没。

任务级成本归因、业务指标回放和告警分层，本质上都是在回答：

  • 这次优化到底值不值

4.5 评测信号最好分成“阻断、观察、诊断”三层 ​

很多团队把所有指标都塞进一张大盘里，结果会出现两个问题：

  • 真正该拦发布的问题没有被拦住
  • 不该打扰值班的问题却天天在响

更稳的做法通常是把信号至少分成三层：

  • 阻断指标：决定这次发布能不能过，例如核心任务成功率、严重安全失败率、关键工具调用成功率
  • 观察指标：不一定阻断，但需要持续盯，例如引用附着率、人工接管率、平均回合数、单位任务成本
  • 诊断指标：帮助定位根因，例如某类 query 的失败分桶占比、某个工具的超时率、某个 grader 的分数分布漂移

OpenAI 当前 Evaluation best practices 明确把 定义目标 -> 选数据 -> 定指标 -> 跑对比并迭代 作为基本闭环；Google SRE 关于 SLO-based alerting 的资料则提醒我们，告警更适合围绕真正会消耗预算的信号，而不是“有变化就响”。两者放在一起的工程启发很直接：

  • 不是所有指标都应该进门禁
  • 不是所有门禁指标都应该打 page
  • 不是所有 page 都应该只由模型团队单独处理

5. 企业里最常见的五个运营闭环判断 ​

5.1 评测要不要进发布门禁 ​

只要系统已经开始持续迭代 Prompt、模型、检索、工具或审批策略，评测就不该只停留在“上线前人工试几条”。

5.2 trace 是不是只给排障用 ​

OpenAI 当前 Trace grading、Evaluate agent workflows 和 Integrations and observability 都在说明：

  • trace 不只是排障工具，也是工作流级评测、失败分桶和回放归因的核心输入

5.3 告警要不要把质量、成本和安全拆开 ​

如果所有异常都塞进一条通道里，最终通常只能发现：

  • 系统挂了

却很难发现：

  • 质量退化
  • 审批异常
  • 工具误用
  • 成本漂移

5.4 成本要不要按任务归因 ​

只看月账单，几乎无法回答：

  • 哪类任务在烧钱
  • 哪条链路该优化
  • 这次优化到底值不值

5.5 失败样例要不要长期经营 ​

如果失败样例只在事故当天看一眼，后面没有分桶、回灌和回放，它们就很难变成组织资产。

5.6 评测集要不要分成“主集、挑战集、线上回流集” ​

如果评测集永远只有一份，团队很容易同时踩中两个坑：

  • 为了过当前版本，主集被不断“教熟”
  • 真实线上新问题又来不及纳入验证

更实用的分法通常是：

  • 主集：做长期基线，用于版本间横向对比，尽量保持稳定
  • 挑战集：专门收最难、最贵、最容易翻车的样例，用于防回归
  • 线上回流集：从最近真实流量、人工驳回、告警命中和失败 trace 里持续补新样例

OpenAI 当前 Evaluation best practices 明确把 synthetic / domain-specific / human-curated / production / historical 数据都列进同一评测数据来源集合，这其实已经在提示我们：

  • 评测集不是单一来源
  • 基线集和新鲜度要同时被经营
  • 线上失败样例必须持续把离线评测往真实分布拉回去

5.7 发布门禁要不要冻结“版本包” ​

很多 AI 发布回头复盘时，最痛的不是“分数低”，而是：

  • 不知道当时到底用的哪版 Prompt
  • 不知道检索配置、工具路由、阈值和 grader 版本是不是一起变了
  • 不知道这次回放和上次回放是不是同一个数据切片

所以评测门禁真正应该冻结的，往往不是“一个模型版本”，而是一个更完整的 release bundle：

  • Prompt / developer instructions 版本
  • 模型与参数版本
  • 工具白名单、路由和 guardrails 版本
  • 检索配置、rerank 配置、chunk / filter 策略
  • graders、阈值、数据集切片和分桶口径

只有把这些一起冻结，后面的回放、对账和事故归因才有意义。

6. 哪些系统分界线最容易被忽略 ​

6.1 离线评测和线上运营不是两个孤岛 ​

没有线上失败样例回流，离线评测很快会和真实流量脱节。

没有离线数据集和基线，线上运营又很难判断：

  • 这次退化到底是不是版本问题

6.2 业务指标和模型指标不能互相替代 ​

通过率、grader 分、引用质量、工具成功率都很重要，但业务系统最后仍然要回答：

  • 用户有没有完成任务
  • 人工审批有没有压垮流程
  • 风险有没有下降

6.3 成本异常和质量异常经常是同一个问题的两面 ​

例如：

  • 工具重试次数变多
  • 上下文装配变长
  • 检索召回退化导致回合数增加

这些问题常常会同时拉高：

  • 延迟
  • 成本
  • 失败率

6.4 低流量系统不要照搬高流量系统的告警方式 ​

Google SRE 当前关于 Alerting on SLOs 的官方资料明确提醒：

  • 多窗口、多 burn-rate 告警在高流量系统里很有效
  • 但低流量系统里，单个失败请求也可能制造极高的表面 burn rate

这对很多企业 AI 系统尤其重要，因为不少内部 Copilot、审批 Agent、专家助手天然就是低频高价值流量。

如果直接照搬高流量服务的 page 规则，很容易出现：

  • 白天没事，晚上偶发一条失败就把人叫起来
  • 小样本波动看起来像事故，值班团队却越看越麻木

更稳的做法通常是：

  • page 看核心高价值链路
  • ticket 看较长窗口里的趋势退化
  • 周报 / 月报看低频场景的聚合质量与人工复核结果

6.5 在线 LLM-as-a-judge 更适合抽样，不适合无差别全量跑 ​

在线评测最大的价值是快，但最大的风险也是快：

  • 成本会迅速放大
  • 噪音会大量进入告警链路
  • 评分波动会让团队误把偶然变化当趋势

LangSmith 当前官方文档明确支持给在线 evaluator 配置 sampling rate，例如只对 10% 的 traces 触发自动评测。这个设计很值得借鉴，因为它说明：

  • 在线 judge 更像高频探针
  • 不一定要覆盖所有流量
  • 抽样、分桶和过滤条件本身就是评测设计的一部分

对企业系统来说，更常见也更稳的组合是：

  • 核心高风险流量做高覆盖或定向全量
  • 普通流量做抽样
  • 可疑分桶做加密采样或重点回放

6.6 trace、dataset、release bundle 最好能互相追溯 ​

OpenAI 当前 Evaluate agent workflows 明确建议：

  • 还在看行为时，先从 traces 开始
  • 确认“好”长什么样之后，再转向可重复的数据集和 eval runs

这背后的工程含义不是“trace 和 dataset 二选一”，而是：

  • trace 负责还原一次真实运行
  • dataset 负责把判断标准固定下来
  • release bundle 负责把当时的系统版本冻结下来

如果这三者互相断开，团队很容易出现：

  • 能看到事故 trace，但无法知道它后来有没有进入回归集
  • 能跑回归集，但不知道对应的是哪次线上变更
  • 能看到分数变化，却追不到是哪一个工具、规则或检索配置引起

7. 不同角色更适合先看什么 ​

7.1 应用工程师 ​

更适合先看：

  1. 评测样例治理专题
  2. 失败样例分桶专题
  3. 真实告警样例专题

7.2 平台或架构同学 ​

更适合先看：

  1. 多通道告警设计专题
  2. 任务级成本归因专题
  3. 模型输出漂移检测专题

7.3 业务或运营负责人 ​

更适合先看：

  1. AI产品指标体系专题
  2. 业务指标回放专题
  3. AI成本治理案例专题

7.4 值班或稳定性负责人 ​

更适合先看：

  1. 多通道告警设计专题
  2. 真实告警样例专题
  3. 模型输出漂移检测专题
  4. 任务级成本归因专题

8. 推荐搭配阅读 ​

9. 重点官方资料 ​

以下入口在 2026-07-08 检查时可访问：