LLM 升级的金丝雀发布：为什么模型上线与代码部署的失效方式完全不同

你的 CI 通过了。你的评估（evals）看起来没问题。你切换了流量开关，然后继续工作。三天后，一位客户提交了一个工单，称生成的每一份报告都不再包含 summary 字段。你翻阅日志发现，新模型开始稳定地生成 exec_summary —— 这是一个隐蔽的键名重命名，由于你忘记将其添加到发布门禁（rollout gates）中，你的 JSON schema 验证从未捕获到这一点。根本原因是模型升级。检测滞后时间为 72 小时。

这并非假设。在那些拥有复杂应用代码部署流水线，却将 LLM 版本升级视为基本“免费” —— 仅是配置更换而非部署 —— 的公司里，这种情况屡见不鲜。这种思维模型是错误的，由此导致的失败模式极其难以捕捉。

为什么 LLM 升级不只是配置更换​

当你部署新版本的服务代码时，新旧版本之间的差异是完全可枚举的：你可以进行 diff 对比，针对已知输入进行测试，并对准确输出进行断言。但模型升级不会给你这些。新模型是一个拥有数十亿参数且无法检查的函数，在运行生产环境输入之前，它在所有生产输入分布下的表现都是不可知的。

有三种失败模式专门出现在模型升级过程中，而在代码部署中并不存在：

输出 Schema 偏移。 模型提供商在改进模型时，并不将输出格式视为一种具有破坏性变更（breaking-change）的契约。在前一个版本中被稳定命名为 category 的字段，现在可能显示为 ticket_category。受限解码（Constrained decoding）可以保证语法上正确的 JSON，但不能保证你特定的字段名称和结构得以保留。下游解析器如果使用 dict["category"]，会在每个请求上静默抛出 KeyError。

无表面回退的语义偏移。 新模型产生的输出可能在自动化评估中得分很高，但在你的评估套件未衡量的地方表现不同。模型可能会在支持工单分类器中开始将错误归因于错误的组件，或者开始在不同的位置生成法律免责声明，从而破坏下游的文本分割器（text splitter）。输出看起来是连贯的；评估分数保持稳定；但产品行为崩溃了。

延迟和成本特征的变化。 产生更高质量输出的模型通常伴随着更多的 token、更长的生成时间或不同的吞吐量特征。一次提升了质量得分的发布，可能会同时触发 SLA 违规或使你的推理账单翻 3 倍。这两点都不会在质量评估中体现出来。

影子测试：基于真实流量的零风险验证​

任何模型升级最稳妥的第一步都是影子测试（shadow testing）：将生产流量同时路由到现有模型和候选模型，仅向用户提供现有模型的响应，并收集候选模型的输出进行比较。用户感知不到任何变化，而你可以积累真实的生产查询和真实的模型行为。

影子测试优于基准评估（benchmark evaluation）的价值正是在于：生产流量并非你的基准分布。你的基准是你认为应该编写的查询。而生产流量是你的真实用户发送的查询 —— 这包括边缘案例、格式错误的输入、意外语言的查询，以及你的评估集永远无法完全代表的新型实体。

影子测试能发现一类只能在真实流量中找到的问题：候选模型针对最长输入生成的特定 JSON schema、并发负载下的延迟特征，以及用户实际使用的特定领域术语的幻觉率。在进行任何流量切分之前进行 24–72 小时的影子测试，能为你提供可操作的依据。

在基础设施层实现起来非常直接。在 API 网关或负载均衡器处，将每个请求复制到两个模型。现有模型的响应同步返回给用户。候选模型的响应则异步捕获，并记录相同的元数据：输入 token、输出 token、延迟、时间戳、用户细分。然后，你对这两组响应运行评分流水线并进行比较。

流量切分：确定性路由与渐进式分配​

一旦影子测试通过了你的质量门禁，就可以转入 live 流量切分。这里的常见错误是使用随机流量分配。随机分配意味着同一个用户在一次请求中看到模型 A，而在下一次请求中看到模型 B，这使得你无法判断质量差异是由模型引起的，还是由会话级上下文变化引起的。

请改用基于哈希（hash）的路由。对用户 ID（或会话 ID、客户 ID —— 任何稳定的标识符）进行哈希处理，并确定性地分配桶（bucket）。0–9 号桶中的用户始终看到候选模型；其他所有人看到现有模型。这能保持个人用户体验的一致性，并使你的 A/B 比较在统计上是严谨的。

推进计划与路由逻辑同样重要。从 5–10% 的流量开始。在转向 25% 之前监测 24 小时。只有在确认候选模型在 25% 比例下表现稳定后，再转向 50%。这并非是对百分比的迷信 —— 而是为了确保有足够的时间观察尾部故障（tail failures）。Schema 违规和语义回退通常出现在特定的输入类别中，而这些类别可能仅占你流量的 2–3%。一个持续 24 小时的 10% 灰度测试能让你接触到这些长尾情况的代表性样本。

在每个阶段，都要跟踪群组（cohort）级别的指标，而不仅仅是汇总指标。汇总指标会掩盖特定细分领域的失败。候选模型可能在英语查询上表现相同，但在法语查询上却悄悄退化。在一个代表性不足的细分领域中，5% 的质量下降在汇总数据中是看不出来的，但却会影响到真实用户。

真正能捕获模型回归的指标​

通用的“质量评分”监控无法捕获上述失败。你需要部署的指标是专门针对 LLM 实际容易失败的地方：

输出 Schema 符合率。 跟踪响应中所有必填字段是否存在、命名是否正确以及类型是否符合预期的百分比。在解析层而非模型层进行埋点——你需要了解你的实际下游消费者是否成功。如果你的解析器抛出了 KeyError 异常，统计并针对它们发出告警。Schema 符合率的下降是你对字段名偏移（field-name drift）问题的最早预警。