A Survey of Context Engineering for Large Language Models: 上下文工程全景综述

Posted on

A Survey of Context Engineering for Large Language Models: 上下文工程全景综述

ArXiv ID: 2507.13334
作者: Lingrui Mei, Jiayu Yao, Yuyao Ge, Yiwei Wang, Baolong Bi, Yujun Cai, Jiazhi Liu, Mingyu Li, Zhong-Zhi Li, Duzhen Zhang, Chenlin Zhou, Jiayi Mao, Tianze Xia, Jiafeng Guo, Shenghua Liu (15位作者)
发布日期: 2025年7月17日 (最后更新: 2025年7月21日)
分类: Context Engineering
论文规模: 分析了超过1400篇研究论文

论文摘要

这是上下文工程(Context Engineering)领域的首个系统性综述，将上下文工程定义为一门正式学科，超越简单的提示设计，涵盖了为LLM系统性优化信息载荷的完整方法论。

核心观点: LLM的性能从根本上由推理时提供的上下文信息决定。因此，上下文工程不仅是提示工程的延伸，更是构建高性能LLM系统的基础设施学科。

综述范围:

  • 基础组件: 上下文检索、生成、处理、管理
  • 系统集成: RAG、记忆系统、工具增强、多Agent系统
  • 前沿方向: 长上下文优化、多模态上下文、动态上下文适配

通过对1400+论文的系统性分析，本文为该领域提供了全面的技术路线图。

核心框架: 上下文工程四大支柱

1. 上下文检索 (Context Retrieval)

定义: 从外部知识源中提取与查询相关的信息

1.1 检索技术分类

稀疏检索 (Sparse Retrieval):

  • 代表方法: BM25, TF-IDF
  • 优势: 高效、可解释
  • 劣势: 无法捕捉语义相似性
  • 适用场景: 关键词精确匹配、大规模初筛

密集检索 (Dense Retrieval):

  • 代表方法: DPR, ColBERT, ANCE
  • 核心技术: 双编码器架构(Query Encoder + Document Encoder)
  • 优势: 语义理解能力强
  • 劣势: 计算开销大
  • 适用场景: 语义相似性搜索、跨语言检索

混合检索 (Hybrid Retrieval):

  • 策略: 结合稀疏和密集方法，取长补短
  • 典型方案: BM25初筛 + DPR重排
  • 效果提升: 相比单一方法，F1提升10-15%

1.2 高级检索范式

迭代检索 (Iterative Retrieval):

1
Query → 初次检索 → 生成中间答案 → 扩展查询 → 再次检索 → 最终答案
  • 应用: 多跳问答(如”谁发明了TCP/IP的导师是谁?”)
  • 挑战: 控制迭代次数，避免检索漂移

自适应检索 (Adaptive Retrieval):

  • 核心思想: LLM自主决定何时检索、检索什么
  • 典型方法: Self-RAG, FLARE
  • 关键技术: 检索触发器(Retrieval Trigger)，判断当前生成是否需要外部知识

2. 上下文生成 (Context Generation)

定义: 合成新的上下文信息，而非检索现有知识

2.1 生成策略

查询重写 (Query Rewriting):

  • 目标: 将模糊查询转换为更精确的检索查询
  • 方法:
    • HyDE: 先生成假设性文档，再用该文档检索
    • Query2Doc: 用LLM扩展查询为伪文档

示例增强 (Example Augmentation):

  • Few-shot Synthesis: LLM生成类似的示例
  • 应用: 少样本学习场景，缓解标注数据不足

知识蒸馏 (Knowledge Distillation):

  • 目标: 从大模型提取知识，注入小模型的上下文
  • 方法: 用大模型生成推理链，作为小模型的上下文

3. 上下文处理 (Context Processing)

定义: 优化上下文的结构和内容，提升LLM的理解和利用效率

3.1 上下文压缩

动机: LLM的上下文窗口有限(如4K, 8K tokens)，但检索到的文档可能非常大

