Wiki Notes

Appearance

02. 发布、灰度与回滚治理 ​

版本：v1.1

最后更新：2026-07-08

适用对象：已经把 LLM、RAG 或 Agent 系统做出来，但还没有把发布、灰度、回滚、人工兜底和事故切换做成标准流程的团队

很多团队第一次做 AI 发布时，心里默认的还是传统后端发版模型：

  • 代码改完
  • 测一下
  • 发布

但 LLM 系统真正会上线的对象，通常不只是代码：

  • Prompt / developer instructions
  • 模型版本或模型路由
  • 检索参数、rerank 参数、过滤规则
  • 工具 schema、审批策略、人机接管规则
  • 会话状态策略、缓存策略、长任务执行策略

这意味着 AI 发布更像：

  • release bundle

而不是普通的单一代码提交。

0.1 发布不是“把新版本推上去”，而是控制风险半径 ​

OpenAI 当前 API deployment checklist、Production best practices、Conversation state、Safety best practices 放在一起看，会很容易得到一个更贴近生产的结论：

  • AI 发布的核心不是“怎么发”
  • 而是“怎么在真实流量里控制错误半径、恢复速度和证据完整性”

也就是说，一个成熟团队做发布时真正关心的通常是：

  • 这次改了哪些运行对象
  • 哪些对象可以先灰度
  • 哪些对象出事时要先冻结
  • 哪些对象要分层回滚

1. 为什么 AI 发布天然比普通发版更容易失控 ​

因为同一轮变更可能同时影响：

  • 输出风格
  • 工具调用路径
  • 检索证据范围
  • token 成本
  • 延迟分布
  • 审批命中率
  • 风险误放行率

OpenAI 当前 API deployment checklist 和 Production best practices 都在强调部署质量、可靠性、成本和恢复能力，这说明发布本身就是生产能力的一部分，不只是上线动作。

2. 发布对象到底应该包含什么 ​

一份更完整的 AI 发布包，至少建议带上：

  1. code version
  2. model version / route policy
  3. prompt version
  4. tool schema version
  5. retrieval config version
  6. safety / approval policy version
  7. eval baseline id
  8. rollback target

如果缺少这些对象，你就会经常碰到这种情况：

  • 版本已经坏了，但说不清是 Prompt 变了、模型变了，还是 rerank 变了

2.1 release bundle 最好是可版本化、可回放、可回退的 ​

很多团队会把发布对象拆散在：

  • 代码仓库
  • Prompt 配置
  • 工具配置
  • 检索配置
  • 值班文档

最后真正出事时，团队知道：

  • “这周发了很多东西”

但不知道：

  • “究竟是哪一组东西一起构成了当前线上行为”

更稳的做法通常是把一次发布显式沉淀成：

  • release bundle

这个 bundle 至少要能回答：

  • 当前线上模型与路由是什么
  • prompt / retrieval / tool / approval 用的是哪一版
  • 对应跑的是哪套 eval / gate profile
  • 回滚时要回到哪个 bundle

2.2 发布对象最好按“可独立回退的层”分组 ​

不是所有变更都应该被绑死在一起。

更适合独立分组的对象通常包括：

  • model / route layer
  • prompt layer
  • retrieval / rerank layer
  • tool / schema layer
  • policy / approval layer
  • state / cache / execution layer

这样一旦出现问题，团队就能更快判断：

  • 是只回退 prompt
  • 还是只冻结工具策略
  • 还是整个 bundle 一起撤

3. 灰度到底在验证什么 ​

灰度不只是“少量用户先试试”。

更实用的理解是：

  • 用受控流量验证新版本是否在真实输入分布下仍然成立

3.1 质量维度 ​

  • 引用是否更准
  • 工具误调用是否上升
  • 长任务完成率是否下降

3.2 运行维度 ​

  • P95 / P99 延迟是否抖动
  • token 成本是否突增
  • 缓存命中是否下降

3.3 风险维度 ​

  • 高风险审批是否误放行
  • 拒答率是否异常变化
  • 越权工具调用是否增加

所以灰度的核心不是“先放一点”，而是：

  • 先验证哪几类风险最值得先看

3.1 灰度样本最好和门禁桶一一对应 ​

很多团队会灰度一批流量，但灰完以后其实并不知道：

  • 它覆盖了哪些关键任务桶

更稳的做法通常是让灰度对象和门禁桶对齐，例如：

  • 高频主任务桶先灰度
  • 高风险桶后灰度
  • 新能力桶单独观察
  • 核心租户桶单独审批

这样灰度窗口里看到的异常，才更容易直接对应到：

  • 哪个桶掉了
  • 哪类风险先冒头了

4. 哪些场景更适合做影子流量 ​

影子流量特别适合下面这些变化：

  • 换模型
  • 换检索策略
  • 换 rerank
  • 调 Prompt 主骨架
  • 调工具选择逻辑

因为这类变化的价值往往在于：

  • 想先看真实输入下的行为差异

但又不想立刻影响线上主决策。

