AI 学习笔记（六十五）：LLM 治理平台升级后的回归验证集、长期漂移检测与周期性健康审查

发表于 分类于 阅读次数： Changyan： 本文字数： 4.6k 阅读时长 ≈ 4 分钟
上一篇讲了 baseline 升级的兼容矩阵、迁移账本和分批 cutover。这篇继续往下走：升级完成不代表万事大吉，怎么用回归验证集确认没静默退步，怎么用长期漂移检测抓住慢变化，以及周期性健康审查怎么排节奏才不会流于形式。

上一篇把 baseline 升级的兼容矩阵、策略迁移账本和分批 cutover 拆开了。

但有一个问题贯穿始终却没展开：升级完了，怎么确认治理能力没退步？

不是看”有没有报错”。报错是显式失败，容易发现。真正危险的是隐性退步：

  1. 某条规则升级后阈值变了，误判率悄悄上升了 3%，没人在意
  2. 某个 overlay 在迁移后变成了孤儿配置，不报错也不生效，团队以为还在受控
  3. 某条默认策略改了语义，前三个月没啥问题，第四个月遇到一个边界 case 才暴露

这篇写三件事：

  1. 怎样用回归验证集在升级后快速确认治理能力没静默退步
  2. 怎样用长期漂移检测抓住慢变化
  3. 周期性健康审查怎么排节奏，才不会变成走形式

1. 升级后最该怕的不是”报错”，是”静默退步”

先说清楚什么叫”静默退步”。

传统软件升级后，你跑一遍单元测试和集成测试，红绿灯一目了然。但治理策略不一样：它的效果不是”对或错”，而是”在某个精度和召回率上拦截了某类风险”。

baseline 升级后，可能出现以下情况：

  • 规则 ID 变了，overlay 的覆盖项变成孤儿，退回默认值，拦截精度下降但没报警
  • 动作语义变了，原来 soft_block 是”拦截+记录”，现在变成”拦截+记录+强制复审”，误伤率上升但没人投诉
  • 默认值漂移，某条规则从 enabled=true 变成 enabled=false，团队依赖的防护消失了但不知道

这些都是”系统在跑，没报错，但治理能力退步了”。

回归验证集要解决的就是：升级后不需要等真实事故来暴露问题，用一套预置的验证用例就能发现退步。

2. 回归验证集：最小结构

回归验证集不是从零发明的。它的思路和软件测试里的回归测试一样：有一套固定用例，每次变更后跑一遍，对比结果。

但治理策略的回归验证集和软件测试的关键区别在于：它的用例不是代码输入输出，而是”给定一条 prompt + 一组策略配置，策略应该怎么判定”。

2.1 用例类型

我建议至少覆盖以下三类：

正例（应该拦截的）

  • 已知有害内容的 prompt
  • 已知会触发 PII 检测的内容
  • 已知会触发成本上限的调用模式

反例（不应该拦截的）

  • 边界安全但内容敏感的正常业务 prompt
  • 模型输出包含合规 PII 但属于白名单场景
  • 高频调用但属于合法批处理

边界例（判决可能变化的）

  • 模糊内容的判定
  • 阈值附近的 prompt
  • 多规则交叉判定

2.2 用例的最小字段

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
regression_test_case:
  id: REG-001
  type: positive  # positive / negative / boundary
  description: "包含信用卡号的客户投诉文本"
  input:
    prompt: "客户投诉：我的信用卡号 4532-XXXX-XXXX-1234 被盗刷..."
    context:
      user_role: support_agent
      team: customer-service
  expected_result:
    triggered_rules: [PII_TEXT_V3]
    action: soft_block
    confidence_threshold: ">= 0.9"
  baseline_version: "2026-05-v2"
  last_verified: "2026-05-16"
  sensitivity: high  # 如果这个用例结果变了，必须立即调查

2.3 敏感度分级

