跳到主要内容

AI 模型的持续部署:你的回滚信号是错误的

· 阅读需 11 分钟
Tian Pan
Software Engineer

你的部署流水线是绿色的。延迟处于正常水平。错误率:0.02%。新的模型版本已成功发布——或者说你的仪表盘是这么显示的。

与此同时,你面向客户的 AI 正在微妙地以较低的精度总结文档,对以前能直接回答的问题含糊其辞,并不时地压平下游流水线所依赖的结构化输出。没有警报响起。没有触发值班呼叫。你收到的第一个信号是两周后的一张支持工单。

这就是 AI 部署中的隐性回归问题。传统的回滚信号——HTTP 错误、p99 延迟、异常率——是为确定性软件构建的。它们无法察觉行为漂移。随着团队更频繁地升级语言模型,“基础设施健康”与“AI 运行正确”之间的鸿沟成了回归问题的藏身之处。

为什么你当前的回滚指标是盲目的

在标准的软件部署中,一个糟糕的发布通常会“大声”报错。配置错误的端点会返回 500。损坏的函数会抛出异常。基础设施层可以察觉失败并自动触发回滚。

模型升级完全打破了这一假设。当你从一个模型版本切换到另一个版本时——或者从外部提供商迁移到微调过的内部模型时——服务基础设施无法洞察模型的行为是否发生了变化。新模型可能会:

  • 返回更短、细节更少的响应,且通过了所有格式验证
  • 在以前给出直接回答的地方开始含糊其辞
  • 改变其默认的推理深度,从而破坏下游 Agent
  • 在语气、冗长度或结构化输出模式上发生漂移

所有这些都表现为带有有效 JSON 主体的 HTTP 200。你的监控系统看不出任何异常。

生产数据使这一点变得具体:模型重新部署时的行为差异是以两位数百分比衡量的。响应长度的波动、指令遵循的一致性以及事实深度都会在模型版本变化时发生偏移——即使版本号看起来只是一个小幅提升。从性能下降开始到收到第一个用户投诉的平均时间是以周计的,而不是分钟。

根本问题在于 AI 系统有两个截然不同的健康维度:基础设施健康(服务是否在线?)和行为健康(AI 是否在做正确的事?)。传统的部署工具只能衡量前者。

模型升级的三阶段部署模式

解决过此问题的团队通常会采用一种顺序方法:先是影子测试,然后是灰度发布 (Canary),最后是全量切换。在进入下一阶段之前,每个阶段都要回答一个不同的问题。

第一阶段:影子部署。 将新模型版本部署到一个接收所有实时流量副本的端点,但其响应会被丢弃——用户只看到当前生产模型的响应。这使你可以在不暴露给用户的情况下,获得真实输入的行为数据。影子部署是针对生产查询的全量分布(包括离线评估集中从未出现的边缘情况)验证新模型的唯一安全方法。

影子流量揭示了与 A/B 测试不同类别的问题。A/B 测试衡量用户在给定选项下的偏好。影子测试衡量新模型在相同输入下与当前模型的行为是否一致,而不受用户选择的影响。你可以在任何用户看到新模型之前,捕捉到格式回归、罕见输入模式下的隐性故障模式以及吞吐量特性。

第二阶段:灰度发布 (Canary)。 将一小部分(通常是 3–10%)的实时流量路由到新模型。持续对灰度输出运行行为评估指标。实时监控差异信号。设置自动回滚阈值,如果指标超过定义的范围,则将流量切回到旧模型。

与传统灰度发布的关键区别在于回滚信号。触发回滚的不是错误率或延迟,而是行为差异指标(如下所述)。一个看起来基础设施健康的灰度版本在行为层面上仍可能失败——如果没有行为指标作为门禁,直到灰度版本被全量推广,你才会发现问题。

第三阶段:全量切换。 一旦灰度指标在定义的观察期(通常为 24–72 小时)内保持稳定,就将所有流量切换到新模型。保持旧模型端点在线至少一个额外的观察期,以防出现滞后的回归问题。

这个序列比直接切换成本更高,但与通过用户投诉才发现回归问题相比,在影响范围超过 5% 的流量之前捕捉到它,这点成本是微不足道的。

行为差异作为真正的回滚信号

核心问题是:哪些指标实际上能在用户发现之前检测到行为回归?

黄金数据集上的评估分数增量 (Delta)。 维护一套精选的 50–200 个代表性输入及预期输出——并针对事实性、指令遵循度、格式正确性和特定任务的准确性进行标注。在推广任何模型之前,针对这套数据集运行旧版本和新版本。计算每个指标的增量。如果任何指标下降超过你的阈值(通常是绝对值的 2–5%),则阻止推广并进行调查。

必须主动维护黄金数据集。六个月前具有代表性的输入可能无法捕捉当前的生产查询分布。每季度轮换示例,并在生产中出现新的边缘情况时进行标注。

嵌入向量余弦漂移。 对两个模型版本的输出样本进行嵌入 (Embedding),并衡量相同输入下新旧输出之间的平均余弦相似度。高余弦相似度意味着模型表达的内容大致相同;低相似度预示着语义差异,这可能是也可能不是故意的。

该指标需要校准。使输出更准确的模型改进也会表现为差异。你寻找的是伴随着评估分数下降的差异——这种组合才意味着回归,而不仅仅是变化。

