解决大模型上下文衰减的6种方案，附详细代码

在构建基于大模型的 AI 应用的过程中，多轮对话或输入内容过长往往会让模型的回答质量下降，这是开发者们普遍头疼的难题。

LangChain 团队提出了6 种可行的解决方案，帮助模型在复杂场景下依然保持稳定而高质量的输出。这些方法基于 LangGraph 框架，涵盖信息检索、智能筛选、上下文隔离等关键技术点，并为每种思路配备了详细的代码示例与性能对比。

可以关注公众号#极客开源👆 获取最新一手#AI大模型#开源项目信息，如果这篇文章对你有用，可以点个“推荐”，听说会影响公众号的#推荐算法。

上下文衰减问题

Chroma 开发团队对 18 个模型做了上下文衰减评估，结果发现随着输入长度的增长，即使在非常简单的任务上模型的表现也会下降，这解释了为什么说：LLM 并不是平等的对待上下文窗口中的每个 Token。

上下文失效可以总结成这 4 种模型：

1. 上下文污染- 进入上下文的幻觉或错误被反复引用。

2. 上下文分散- 当上下文变得如此庞大，以至于模型更多地关注累积的历史而非训练内容。

3. 上下文混乱- 多余的内容影响响应质量，因为模型感觉有义务使用所有可用的上下文。

4. 上下文冲突- 累积上下文中的冲突信息降低推理能力。

上下文工程解决思路

Drew 总结出了 6 种上下文工程技术方案来帮助修复这些失败模式，包括：

1. RAG（检索增强生成）

2. 工具配置

3. 上下文隔离

4. 上下文修剪

5. 上下文摘要

6. 上下文卸载

LangChain 团队基于Drew 的思路，在一系列 Jupyter 笔记本中使用 LangGraph 实现了每种技术，如下所述。

快速开始

1. 前提条件：Python 3.9或更高版本，uv 包管理器

2. 克隆仓库并激活虚拟环境：

gitclonehttps://github.com/langchain-ai/how_to_fix_your_contextcdhow_to_fix_your_contextuvvenvsource.venv/bin/activate#Windows系统：.venv\Scripts\activate

3. 安装依赖

uvpipinstall-rrequirements.txt

4. 使用模型提供商设置环境变量

exportOPENAI_API_KEY="your-openai-api-key"exportANTHROPIC_API_KEY="your-anthropic-api-key"

1. RAG（检索增强生成）

笔记本：github.com/langchain-ai/how_to_fix_your_context/blob/main/notebooks/01-rag.ipynb

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

实现：使用 LangGraph 创建 RAG 代理，其检索工具基于 Lilian Weng 的博客文章构建。代理使用 Claude Sonnet 在回答问题前智能搜索相关上下文。

关键组件：

使用 RecursiveCharacterTextSplitter 进行文档加载和分块

使用 OpenAI 嵌入创建向量存储

带有工具调用条件边的 LangGraph StateGraph

指导代理在检索前明确研究范围的系统提示

性能：对于关于奖励破解类型的复杂查询，使用了 25k 个标记，由于标记密集的工具调用而驱动。

2. 工具配置

笔记本：github.com/langchain-ai/how_to_fix_your_context/blob/main/notebooks/02-tool-loadout.ipynb

工具配置是选择只将相关的工具定义添加到你的上下文中的行为。

实现：通过在向量存储中索引所有 Python 数学库函数并根据用户查询动态选择相关工具来演示语义工具选择。

关键组件：

所有数学函数的 UUID 映射工具注册表

使用嵌入对工具描述进行向量存储索引

基于语义相似性搜索的动态工具绑定（限制 5 个工具）

扩展状态类来跟踪每次对话选择的工具

好处：避免重叠工具描述的上下文混乱，与加载所有可用工具相比提高工具选择准确性。

3. 上下文隔离

笔记本：github.com/langchain-ai/how_to_fix_your_context/blob/main/notebooks/03-context-quarantine.ipynb

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

实现：使用 LangGraph 监督器架构创建监督器多代理系统，具有拥有隔离上下文窗口的专业代理。

关键组件：

将任务路由到适当专家的监督器代理

具有加法/乘法工具和专注数学提示的数学专家代理

具有网络搜索能力和研究专注提示的研究专家代理

基于任务类型的清晰委托规则（研究 vs 计算）

好处：每个代理在自己的上下文窗口中操作，防止上下文冲突和分散注意力。监督器使用基于工具的切换为需要多种技能的复杂任务协调代理。

4. 上下文修剪

笔记本：github.com/langchain-ai/how_to_fix_your_context/blob/main/notebooks/04-context-pruning.ipynb

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

实现：通过智能修剪步骤扩展 RAG 代理，在将检索到的文档传递给主 LLM 之前删除不相关内容。

关键组件：

指导较小 LLM 仅提取相关信息的工具修剪提示

GPT-4o-mini 作为修剪模型以降低成本

带有摘要字段的扩展状态类用于上下文压缩

基于原始用户请求的修剪以保持相关性

性能改进：与基本 RAG 相比，同一查询的标记使用量从 25k 减少到 11k，展示了在保持答案质量的同时显著的上下文压缩。

5. 上下文摘要

笔记本：github.com/langchain-ai/how_to_fix_your_context/blob/main/notebooks/05-context-summarization.ipynb

上下文摘要是将累积的上下文浓缩成精简摘要的行为。

实现：通过添加摘要步骤构建 RAG 代理，压缩工具调用结果以减少上下文大小同时保留基本信息。

关键组件：

创建文档全面而简洁版本的工具摘要提示

GPT-4o-mini 作为摘要模型以提高成本效率

在消除冗余的同时保留所有关键信息的指导原则（50-70% 缩减目标）

带有摘要字段的扩展状态类用于跟踪压缩内容

方法：与删除不相关内容的修剪不同，摘要将所有信息压缩成更紧凑的格式，适用于所有检索内容都相关但冗长的情况。

6. 上下文卸载

笔记本：github.com/langchain-ai/how_to_fix_your_context/blob/main/notebooks/06-context-offloading.ipynb

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

实现：演示了两种上下文卸载方法——会话期间的临时暂存区存储和使用 LangGraph 存储接口的持久跨线程内存。

关键组件：

带有暂存区字段的扩展状态类用于临时存储

WriteToScratchpad 和 ReadFromScratchpad 工具用于记笔记

InMemoryStore 用于持久跨线程内存

维护有组织笔记并基于先前研究构建的研究工作流

两种存储模式：

1. 会话暂存区：单个对话线程内的临时存储。

2. 持久内存：使用命名空间键值对进行跨线程存储，在不同对话会话中持续存在。

好处：使代理能够维护研究计划、积累发现并跨多次交互访问先前工作，类似于 Anthropic 的多代理研究员和 ChatGPT 等产品实现内存的方式。