不是所有用例都一样重要。建议给每个用例打敏感度标签：

  • high：核心安全规则，结果变化必须立即调查
  • medium：重要但容忍小幅波动，结果变化需要记录并在下一个审查周期确认
  • low：辅助规则，结果变化记录即可

敏感度分级的好处是：升级后不需要所有用例都绿灯才能推进。高敏感度的必须全过，中低敏感度的允许有少量变化但需要记录。

2.4 回归验证的执行时机

不是每次小改动都要全量回归。建议的时机：

  1. baseline 升级后：全量回归
  2. 策略调参后：只跑受影响的用例
  3. overlay 变更后：只跑对应团队的用例
  4. 定期健康审查时：全量回归（频率后面说）

3. 长期漂移检测：抓住慢变化

回归验证集解决的是”升级后有没有立即退步”。但还有一类问题是慢慢发生的：

  1. 模型在不更新策略的情况下，因为数据分布变化，判定结果悄悄漂移
  2. 用户的 prompt 风格逐渐变化，原来边界安全的 prompt 开始频繁触发误判
  3. 新业务场景上线，旧策略的覆盖率在不知不觉中下降

这些变化不会在升级那一刻爆发，而是像温水煮青蛙，等你发现的时候已经偏了很多。

3.1 漂移检测的最小指标

我建议跟踪以下几个指标：

拦截率漂移

每周统计各规则的触发率。如果某条规则的触发率在过去 4 周内持续上升或下降超过 10%，标记为”漂移中”。

误判率漂移

基于用户反馈和人工复审结果，统计各规则的误判率变化趋势。误判率持续上升意味着规则要么过时要么需要调参。

孤儿率漂移

每次策略变更后，扫描 overlay 引用。如果某条 overlay 引用的规则 ID 在 baseline 中不存在，标记为孤儿。孤儿配置的累计增长就是漂移信号。

覆盖率漂移

统计每周新增的 prompt 场景中，有多少没有被现有规则覆盖。如果”未覆盖”比例持续上升，说明规则集需要补充。

3.2 漂移检测的告警阈值

1
2
3
4
5
6
7
8
9
10
11
12
13
drift_alert_thresholds:
  trigger_rate_change_4w:
    warning: 10%
    critical: 25%
  false_positive_rate_trend:
    warning: "连续 2 周上升"
    critical: "连续 4 周上升"
  orphan_overlay_count:
    warning: 3
    critical: 10
  uncovered_scenario_rate:
    warning: 5%
    critical: 15%

3.3 漂移检测的自动化

最简做法：每周跑一次批处理脚本，计算以上指标，生成漂移报告，标记需要人工确认的条目。

不需要复杂的 ML 模型来做漂移检测。简单的统计方法就够了：看趋势、看变化率、看是否超出阈值。复杂方法容易引入”检测器本身的漂移”问题。

4. 周期性健康审查：怎么排节奏才不会走形式

回归验证集和漂移检测是工具。周期性健康审查是组织节奏——把这些工具的输出变成决策和行动。

很多团队做了健康审查，但最后变成了走形式：读一遍报告，说”没问题”，结束。问题出在两点：

  1. 审查节奏不对——太频繁就没人认真看，太稀疏就抓不住问题
  2. 审查没有决策闭环——发现问题后没人负责跟进

4.1 推荐的审查节奏

月度轻量审查

  • 跑一遍受影响用例的回归验证（不是全量）
  • 检查漂移报告中的 warning 级别条目
  • 确认本月策略变更是否全部有迁移账本记录
  • 产出：一份 1-2 页的月度健康摘要

季度深度审查

  • 全量回归验证
  • 检查所有漂移报告（含 critical 级别）
  • 评估规则集的覆盖率和有效性
  • 评估 overlay 孤儿率和继承完整性
  • 产出：一份季度健康报告 + 一组待办事项（明确责任人和截止日期）

