Canary、回滚与变更管理
本节目标
将通过离线门的LLM发布单元渐进引入真实流量，并在扩大前明确定义暂停、回滚和证据不足时的动作。
为什么LLM发布更需要渐进证据
离线评测无法覆盖所有真实输入、供应商容量、工具权限和用户行为。LLM输出还有随机性，简单比较几个请求很容易把噪声当回归。Canary的目的不是“先让少数用户帮我们测试”，而是在受控风险下收集离线无法获得的证据。
发布前的变更记录
每次发布至少应说明：
- 候选和当前基线manifest的精确差异；
- 改动理由、预期改善与已知风险；
- 离线评测、安全检查与未解决的不确定项；
- 实验单元、流量分配和污染防护；
- 扩大、暂停、回滚条件与决策者；
- 回滚manifest、紧急降级和工具禁用方案；
- 观察时间、最小样本量、标签延迟与事后评审时间。
对高风险变更，人工审批是合理的。审批不应只是一个可点击按钮；审批者需看到与本次固定manifest绑定的证据。
影子、Canary与A/B的区别
| 方式 | 候选输出是否影响用户 | 主要能回答什么 |
|---|---|---|
| 离线回放 | 否，使用历史或合成输入 | 已知样本上是否回归 |
| 影子运行 | 否，复制真实请求但不采用结果 | 真实输入分布、延迟、工具模拟结果和候选差异 |
| Canary | 是，限定范围 | 候选在真实因果链中是否可运营 |
| A/B实验 | 是，通常为产品效果优化 | 两种方案对业务结果的相对影响 |
影子运行若会真正调用发邮件、下单或写数据库工具，就不再是“不影响用户”。需要工具沙箱、只读模式或副作用隔离，而不是简单复制全部请求。
流量分配要避免污染
对多轮会话，一个用户在同一任务中反复切换release会污染上下文与比较。通常需按用户、会话或任务进行稳定分组，并记录实际分配理由。同时还要检查：
- 候选和基线是否服务相近的任务、地区与时段；
- 是否因高价值用户被排除而只得到低风险结论；
- 跨release共享的缓存是否返回了另一版本的答案；
- 外部供应商容量和时段是否同时变化。
扩大、暂停与回滚
flowchart LR A["冻结 release manifest"] --> B{"离线质量、安全、成本门通过？"} B -->|否| R["拒绝发布并保留证据"] B -->|是| S["影子运行：隔离副作用"] S --> C["限定范围 Canary"] C --> D{"关键伤害或越权？"} D -->|是| I["停止流量 / 事故响应 / 禁用能力"] D -->|否| E{"证据充分且所有 gate 通过？"} E -->|否，信号冲突或标签未回流| P["保持或暂停，不宣称成功"] E -->|是| F{"已到计划流量？"} F -->|否| C F -->|是| G["晋级并持续监控"] I --> H["回滚 manifest 或业务补偿"]
图 1 LLM 发布门禁状态机。文字替代：固定 release 先过离线门，再经隔离副作用的影子运行和限定 Canary；关键伤害立即进入事故响应，证据不足保持或暂停，只有质量、安全、性能和成本门都满足才逐级扩大；已产生的副作用另走补偿。图依据本节发布决策表、Kubernetes rollout/rollback 通用机制和所引评测指南整理；Mermaid 源码即再生成方式。
不要把“没触发告警”作为唯一扩大条件。一个决策表可以是：
| 证据 | 动作 |
|---|---|
| 关键安全失败、越权工具或明确用户损害 | 停止流量，遵循事故程序，必要时回滚/禁用功能 |
| 延迟或错误显著恶化 | 暂停扩大，核对release与供应商状态，必要时回滚 |
| 质量信号矛盾、标签未回流 | 保持当前范围或停止，不声称已成功 |
| 样本量和观察周期达到计划，质量/安全/性能/成本均满足策略 | 按预定阶梯扩大，继续观察 |
观察时间与流量比例没有通用数值：应从事件率、标签延迟、预期效应和风险反推。
回滚的完整性
回滚对象是发布manifest，包括Prompt、上下文、检索快照与配置、模型、工具、网关路由和安全策略。如果新release已写入外部状态，回滚代码不会自动撤销发送的邮件或创建的订单；这需要业务补偿方案与人工处置。
还要区分“回滚到旧release”和“降级为不使用LLM/不调用工具”。外部供应商故障或数据泄露时，旧release可能同样不安全。
练习与自测
为“可以读取日程并创建会议”的Agent设计一个发布计划。列出影子环境如何禁用写操作、Canary分组、质量/安全/成本指标、扩大条件和已创建会议的补偿方案。自测：
- 为什么影子Agent不能使用真实写工具？
- 为什么每次请求随机分组会污染多轮会话？
- 哪些故障中“回滚旧release”不如“停用LLM功能”安全？
小结与下一步
Canary是一次有预注册判定条件的受控变更，不是一个万能百分比。当判定失败或用户受影响时，按 事故响应与持续改进 处置。
参考资料
- Kubernetes Deployments（访问于2026-07-14；版本替换与回滚的通用基础）
- Kubernetes Canary Deployments（访问于2026-07-14；流量分配实现取决于网关/服务网格等组件）
- OpenAI Evaluation best practices（访问于2026-07-14）