Wiki Notes

Appearance

模型输出漂移检测专题 ​

版本：v1.2

最后更新：2026-07-08

适用对象：正在做 LLM 应用、RAG、Agent、多工具工作流和高风险审批系统，需要把“最近好像变差了”变成“能尽早发现、能定位来源、能触发治理动作”的产品、平台、评测和值班同学

很多模型问题并不是一次性故障，而是缓慢发生的：

  • 结果一天比一天不稳定
  • 风格慢慢变化
  • 某类任务成功率悄悄下降
  • JSON 结构开始偶发缺字段
  • 原来稳的高风险场景开始出现误放或误拒

这类问题如果没有专门机制，团队往往要等到用户明显投诉后才意识到。

OpenAI 当前 Evaluation best practices、Model optimization、Evaluate agent workflows，以及 LangSmith 当前 online evaluations、W&B Weave 当前 monitor using built-in signals、evaluations overview 等官方资料，在 2026-07-08 复核时都指向一个共同现实：

  • 模型输出的质量并不会因为“上次评测过了”就长期稳定，必须持续比较、持续切片、持续回流。

所以这篇专题真正关心的不是“看起来好像变差了”，而是：

  1. 如何建立可比较的基线
  2. 如何把变化切成可观测信号
  3. 如何把漂移映射到模型、prompt、检索或工具链变更
  4. 如何让漂移告警触发真正的治理动作

1. 什么是输出漂移 ​

更实用的理解通常是：

  • 在没有显式业务目标变化的情况下
  • 模型输出分布、质量或行为逐渐偏离原本稳定状态

漂移不一定表现为“完全错误”，也可能只是：

  • 风格变了
  • 长度变了
  • 某些边界样例开始频繁出问题
  • 某类风险动作的判定阈值悄悄偏移

这也是为什么很多漂移在早期不容易被发现：

  • 它不是宕机
  • 不是大面积 500
  • 而是“有些地方慢慢不对了”

2. 为什么漂移特别难发现 ​

漂移通常不是一次性崩掉，而是：

  • 慢慢变差
  • 局部变差
  • 只在某些切片里变差

如果只看总体成功率或偶发人工抽查，很容易漏掉这些变化。

最常见的误判是：

  • 整体通过率还行，所以系统没问题

但真实情况可能是：

  • 企业客户场景下通过率下降
  • 高风险退款场景误放率升高
  • 结构化输出缺字段率上升
  • 某个 prompt 版本只在长上下文里退化

这些问题都可能被平均值掩盖。

3. 漂移不一定只由模型版本变化引起 ​

很多“模型漂移”其实不是模型本身变了，而是周边系统变了。

更常见的来源包括：

  • 模型版本变化
  • prompt 版本变化
  • query rewrite 变化
  • 检索上下文变化
  • rerank 变化
  • 工具返回结构变化
  • 用户问题分布变化
  • 安全策略或审批规则变化

所以漂移检测不能只盯着：

  • model = x.y.z

还要记录：

  • prompt version
  • retrieval version
  • rerank version
  • tool schema version
  • guardrail version
  • route version

否则告警出来后很难归因。

4. 一个更实用的漂移分类法 ​

把漂移拆成几层来看，会比“最近质量变差”有用得多。

4.1 文本层漂移 ​

关注：

  • 输出长度变化
  • 格式变化
  • 语气变化
  • 结构稳定性变化

适合监控：

  • 摘要
  • 文案
  • 结构化输出

4.2 任务层漂移 ​

关注：

  • 某类任务成功率变化
  • 某类任务工具调用率变化
  • 某类任务拒答率变化

适合监控：

  • FAQ
  • RAG 问答
  • 工单路由
  • 审批建议

4.3 风险层漂移 ​

关注：

  • 高风险误放
  • 高风险误拒
  • 审批触发模式变化
  • 敏感信息泄露迹象

这类漂移最值得优先关注，因为它们通常影响最大。

4.4 运行时层漂移 ​

关注：

  • 任务链变长
  • 重试增加
  • fallback 增多
  • tool failure 升高

这类漂移有时看起来像稳定性问题，但它往往会进一步拖坏质量与成本。

5. 漂移检测离不开基线 ​

没有基线时，很多问题只能靠感觉：

  • 好像最近变差了

