109 篇博文 含有标签「mlops」

在 1 月下旬的一个周一早上，仪表盘发出了第一次回归预警。支持助手的质量得分一夜之间下降了 3 分。周末没有发布 Prompt 变更。没有更换模型。评估套件——团队在 6 个月前构建的一个包含 800 行数据的精选黄金集 (gold set)——也没有任何变化。有人开了一个故障单 (incident)。

经过两天的二分定位 (bisecting) 之后，得到的答案平淡无奇且是结构性的。那是美国国税局 (IRS) 开启当年税务申报后的第一个工作周一。一半的入站查询已从“我的薪水到账了吗”变成了“我该如何申报来自支付 App 的 1099-K 表单”。在夏季采样的评估集对 1099-K 毫无头绪。模型并没有变差。是客户变了。评估标准是针对一个已经不存在的客户群进行校准的。

这种模式在每一个拥有季节性用户的产品中每季度都会重复出现——报税季的金融科技、季度末的销售工具、开学季的教育产品、退货季的电子商务、订票季的旅游产品、投保季的医疗保健。将“评估集视为固定资产”是一种舒适的抽象，但在一个无人更新的日程表上，这种做法是错误的。

黄金评估集的通过率为 94%。模型在本季度已经升级了两次，提示词修改了 11 次，工具库增加了 4 个，仪表盘依然是一片绿色。然而，一名销售工程师转发了一份对话记录，显示智能体（Agent）自信地将客户引导至一个两个月前就已停用的工作流；与此同时，支持团队负责人悄悄开启了一个讨论组，询问为什么在评估流水线显示没有回归的情况下，满意度评分已经连续下滑了六周。黄金集并没有撒谎。它只是在用上个季度的产品标准来衡量这个季度的流量，而除此之外没人要求它做别的事。

这是评估系统最难察觉的一种失效模式，因为本该检测质量回归的工具本身就是误报的源头。通过率是针对集合中的项目计算的；集合中的项目是根据某个时间点的使用快照精心筛选的；用户的使用方式已经演进，但通过率依然保持“干净”。团队信任绿色的仪表盘，发布了另一个模型升级，几个月后才发现生产环境的分布与评估集所衡量的东西已经南辕北辙，而这种状态持续的时间超出了所有人的想象。

解决方法并不是提高黄金集的更新频率。更新频率是一个错误的调节旋钮；正确的旋钮是拥有第二个针对不同时间窗口校准的工具，以便在用户发现问题之前，通过两者之间的分歧来暴露漂移。这第二个工具就是影子评估（Shadow Eval）—— 一个从当前生产流量中持续重建的并行评估集，它与黄金集并行运行，其明确的任务就是与黄金集唱反调。

我上个季度合作的一个团队在周二凌晨 2:14 向生产环境推送了一个回归错误。值班警报触发了，因为其摘要代理（summarization agent）下游的 JSON 解析器以“尾随逗号错误”拒绝了二十分之一的响应。模型没变。提示词（prompt）没变。评估套件在前一天晚上的通过率为 96.4%，稳稳高于 95% 的准入门槛。改变的只是 package.json 中的一行：模型提供商的 SDK 从 4.6.2 升级到了 4.6.3。补丁更新（Patch bump）。由依赖机器人自动合并。发布说明里写着“内部清理”。

所谓的“内部清理”是一个收紧的 JSON 模式解析器，它删除了一个宽容的后备路径，而这个路径此前一直在默默修复模型工具调用输出中反复出现的尾随逗号怪癖。模型的行为没有改变。但 SDK 对该行为的解释改变了。团队的评估套件从未发现这个回归，因为评估套件运行的 SDK 版本与依赖机器人刚刚推送的版本不同。

这就是 LLM SDK 升级税，它是当今生产环境 AI 中最隐蔽、代价最昂贵的故障模式之一。SDK 不是被动的传输工具。它是你提示词行为的积极参与者，而那些在没有评估的情况下升级 SDK 的团队，实际上是在进行一场伪装的模型发布。

针对糟糕的代码部署，标准流程是在一分钟内完成回滚。针对错误的配置推送，标准流程是亚秒级的开关切换。而针对糟糕的模型升级，应对方案则是值班工程师在早上 09:14 临时想出的法子，而且通常需要耗时 7 小时才能完成。在这 7 小时内，性能倒退持续累积——错误的答案被发送给客户，支持工单堆积如山，而监控面板显示的只是缓慢的倾斜曲线，而非迅速回归绿色的断崖式好转。

