Foundations of Model Context Engineering / 模型上下文工程基础

第 1 章：模型上下文工程基础 / Foundations of Model Context Engineering

---

什么是上下文，为什么它决定了 AI 应用的上限

当我们向一个大型语言模型（Large Language Model, LLM）提出问题，模型给出的回答质量不仅取决于模型本身的参数——那些通过海量文本训练习得的“知识”——更取决于我们在那一刻向它传递了什么信息。这段信息，就是上下文（Context）。

上下文是 LLM 推理过程中的“工作记忆”。它决定了模型能够“看见”什么、“想起”什么、在当前任务中能够“利用”什么。无论是最简单的问答系统，还是最复杂的智能助手，上下文管理的方式直接决定了应用效果的天花板。

然而，上下文管理长期以来被视为“调 Prompt”的技巧，而非一门工程学科。直到 LLM 的上下文窗口从 4,096 token 扩展到百万量级，直到 RAG（检索增强生成）系统需要协调海量文档与模型交互，直到多轮对话需要精确维护状态——上下文管理的问题才真正浮出水面：它不再是一个 trick，而是一个系统性问题，需要系统性的解决框架。

本书的第一章，旨在建立这个框架的认知基础。我们将回答三个根本问题：第一，什么是 LLM 范式下的上下文，它与模型参数有什么关系？第二，上下文工程面临的核心挑战是什么，可以用什么样的统一视角来分解这些问题？第三，为什么现在——而不是五年前或十年后——上下文工程成为了一门必须掌握的学科？

这三个问题构成了理解本书其余十四章的认知基座。无论你是构建对话系统、设计知识库应用，还是在研究下一代 AI 架构，第一章的框架都将帮助你更清晰地定位问题、选择方案、评估权衡。

---

1.1 参数化记忆与非参数化上下文：理解 LLM 知识的两极

The Two Poles of LLM Knowledge: Parametric vs. Non-parametric Memory

要理解上下文工程的意义，首先要理解 LLM 的知识究竟存储在哪里、是如何被调用的。

LLM 的知识存在于两个截然不同的位置：参数化记忆（Parametric Memory）和非参数化上下文（Non-parametric Context）。

参数化记忆是模型在训练阶段习得并编码在神经网络权重中的知识。当我们说一个模型“知道”牛顿定律、“了解”某位作家的生平、“掌握” Python 语法时，指的正是这些存储在参数中的知识。参数化记忆的特点是：它是隐式的、分布式的、与权重融为一体的。我们无法直接读取某个参数来表示“模型知道 X”；知识是通过无数参数的协同作用涌现出来的。

参数化记忆的优势在于：它高度凝练——数十亿参数可以编码人类知识的广阔图景；它高度泛化——模型能够将训练中习得的模式迁移到未见过的情境。然而，参数化记忆也有根本性的局限：它不可直接编辑、不可精确查询、不可避免地包含过时或错误的信息。当你想让模型“只使用最新发布的产品文档”来回答问题时，参数化记忆帮不了你；当你想让模型“忽略它在训练数据中学到的错误观点”时，参数化记忆同样无能为力。

非参数化上下文则完全不同。它是在模型推理时显式提供给模型的信息——你写在 prompt 中的文字、从外部检索回来的文档、对话历史中的消息、用户上传的文件。非参数化上下文的特点是：它是显式的、可控的、临时的。你可以随时修改、替换、补充；它不会影响模型权重，只是当前推理的输入。

非参数化上下文解决了参数化记忆的核心痛点：

• 它可以**提供实时信息**，比如今天的天气、刚发布的财报；
• 它可以**覆盖模型的错误知识**，因为模型更倾向于使用上下文中的信息；
• 它可以**注入领域特定的专有知识**，而不需要重新训练模型；
• 它可以**实现精确的记忆和状态追踪**，通过上下文窗口传递。

然而，非参数化上下文也有自己的代价：它消耗 token，而 token 是有成本的；它受限于上下文窗口大小，而窗口再大也是有限的；它需要从外部获取，而检索本身可能引入噪声和错误。

The Complementarity Principle / 互补性原则

理解参数化记忆与非参数化上下文的关键，不在于判断哪个更重要，而在于认识它们的互补性。