4.1 shadow 更适合回答“会不会变”，canary 更适合回答“能不能放” ​

两者经常被混在一起，但价值不同：

  • shadow
    • 先并行跑
    • 不改主决策
    • 更适合看行为差异
  • canary
    • 真实服务一小部分流量
    • 会真正影响结果
    • 更适合看是否可承受上线

也就是说，更成熟的节奏通常不是二选一，而是：

  • 先 shadow
  • 再 canary
  • 再 monitored rollout

5. 灰度比例不是唯一控制杆 ​

更稳的 AI 灰度通常要同时控制：

5.1 人群 ​

  • 内部用户
  • 低风险租户
  • 指定业务线

5.2 任务类型 ​

  • 只灰度摘要
  • 不灰度自动执行
  • 只灰度低风险问答

5.3 风险等级 ​

  • 只放 P0 / P1 任务
  • 高风险动作保持人工确认

5.4 流量时间窗 ​

  • 先在白天值班时段放量
  • 非值班时段自动降级

这样做比单纯设一个 10% traffic 更可控。

5.5 租户、桶和时段组合控制，通常比“纯百分比”更稳 ​

AI 系统很少是完全均匀流量。

更实用的发布控制通常会同时指定：

  • 哪些租户
  • 哪些任务桶
  • 哪些时段
  • 哪些 risk class

例如：

  • 白天值班时段给内部租户放新 route
  • 晚上只保留低风险问答灰度
  • 周末不扩大写动作范围

这样做的本质是：

  • 把发布控制从“随机抽 10%”
  • 提升到“精确控制风险暴露面”

6. 回滚为什么必须先设计，不要等出事再想 ​

LLM 系统的回滚对象通常不只一种。

至少要区分：

6.1 Prompt 回滚 ​

适合：

  • 风格走偏
  • 工具选择逻辑异常
  • 结构化输出稳定性下降

6.2 模型回滚 ​

适合：

  • 新模型成本过高
  • 延迟不可接受
  • 某些任务质量明显退化

6.3 检索配置回滚 ​

适合：

  • 召回池质量变差
  • 版本过滤失效
  • hybrid / rerank 策略异常

6.4 工具策略回滚 ​

适合：

  • 工具误调用变多
  • 副作用动作风险升高
  • 参数校验规则失效

如果没有分层回滚，你只能：

  • 把所有问题都当成“大回退”

这会让恢复成本和业务影响都变大。

6.5 回滚半径最好提前定义 ​

更成熟的团队通常不会等事故里再决定“撤多大”。

可以提前定义几类回滚半径：

  • 单租户回滚
  • 单任务桶回滚
  • 单 route / 单 model 回滚
  • 单 policy / 单 tool family 回滚
  • 全 bundle 回滚

这一步很关键，因为很多事故其实并不需要：

  • 全站一起退

而是需要：

  • 先把最危险的那一层收住

6.6 incident mode 往往比立即全量回滚更实用 ​

很多事故初期，团队还没完全定位根因。

这时一个更稳的选择通常是先进入：

  • incident mode

也就是临时切换到更保守的运行状态，例如：

  • 强制只读
  • 强制人工审批
  • 关闭高风险工具
  • 冻结新 route / 新 bundle
  • 切回小范围稳态流量

这比一上来盲目全量回滚更好，因为：

  • 可以先止血
  • 再有序定位到底是哪层坏了

7. 发布门禁最值得先卡哪几类检查 ​

7.1 评测门禁 ​

  • 是否跑过关键任务集
  • 是否跑过高风险样例
  • 是否和基线版本比较

7.2 运行门禁 ​

  • 成本预算是否超线
  • 延迟是否明显恶化
  • 速率限制余量是否足够

7.3 安全门禁 ​

  • 高风险动作是否仍需审批
  • 红队样例是否回归
  • 关键工具 schema 是否通过校验

7.4 可回滚门禁 ​

  • 是否记录了回滚目标
  • 是否验证旧版本仍可用
  • 是否写清楚值班 runbook

7.5 发布对象完整性门禁 ​

还建议单独确认：

  • release bundle 是否完整
  • 版本号是否一致
  • 新老 bundle 是否都能被回放
  • 依赖配置是否已经冻结

很多事故不是因为“模型不够好”，而是因为：

  • 线上跑的并不是你以为那套对象组合

8. OpenAI 部署清单给我们的一个现实提醒 ​

OpenAI 当前部署清单的价值，不在于“教你怎么写接口”，而在于反复强调：

  • 部署质量往往由一些容易忽略的设计决定拉开差距

对 AI 系统来说，这些高价值决定通常包括：

  • 不同步长任务强行同步返回
  • 不把所有任务都走最高成本路径
  • 不把历史状态管理留给前端随意拼接
  • 不把发布验证仅仅等同于人工试聊几轮

9. 发布批次应该能回答哪些问题 ​

一个成熟的发布批次，至少应该能回答：

  1. 这次变更改了哪几层。
  2. 影响了哪些用户或任务桶。
  3. 对应的基线评测是什么。
  4. 当前灰度比例是多少。
  5. 如果出事，回到哪一个版本。
  6. 当前值班同学应该先看什么指标。