压缩技术:

抽取式压缩 (Extractive Compression):

  • 方法: 选择最重要的句子/段落
  • 指标: 重要性打分(基于相关性、新颖性)
  • 工具: LLMLingua, Selective Context

生成式压缩 (Abstractive Compression):

  • 方法: 重写为更简洁的摘要
  • 风险: 可能丢失细节信息
  • 平衡策略: 保留关键数字、实体、日期

Token-level压缩:

  • 极端压缩: GIST Tokens, AutoCompressor
  • 原理: 将长文本压缩为特殊的”记忆token”
  • 压缩比: 高达10:1

3.2 上下文重排序

问题: “Lost in the Middle”现象——LLM对上下文开头和结尾的信息敏感，中间部分容易被忽略

解决方案:

  • 重要性排序: 将最相关的信息放在开头或结尾
  • 交错排序: 交替放置高/低相关度内容
  • 注意力引导: 在上下文中插入强调标记(如”重点:”、”关键信息:”)

4. 上下文管理 (Context Management)

定义: 在长对话或多轮交互中，维护和更新上下文

4.1 记忆机制

短期记忆 (Short-term Memory):

  • 实现: 直接保留最近N轮对话
  • 缺点: 上下文窗口耗尽时，旧信息丢失

长期记忆 (Long-term Memory):

  • 存储: 外部数据库(向量数据库、图数据库)
  • 检索: 根据相关性动态加载到上下文
  • 代表系统: MemGPT, Generative Agents

层级记忆 (Hierarchical Memory):

  • 结构: 工作记忆(当前任务) → 情景记忆(历史对话) → 语义记忆(长期知识)
  • 灵感: 模仿人类记忆系统

4.2 上下文更新策略

滑动窗口 (Sliding Window):

  • 保留最近K个token，丢弃更早的内容
  • 简单高效，但可能丢失重要历史信息

压缩历史 (Compressed History):

  • 将旧对话压缩为摘要，保留在上下文中
  • 例如: “在前面的对话中，用户提到了X和Y…”

选择性保留 (Selective Retention):

  • 基于重要性评分，保留关键信息，丢弃冗余内容
  • 需要额外的LLM调用来评估重要性

系统架构: 四大应用范式

范式1: 检索增强生成 (RAG)

架构:

1
查询 → 检索器 → 相关文档 → 拼接到上下文 → LLM生成

关键技术:

  • 索引优化: 分块策略(Chunking)、向量化(Embedding)
  • 检索优化: 查询重写、混合检索、重排序
  • 生成优化: 引用标注、幻觉检测

前沿变体:

  • Self-RAG: LLM自主决定是否检索
  • CRAG: 纠正式RAG，先评估检索质量，必要时重新检索
  • GraphRAG: 基于知识图谱的结构化检索

范式2: 记忆系统 (Memory Systems)

架构:

1
用户输入 → 记忆检索 → 相关历史 → 当前上下文 → LLM → 更新记忆

典型系统:

MemGPT:

  • 模拟操作系统的虚拟内存管理
  • 主动在主记忆(上下文)和外部存储间swap内容

Generative Agents (斯坦福小镇):

  • 每个Agent维护独立的记忆流
  • 支持检索、反思、规划

Reflexion:

  • 从失败中学习，将经验教训写入长期记忆
  • 下次遇到类似任务时调用

范式3: 工具增强推理 (Tool-Augmented Reasoning)

核心思想: 将外部工具(API、代码执行器、搜索引擎)视为扩展上下文的手段

架构:

1
查询 → LLM规划 → 调用工具 → 结果作为上下文 → 继续推理

典型方法:

ReAct (Reasoning + Acting):

  • 交替进行推理和行动
  • 示例: “思考: 需要查询天气 → 行动: search(‘北京天气’) → 观察: 结果是晴天 → 思考: 可以推荐户外活动”

Toolformer:

  • 自监督学习何时、如何调用工具
  • 训练数据: 自动生成工具调用标注

