129 篇博文 含有标签「mlops」

大多数构建 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 工程中讨论最少的运营风险之一，它会打击那些"做了所有正确事情"的团队——有评估集、有监控、有稳定的提示词工程。模型就在他们脚下悄悄地变了。

关于生产环境中的 LLM，大多数讨论都围绕着聊天界面、Copilot 和自主代理。但如果你审计企业 LLM Token 的实际消耗去向，你会发现一个完全不同的景象：绝大多数的使用都发生在批处理数据管道（batch data pipelines）中 —— 从文档中提取字段、对支持工单进行分类、规范化混乱的供应商记录、为原始事件添加语义标签。没有人为这个层级编写会议演讲，也没有人认真地对其进行基准测试。而这种沉默正让团队付出真金白银和准确性的代价。

这是从业者最先构建、最后辩护、且监控最少的 ETL 层级。对于大多数组织来说，这也是 LLM 支出杠杆率最高的一层，同时也是产生隐形失败潜力最高的一层。

这个方案听起来简洁明了：为每种专项技能分别微调轻量级LoRA适配器——一个处理专业语气，一个处理JSON格式化，一个处理医学术语，一个负责安全护栏——然后在推理时将它们组合起来。团队上线了这套设计，开发阶段运行良好，但到了生产环境却频频崩溃：两个适配器开始争夺同一权重区域，输出质量骤降，最终与未经训练的基础模型毫无二致。不是略有下降，而是彻底退化。

本文探讨适配器组合在实际应用中的表现、朴素合并为何屡屡失败，以及哪些策略在生产规模下真正有效。

你的 AI 功能发布时准确率为 92%。团队举杯欢庆。三个月后，进展陷入停滞 —— 尽管投入了更多数据、更多算力和两次模型升级，错误率却不再下降。听起来很熟悉吗？

这就是 “90% 可靠性之墙”，这并非巧合。它源于三种力量的交汇：边际准确率提升的指数级成本、可消除误差与结构上不可避免误差之间的区别，以及生产环境中故障的复合放大效应 —— 而这些是基准测试永远无法捕捉到的。不了解自己正在与哪种力量对抗的团队，将会浪费数个季度的时间去试图解决那些根本无法解决的问题。

大多数AI推理决策都遵循同一逻辑：模型部署在云端，因为只有在那里才能运行，仅此而已。但这一算法正在迅速改变。旗舰智能手机现在搭载了能够以交互速度运行70亿参数模型的神经引擎。骁龙8 Elite可以以约每秒10个token的速度从30亿参数模型生成内容——足够流畅的对话体验——而高通Hexagon NPU在预填充阶段可达到每秒690个token。问题不再是"我们能否在设备上运行？"，而是"我们应该这样做吗，什么时候该这样做？"

答案很少是显而易见的。将推理迁移到边缘端会引入真实的权衡：量化带来的质量损耗、设备机群更新的维护负担，以及跨设备SKU的硬件碎片化。但留在云端也有其代价：数百毫秒的往返延迟、随规模扩展而累积的云GPU账单，以及没有任何SLA能完全解决的数据主权问题。本文为应对这些权衡提供了一个实用框架。

当加拿大航空（Air Canada）的客服聊天机器人向客户承诺为近期遭遇丧亲之痛的旅客提供折扣票价时，它所描述的政策其实并不存在。法院后来依然裁定加拿大航空必须兑现这一“幻觉”产生的退款。当一家雪佛兰经销店的聊天机器人经协商以 1 美元的价格卖出一辆 2024 款 Tahoe 时，没有任何机制能阻止它。在这两个案例中，最直接的问题是模型质量。而真正的问题——在运营层面上至关重要的问题——则更简单：到底应该由谁来发现这些问题？

在大多数组织中，答案是：没有具体的人。AI 质量处于机器学习工程（ML engineering）、产品管理、数据团队和运营的交汇点。每个职能部门都只看到局部，没有人声称拥有完整的责任权。其结果是一个“真空地带”，本应被发现的问题被漏掉了；而当某些环节出现故障时，事后分析报告（postmortem）里列出了一堆团队，而每个团队都以为别人会负责。

凌晨两点，报警器响了。仪表盘显示没有 5xx 错误、没有超时激增、没有异常延迟。然而客服已经被淹没："AI 给出了奇怪的回答。"你打开运行手册——立刻意识到它是为完全不同的系统写的。

这是 2026 年 AI 故障响应的标志性失效模式。系统在技术上完全健康。Bug 是行为上的。传统运行手册假设存在离散的失败信号：堆栈跟踪、错误码、不响应的服务。基于 LLM 的系统彻底打破了这一假设。输出语法正确、延迟正常、内容却完全错误。没有任何告警能捕捉到它。唯一的信号是某些东西"感觉不对"。

这篇文章是我第一次不得不响应生产 AI 故障时希望就存在的手册。