为什么渐进式发布对 AI 功能不起作用（以及该怎么做）

灰度发布（Canary deployments）之所以有效，是因为 Bug 是二元的。代码要么崩溃，要么正常运行。你将 1% 的流量引导到新版本，观察 30 分钟的错误率和延迟，然后决定回滚或继续。系统会自动评分。一个糟糕的发布会大声宣告自己的存在。

AI 功能并非如此。一个开始生成微妙错误建议、过时推荐或听起来煞有介事的废话的语言模型，其 5xx 错误率为零。延迟保持在 SLO 范围内。灰度发布看起来是绿色的，而产品却在无声无息地辜负用户。

这不是工具问题。这是概念上的错位。渐进式发布背后的整个思维模型——确定性代码、自我评分系统、二元通过/失败——在你引入一个其正确性无法通过观察请求本身来衡量的组件时，就会崩溃。

每个发布工具都遵循的假设

Netflix 的 Kayenta 是权威的开源灰度分析工具，其工作原理是将流量拆分为基准（baseline）和灰度（canary），收集指标分布，并运行 Mann-Whitney U 检验来确定这两个群体是否存在显著差异。输出是一个 0–100 的置信度分数。低于阈值，你就回滚。

对于确定性系统，这非常优雅。其潜在假设是，如果你针对相同的流量运行相同的代码，你会得到可比的结果分布——而偏差是出了问题的可靠信号。

功能开关（Feature flags）延续了相同的思维模型。你为一部分用户切换代码路径，比较结果，然后做出决定。隐含的假设是，切换该开关的“结果”在你的实验时间范围内是定义明确且可衡量的。

这两类工具都是为一个这样的世界构建的：

• 相同的输入产生相同的输出
• 故障会发出可观察的信号（错误代码、异常、超时）
• 无需读取响应内容即可评估正确性
• 回归在几分钟内就会显现，而不是几天

由 LLM 驱动的功能违反了以上所有四点。

为什么 LLM 输出会打破这些假设

非确定性不是你可以修复的 Bug。 语言模型的输出因温度（temperature）采样、跨硬件的浮点精度差异、批处理效应以及 CUDA 内核的非确定性而异。2024 年的一项研究确认，即使在 temperature=0 的情况下，不同的硬件对相同的输入也会产生不同的输出。这意味着没有稳定的基准分布可以进行比较——你是在将一个输出云与另一个输出云进行比较，而这些云具有与质量无关的固有离散性。

质量下降看起来像正常输出。 当一个金融科技聊天机器人开始提供过时的监管建议时，所有运行指标都保持绿色。当一个电子商务推荐模型开始生成通用的产品描述时，错误率和延迟都在正常范围内。2025 年的一项行业调查发现，75% 的企业在缺乏适当监控的情况下观察到 AI 性能下降，超过一半的企业报告称，由于现有仪表盘无法捕获 AI 错误，导致了收入损失。

这种模式是一致的：失败模式是输出质量分布的微妙偏移，而不是可观察错误信号的激增。

没有实时的地面真值（Ground Truth）。 当你的 API 返回 500 错误时，你立即知道出了问题。当语言模型给用户一个确信的错误答案时，你当时无法得知。LLM 输出的地面真值是通过缓慢、昂贵的渠道获得的——用户反馈（稀疏且有偏见）、专家评审（不可扩展）或下游行为信号（用户重新表述问题、放弃会话）。传统的灰度发布可以在几分钟内检测到回归。而 LLM 灰度发布可能需要数小时或数天才能积累足够的标注或代理标注数据点，以达到统计学意义。

上下文敏感性使得代表性采样变得困难。 确定性服务的 1% 灰度流量具有代表性，因为同一代码以相同方式处理所有请求。对于 LLM 功能，1% 的灰度流量可能无法覆盖模型性能退化的长尾输入分布。在某些模型中，多轮交互可能导致性能下降高达 73%——但这些交互可能不会出现在你灰度发布的第一个小时内。微小的提示词（Prompt）格式更改会使准确率波动约 5%。生产环境的输入分布与你评估时的分布完全不同。

实践中究竟会出现什么问题

失败模式主要集中在以下几种模式。

无声的行为回归。 你正在发布的模型版本在留出的测试集上表现相当，但在你从未预料到的长尾生产输入上性能下降。等到积累了足够的用户反馈来显现信号时，发布已经完成，归因变得模糊不清。

评估与生产之间的鸿沟。 团队经常在精心策划的评估集上获得 90% 以上的成功率，却发现生产环境中的成功率仅为 70%。这种差距源于分布偏移：测试数据中未体现的词汇、格式和交互模式。渐进式发布无法帮你捕捉到这一点——它只是逐渐扩大了风险暴露面。

相关的尾部故障。 语言模型的质量往往在边缘案例（edge cases）上下降，而这些案例是相关的。如果你的 1% 灰度样本中不包含触发故障的特定输入，灰度测试就会通过，发布继续。一家医院的 AI 部署在发布后发现，其临床模型忽略了最近停用的药物——这是一个需要多会话上下文的故障，而这在测试中并未覆盖。灰度发布从未发现它。