ART (Automatic Reasoning and Tool-use):

  • 从任务库中检索类似任务的工具使用模式
  • 迁移到新任务

范式4: 多Agent系统 (Multi-Agent Systems)

挑战: 每个Agent有独立的上下文窗口，如何协调?

上下文共享策略:

广播模式 (Broadcast):

  • 所有Agent共享同一个全局上下文
  • 缺点: 上下文窗口快速耗尽

隔离模式 (Isolation):

  • 每个Agent维护独立上下文
  • 通过消息传递交换信息
  • 优点: 可扩展性强

层级模式 (Hierarchical):

  • Manager Agent维护全局上下文
  • Worker Agent维护局部上下文
  • Manager负责任务分配和结果聚合

代表系统:

  • AutoGPT: 单Agent + 工具调用
  • MetaGPT: 多Agent角色扮演(产品经理、工程师、测试…)
  • ChatDev: 软件开发多Agent协作

技术深度对比

RAG vs Fine-tuning: 何时选择哪个?

维度 RAG Fine-tuning
知识更新 实时(更新数据库即可) 慢(需重新训练)
成本 低(仅推理成本) 高(需GPU训练)
可解释性 强(可追溯到源文档) 弱(知识融入参数)
准确性 取决于检索质量 取决于训练数据
适用场景 知识密集型任务 风格适配、领域泛化

最佳实践: 结合使用——Fine-tuning提升模型理解能力,RAG注入最新知识

长上下文模型 vs 上下文工程: 是对立还是互补?

长上下文模型 (如GPT-4 128K, Claude 200K):

  • 优势: 可以”暴力”塞入所有信息
  • 劣势:
    • 成本高(按token计费)
    • 仍存在”Lost in the Middle”问题
    • 推理速度慢

上下文工程:

  • 优势: 精准、高效、可控
  • 劣势: 需要额外设计检索和压缩策略

结论: 互补关系——长上下文提供基础能力,上下文工程提升效率和质量

前沿研究方向

1. 上下文意识的模型训练

问题: 当前LLM训练时未明确建模上下文利用

方向:

  • 上下文敏感训练: 在预训练阶段引入上下文检索任务
  • 上下文对比学习: 学习区分有用和无用的上下文

2. 自适应上下文预算分配

问题: 不同任务需要不同长度的上下文，如何动态分配?

方向:

  • 强化学习: 以任务性能为奖励,学习最优上下文长度
  • 元学习: 快速适应新任务的上下文需求

3. 多模态上下文融合

挑战: 如何统一处理文本、图像、音频、视频上下文?

方向:

  • 统一编码器: 将所有模态映射到同一表示空间
  • 跨模态检索: 文本查询检索图像上下文

4. 隐私保护的上下文工程

问题: 外部检索可能泄露用户隐私

方向:

  • 联邦检索: 在本地设备上检索,不上传查询
  • 差分隐私: 对检索结果添加噪声

5. 上下文工程的自动化

愿景: 从手动设计上下文策略→ AI自动优化

代表工作:

  • DSPy: 声明式编程框架,自动优化提示和上下文
  • ACE: 自进化上下文工程(见相关论文)

评估与基准

关键评估指标

效果指标:

  • 准确性: 最终答案的正确率
  • 相关性: 检索上下文与查询的匹配度
  • 完整性: 是否包含回答问题的充分信息
  • 一致性: 多次检索的稳定性

效率指标:

  • 延迟: 检索+生成的总时间
  • 成本: Token消耗、API调用次数
  • 吞吐量: QPS (Queries Per Second)

代表性Benchmark

Benchmark 任务类型 规模 特点
NaturalQuestions 问答 300K 基于真实Google搜索
HotpotQA 多跳推理 113K 需要组合多个文档
KILT 知识密集型任务 11个子任务 统一评估框架
LongBench 长文本理解 21个任务 评估长上下文能力
MTEB 检索 56个数据集 多语言、多任务

