长上下文如何失效
来源 (中文翻译版): https://www.dbreunig.com/2025/06/22/how-contexts-fail-and-how-to-fix-them.html 抓取时间: 2026-07-21 16:19:18
2025 年 6 月 22 日 智能体 大语言模型 人工智能 提示工程 上下文管理
长上下文如何失效
管理上下文是成功构建智能体的关键
随着前沿模型的上下文窗口持续增长¹，许多模型支持高达 100 万个 Token，我看到许多令人兴奋的讨论，认为长上下文窗口将解锁我们梦想中的智能体。毕竟，有了足够大的窗口，你可以简单地把你可能需要的一切——工具、文档、指令等等——都扔进提示里，然后让模型来处理剩下的事情。
长上下文削弱了人们对 RAG 的热情（当你可以把所有文档都放进提示时，就不需要找最好的文档了！），推动了 MCP 的炒作（连接到所有工具，模型可以完成任何工作！），并激发了人们对智能体的热情²。
但实际上，更长的上下文并不会产生更好的响应。让你的上下文过载会导致你的智能体和应用程序以令人惊讶的方式失败。上下文可能会被污染、分散注意力、令人困惑或产生冲突。这对智能体来说尤其成问题，因为智能体依赖上下文来收集信息、综合发现和协调行动。
让我们来看看上下文失控的各种方式，然后回顾缓解或完全避免上下文失效的方法。
上下文失效模式
- 上下文污染：当幻觉进入上下文时
- 上下文分心：当上下文压倒训练时
- 上下文混淆：当多余的上下文影响响应时
- 上下文冲突：当上下文的某些部分不一致时
上下文污染
上下文污染是当幻觉或其他错误进入上下文并被反复引用时。
Deep Mind 团队在 Gemini 2.5 技术报告中提到了上下文污染，该报告我们在上周进行了详细分析。在玩 Pokémon 时，Gemini 智能体偶尔会在游戏过程中产生幻觉，从而污染其上下文：
这个问题的一种特别恶劣的形式可能发生在"上下文污染"中——上下文的许多部分（目标、摘要）被关于游戏状态的错误信息"污染"，这通常需要很长时间才能纠正。因此，模型可能会沉迷于实现不可能或不相关的目标。
如果其上下文的"目标"部分被污染，智能体会制定荒谬的策略，并重复行为以追求无法实现的目标。
上下文分心
上下文分心是当上下文变得太长以至于模型过度关注上下文，而忽略了它在训练期间学到的东西时。
随着智能体工作流程中上下文的增长——随着模型收集更多信息并建立历史——这种积累的上下文可能会变得分散注意力而不是有帮助。玩 Pokémon 的 Gemini 智能体清楚地展示了这个问题：
虽然 Gemini 2.5 Pro 支持 100 万+ Token 的上下文，但有效地将其用于智能体呈现了新的研究前沿。在这个智能体设置中，观察到当上下文显著增长超过 10 万 Token 时，智能体表现出倾向于偏爱从其大量历史中重复动作，而不是综合新计划。这种现象虽然是轶事，但突出了长上下文用于检索与长上下文用于多步骤生成推理之间的重要区别。
智能体没有使用其训练来开发新策略，而是沉迷于从其广泛的上下文历史中重复过去的动作。
对于较小的模型，分心上限要低得多。Databricks 的研究发现，Llama 3.1 405b 的模型正确性在 32k 左右开始下降，较小的模型更早。
如果模型在其上下文窗口填满之前很久就开始表现异常，那么超大上下文窗口的意义何在？简而言之：摘要³和事实检索。如果你不做这两件事中的任何一件，就要警惕你选择的模型的分心上限。
上下文混淆
上下文混淆是当上下文中的多余内容被模型用来生成低质量响应时。
有一段时间，看起来真的好像每个人都要推出 MCP。一个强大模型的梦想——连接到所有你的服务和东西，完成你所有的平凡任务——感觉触手可及。只需把所有工具描述扔进提示然后开始。Claude 的系统提示为我们指明了方向，因为它主要是工具定义或使用工具的指令。
但即使整合和竞争不会减缓 MCPs，上下文混淆也会。事实证明，工具太多可能真的是个问题。
伯克利函数调用排行榜是一个工具使用基准，评估模型有效使用工具来响应提示的能力。现在是第 3 版，排行榜显示每个模型在提供多个工具时表现都会变差⁴。此外，伯克利团队"设计了没有提供的函数相关的场景……我们期望模型的输出是不进行函数调用。"然而，所有模型都会偶尔调用不相关的工具。
浏览函数调用排行榜，你可以看到问题随着模型变小而变得更糟：
上下文混淆的一个惊人例子可以在最近的论文中看到，该论文评估了小模型在 GeoEngine 基准上的性能，该基准测试包含46 种不同工具。当团队给量化（压缩）的 Llama 3.1 8b 一个包含所有 46 种工具的查询时，它失败了，尽管上下文在 16k 上下文窗口范围内。但当他们只给模型 19 种工具时，它成功了。
问题是：如果你把某样东西放在上下文中，模型必须注意它。 它可能是不相关的信息或不必要的工具定义，但模型会考虑它。大型模型，特别是推理模型，在忽略或丢弃多余上下文方面变得更好，但我们不断看到毫无价值的信息绊倒智能体。更长的上下文让我们塞进更多信息，但这种能力伴随着缺点。
上下文冲突
上下文冲突是当你在上下文中积累与上下文中其他信息冲突的新信息和工具时。
这是上下文混淆的一个更有问题的版本：这里的坏上下文不是不相关的，而是直接与提示中的其他信息冲突。
微软和 Salesforce 团队在最近的论文中出色地记录了这一点。该团队从多个基准中提取提示，并将其信息"分片"到多个提示中。可以这样想：有时，你可能会坐下来在 ChatGPT 或 Claude 中输入几段文字，然后按回车，考虑每一个必要的细节。其他时候，你可能会从一个简单的提示开始，然后当聊天机器人的答案不令人满意时添加更多细节。微软/Salesforce 团队修改了基准提示，使其看起来像这些多步骤交流：
左侧提示的所有信息都包含在右侧的几条消息中，这些消息将在多个聊天轮次中播放。
分片提示产生了显著更差的结果，平均下降了 39%。团队测试了一系列模型——OpenAI 备受赞誉的 o3 的分数从 98.1 下降到 64.1。
发生了什么？为什么如果信息是分阶段收集的而不是一次性收集的，模型表现会更差？
答案是上下文混淆：包含整个聊天交流的组装上下文包含模型在拥有所有信息之前回答挑战的早期尝试。这些不正确的答案仍然存在于上下文中，并在模型生成最终答案时影响它。团队写道：
我们发现大语言模型通常在早期回合中做出假设并过早尝试生成最终解决方案，它们过度依赖这些解决方案。简而言之，我们发现当大语言模型在对话中走错路时，它们会迷失方向并且无法恢复。
这对智能体构建者来说不是好兆头。智能体从文档、工具调用以及负责子问题的其他模型组装上下文。所有这些从不同来源提取的上下文都有可能自相矛盾。此外，当你连接到你没有创建的 MCP 工具时，它们的描述和指令与你的提示其余部分冲突的机会更大。
百万 Token 上下文窗口的到来感觉具有变革性。将智能体可能需要的一切都扔进提示的能力激发了超级智能助手的愿景，这些助手可以访问任何文档、连接到每个工具，并保持完美的记忆。
但正如我们所见，更大的上下文会创造新的失效模式。上下文污染嵌入了随时间累积的错误。上下文分心导致智能体严重依赖其上下文并重复过去的动作而不是前进。上下文混淆导致不相关的工具或文档使用。上下文冲突创造了破坏推理的内部矛盾。
这些失效对智能体的打击最大，因为智能体恰好工作在上下文膨胀的场景中：从多个来源收集信息、进行顺序工具调用、参与多轮推理以及积累大量历史记录。
幸运的是，有解决方案！在即将发表的帖子中，我们将介绍缓解或避免这些问题的技术，从动态加载工具的方法到启动上下文隔离。
阅读后续文章，"如何修复你的上下文"
输入你的电子邮件以接收不定期更新。
- Gemini 2.5 和 GPT-4.1 有 100 万 Token 的上下文窗口，足够大到可以把《无尽的玩笑》放进去，还有足够的剩余空间。↩
- Gemini 文档中的"长格式文本"部分很好地总结了这种乐观主义。↩
- 事实上，在上面引用的 Databricks 研究中，模型在给定长上下文时失败的常见方式是它们返回所提供上下文的摘要，而忽略提示中包含的任何指令。↩
- 如果你在排行榜上，请注意"Live (AST)"列。这些指标使用企业为产品贡献的真实工具定义，"避免数据集污染和有偏见基准的缺点。"↩