123 篇博文 含有标签「mlops」

你的 AI 功能顺利上线了。延迟很低，错误率微乎其微，HTTP 响应全是 200。六个月后，一名用户抱怨聊天机器人言之凿凿地推荐了一款你在三个月前就停产的产品。工程师深入调查后发现，系统在回答用户问题时，有三分之一的情况都是错误的——这不是因为代码部署出了问题，也不是因为依赖项升级，而是因为时间的流逝。你将一张快照交付到了奔流的河水中。

这并非假设。行业数据表明，91% 的生产环境 LLM 在部署后的 90 天内会出现可衡量的行为漂移。一个最初能在无需人工干预的情况下处理 70% 查询的客户支持机器人，到第三个月时，这一比例可能会悄然下降到 50% 以下——而此时，基础设施仪表盘全程显示的都是代表正常的绿色。“六个月悬崖”是真实存在的，它是无声的，而且大多数团队并没有能够预见其到来的监测手段。

当一个人脸识别系统报告95%的准确率时，你的第一直觉是发布它。但这个直觉是错的。同一个系统可能同时对深肤色女性的错误率高达34%，而对浅肤色男性只有0.8%——40倍的差异，完全隐藏在那个令人安心的聚合数字里。

这就是聚合准确率幻觉，它正在摧毁从招聘到医疗保健再到语音识别等各个行业的生产AI功能。这种模式在结构上与辛普森悖论相同：一个在聚合层面看起来公平的模型，可以同时在每个有意义的子群体上进行系统性歧视。聚合指标是加权平均值。当某些子群体在评估集中数量较少或代表性不足时，其失败率会被多数群体的成功所稀释。

修复方法不是换一个不同的准确率阈值，而是分类评估——按子群体计算性能指标，定义差异SLO，并像监控延迟和错误率一样在生产中持续监控它们。

你发布了一个AI功能，用户喜爱它，然后三个月后，支持收件箱里塞满了困惑的投诉。你的基础设施没有任何改动。代码一模一样。但这个功能悄无声息地变差了。

这就是AI功能维护悬崖：累积的无声退化变成可见故障的那一刻。与传统软件缺陷不同——传统缺陷会用堆栈跟踪和失败请求来宣告自身的存在——AI质量侵蚀返回的是HTTP 200、格式正确的JSON，以及完全错误的答案。你的监控面板是绿色的。你的功能已经坏掉了。

一项涵盖四个行业32个数据集的跨机构研究发现，91%的机器学习模型会在没有主动干预的情况下随时间退化。这不是尾部风险——这是你发布并撒手不管的每一个AI功能的预期结果。

你的团队在六个月前发布了一项由 AI 驱动的摘要功能。采用率停滞在 8% 的用户。模型调用每月耗资 4,000 美元。构建该功能的工程师已经调到了另一个团队。现在，模型提供商正在涨价。

所有的直觉都在告诉你：砍掉它。但事实证明，停掉一个 AI 功能要比停掉任何其他类型的功能都难得多——大多数团队都是在退役过程中，当合规问题开始出现、核心用户开始反抗时，才以惨痛的方式意识到这一点的。

这是一份在发布功能之前就应该存在的指南，但在你盯着那些明显指向退出的使用率图表时，它最为有用。

传统的技术债务往往会自我显现。构建缓慢、测试失败、或是被抑制了六个月的 lint 警告——这些都是你可以通过 grep 搜索、转化为工单并排入冲刺（sprint）的症状。AI 特有的债务则不同。它在部署的间隙中悄然累积，在任何人意识到数据波动之前，它就已经降低了系统的性能。

大多数生产环境中的 AI 系统现在都有三个正在滴答作响的“债务时钟”。第一个是当特定模型版本流行时才有意义的提示词（prompt）。第二个是在构建时能代表用户行为，但现在已经过时的评估集（evaluation set）。第三个是仍在支撑检索层的嵌入（embeddings）索引，它们是由早已被弃用的模型生成的。每个时钟独立运行。三者共同叠加。

