LLM 中的上下文退化：长上下文论文究竟揭示了什么

r/MachineLearning 上一篇新帖认为，尽管现代上下文窗口的规模令人安心，长时间的 LLM 会话仍会在达到标称上限前开始退化。该帖将这一问题与长时间分析和编程会话联系起来：早先的决策依然可见，却逐渐失去影响力。

多项研究在总体方向上支持这一说法，但具体细节很重要。模型并不会在超过某个固定 token 数后简单地忘记一切。其表现会随上下文长度、证据位置、任务难度、词汇重叠程度及周边材料而变化。

因此，真正的矛盾并非短上下文与长上下文之争，而是容量与可靠使用之间的差异。模型可以接收一份文档，却未必能同样有效地使用其中每一部分。

这种差异给将对话历史视作持久工作记忆的开发者、研究人员和知识工作者带来了压力。它也对那些将一次连续聊天呈现为一条连续推理链的产品界面提出了挑战。

Reddit 帖子将隐蔽的失效转化为工作流问题

眼前发生的事件，是一场研究讨论正在演变为关于人们如何进行长时间 AI 会话的实用警示。

2026 年 8 月 2 日，一位用户向 r/MachineLearning 提交了一篇关于上下文退化的帖子。其链接说明称，长会话可能在远未达到 token 上限时就开始退化。

这篇投稿并未建立新的基准。它围绕一种熟悉的体验，重新包装了一个既有研究问题：助手一开始表现敏锐，随后逐渐丢失约束、优先级或先前的推理。

这种体验可能以多种形式出现。编程助手可能重新引入已被否决的架构。研究助手可能在用户纠正后，仍引用过时的假设。分析工具可能保留单独的事实，却丢失连接这些事实的逻辑。

这些失效很难诊断，因为聊天记录看起来依然完整。较早的消息仍显示在屏幕上，助手在被提示时往往也能引用它们。然而，准确检索并不保证正确推理。

上下文窗口是模型在一次请求中可接收的最大 token 序列。它并不承诺每个被接收的 token 都能获得同等的实际权重。

这种差异类似于存储容量与工作注意力之间的区别。一张拥挤的桌子可以放下所有相关文件，但压在一大摞文件下面的那份会更难使用。这个类比并不完美，因为 transformer 并不像人类一样思考，但它捕捉到了实际操作中的风险。

这篇帖子出现之际，上下文窗口已成为显眼的产品指标。更大的窗口可容纳代码仓库、书籍、会议历史和研究论文集合。这种容量很有用，但也可能鼓励用户无限期维持同一个会话。

于是，长会话会积累多种摩擦：被放弃的方案、重复的指令、中间输出、纠正内容和陈旧事实。每一项仍可能被调用，但它们持续存在并不意味着同样有帮助。

由此产生的退化很少是一次彻底崩溃。回答可能依旧流畅，却越来越不忠实于项目的主导决策。这使得上下文失效比明确的错误消息更危险。

现有研究记录支持这一广泛警示。不过，它并不支持某个特定轮次就是失效点的普遍说法。例如，没有论文证明在不同模型和任务中，第二十条消息都会变得实际上无法访问。

改变的是问题的框架。长上下文的弱点正从基准讨论进入日常工作流设计。问题不再是模型能否接收整个转录记录，而是这份记录是否仍是值得信赖的推理环境。

论文揭示的是多种失效，而非单一的上下文断崖

上下文退化是一组可测量的弱点，而不是 LLM 突然失去记忆的单一阈值。

最常被引用的位置效应结果来自 2024 年论文 Lost in the Middle。作者在不同证据位置下测试了多文档问答和键值检索。

当相关信息出现在开头或结尾附近时，性能往往最强。当相同信息出现在中间时，性能会下降，即使是为长上下文设计的模型也是如此。

这种模式通常被描述为 U 形性能曲线。该曲线显示了位置敏感性，但并不意味着每个模型都会忽略中间内容。结果会因模型、输入长度、任务和提示构造而异。

