123 篇博文 含有标签「mlops」

你的 AI 功能顺利发布。评估集准确率：91%。延迟：可接受。团队深感自豪。六个月后，用户开始抱怨该功能感觉“很笨”，支持工单不断增加，而你的综合指标悄然比发布当天下降了 8%。没有人更改过模型。底层数据流水线完好无损。发生了什么？

这就是逆行准确率问题（The retrograde accuracy problem）。随着产品的增长——新功能、新用户细分、新边缘情况、新流程——你的 AI 在生产环境中看到的输入分布会悄然偏离其训练时的分布。模型没有更新，数据流水线没有故障，而是产品本身的增长超出了模型的能力范围。

你的公司运行着一个共享的 LLM 服务集群。两个租户在使用它：一个面向客户的聊天机器人，其首令牌延迟 SLO 为 500 毫秒；以及一个批量文档丰富管道，通宵处理数千个长上下文提示。某天凌晨三点，聊天机器人团队把你叫醒，因为他们的 P95 TTFT 飙升到了 12 秒。根本原因：批处理任务比预期更早启动，用预填充工作占满了 GPU 内存，而聊天机器人的短请求在一列 8,000 个令牌的提示后面等待。你的 FIFO 调度器给了它们同等的优先级。在你手动终止批处理任务之前，聊天机器人的 SLO 已经被违反了 4,000 次。

这种故障模式很常见，理论上早已被理解，但在实践中却出人意料地普遍。大多数团队部署 vLLM 或 TGI 时使用默认的 FIFO 调度器，随着时间推移添加多个工作负载，只有在发生事故时才发现优先级反转问题。

大多数 AI 团队只会构建一次评测套件——在上线前的冲刺阶段，他们精心设计了边界场景用例，记录预期输出，经过评审后发布。六个月后，套件仍然通过。然而，模型在实际生产流量上已经悄然退步，而评测框架却是在那些流量出现之前编写的。它仍然在评判作者提出问题的答案，而非用户真正在问的问题。

这就是"博物馆问题"：一个在某个时间点策划的评测套件会不断积累文物。它证明系统能处理某人预期的场景，却无法覆盖真正让它崩溃的场景。

你的测试环境通过了所有检查。LLM 对每个测试提示词都做出了正确响应。延迟表现良好。质量评分看起来也不错。你发布了。然后，两天后，生产环境开始在你的评估集从未涵盖的一类查询中出现幻觉，你的成本飙升了 3 倍，因为缓存是冷的，而且你的供应商推送的模型更新静默地改变了行为，而你的旧测试套件无法检测到。测试环境显示一切正常，生产环境却给出了截然不同的结果。

这并不是一个可以通过编写更多测试用例来弥补的测试差距。预发布环境对 AI 系统具有结构性的误导，而对传统软件则不然。失败模式是系统性的，解决办法不是更好的测试环境，而是一种不同的架构。

你的 ML 团队进行了一项大有可为的实验。模型在评估集上比基准线高出了 8 个百分点。利益相关者们都很兴奋。然而，交付却花了四个月的时间——等到功能上线时，产品路线图已经发生了变化，提出需求的团队有了不同的优先级，而且由于部署目标在过程中发生了改变，一半的基础设施工作都得重做。听起来很耳熟吗？

这就是“时钟不匹配”问题：AI 团队和产品团队运行在完全不同的时间尺度上，而大多数组织将其视为协作失败，但实际上这是一个架构问题。你无法通过更好的站立会议节奏来修复结构性的不匹配。

大多数工程团队在推出第一个AI智能体六个月后，会发现自己已经拥有了15个。这并非出于规划——而是因为每个团队都解决了真实问题并付诸实施。客服团队构建了分类智能体，数据团队构建了报告生成智能体，平台工程团队构建了运行手册智能体，基础设施团队又构建了三个。这些智能体之间没有共享的认证、日志、工具或评估方法。Token费用从十几个供应商账户持续流失，而没有人能告诉你哪个智能体负责哪些开销。

这一时刻，正是能够规模化AI的工程组织与不能的工程组织之间的分水岭。答案不是放慢智能体的开发——而是在熵使整合变得不可能之前，先进行一次组合审计。

大多数工程团队对待伦理问题，就像他们过去对待安全问题一样：在功能发布之后、有人投诉之时才去处理。这种类比令人不安。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 年的两倍。这些失败大多发生在从概念验证过渡到生产环境的阶段——正是人手不足、脱节的中央团队暴露出裂缝的时候。