年度全面体检

  • 重新评估规则集是否仍然匹配业务需求
  • 审查所有 exception 和 risk acceptance 的有效性
  • 评估治理平台整体的健康度趋势
  • 产出：年度治理健康报告 + 下一年度的治理路线图

4.2 审查的决策闭环

每次审查必须回答三个问题：

  1. 发现了什么问题？ — 从回归验证、漂移检测、覆盖率分析中提取
  2. 谁负责解决？ — 每个问题必须有明确责任人
  3. 什么时候解决？ — 每个问题必须有截止日期

如果审查后没有产出待办事项，要么是治理确实完美（概率极低），要么是审查没认真做。

4.3 审查结果跟踪

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
health_review_record:
  period: "2026-Q2"
  type: quarterly
  date: "2026-06-30"
  findings:
    - id: HF-001
      type: drift
      severity: warning
      description: "PII_TEXT_V3 误判率连续 3 周上升"
      owner: zhangsan
      deadline: "2026-07-15"
      status: open
    - id: HF-002
      type: regression
      severity: critical
      description: "边界用例 REG-042 在 baseline 升级后判定结果变化"
      owner: lisi
      deadline: "2026-07-05"
      status: open
  action_items_count: 2
  next_review: "2026-09-30"

5. 三件事的关系

回归验证集、漂移检测和周期性健康审查，解决的其实是同一个问题的三个时间尺度：

  1. 回归验证集：升级后的即时确认——“刚才的变更有没有搞坏什么？”
  2. 漂移检测：升级后的持续监测——“有没有慢慢变坏？”
  3. 周期性健康审查：定期的组织盘点——“整体还行不行？需要做什么调整？”

三者缺一不可。只有回归验证，你会错过慢变化；只有漂移检测，你会缺少组织层面的决策节奏；只有健康审查，你会缺少数据支撑变成纯讨论。

6. 常见坑

坑一：回归验证集只在升级时跑一次

升级后跑一遍就不管了，下次升级发现用例已经过时，需要全部重写。回归验证集应该是活文档，每次发现新边界 case 都要加进去。

坑二：漂移检测只看 trigger rate

trigger rate 漂移只是表象。真正要盯的是：为什么会漂？是用户行为变了，还是规则本身老化了，还是 baseline 升级引入了隐式变化？不追问原因，漂移检测就只是图表。

坑三：健康审查没有决策闭环

读报告、讨论、结束。问题照旧。每次审查必须产出带责任人和截止日期的待办，并在下次审查时确认完成情况。

坑四：所有用例敏感度都标 high

结果就是每次回归都”全部必须过”，反而降低了效率。区分敏感度是为了让高敏感度的用例得到及时关注，低敏感度的允许有合理波动。

7. 一周最小落地顺序

  1. Day 1
    建立回归验证集模板，至少包含 10 个用例（3 正例 + 3 反例 + 4 边界例），每个用例标好敏感度
  2. Day 2
    在当前 baseline 上跑一遍回归验证，确认基线结果，把结果存为参照
  3. Day 3
    搭建漂移检测的周度指标计算脚本，至少覆盖 trigger rate 变化和孤儿率
  4. Day 4
    定义月度轻量审查和季度深度审查的 checklist 和模板
  5. Day 5-6
    把漂移检测脚本跑一遍，确认结果可读，调整阈值
  6. Day 7
    安排第一次月度轻量审查，产出健康摘要

小结

升级后最怕的不是报错，是静默退步。回归验证集让你能快速发现退步，漂移检测让你抓住慢变化，周期性健康审查让这些发现变成行动。

如果这周只能做一件事，我会先把回归验证集搭起来——哪怕只有 10 个用例，也比什么都没有强。因为等你真正需要它的时候，从零开始已经来不及了。

下一篇可以继续写：LLM 治理平台多环境策略同步、配置即代码与部署流水线最小实践。

本文永久链接: https://www.mulianju.com/learning-notes/ai-learning-notes-llm-governance-post-upgrade-regression-verification-drift-detection-periodic-health-review/