AI 学习笔记（五十八）：LLM 平台治理采纳率分析、策略有效性衰减与年度升级节奏
上一篇讨论了平台默认配置进入运行后的三个问题：配置要分层发布，团队覆盖层要做版本兼容，平台误判时要能快速降级并保留证据。
这些问题解决之后，平台治理并没有结束。相反，它进入了更容易被忽略的阶段：默认配置已经发布了，团队也陆续接入了，仪表盘上看起来一切都在运行。这个阶段最危险的地方，是团队很容易把“配置被接入”当成“治理生效”。
但 LLM 治理能力不是装上就一直有效。模型版本会换，业务场景会变，团队复核容量会波动，攻击样本和误用方式也会迁移。一个去年有效的策略，今年可能只是增加噪声；一个刚发布时很稳的默认配置，经过几轮团队覆盖后，也可能已经和平台基线偏离很远。
所以这一篇继续讨论三个运行期问题：
- 平台治理采纳率应该怎么分析，避免只看接入数量
- 治理策略有效性为什么会衰减，应该看哪些早期信号
- 平台治理能力自身怎样安排年度升级，而不是靠临时补丁续命
1. 采纳率不能只看启用开关，要看关键路径是否真的经过平台
平台治理上线后，最容易统计的指标是 enabled_team_count：有多少团队打开了默认配置，有多少应用接入了 SDK，有多少链路上报了审计字段。
这些指标有用，但只能说明“入口接上了”。它们不能说明关键请求是否真的走过平台治理路径，也不能说明团队有没有把高风险场景绕到本地逻辑里。
更稳妥的采纳率分析，至少要分三层看：
config_adoption：团队是否启用了平台默认配置traffic_adoption：真实流量里有多少经过平台治理路径decision_adoption：关键风险决策是否由平台策略参与
例如某个团队启用了高风险回答审计配置，但只有 20% 的真实外部回答链路上报到了平台，剩下的链路仍然走本地逻辑，那它的治理采纳就不能算完成。再比如平台只记录了请求，却没有参与风险分级、复核路由或回滚判断，那它更像旁路日志，不是治理能力。
可以用一个轻量台账避免采纳率被虚高统计：
1 | platform_adoption_review: |
这里真正需要关注的，不是所有团队都达到 100%，而是每个团队的采纳状态是否被正确命名。config_enabled_but_not_governed 比一个漂亮的接入率数字更有价值，因为它提醒平台：现在的问题不是继续推广，而是要回到流量路径和决策路径排查。
2. 采纳质量要和团队覆盖层一起看
平台默认配置发布后，团队覆盖层会继续存在。上一期说过，覆盖层不是例外清单，而是本地经验。问题在于，如果采纳率只看平台层，就会漏掉覆盖层对治理效果的真实影响。
一个团队可能启用了平台 baseline，但在覆盖层里调低了抽样比例、放宽了复核阈值、延后了强拦截模式。单独看平台采纳，它是绿色；合并覆盖层之后，它可能已经和平台期望相差很远。
所以采纳质量要看三件事：
- 覆盖层改了平台默认配置的哪些行为
- 这些改动有没有理由、负责人和重新评估条件
- 改动后是否仍然满足平台最低治理底线
一个简单的合并视图可以长这样：
1 | effective_governance_view: |
这个视图的重点，是把“平台配置”和“团队实际生效配置”放在一起。否则平台很容易以为策略已经落地，业务也容易以为自己已经接入，最后只有事故发生时才发现真实行为不是任何一方以为的样子。
3. 策略有效性会衰减，因为系统不是静止的
治理策略不是一次验证后永久有效。
LLM 应用变化太快：模型版本升级会改变输出分布，prompt 模板调整会改变风险暴露，工具调用能力增强会改变事故路径，业务团队扩场景会带来新语义，用户也会逐渐学会绕过旧规则。
所以策略有效性会自然衰减。衰减不一定意味着策略错了，而是说明它和现实系统之间的距离变大了。
常见衰减信号包括：
alert_noise_growth：告警变多，但真正需要处理的比例下降manual_review_precision_drop：人工复核命中率下降escape_case_shift：逃逸样本从旧类型迁移到新类型overlay_patch_growth：团队覆盖层补丁持续增加rollback_frequency_growth：同类策略回滚次数增加
这些信号里，最容易被忽略的是 overlay_patch_growth。如果多个团队都在覆盖层里给同一条平台策略打补丁，说明问题很可能已经不是团队特殊情况，而是平台策略本身需要重新校准。
可以把策略衰减监控做得很小：
1 | strategy_decay_watch: |
这里的 action 不是立刻下线策略，而是提醒平台在下一轮扩大前先重新校准。很多治理失败不是因为没有策略，而是明知道策略已经老化，还继续拿它当稳定基线。
4. 有效性复盘要区分策略失效和场景迁移
策略衰减出现后，平台团队容易直接把问题归因到“规则不准”。但在 LLM 系统里，规则不准只是其中一种可能。
我会先区分四类情况：
strategy_misfit：策略设计本身不适合当前风险threshold_drift：策略方向仍对，但阈值需要校准scenario_shift：业务场景变了，原策略覆盖不到新风险operation_gap：策略有效，但复核、告警、回滚承接断了
这四类对应的处理方式不同。策略不适合，要重新设计；阈值漂移，要回放样本和调参；场景迁移，要重新做风险建模；运营断点，则要补队列、值班、通知和回滚路径。
如果不做区分，平台很容易把所有问题都变成调阈值。阈值越调越复杂，策略越来越难解释，团队覆盖层也会越来越厚。
有效性复盘最好保留这样的判断：
1 | strategy_effectiveness_review: |
这类记录能避免团队把“新场景没覆盖”误判成“旧策略失败”。旧策略可以继续服务旧路径，新场景需要新治理设计。
5. 年度升级节奏不是大版本仪式，而是治理资产清理机制
平台治理做久了，配置、策略、覆盖层、仪表盘和回滚协议都会越来越多。每季度只做局部调整，时间长了会形成一堆历史包袱：没人敢删的旧策略、没人记得原因的覆盖、仍被引用但已经低效的告警、过期但还在文档里的复核流程。
所以平台治理需要年度升级节奏。
年度升级不是为了制造大版本，也不是把所有配置重新命名一遍，而是做一次治理资产清理和基线重建。它至少要回答五个问题：
- 哪些策略已经被稳定复用，可以进入新的
baseline - 哪些策略有效性衰减，需要重新校准或降级
- 哪些团队覆盖层已经具备平台化条件
- 哪些历史例外、旧阈值、旧告警应该退场
- 下一年度有哪些新模型、新工具、新业务场景需要提前预留治理能力
一个年度升级台账可以保持很朴素：
1 | annual_governance_upgrade: |
这张表的价值，是让平台治理每年都有一次“清账”。否则治理平台会像很多内部系统一样，功能只进不出，复杂度只涨不降。
6. 升级窗口要保护业务节奏，也要保护治理判断
年度升级听起来很合理，但如果安排不好，也会变成新的风险源。
平台治理升级通常会碰到业务发布窗口、模型升级窗口、合规审计窗口和团队季度目标。把所有治理变更集中到一个时间点，很容易让团队同时面对模型变化、业务变化和治理变化，最后出了问题也分不清来源。
所以升级窗口要有两条保护线：
- 保护业务节奏：不要在高峰发布期强推大范围治理行为变化
- 保护治理判断：不要把模型大升级、业务大改版和治理强策略升级叠在一起
更好的方式是把年度升级拆成几个阶段：
inventory：盘点策略、覆盖层、告警、回滚协议simulation：用历史样本回放新基线和新阈值shadow：真实流量只记录，不改变用户可见行为progressive_rollout：按团队和场景逐步启用cleanup：下线旧策略和过期覆盖层
这样升级不是一次“大切换”，而是一段有证据、有灰度、有清理动作的运行过程。
7. 小结：平台治理要从接入管理走向生命周期管理
LLM 平台治理能力发布以后，不能只看有多少团队接入。更重要的是关键流量有没有经过平台，风险决策有没有使用平台策略，团队覆盖层合并后是否仍然满足最低治理底线。
策略有效性也不能默认稳定。模型、业务、工具和用户行为都会改变，治理策略会随时间衰减。平台要提前看告警噪声、复核命中率、逃逸样本迁移、覆盖层补丁增长和回滚频率，而不是等事故发生后才承认策略过期。
年度升级节奏的意义，不是做一个漂亮的大版本，而是让治理资产有机会被重新校准、合并、下线和补强。只有这样，平台治理才不会从风险控制能力慢慢变成历史配置堆积。
如果说上一篇讨论的是“平台治理怎样安全发布”，这一篇回答的就是“发布以后怎样判断它还活着、还有效、还值得继续维护”。
下一篇可以继续讨论治理平台和业务团队之间的协作机制：平台如何给团队提供自助诊断能力，团队如何把本地经验反哺平台，以及治理争议怎样进入仲裁和复盘闭环。