实战建议

构建RAG系统的最佳实践

1. 数据准备阶段

文档分块策略:

1
2
3
4
5
# 不推荐: 固定长度分块(可能割裂语义)
chunks = split_by_length(doc, chunk_size=512)

# 推荐: 语义分块
chunks = split_by_semantics(doc, method="sentence_bert")

元数据管理:

1
2
3
4
5
6
7
8
9
10
{
  "content": "文档内容...",
  "metadata": {
    "source": "arxiv:2507.13334",
    "title": "Context Engineering Survey",
    "date": "2025-07-17",
    "section": "Introduction",
    "importance_score": 0.92
  }
}

2. 检索优化

混合检索实现:

1
2
3
4
5
# 第一阶段: BM25粗筛(快速过滤)
候选文档 = bm25_search(query, top_k=100)

# 第二阶段: 密集检索重排(精准匹配)
最终文档 = dense_rerank(query, 候选文档, top_k=5)

查询增强:

1
2
3
4
5
6
7
8
9
10
# 原始查询
query = "什么是上下文工程?"

# HyDE增强: 先生成假设答案
hypothetical_answer = llm.generate(
    f"请详细回答: {query}"
)

# 用假设答案检索(往往更准确)
docs = retriever.search(hypothetical_answer)

3. 上下文组织

推荐模板:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
[系统指令]
你是一个专业的AI助手,请基于以下上下文回答问题。

[检索上下文]
--- 文档1 (相关度: 0.95) ---
{doc1_content}

--- 文档2 (相关度: 0.87) ---
{doc2_content}

[重要提示]
- 优先使用上下文中的信息
- 如果上下文不足,明确说明
- 标注信息来源(如"根据文档1...")

[用户问题]
{user_query}

工具选型指南

组件 推荐工具 适用场景
向量数据库 Pinecone, Weaviate, Qdrant 密集检索
图数据库 Neo4j, ArangoDB GraphRAG
RAG框架 LangChain, LlamaIndex 快速原型
检索模型 OpenAI Ada, Cohere Embed 通用检索
重排序 Cohere Rerank, BGE Reranker 精准排序

个人评价

综述质量 (5/5)

这是一篇里程碑级别的综述:

全面性: 覆盖1400+论文,几乎涵盖了该领域的所有重要工作

结构化: 将分散的研究统一到”检索-生成-处理-管理”的清晰框架

前瞻性: 不仅总结现有工作,还指出了明确的未来方向

实用价值 (4.5/5)

对研究者:

  • 快速了解领域全貌,找到研究切入点
  • 识别未被充分探索的方向

对工程师:

  • 技术选型参考(RAG vs 记忆系统?)
  • 最佳实践指导

对产品经理:

  • 理解上下文工程的能力边界
  • 评估不同方案的成本效益

不足之处

  1. 缺乏代码示例: 作为综述,未提供可运行的代码(这是合理的,但降低了工程友好度)
  2. 评估对比不足: 不同方法的性能对比较少(可能受限于Benchmark不统一)
  3. 成本分析缺失: 未深入讨论不同技术的成本(Token、计算、存储)

总评分: 4.8/5.0

分类置信度: Very High (99%) - Context Engineering

推荐阅读优先级: ⭐⭐⭐⭐⭐ (最高优先级)

适合人群:

  • 必读: 所有从事RAG、Agent系统开发的工程师和研究者
  • 推荐: 对LLM系统优化感兴趣的产品经理和架构师
  • 延伸: 对提示工程感兴趣的初学者(虽然本文偏学术,但提供了很好的知识框架)

延伸阅读:

使用建议:

  • 作为知识地图: 遇到上下文相关问题时,查阅对应章节
  • 作为文献入口: 论文引用了大量参考文献,可按需深入
  • 作为技术选型指南: 对比不同方法的优劣,选择适合自己场景的技术栈
© 2026 Generative AI Discovery All Rights Reserved.
Theme by hiero