位置只是问题的一部分。RULER 在简单的大海捞针式检索基础上，扩展了多针检索、多跳追踪和聚合任务。

其研究人员在 13 项任务中评估了 17 个长上下文模型。尽管每个被评估模型都声称至少支持 32,000 token 的上下文，但只有一半能在该长度下维持令人满意的表现。

因此，RULER 基准揭示了找到一个字面字符串与使用分布式信息之间的差异。模型可以通过简单的检索测试，却在聚合或链式推理上举步维艰。

NoLiMa 将这一区别进一步推进。它降低了问题与相关证据之间的词汇重叠，迫使模型推断关联，而非匹配相似词语。

研究人员评估了 13 个声称至少支持 128,000 token 的模型。在 32,000 token 时，其中 11 个模型跌至其强短上下文基线的一半以下。

GPT-4o 仍是该测试中表现较强的系统之一。即便如此，其报告结果仍从 99.3% 的短上下文基线降至 32,000 token 时的 69.7%。

这些 NoLiMa 结果很重要，因为普通分析很少提供完美的关键词对齐。一个项目决策与后续问题可能通过不同词汇表达同一概念。

对话还会引入时间维度的复杂性。用户可以先陈述某项偏好，之后再修改它，然后提出一个要求系统识别当前版本的问题。

LongMemEval 正是围绕这一更广泛的记忆问题设计的。它包含 500 个问题，测试信息提取、多会话推理、时间推理、更新后的知识以及恰当的弃答。

其作者报告称，商业聊天助手和长上下文模型在持续交互中的整体准确率下降了 30%。该结果针对的是特定基准，而非每一段真实对话。

综合来看，这些研究至少区分了四类问题。模型可能难以定位证据、连接间接相关的证据、优先处理当前版本，或在检索到正确材料后仍无法正确推理。

最后一种失效尤为重要。这意味着，仅仅改善搜索并不能解决长上下文问题。

为什么完美检索仍无法保护长时间分析

即使模型找回了正确证据，随着总输入变长，它的推理仍可能变差。

一篇 2025 年 10 月的预印本在五个开源和闭源模型中分离检验了这种可能性。研究人员测试了数学、问答、编程以及合成变量求和任务。

他们在保持证据和问题受控的前提下构造了更长输入。报告的性能损失范围为 13.9% 至 85%，尽管相关证据的检索完全准确。

作者还用干扰最小的空白字符替换了无关散文。部分模型仍然退化。随后，他们在开源模型实验中屏蔽无关 token，退化依旧存在。

这项完美检索研究是一篇预印本，而非已确立的科学共识。其实验具有合成性质，模型样本也并不代表所有当前系统。

尽管如此，这一结果挑战了一种方便的解释。上下文失效并不总能归咎于模型从嘈杂材料中选错段落。

研究人员还将证据放在问题之前紧邻的位置。在若干设置中，更长的输入仍会损害性能。这一发现削弱了“只要重复最新指令就能修复拥挤对话”的说法。

另一篇 2026 年预印本研究了结构化填充内容下的位置失效。它测试了当周围上下文保持受控时，目标问题的位置是否会改变准确率。

该研究报告称，脆弱模型从末尾位置到中间位置出现了大幅准确率下降。在其最初的五模型集合中，76% 的中间位置错误与周围填充内容的答案一致，而处于末尾时这一比例为 22%。

研究人员将该结果解释为填充内容干扰的证据。较新的版本通常显示出较小的下降幅度，这也表明供应商正在改善某些长上下文行为。

这些研究不应被合并为一个普遍失效率。它们采用了不同的模型、数据集、评分方法、上下文长度和退化定义。

但它们支持一个共同结论：最大上下文长度与有效上下文长度是不同的衡量指标。

最大上下文长度描述输入接收能力。有效上下文长度描述模型能够针对特定任务可靠使用多少材料。

随着任务变得不那么字面化，这一有效长度可能缩短。当模型必须组合证据、区分修订版本、保留约束或抵抗看似合理的干扰时，它也可能缩短。

