129 篇博文 含有标签「mlops」

一个欺诈检测模型的准确率在三周内悄无声息地下降了一半。延迟正常，错误率为零，所有基础设施仪表盘都显示绿色。工程师们在第一周审计数据管道，第二周比较模型权重，第三周重新审视工单，直到有人发现欺诈者只是改变了他们的语言模式。修复工作——用最近的样本重新训练——只花了两天。而误诊却花了三周。

这种模式在生产环境中的 AI 团队里不断重复：性能下降触发了笼统的“模型问题”警报，团队开始基于直觉而不是根本原因来调整参数。原因并不是缺乏监控纪律，而是大多数可观测性技术栈将三个结构上截然不同的问题混为一谈。模型漂移（Model drift）、数据漂移（Data drift）和提示词漂移（Prompt drift）具有不同的检测特征、不同的警报拓扑结构和不同的修复路径。将它们混淆，就会在错误的修复方案上浪费数周时间。

当一次人格更新让一个流行的 AI 助手变得明显更加讨好和客气时，工程团队迅速发现了问题，并在几天内发布了回滚。代码更改很干净。模型切换也很直接。然而，用户还是被激怒了——不是因为回滚出错了，而是因为他们中的一些人已经围绕那个“奉承版”建立了工作流。他们的提示策略、审阅环节、对模型置信度信号的解释——所有这一切都针对一个他们再也无法访问的 AI 进行了调整。

回滚代码只花了几个小时。回滚用户却是不可能的。

这种不对称性是 AI 功能管理的中心挑战，大多数工程团队在吃亏之前都会低估它。传统的回滚思维将“撤销”视为一种纯粹的技术操作。对于 AI 功能来说，这只是故事的一半。

上季度，某推荐引擎推送了冒犯性内容，随后召开的事故复盘会议以一种我们再熟悉不过的方式收场：两小时的会议里，ML 工程师把矛头指向检索语料库，数据工程师把矛头指向提示词，产品工程师把矛头指向监控，基础设施团队把矛头指向没人记得何时升级的模型版本。最终产出了三条行动项，却没有一条落实到具体负责人。事故就此关闭。六周后，同样的故障模式再次上线。

这不是某一个团队的故事，而是大多数组织处理 AI 事故时的默认结局。AI 功能在生产环境中造成的后果，由足够多的参与方共同承担，导致标准的事故复盘根本无法锁定因果关系。那套在排查数据库超时时行之有效的"5 Why"分析法，面对"模型给出了错误答案"时便彻底失灵——因为下一步该追问什么，从来都不显而易见。

你花了数周时间构建检索流水线。分块策略已调整，相似度阈值已校准，用户反馈看起来很积极。然后，在某个周一的早晨，在你没有任何部署的情况下，检索质量开始下降。以前能搜出正确文档的查询，现在返回的却是关联度极低的噪音。没有错误日志。没有异常。流水线运行顺畅。

发生变化的是你的嵌入（Embedding）提供商更新了模型。你的整个向量索引——那些费尽心力嵌入的数百万个文档——现在填充的是来自一套坐标系统的向量，而这套系统与你的查询编码器生成的向量已不再匹配。结果不是系统崩溃，而是不可见的垃圾数据。

一个在内部基准测试中得分 94%、在演示中令利益相关者印象深刻、通过所有离线评估的模型，进入生产后仍然可能跌落至 7% 的真实客户数据有效准确率。这不是假设——这是多个企业 AI 部署中有据可查的结果，也是一种更广泛模式的症状：从"试点成功"到"生产价值"之间的鸿沟，正是大多数企业 AI 悄然消亡的地方。

在各行各业，大约 85–88% 的企业 AI 试点项目从未到达生产。每启动 33 个 PoC，只有四个能够上线。尽管模型能力大幅提升，这一比例三年来几乎没有改变。失败的根源几乎从不在于模型是否足够好——几乎总是在于成功演示与真实用户真正依赖该系统完成实际工作之间所发生的事情。

你的 RAG 评估套件在忠实度（faithfulness）方面达到了 0.89。你向知识库添加了 5,000 个新的支持文档。你重新运行相同的评估，忠实度降到了 0.79。你的团队提交了一个模型退化（model regression）工单。

其实没有任何退化。你的评估只是变成了一个谎言。