差距之所以长达 7 小时，并非因为团队动作缓慢，而是因为模型升级的“回滚”与代码的“回滚”并非同一种原语。它更接近于数据库模式（schema）迁移：局部的、滞后的，且无法通过按下你希望存在的那个按钮来撤销。围绕“一个按钮”编写事故应对方案的团队，并不具备实际回滚所需的控制能力。

这篇文章将探讨这些控制能力具体是什么样的，为什么必须提前为此付出代价，以及当你第一次尝试在负载下回滚模型时，你会对你的平台有哪些新发现。

一个新的嵌入模型发布了。基准测试数据提升了 4 %。一位 Staff 工程师提交了一个工单：“将 embedding 升级到 v3。”两周后，索引已完成重新嵌入，别名已切换，团队通过特性标志（feature flag）发布了变更。六周后，支持工单堆积如山。搜索结果“感觉不对劲”。复盘会召开了。没人能解释为什么出现了退化，因为没有系统崩溃，每个仪表盘显示的都是绿色。

问题不在于模型的更换。问题在于向量存储根本不知道哪些向量来自哪个模型。数据库里没有这一列。没有用于追踪哪些记录已回填的迁移表。没有 alembic_version 行，没有 schema_migrations 表，也没有先前状态的 pg_dump。团队将 embedding 升级视为一次简单的配置切换，而向量存储在模式（schema）层面缺乏能阻止他们犯错的概念。

Embedding 迁移需要数据库迁移二十年来一直依赖的相同产物：写入每个向量、在每次查询时检索、并作为切换和回滚准入准则的单条记录版本标签。这是大多数团队最容易忘记添加的一列，而后期补救的成本远高于前期添加。

模型发布的公告在周二早上落地。博客文章开头是一张图表：HumanEval 提升了 4 个点，SWE-bench Verified 提升了 6 个点，MATH 提升了 3 个点，而当前流行的 Agent 测试套件提升的数值在一年之前足以写成一篇研究论文。到了周二下午，你公司的 Slack 频道里就会出现该图表的截图，随之而来的还有一个类似决策的问题：“我们要切换过去吗？”这个讨论线程将基准测试的增量视为一种预测 —— 仿佛这些数字描述了新模型在 你的 产品中、使用 你的 提示词、在 你的 工具链下、针对 你的 评估准则所能表现出的效果。事实并非如此。厂商给出的数字是你可能看到的性能上限。你实际获得的提升大约在零到该标题数值的一半之间，如果不运行一次厂商从未运行过的评估，你无法得知确切结果。

这并非在抱怨基准测试的有效性。基准测试是真实的。它们是针对真实的评估套件运行的。厂商没有撒谎。问题在于厂商的评估套件是一个理想化的环境，剥离了生产部署中引入的每一个变量，而在这些条件下生成的数字在结构上无法预测模型在你环境下的行为。将其视为一种预测是一种范畴错误 —— 它会导致采购决策、容量规划承诺以及发布时间表都基于虚构的事实进行校准。

大多数团队在生产环境中第一次更换嵌入模型（embedding model）时，都会将其视为批处理作业。重新运行嵌入器，构建新索引，切换别名，然后部署。延迟保持正常。错误率为零。每个查询都有结果。然而，检索质量会在数周内悄悄下降，而没人察觉。因为症状是“用户抱怨答案感觉不对”，而不是监控面板上的红报警报。

这不仅仅是部署问题，而是一个团队决定盲目进行的架构迁移（schema migration）。旧的嵌入空间和新的嵌入空间是不同的参考系；以前表示“这两个段落关于同一个话题”的余弦几何（cosine geometry）在数值置信度上不再具有相同的含义。以前聚集在一起的文档和查询会以非均匀的方式漂移。在旧分布上训练的重排序器（re-rankers）会开始处理那些不再符合其学习规律的样本。对逐点相关性（pointwise relevance）评分正常的评估套件会漏掉这一切，因为没有任何单个文档移动得太远，但整个图谱发生了旋转。

如果将这种更换视为数据库迁移，几乎所有出错的情况都是可以预防的。如果将其视为批处理作业，那么回归（regressions）就会按照无人负责的进度表悄然降临。

