AI 学习笔记（六十四）：LLM 治理 baseline 升级兼容矩阵、策略迁移账本与跨团队 cutover 节奏

发表于 分类于 阅读次数： Changyan： 本文字数： 5.8k 阅读时长 ≈ 5 分钟
上一篇讲了治理平台自己的 change safety 分级与回退。这篇继续往下走：baseline 升级时怎样用兼容矩阵提前发现继承断裂，怎样用策略迁移账本让每一处改动可追溯，以及跨团队 cutover 怎样排节奏才不会一锅端。

上一篇把治理平台的 change safety 拆成了三类变更——策略调参、团队 overlay 调整、baseline 升级——并且给每类配了风险分级、评审模板和回退方案。

但那篇留下了一个尾巴：baseline 升级具体怎么做，才不会把已经稳定的团队配置一起冲掉？

这个问题不是”回滚配置文件”就能解决的。因为 baseline 升级本质上是在改一条继承链：

  1. 平台 baseline 定义了默认规则集
  2. 各团队在 baseline 上叠加了自己的 overlay
  3. overlay 里有些是显式覆盖，有些是”依赖 baseline 某条规则存在而成立的隐式依赖”

baseline 一升级，显式覆盖通常还能撑住，隐式依赖就容易断。

这篇继续写三件事：

  1. 怎样用兼容矩阵在升级前就识别继承断裂
  2. 怎样用策略迁移账本让每一处改动有据可查
  3. 跨团队 cutover 怎样排节奏，才能避免”一升级全挂”的局面

1. Baseline 升级的真实风险，不在回滚，而在继承断裂

很多团队对 baseline 升级的理解停留在”推一份新配置，有问题就回滚”。

但问题在于：回滚只能恢复 baseline 自身，恢复不了那些因为 baseline 变了而悄悄失效的 overlay 依赖。

举几个真实场景：

场景 A：规则 ID 变了

旧 baseline 有一条 PII_DETECTION_V2，某团队在 overlay 里写了 PII_DETECTION_V2.threshold = 0.95。新 baseline 把这条拆成了 PII_TEXT_V3 和 PII_IMAGE_V3，旧 ID 直接删了。

结果：overlay 里的覆盖项变成孤儿配置，不报错也不生效，团队以为自己还受控，实际已经退回 baseline 默认值。

场景 B：动作语义变了

旧 baseline 里 HARMFUL_CONTENT.confidence >= 0.9 → soft_block，某团队为了调试临时改成 → warn。新 baseline 把 soft_block 的含义从”拦截并记录”改成”拦截并记录，同时强制人工复审”。

结果：团队把动作改成 warn 的意图是”先放行再看”，但 baseline 升级后 soft_block 语义变了，等团队切回来时行为已经不一样了，而他们可能根本不知道。

场景 C：默认值漂移

旧 baseline 某条规则默认 enabled = true，某团队从未显式覆盖过这条——他们依赖的就是”默认开着”。新 baseline 把默认值改成了 enabled = false。

结果：这条规则在团队层面静默关闭，没有任何告警，也没有任何 overlay 会提醒你”你曾经依赖这个默认值”。

这三个场景的共同特征是：问题不在 baseline 文件本身，而在 baseline 与 overlay 之间的继承关系。单纯的配置回滚解决不了继承断裂。

2. 兼容矩阵：升级前先把”谁依赖了什么”摊开

兼容矩阵的核心思路很简单：在升级之前，把旧 baseline 的每一条规则，和新 baseline 的每一条规则，做一次结构化比对。

比对的维度不需要很多，但必须覆盖以下几项：

2.1 规则 ID 映射

旧规则 ID → 新规则 ID。

如果 ID 没变，标记为 stable；如果拆分了，标记为 split 并记录拆分关系；如果合并了，标记为 merged；如果删除了，标记为 removed。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
compatibility_matrix:
  rule_id_mapping:
    - old: PII_DETECTION_V2
      new: [PII_TEXT_V3, PII_IMAGE_V3]
      change_type: split
      migration_note: "文本和图像 PII 检测拆分为独立规则，overlay 中引用 PII_DETECTION_V2 的配置需要分别映射"

    - old: HARMFUL_CONTENT
      new: HARMFUL_CONTENT
      change_type: stable
      action_semantics_changed: true
      migration_note: "soft_block 语义变更为拦截+强制人工复审，依赖 soft_block 行为的 overlay 需要确认意图"

    - old: CODE_INJECTION_V1
      new: null
      change_type: removed
      migration_note: "已被 CODE_SECURITY_V2 完全替代，无自动映射"