更稳妥的做法通常是：

  • 为关键场景保留历史基线
  • 对比当前输出与基线差异

基线可以是：

  • 某个稳定版本的离线评测结果
  • 某个生产时间窗的线上统计
  • 关键高风险样例的人工标注结果

一个简单的基线对象可以是：

json
{
  "slice": "enterprise_refund_rag",
  "model_version": "model-a-2026-06",
  "prompt_version": "refund-v7",
  "window": "2026-06-20_to_2026-06-27",
  "metrics": {
    "pass_rate": 0.91,
    "citation_accuracy": 0.96,
    "json_valid_rate": 0.995,
    "human_handoff_rate": 0.08
  }
}

关键不是这个 JSON 长什么样，而是：

  • 你得知道现在是和谁比

6. 观测漂移时，不要只看整体指标 ​

更值得优先观察的通常有：

  • 某类任务通过率变化
  • JSON 或 schema 稳定性下降
  • 引用准确率下降
  • 人工接管率上升
  • 高风险拒答或放行模式变化
  • 工具参数合法率下降
  • unsupported claim rate 上升

这些信号比只看平均 token 或平均时延更贴近真实业务影响。

7. slice-based monitoring 比总平均更重要 ​

很多漂移只发生在特定切片里。

所以更推荐按以下维度切片观察：

  • 任务类型
  • 用户等级
  • 租户
  • 风险等级
  • 是否长上下文
  • 是否走检索
  • 是否走工具
  • 是否触发审批

例如：

  • 总体通过率稳定
  • 但 高风险退款 + RAG + 企业客户 这个切片连续三天下降

这类问题如果没有切片，几乎看不到。

8. 什么叫“可行动的漂移指标” ​

好的漂移指标，不只是发现变化，还要能映射到下一步动作。

例如：

指标可能动作
json_valid_rate 下降检查结构化输出 prompt / schema / model route
citation_accuracy 下降检查 retrieval、rerank、context assembly
high_risk_false_allow_rate 上升检查 guardrails、approval policy、模型升级
human_handoff_rate 上升检查信心阈值、工具链、场景分布变化
unsupported_claim_rate 上升检查模型是否脱离证据、知识是否过期

如果指标只能“告诉你不对劲”，却无法帮助归因，它的治理价值会很快下降。

9. 在线漂移检测和离线回归应该一起做 ​

OpenAI 的评测最佳实践强调持续测量；LangSmith 的 online evaluators 也明确说明：

  • online evaluations 适合持续监控生产 traces

所以更稳的组合通常是：

9.1 离线回归 ​

作用：

  • 在发布前比较不同版本
  • 用固定样例集看回归和退化

9.2 在线漂移监控 ​

作用：

  • 发现真实流量里的变化
  • 监控长尾场景
  • 捕捉数据分布漂移

两者的关系通常是：

text
offline baseline
 -> production rollout
 -> online monitoring
 -> drift alert
 -> slice diagnosis
 -> add new cases back to eval set

10. online evaluators 和 built-in signals 能解决什么 ​

LangSmith 当前官方文档里，online evaluators 用于：

  • 对生产 traces 持续打分
  • 发现问题
  • 监控改进是否生效

W&B Weave 当前 monitors 文档则强调：

  • built-in signals 可持续检测生产 traces 中的常见问题

这两类能力很适合做漂移检测，因为它们能把“主观抽查”转成：

  • 持续、可比的在线评分信号

例如可以长期监控：

  • 是否更容易答非所问
  • 是否更容易无依据生成
  • 是否更容易出现格式问题
  • 是否更容易触发风险信号

11. 一套实用的漂移监控字段 ​

建议至少为每次线上请求保留这些字段：

json
{
  "request_id": "req_20260708_001",
  "task_type": "rag_answer",
  "slice": "enterprise_refund",
  "model_version": "model-a-2026-07",
  "prompt_version": "refund-v8",
  "retrieval_version": "hybrid-v3",
  "tool_schema_version": "toolset-v4",
  "json_valid": true,
  "citation_accuracy_score": 0.93,
  "human_handoff": false,
  "risk_level": "high",
  "online_eval_score": 0.88
}