这就是 RAG 评估失效悖论：在你更新知识库的那一刻，你针对旧索引构建的评估集就会悄无声息地停止衡量其设计的初衷。大多数团队在几个月后才会发现这一点——在为幻影般的退化消耗了大量的工程周期之后——如果他们真的能发现的话。

你的 AI 功能顺利发布。评估集准确率：91%。延迟：可接受。团队深感自豪。六个月后，用户开始抱怨该功能感觉“很笨”，支持工单不断增加，而你的综合指标悄然比发布当天下降了 8%。没有人更改过模型。底层数据流水线完好无损。发生了什么？

这就是逆行准确率问题（The retrograde accuracy problem）。随着产品的增长——新功能、新用户细分、新边缘情况、新流程——你的 AI 在生产环境中看到的输入分布会悄然偏离其训练时的分布。模型没有更新，数据流水线没有故障，而是产品本身的增长超出了模型的能力范围。

你的公司运行着一个共享的 LLM 服务集群。两个租户在使用它：一个面向客户的聊天机器人，其首令牌延迟 SLO 为 500 毫秒；以及一个批量文档丰富管道，通宵处理数千个长上下文提示。某天凌晨三点，聊天机器人团队把你叫醒，因为他们的 P95 TTFT 飙升到了 12 秒。根本原因：批处理任务比预期更早启动，用预填充工作占满了 GPU 内存，而聊天机器人的短请求在一列 8,000 个令牌的提示后面等待。你的 FIFO 调度器给了它们同等的优先级。在你手动终止批处理任务之前，聊天机器人的 SLO 已经被违反了 4,000 次。

这种故障模式很常见，理论上早已被理解，但在实践中却出人意料地普遍。大多数团队部署 vLLM 或 TGI 时使用默认的 FIFO 调度器，随着时间推移添加多个工作负载，只有在发生事故时才发现优先级反转问题。

大多数 AI 团队只会构建一次评测套件——在上线前的冲刺阶段，他们精心设计了边界场景用例，记录预期输出，经过评审后发布。六个月后，套件仍然通过。然而，模型在实际生产流量上已经悄然退步，而评测框架却是在那些流量出现之前编写的。它仍然在评判作者提出问题的答案，而非用户真正在问的问题。

这就是"博物馆问题"：一个在某个时间点策划的评测套件会不断积累文物。它证明系统能处理某人预期的场景，却无法覆盖真正让它崩溃的场景。

你的测试环境通过了所有检查。LLM 对每个测试提示词都做出了正确响应。延迟表现良好。质量评分看起来也不错。你发布了。然后，两天后，生产环境开始在你的评估集从未涵盖的一类查询中出现幻觉，你的成本飙升了 3 倍，因为缓存是冷的，而且你的供应商推送的模型更新静默地改变了行为，而你的旧测试套件无法检测到。测试环境显示一切正常，生产环境却给出了截然不同的结果。

这并不是一个可以通过编写更多测试用例来弥补的测试差距。预发布环境对 AI 系统具有结构性的误导，而对传统软件则不然。失败模式是系统性的，解决办法不是更好的测试环境，而是一种不同的架构。

你的 ML 团队进行了一项大有可为的实验。模型在评估集上比基准线高出了 8 个百分点。利益相关者们都很兴奋。然而，交付却花了四个月的时间——等到功能上线时，产品路线图已经发生了变化，提出需求的团队有了不同的优先级，而且由于部署目标在过程中发生了改变，一半的基础设施工作都得重做。听起来很耳熟吗？

这就是“时钟不匹配”问题：AI 团队和产品团队运行在完全不同的时间尺度上，而大多数组织将其视为协作失败，但实际上这是一个架构问题。你无法通过更好的站立会议节奏来修复结构性的不匹配。

大多数工程团队在推出第一个AI智能体六个月后，会发现自己已经拥有了15个。这并非出于规划——而是因为每个团队都解决了真实问题并付诸实施。客服团队构建了分类智能体，数据团队构建了报告生成智能体，平台工程团队构建了运行手册智能体，基础设施团队又构建了三个。这些智能体之间没有共享的认证、日志、工具或评估方法。Token费用从十几个供应商账户持续流失，而没有人能告诉你哪个智能体负责哪些开销。

这一时刻，正是能够规模化AI的工程组织与不能的工程组织之间的分水岭。答案不是放慢智能体的开发——而是在熵使整合变得不可能之前，先进行一次组合审计。