65 篇博文 含有标签「mlops」

在某个预发布（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% 的机器学习模型会随时间降级，而且大多数降级是悄无声息的。系统继续运行，代码没有变化，但随着现实世界不断演进而模型原地踏步，预测结果越来越差。

过去三年，工程团队上线的AI功能数量超过了此前十年的总和。但他们几乎没有下线过任何一个。德勤的研究发现，2025年有42%的公司放弃了至少一个AI项目——相比前一年的17%大幅上升——每个被废弃项目的平均沉没成本高达720万美元。然而，那些留在生产环境中的功能往往比被砍掉的更具破坏性：它们缓慢侵蚀用户信任，积累每月复利的技术债，并消耗本可用于有效工作的工程资源。

这种不对称是结构性的。AI功能上线会带来公告、利益相关方的兴奋和团队荣誉。而退场则被视为失败的承认。因此，糟糕的功能不断积累。解决之道不是意志力，而是一套决策框架——让退场成为一种正常、可预期的工程结果，而非组织危机。

你的模型通过了公平性审查。人口统计学平价（demographic parity）在可接受范围内，机会均等指标（equal opportunity metrics）看起来很干净，审计报告也被贴上了绿色的勾，进入了 Confluence。三个月后，一名记者拿出的屏幕截图显示，你的系统对某一人口群体的贷款批准率仅为另一群体的一半——而你发布前的那些数据在技术层面一直都是准确的。

这就是偏差监控的缺口。发布前的公平性测试是根据运行测试时存在的数据集来验证你的模型的。但在生产环境中运行的 AI 系统并不处于那种静态的世界中。用户行为会发生变化，人口分布会产生偏移，特征相关性会演变，而那些在发布时无法衡量的差异可能在几周内演变成严重的失效模式。能够捕捉这些问题的系统，在当今大多数 ML 技术栈中都是缺失的。

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

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

大多数 AI 流水线故障并非模型问题。模型运行正常，输出看起来也是 JSON，但下游阶段却悄然崩溃——原因可能是字段被重命名、类型发生变化，或者嵌套对象新增了一个下游阶段根本不知道如何处理的必填属性。流水线执行完毕并报告成功，而某个数据仓库里的数字已经悄悄出错。

这就是 AI 流水线的契约测试问题，也是生产 AI 系统中最被忽视的可靠性风险之一。根据近期基础设施基准数据，企业 AI 系统平均每月发生近五次流水线故障，每次解决耗时超过十二小时。主要原因并非模型质量差，而是数据质量和 Schema 契约违规：64% 的 AI 风险存在于 Schema 层。

每位产品负责人都听过这个论调：更多用户产生更多数据，更好的数据训练更好的模型，更好的模型吸引更多用户。数据飞轮是复利护城河，这正是AI巨头们能够赢得市场的原因。

这个论调并没有错。但实施几乎总是出了问题。在实践中，大多数数据飞轮都有多个泄漏点——反馈循环看似在运转，实际上却在放大偏差、强化陈旧模式，或者优化一个与真实目标背道而驰的代理指标。构建这些系统的工程师很少知道自己遇到的是哪种泄漏，因为所有泄漏从外部看起来都一样：参与度上升，模型在可测量的指标上持续改进，而系统却在难以归因的方式下变得越来越没用。

这就是数据飞轮陷阱。理解其失败模式，是构建真正有效飞轮的前提。

大多数团队将他们的黄金评估集（golden eval set）视为宪法——持久、权威且变动成本极高。他们花数周时间挑选案例，请领域专家进行标注，并将其接入 CI。然后，他们就转去忙别的事了。

六个月后，评估套件显示通过率为 87%，但用户却在抱怨输出结果支离破碎。评估指标并没有倒退——它们只是腐化了。该数据集测量的仍然是 10 月份重要的数据。它只是不再测量现在重要的数据。

这就是黄金数据集腐化问题（golden dataset decay problem），它比大多数团队愿意承认的更为普遍。

模型卡显示代码生成准确率为 89%。你的团队在实际代码库上只得到了 28%。模型卡显示有 100K token 的上下文窗口。而在你的文档工作负载下，性能在 32K 时就大幅下降。模型卡通过了红队安全评估。但在上线后的 72 小时内，针对用户的提示词注入攻击就出现了。

这种差距并不罕见。这已成为常态。在 2025 年对 1,200 个生产部署的分析中，42% 的公司在生产集成阶段放弃了他们的 AI 计划 —— 高于前一年的 17%。他们中的大多数都仔细阅读过模型卡。

问题不在于模型卡撒谎。而在于它们衡量的内容与你需要了解的内容不同。准确理解这一差距 —— 并构建内部基准测试套件来弥补它 —— 是交付可靠 AI 的团队与交付懊悔的团队之间的分水岭。

你的 AI 功能在内部测试中表现出色。工程师拍手叫好，产品经理竖起大拇指，评估套件在基准测试中显示了 94% 的准确率。然后你上线了，两周之内，用户就遇到了你从未见过的故障模式——错误的答案、混乱的输出，以及让模型显得极为糟糕的边缘情况。

这就是生产分布差距（production distribution gap）。这不是一个新问题，但对 AI 系统来说，它比确定性软件严重得多。理解其背后的原因——并制定具体的解决方案——是决定 AI 功能悄然侵蚀用户信任还是随着使用不断改进的关键分水岭。