如果这些问题都答不出来，那说明发布对象仍然过于模糊。

9.1 发布批次最好还能回答“谁有权暂停什么” ​

更成熟的发布批次信息里，通常还会补：

  • 哪些开关可直接关闭
  • 哪些 route 可冻结
  • 哪些工具可停用
  • 哪些租户可切回旧版
  • 谁拥有最终回滚权限

因为事故现场最容易卡住的不是“没人发现问题”，而是：

  • 发现了，但不知道谁能动哪一个开关

10. 人工兜底不应该只是“出事再人工接管” ​

更成熟的做法是提前定义：

  • 哪些任务天然需要人工确认
  • 哪些任务只在异常时转人工
  • 哪些任务上线前一律 shadow，不直接决策

人工兜底的核心价值是：

  • 让系统可以先带着边界上线，而不是非要一次性自动化到头

10.1 人工兜底最好显式分成三种模式 ​

更实用的分层通常是：

  • pre-approval
    • 先批后执行
  • post-review
    • 先执行低风险动作，再抽样或规则复核
  • handoff
    • 遇到异常直接转人工继续完成

这三种模式成本和适用范围不同。

如果全部混成一句“必要时人工接管”，后面很难回答：

  • 到底是审批策略的问题
  • 还是接力链路的问题

11. 一条更实用的发布流 ​

建议把发布拆成下面这条链：

text
Change proposal
 -> Offline eval
 -> Risk review
 -> Canary / shadow
 -> Monitored rollout
 -> Steady-state watch
 -> Post-release review

这条链的重点是：

  • 发布不是一瞬间，而是一段受控观察窗口

11.1 steady-state watch 结束前，不应默认认为“发布已经结束” ​

很多团队上线成功后马上散会，但 AI 系统里很多问题是：

  • 放量几分钟没问题
  • 几小时后才暴露

例如：

  • 缓存命中下降
  • 大模型使用率缓慢抬升
  • 长任务积压
  • 审批池开始堆积

所以更稳的做法通常是把：

  • steady-state watch

当成发布链的一部分，而不是附属观察动作。

11.2 一个更像生产系统的发布节奏通常是“bundle -> shadow -> canary -> wave rollout -> watch” ​

比起单次切换，更成熟的节奏通常是：

  1. 冻结 release bundle
  2. shadow 观察行为差异
  3. canary 小流量真实服务
  4. wave rollout 分波次放量
  5. steady-state watch 观察稳定窗口

这个节奏的价值在于：

  • 每一步都可停
  • 每一步都可回
  • 每一步都有不同关注指标

12. 哪些指标最适合放进发布观察面板 ​

12.1 质量 ​

  • 任务完成率
  • 引用正确率
  • 工具成功率
  • 审批命中率

12.2 运行 ​

  • 请求量
  • P95 / P99 延迟
  • token 成本
  • 缓存命中
  • 背景任务积压

12.3 风险 ​

  • 高风险动作尝试次数
  • 人工接管率
  • 拒答率异常
  • 红队样例告警

12.4 路由与状态 ​

  • route 命中分布
  • escalation / fallback 比例
  • 长任务恢复成功率
  • 审批后恢复成功率
  • handoff 成功率

这类指标很重要，因为很多 AI 发布问题不是单条回答错，而是：

  • 路由曲线变了
  • 状态恢复链坏了
  • 人机接力断了

13. 常见反模式 ​

  • 只回滚代码，不回滚 Prompt 和检索配置。
  • 发布前只做人工试聊，不跑固定评测集。
  • 新模型直接全量切换，不做 shadow 或 canary。
  • 没有值班 runbook，只靠“谁改的谁盯着”。
  • 高风险动作和低风险问答用同一套灰度策略。

14. 一组最小可用的发布策略模板 ​

14.1 低风险问答系统 ​

  • 先 shadow
  • 再小流量灰度
  • 指标稳定后逐步放量

14.2 RAG 检索系统 ​

  • 先离线回归检索质量
  • 再灰度指定租户
  • 重点看引用质量和旧版本残留率

14.3 Agent / 工具执行系统 ​

  • 先只灰度只读动作
  • 写操作保持人工审批
  • 等工具成功率稳定后再扩动作范围

14.4 大版本模型切换 ​

  • 先 shadow 比较行为差异
  • 再对低风险租户 canary
  • 核心指标稳定后分波次放量
  • 高风险动作保守维持旧 policy 或更强审批

14.5 检索或 rerank 主链改造 ​

  • 先离线对比候选池与引用质量
  • 再灰度特定任务桶或租户
  • 重点看旧版本残留、误召回和引用正确率

14.6 审批或 guardrail 策略调整 ​

  • 先看误放行和误阻断历史样本
  • 新策略先进入观察桶
  • 发布时重点盯人工接管率和审批池积压

15. 推荐搭配阅读 ​

16. 重点官方资料 ​

以下资源已按 2026-07-08 复核可访问：