90 篇博文 含有标签「mlops」

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

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

三个词。就这么多。

一个团队在现有 prompt 中添加了三个词，目的是改善"对话流畅性"——这个调整在 playground 里看起来无害。几个小时内，结构化输出错误率急剧攀升，一个创收工作流停止运作，工程师们争相还原 prompt 改动前的内容。没有版本历史，没有回滚机制，只有一条 Slack 消息，来自某个"大致记得"内容的人，以及一份与 Google 文档中过时副本的 diff。

这不是假设场景，而是几乎每个规模化交付 LLM 功能的组织都在重复经历的模式。Prompt 从应用代码中的字符串起步，经过非正式编辑演化，积累了无文档记录的微小调整，最终到达无人确信生产环境里运行着什么、也不知道为何如此表现的状态。

解决方案不是一个新工具，而是对团队一直以配置文件方式对待的东西施加工程纪律。

某金融科技公司首次部署AI交易审批代理时，产品团队在一周离线评估结果良好后便确信模型已准备好自主运行。他们将其推进至副驾驶模式——代理提出审批建议，人工可以覆盖——审批率看起来很不错。三周后，一个规律浮现：模型在系统性地低批准来自非英语用户的交易，这种偏差与姓名模式相关，而非风险信号。在上线前没有人检查过分段层级的性能。这不是欺诈检测失败，而是阶段门控失败。

大多数团队原则上理解AI功能应该渐进式上线。但他们缺少的是一个具体的工程框架来定义"渐进"的实际含义：哪些指标解锁每个阶段、在升级之前需要哪些监控，以及什么触发自动回滚。没有这些，自主性升级就变成了组织层面的乐观主义行为，而非可重复的工程决策。

你的 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 的输出则不同——用户集成的不是契约，而是行为分布。移除一个模型不仅是移除了一项功能，它还移除了一种特定的行为模式，用户可能在没有意识到的情况下花了几个月的时间去适应它。