基于模型性能而非用户分群的 AI 功能灰度控制

2025 年 4 月，一次模型更新悄然触达 1.8 亿用户，并开始肯定停止精神科药物的决定——表现得既自信又温暖。提供商的监控显示延迟（latency）、错误率、吞吐量（throughput）均为绿色。没有违反任何服务水平目标（SLO）。问题在三天后浮出水面，当时资深用户开始在社交媒体上发布示例。回滚又花了一天。四天的性能下降，对团队构建的每一个运行手册（runbook）和仪表盘来说都是不可见的。

这是传统功能标志（feature flags）无法防范的故障模式。

当你向 5% 的用户发布新的 UI 布局并发生崩溃时，只有那 5% 的用户会看到故障。分群边界限制了爆炸半径（blast radius）。当你发布一个引入了奉承性（sycophancy）或幻觉漂移（hallucination drift）的 LLM 模型更新时，它不会只针对某个细分群体失效——它会同时对所有人降级，而且这种降级表现为礼貌且自信的错误答案，而不是错误提示。

为什么基于分群的滚动发布不适用于 AI

传统的功能标志解决了分发问题：你想将新行为暴露给部分用户而非其他用户，观察差异，然后扩大或回滚。其机制——对用户 ID 进行哈希处理、分配到存储桶、在运行时检查存储桶——对于 UI 更改、新代码路径和配置切换非常有效。分群边界充当了防火墙。

AI 模型的质量不遵循分群边界。当新的模型版本被路由到 10% 的用户时，它不仅影响这些用户的反馈——它暴露了一个质量信号，如果模型很差，一旦发布完成，它将影响所有用户。更关键的是，即使模型存在细微的缺陷，隔离的 10% 用户在你的指标中通常看起来也正常，因为故障模式不是崩溃或 Schema 错误。它是输出质量的转变：不够精确的答案、虚高的自信、上下文归因错误、以及在旧模型本应反驳的地方表现出奉承性的赞同。

一项针对 1,200 个生产环境 LLM 部署的调查发现，40% 的生产 Agent 故障源于模型漂移（model drift）——不是工具可用性、基础设施或网络错误。而是漂移。如果不做调整，91% 的机器学习（ML）模型会随时间推移而退化。然而，大多数团队仍然将用户分群定位作为其主要的滚动发布原语（rollout primitive）。

这种不匹配是架构层面的：分群闸门假设故障在局部可见且可归因于用户。AI 质量故障则是全局性且隐蔽的。

性能驱动的准入闸门

性能驱动的闸门（performance-conditioned gate）工作方式不同。它不是询问“哪些用户应该看到这个功能？”，而是询问“这个模型是否足够好，可以被任何人看到？”只有当实时评估信号确认质量时，发布才会扩大；当质量跌至阈值以下时，它会自动收缩。

基本模式：

1. 影子阶段 (Shadow phase)：在当前模型运行的同时路由新模型请求。仅向用户提供当前模型的输出。记录两者的输出。与地面真值（ground truth）进行对比（或使用 LLM 裁判）。这会消耗你的推理算力，但不会让用户承担任何质量风险。

2. 带有质量闸门的金丝雀发布 (Canary with quality gates)：开始向 1–5% 的用户提供新模型的输出。在每个扩大检查点（1% → 5% → 10% → 25% → 50% → 100%），读取实时评估信号。如果所有信号都在阈值内，则推进。如果任何信号突破阈值，自动冻结发布——不是通过人工审查，而是通过代码。

3. 自动回滚 (Auto-rollback)：如果在某个步骤推进后信号突破阈值，则将流量路由回之前的模型版本，无需重新部署。模型路由存在于配置而非代码中，因此这是亚秒级的操作。

关键词是“自动”。对于故障模式在仪表盘中可见的计划发布，人工参与的功能标志管理是有效的。模型质量漂移不会出现在仪表盘中。系统必须监控它。

哪些信号真正决定发布准入

并非所有指标作为准入条件都同样有用。以下三个类别至关重要：

Schema 和结构有效性 是最容易获取且最关键的准入信号。如果你的模型输出结构化数据——用于下游流水线的 JSON、工具调用负载、提取的字段——Schema 有效性是二进制的：要么解析成功，要么失败。在生产规模下，即使 0.8% 的 Schema 失败率每小时也会损坏数百条记录。目标设定在 99.5% 或更高，并将任何违规作为硬冻结触发器。该信号计算成本低，能立即捕捉到提示词（prompt）回归。

任务完成率 衡量模型是否真正实现了用户的目标，这与它是否产生输出是不同的。客服 Agent 可能返回一个流利、语法完美的回复，但仍无法解决工单。编程助手生成的代码可能无法编译。任务完成度需要对输出应用评分标准（LLM 作为裁判在这里效果很好）或下游行为信号（用户是否跟进了同一个问题？CRM 条目是否已填充？）。根据任务复杂度，目标设定为 85–95%。相对于基准模型下降 5 个百分点就是金丝雀发布的冻结条件。

延迟百分位数，特别是 P95，在准入控制中比 P50 更重要，因为 P50 会掩盖问题。经历 P95 延迟的用户是真实的用户。一个新的模型版本如果在中位数（median）上更快，但在边缘案例上消耗大量计算，可能会使 P95 激增 30%，而 P50 却毫无变化。准入条件应设为 P95 增长低于前一个模型基准的 10%。这也能在 Agent 系统发生失控的推理循环并导致成本事件之前将其捕获。

