Shadow Testing（影子测试）
影子测试（Shadow Testing），又称影子部署（Shadow Deployment）、影子流量（Shadowing Traffic）、流量镜像（Traffic Mirroring），是一种把真实生产流量复制一份发给新版本、但不把新版本的响应返回给用户的部署验证技术。用户始终只看到当前版本（V-Current）的响应；新版本（V-Next）的输出只用于日志、对比和评估。它与"暗发布（Dark Launching）“相近：把新功能或新版本放进生产环境跑真实流量，但用户看不到、用不到。
核心动机来自混沌工程的一条原则：系统行为随环境和流量模式变化，只有采样真实流量才能可靠捕获请求路径；合成测试数据很难复现真实生活的组合与可能。影子测试把真实客户行为灌进 V-Next，又对生产零影响，同时检验 V-Next 的基础设施能否像 V-Current 一样扛住真实流量的规模。
与金丝雀、A/B 测试的区别
三种渐进式发布常被混淆，但风险暴露方式不同：
| 方式 | 新版本是否服务用户 | 回答的问题 |
|---|---|---|
| 影子测试 | 否，只接收复制流量，输出不返回用户 | 新版本在真实流量下是否不退化 |
| 金丝雀发布（Canary） | 是，小比例（如 1% → 5% → 20% → 100%）用户看到新版本 | 新版本在真实用户上是否安全 |
| A/B 测试 | 是，两个变体分别服务不同用户群 | 新版本是否比旧版本更好 |
影子测试是任何重大变更的最低风险起点：它不把任何用户暴露给新版本。金丝雀在影子建立"没有明显退化"的信心后，再把风险转移到一小部分真实用户。A/B 则在金丝雀证明"可以安全部署"之后，衡量"是否真的更好”。把这三个问题混在一起，会发布出技术上稳定却让用户体验变差的变更。
代价与局限
影子测试不是免费的：
- 约 2 倍推理成本：每个请求被两个版本各处理一次，评估期间推理支出大致翻倍。
- 拿不到用户反馈：用户看不到影子响应，所以无法收集用户对新版本的主观反馈；它只能告诉你"新版本在真实输入下输出是否退化"，不能告诉你"用户是否更喜欢"。
- 需要评估层：没有自动化对比，影子模式只会留下一堆日志。真正需要的是按用例相关的标准（事实准确性、语气、任务完成度、格式合规）、token 数与成本对比，以及真实并发负载下的延迟测量来对比两个响应。
- 关联复杂度：把影子请求与基准响应关联起来对比，本身增加运维开销。
因此影子测试适合重大变更（模型升级、重大提示结构调整、新工具 schema），不适合细微的提示词微调。
LLM 发布为何不同于发布代码
LLM 的发布结合了软件部署里最难的部分，使影子测试尤其有用：
- 不确定性不可约：即便 temperature=0、贪婪采样，LLM API 在实践中也不确定——研究记录了输入完全相同时多次运行准确率差异可达 15%，根源是 GPU 浮点非结合性与批大小变化。所以无法用单元测试给模型变更提供可靠信号。
- 小变化大爆炸半径：提示词微调、微调数据更新或模型升级会以基准测试捕捉不到的方式改变行为；一个 MMLU 更高的新模型可能对模糊客户问题表现不同、输出更长撑坏 UI、或拒绝旧模型接受的请求。这些退化直到真实流量下才显现。
- 反馈延迟：糟糕的 LLM 输出不像 500 错误立即暴露，可能数小时或数天后才通过用户投诉、下游管道故障或工单浮现。
- 成本是变量：换模型改变 token 成本；质量提升 20% 的新模型单次调用可能贵 3 倍。影子测试让你小规模摸清成本曲线。
一种行之有效的模式是：在部署任何东西之前，先对历史生产请求回放影子模式——把上周流量在候选模型上重跑，让评审员把输出和当前模型的输出对比，在触及生产基础设施前快速发现可能退化的地方。
GPT-Live 的语音系统案例
OpenAI 在让 GPT-Live 面向用户前，做了一次静默的影子测试：把一小部分、逐步增加的生产 ChatGPT Voice 会话同时路由到既有 Advanced Voice Mode 和新系统；Advanced Voice Mode 照常服务用户，影子路径以只读模式跑推理。这让新系统暴露在真实客户端、网络、会话时长和地理分布下，却不改变用户听到的任何内容。
这次测试产出几条超出"模型对不对"的容量与运维教训，它们对任何实时或有状态 AI 系统的影子测试都适用：
- 容量不能只化约成 GPU 吞吐：语音会话持续开着、持续发帧，CPU 侧的流处理器、队列和网络路径要和推理一起扩。真实负载下某个支撑组件比压测预估更早饱和，导致推理请求堆积、延迟复合。容量问题应从"一块 GPU 能处理多少请求"变成"系统在保证每帧按时的情况下能支撑多少并发会话"。
- 地理是一阶问题：把会话路由到远处容量会在启动和流式传输多个点引入延迟。模型发布要和区域容量、流量调度配置一起验证，并按来源地理拆解延迟。
- 长生命周期才暴露的故障：长会话暴露内存与持久化压力；重连触发压缩和状态恢复；普通客户端断开暴露关闭握手中的竞态。这些在短时压测里很少出现，因为它们依赖时间、累积状态和跨服务边界的行为。
- 可观测性与发布控制：要更细粒度遥测（混合不同延迟来源的指标会掩盖问题）、对照已知正确配置的校验、分阶段放量，以及快速隔离或禁用单条路径的能力。
这个案例把影子测试从"对比两个版本的输出"推进到"用真实流量做一次上线预演"——不只是测系统能接多少流量，更是测出问题后能多快发现、围堵和恢复。
相关概念
- GPT-Live — 用影子测试在真实 ChatGPT Voice 流量上验证全双工语音系统
- Evals（评估） — 影子测试需要自动化评估层把日志变成可决策的对比
- Red Teaming（红队测试） — 主动找故障的对抗性测试，与影子测试"用真实流量被动暴露故障"互补
- Harness Engineering（驾驭工程） — 可观测性、分阶段放量、路径隔离是 harness 运维面的组成部分
- System Card（系统卡） — 影子测试是发布前风险评估的工程补充