AI 系统的影子流量：在上线前验证模型变更的最安全方式

大多数团队上线 LLM 变更的方式，与 2005 年上线 Web 变更如出一辙——跑几个离线评估，说服自己数字看起来不错，然后直接推上去。意外总在周一早上到来：一个通过了所有基准测试的系统提示词调整，悄无声息地破坏了评估集之外 40% 的用户查询。

影子流量就是解决方案。思路很简单：将候选模型或提示词与生产系统并行运行，向其输入每一个真实请求，对比输出结果，同时只让用户接触当前版本。零用户暴露、真实生产数据、上线前的统计置信度。但将这一方法应用于 LLM，需要重新思考几乎所有实现细节——因为语言模型是非确定性的、推理成本高昂，且其输出无法通过简单 diff 进行比较。

离线评估为何在边界处失效

每个 ML 团队都有评估套件。问题在于它覆盖不到的地方。你的黄金数据集是在开发阶段精心挑选的，这意味着它反映的是团队认为重要的查询——而非真实用户在周五凌晨 2 点发送的那些。生产数据有长尾：不寻常的措辞、多语言混用、出乎意料的对抗性输入，这些都会暴露合成基准测试无法触及的脆弱性。

一个在离线套件上得分 94% 的提示词变更，依然可能让真实用户的体验下降两位数。评估性能与生产性能之间的差距，是 LLM 工程中被持续低估的风险之一。影子流量通过在变更上线之前——而非之后——将生产查询纳入验证循环，弥合了这一差距。

离线评估的另一个问题是数据陈旧。生产分布会随时间漂移。如果你半年没有更新评估集，它已经无法代表用户真正在问什么了。影子测试在定义上始终是新鲜的——它针对的是今天的流量。

影子测试的实际架构

架构由三个组件构成：捕获层、比较层和分析层。

捕获层位于你的 API 网关或服务网格中，复制每一个进入的请求。原始请求照常发送给生产模型——用户体验完全不变。副本被发送到运行候选模型或提示词的影子部署。由于影子系统在生产响应已经发送之后异步运行，用户不会感受到任何延迟影响。

比较层接收来自生产系统和影子系统的输出，并将它们与共享的请求上下文一起记录下来。大部分工程复杂性都在这里。你需要存储：原始输入、生产输出、影子输出、各自的延迟和成本、模型返回的任何置信度分数或结构化字段，以及足够的请求元数据以便后续对数据进行切片分析。

分析层定期运行——通常是批处理任务——并对记录的配对计算比较指标。这里决定候选版本是否可以晋升。

GoReplay 等工具可以在基础设施层面处理流量捕获和回放，无需修改应用程序代码。AWS SageMaker 原生支持影子部署。对于已在使用 Kubernetes 的团队，Istio 和 Envoy 无需触碰服务代码即可路由影子流量。

选择合适的比较指标

这是 LLM 影子测试与传统影子测试差异最大的地方。当你对 SQL 查询优化进行影子测试时，你验证结果是否完全相同。当你对 LLM 进行影子测试时，完全相同的输出是不可能的——你是在将散文与散文进行比较，语义等价才是重点。

指标体系根据是否有基准答案分为两类。

当你有黄金答案——特定查询的预期输出——时，基于参考的指标效果很好。ROUGE 分数衡量 n-gram 重叠，计算速度快。BERTScore 使用上下文嵌入，能捕捉 ROUGE 遗漏的释义。对于结构化输出，格式合规性检查（有效 JSON、必填字段存在）几乎没有计算成本，却能发现相当大比例的回归。

当你没有黄金答案时——这是大多数生产流量的情况——你需要无参考评估。基于嵌入的语义相似度将两个输出视为向量，测量它们之间的余弦角。分数高于 0.8 通常表明输出在语义上等价。LLM-as-judge 使用 GPT-4 或 Claude 等强模型来逐对评估影子输出是否优于、劣于或等同于生产基线。GPT-4 与人类评估者在逐对比较上的一致率超过 80%，这使其可以作为大规模人类判断的代理。

实践中的做法是根据成本分层运行多个指标。正则表达式和格式检查几乎是免费的，应该对 100% 的影子流量运行。嵌入相似度的成本足够低，可以用于 10-20% 的流量。LLM-as-judge 评估成本高昂——每次比较需要 5-30 秒和真实的 API 费用——因此应该对 1-2% 的采样子集运行。

采样策略：在不支付完整 A/B 测试成本的情况下获得统计置信度

A/B 测试之所以昂贵，是因为它需要用户暴露。你需要将真实用户引导到候选版本，等待足够的转化或反馈信号，并接受在整个测试期间一定比例的用户体验了潜在退化的版本。

影子测试消除了暴露成本。你可以对 100% 的流量运行它——不影响任何用户——并且仍然可以选择只评估其中一部分配对，因为瓶颈是评估成本，而不是流量量。

分层采样策略可以简洁地处理这个问题：

• 第 1 层（100% 影子配对）：确定性检查——格式验证、结构化字段合规性、安全过滤器触发
• 第 2 层（10-20%）：基于嵌入的语义相似度、响应长度分布
• 第 3 层（2-5%）：LLM-as-judge 逐对评估
• 第 4 层（<1%）：人工审查采样的回归和边缘案例