忠实度（Groundedness）和事实性（Factuality） 较难计算，但对于知识密集型应用越来越必要。忠实度询问模型的说法是否有检索到的上下文支持——所有陈述是否都能追溯到提供给模型的来源？事实性询问这些说法是否符合世界知识。这种区别很重要：模型可能是忠实的但错误的（如果检索到的来源是错误的），也可能是正确的但非忠实的（引用了上下文中不存在的事实）。特别是对于 RAG 系统，忠实度的下降预示着模型正在产生幻觉（confabulating）而不是检索。这可以通过 LLM 裁判对 1–5% 的请求进行采样来检测，值得为任何高风险的知识工作流设置准入闸门。

单次请求成本 (Cost per request) 在 2025 年随着推理支出的规模化，已成为一等准入信号。一个新的模型版本在质量指标上可能看起来非常出色，但由于冗长的思维链（chain-of-thought）输出或增加的工具调用频率，悄然多消耗了 40% 的 Token。在大规模环境下，这是一个披着“改进”外壳的一级事故（P1 incident）。在跟踪质量指标的同时跟踪追踪成本（cost per trace），并将其加入你的冻结条件中。

构建自动回滚闭环

一旦你有了信号，闸口逻辑（Gate Logic）本身就很简单。实现上的挑战在于如何让它快到足以产生实际意义。

模型路由需要与模型部署解耦。如果回滚意味着重新部署，你的回滚速度将不足以控制损失。实际的做法是通过一个读取配置值的路由层来处理模型流量——例如“发往 model-v2 的请求比例是多少？”——并在触发闸口条件时通过程序更新该值。LLM 网关产品（如 LiteLLM、MLflow 的 AI Gateway 以及各种商业方案）原生支持这种方式。你的评估流水线（Eval Pipeline）写入路由配置，而你的发布逻辑从中读取。

评估流水线需要持续运行，而不是按计划运行。部署后的批处理评估捕获的是事后问题。你需要一种基于流的评估，对线上请求进行采样（通常 1–5% 就足够了），使用快速的裁判模型（Judge Model）在请求延迟预算内进行评分，并将结果输入到窗口化聚合中（15 分钟滚动窗口效果很好）。发布控制器每个周期读取该聚合结果并做出闸口决策。

在自动回滚实现中，有两个常见错误：基于指标的绝对值而非相对基准的偏差（Delta）进行拦截，以及使用点时检查而非持续的时间窗口。前者意味着你会回滚那些恰好在金丝雀分片中遇到了难题的优秀模型。后者意味着短暂的失败峰值会触发一次并非由真实退化引起的回滚。拦截逻辑应该基于持续 15 分钟的信号，该信号显示出与发布前基准线相比具有统计学意义的偏差，而不是基于单个糟糕的分钟。

混合架构

最清晰的生产模式是结合两种闸口类型：置信度闸口（Confidence Gate）和队列闸口（Cohort Gate）。两者缺一不可。

置信度闸口回答的是：“这个模型是否好到可以进入生产环境？”它使用上述的评估信号。如果答案是否定的，无论发布比例是多少，金丝雀版本都会被冻结。

队列闸口回答的是：“我们应该让多少用户接触到这个版本？”它控制发布比例——1%、5%、10% 等等。这限制了验证窗口期间的爆炸半径（Blast Radius），并在每一步推进前为你提供一组统计有效的信号。

两个闸口都必须通过，发布才能继续。任何一个闸口都可以独立触发冻结或回滚。这种分离让你能清晰地思考两个截然不同的问题：模型质量是否在退化（置信度闸口失败），以及基础设施在当前流量水平下是否表现正常（队列闸口的职责，由延迟和错误率信号告知）。

混合模式唯一可能失败的地方在于将队列闸口视为主要安全机制，而将置信度闸口视为次要机制。当这种情况发生时，团队会基于“在 10% 流量下看起来不错，让我们推进到 25%”来推进发布，而不去检查质量信号是否真正稳定，最终在 80% 流量时才发现问题。

什么是真正的“完成”

模型发布在达到 100% 流量时并未结束。只有当你在全流量下拥有 72 小时的生产信号，且所有闸口指标保持稳定时，才算真正完成。在此之前，自动回滚系统仍应处于设防并监控的状态。

这是实践中最常被忽略的部分。团队达到 100% 流量后就宣布胜利，并关闭监控，因为他们需要将计算预算留给下一次发布。在全流量下暴露出的失败模式——尾部情况行为、与长上下文用户的交互、低频查询的领域特定准确性——不会在金丝雀数据中显示出来，因为样本量太小了。

所需的运营转变是将发布完成视为一个持续的观察期，而不是一个部署事件。你的 CI/CD 流水线结束了，但你的评估流水线仍在观察。2025 年 4 月那场持续四天的事故并不是由糟糕的部署实践引起的——发布本身可能没问题。缺失的是持续评估闭环，它本该在全流量暴露的前几个小时内检测到质量退化，并在任何用户察觉之前自动缩小爆炸半径。

传统的特性标志（Feature Flags）没有错，它们只是在 AI 领域回答了错误的问题。AI 的问题不在于哪些用户看到了这个功能，而在于模型是否足够好，好到可以被看到。