Wiki Notes

Appearance

影子发布与灰度评估专题 ​

版本：v1.4

最后更新：2026-07-08

适用对象：正在升级模型、重写 Prompt、调整检索与工具策略、上线新 guardrails，或需要在真实流量里先比较新旧行为再逐步放量的产品、平台、评测与运维同学

很多 AI 系统在准备升级模型、检索或提示词时，最怕的不是新方案完全不可用，而是：

  • 看起来大体正常
  • 但在真实流量里悄悄变坏

这就是为什么上线前常常需要：

  • 影子发布
  • 灰度评估

更贴近现实的理解是：

  • 影子发布是“先在真实环境里看差异”
  • 灰度评估是“再把一小部分真实后果交给新方案”

这两者一起，才构成更完整的发布门禁。

根据 2026-07-08 可访问的 OpenAI Evaluation best practices / Production best practices / Safety in building agents、Google SRE 的 Canarying Releases / Alerting on SLOs、以及 Anthropic 关于 human confirmation 与工具风险边界的资料，一个很重要的共识是：

影子发布解决“新旧方案在真实流量下怎么不一样”，灰度评估解决“这些差异是否已经足以影响真实用户和业务风险”。

1. 什么是影子发布 ​

更实用的理解通常是：

  • 新方案跟着真实请求一起跑
  • 但不直接影响用户返回结果

它的目标不是立即替换旧方案，而是先回答一个问题：

  • 新方案在真实分布下到底表现如何

影子发布特别适合 AI 系统，因为很多问题只有在真实流量里才会暴露：

  • query 更脏
  • 长尾场景更多
  • 检索上下文更复杂
  • 工具链更不稳定
  • 用户行为比离线样例更难预测

2. 什么是灰度评估 ​

灰度评估更偏向：

  • 把一小部分真实流量真正交给新方案
  • 观察质量、安全、成本、延迟和人工介入变化

和纯离线评测相比，它更接近真实生产条件。

和影子发布相比，它的关键区别在于：

  • 用户开始真正受到新方案影响

所以灰度不是“再测一轮”，而是一个带风险的运行阶段。

3. 为什么 AI 系统特别适合先影子、再灰度 ​

Google SRE 当前 Canarying Releases 的核心思想非常直接：

  • 先让控制组和试验组并存
  • 观察差异
  • 如果误差超阈值，就暂停或回滚

OpenAI 当前 Evaluation best practices 和 Production best practices 也反复强调：

  • 离线评测很重要
  • 但真实流量会暴露分布外问题
  • 高风险系统要逐步暴露变化，而不是一次全量

对 AI 系统尤其成立，因为很多退化只会在生产分布下显现：

  • 用户问题分布比测试集复杂
  • 工具调用的尾部失败更多
  • 检索知识更脏更乱
  • 长上下文、多轮对话更容易出现隐藏问题

4. 哪些变化最值得先做影子发布 ​

尤其下面这些变化，建议优先先影子跑一轮：

  • 模型切换
  • Prompt 大改
  • 检索策略调整
  • rerank 规则调整
  • 工具路由逻辑调整
  • 审批或 guardrails 规则变化
  • 高价值知识域大批量更新

因为这些改动很多时候不是“能不能用”的问题，而是：

  • 是否比现在更稳

5. 一个更稳妥的发布路径通常是什么 ​

建议按下面顺序推进：

text
Offline eval
 -> Shadow traffic
 -> Small canary
 -> Gradual rollout
 -> Full release

这条路径的价值在于：

  • 离线先过滤明显不合格方案
  • 影子阶段先看新旧差异
  • 灰度阶段再验证真实用户影响
  • 放量阶段逐步扩大风险暴露面

5.1 影子发布不是“复制一遍请求”这么简单 ​

很多团队第一次做 shadow traffic，会把它理解成：

  • 生产请求复制到新链路

这只是开始，不是完整设计。

更贴近生产的关键问题其实是：

  • 新链路会不会真的执行副作用
  • 新链路是否还能访问真实高敏数据
  • 工具调用、审批调用、写路径调用怎么做只读隔离
  • 影子链路报错后会不会反过来影响主链路稳定性