2.2 动作语义变更

即使规则 ID 没变，动作的含义也可能变了。兼容矩阵必须单独标记这类变更。

2.3 默认值漂移

把所有默认值变化的字段列出来，包括从 true → false、阈值从 0.8 → 0.9 等。

2.4 影响面评估

每条规则变了，会影响哪些团队？这需要结合 overlay 数据来算。

1
2
3
4
5
6
7
8
9
10
11
impact_assessment:
  PII_DETECTION_V2:
    affected_teams:
      - team: payment
        overlay_refs: [PII_DETECTION_V2.threshold]
        risk: high
        reason: "显式覆盖了阈值，ID 变更后配置成为孤儿"
      - team: content-moderation
        overlay_refs: []
        risk: medium
        reason: "未显式覆盖但依赖默认启用，拆分后需确认两个新规则都启用"

这一步的产出是一份结构化文档，不是一行 release note 概要。它要能让每个受影响团队自己读、自己判断、自己决定怎么跟。

3. 策略迁移账本：每一处改动都要有据可查

兼容矩阵解决的是”升级前识别风险”，策略迁移账本解决的是”升级后追溯发生了什么”。

3.1 为什么要单独搞一个账本？

有些人会觉得”git log 不就是账本吗？”不完全对。

git log 记录的是配置文件的变化，但它不记录以下信息：

  1. 这条变化是因为 baseline 升级引起的，还是团队自己改的
  2. 这条变化在兼容矩阵里对应哪一条映射
  3. 这条变化是自动迁移的，还是人工确认后手动改的
  4. 这条变化在灰度期间有没有引起告警

策略迁移账本就是把这些信息补上。

3.2 账本的最小字段

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
migration_ledger:
  baseline_version: "2026-05-v2"
  cutover_date: "2026-05-20"
  entries:
    - entry_id: MIG-001
      team: payment
      old_rule: PII_DETECTION_V2
      new_rules: [PII_TEXT_V3, PII_IMAGE_V3]
      change_type: split
      overlay_action: manual_remapping
      operator: zhangsan
      verified: true
      verification_date: "2026-05-19"
      notes: "团队选择把原阈值 0.95 同时应用到两条新规则"

    - entry_id: MIG-002
      team: content-moderation
      old_rule: HARMFUL_CONTENT
      new_rules: [HARMFUL_CONTENT]
      change_type: action_semantics_changed
      overlay_action: accepted_new_semantics
      operator: lisi
      verified: true
      verification_date: "2026-05-18"
      notes: "团队确认 soft_block 新语义（拦截+强制复审）符合其安全要求"

3.3 账本的三个用法

用法一：灰度期间的对照表

某个团队在灰度期间报告”PII 检测好像漏了”，直接查账本：这个团队的 PII overlay 做了什么迁移？映射关系对不对？阈值有没有带过来？

用法二：升级后的审计依据

如果后续发现某条规则静默失效了，查账本：这条规则在升级时有没有被迁移？谁确认的？当时怎么判断的？

用法三：下一次升级的输入

下一次 baseline 升级时，上一次的迁移账本就是兼容矩阵的输入之一。上一次哪些规则容易出问题，哪些团队的 overlay 迁移阻力大，都可以提前参考。

4. 跨团队 cutover 节奏：不要一锅端

兼容矩阵和迁移账本解决的是”能不能看清楚风险”，但升级真正出事，往往是因为节奏没排好。

4.1 为什么要分批 cutover？

如果所有团队同时切换到新 baseline，出了问题就是全局性的。而且不同团队对风险的承受能力不一样：

  1. 支付团队：任何误伤都可能影响交易，必须最稳
  2. 内部工具团队：容错空间大，可以先当小白鼠
  3. 内容审核团队：漏检比误杀更危险，对新规则的反应速度要求高

分批 cutover 的目标不是”慢”，而是”每一批都能观察、能判断、能回退”。

4.2 分批策略

我推荐按以下维度排批次：

第一批：内部工具 / 低风险团队

  • 先让容错空间最大的团队切过去
  • 观察期至少 48 小时
  • 重点看：有没有继承断裂、有没有静默失效、有没有告警误触发

第二批：中等风险团队

  • 根据第一批的反馈调整兼容矩阵和迁移账本
  • 观察期缩短到 24-48 小时

第三批：高敏感团队（支付、合规、安全）

  • 前两批都稳定了再切
  • 切换前要求每个团队在账本里确认自己的 overlay 迁移状态