一个有效的 LLM 应用，本质上是在设计一个信息路由与合成系统：哪些知识应该从参数中召回，哪些知识应该从上下文中提供，哪些知识需要两者协同。理想情况下，模型应该像一位博学的专家，不仅依靠记忆工作，更能快速查阅参考资料、接受新信息、与用户共同思考。

这种互补性在实践中表现为一个经典问题：模型什么时候用内部知识，什么时候用外部信息？ 大量研究表明，LLM 存在“上下文幻觉”问题——它可能忽视上下文中的关键信息，转而依赖参数中存储的知识；它也可能过度依赖上下文，在上下文与参数知识冲突时产生混乱。上下文工程的核心任务之一，正是设计机制来引导模型正确地在两者之间切换。

一个直观的类比是人类的认知过程：我们既依靠长期记忆（参数化记忆）来快速反应，也依靠工作记忆（上下文）和外部笔记（非参数化检索）来处理复杂任务。LLM 应用的设计，就是为模型构建类似的认知支持系统。

---

1.2 四操作框架：分解上下文工程问题的方法论

The Four Fundamental Operations: A Unifying Framework

上下文工程（Model Context Engineering）作为一门学科，其核心挑战可以用一个统一的框架来描述：任何上下文相关的问题，都可以分解为四种基本操作的某种组合：

1. 选择（Selection）：从大量可用信息中挑选最相关的内容进入上下文 2. 压缩（Compression）：将信息提炼为更紧凑的表示，减少 token 消耗 3. 转换（Transformation）：改变信息的形态，使其更适合模型处理 4. 维护（Maintenance）：在多轮交互或长时间运行中保持上下文的状态一致性

这四种操作不是彼此独立的，而是形成一个数据处理流水线（pipeline），共同决定上下文的质量。以下是该框架的流程图：

```mermaid flowchart TD A[原始信息源] --> B[选择 Selection] B --> C[压缩 Compression] C --> D[转换 Transformation] D --> E[上下文窗口 Context Window] E --> F[LLM 推理] F --> G[用户响应] G --> H[维护 Maintenance] H --> A

B -->|反馈/路由| I[选择调整] C -->|质量评估| J[压缩率调整] E -->|溢出处理| K[容量管理]

style A fill:#f9f,color:#000 style E fill:#bbf,color:#000 style F fill:#bfb,color:#000 ```

这个框架的价值在于：它提供了一致的术语和抽象，使不同领域的研究者和工程师能够用相同的方式描述问题。当你面对一个具体的上下文挑战时，你的问题必然落在四个操作之一（或多个操作的组合）中；当你评估一个解决方案时，你可以从这四个维度来检视其设计。

Selection: The Problem of Relevance / 选择：相关性判断的核心挑战

选择是上下文工程中最直观也最困难的操作。它的目标是从庞大的候选信息池中，找出最可能回答当前问题的内容。

在 RAG 系统中，选择操作表现为检索（Retrieval）：给定用户查询，从向量数据库中找出最相似的文档片段。表面上这是一个匹配问题，但实际远比匹配复杂。相关性不仅是语义相似性，还涉及：

• **时效性**：今天的新闻比上周的更重要；
• **权威性**：官方文档比社区帖子更可靠；
• **完整性**：需要足够的信息来回答，但不要引入过多噪声；
• **多样性**：多个角度的信息可能比单一来源更全面；
• **上下文依赖**：某个片段单独看相关性不高，但在特定上下文中却是关键。

选择操作的技术挑战在于：LLM 的注意力机制对上下文的每个 token 分配权重，但这个分配是隐式的、不可控的。我们无法直接告诉模型“我希望你更多地关注这几句话”。因此，选择操作必须在输入阶段完成——如果我们选错了信息，后续无论模型多强大，都难以弥补。

典型的选择策略包括：

• **稀疏检索**（如 BM25）：基于关键词匹配，适合精确术语匹配的场景；
• **密集检索**（如向量相似度）：基于语义理解，适合同义词和释义；
• **混合检索**：结合两者优势，通过重排序（Reranking）筛选最终结果；
• **查询改写**：在检索前将用户问题转换为更适合检索的表述；
• **迭代检索**：根据中间结果决定是否需要补充检索。

Compression: The Art of Saying More with Less / 压缩：用更少说更多

压缩的目标是将选中的信息提炼为更紧凑的形式，以适应有限的上下文窗口或降低 token 成本。

