90 篇博文 含有标签「mlops」

你的 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 故障时希望就存在的手册。

几乎在每一个 AI 产品团队中都会出现这样一种模式：团队发布了初始模型，用户开始与之交互，接着有人在回复底部添加了一个“点赞/点踩”小部件。他们称之为反馈闭环。三个月后，模型并没有任何改进。团队纳闷为什么飞轮没有转起来。

问题不在于执行，而在于显式评分并不是反馈闭环——它们只是调查问卷。只有不到 1% 的生产环境交互会产生显式用户反馈。而那 99% 从未点击任何按钮的用户正在向你发送远为丰富的信号；你只是没有收集它们。构建真正的反馈闭环意味着通过系统埋点来捕获行为轨迹，在大规模场景下高效地标注它们，并将其导回训练和评估流程中，从而实现随时间推移的复利增长。

你的模型精度在某个夜晚突然下降了8%。模型代码没有任何改动，没有发生任何部署，评估套件是绿色的。于是你花了一周时间调整超参数、修改提示词、对比检查点损失——最终有人注意到，三天前特征流水线里落地了一次Schema迁移。一个字段从NULL改成了空字符串。就这样，就是这个变化导致了回退。

这是生产ML系统中最常见的故障模式，与模型质量几乎毫无关系。问题的根源在于大多数团队被坑过之后才会补上的一个结构性缺口：数据版本和模型版本紧密耦合，但它们由不同的工具追踪、归属于不同的团队。

当 Anthropic 去年废弃一个 Claude 模型时，一家公司察觉到了——但这仅仅是因为下游解析器在生产环境中开始报错。罪魁祸首？新模型偶尔会将其 JSON 响应包裹在 Markdown 代码块中。旧模型从不这样做。没人记录过这一假设，也没人对此进行过测试。修复只花了一个下午；诊断却花了三天。

这种模式——无声的行为依赖在生产环境中“震耳欲聋”地崩盘——是模型迁移中典型的失败模式。你更新了模型 ID，跑了一个简单的冒烟测试（sanity check），然后发布。六周后，一些细微的问题出现了。你的 JSON 解析失败率提高了 0.6%。边缘情况下的拒绝率翻了一番。你的结构化提取漏掉了一个以前能可靠填充的字段。差异不在代码中——而在模型的行为中，而你从未为此编写过契约（contract）。

随着主要供应商现在的废弃周期缩短至 60–180 天，且模型发布的速度在加快，这已不再是一个理论上的担忧。这是一个周期性的运营挑战。以下是如何提前应对的方法。