这解释了为什么即使简单回忆能力依然令人印象深刻，长时间分析仍可能感觉不稳定。询问“我对数据库说了什么？”测试的是检索。询问“当前设计是否仍满足所有数据库约束？”测试的则是检索、优先级判断和推理。

长聊天还包含模型生成的材料。每一份草稿、解释和推测性说法，都可能成为未来的上下文。早期模型错误因此可能与用户后来的纠正相竞争。

问题不在于系统拥有会衰退的人类式记忆。模型接收的是经过构造的输入，并基于该输入产生输出。失效存在于它对不断增长序列的使用是否可靠。

这一机制使上下文管理成为工程问题。它也解释了为什么措辞精美不能作为底层推理始终保持对齐的证据。

真正的对手是缺乏控制的连续性

核心权衡在于便利的对话连续性，与一组更小、受治理的权威事实之间。

一次连续会话让人感觉高效。用户无需反复说明项目，助手则似乎保留了每一项决策和发现。

连续性也降低了可见的准备成本。重新开启一个聊天仿佛是在丢弃工作，尤其是在数小时的研究或调试之后。

然而，不间断的转录记录会变成一个未经管理的数据库。旧假设与已确认事实并列。被否决的计划与获批决策并列。临时措辞与具有约束力的要求并列。

助手在接收这些材料时，并没有成熟信息系统中常见的治理机制。聊天记录不会自动区分现行政策、过时笔记、原始证据和推测性输出。

较新的信息可能会有所帮助，因为它出现在靠近末尾的位置。然而，后来的更正并不会抹去先前的陈述。除非应用主动对其进行总结、检索或筛选，否则两个版本都可能仍然可用。

这给 AI 产品团队带来了压力。大型上下文窗口容易营销，而可靠地使用上下文则需要针对任务的评估和谨慎的系统设计。

这也给构建智能体的团队带来压力。智能体往往会在多个步骤中累积工具结果、计划、错误、观察和生成的代码。每一项新内容都会增加后续操作必须解读的材料。

开发者可以采用检索增强生成，即 RAG。RAG 会搜索外部集合，并针对给定请求向模型提供选定段落。

检索能够减少放入活跃提示词的材料量。它还可以保留来源溯源信息，并让更新比重写一整份庞大转录记录更容易。

但 RAG 并不会自动解决问题。检索可能会选出语义相似但不完整的段落。糟糕的分块边界可能会把例外情况与其所修饰的规则分开。

完美检索研究提出了第二个担忧。即使正确证据已经存在，过长的提示词仍可能削弱任务表现。

更好的设计会将上下文视为经编译的工作集。系统应针对每项任务，组装当前指令、已验证证据、未解决问题以及最少量的相关历史。

这一思路也会改变个人工作流。用户不必要求聊天成为唯一记录，而可以维护一小组外部工件。

决策日志记录选择了什么、为何选择，以及拒绝了哪些替代方案。证据文件将源材料与模型解读分开。任务简报记录当前目标和约束条件。

这正是结构化个人知识库可以发挥作用的地方。其有用之处并非无限存储，而是能够检索出更小、更具时效性的材料集合。

目标不是消除连续性，而是停止将连续性当作控制力。

长转录记录作为档案仍然很有价值。当档案同时充当唯一的规范、记忆系统和推理工作区时，它就会带来风险。

经受证据检验后仍然成立的习惯

最安全的工作流会定期在要求模型继续推理前，将对话转化为紧凑、可检查的状态。

第一个习惯是将持久状态与对话历史分开。持久状态包括已批准的决策、定义、约束、证据和未解决问题。

将这些状态保存在聊天之外的一份简短文档中。可以让模型提出更新建议，但在接受之前应审阅这些更新。

这一步可以防止助手的推测性回答悄然变成项目事实。它也为下一次会话提供更清晰的起点。

第二个习惯是在作出重要决策后使用检查点。检查点应捕捉当前目标、已接受的结论、被拒绝的选项以及下一项测试。

