六个月悬崖：为什么生产环境中的 AI 系统会在没有一行代码改动的情况下发生退化

你的 AI 功能顺利上线了。延迟很低，错误率微乎其微，HTTP 响应全是 200。六个月后，一名用户抱怨聊天机器人言之凿凿地推荐了一款你在三个月前就停产的产品。工程师深入调查后发现，系统在回答用户问题时，有三分之一的情况都是错误的——这不是因为代码部署出了问题，也不是因为依赖项升级，而是因为时间的流逝。你将一张快照交付到了奔流的河水中。

这并非假设。行业数据表明，91% 的生产环境 LLM 在部署后的 90 天内会出现可衡量的行为漂移。一个最初能在无需人工干预的情况下处理 70% 查询的客户支持机器人，到第三个月时，这一比例可能会悄然下降到 50% 以下——而此时，基础设施仪表盘全程显示的都是代表正常的绿色。“六个月悬崖”是真实存在的，它是无声的，而且大多数团队并没有能够预见其到来的监测手段。

悄然侵蚀生产环境 AI 的三种力量

LLM 驱动的系统中的无声退化很少是由单一因素引起的。它通常是三种独立衰减过程同时发生的汇聚，每种过程都在不断累积，直到整体跌落变得无法忽视。

**评估分布漂移（Eval distribution drift）**是最被低估的因素。当你发布一个 AI 功能时，你会构建一个反映你所能想象到的查询和边缘案例的评估集。但生产环境的流量是不断演进的。用户会采用新的术语，询问你自发布以来添加的新功能，并以你评估集从未预料到的方式提出问题。模型本身没有改变，但你的测试内容与生产环境中实际发生的情况之间的差距每周都在拉大。你的评估套件保持绿色，而现实世界的准确率却在悄然流失——由于你测量的是错误的东西，你甚至收不到任何信号。

**隐性基础模型更新（Silent base-model updates）**是更危险的原因，因为它们完全超出了你的控制。模型提供商经常在不更改你在生产环境中调用的模型名称的情况下，更新其模型的行为。Anthropic 放弃了版本锁定支持，强制用户使用最新版本。OpenAI 提供带日期的快照，但会定期以 3 到 6 个月为周期弃用它们。当模型提供商发布行为更新时——即使是出于好意的更新——你的提示词（prompts）也可能以微妙的方式失效：结构化输出格式略有变化，拒绝模式发生转变，推理风格的改变足以影响下游逻辑。一个被广泛报道的案例是：由于智能体（agent）行为发生变化，一次隐性的模型更新在三天内使 CI 失败率翻了一倍，而代码本身没有发生任何改动。

**知识库腐烂（Knowledge base rot）**使上述问题更加复杂。任何 RAG 系统的时效性都取决于其索引文档的更新频率。定价页面在几周内就会与现实脱节。合规文件过期且未重新索引。在发布时索引了你的文档的系统，会继续根据数月前的过时信息自信地回答问题——由于 RAG 输出看起来依然逻辑严密、格式良好，因此没有任何明显的信号表明底层事实已经出错。一项分析发现，仅仅由于知识陈旧，RAG 系统在 90 天内就会损失大约三分之一的有效准确率。

为什么你的监控手段无法察觉

“六个月悬崖”最深层的问题在于，传统的可观测性是为基础设施故障而非语义故障设计的。当你的 AI 功能向用户提供错误信息时，HTTP 状态码、延迟百分位和错误率看起来依然健康。“系统运行正常”与“系统有用”之间的鸿沟，正是无声退化生存的地方。

尽管 89% 的组织声称拥有可观测性方案，但在生产环境中运行 AI 智能体的组织中，只有 62% 能够检查其智能体在每个具体步骤中实际执行的操作。可观测性通常意味着请求/响应日志，但这并不等同于质量测量。

LLM 特有的失效模式以传统 ML 监控无法预见的方式放大了这一问题。在经典的机器学习中，你可以使用输入特征分布的统计方法（如 KL 散度、群体稳定性指数、特征重要性偏移）来检测漂移。这些方法对 LLM 系统部分有效，但它们对语义漂移（semantic drift）却是盲目的：两个响应在 Token 长度和词汇表上可能在统计上非常相似，但编码的意思却完全不同（其中一个可能是错误的）。一个曾经能准确总结复杂技术内容的模型，可能会开始产生听起来很合理但忽略了关键限制条件的总结——没有任何 Token 分布指标能捕捉到这一点。

多智能体系统（Multi-agent systems）面临着额外的复合失效。在长期运行中，智能体遇到的输入分布与最初设计的分布越来越大。决策模式逐渐偏离设计规范，而无需显式的参数更改或任何可观测的故障事件。生产环境中最危险的响应是“无声的 200 OK”：请求完成了，响应看起来很合理，而数据质量在被人发现之前已经被无声地污染了 11 天。

生产级 AI 维护的真实面貌