成本螺旋。 对于智能体（Agentic）功能，相关的故障指标不是输出质量，而是行动成本。没有硬性限制的递归智能体模式可能会在几分钟内演变成灾难性的成本飙升。在账单寄到之前，错误率一直保持为零。

心智模型的转变：是分布，而非决策

正确的框架不是“这是否出错了？”，而是“质量分布是否偏移出了可接受的容差范围？”

这重塑了发布流程的每一个环节。

你衡量什么。 与其关注错误率和延迟百分位，你需要的是任务成功率、幻觉率、输出格式遵守度、输出与参考答案之间的语义相似度漂移，以及像会话放弃率和重写提示率（re-prompt rate）这样的行为代理指标。这些指标需要构建一个评估层，而这在任何标准的可观测性栈中都是不自带的。

你何时可以做决策。 传统的金丝雀分析（canary analysis）可以在 30–60 分钟内完成。而 AI 功能的质量评估需要积累足够的输出来对质量评分分布进行统计测试。请按小时而非分钟来做计划。对于那些基准真相（ground truth）需要下游信号（用户是否完成了任务？他们是否回来了？）的功能，请按天来做计划。

什么能通过你的 CI 门禁。 对于确定性代码，CI 门禁是单元测试的通过/失败。对于 AI 功能，门禁是在精心策划的黄金数据集（golden dataset）上高于阈值的评估分数。如果一个提示词（prompt）的更改导致你的 LLM-as-judge 质量分数从 0.87 降至 0.79，那这就应该像测试失败一样阻止部署——正如处理失败的测试那样。

回滚意味着什么。 对于软件，回滚是即时的。对于 AI 功能，提示词版本、模型权重和知识库可能是独立版本化的。一个有效的回滚策略需要将所有这些打包成不可变的、原子化的版本快照，这样你才能真正恢复到一个已知的良好状态，而不是部分撤销。

行之有效的模式

在正式流量前采用影子模式（Shadow mode）。 在生产环境并行运行新模型版本，记录其输出但绝不提供给用户。进行线下对比。这是置信度最高的方法：零用户影响，最大信号。Uber 在其超过 75% 的关键在线机器学习（ML）场景中应用了影子测试。权衡之处在于成本——你正在并行运行两个系统——以及缺乏真实的用户交互信号（用户无法对他们看不见的输出做出反应）。

以 LLM 为评判者的质量门禁。 使用一个独立的模型来大规模评估主模型的输出。研究表明，LLM 评判者与人类判断的一致性约为 85%——这与人类评估者之间的一致性相当。模式是：针对你的黄金数据集运行候选模型，让评判者对每个输出进行打分，在推送到正式流量之前，要求平均分高于阈值。这使质量成为一流的 CI 门禁，而不是事后才考虑的事情。

分阶段扩大自主权，而非流量百分比。 与其将 1% 的流量发送给新模型，不如分阶段扩大功能的自主权。从建议模式（suggestion mode）开始，AI 提供建议但由人类接受或拒绝。在置信度高的情况下推进到受监督的自主（supervised autonomy）。只有在早期阶段积累了足够的信号后，才达到完全自主。这就是 Ramp 为其费用审批代理所实现的——它现在自动处理 65% 以上的审批，这是通过分阶段的信任扩展而非金丝雀百分比增长实现的。

按用户信任层级进行渐进式暴露。 内部工程师 → 内部员工 → 选择加入的测试用户 → 资深用户 → 正式发布。这确保了你的早期采用者是最耐错的，并且最有可能提供详细的反馈，同时保护更广泛的用户群免受早期质量问题的影响。

将评估（Evals）作为部署拦截器。 构建一个包含 500–2,000 个关键输入/输出对的精选黄金数据集。任何提示词更改、模型版本升级或工具 Schema 更新都必须在部署前通过评估套件。对待质量分数下降要像对待测试失败一样：不通过则不发布。

运营现实

这些在事后补救都不容易。影子模式需要能够运行并行模型版本的基础设施。LLM-as-judge 为你的 CI 流水线增加了评估成本和延迟。黄金数据集需要维护时间，并且会随着生产分布的偏移而失效。分阶段的自主权扩展需要产品和工程部门在你的业务场景中对“受监督”的定义达成一致。

做对这些的团队在第一个功能推向生产之前，就将 LLM 评估基础设施视为一流的投资，而不是在下个季度才去填补的观测空白。没做对的团队通常是通过用户投诉、成本事件或负面新闻报道才发现问题——而所有这些都发生在发布完成很久之后，线索已经中断。

核心教训是令人不安的：使软件部署安全且可逆的工具和流程并不能直接迁移。渐进式发布看起来像是尽职调查，但对于 AI 功能来说，它们更像是表演——一种应用于本质上不同的系统的熟悉仪式，为一个可能正以仪器无法察觉的方式失败的发布提供一种虚假的控制感。

先构建评估基础设施。根据质量分数设置门禁。扩大自主权，而不仅仅是流量。接受反馈循环变慢的事实，并据此进行投资。