不要要求泛泛的总结。泛泛总结偏向流畅性和覆盖面，而检查点需要明确的类别和可追溯的承诺。

一个有用的检查点可包含五个字段：

• 当前目标和成功定义

• 具有约束力的限制及其来源

• 已作出的决策和被拒绝的替代方案

• 需要证据支撑的未决不确定性

• 下一步行动及其预期输出

第三个习惯是在任务边界处开启新会话。研究收集、证据评估、大纲设计和最终写作，对上下文提出的要求各不相同。

研究会话受益于来源细节。写作会话受益于经过验证的论断和已经确定的结构。将每一轮研究交流都带入起草阶段，只会增加材料，却不会带来相称价值。

开启新会话并不意味着丢弃已有工作。它意味着交接经过筛选的内容，而不是把整个工作现场都交过去。

第四个习惯是在任务附近重复关键约束，同时保留一个权威版本。这在生成代码、评估证据或在严格要求下写作时尤其有用。

重复内容应引用事实来源。否则，复制的指令可能在多个版本中逐渐漂移，并造成另一种上下文问题。

第五个习惯是要求模型展示其工作状态。在输出具有重要后果的结果前，请求它说明自己当前看到的假设、证据、约束和未解决冲突。

这并不能保证其内部过程完全忠实。模型的解释不会揭示其答案的每一个计算原因。但它确实提供了一项实用的对齐检查。

如果模型遗漏了具有约束力的限制，就应停止并修复工作上下文。不要仅仅因为之前的回答听起来很专业就继续推进。

第六个习惯是将检索与判断分开。先要求提供确切相关的证据，再要求仅基于该提取集合进行分析。

2025 年的完美检索论文测试了一种相关的“先检索、后推理”策略。该研究报告称，GPT-4o 在 RULER 上的表现最高提升了四个百分点。

这一结果仅限于所评估的设置。但它仍支持一种实用模式：在确定相关证据后，缩短推理输入。

第七个习惯是保留溯源信息。每项重要论断都应指向一个来源、实验、文件或用户决策。

溯源信息使错误更容易纠正，因为用户可以区分原始证据与助手的解读。它还有助于在多次会话后解决矛盾。

第八个习惯是将模型总结视为有损信息。总结会压缩、排序和重新解读。它们绝不应悄然取代原始证据。

应保留源文档，并针对它们审计高影响力论断。总结是导航层，而不是不可质疑的记录。

第九个习惯是观察行为症状，而不是等待 token 警告。警示信号包括重复提问、重新提出已被否决的想法，以及定义前后不一致。

其他症状包括忽略要求的输出格式、混淆证据与假设，或回答任务的早期版本。

当这些症状出现时，在同一会话中继续增加提示反而可能使情况更糟。更安全的应对通常是建立检查点、验证，然后用更小的上下文重新开始。

这些做法并不会给出一个普遍安全的会话长度。研究并不支持这种结论。它们能在退化变得昂贵前建立恢复点。

证据尚未证明的内容

长上下文基准测试足以支持谨慎态度，但并不能证明每段冗长对话都必然变得不可用。

这些研究差异显著。Lost in the Middle 侧重于证据位置。RULER 改变检索复杂度，而 NoLiMa 则降低词汇重合度。

LongMemEval 考察持续性的对话记忆。完美检索预印本试图隔离输入长度本身的影响。这些实验有所重叠，但并未测量完全相同的现象。

合成基准测试也会简化真实工作。它们提供了控制条件，有助于识别原因，但真实会话还包含工具、系统提示、应用记忆以及不断变化的用户目标。

商业应用可能会以未公开的方式预处理聊天记录。它们可能总结早期轮次、检索选定记忆、移除内容，或应用隐藏指令。

因此，使用相同底层模型的两个产品可能表现不同。即使同一个产品，也可能在模型更新或上下文管理修订后发生变化。

模型家族之间也存在差异。一些研究显示，一个系统存在显著的位置弱点，而另一些系统的下降较小。较新的版本有时会减轻早期的失效模式。

