43 篇博文 含有标签「mlops」

上个季度，你的团队上线了一个基于 RAG 的搜索功能。它需要向量数据库、嵌入模型、标注流水线、分块服务和评估框架。每个组件单独来看都合情合理。但六个月后，你发现这五个组件中有三个没有明确的负责人，有两个运行在工程师的个人云账户上，还有一个被供应商悄悄下线了，无人知晓。凌晨三点的告警来自一个没人记得是何时添加的组件。

这就是 AI 依赖足迹问题：每个 AI 功能所需基础设施的累积叠加，加上组织层面在上线前几乎不规划所有权的现实，共同造就了这一困局。

大多数运行持续微调的团队都以同样的方式发现了污染问题：每周评估指标持续提升，团队欢欣鼓舞，然后某个用户反馈模型"变差了"。一旦深入排查，你才意识到你的评估基准已经悄悄地泄漏到训练数据中好几个月了。每一个看起来像能力提升的指标，其实不过是记忆。

数字比直觉更糟糕。LLaMA 2 的 MMLU 样本中有超过 16% 被污染——其中 11% 属于严重污染（超过 80% 的词元重叠）。GPT-2 在被污染的基准上比干净基准的得分高出 15 个百分点。这不是边缘案例。在持续微调循环中，污染是默认结果，除非你从架构层面明确加以防范。

微调模型上线六个月后，监管机构问道："哪些训练样本来自已撤回同意的用户？"你翻开一张电子表格，搜遍 Slack 归档，最终靠标注批次邮件和一份自第一个冲刺后就未更新的 README 来重建历史。这是常态，而非例外。对 44 个主要指令微调数据集的审计发现，超过 70% 的许可证标记为"未指定"，许可证类别实际应用的错误率超过 50%。溯源问题是结构性的，而且总在你最承受不起的时候爆发。

本文讲的是在需要之前就建立微调数据溯源注册表——包括模式设计、驱动需求的审计场景，以及使其可操作而不变成额外负担的生产模式。

大多数团队选择 LLM 的方式就像选择数据库引擎一样：在架构评审时选一次，然后再也不改。你选了 GPT-4o 或 Claude 3.5 Sonnet，把它写进配置文件，然后上线。这个选择感觉无法逆转，因为更改它需要重新部署、跨服务协调，以及针对本周 eval 的回归测试。

这种思维方式是错误的。你的流量并不是同质的。"总结这篇文档"和"调试这个神秘堆栈跟踪"两个请求同时打到同一个接口，对能力的需求天差地别——但从静态模型选择的基础设施视角来看，两者毫无区别。你要么对其中一个过度供给，要么对另一个供给不足，而且每一个请求都是如此。

模型路由将 LLM 的选择视为运行时分发决策。每个进入的查询都会根据能预测该请求最合适模型的信号进行评估，并据此进行分发。路由层不存在于配置文件中——它运行在你的请求路径上。

大多数团队对待标注流水线的方式，就像对待他们 2019 年的 CI 脚本一样：它能运行，大部分时候如此，而且没人想去碰它。一个带有颜色标记行的共享电子表格。一个将任务路由到 Slack 频道的 Google 表单。三名承包商异步工作，在一个讨论串中对比笔记。

接着，一个模型发布后质量下降，评估（eval）以一种令人困惑的方向退化，事后分析（post-mortem）最终揭示了显而易见的事实：标签错了，而且没人构建任何东西来检测它。

标注不是一个数据问题。它是一个软件工程问题。那些以此方式对待它的团队——使用队列、模式（schemas）、监控和结构化的分歧处理——构建的 AI 产品会随着时间的推移而改进。而那些不这么做的团队则陷入了无法解释的重新标注循环。

你的 AI 产品三个月前上线了。你有显示延迟、错误率和 token 成本的仪表盘。你已经看到用户与系统交互了数千次。然而你的模型和上线那天相比，好的地方一样好，差的地方一样差。

这不是数据问题。你拥有的数据已经多得不知该拿来做什么。这是架构问题。那些告诉你模型哪里失败的信号，就躺在应用日志、用户会话和下游结果数据里。它们与任何能改变模型行为的东西断开了连接。