这样当漂移发生时，团队才能回答：

  • 是哪个切片先变差
  • 和哪次变更最相关
  • 是模型、prompt 还是检索在变化

12. 怎么定义漂移告警阈值 ​

漂移告警不建议只靠一个固定阈值硬判。

更稳的做法通常是结合：

  • 历史均值
  • 滑动窗口
  • 切片对比
  • 高风险阈值单独收紧

例如：

  • 某切片 pass_rate 连续 3 个窗口低于历史基线 5%
  • citation_accuracy 较上周同类请求下降 8%
  • json_valid_rate 连续 1 小时低于 99%
  • high_risk_false_allow_rate 单日高于基线两倍

注意：

  • 高风险场景阈值应明显更严格

13. 漂移检测最好和发布时间线绑定 ​

很多团队发现漂移后，最大困难不是“变差了”，而是：

  • 不知道从哪次变更开始变差

所以更稳的做法是把漂移分析直接绑到：

  • 发布批次
  • prompt bundle
  • route version
  • tool schema version
  • retrieval config version

这样告警出来后，你更容易回答：

  • 它是自然数据波动
  • 还是某个版本引入的系统性变化

14. 漂移治理动作最好分成三级 ​

发现漂移后，不是每次都要立刻大回滚。

更实用的动作通常分三级。

14.1 观察级 ​

  • 提高采样
  • 增加人工抽检
  • 暂不回滚，只重点监控

14.2 收敛级 ​

  • 回退某个 prompt
  • 暂停某个模型路由
  • 收紧高风险自动执行
  • 提升人工接管比例

14.3 修复级 ​

  • 重做基线
  • 补 regression dataset
  • 调整检索 / schema / route / workflow
  • 新增 trace grading 或 online evaluator

这样团队不会陷入：

  • 每次轻微波动都大动干戈
  • 或者每次严重漂移都只停留在“再观察一下”

15. 漂移检测结果如何进入治理闭环 ​

更好的做法通常是：

  1. 发现异常变化。
  2. 定位是模型、prompt、检索还是工具链变化。
  3. 触发灰度回退、人工复核、线上限流或回归测试。
  4. 把新漂移样例拉入失败样例分桶和回归集。

如果检测完没有动作链路，漂移监控很快就会失去价值。

常见触发动作包括：

  • 回退到上一版 prompt
  • 暂停某个新模型路由
  • 降低某类自动执行权限
  • 强制高风险切片转人工
  • 提升 online evaluator 采样率

16. 漂移检测最常见的反模式 ​

16.1 只看整体指标，不看切片 ​

这会让局部严重退化长期被隐藏。

16.2 没有历史基线 ​

最后只能靠“感觉变差了”。

16.3 发现漂移后无法定位变更来源 ​

说明版本治理和观测字段没打通。

16.4 漂移告警与回滚机制脱节 ​

报警很多，但没有动作，团队很快就会麻木。

16.5 只关注文本风格，不看业务结果 ​

很多业务漂移不会先表现为措辞变化，而是先表现为：

  • 误判率
  • 漏召回
  • 审批异常
  • 错误执行建议

17. 一个更稳的落地顺序 ​

建议按下面顺序做第一版漂移检测：

  1. 先定义关键场景和关键切片。
  2. 为这些切片建立离线基线。
  3. 在线记录版本字段和关键质量指标。
  4. 用 online evaluators 或 built-in signals 持续打分。
  5. 先对高风险切片配置更严格告警。
  6. 把告警结果回流到失败样例分桶和回归集。

这比一开始就追求“全量自动漂移检测平台”更稳。

18. 推荐搭配阅读 ​

19. 重点官方资源 ​

以下入口已按 2026-07-08 的官方资料重新整理：

20. 落地检查清单 ​

  • 是否已经为关键场景和关键切片建立了可比较基线
  • 是否同时记录了 model、prompt、retrieval、route、tool 等版本字段
  • 是否能区分文本层、任务层、风险层和运行时层漂移
  • 是否避免只看整体指标，而能按租户、风险、任务和上下文长度切片
  • 是否为高风险切片设置了更严格的漂移阈值
  • 是否能把漂移告警直接映射到回退、限流、转人工或回归测试动作
  • 是否把新出现的漂移样例持续回流到失败样例分桶和评测集