例如，2026 年的位置研究报告称，若干较新模型在末尾与中间位置之间的差距更小。这表明上下文使用正在改善，尽管剩余的失效问题仍然重要。

研究人员也在讨论，什么才算有意义的长上下文任务。字面意义上的针检索可能过于简单，而高度构造的推理测试又可能不同于日常工作。

有用的评估应与部署场景相匹配。法律审查系统需要处理例外、修订和跨文档关系。代码智能体需要依赖关系、当前文件以及已接受的架构约束。

两类系统都不应仅凭能否定位一句植入的句子来评判。同样，一个困难基准测试也不应抹杀系统在更狭窄任务上的有用表现。

“上下文腐烂”这一说法也可能造成误导。它听起来像信息在运行中的对话里发生了物理衰减。实际上，在许多系统中，每次响应的输入可能都会被重新构建。

可观察到的问题是，随着可用上下文变得更长或组织更差，任务表现会下降。内部原因可能涉及注意力、位置、干扰、预处理、检索或任务复杂度。

Chroma 的大型比较报告明确表示，它并未确定一个决定性机制。其研究人员观察到，在受控任务中，性能会随上下文长度和结构而变化。

context rot report主张谨慎地构建上下文。它也承认，需要将任务本身的内在难度与处理长度时的局限区分开来。

这种谨慎应当影响用户的判断。聊天后期的一次糟糕回答，本身并不能证明发生了上下文退化。

任务可能变得更难。指令可能相互冲突。工具可能返回了错误信息。模型可能已经更新，或者应用可能压缩了历史记录。

实际应对方式仍然相似：检查可用状态、减少歧义，并在受控条件下复现故障。

对于高风险工作，应使用干净、紧凑的提示词运行相同任务，并将结果与长会话结果进行比较。这项测试比单凭直觉提供更多证据。

长上下文 LLM 接下来值得关注的方向

下一阶段真正有价值的进展，将把宣传中的容量与任务特定的可靠性、可见的记忆控制和可重复的工作流测试连接起来。

第一个信号是模型发布中更好的位置评估。供应商应报告：当相同证据从开头移动到中间和末尾时，性能会如何变化。

这些评估应包括推理、聚合和修订处理。一个模型即使能在最大长度下检索到字面短语，也尚未证明其具备可靠的项目记忆。

如果位置控制结果成为标准，容量与可用性之间的差距将更容易比较。如果这类结果仍然缺失，买方就必须继续自行构建测试。

第二个信号是“先检索、后推理”系统的进展。这些系统识别相关证据，构建更短的工作上下文，然后执行所要求的分析。

关键衡量指标不只是检索召回率。开发者必须评估最终答案是否遵守约束、是否正确结合证据，以及是否拒绝过时信息。

成功的系统还将保留溯源信息。用户应能够检查：哪些来源和决策进入了对某项重要回答的工作上下文。

第三个信号是用户对记忆和会话状态的控制。产品界面需要更清晰地区分聊天历史、已保存记忆、检索到的文档和活跃指令。

用户应能将某一条目标记为权威、已被取代、不确定或排除。缺少这些控制机制时，更长的记忆会在保留更多有用事实的同时，也保留更多相互矛盾的信息。

对于团队而言，近期的经验教训很直接：不要仅凭上下文长度来选择 AI 系统。应使用真实的证据放置方式和真实的噪声，对关键任务进行测试。

对于个人而言，正确的应对方式并不是放弃长时间会话，而是改变一个会话被允许承担的职责。

让对话记录探索过程。将经验证的证据、当前决策和具有约束力的限制条件保存在更小的外部资料中。每当任务发生变化时，刷新模型的工作集。

在下一次进行长时间分析之前，先创建一份紧凑的项目简报和一份决策台账。随后，将一次全新会话的回答与最长对话中的回答进行比较。

如果全新版本对约束条件的遵循更准确，那么上下文并没有充当可靠的记忆。它充当的是一个噪声不断增加的档案库。