压缩不是简单的内容截断。粗暴的截断可能丢失关键信息，导致上下文不完整。更重要的是，LLM 对信息的位置和结构敏感——段落开头的句子通常获得更多注意力，列表中的项目可能被平等对待但实际重要性不同。

有效的压缩需要理解信息的语义核心：哪些是必须保留的事实，哪些可以舍去，哪些需要重新表述以保持完整性？

压缩操作的典型技术包括：

• **摘要生成**（Summarization）：使用 LLM 或专用摘要模型将长文本压缩为摘要；
• **关键信息提取**：识别并保留实体、关系、事件等结构化信息；
• **层次化表示**：将信息组织为树状或图状结构，每层是下层的摘要；
• **选择性复制**：在压缩过程中保留原始文本的关键片段不做压缩。

压缩操作需要权衡两个维度：信息损失和压缩率。高压缩率意味着更高的成本效率和更宽松的上下文限制，但信息损失风险增大；低压缩率保留更多细节，但可能超出窗口限制或引入过多噪声。实际应用中，这个权衡取决于具体场景——医学诊断需要完整信息，闲聊摘要可以大胆压缩。

Transformation: Reshaping Information for the Model / 转换：为模型重塑信息形态

转换改变信息的形态，使其更适合 LLM 处理。这听起来可能像压缩，但两者有本质区别：压缩是减少信息量，转换是改变信息结构。

LLM 对输入格式的敏感程度远超大多数人的直觉。同样的信息，用不同的结构呈现，可能得到截然不同的回答。例如：

• 将非结构化文本转换为结构化数据（JSON、表格）可以提升信息提取准确性；
• 将长对话历史转换为摘要可以减少 token 消耗，但可能丢失关键细节；
• 将代码片段与相关文档分离可以避免模型混淆不同来源的信息；
• 将隐式依赖关系转换为显式说明可以帮助模型正确执行多步推理。

转换操作的核心挑战在于：需要理解模型如何“看待”信息。这不是一个简单的格式问题，而是涉及认知科学——模型如何分配注意力、如何处理长距离依赖、如何在上下文中进行推理？

典型的转换技术包括：

• **结构化输出**（Structured Output）：强制模型输出特定格式（如 JSON Schema），提高可解析性；
• **提示工程**（Prompt Engineering）：通过措辞和格式引导模型的注意力分配；
• **上下文结构设计**：预先组织上下文的层级结构（如“背景-任务-要求-示例”）；
• **格式转换**：Markdown 转表格、文本转代码块、自然语言转 SQL。

Maintenance: Preserving State Across Time / 维护：在时间中保持状态

维护是四种操作中最容易被忽视的，但它对用户体验和系统可靠性至关重要。维护的目标是在多轮交互、长时间运行、或跨会话的场景中，保持上下文的状态一致性。

最典型的维护场景是对话历史管理。当对话轮次增加，历史消息会：

• 超出模型的上下文窗口限制；
• 包含大量与当前问题无关的历史信息；
• 包含可能干扰当前推理的过时上下文。

维护操作需要在信息保留和上下文精简之间取得平衡。常见的维护策略包括：

• **会话摘要**：定期将对话历史压缩为摘要，保留关键要点；
• **滑动窗口**：只保留最近 N 轮对话，丢弃早期历史；
• **重要性加权**：根据某种评分机制保留高价值消息，丢弃低价值消息；
• **结构化记忆**：维护一个独立的“记忆”模块，记录关键信息而非完整对话；
• **会话分段**：将长对话分解为多个段落，每个段落独立处理。

维护的另一个关键场景是跨会话记忆。当用户重新打开一个应用时，如何恢复之前的上下文？这涉及到外部存储和上下文重建——不是在模型内部维护，而是在系统层面管理。

---

1.3 从 Few-shot 到 Long-context：历史演进与能力边界

The Evolution: From Few-shot Learning to Million-token Contexts

理解上下文工程为何在今天变得关键，需要回溯 LLM 能力演进的历史轨迹。

Few-shot Learning（少样本学习）是 GPT-2（2019）和 GPT-3（2020）时代提出的范式。当时的模型上下文窗口仅有 2,048 到 4,096 token——大约相当于一篇文章的长度。在如此有限的上下文中，“上下文工程”的概念几乎不存在：你没有足够的空间来提供大量外部信息，few-shot examples（少样本示例）是唯一需要管理的上下文内容。

