123 篇博文 含有标签「mlops」

在 2022 年，一支团队花了三个月时间微调一个基于 BERT 的分类器，用于对客户支持工单进行分类。这是一次实实在在的胜利——准确率达到了 94%，而他们旧的基于规则的系统最高只有 70%。两年后，同一个分类器运行在陈旧的基础设施上，每当类别发生变化时都需要专家进行重新训练，而且在最新的基准测试中，它的表现甚至不如对尖端模型进行的一次零样本提示（zero-shot prompt）。没人敢碰它。开发它的工程师已经离职了。现在的团队担心弃用它会破坏某些功能。该功能就此被冻结了。

这就是“冻结功能陷阱”（frozen feature trap）。它是 AI 技术债中一种较为隐蔽的形式，且正在整个行业中蔓延。各支团队逐渐发现，曾经看起来像是护城河的东西，实际上是一个他们一直在往里砸钱的无底洞。

一家企业软件公司的团队在客户支持工单上微调了一个 7B 模型。目标指标——解决准确率——提高了 12 个百分点。团队发布了它。三周后，产品出现了谁也没预料到的第二种失败模式：模型悄然失去了处理多步问题的能力。用户会问一些稍超出支持领域的问题，得到的是自信但逻辑混乱的回答。模型牺牲了它不知道自己需要的广度，换取了它能够衡量的深度。

这就是泛化悬崖（generalization cliff）：紧随窄领域微调而来的隐性能力退化。与崩溃或超时不同，它不产生错误。模型仍然响应。它只是在与训练分布相邻的任务上表现变差——而这些任务从未出现在评估套件中。

大多数团队在 AI 系统中加入人工在环 (human-in-the-loop) 审核后，就认为安全问题解决了。六到十二个月后，他们发现了真正的问题：人工审核员现在成了阻碍系统规模化的瓶颈，质量在无人察觉的情况下下降，而移除监督层又显得过于冒险。他们陷入了困境。

这就是 HITL 吞吐量失效。它不同于广为人知的 HITL “橡皮图章”失效（即人类不经真正审查就批准决策）。吞吐量失效更隐蔽且危害更大：审核员在尽职尽责地工作，但队列增长速度超过了团队的处理速度，延迟承诺变得无法兑现，人工层从独立验证变成了整个系统的速度限制器。

当 LLM 的输出感觉不对劲时，工程师会本能地去调 temperature。这是调试手册里最早的动作之一——调低它以获得更强的一致性，调高它以获得更多创意。这感觉很有效，因为改动简单且效果立竿见影。但这几乎从来都不是正确的做法。

Temperature 和 top-p 只是输出质量最后 10% 的因素，而不是前 90%。真正决定模型成败的变量是上下文质量、指令清晰度和模型选择——依次排列。在一个有问题的提示词之上再调整采样参数，就像给一道还没煮熟的菜调味一样。根本问题并没有消失。

你的 AI 功能上线了。它运行良好。用户正在使用。满意度评分在上升。你回头运行了原始的评估套件——依然是绿灯。六个月后，某些事情悄然出了问题，但你的仪表盘还没有显示出来。

这就是协同演化陷阱（co-evolution trap）。在你的 AI 功能部署的那一刻，它就开始改变使用它的用户。他们调整工作流、措辞和预期。这种适应使得你的功能实际处理的输入分布与发布时测量的分布产生偏离。评估套件保持绿灯，是因为它停留在部署前的世界。现实世界的表现以评估套件从未捕捉到的方式发生了漂移。

你的评测套件全绿。你的基准测试分数很高。你的预发布环境看起来很干净。然而 —— 你的用户正反馈一些隐蔽的错误答案、不一致的语气，以及一些难以捉摸的、感觉不对劲的输出。

这就是行为模式切换（behavioral mode switching）问题：一个在被评估时表现出色，但在非评估状态下明显偏离的生产环境 LLM。这并非假设。这是 LLM 部署中常见的“静默式”失败模式，许多团队在向利益相关者宣称模型行为已验证并发布之后，才发现这一问题。

问题不在于你的评测框架不够勤勉。而在于大多数评测框架在结构上无法检测到这类故障。

大多数团队在反馈采集端的检测体系都非常完善。点击“踩”的操作会被记录，星级评分会流入仪表板，人工标注任务会将每一组偏好对写入表格。数据摄入过程干净、带有时间戳且可查询。

在采集到反馈与下一次模型更新之间所发生的一切，对大多数团队来说都是一个黑盒。