LLM 作为裁判 (LLM-as-judge) 评分。 使用一个单独的评估模型根据评分标准对灰度输出进行评分:准确性、指令遵循度、语气、冗长度以及任何特定任务的标准。对两个模型的相同输入进行评分并比较分布情况。这是最灵活的方法,因为你可以定义符合实际需求的评估标准,而不是依赖通用的基准测试。

保持评估标准的聚焦——每次调用 3 到 5 个标准——以维持信号质量。试图同时对太多维度进行评分的评估器会产生稀释且不可靠的分数。在将其信任为部署门禁之前,请先根据人工标注校准你的评估器。

输出分布统计。 跟踪更简单的统计属性作为领先指标:响应长度分布、结构化模式合规性(输出是否符合预期的 JSON 模式或标题结构?)以及拒绝率。这些计算成本低廉且告警迅速。它们无法捕捉微妙的语义漂移,但能立即发现格式回归。

生产灰度门禁通常结合了所有这四种信号:任何单一阈值的突破都会触发调查,两个或更多阈值的突破将触发自动回滚。

为什么固定模型版本只能换取时间,而非安全

面对这个问题,最自然的反应是将你的部署固定(Pin)在特定的模型版本上,并按照自己的节奏进行更新。这在战术上是正确的建议,但它会制造一种长期安全的错觉。

模型提供商会停用版本快照。当一个固定版本到达生命周期终点(EOL)时,你将面临强制迁移,而由于停用通知提供的缓冲期通常只有 90 天或更短。那些一直依赖固定版本而不是构建行为评估基础设施的团队,突然需要在截止日期的压力下验证重大的模型切换,却缺乏安全执行此操作的工具。

固定版本之下的推理服务基础设施也不是静止不变的。提供商会在不改变版本标识符的情况下更新量化参数、采样实现和批处理策略。这些基础设施层面的变更可能会改变输出行为,而这种改变对版本锁定是不可见的。

内部微调使情况更加复杂。如果你“固定”的模型是一个微调衍生版本,那么你构建训练批次的方式、设置超参数的方式,甚至数据流水线预处理输入的方式,都可能随着时间的推移导致模型行为发生漂移——而这一切发生时,版本字符串依然保持不变。

当你需要在高风险时期保持稳定时,固定版本是一种合理的短期策略。但你应该将其视为在构建确保升级安全的评估基础设施时的“暂停升级协议”,而不是该基础设施的永久替代品。

构建部署门控

一个实用的行为部署门控由三个组件组成:评估框架、流量层和告警策略。

评估框架针对旧模型和新模型的输出运行你的黄金数据集(Golden Dataset)和 LLM-as-judge 评分标准。它计算每个指标的得分、增量和置信区间。它应该在金丝雀阶段持续运行,而不仅仅是在部署时运行——因为随着全天流量模式的变化,行为漂移可能会逐渐显现。

流量层实现金丝雀切分和回滚触发器。现代推理平台(如 AWS SageMaker、GCP Vertex AI)原生支持基于百分比的流量切分,并能根据指标阈值自动回滚。如果你运行的是自己的推理基础设施,请在反向代理层(如 Envoy、HAProxy)实现流量整形,并通过告警钩子(Webhook)将其连接到你的评估框架。

告警策略定义了阈值和升级路径。并非所有的行为差异都是坏事——模型升级可能会有意改变输出风格。你的策略需要区分“回归”(差异加评估得分下降)和“改进”(差异加评估得分提升),并将它们路由到不同的工作流。回归触发自动回滚;改进则需要人工签核后才能发布。

实践中的应用场景

一个正在升级其文档摘要模型的团队可能会执行以下流程:

他们在影子模式(Shadow Mode)下部署新模型 48 小时,捕获完整生产查询分布下的输出。他们运行黄金数据集评估,发现事实性得分提高了 3%,但注意到新模型的输出长度平均下降了 18%。他们调查了长度缩减的原因——在他们的案例中,发现新模型跳过了长文档的某些部分。

他们认为长度回归对他们的用例来说是个问题。他们没有直接发布或回滚,而是调整了提示词(Prompt)以补偿新模型的摘要风格,重新运行影子评估,确认指标差距缩小,然后进入金丝雀阶段。

在 5% 的金丝雀阶段,其 LLM-as-judge 得分保持稳定。他们观察金丝雀版本 36 小时,确认没有违反任何指标,然后将流量全部切换到新模型。

从新模型发布到全量生产上线总共耗时:五天,大部分时间花在观察窗口上。他们捕获的长度回归对用户造成的总影响:零。

这就是“部署模型”与“安全部署模型”之间的区别。

展望

行为部署门控的工具链正在迅速成熟。专用可观测性平台现在开箱即用地提供嵌入漂移检测(Embedding Drift Detection)、LLM-as-judge 集成和自动回滚钩子。投资于这些基础设施的团队虽然支付了前期建设成本,但随后获得了自信且频繁升级模型的能力。

另一种选择——将模型升级视为库版本升级,并依赖 HTTP 指标来捕获问题——这种方法在出事前看起来总是行得通。鉴于模型提供商现在每月都会发布重大的能力更新,升级的频率只会不断增加。服务于软件部署数十年的基础设施健康指标,在 AI 系统日益成为生产工作负载核心的过程中,将继续发生静默失败。

现在就构建行为评估层,趁着现在的“回归”还只是学习经验,而不是生产事故。

References:Let's stay in touch and Follow me for more thoughts and updates