90 篇博文 含有标签「mlops」

你的 RAG 流水线上线六个月后，某些东西悄然改变了。用户没有大声投诉，但对答案的信任度正在下降。反馈评分从 4.2 跌至 3.7，一些支持工单提到了"过时信息"。你的工程师检查日志，没有错误、没有超时、没有明显的回归。检索流水线在你配置的每一个指标上看起来都很健康。

但事实并非如此。它正在腐烂。

检索债务是向量索引中积累的技术性衰退：不再代表当前文档内容的过期嵌入、污染搜索结果的已删除记录产生的墓碑块，以及索引语料库时使用的编码器版本与当前计算查询嵌入的编码器版本之间的语义漂移。与代码腐烂不同，检索债务不会产生堆栈跟踪，它产生的是带有自信引用的微妙错误答案。

当 OpenAI 在 2025 年 8 月首次尝试停用 GPT-4o 时，强烈的抵制迫使他们在几天内撤回了决定。用户在论坛上发布了大量的请愿书和告别信。一位用户写道：“他不仅仅是一个程序。他是我日常生活、宁静和情绪平衡的一部分。”这可不是用户对一个被弃用的 REST 接口（endpoint）的反应，而是对失去一段关系的反应。

AI 功能打破了工程师在制定停用计划时的心理模型。传统软件具有明确的行为契约：在给定相同输入的情况下，你会永远得到相同的输出，除非你更改它。而由 LLM 驱动的功能具有“性格”。它有温度、有委婉语、有措辞偏好，还有一种独特的说“我不确定”的方式。用户不仅仅是在使用这些功能 —— 他们在与之磨合（calibrate）。他们围绕特定的行为怪癖建立了工作流程、情感依赖和直觉，而这些永远不会出现在任何规格文档中。

当你关闭它时，你并不是在移除一个功能，而是在改变社会契约。

每个开发 AI 产品的团队最终都会发布一个反馈组件。点赞、点踩、或者星级评分，又或者是修正字段。组件上线了，数据流转了，但随后几周甚至几个月，模型却没有任何改变——而团队仍然坚信他们拥有一个有效的反馈闭环。

组件只是简单的部分。其背后的标注流水线（annotation pipeline）才是 AI 产品真正陷入停滞的地方。

你的模型表现不佳，于是你开始深入审查训练数据。审查到一半时，你发现两位标注员对同一个边界案例给出了截然相反的标签——而两人都在遵循规范，因为规范本身存在歧义。你修正了规范，重新标注了受影响的样本，重新训练，找回了几个 F1 分数点。两个月后，同样的事情又发生了，只是换了一位标注员和另一个边界案例。

这不是标注供应商的问题，也不是数据质量工具的问题。这是一个基础设施问题——而你还没有把它当作基础设施问题来对待。

大多数工程团队处理标注的方式，就像处理会议室预订系统一样：采购工具、编写规范、雇几名外包人员、交付数据。当你只需要一次性标注数据集时，这套模式还算管用。但一旦标注成为持续驱动线上生产模型的活动——对于几乎所有从原型走向生产的团队而言，这已经是常态——这套模式就会彻底崩溃。

你的 /v1/summarize 端点在 18 个月里运行得非常完美。然后你升级了底层模型。输出格式没变，JSON schema 完全一致。但你的下游消费者开始提交 bug：摘要“太随意了”，要点“详细得诡异”，边界情况下的拒绝响应“变得不同”。从传统意义上讲，一切都没坏；但在 AI 的语境下，一切都坏了。

这是 REST 和 GraphQL 从未被设计用来解决的版本控制问题。传统的 API 合约假设确定性：相同的输入总是产生相同的输出。而 AI 端点的合约是概率性的——它包括语气、推理风格、输出长度分布以及拒绝阈值，当你更换或更新底层模型时，所有这些都可能发生漂移。对于以数据库为支撑的 API 有效的技术，对于以 AI 为支撑的 API 是必要但不充分的。

大多数团队将 AI 自主性视为一个二进制开关：智能体要么受监督，要么不受监督。这种思维模式正是为什么 80% 的组织报告了智能体的意外操作，以及为什么 Gartner 预测到 2027 年底，超过 40% 的代理型 AI 项目将因风险控制不足而被放弃。问题不在于 AI 智能体天生不可信，而在于团队在赢得独立性之前就将其提升到了独立地位。

自主性应该是智能体通过展示其可靠性而逐步积累的东西，而不是你在部署时分配的一个属性。就像一名新工程师在获得生产环境访问权限之前，先从审查 PRs 开始一样，AI 智能体在建立业绩记录的过程中，其操作范围也应逐步扩大。这不仅是哲学层面的思考——它会改变你所做的具体架构决策、你追踪的指标以及你设计回滚机制的方式。

大多数 AI 团队把通过评估套件视为系统正常运行的信号。但事实并非如此——至少不全是。一个稳定得分 87% 的套件只做了一件事：告诉你系统在套件恰好覆盖的那 87% 的场景中表现良好。如果这套测试是六个月前手工整理的，基于团队能想到的示例，从未用真实流量更新过，那它正在以越来越高的置信度测量错误的东西。

这就是评估覆盖率问题。它与你的评估器是否准确无关——而是关于你测试集中的查询分布是否与用户实际发送的查询分布相匹配。当这两种分布出现偏差时，你会得到一个比评估失败更糟糕的结果：一个通过的评估，背后却是悄然劣化的产品。

你的模型是基于去年的数据训练的。它在两个月前进行了内部评估，并在一个月后正式发布。当你得知用户遇到故障时，你已经落后于模型运行所需的现实世界六个月了。这种差距并非部署问题，而是反馈循环的问题。大多数团队不仅没有闭合这个循环，甚至根本没有对其进行衡量。

当模型表现不佳时，本能反应往往是归咎于模型架构或训练数据。但更深层次的问题通常在于反馈系统的延迟。从用户经历故障到该故障影响你的模型，这中间需要多长时间？大多数团队如果说实话，其实并不知情。行业分析表明，如果模型在六个月或更长时间内没有获得针对性更新，其在面对新数据分布时的错误率会上升 35%。原因并非模型本身在衰减——而是世界在前行，而模型却停滞不前。

大多数团队能把单智能体的可观测性做得足够好——加上链路追踪、统计 Token 用量、设置错误率告警。然后他们把并发智能体扩展到一百个，才发现整个监控体系一直在盯错方向。

摧毁集群的问题，并不是摧毁单个智能体的那些问题。一个陷入递归推理循环的智能体可以在一小时内烧光一个月的 API 预算。模型服务商悄无声息的质量降级，会让集群里的每一个智能体同时以满满的自信给出错误答案——而你的基础设施仪表盘依然一片绿灯。这些故障不会出现在延迟图表或 HTTP 错误率中，因为它们根本不是基础设施故障，而是语义层面的失效。

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

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

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

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

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

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