正确的思想模型是将 AI 功能维护视为基础设施维护：定时、可衡量且强制执行 —— 而不是在接到用户投诉后才被动应对。

黄金数据集（Golden set）测试是基础。 黄金数据集是包含预期输出（或评估准则）的固定输入集合，你需要针对生产环境流量样本持续运行这些测试。一个最小可行黄金数据集包含 50-100 个覆盖核心用例的示例。生产级数据集则运行 200-500 个示例。成熟的系统会不断从生产失败案例中提取示例。测试在每个候选发布版本上运行；相对于主分支，如果整体质量得分下降 3%，就应触发调查，而不是直接发布。

四种统计信号可以在用户发现之前捕获偏移（Drift）：

• 回答长度分布的 KL 散度：跟踪 7 天滚动基准。在约 87% 的案例中，回答长度的变化是质量发生偏移的领先指标 —— 开始变得更啰嗦或更简洁的模型通常在更广泛的行为上发生了改变。
• Embedding 偏移：跟踪回答与预期输出随时间变化的语义相似度。当 Embedding 开始偏离参考分布时，说明模型对 Prompt 的理解发生了某些变化。
• LLM-as-judge 评分：使用第二个 LLM 调用，根据正确性和事实一致性的准则为生产输出评分。持续对 1% 的生产流量样本运行此操作。
• 拒绝指纹识别（Refusal fingerprinting）：监控拒绝模式的变化。拒绝次数的突然激增或下降，几乎总是模型行为策略发生变化的信号 —— 通常源于供应商的静默更新。

刷新频率应该是明确的，而不是响应式的。 生产级团队达成共识的标准时间表：

• Prompt 重新评估：每 30 天一次，或者在任何模型供应商发布公告后的 48 小时内，针对过去一周的生产流量样本运行完整的评估套件。发布时通过测试的 Prompt 往往随着模型的更新而需要调整。
• 知识库审核：每 60-90 天审核一次文档的新鲜度。对于 RAG 系统，将“文档时效”作为与检索延迟和回答质量同等重要的一等公民指标。任何超过预期保质期（定价信息为几天，政策为几个月，稳定的架构内容为一年）的文档在呈现给用户之前都需要验证。
• 黄金数据集扩展：每季度从过去一段时间发现的生产失败案例和边界案例中增加 50-100 个示例。一个不增长的黄金数据集对生产环境真实情况的反映会变得越来越片面。
• 模型版本审核：跟踪你在生产中调用的每个模型版本以及供应商的弃用时间线。对于 OpenAI，这意味着关注弃用页面，并在计划中预留 60 天的迁移缓冲。对于 Anthropic，这意味着接受更新是自动的，并转而投资于快速评估基础设施。

技术失败背后的组织失败

“六个月悬崖”既是一个技术问题，也是一个组织问题。当一个 AI 功能发布后，构建它的团队就会转向其他项目。该功能被视为“已完成”。责任归属随之消散。没有人负责维护评估套件，没有人负责知识库刷新，也没有人建立监控，因为该功能只是被发布了 —— 而没有被维护。

避开“六个月悬崖”的团队做出了一个结构性决策：他们认为 AI 功能需要与生产服务同等级别的持续维护。这意味着：

• 为评估套件维护和知识库刷新分配明确的负责人，独立于开发该功能的团队
• 将“AI 质量”视为与延迟和可用性并列的 SLO —— 设有告警、阈值和值班责任
• 定期审阅模型供应商的公告，并相应调整版本锁定和迁移时间线
• 将静默失败 —— 即看起来正确但包含陈旧或错误信息的输出 —— 视为一等公民 Bug，而不是“预期行为”

这里的工程规范并不光鲜。它就像每次部署前运行的 CI 流水线与只设置一次从未扩展过的流水线之间的区别。黄金数据集、偏移监控和刷新频率相当于 AI 系统的集成测试：这是团队在快速前进时最先忽略的东西，也是当生产环境悄无声息地崩溃时，他们最渴望当初已经投资的东西。

从哪里开始

如果你现在有正在运行的 AI 功能，但还没有持续维护的基础设施，优先级顺序如下：

1. 本周构建一个黄金数据集。 即使只有 50 个覆盖核心用例的示例，也能为你提供回归检测。在下次部署前运行它。
2. 对 1% 的生产流量增加 LLM-as-judge 评分。 你不需要完美的准则。针对样本运行一个简单的“此回答是否正确且有事实依据？”的 Prompt，就能为你提供质量趋势线。
3. 审计你的知识库时效。 找出 RAG 索引中自发布以来从未更新过的文档。假设它们在某些方面是错误的。
4. 检查你的模型版本暴露情况。 对于你在生产中调用的每个模型，了解供应商上次更新其行为的时间以及弃用时间线。

“六个月悬崖”并非不可避免。当 AI 功能被视为一次性交付物，而不是需要持续衡量和维护的生产系统时，它是必然的结果。那些最先发现质量下降（在用户发现之前）的团队，是那些构建了观测仪器的团队。