大多数团队在选择标注策略时，都会比较单价：众包工人大约 $0.08/条，LLM 生成不到$0.003/条，人类领域专家约 $1/条。跑一遍表格，选出看起来"足够好"的最便宜选项，然后上线。这套算法经常让团队陷入麻烦。

真正的决策并非只看单条标签的成本。每种标签来源都有一个隐藏的质量税——以垃圾梯度、误导性评估曲线，或花费数月排查生产故障的形式复利叠加；而干净的标签本可以在训练阶段就捕获这些问题。最便宜的来源往往是计入下游信任成本后最昂贵的一种。

大多数构建 AI 产品的团队会花费数周时间设计评分组件、星级点击、点赞/点踩按钮。然而六个月后，他们查看数据时发现响应率仅为 2% —— 数据偏向于极端体验，被那些带有强烈偏好的人主导，而且在区分 7/10 和 9/10 的输出方面几乎毫无用处。

与此同时，每一个用户会话都在产生源源不断的真实、明确的行为信号。接受代码建议并继续操作的用户是满意的。立即按下 Ctrl+Z 的用户则不满意。连续四次重新组织问题的用户正在告诉你一些显式评分永远无法捕捉到的信息：前三次回答都失败了。无论你是否收集，这些信号都存在。问题在于你是否正在闭合这个反馈回路。

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

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

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

大多数团队会在最糟糕的时机发现同一个事实：下线一个 AI 功能与废弃一个 API 完全不同。你在文档中添加了停用日期，发送了常规的三封系列邮件，切换了标志位——然后眼睁睁地看着支持队列激增 80%，而用户则大声解释替代方案“运行方式不一样”。他们的意思是：旧智能体的怪癖、特定的故障模式、以及它独有的错误答案，都已经变成了业务中不可或缺的支撑。他们在那些直到消失才被察觉的行为基础上，构建了整个工作流。

这就是 AI 功能废弃的核心问题。确定性 API 具有明确的契约（contracts）。如果你移除一个端点，每个依赖它的调用者都会收到 404 错误。损坏是可追踪、有限且可预测的。概率性 AI 的输出则不同——用户集成的不是契约，而是行为分布。移除一个模型不仅是移除了一项功能，它还移除了一种特定的行为模式，用户可能在没有意识到的情况下花了几个月的时间去适应它。

你的 RAG 系统运行正常。延迟处于常规水平。错误率为零。但一位询问“加州雇佣法”的用户却不断得到关于房地产的搜索结果 —— 而你的日志显示一切正常。

这就是嵌入漂移（embedding drift）在作祟：这是一种不会抛出异常、不会导致错误率飙升，也不会出现在标准可观测性仪表盘上的检索失效模式。当你的向量数据库积累了在不同条件下生成的嵌入时 —— 比如不同的模型版本、不同的分块规则、不同的预处理流水线 —— 向量开始指向不兼容的方向，这种情况就会发生。系统仍在处理请求，但语义坐标已不再对齐，检索质量在数周或数月内悄然恶化。

你花了三周时间精心整理一套高质量的评估集。你编写了测试用例来覆盖产品经理担心的边缘情况，从内测用户中采样了真实查询，并得到了一个团队认可的准确率数字。六个月后，这个数字仍然出现在每周的仪表盘上。你刚刚发布了一次在评估中表现出色的模型更新，用户却在提交工单。

问题不在于模型退步了。问题在于你的评估集几个月前就已经不再代表现实——而没有人注意到。

这种失败模式有个名字：评估集衰退。它几乎发生在每一个生产AI团队身上，而且几乎从不会在用户行为中出现可见损失之前被发现。

周一你的提示词还运行正常。周三，用户开始抱怨响应感觉不对劲——答案变短了，下游的 JSON 解析时不时崩溃，原本准确率 94% 的分类器现在徘徊在 79% 左右。你没有部署任何新代码，配置文件里调用的模型名称还是那个。但某些东西变了。

这就是隐形模型漂移：LLM 供应商在不作任何公告的情况下推送静默的、未记录的行为变更。这是 AI 工程中讨论最少的运营风险之一，它会打击那些"做了所有正确事情"的团队——有评估集、有监控、有稳定的提示词工程。模型就在他们脚下悄悄地变了。