OpenAI 当前 Safety in building agents 和 Anthropic 当前 computer use 资料都在提醒同一件事：

  • 高风险动作不能因为“只是测试”就默认放开

所以更稳的影子设计通常是：

  • 主回答继续由旧方案返回
  • 新方案只生成候选结果和风险证据
  • 工具层改成只读、dry-run、mock response 或审批前断开
  • 高风险动作只记录“本来会怎么做”，但不真正执行

5.2 更像生产的发布路径，通常还会多一层“静默写前检查” ​

对带外部副作用的 Agent / workflow 系统，一个更稳的路径通常不是直接：

  • offline -> shadow -> canary

而是：

  • offline -> shadow read path -> silent write check -> small canary -> gradual rollout

这里的 silent write check 更像：

  • 真正跑到动作决策前
  • 记录参数、审批路径、风控标签和预期副作用
  • 但最后一步不提交真实写入

这层非常适合发现：

  • 参数 schema 看起来合法，但业务语义已偏
  • 工具选择没错，但审批路由变了
  • 写动作目标对象不对
  • 引用证据不足，却已经准备执行

6. 影子阶段真正应该盯什么 ​

影子阶段最有价值的通常不是单一分数，而是“差异视角”。

建议重点看：

  • 新旧回答差异
  • 新旧引用差异
  • 新旧工具调用差异
  • 新旧 guardrail 触发差异
  • 新旧审批触发差异
  • 新旧成本与延迟差异

因为很多问题并不是：

  • 直接失败

而是：

  • 输出悄悄变了
  • 路由悄悄变了
  • 风险路径悄悄放大了

6.1 影子阶段最好有一张“差异记分卡” ​

如果影子阶段只是把新旧答案存下来，团队通常还是会很快迷失。

更实用的做法通常是给每条请求补一张结构化差异卡，至少记录：

  • request_id
  • bucket
  • old_route / new_route
  • old_model / new_model
  • old_answer / new_answer
  • citation_diff
  • tool_diff
  • guardrail_diff
  • approval_diff
  • latency_diff
  • cost_diff
  • review_status

这样影子流量才容易被真正用于：

  • 人工抽检
  • 失败分桶
  • 风险聚类
  • 后续回归集扩充

6.2 不要只看“差异有多少”，更要看“差异集中在哪” ​

很多变更会出现一种很危险的情况：

  • 整体差异比例不高
  • 但差异高度集中在某几个高风险桶

例如：

  • 合同审批类 query
  • 高金额操作
  • 带工具调用的会话
  • 长上下文检索问题

这类情况下，如果只看全局 diff rate，很容易误以为：

  • 变化不大，可以继续放量

实际上更应该先回答：

  • 这些差异是不是恰好都落在我们最不能出错的地方

7. 灰度阶段为什么不能只看成功率 ​

只看成功率通常会漏掉大量关键问题：

  • 延迟变高
  • 成本上升
  • 高风险样例误放
  • 引用稳定性下降
  • 人工审批量暴增
  • 人工接管量上升

所以灰度评估最好同时观察：

  • 质量
  • 安全
  • 成本
  • 延迟
  • 运维负担

这五项经常会彼此拉扯，不应只看一侧。

7.1 成功率高，不代表风险半径小 ​

AI 灰度里很常见的一种错觉是：

  • 成功率没掉
  • 所以可以继续放量

但更接近真实发布治理的问题通常是：

  • 高风险动作是否更容易误放
  • 人工审批是否被打爆
  • 运营复核量是否上升
  • 用户投诉是否集中在少数高价值流程

也就是说，灰度阶段真正要控制的往往不是：

  • “平均有没有好一点”

而是：

  • “最坏的那部分风险有没有被放大”

8. 更适合 AI 系统的灰度门禁怎么设 ​

一个更可执行的做法通常是：

  1. 先定义核心指标阈值。
  2. 先定义必须阻断的红线。
  3. 先定义谁能决定继续或终止。
  4. 先定义回滚条件与时限。

