109 篇博文 含有标签「mlops」

大多数团队在 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 工程中最隐蔽的失败模式之一，而且随着评估集的变大而变得更糟，因为维护它的人将“更多用例”误认为是“更好的覆盖”。

一位平台工程师修改了公司“品牌风格”序言中的开场白——这是用于统一所有面向客户的助手语气的一行代码。这项改动通过 feature flag 发布。到了周二，搜索团队的相关性退化指标激增，支持机器人的评估通过率下降了四个百分点，入职引导 Agent 的重试率翻了一倍。这些团队中没有一个动过自己的代码。他们都没有收到任何预警。平台工程师对这一切一无所知，因为没人收到过类似的警报：“你的修改刚刚搞坏了三个下游功能。”

这就是定义 AI 团队成立第二年后的典型失效模式。第一年，每个团队都在各自的角落闭门造车。第二年，这些角落开始共享产物——这里一个提示词片段，那里一个种子评估集，或者一个被当作协议复用的工具 Schema。当这种共享变得隐性时，AI 功能之间的依赖图就变得不可见了。你现在拥有的是一个没人能叫出其边缘名称的分布式系统。

解决这一问题的方法论（discipline）并不是一个新平台，而是绘制这张图。

公平性审计曾是发布流水线中的一个绿色对勾。合规团队在 3 月签署通过了它。支持工单从 10 月开始涌现——来自一个模型从未被评估过的国家的的一组用户，得到的答案效用远低于其他人。模型本身没有任何改变。审计对模型的判断从未出错。它错在对世界的判断。

这是一个没人愿意大声说出来的失败模式：静态偏差评估只是已经发生漂移的数据流中公平性的一个快照。评估在运行时并没有撒谎。它告诉你的是一个关于不再存在的分布的真实情况。等到支持团队积攒了足够的工单并归纳出模式时，模型对该群体的处理不公已经持续了两个季度，而审计报告已经过时一年了。