【上下文工程经验】 如何修复您的上下文

https://www.dbreunig.com/2025/06/26/how-to-fix-your-context.html

如何修复您的上下文

缓解和避免上下文失败

接续我们之前的文章"长上下文如何失败"，让我们梳理一下可以缓解或完全避免这些失败的方法。

但在此之前，让我们简要回顾一下长上下文可能失败的几种方式：

  • 上下文污染： 当幻觉或其他错误进入上下文，并被反复引用时。
  • 上下文分心： 当上下文变得过长，模型过度关注上下文，忽略了训练期间学到的知识。
  • 上下文混淆： 当上下文中的多余信息被模型用来生成低质量响应时。
  • 上下文冲突： 当您在上下文中积累的新信息和工具与提示中的其他信息冲突时。

这里的一切都与信息管理有关。上下文中的每一项都会影响响应。我们又回到了古老的编程格言："垃圾进，垃圾出"。值得庆幸的是，有很多选项可以处理上述问题。

上下文管理策略

RAG

检索增强生成（RAG）是有选择地添加相关信息以帮助LLM生成更好响应的行为。

关于RAG已经写了太多，我们今天不会深入讨论，只是说：它仍然非常活跃。

每当模型提高上下文窗口的标准时，就会诞生新的"RAG已死"辩论。最近的重大事件是Llama 4 Scout以1000万token窗口登场。在那个规模下，真的很诱人地想："算了，全部扔进去"，然后收工。

但是，正如我们上次所说：如果您将上下文当作杂物抽屉，那些杂物会影响您的响应。如果您想了解更多，这里有一个看起来很棒的新课程。

工具装备

工具装备是仅选择相关工具定义添加到上下文中的行为。

"装备（loadout）"一词是游戏术语，指的是您在关卡、比赛或回合之前选择的特定能力、武器和装备组合。通常，您的装备是根据上下文量身定制的——角色、关卡、团队其余成员的构成，以及您自己的技能集。

在这里，我们借用这个术语来描述为给定任务选择最相关工具的行为。

选择工具的最简单方法可能是将RAG应用于您的工具描述。这正是甘天天和孙启尧所做的，他们在论文"RAG MCP"中详细说明了这一点。通过将工具描述存储在向量数据库中，他们能够根据输入提示选择最相关的工具。

在提示DeepSeek-v3时，团队发现当您拥有超过30个工具时，选择正确的工具变得至关重要。超过30个工具，工具的描述开始重叠，造成混淆。超过100个工具时，模型几乎肯定会在测试中失败。使用RAG技术选择少于30个工具可以显著缩短提示，并使工具选择准确性提高多达3倍。

对于较小的模型，问题在我们达到30个工具之前就开始出现。我们在上一篇文章中涉及的一篇论文"少即是多"表明，Llama 3.1 8b在给定46个工具时基准测试失败，但在只给定19个工具时成功。问题是上下文混淆，而不是上下文窗口限制。

为了解决这个问题，"少即是多"背后的团队开发了一种使用LLM驱动的工具推荐器动态选择工具的方法。LLM被提示推理"它'相信'需要回答用户查询的工具数量和类型"。然后对这个输出进行语义搜索（再次使用工具RAG）以确定最终装备。他们使用伯克利函数调用排行榜测试了这种方法，发现Llama 3.1 8b的性能提高了44%。

"少即是多"论文指出较小上下文的另外两个好处：减少能耗和提高速度，这是在边缘操作时的关键指标（意思是在您的手机或PC上运行LLM，而不是在专用服务器上）。即使他们的动态工具选择方法未能改善模型的结果，能耗节省和速度提升也是值得的，分别获得了18%和77%的节省。

值得庆幸的是，大多数智能体的功能范围较小，只需要少数几个精心策划的工具。但如果功能的广度或集成数量需要扩展，请始终考虑您的装备。

上下文隔离

上下文隔离是将上下文隔离在各自专用线程中的行为，每个线程由一个或多个LLM单独使用。

当我们的上下文不太长且不包含无关内容时，我们会看到更好的结果。实现这一点的一种方法是将任务分解为更小的、隔离的作业——每个作业都有自己的上下文。

有许多例子展示了这种策略，但这种策略的一个易懂的写法是Anthropic的详述其多智能体研究系统的博客文章。他们写道：

搜索的本质是压缩：从庞大的语料库中提炼见解。子智能体通过在各自的上下文窗口中并行操作来促进压缩，在为主要研究智能体压缩最重要的token之前，同时探索问题的不同方面。每个子智能体还提供关注点分离——不同的工具、提示和探索轨迹——这减少了路径依赖并能够进行彻底、独立的调查。

研究适合这种设计模式。当给出一个问题时，可以识别几个子问题或探索领域，并使用多个智能体分别进行提示。这不仅加快了信息收集和提炼（如果有可用的计算资源），而且防止每个上下文积累过多信息或与给定提示无关的信息，从而提供更高质量的结果：

我们的内部评估显示，多智能体研究系统特别擅长需要同时追求多个独立方向的广度优先查询。我们发现，以Claude Opus 4作为主智能体、Claude Sonnet 4作为子智能体的多智能体系统在我们的内部研究评估中比单智能体Claude Opus 4的表现好90.2%。例如，当被要求识别信息技术标普500公司的所有董事会成员时，多智能体系统通过将此分解为子智能体的任务找到了正确答案，而单智能体系统在缓慢的顺序搜索中未能找到答案。

这种方法也有助于工具装备，因为智能体设计者可以创建几个智能体原型，每个原型都有自己专用的装备和如何使用每个工具的指令。