4.3 每批 cutover 的最小 checklist

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
cutover_checklist:
  batch: 1
  teams: [internal-tools, dev-platform]
  before_cutover:
    - compat_matrix_reviewed: true
    - migration_ledger_populated: true
    - rollback_bundle_tested: true
    - canary_percentage: 10
  during_cutover:
    - monitor_false_block_rate: true
    - monitor_missed_risk_rate: true
    - monitor_overlay_orphan_count: true
  after_cutover:
    - verification_period_hours: 48
    - no_critical_alerts: pending
    - overlay_integrity_check: pending
  decision:
    proceed_to_next_batch: pending
    rollback_needed: false

4.4 批次间的信息传递

每批 cutover 结束后，不只是看”有没有报错”，还要把以下信息传给下一批：

  1. 实际发生的继承断裂有哪些（兼容矩阵可能漏判）
  2. 哪些迁移路径比预期复杂（迁移账本需要补说明）
  3. 灰度观察期有没有发现新问题（下一批的观察项要更新）
  4. 团队反馈的典型困惑（下一批的迁移指引要更明确）

这比简单地”第一批 OK 就推第二批”要靠谱得多。

5. 一个完整升级周期的最小流程

把前面几块串起来，一次 baseline 升级的最小流程大概是：

  1. 准备期（Day 1-3）

    • 生成兼容矩阵
    • 识别所有受影响的 overlay
    • 填充迁移账本的”计划”部分

  2. 预演期（Day 4-5）

    • 在 staging 环境做一次完整 dry-run
    • 验证回滚 bundle 能正确恢复继承关系
    • 根据预演结果修正兼容矩阵

  3. 分批 cutover（Day 6-12）

    • 第一批 + 48h 观察
    • 第二批 + 24-48h 观察
    • 第三批

  4. 收尾（Day 13-14）

    • 完成迁移账本的”实际”部分
    • 确认所有团队的 overlay 不再有孤儿配置
    • 总结本轮升级的经验，写入下次升级的参考输入

6. 常见坑

坑一：兼容矩阵只做了一半

只比对了规则 ID 和阈值，没比对动作语义和默认值漂移。结果看着”兼容”，实际隐式依赖全断了。

坑二：迁移账本只在升级时用了一次

升级完就不管了，后续审计时发现配置已经漂移，和账本对不上。迁移账本应该在每次 overlay 变更时也更新，而不是只在 baseline 升级时才写。

坑三：分批 cutover 但没有批次间信息传递

每批独立做，前一批踩的坑没有传给后一批，导致同样的错误重复出现。

坑四：回滚只回 baseline，不回 overlay

baseline 回滚了，但 overlay 已经按新 baseline 迁移过了，结果回到旧 baseline 后 overlay 又变成不匹配状态。回滚必须覆盖 baseline + overlay + 迁移账本状态，三者一起回。

7. 一周最小落地顺序

  1. Day 1
    为下一次 baseline 升级搭建兼容矩阵模板，至少覆盖规则 ID 映射、动作语义变更和默认值漂移
  2. Day 2
    扫描所有团队的 overlay，标记每条 overlay 引用了哪些 baseline 规则，形成影响面评估
  3. Day 3
    搭建迁移账本模板，至少包含 entry_id、团队、旧规则、新规则、变更类型、迁移操作、确认状态
  4. Day 4
    定义分批 cutover 策略，按风险等级把团队分到三批，每批设观察期
  5. Day 5
    在 staging 环境做一次 dry-run，验证兼容矩阵的覆盖度
  6. Day 6-7
    执行第一批 cutover，填充迁移账本的”实际”部分，确认观察指标

小结

Baseline 升级最怕的不是”推了一份有 bug 的配置”，而是”配置本身没 bug，但继承关系悄悄断了”。

兼容矩阵、策略迁移账本和分批 cutover，三件事解决的是同一个问题的三个阶段：

  1. 兼容矩阵：升级前，把风险摊开
  2. 迁移账本：升级后，让每一处变化可追溯
  3. 分批 cutover：升级中，让每一批都能安全观察和回退

如果这周只能做一件事，我会先把兼容矩阵搭起来。因为只要能把”谁依赖了什么”摊开看，后面两步的阻力会小很多。

下一篇可以继续写：LLM 治理平台升级后的回归验证集、长期漂移检测与周期性健康审查。

本文永久链接: https://www.mulianju.com/learning-notes/ai-learning-notes-llm-governance-baseline-upgrade-compatibility-matrix-strategy-migration-ledger-cross-team-cutover-cadence/