129 篇博文 含有标签「mlops」

当你在多个区域运行无状态 HTTP API 时，路由问题基本上已经解决了。在前面放一个全球负载均衡器，按地理位置分配请求，最糟糕的情况也不过是缓存项稍微过时。任何副本都可以处理任何请求，并获得相同的结果。

LLM 推理打破了每一个假设。一旦你添加了提示词缓存（Prompt Caching）——你肯定会加，因为缓存命中和未命中的成本差异大约是 10 倍——你的服务就会以大多数基础设施团队预料不到的方式变得有状态，直到他们在第二个区域看到延迟数据退化。

你的 AI 功能准时上线了。用户正在使用它。一切看起来都很正常 —— 直到一季度后，一张支持工单揭露了系统已经“一本正经地胡说八道”了好几周，你的评估套件（evaluation suite）什么也没抓到，而向量索引正悄无声息地返回过期结果。没有任何环节崩溃。系统全程返回 200 OK。

这就是 AI 技术债务的样子。它不像失败的单元测试或堆栈溢出，而是以一种温和且概率性的方式退化。你不会遇到崩溃 —— 你面对的是微妙的质量侵蚀。主要由三种不同的负债驱动：提示词债务（prompt debt）、评估债务（eval debt）和嵌入债务（embedding debt）。每一项都独立积累，每一项又都在加剧其他的债务。而大多数工程团队正同时背负着这三者。

上个季度，你的团队上线了一个基于 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%。代码写得前所未有地快，只是没有上线。