Few-shot 学习的核心技巧是示例选择（Example Selection）：如何从大量候选示例中挑选最相关的几个放入 prompt？这开启了上下文工程思想的萌芽——即使在有限空间内，如何选择和排列信息仍然重要。

Long-context Models（长上下文模型）的突破发生在 2023-2024 年。Claude 3（200K token）、Gemini 1.5 Pro（1M token）、GPT-4 Turbo（128K token）、Claude 3.5（200K token）——上下文窗口的数量级增长，彻底改变了上下文工程的含义。

当上下文窗口从 4K 扩展到 1M token，上下文工程的意义发生了质变：

• **从“选择放入什么”变为“管理海量信息”**：在 4K 时代，你可以把几乎所有相关信息都塞进 prompt；在 1M token 时代，信息量远超人类手动筛选的能力，必须依赖自动化的选择、压缩和转换。
• **从“Prompt 技巧”变为“系统工程”**：简单的 few-shot 示例无法利用百万 token 的能力；你需要构建完整的数据管道、检索系统、状态管理机制。
• **从“模型限制”变为“工程挑战”**：当模型能力不再是瓶颈，工程问题浮出水面——如何高效地在海量文档中检索？如何确保信息质量？如何管理成本？

这个演进过程可以用一个简单的类比说明：few-shot 时代相当于用一篇文章来教一个学生；long-context 时代相当于用一个图书馆来教一个学生。管理一篇文章很简单，但管理一个图书馆——索引、检索、筛选、更新——则需要系统性的方法。

The "Lost in the Middle" Problem / “中间迷失”问题

长上下文模型带来了新能力，也带来了新问题。其中最核心的是“中间迷失”（Lost in the Middle）问题。

研究表明，当相关信息位于上下文的开头或结尾时，LLM 能够很好地利用它；但当相关信息位于中间位置时，模型的表现显著下降。这一现象在多个任务和多个模型中都被观察到。

“中间迷失”的原因与 Transformer 的注意力机制有关：虽然理论上全局注意力可以处理任意距离的依赖，但实际训练数据中，关键信息出现在开头或结尾的频率更高，模型在训练中习得了这种位置偏好。

这对上下文工程的设计有深刻启示：选择操作不能仅仅返回语义相关的片段，还需要考虑片段在上下文中的位置分布。一个优秀的 RAG 系统，可能会刻意将最相关的信息放在窗口开头或结尾，或者通过多次检索、重排序等策略来缓解位置偏差。

解决“中间迷失”的工程策略包括：

• **HyDE（假设性文档嵌入）**：先生成一个假设性答案，再用它来检索真实文档，改变检索的分布；
• **重排序（Reranking）**：在初步检索后，将候选文档重新排序，优先选择可能出现在首尾位置的；
• **窗口滑动与多次查询**：将长文档切分为多个窗口，分别处理后合并结果；
• **层级检索**：先在大粒度（如章节）检索，再在匹配章节内细粒度检索。

---

1.4 为什么上下文工程现在成为关键学科

Why Context Engineering Matters Now

要理解上下文工程为何在当下成为一门关键学科，我们需要审视几个正在汇聚的技术与产业趋势。

第一，模型能力增长的重心正在转移。

过去五年，LLM 的进步主要体现在模型参数量的增长和预训练知识的扩展。GPT-2 到 GPT-4 的跃迁，核心是参数知识的多寡。但这种范式的边际收益正在递减——继续扩大模型的知识容量变得越来越昂贵，而用户对“精准、可控、实时”信息的需求却持续增长。

上下文工程正是这个转移的核心：从“让模型记住更多”转向“让模型更有效地使用信息”。当你不再能简单依赖模型的内部知识时，如何组织和呈现外部知识就成了决定性的工程问题。

第二，应用场景的复杂度在指数级增长。

早期的 LLM 应用——问答、摘要、翻译——对上下文的要求相对简单：单个问题，单个回答，上下文几乎是空的。但今天的应用场景正在向复杂系统演进：

• **Agent 系统**：需要维护长期状态、规划多步行动、在执行中持续学习；
• **知识库问答**：需要在百万文档中检索、整合、生成；
• **多模态交互**：需要处理文本、图像、音频、视频的交织上下文；
• **企业级应用**：需要满足合规性、可审计性、权限控制等工程要求。

这些场景的共同点是：上下文管理不再是可选的优化，而是功能的核心组成部分。一个无法正确管理上下