129 篇博文 含有标签「mlops」

大多数工程团队对待伦理问题，就像他们过去对待安全问题一样：在功能发布之后、有人投诉之时才去处理。这种类比令人不安。2004年，SQL注入还是个"以后再修"的问题。如今，每个正规团队的CI中都有自动注入检测。AI伦理审查正处于同样的拐点——不提前建立门控机制的团队，终将以惨痛教训明白它存在的意义。

问题不在于初衷，而在于结构。安全审查有20年的标准化先发优势：OWASP清单、CVE评分、渗透测试、上线前的强制审批。伦理审查则没有这些规范。大多数团队既没有定义明确的触发条件，也没有清单、退出标准，更没有指定的责任人。结果是：一个医疗算法将黑人患者被识别为需要护理的比例降低了超过50%——不是因为工程师心怀恶意，而是因为没有人在上线前运行分组准确率分析。一个招聘模型系统性地降低了含有"女性"一词的简历排名——用历史数据训练，未经公平性审查就发布，几个月后才在生产中被发现。这些不是边缘案例，而是在伦理作为上线后没有牙齿的复选框时必然发生的结果。

你的推荐模型在三个月前上线了。点击率增长了 18%。观看时长在不断攀升。仪表盘上一片飘绿。领导层很满意。

而你的模型正在悄悄地破坏它将用于训练下一个版本的数据。

这就是训练数据自中毒（training data self-poisoning）：一种反馈循环，其中已部署的 AI 功能会改变用户行为，其方式破坏了模型最初训练时学习的交互数据。最糟糕的是，你的标准参与度指标会告诉你一切正常 —— 直到它们失效的那一刻。

每个 AI 融资演讲稿中都会包含一张关于数据飞轮的幻灯片。故事听起来很诱人：用户与你的 AI 功能交互，交互产生数据，数据训练出更好的模型，更好的模型吸引更多用户，循环往复。只要规模足够大，你就能拥有一道难以逾越的竞争护城河。

问题在于，大多数发布 AI 功能的团队并没有飞轮。他们只有一个日志文件。一个非常巨大、存储成本极高，但从未改进过模型，也永远不会改进模型的日志文件——因为实现真正飞轮的三个前提条件缺失了，而且没有人问过这些条件是否存在。

你的图像生成功能刚刚走红。每天有 100,000 个请求涌入。API 提供商的速率限制在技术上可以应对。但 p95 延迟爬升到了 12 秒。你的 NSFW 分类器正在误报合法的医学插图。合规性审计显示，加州的《人工智能透明度法案》（AI Transparency Act）要求自 2024 年 9 月起添加水印。支持团队收到了 50 个来自内容被静默拦截的用户的待处理工单。当你意识到需要一套真正的生产级技术栈时，你已经在危机模式中虚耗了两周。

这就是“直接调用 API”失效的时刻——不是因为 API 本身不好，而是因为演示的成功暴露了你对推理延迟、内容策略、审核公平性和监管合规性所做出的每一项假设。教程中从未展示过的工程工作就在这里。

一个中型公司的团队在发布文档摘要功能三个月后，对提示词进行了优化。新提示词在他们手动测试的 5 个示例上表现更好。他们在周五下午部署了它。周一上午，Slack 里堆满了用户反馈：摘要现在会截断一半文档，却将截断后的内容呈现为完整版本。功能看起来没问题，变更通过了代码审查，没有人发现，因为根本没有评估机制——没有黄金测试集，没有回归基线，没有自动检查。棘轮已经悄悄转动了数月。

这就是评估债务最典型的表现形式。团队跳过评估并非因为粗心大意，而是因为为 AI 功能编写评估比听起来难得多，功能发布快且看起来运行良好，没有人想拖慢一个高速运转的团队。现在，他们正在偿还复利。

中央 AI 团队本应是答案。把最优秀的 ML 工程师集中到一个团队，统一工具链，建立治理机制，让产品团队无需深入理解 AI 就能直接消费 AI 能力。这是一个听起来很美的架构——在组织架构图上清晰可见，在董事会演示中无懈可击。然而在实践中，它可靠地生产出一种失败模式，看起来恰恰就像它本要消除的碎片化。

中央 AI 团队变成了瓶颈。产品团队在后面排队等待。它交付的 AI 对每个需要特定功能的领域来说都显得过于通用。构建平台的 ML 工程师不了解产品指标。需要帮助的产品工程师只能靠提工单才能调试 AI 行为。一个 3 个月的试点成功了；一个 9 个月的安全审查把它埋葬了。

2025 年，企业放弃 AI 项目的比率已超过 2024 年的两倍。这些失败大多发生在从概念验证过渡到生产环境的阶段——正是人手不足、脱节的中央团队暴露出裂缝的时候。

在 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 部署中常见的“静默式”失败模式，许多团队在向利益相关者宣称模型行为已验证并发布之后，才发现这一问题。

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