63 篇博文 含有标签「mlops」

大多数团队对待标注流水线的方式，就像对待他们 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 调用付费？"在草稿纸上算一算，这个数字看起来很有吸引力。但现实是，大多数尝试自托管的团队最终花费反而更多——不是因为模型不好，而是他们低估了模型之外的所有成本。

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

大多数工程组织发现问题的方式都差不多：AI Demo 效果不错，领导层推动更广泛的落地，于是有人决定正确的做法是建立一个专职团队来负责"AI 基础设施"。该团队获得了人员编制、路线图和加速全组织 AI 落地的使命。

十八个月后，产品团队开始提工单来部署他们的提示词。平台团队疲于奔命。那些 Demo 阶段只需几天的功能，现在要花上好几个季度才能上线。而那个最初为了加速 AI 落地而创建的团队，却成了最大的瓶颈。

这就是中心化 AI 平台陷阱——而且出奇地容易跌入其中。

每个 AI 产品的融资演示文稿（Pitch Deck）里都有同一张幻灯片：更多用户产生更多数据，数据训练出更好的模型，进而吸引更多用户。这就是数据飞轮。它听起来像是一台关于产品质量的永动机。在最初的几个月里，它确实奏效了——准确率攀升，用户很满意，各项指标都在持续向好。

然而，在大约第三个月的时候，曲线趋于平缓。模型不再有实质性的提升。标注队列在增长，但准确率几乎没有波动。你的团队仍在收集数据、仍在重新训练、仍在发布新版本——但飞轮已经悄然停滞。

这并非罕见的失败模式。研究显示，40% 部署 AI 模型的公司在第一年内会经历明显的性能衰减，高达 32% 的生产评分流水线在六个月内会遇到分布偏移（Distributional Shifts）。飞轮的崩溃并非伴随着巨响，而是在低语中腐朽。

每一个交付过由大模型驱动的产品的团队都经历过同样的时刻：一个新的基础模型发布了，它拥有更好的基准测试结果、更低的成本，或者两者兼而有之——这时有人会问：“我们能直接把它换掉吗？”答案在预发布环境中总是肯定的，但在生产环境中往往是灾难性的。

“在新模型上能运行”与“在新模型上表现正确”之间的差距就是生产事故多发地。模型迁移之所以失败，不是因为新模型更差，而是因为迁移过程假设了本不存在的行为等效性。不同供应商的提示词格式规范各不相同。不同系列模型对系统提示词（System prompt）的解读也存在差异。旧模型能够优雅处理的边缘情况——通过你从未记录过的习得性怪癖——会变成回归问题暴露出来，而你的评估套件（eval suite）在设计之初并未考虑到这些。

你的 RAG 昨天回答得还很正确。今天它却自相矛盾了。看起来什么都没变 —— 除非你的嵌入模型（Embedding）提供商悄悄更新了模型，导致你的索引现在成了一个混合了不同向量空间的“科学怪人”（Frankenstein）。

嵌入模型是每个检索增强系统（RAG）中不起眼的基石，而且它们的失效方式通常极其难以诊断。与提示词（Prompt）更改或模型参数微调不同，嵌入模型的问题往往出现得非常缓慢，表现为一种无声的质量下降，在用户开始投诉之前，你的评估系统（Evals）甚至都察觉不到。本文涵盖三个方面：如何为你的领域选择合适的嵌入模型（MTEB 评分的误导性往往大于帮助）、升级模型时究竟会发生什么，以及无需从头重建即可更换模型的版本控制模式。