这样当灰度期间出现异常时，团队不是：

  • 临时再讨论一次

而是：

  • 按预案执行

8.1 典型红线示例 ​

  • 高风险样例漏放率上升
  • 权限误召回率上升
  • 人工审批积压异常
  • P95 延迟超阈值
  • 单任务成本超预算

8.2 更稳的灰度门禁通常是 gate profile ​

很多团队会给所有变更共用一套门禁阈值，但真实系统更适合按变更类型拆 profile。

例如：

  • model switch gate
  • prompt rewrite gate
  • retrieval change gate
  • tool routing gate
  • guardrail policy gate

因为它们最容易带来的风险并不一样：

  • 模型切换更容易影响语气、推理和成本
  • 检索调整更容易影响引用和事实稳定性
  • 工具路由更容易影响副作用和审批路径
  • guardrail 变更更容易影响误拦、漏拦和人工负担

用 gate profile 的好处是：

  • 每类变更看真正相关的红线
  • 不会用泛化阈值掩盖关键风险

9. 影子阶段和灰度阶段应该分别关注什么 ​

9.1 影子阶段更关心 ​

  • 差异分布
  • 长尾失败
  • 工具行为变化
  • 引用和检索变化
  • 风险触发模式变化

9.2 灰度阶段更关心 ​

  • 用户实际影响
  • 人工介入量
  • 成本和延迟
  • 安全边界是否被打穿
  • 是否触发回滚条件

如果这两个阶段混在一起，常见问题是：

  • 看到了差异，但不知道是否影响用户
  • 看到了用户反馈，却追不到差异来源

10. 哪些样本最值得单独监控 ​

并不是所有请求都值得一视同仁。

建议单独盯这些高风险桶：

  • 权限与审批相关请求
  • 财务 / 合同 / 合规问答
  • 编号、产品名、错误码类 query
  • 高价值工具调用
  • 长上下文、多工具、多轮请求

因为这类场景最容易出现：

  • 平均分还行，但高风险场景已经退化

11. 灰度评估和回归测试应该怎么配合 ​

更成熟的做法通常是：

  • 离线回归负责守住已知风险
  • 影子负责发现真实流量差异
  • 灰度负责验证真实用户影响

三者缺一不可。

如果只有离线回归，没有影子和灰度，常见问题是：

  • 测试集通过了，生产分布没通过

如果只有灰度，没有回归，也会出现：

  • 每次上线都要重新承担同类风险

12. 为什么新旧对比一定要保留证据 ​

影子和灰度最怕的一件事是：

  • 大家感觉新方案不对
  • 但说不清到底哪里不对

所以建议至少保留：

  • request id / trace id
  • 旧方案输出
  • 新方案输出
  • 引用差异
  • 工具调用差异
  • 风险标签差异
  • 最终裁决结果

12.1 更稳的证据模型，通常还会保留“为什么不同” ​

如果条件允许，建议在差异证据里再补这些字段：

  • retrieval_set_hash
  • top_k_doc_ids_before_rerank
  • rerank_reason 或 rerank score
  • tool_args_preview
  • policy_version
  • approval_policy_version
  • fallback_trigger_reason

这些字段很有用，因为后续你常常不是只想知道：

  • 新旧不同

而是想追到：

  • 是检索变了
  • 还是 rerank 变了
  • 是模型输出变了
  • 还是策略版本变了

这样后续才能做：

  • 差异分析
  • 人工抽检
  • 失败样例沉淀
  • 回归集扩充

13. 为什么灰度比例不该只按流量算 ​

很多团队说灰度 1%、5%、10%，但 AI 系统里的风险不一定按流量均匀分布。

更稳的思路通常是：

  • 低风险流量先放
  • 高风险流量后放
  • 新租户和老租户分开看
  • 特定工具调用单独放量

也就是说：

  • 灰度比例不仅是流量比例，更是风险暴露比例

13.1 更稳的放量方式通常是“风险加权放量” ​

一个比较实用的顺序通常是：

  1. 先低风险只读流量。
  2. 再低风险真实写流量。
  3. 再放中风险、低金额、低外部影响动作。
  4. 最后才放高风险或高价值流程。

