![[AI 上下文 #2] 长上下文为何会毁掉回答 封面图](/assets/images/posts/2441c21a-97a2-413d-93be-21c88b2120cb/1.jpg)
第 1 篇我们了解了上下文窗口为何有限。但看到如今的模型规格，难免会想：既然已经有 100 万 token 的模型，直接把整个代码库或文档全部放进去不就行了吗？还有必要节省着用吗？
本篇要打破的误区正是这一点。能“放进”上下文窗口，和模型能“用好”这些内容，是完全不同的问题。多项研究已经证实，上下文越长，模型性能越低；长期运行过代理的开发者也都能切身体会到：会话后半段的回答变得散乱，甚至开始重新修复已经修好的 bug。
lost in the middle：中间内容读不到
斯坦福研究人员于 2023 年发表的《Lost in the Middle》论文，是该领域最常被引用的成果之一。他们把正确文档放在长上下文的不同位置，测试模型找到它的能力，结果发现准确率呈 U 型曲线。开头和结尾的信息容易找到，而正中间的信息召回率会大幅下降。严重时，把答案放在中间的性能甚至低于完全不给文档、直接提问的情况。
模型确实会“读完”20 份文档，只是不会平均分配注意力。注意力权重也呈现出类似的模式：人阅读厚重报告时会集中看引言和结论，只用眼睛扫过正文。
模型发布资料中经常出现的“干草堆里找针（needle in a haystack）”测试分数，很容易掩盖这个问题。该测试只是在长文本中埋入一个句子，再要求模型原样找出；如今的大多数模型都能接近满分。实际工作并不是简单的信息召回。当任务变成需要连接多处信息并进行推理时，同一个模型的分数会随着上下文变长而下滑。
context rot：长度本身就会降低性能
2025 年，向量数据库公司 Chroma 发布了一份技术报告，将这一现象命名为“context rot”。他们以 18 个主流模型为对象，只不断增加输入长度并执行相同任务，结果发现即使任务难度不变，仅仅因为输入变长，性能就持续下降。即使输入仍在上下文窗口规格之内也是如此。
原因是多种因素叠加。首先是注意力的结构性限制。注意力权重就像总量固定的预算，token 越多，分配给单个 token 的份额就越薄。无关内容混入得越多，真正重要的信号就越容易被淹没。其次是训练分布问题。模型训练时接触的大多数文本都是短文档，因此数十万个 token 的输入对模型来说是训练期间几乎没见过的陌生场景。规格上可以处理，并不代表能保证这种长度下的推理质量。
因此在实践中，需要建立“有效上下文”的概念。即使规格是 20 万 token，在复杂推理任务中能够维持质量的范围也远短于此，采取这样的判断更稳妥。规格数字表示“放到这里不会报错”，而不是“放到这里模型依然聪明”。
代理的上下文不只是长，还很杂乱
在代理中，问题会进一步恶化。正如第 1 篇所见，代理的上下文会积累工具调用结果，而这些累积内容不只是很长，还彼此矛盾。
看看典型场景。代理为了修复 bug，读取文件、修改文件，再次读取。现在上下文中并排存在同一文件修改前和修改后的版本，也同时有失败和成功的测试日志。模型下一步判断时会参考哪一个，无法保证。它看到旧版本，说“这里还有 bug”，于是重新开始一个已经完成的修复，这就是问题的来源。
这些失败模式也有名称。错误信息（例如混入幻觉的摘要）进入上下文，并连锁污染后续判断，称为 context poisoning；累积历史过长，使模型被过去模式的重复吸引，而不是遵循新指令，称为 context distraction；相似但不同的信息混在一起造成混淆，称为 context confusion；矛盾信息发生冲突，称为 context clash。即使不知道这些名称，症状也很熟悉。会话后半段的代理特别容易重复同一个错误，或去做被要求不要做的事，通常就是这四种情况之一。
识别质量下降的信号
如果在长会话中出现以下信号，就该怀疑是上下文问题。
- 重新处理已经解决的问题，或反复读取同一个文件
- 开始违反会话初期确定的规则，例如代码规范或不得修改的文件
- 回答变得冗长，不再围绕上一个问题，而是被很久以前的话题带偏
- 忽略刚刚提供的信息，使用上下文某处的过时信息回答
重要的是，模型并不是“累了”。模型是一个每轮都会从头重新读取内容的无状态机器。发生变化的不是模型，而是它需要读取的上下文状态。输入变得又长、又乱、又矛盾，所以输出质量才会下降。
总结
- 进入上下文不等于会被很好地使用。中间信息召回率下降的 lost in the middle，以及长度本身降低性能的 context rot，都是研究已经证实的现象。
- 规格数字是上限，不是质量保证。任务所需的推理越复杂，就越应该认为有效上下文远短于规格。
- 代理的上下文会积累工具调用残留，甚至包含矛盾。poisoning、distraction、confusion、clash 四种失败模式，是会话后半段质量下降的主要原因。
诊断完成后，从下一篇开始讨论解决方案。先从最基本的工具 /clear 和 /compact 讲起。二者都“清空上下文”，但工作原理完全不同，使用不当反而会丢失工作上下文。我们将建立何时清空、何时压缩的判断标准。