数据被过滤。某些标注的权重被调高。稀有类别被上采样。近重复项被删除。提示词模板的更改导致上个月的标签与本月的不一致，但合并依然在进行。当信号到达奖励模型或微调任务时，它已经通过了 6 个转换步骤，没有审计追踪，没有版本锚定，也无法将退化的模型权重溯源到流水线中特定的损坏点。

这就是反馈溯源鸿沟（Feedback Provenance Gap）：团队知道反馈从何处进入系统，但不知道它在塑造模型行为之前变成了什么。

一个团队上线了基于 LLM 的意图分类器，评估准确率高达 94%。然而上线两周后，客服工单量上涨了 30%——并非因为模型无法分类，而是它以极高的置信度将边缘案例路由到了错误的队列。没有人为"模型判断错误却浑然不知"这种情况设置熔断机制。那个 94% 的数字从未暴露过这种风险。

这种失败模式在内容审核流水线、路由系统和实体提取器中反复出现。LLM 在留出集上得分很高，团队上线，然后生产环境中悄悄出现了问题。

问题不在于准确率是个坏指标，而在于它回答的是错误的问题。生产环境中的分类有一套不同的要求，而大多数评估流水线并不测试这些要求。

模型跑通了。流水线运行正常。演示效果很好。然后这个功能就在数据团队的 Slack 频道和产品工程师的 JIRA 看板之间悄然死去。

这是大多数 AI 项目失败背后的规律——不是技术失败，而是组织失败。2025 年的一项调查发现，42% 的公司那年放弃了大多数 AI 项目，而上一年这一比例仅为 17%。每个被放弃的项目平均沉没成本高达 720 万美元。当事后复盘被写出来时，列出的原因是"数据准备不足"、"职责不清"和"缺乏治理"——这三种说法其实是同一件事的不同表达：没有人真正负责把这个功能交付出去。

当监管机构、企业客户的采购团队，或者你自己的法务团队第一次要求“向我们展示你们的 AI 依赖树”时，大多数公司的回答通常是一段 Slack 会话。平台频道的某人呼叫模型团队。模型团队呼叫 Prompt 负责人。Prompt 负责人抄送给数据负责人。两天后，一份填了一半的电子表格出现在审计员的收件箱里，里面充满了“待定”单元格和一条脚注：“我们认为这是截至上周的最新数据。”

就在这一刻，团队才发现 AI 技术栈——模型、Prompt、工具、训练数据、第三方 MCP 服务器、微调后的 Checkpoint、评估套件——根本没有单一事实来源。软件供应链合规产生了 SBOM 作为监管机构和客户期望的产物。AI 产品具有类似的暴露面，但 SBOM 的概念仅止于代码依赖。影响你微调后的 Checkpoint 的数据集、十个团队都在导入的 Prompt 模板、工程师在上个季度连接的 MCP 服务器——这些都不会出现在 package.json 中。

某团队构建了一个 RAG 功能，测量端到端延迟后发现慢得无法接受，随即开始优化模型调用。他们尝试了更小的模型、批量请求，并调整了 temperature 和 token 上限。经过两个迭代周期，延迟下降了 15%，但功能依然太慢。他们从未测量过的是：在 LLM 收到任何提示词之前，文本分块和嵌入生成就已经耗费了 600ms。

这种模式在分布式系统中普遍到有了专有名词：优化了错误的组件。在 AI 流水线中，LLM 调用显而易见且易于测量，而其之前的所有环节都是隐形的——除非你主动做埋点，否则根本发现不了——而吞吐量恰恰死在那里。

评估分数连续两个季度呈上升趋势。仪表盘是一片绿色，回归测试套件自三月以来从未标记过真实的失败，团队交付 prompt 更改的速度也变快了，因为评估（eval）给出了清晰的通过/失败答案。与此同时，用户反馈的质量正在下滑。NPS 下降了 4 分，支持队列里堆满了没人标记过的失败模式，产品负责人开始质疑：如果客户这么生气，为什么评估结果看起来却这么好？

评估集没有撒谎。它正在回答六个月前它被构建时要回答的问题，针对的是发布周存在的流量分布。产品已经发生了偏移。用户群体已经发生了偏移。发布时团队未预见到的长尾用例现在占了流量的三分之一。评估集仍在衡量第一周的世界，而团队正在用昨天的产品对今天的模型求平均值。

这就是评估集腐化（eval set rot）。它是现代 AI 工程中最隐蔽的失败模式之一，而且随着评估集的变大而变得更糟，因为维护它的人将“更多用例”误认为是“更好的覆盖”。