这比单纯按 1% -> 5% -> 10% 更贴近 AI 系统现实，因为 AI 风险并不是线性分布在所有请求上的。

14. 为什么影子和灰度要和人工评审结合 ​

OpenAI 当前 eval best practices 明确建议：

  • 用多轮详细人工评审不断修正评分标准
  • 对重要样例做随机化和盲评

这对影子与灰度非常有帮助，因为很多 AI 差异不是简单对错，而是：

  • 语气更危险
  • 引用更虚
  • 结构化输出更脆
  • 人工运营负担更重

这些问题往往需要人工抽样才能真正识别。

15. 为什么影子流量不应该无止境持续 ​

影子流量很有价值，但如果没有明确目标，也容易变成：

  • 一直并行跑
  • 一直不敢放量
  • 一直多付双倍成本

所以更好的方式通常是提前定义：

  • 影子阶段关注哪些差异
  • 什么条件算通过
  • 什么条件算必须退回重做
  • 最长观察窗口多长

15.1 影子阶段也应该有明确退出条件 ​

建议至少提前写清：

  • 差异率阈值
  • 高风险桶人工抽检通过率
  • 工具 / guardrail / 审批路径一致性要求
  • 成本和延迟可接受区间
  • 是否已经完成足够覆盖的真实流量观察

否则影子阶段很容易沦为：

  • 大家都觉得“再看几天”
  • 但没人知道到底看够没有

16. 为什么灰度期间要提前定义“谁能拍板” ​

很多灰度失败，不是失败本身多严重，而是：

  • 明明看出有问题
  • 但没人敢停
  • 或者大家都想再等等看

这在 AI 发布里尤其危险，因为：

  • 错误不一定立刻大面积爆炸
  • 但会逐步放大风险和用户信任损失

所以必须提前明确：

  • 谁能暂停灰度
  • 谁能回滚
  • 谁能决定继续放量

16.1 最好提前指定“技术拍板人”和“业务拍板人” ​

AI 灰度和普通发布一个很不一样的地方在于：

  • 有些问题是技术退化
  • 有些问题是业务风险放大

所以更稳的责任划分通常不是只设一个 owner，而是至少明确：

  • 技术拍板人
    • 是否暂停、回滚、切 fallback
  • 业务 / 风险拍板人
    • 是否接受短期质量变化或人工负担变化

这样出现争议时，团队不会陷入：

  • 技术觉得该停
  • 业务觉得还能扛
  • 最后谁都没有正式决策权

17. 一个更适合 AI 系统的最小灰度清单 ​

如果团队现在还没有成熟的影子 / 灰度机制，建议至少先做到下面这些事：

  1. 重大变更先做离线评测。
  2. 影子阶段保留新旧差异证据。
  3. 灰度阶段单独监控高风险样例桶。
  4. 提前定义红线、回滚条件和拍板人。
  5. 人工抽检必须进入影子与灰度环节，而不是只看机器分数。

18. 常见反模式 ​

  • 离线过了就直接全量
  • 影子阶段不保留新旧差异证据
  • 灰度阶段只看成功率
  • 放量按总流量走，不看风险桶
  • 没有回滚阈值，出问题再讨论
  • 影子阶段无限延长，却没有明确通过条件
  • 影子链路仍然能真实执行写动作或高风险工具
  • 灰度指标全是平均值，没有高风险桶或长尾桶观测
  • 只有技术指标，没有审批积压、人工接管和投诉类指标
  • 没有区分技术拍板人与业务拍板人

19. 推荐搭配阅读 ​

20. 重点官方资源 ​

以下资源已按 2026-07-08 做过可访问性检查：

21. 落地检查清单 ​

  • 是否区分了影子发布和灰度评估的目标与通过条件
  • 是否在影子阶段保留了新旧输出、引用、工具与风险差异证据
  • 是否在灰度阶段同时观察质量、安全、成本、延迟和人工介入
  • 是否对高风险桶单独控制放量和回滚阈值
  • 是否明确了暂停灰度、继续放量和回滚的拍板人