大多数团队把 LLM 当作静态制品，然后在外围包裹监控和评估。最优秀的团队则把生产环境视为一条永不停歇的训练流水线。

对语言模型进行微调能给你带来竞争优势——直到提供商在你的适配器之下更新了基础模型。此时，两种情况之一会发生：你的服务因形状不匹配错误而崩溃，或者——更危险的是——它开始静默输出降级结果，而你的监控系统毫无异常。大多数团队发现第二种情况，往往是在用户投诉"AI 变蠢了"之后。

这就是适配器兼容性悬崖。你在模型版本 N 上训练了一个 LoRA 适配器，提供商发布了版本 N+1，你的适配器现在运行在一个从未为之设计的基础上，且没有任何迁移路径。

你上周二发布了一个智能体。代码库没有任何改动。到了周四，它开始拒绝之前已经可靠处理了好几周的工具调用。你的 git 日志是干净的，测试全部通过，CI 流水线一片绿色。但智能体坏了——而且你没有可以回滚的版本，因为真正发生变化的东西根本不在你的代码仓库中。

这就是智能体版本控制的核心悖论：你追踪的制品（代码、配置、提示词）是必要的，但不足以定义你的智能体实际做了什么。行为是从代码、模型权重、工具 API 和运行时上下文的交叉中涌现出来的——其中任何一个都可以在版本控制系统中不留痕迹地发生变化。

你的 AI 功能上线时赢得了满堂喝彩。三个月后，用户正在悄悄绕过它。你的仪表板依然显示绿色——延迟正常、错误率平稳、可用性完美。但满意度评分在下滑，工单里开始出现"AI 行为怪怪的"，曾经能处理 70% 咨询的功能现在勉强应付 50%。

这就是 AI 功能衰退：AI 驱动的功能逐渐退化，原因不在于模型变更或代码缺陷，而在于底层世界在它脚下悄然变化。不同于传统软件会以堆栈追踪的方式失败，AI 功能是无声退化的。系统在运行，模型在响应，输出在交付——只是它不再是用户所需要的了。

大多数 AI 功能都死在"在 notebook 中可行"和"在生产环境可行"之间的鸿沟里。不是因为模型不好，而是因为构建模型的团队和拥有产品的团队从未坐在同一间会议室里。AI 团队拓扑问题——AI 工程师在组织架构中的位置——悄然成为你的 AI 投资能否上线的最大预测因素。

数据印证了这一点。只有大约一半的 ML 项目能从原型走到生产环境，在成熟度较低的组织中，失败率高达 90%。与此同时，CircleCI 的 2026 年软件交付状态报告发现，尽管 AI 辅助代码生成使功能分支吞吐量提升了 59%，中位团队的生产分支产出实际上下降了 7%。代码写得前所未有地快，只是没有上线。

一个在单张 RTX 4090 上运行的经过微调的 7B 参数模型，可以在特定领域任务上超越 GPT-4，同时在初始硬件投资之后每个 token 的成本为零。这不是理论上的说法——Diabetica-7B，一个专注于糖尿病的模型，在临床查询上达到了 87.2% 的准确率，在同一基准测试中击败了 GPT-4 和 Claude 3.5。但前提是什么？你需要准确理解边缘推理何时有意义，何时只是昂贵的干扰。

大多数团队默认使用云端 API，因为它们简单。你发送一个 HTTP 请求，就能得到 token 返回。但这种简单性有一个成本，它的扩展方式是许多工程师在为时已晚之前没有预料到的——而且成本并不总是以金钱来衡量的。

每隔几个月，团队里就会有人转发一篇关于 Llama 或 Qwen 在某个基准测试上"媲美 GPT-4"的博客文章，然后不可避免地提出这个问题："既然我们可以自己运行，为什么还要为 API 调用付费？"在草稿纸上算一算，这个数字看起来很有吸引力。但现实是，大多数尝试自托管的团队最终花费反而更多——不是因为模型不好，而是他们低估了模型之外的所有成本。

话虽如此，在某些特定场景下，自托管开源权重模型确实是明确正确的选择。关键在于认清你实际所处的场景，而不是你希望自己所处的场景。