Context Engineering

2025年8月12日

2 分钟阅读

#Context Engineering #LLM #AI

Context Engineering 是大型语言模型（LLM）应用中的系统性技术，旨在通过动态构建、管理和优化输入模型的信息负载（包括指令、记忆、工具输出、外部知识等），提升模型在复杂任务中的性能、稳定性和可靠性。

Context Engineering（上下文工程）是大型语言模型（LLM）应用中的系统性技术，旨在通过动态构建、管理和优化输入模型的信息负载（包括指令、记忆、工具输出、外部知识等），提升模型在复杂任务中的性能、稳定性和可靠性。以下是其核心内容的详细解析：

一、Context Engineering 的定义与背景

超越 Prompt Engineering
- Prompt Engineering：聚焦单次对话的指令设计（如“以专家身份生成报告”），适用于简单任务。
- Context Engineering：构建动态、结构化的上下文系统，整合多源信息（如历史对话、知识库、工具返回值），解决长期任务中的信息碎片化和遗忘问题。
- 核心目标：提供“足够且精确”的上下文，使任务对 LLM 可解（如员工绩效评估需注入目标、历史评价等数据）。
数学形式化框架
上下文被定义为动态组件集合：
$$C = \{c_1, c_2, …, c_n\}$$
其中 $c_i$ 代表指令、外部知识、记忆等组件，通过组装函数（如优先级排序）生成优化后的上下文。
优化目标为最大化任务收益：
$$\max_{\theta} \mathbb{E}{t \sim T}[R(C{\theta}, t)]$$
（$\theta$：上下文生成参数；$t$：任务实例）。

二、核心组件与技术机制

上下文构成要素

组件类型	功能	实例
系统指令	定义模型行为规则（如输出格式、角色设定）	代码生成需指定语言和规范
记忆系统	短期记忆（当前对话）与长期记忆（历史数据）	ChatGPT 跨会话记忆用户偏好
外部知识	实时检索增强（RAG）注入领域知识	法律助手检索案例库回答咨询
工具集成	调用 API 获取实时数据（天气、股票）	ReAct 框架实现“思考-行动-观察”循环
结构化标注	用显式格式与分区组织上下文（XML/JSON、Markdown 分隔符、字段语义、优先级）	结构化提示与输出 Schema 约束

关键技术方法

Retrieval-Augmented Generation (RAG)
动态检索外部知识，解决模型静态知识局限。例如：

1
2
3
4
class ContextualRAG:
    def engineer_context(self, query, user_profile):
        docs = vector_store.similarity_search(query, k=5)  # 检索相关文档
        return {"knowledge": docs, "user_profile": user_profile}  # 组装上下文

进阶：混合检索（BM25+向量）、多查询扩展（Multi-Query/HyDE）、候选去重与聚类、重排（如 bge/cohere reranker）。
排布与位置偏置：关注 “Lost in the Middle”，将关键证据置顶或靠近问题，按证据链排序，并保留近因优先。
溯源与归因：为每条片段保留 source/id，答案中引用 [n] 以便核验与评估。

上下文压缩与优化
因 Token 限制（如 GPT-4 Turbo 的 128K），需通过总结、修剪或聚类减少冗余信息。
例：Claude 在上下文达 95% 容量时自动压缩对话历史。
思维链（Chain-of-Thought）
分步推理提升逻辑性，数学任务准确率从 17.7% 升至 78.7%。

三、工程策略：五大核心方法

针对上下文过载问题，工业界采用四大策略：

策略	原理	应用场景
写入（Write）	将关键信息暂存外部存储（如数据库），按需调用	电商客服记录用户订单历史
选择（Select）	精准筛选相关信息（如工具描述、知识片段）	代码助手结合 AST 解析和知识图谱检索代码
压缩（Compress）	总结长文本或删除低价值内容	分层总结多轮对话核心要点
隔离（Isolate）	划分独立上下文区域（多智能体架构）	OpenAI Swarm 库分配子任务给专用 Agent
结构化（Structure）	用明确格式/分区与字段语义组织上下文与输出，增强解析与可控性	XML/JSON/Markdown 分区、字段优先级、输出 Schema/JSON Schema

结构化最小模板示例：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
{
  "role": "system",
  "policy": "风格/安全/禁忌",
  "task": "目标与成功标准",
  "context": {
    "question": "...",
    "retrieved_knowledge": [{"id": "...", "snippet": "...", "source": "..."}],
    "examples": [{"input": "...", "output": "..."}],
    "constraints": ["格式要求", "令牌上限", "工具可用性"]
  },
  "output_schema": {
    "type": "object",
    "properties": {
      "answer": {"type": "string"},
      "citations": {"type": "array", "items": {"type": "string"}}
    },
    "required": ["answer"]
  }
}

四、评估与度量

组件化评估
- 检索器（Retriever）：Recall@K、Precision@K、MRR、nDCG。
- 生成器（Generator）：忠实度/可溯源性（Faithfulness/Groundedness）、无幻觉率。
- 系统级：任务成功率、步骤/成本预算（Step/Cost Budget）。
自动化评估框架
- RAGAs、ARES、TruLens、G‑Eval 等基于 LLM‑as‑Judge 的评估工具。
- 结合对照集与规范化提示，控制评审偏置与方差。
基线流程
- 构建标注集 → 独立评估检索与生成 → 端到端评估 → 误差分解与回归修复。

五、实际应用与挑战

典型场景
- 客户支持：结合知识库、用户历史生成个性化响应。
- 代码助手：注入项目文档、Commit 历史提升代码建议准确性（如 Windsurf 工具）。
- 医疗诊断：多智能体协作整合患者记录、医学文献，生成诊断报告。
核心挑战
- 上下文污染（Poisoning）：幻觉内容误导后续决策。
- 长度限制：百万级 Token 处理成本过高（注意力机制 $O(n^2)$ 复杂度）。
- 评估困难：传统指标（BLEU）无法衡量推理链质量。
- 缓解策略（要点）：
  - 引用溯源（Attribution）：保留证据 source 与引用标记，答案与证据分离呈现。
  - 自我一致性与交叉验证：多样化解答取交集或投票，拒绝不一致结论。
  - 可信度与阈值：为证据和结论打分，设置最小可信阈值与回退策略。
  - 提示注入/越权防护：输入清洗、规则优先级、输出过滤与审计。
记忆与隐私策略
- 记忆分层：短期/长期/知识库三层；跨会话采用摘要蒸馏与合并。
- 生命周期：TTL、LRU/频次驱动回收、热点压缩与去冗余。
- 隐私合规：PII 识别与脱敏/加密、最小必要注入原则、会话域/任务域边界。
编排与成本
- 编排：图式/状态机（如 LangGraph/GraphRAG），中断恢复与幂等。
- 成本与延迟：提示/结果缓存、分层压缩、重排门槛、回退模型与步骤预算。

六、未来发展方向

理论突破：建立上下文组合的数学规范（如贝叶斯后验优化）。
技术演进：
- 长上下文处理（如 Mamba 模型的线性复杂度架构）。
- 多模态整合（图像、音频等非文本上下文）。
伦理与系统：设计内存隐私保护机制（如差分隐私）。

总结

Context Engineering 是 LLM 从“静态指令”迈向“动态感知”的核心范式，通过系统化构建上下文（指令、记忆、工具、知识），显著提升模型在复杂任务中的能力。其技术体系融合了 RAG、思维链、多智能体等前沿方法，但需进一步解决长文本处理、幻觉控制等挑战。随着自动化上下文生成（如 AutoPrompt）和新型架构的发展，该领域将持续推动 AI 应用的可靠落地。