你在 09:14 发布了一个系统提示词（system-prompt）变更。发布仪表盘在 09:31 变绿。到 11:00 时，你的评估追踪器依然显示正常，成本仪表盘也无异常，但一位客户成功工程师联系了团队：仅在亚太地区，解析端的结构化输出错误上升了约 3%。北美无异常。欧洲无异常。

发布在覆盖 67% 的区域时自动暂停了，因为某个 POP 节点上的一个非核心健康检查在切换期间发生了抖动，而当时没人注意到。在六个小时里，us-east 和 eu-west 运行着提示词 v47，而 ap-south 和 ap-northeast 仍停留在 v46。你正在运行一个按地理位置划分的实时 A/B 测试——只不过这个测试不是你设计的，你看不到测试过程，而且那个本应捕捉质量回退的评估套件正巧连接到其中一个区域的新版本，然后若无其事地忽略了问题。

这种失败模式并不是单个工具的 bug。它是将提示词通过为不同类型的工件构建的部署系统进行推送时，所产生的可预见的后果。

在某个预发布（staging）频道里，一位工程师写道：“将嵌入模型（embedder）升级到 v3，新模型在 MTEB 上的得分提高了 4 分，冒烟测试通过后合并。”两天后，客服工单开始陆陆续续出现，反馈搜索结果感觉“莫名其妙地不对劲”。一周后，检索精度下降了 14 个百分点，余弦相似度分数从 0.85 暴跌至 0.65 左右，而且没人能解释原因——因为这次部署看起来与过去五次模型升级完全一样。这根本不是一次普通的部署。而是一次披着部署外衣的数据库迁移。

嵌入模型轮转是 AI 基础设施中最容易被归类错误的变更类型。它通过与提示词（prompt）微调或生成模型版本更新相同的渠道进入你的系统——配置文件、PR、CI 检查——因此它遵循配置变更的治理流程。但从底层来看，新的嵌入模型并不会产生旧向量的更好版本。它产生的向量完全存在于不同的坐标系中，跨两个流形计算余弦相似度是一个范畴错误（category error）。正确的心理模型不是“升级依赖版本”，而是“在提供读取服务的同时，为一个拥有 5000 万行的表更换主键编码”。

一名高级工程师在六个月前离职了。她负责管理用于路由客户支持工单的分类器适配器——这是一个基于 847 个手动标注样本训练的 32 秩 LoRA，挂载在一个还有 43 天就要停用的基础模型上。没人记得为什么从最初的 2,000 个样本中选出了这 847 个。训练数据存在一个 S3 存储桶里，由于其生命周期策略，超过一年的对象会被自动清除。她的笔记本电脑已被抹除。那个微调笔记本（notebook）中有一个单元格调用了一个预处理函数，该函数是从她个人的 dotfiles 仓库导入的，而现在那个仓库是私有的。

这就是“孤儿适配器”（Orphan Adapter）——一个比其维护者、数据甚至其所基于的基础模型寿命更长的微调模型。它存在于你的生产栈中，路由着真实的流量，而团队中没人能重新构建它。停用邮件并没有制造这场危机，它只是揭露了危机。

金丝雀部署完美收工：错误率纹丝不动，延迟没有飙升，监控大盘一片绿色。你将新模型全量推送给所有流量——三周后，客服队列里挤满了用户投诉，说 AI "感觉不对劲"、"不再有用了"。

这正是将传统功能开关机制套用到 AI 系统上的核心问题。一个模型可以在"没有崩溃"的情况下悄悄退化：它照常返回 200 状态码，以正常速度生成 token，输出的文本也能通过表面校验——但与此同时，它的幻觉频率在悄悄上升，回答越来越简短或回避，或者在你的用户真正依赖的细微推理模式上悄然退步。你多年来一直监控的遥测指标，从来就不是为了捕捉这类故障而设计的。

你的 AI 功能上线一切顺利。演示令人印象深刻，发布指标看起来很好，模型在测试集上的基准准确率达到了 88%。大约三个月后，一位客户成功经理转发了一张截图。AI 推荐结果毫无道理。你查看日志，进行快速评估，发现准确率已经漂移到 71%。没有任何警报触发，没有抛出任何错误。整个过程中基础设施监控面板一直显示绿色。

这种情况并非偶发。对 32 个生产数据集的研究发现，91% 的机器学习模型会随时间降级，而且大多数降级是悄无声息的。系统继续运行，代码没有变化，但随着现实世界不断演进而模型原地踏步，预测结果越来越差。