这种结构在最常见的故障模式（格式错误的输出、安全违规）上提供廉价覆盖，同时将昂贵的评估保留给足够大的样本以具有统计意义。在流量适中的系统上，LLM-as-judge 评估的 2% 采样每天仍然能提供数千次比较，这对于 95% 置信度的回归检测来说绰绰有余。

对于统计层，在开始之前使用功效分析确定最小样本量。考虑 LLM 输出方差——因为模型是非确定性的，你的比较指标方差比确定性软件更高。一个实用的经验法则：估计比等效传统软件测试所需样本量多 2-3 倍。

值得了解的一个细节：即使温度设置为零，LLM 在生产中的输出也不是真正确定性的。内核级批处理效应意味着以不同批次大小处理的相同请求会产生不同的输出。这就是为什么影子比较必须使用语义指标而非精确匹配——即使两个模型在功能上等价，精确匹配也会始终显示误报回归。

实践中的评估工作流

影子测试的正确思维模型不是"替代 A/B 测试"，而是"A/B 测试之前的门控"。完整的部署序列如下：

离线评估在你的开发环境中捕获明显的回归——逻辑错误、格式失败、灾难性质量下降。这在每次提交时在 CI 中运行，应该很快（秒到分钟级别）。

影子测试在零用户暴露的情况下验证真实生产流量。根据你的流量量，运行时间从几小时到几天不等。你在寻找：延迟回归、成本增加、真实世界查询上的质量回归和安全失败。通过影子测试意味着你的变更可能可以安全地暴露给用户。

A/B 测试衡量面向用户的影响——满意度、参与度、任务完成率。这需要用户暴露，是唯一能知道质量改进是否转化为业务成果的方式。但它昂贵且缓慢，所以只有在影子测试已经通过候选版本之后才运行。

分阶段推出将新版本逐步扩展到 5%、25%、100% 的流量，在每个阶段进行监控。影子测试已经对功能属性进行了去风险化；分阶段推出可防止大规模意外负载效应。

Google 和 Netflix 的开源 Kayenta 工具自动化了这一工作流的金丝雀分析部分。Kayenta 对你选择的指标运行统计显著性测试，返回 0-100 的综合健康分数，并与 Spinnaker CD 流水线集成。它每天为生产流量处理数千次金丝雀判断。一旦你定义了正确的指标，该框架就可以直接迁移到 LLM 系统。

困难所在

LLM 的影子测试存在传统影子测试中不存在的故障模式。

依赖上下文的查询是最常见的问题。如果用户的会话包含先前的对话历史，孤立地回放最后一条消息会改变语义上下文。在没有相同对话历史的情况下评估的影子模型，会因与被测试的模型变更无关的原因而产生与生产不同的输出。你需要捕获和回放完整的会话上下文，这大幅增加了存储需求。

成本核算并不简单。运行影子部署会使你的推理支出翻倍。对于已经密切关注单位经济的团队来说，这很重要。缓解措施是在有限的时间窗口内运行影子部署——足够长以积累统计上有效的样本，然后关闭影子——而不是持续运行。

延迟测量具有欺骗性。因为影子是异步运行的，用户不会看到影子延迟。但你仍然需要测量它。一个运行速度慢 3 倍的候选模型，即使用户从未直接体验到延迟，也会产生显著的基础设施成本和容量影响。

最后，回归归因很困难。当影子测试标记质量下降时，你需要诊断回归是在模型变更、评估指标、采样偏差还是 LLM 输出固有的非确定性中。构建你的比较日志，使你能够按查询类型、用户细分、输入长度和其他协变量进行切片——否则你会花几天时间调试一个最终是采样伪像的回归。

入门工具

GoReplay（开源）无需修改应用程序代码即可在基础设施层捕获和回放 HTTP 流量。适合在基础设施层进行影子测试。

DeepEval 在 pytest 兼容的接口中提供 50+ 内置 LLM 评估指标。开箱即用处理幻觉检测、忠实度、相关性和语义相似度。

Evidently 拥有 100+ 预构建的 LLM 评估和监控指标，并支持生产比较可视化的仪表板。

Opik by Comet 是全栈 LLM 评估平台，追踪每次推理调用，并将离线评估指标与随时间变化的生产行为关联起来。

对于 AWS 上的团队，SageMaker 的原生影子部署功能无需自定义基础设施即可处理流量路由和比较日志记录。

收益

影子测试不能替代你对模型质量的直觉。它不能消除对深思熟虑的评估设计或仔细提示词工程的需求。它消除的是只出现在真实生产流量上的那类故障——长尾查询、不寻常的措辞、在开发期间没有人预见到的边缘案例。

最常遭受 LLM 回归的团队，往往是那些过于信任离线评估的团队。解决方案不是更多评估数据——尽管那也有帮助。而是关闭真实生产查询分布与你的上线前验证流程之间的反馈循环。影子流量是结构性解决方案。工程开销是真实的，但有界的。替代方案——盲目地发布变更，从用户报告中了解故障——代价更高。

---

相关文章：谁负责 AI 质量？、结构化输出语义验证