那么，智能体构建者面临的挑战是找到将孤立任务分拆到单独线程的机会。需要在多个智能体之间共享上下文的问题不太适合这种策略。

如果您的智能体领域适合并行化，请务必阅读整个Anthropic的写法。它非常出色。

上下文修剪

上下文修剪是从上下文中删除无关或其他不需要信息的行为。

智能体在启用工具和组装文档时会积累上下文。有时，值得暂停以评估已组装的内容并删除废料。这可能是您让主LLM处理的事情，或者您可以设计一个单独的LLM驱动工具来审查和编辑上下文。或者您可以选择更适合修剪任务的东西。

上下文修剪有（相对）悠久的历史，因为在ChatGPT之前，上下文长度在自然语言处理（NLP）领域是一个更有问题的瓶颈。基于这一历史的当前修剪方法是Provence，"一个用于问答的高效且鲁棒的上下文修剪器"。

Provence快速、准确、易于使用且相对较小——只有1.75 GB。您可以用几行代码调用它，如下所示：

from transformers import AutoModel

provence = AutoModel.from_pretrained("naver/provence-reranker-debertav3-v1", trust_remote_code=True)

# 读入阿拉米达，加州维基百科条目的markdown版本
with open('alameda_wiki.md', 'r', encoding='utf-8') as f:
    alameda_wiki = f.read()

# 根据问题修剪文章
question = '离开阿拉米达我有什么选择？'
provence_output = provence.process(question, alameda_wiki)

Provence编辑了文章，删减了95%的内容，只给我留下了这个相关子集。它做得很好。

人们可以使用Provence或类似功能来筛选文档或整个上下文。此外，这种模式强烈支持在字典或其他形式中维护上下文的结构化1版本，从中您可以在每次LLM调用之前组装编译字符串。这种结构在修剪时会派上用场，允许您确保保留主要指令和目标，同时可以修剪或总结文档或历史部分。

上下文总结

上下文总结是将积累的上下文归纳为浓缩摘要的行为。

上下文总结最初出现是为了处理较小的上下文窗口。当您的聊天会话接近超过最大上下文长度时，会生成摘要并开始新线程。聊天机器人用户在ChatGPT或Claude中手动执行此操作，要求机器人生成简短回顾，然后将其粘贴到新会话中。

然而，随着上下文窗口的增加，智能体构建者发现总结除了保持在总上下文限制内之外还有好处。随着上下文的增长，它变得令人分心，并导致模型较少依赖训练期间学到的知识。我们称之为上下文分心。玩宝可梦的Gemini智能体背后的团队发现超过100,000个token的任何内容都会触发这种行为：

虽然Gemini 2.5 Pro支持1M+token上下文，但为智能体有效利用它呈现了一个新的研究前沿。在这种智能体设置中，观察到随着上下文显著超过100k token，智能体表现出倾向于重复其庞大历史中的动作，而不是合成新颖计划的趋势。这种现象虽然是轶事性的，但突出了检索的长上下文和多步骤生成推理的长上下文之间的重要区别。

总结您的上下文很容易做到，但对于任何给定的智能体来说都很难完美。知道应该保留什么信息，并向LLM驱动的压缩步骤详细说明这一点，对智能体构建者至关重要。值得将此功能分解为自己的LLM驱动阶段或应用程序，这允许您收集可以直接通知和优化此任务的评估数据。

上下文卸载

上下文卸载是将信息存储在LLM上下文之外的行为，通常通过存储和管理数据的工具。

这可能是我最喜欢的策略，仅仅因为它如此简单，您不相信它会起作用。

再次，Anthropic有这种技术的很好写法，详述了他们的"think"工具，基本上就是一个草稿板：

通过"think"工具，我们给Claude提供了包含额外思考步骤的能力——具有自己的指定空间——作为获得最终答案的一部分...这在执行长工具调用链或与用户进行长多步对话时特别有用。

我真的很欣赏Anthropic发布的研究和其他写作，但我不喜欢这个工具的名称。如果这个工具被称为scratchpad，您会立即知道它的功能。它是模型写下不会污染其上下文、可供以后参考的笔记的地方。"think"这个名字与"扩展思考"冲突，并且不必要地将模型拟人化...但我跑题了。

有一个记录笔记和进度的空间有效。Anthropic显示将"think"工具与特定领域提示（您在智能体中无论如何都会这样做）配对产生显著收益，针对专业智能体的基准提高多达54%。

Anthropic确定了上下文卸载模式有用的三种场景：

  1. 工具输出分析。当Claude需要在行动前仔细处理先前工具调用的输出，并可能需要在其方法中回溯时；
  2. 政策密集环境。当Claude需要遵循详细指导原则并验证合规性时；以及
  3. 顺序决策制定。当每个动作都建立在先前动作之上且错误代价高昂时（通常在多步骤领域中发现）。

上下文管理通常是构建智能体最难的部分。编程LLM，正如Karpathy所说，"恰到好处地打包上下文窗口"，智能地部署工具、信息和常规上下文维护是智能体设计者的工作。

所有上述策略的关键见解是上下文不是免费的。上下文中的每个token都会影响模型的行为，无论好坏。现代LLM的庞大上下文窗口是一种强大的能力，但它们不是信息管理马虎的借口。

当您构建下一个智能体或优化现有智能体时，问问自己：这个上下文中的一切都在发挥作用吗？如果没有，您现在有六种方法来修复它。

posted @ 2025-08-18 10:25  一介布衣、  阅读(100)  评论(0)    收藏  举报