在LLM的推理过程中向上下文窗口持续添加令牌即使窗口填充量尚未达到架构的容量上限仍会导致输出质量发生隐蔽且渐进式的退化。这一现象被定义为“上下文腐烂”。人工智能模型的功能在测试阶段往往表现优异但上线后生成内容的质量可能悄然衰退。LLM模型本身没有改动、提示词未曾修改、响应延迟指标正常、错误率也维持在正常范围但生成内容的质量却逐渐劣化逻辑衔接生硬、丢失关键细节以及频繁引用无关历史信息。这种现象有其专属名称“上下文腐烂context rot”。它不会导致异常不会出现在仪表盘中。它是人工智能生产环境系统中最为隐蔽的故障模式之一而及早认识并应对这一现象对于保障内容生成系统的长期质量具有重要意义。LLM中的注意力机制的工作原理要理解上下文腐烂需要了解其核心的底层机制。在LLM生成每个新令牌之前它会查看上下文中的全部令牌并决定给每个令牌赋予多大的权重——这就是所谓的“注意力”。关键见解注意力得分经过归一化处理所有令牌得分的总和为1.0。换句话说注意力总量是一个固定预算。当上下文仅有500个令牌时一条关键信息可能分配到0.15至0.2的注意力权重而当上下文扩展至50,000个令牌时同一条关键信息所能获得的注意力便可能骤降至约0.002。Java// Simplified illustration — not actual LLM code public float[] generateNextToken(String[] contextTokens) { float[] scores new float[contextTokens.length]; for (int i 0; i contextTokens.length; i) { // How relevant is each past token to what we are generating? scores[i] computeRelevance(currentState, contextTokens[i]); } // Scores must sum to 1.0 — a fixed attention budget float[] weights softmax(scores); return weightedCombination(contextTokens, weights); }每新增一个令牌都会对其他所有令牌可获得的注意力产生微量的稀释效应无论其与当前生成任务是否相关。这正是导致上下文腐烂的根源所在。上下文位置与注意力分配一项针对多文档问答的著名实验揭示了人工智能系统构建者值得警醒的规律。该实验将正确答案置于长上下文中的不同位置并只依据其位置维度测量检索准确率•答案在开头准确率约75%•答案在结尾准确率约72%•答案在中间准确率约55%检索准确率下降幅度高达20%其决定因素完全在于信息在上下文中所处的位置而非信息本身的质量或与当前任务的相关性。该信息虽然客观存在并且模型在技术层面能够“感知”到它但并未对其施以有效的注意力处理从而未能正确利用。这就是所谓的“中间丢失”Lost-in-the-Middle效应。它是Transformer训练过程本身的一个新兴架构特性——模型天生学会强烈关注输入内容的开头和结尾因为人类写作中最具信息密度的内容往往出现在这些位置。长上下文的中间区域由此沦为注意力的“死区”这是训练过程中的自然产物而不是设计方面的缺陷。这一现象在当代模型中是否依然存在客观而言是的但存在重要区别。新一代模型已能在较大程度上解决简单事实检索问题——在长上下文中定位特定事实已经成为当前架构能够较好处理的任务。然而在多步骤推理任务中该问题不仅持续存在甚至有所加剧。此类任务要求模型同时综合多个文档中的信息而这恰恰是大多数生产级人工智能系统所面临的实际场景。因此即便基准测试指标持续攀升实际部署中的风险依旧不容忽视。上下文腐烂在实际应用中的表现场景1编码智能体的任务偏移一个编码智能体需要修复某处缺陷。它先后读取15个文件探索3个错误的线索并经历多次回溯。每一次文件读取、搜索结果返回、无效排查记录的写入都在上下文中持续累积。当智能体找到埋没在20000个令牌中间的问题文件时注意力已经无法对该文件进行充分聚焦——其分析深度与精度远不及在干净上下文环境中的表现。场景2RAG管道的输出失真一个检索增强生成RAG检索管道默认对每次查询返回10个文档块约合5,000个令牌在大多数查询场景下运行稳定。然而当查询较长时系统提示与对话历史记录随之增加总上下文增长至40,000个令牌。此时第三和第四个检索到的文档块恰好处在上下文的中间区域落入注意力死区。模型生成的回复看似通顺实则依赖首尾片段拼凑而成遗漏了第四个文档块中的关键细节。如何检测上下文腐烂步骤1记录每次LLM调用的上下文长度。如果无法衡量则无法管理。步骤2运行位置准确性测试。将一个关键事实置于实际上下文中的不同位置检查模型是否能正确检索。Javapublic void positionalAccuracyTest(LlmClient client, String keyFact, String fillerText) { double[] positions {0.1, 0.5, 0.9}; // beginning, middle, end for (double pos : positions) { int split (int) (fillerText.length() pos); String context fillerText.substring(0, split) \nKEY: keyFact \n fillerText.substring(split); String response client.complete(context, Summarise the most important information from the context.); boolean found response.toLowerCase().contains(keyFact.toLowerCase()); System.out.printf(Position %d%%: %s%n, (int)(pos 100), found ? RECALLED : MISSED); } }如果模型在10%和90%位置处检索通过而在50%位置处失败则表明在该上下文长度下系统中的上下文腐烂效应是可以测量的。步骤3针对上下文长度阈值配置告警。建议将软告警阈值设为约50,000个令牌硬性告警阈值设为约100,000个令牌。上述数值仅为初始参考基准——确切的最佳阈值需依据上述位置准确性测试的结果对特定模型与任务类型进行校准。上下文腐烂也是成本问题大多数关于上下文腐烂的讨论聚焦于生成质量这无可厚非。然而在具备实际规模的部署场景中它同时也是一个不容忽视的财务问题——而这个维度往往要等到出具账单之后才会被重视。LLM服务提供商按令牌用量计费上下文中每个令牌在每次调用中都会被计费。对于同一任务一个已经增长到80,000个令牌的上下文其单次调用成本约为10,000个令牌时的8倍而输出质量反而更低。这并非一种权衡而是在两个维度上同时承受损失。每个令牌的确切成本因提供商和模型级别而异但这一比例关系具有普遍性——上下文越长成本越高。计算层面的现实进一步加剧了这一困境。Transformer的注意力机制随上下文长度呈二次方扩展——令牌数量翻倍时所需计算量并非倍增而是增长约四倍。在低调用量下这一效应几乎难以察觉但当每日调用量达到数百万次级别时它就成为人工智能系统运营成本中最大的单项支出之一。上述数值仅为示例真正值得关注的是其比例关系。针对同一任务上下文增长至80,000个令牌时的单次调用成本约为10,000个令牌时的8倍而输出质量通常反而更低——这并非取舍而是双重恶化。在大规模部署中上下文腐烂已不仅是质量问题更是预算问题。压缩上下文、采用精确检索、实施子智能体隔离这些措施不仅是工程最佳实践更是切实有效的成本控制手段。4项实用缓解措施1.压缩应尽早实施而不是等到质量衰减显现之后方才补救应在上下文规模显著增长之前对较早的对话轮次进行摘要压缩而不是事后补救。Javapublic ListMessage compactIfNeeded(ListMessage messages, LlmClient client) { int limit 30_000; if (estimateTokens(messages) limit) return messages; // Need at least a system prompt messages to summarise recent turns if (messages.size() 7) return messages; // Everything except system prompt and last 5 turns ListMessage older messages.subList(1, messages.size() - 5); String summary client.complete(Summarise concisely: format(older)); ListMessage compacted new ArrayList(); compacted.add(messages.get(0)); // system prompt compacted.add(new Message(system, summary)); compacted.addAll(messages.subList(messages.size() - 5, messages.size())); return compacted; }2.使用子智能体进行探索当智能体需要执行搜索或探索性操作时应在具备独立上下文窗口的专用子智能体中完成。仅将压缩后的结果而不是探索轨迹返回至父智能体从而将数据噪音有效隔离于上下文之外。3.在RAG中遵循“检索更少、重排序为先”原则三个高度相关的文档块始终优于十个相关性松散的文档块——检索数量不等于检索质量。应首先获取范围更广的候选集按相关性分数重新排序最终仅将排名靠前的文档块传递给模型。4.关键内容的刻意放置策略基于注意力机制的分布规律关键上下文信息应置于开头或结尾而非中间位置。系统提示词与当前用户查询天然占据这些优势区域需要固定放置与此同时中间段落内容应进行有规划的填充以优化整体信息架构。这对不同层级人员意味着什么1.对于初级工程师当LLM的功能在本地测试通过、但在生产环境表现异常时首要排查步骤应为检查上下文长度。建议将llm.context_tokens指标与延迟、错误率一同纳入可观测性堆栈——这是一个改动很小却信号意义重大的举措。2.对于技术负责人与架构师上下文并不是免费资源。在每一个涉及LLM功能的设计讨论中必须清晰回答两个问题“当前上下文窗口中包含什么以及为什么包含”如果无法给出明确答案则意味着设计本身尚不成熟。3.对工程经理与团队领导者上下文劣化不会出现在标准仪表盘中。错误率和延迟指标可能始终健康而响应质量却在悄然下滑。将上下文长度与下游质量指标、任务成功率及用户满意度进行关联监控已经成为生产级人工智能系统不可或缺的运维要求。结论上下文腐烂这个概念初听时略显高深但一旦真正应用就会觉得它本该是显而易见的常识。其核心实现其实很简单Transformer的注意力机制本质上是一种有限且可被稀释的资源。每向上下文窗口添加一个额外的令牌都会从其他内容那里分走一份注意力。当上下文的规模不断增长而关键信息恰好被埋没在中间位置时质量便会以真实、可测量但悄无声息的方式下降。好消息是这个问题完全可控。尽早压缩、将探索性任务隔离到子智能体中、采用精准检索、刻意将关键内容放在首尾——这些都不需要高深的机器学习知识它们只是人工智能时代的标准化工程规范。最有帮助的思维模型是像经验丰富的工程师对待内存那样对待上下文——刻意规划分配及时释放不再需要的内容始终保持工作集的精简与专注。只要为模型提供干净的信号而不是嘈杂的噪声它们就是稳定地生成高质量的结果。原文标题Context Rot: Why Your AI Agent Gets Worse the Longer It Works作者Vineet Bhatkoti