上下文工程概述：为什么上下文是LLM的灵魂

上下文工程概述：为什么上下文是LLM的灵魂

当你向ChatGPT提问“为什么天空是蓝色的”时，你可能不会想到，这个看似简单的回答背后，隐藏着一个深刻的悖论：模型能够给出多么详尽和准确的答案，并不取决于模型本身有多强大，而取决于它在回答的那一瞬间“看到”了什么。这个它能看到的东西，就是上下文（Context）。

上下文是大型语言模型进行推理和生成的全部信息基础。如果把模型比作一个极其聪慧但患有严重失忆症的人，那么上下文就是贴在它面前的便签条——它只能在便签条写下的内容范围内工作，超出这个范围的任何信息，对它来说都不存在。因此，理解上下文工程的本质，就是理解LLM能力边界的钥匙。

这引出了本章要回答的核心问题：为什么上下文是大型语言模型能力的决定性因素？上下文工程究竟在解决什么问题？围绕这两个问题，我们将从概念本质、物理限制、工程方法论和动手实践四个层面，逐步揭开上下文工程的神秘面纱。

理解上下文的本质：模型推理的“全部已知”

上下文不是输入，而是信息的组装

在日常语言中，我们习惯于把“上下文”理解为一段文字的前后关联——比如一篇文章的语境。但在大语言模型的语境中，上下文有着精确的技术含义：模型在进行每一次推理时接收的完整输入集合。

这个集合通常包含以下几个组成部分：

系统级上下文是最底层的配置信息，它设定了模型的基本行为准则。例如，当你告诉模型“你是一位专业的数据分析师”，这条指令就是系统级上下文。系统级上下文的特点是它会持续作用于整个对话过程，不会随着对话的深入而改变，除非你主动修改它。

对话历史上下文记录了当前会话中所有的交互内容。在一个多轮对话中，用户之前问过的问题和模型给出的回答，都会被纳入后续推理的上下文之中。这使得模型能够理解对话的连贯性，而不是把每个问题都当作完全独立的新问题来处理。

当前输入上下文是用户本轮提供的最新问题或指令。这是触发模型推理的直接动因，它需要被清晰地纳入上下文，供模型理解用户当前的需求。

外部知识上下文是近年来随着检索增强生成（RAG）技术发展而引入的新型组件。当需要模型回答涉及专业知识的问题时，系统会将相关文档或从知识库中检索到的信息注入上下文，使得模型能够在这些材料的基础上进行回答，而不是仅凭训练知识。

上下文工程的第一个核心洞察是：上下文不是单一的一条信息，而是一个经过精心组装的集合。这个集合的质量和结构，直接决定了模型输出的质量上限。当我们说“上下文是LLM的灵魂”时，我们实际上是在说：模型的能力并非完全由参数决定，而更多取决于我们如何组织和呈现信息给模型。

信息选择悖论：上下文不是越多越好

一个违反直觉的事实是：上下文并不是越多越好。这听起来与直觉相悖——模型能“看到”更多信息难道不是好事吗？实际情况远比这复杂。

当上下文过长时，会出现两个严重问题。第一个是注意力分散问题。Transformer架构的注意力机制虽然强大，但它对信息的选择能力是有限的。当上下文中充斥着大量无关或低相关度的信息时，模型很难准确识别出最关键的内容，从而导致输出质量下降。这就像在一份冗长的报告中，关键信息被淹没在大量的噪音中，读者很难准确把握核心观点。

第二个问题是位置偏见问题。研究表明，当上下文非常长时，模型往往会对上下文开头和结尾的信息表现出更强的记忆力，而对中间部分的信息记忆力较弱。这种现象被称为“中间丢失”（Lost in the Middle）问题。这意味着，如果你的关键信息恰好位于冗长上下文的中间位置，它被模型“忽略”的概率会显著上升。

因此，上下文工程面临的核心挑战是：在有限的空间内，选择最相关的信息，并以最优的结构呈现。这不是一个简单的信息堆积问题，而是一个信息筛选、压缩和组织的问题。

一个直观的对比示例

让我们用一个具体例子来说明上下文质量对输出的巨大影响。假设你需要模型帮助审阅一段代码，并指出其中的安全漏洞：

场景A（低质量上下文）：

``` 用户：请审阅以下代码的安全性 [代码片段，500行，包含数据库操作、用户输入处理、文件操作等] ```

场景B（高质量上下文）：

``` 系统：你是一位专注于Web应用安全的高级工程师。你的职责是识别代码中的安全漏洞，特别关注以下类型：SQL注入、XSS跨站脚本、CSRF、会话管理问题、敏感信息泄露。

用户：请审阅以下代码片段，重点关注用户输入验证和数据库查询部分。

[仅包含相关代码片段，约50行] ```

在这两个场景中，使用的是同一个模型，但输出的质量可能相差甚远。场景A中，模型可能给出泛泛而谈的评论；场景B中，模型能够有针对性地识别具体漏洞并给出修复建议。这种差异不是模型能力造成的，而是上下文质量造成的。

这个对比揭示了上下文工程的一个核心原则：给模型提供正确类型的信息，比提供尽可能多的信息更重要。

上下文窗口：物理限制的客观存在

什么是上下文窗口

上下文窗口（Context Window） 是指模型一次推理所能处理的最大Token数量。这里的Token是语言模型处理信息的基本单位。对于英文文本，一个Token大约等于4个字符或0.75个单词；对于中文文本，一个Token大约等于1-2个汉字。理解Token的概念对于估算上下文长度至关重要。

上下文窗口的大小直接限制了你能一次性“喂给”模型的信息量。如果你的上下文超过了窗口上限，超出部分会被直接截断，模型看不到这些信息。这就像是一个固定大小的白板，无论你有多少内容要展示，只能在白板尺寸范围内排列，超出部分要么被裁剪，要么被忽略。

上下文窗口是一个硬件级限制，它由模型的架构设计决定，一旦模型训练完成，这个上限就基本固定了（虽然有些模型支持不同尺寸的版本）。这与模型的参数数量、训练数据量等软性能力指标不同，上下文窗口是一个刚性的物理边界。

上下文窗口的竞争史

回顾大语言模型的发展历程，我们可以清晰地看到上下文窗口的演进轨迹，这段历史本身就是各家厂商技术竞争的主战场之一。

2020年，OpenAI发布的GPT-3将上下文窗口提升到了2048个Token，这是一个里程碑式的突破。在此之前，大多数模型的窗口只有几百个Token，难以处理较长的文档。2048个Token大约相当于1500个英文单词或1000个汉字，勉强能够容纳一篇中等长度的文章。

2022年，GPT-3.5将窗口扩展到4096个Token，同年发布的Claude 1则达到了9000个Token以上的水平。这场军备竞赛开始加速。

2023年是关键的一年。GPT-4发布时提供了两种版本：8K版本和32K版本。Anthropic的Claude 2则直接支持100K Token的上下文——这意味着它可以一次性处理整本《哈利·波特》或数百页的技术文档。Gemini 1.5更是将这个数字推高到了100万Token。

为什么厂商要如此激烈地竞争上下文窗口的大小？这背后的逻辑非常清晰：更长的上下文窗口意味着更强的多文档处理能力、更复杂的推理能力、以及更广泛的应用场景。一个只有4K窗口的模型，很难胜任法律合同分析、医疗档案审查、代码库理解这类需要处理大量信息的任务。

但这里存在一个被很多人忽视的悖论：窗口越大并不意味着模型对长上下文的利用率越高。研究表明，许多模型在上下文长度显著增加后，对远处信息的捕获能力会下降。这就是为什么我们需要上下文工程——不是简单地增大窗口，而是帮助模型更好地利用已有的窗口空间。

窗口限制带来的工程挑战

理解上下文窗口的限制对于实际应用开发至关重要，因为它带来了一系列具体的工程挑战。

挑战一：信息截断问题。当用户的输入或检索到的文档超过窗口上限时，必须进行截断。但截断什么内容是一个需要精心设计的问题。最简单的策略是截取开头或结尾，但这样做可能会丢失关键信息。更好的策略是基于语义相关性选择保留的内容，或者对长文档进行分块处理。

挑战二：成本与延迟问题。上下文的长度直接影响推理成本和响应延迟。更长的上下文意味着更多的Token需要处理，消耗更多的计算资源和时间。在实际应用中，我们需要在上下文质量和成本之间寻找平衡点。

挑战三：信息密度问题。当窗口有限时，提高单位Token的信息密度变得至关重要。这催生了信息压缩技术的需求——如何用更少的Token传达更多的语义信息。

挑战四：状态维护问题。对于需要长期交互的应用（如持续对话的AI助手），如何在有限的窗口内维护对话状态是一个持续性的挑战。当对话历史超过窗口限制时，必须做出选择：保留什么，丢弃什么。

理解这些挑战，是理解上下文工程必要性的起点。

上下文工程与提示工程：不同的层次，相同的目标

提示工程的局限性

提到上下文工程，很多人会联想到提示工程（Prompt Engineering）——那个教你如何写好Prompt的技术领域。确实，上下文工程和提示工程有着密切的联系，但两者并不是同一回事。理解它们之间的区别，是建立清晰认知框架的关键。

提示工程的核心关注点是：如何设计单次输入的措辞、格式和结构，以获得期望的模型输出。常见的提示工程技术包括：使用清晰具体的指令、提供示例（Few-shot Learning）、设定输出格式、使用思维链（Chain of Thought）等等。

举一个提示工程的例子：

``` 你是一个翻译助手。请将以下中文翻译成英文，保持原文的文学风格：

[中文文本] ```

这里的技巧在于如何组织指令、如何描述任务、如何设置约束条件。提示工程假定上下文中只包含用户输入和系统指令，不需要考虑信息管理的问题。

然而，当你的应用场景变得更加复杂时，提示工程就显露出了它的局限性。假设你需要开发一个能够处理用户长篇文档的AI助手，用户的文档可能有几十万字，远远超过模型的上下文窗口限制。在这种情况下，仅靠优化Prompt的措辞是无法解决问题的，你需要系统性地管理进入上下文的文档内容——这正是上下文工程要解决的问题。

上下文工程的更大视野

上下文工程的定义是：在模型的上下文窗口限制下，系统性地管理和优化进入模型输入的所有信息，以实现最佳的推理效果。这包括了信息的选择、压缩、组织、更新和维护等一系列问题。

如果用建筑来类比：提示工程就像是教你如何设计一面精美的玻璃窗；而上下文工程关注的是整栋建筑的采光系统——包括窗户的位置、尺寸、玻璃的选择、窗帘的调节，以及如何让阳光（信息）最优地照进房间（模型的推理过程）。

上下文工程包含了提示工程，但远不止于此。上下文工程的核心关注点包括：

上下文长度管理：如何在有限的窗口内安排尽可能多的相关信息，如何处理超出窗口限制的情况。

信息压缩与摘要：如何用更少的Token表达相同的信息，如何识别和丢弃冗余内容。

检索增强：如何从外部知识源动态获取相关信息并注入上下文。

状态维护：如何在长期交互中保持上下文的连贯性和一致性。

这四大支柱构成了上下文工程的完整框架。在后续章节中，我们将对每一个支柱进行深入探讨。

协同而非替代

需要强调的是，上下文工程并不是要取代提示工程，而是对它的扩展和深化。优秀的上下文工程实践必须建立在良好的提示工程基础之上。

举一个例子来说明两者的协同关系：假设你要构建一个法律文档分析助手。上下文工程负责解决“如何将相关法律条文注入上下文”以及“如何管理大量文档的分块和检索”的问题；而提示工程负责设计“如何引导模型按照法律分析的逻辑框架来输出结论”。

换句话说，上下文工程解决的是“给模型看什么”的问题，而提示工程解决的是“让模型怎么看”的问题。两者缺一不可，共同决定了最终的应用效果。

上下文工程的四大支柱

支柱一：上下文长度管理

上下文长度管理是上下文工程的基础设施层，它解决的是如何在有限窗口内最大化信息价值的问题。

核心策略一：信息分块（Chunking）。当文档长度超过窗口限制时，需要将文档切分成若干小块（Chunk）进行处理。分块策略的选择直接影响信息保留的完整性和检索的准确性。常见的分块方法包括：固定长度分块（按Token数或字符数切分）、语义分块（按句子或段落边界切分）、层次分块（先按文档结构分层，再逐层细化）。

核心策略二：优先级排序。当上下文空间紧张时，需要决定哪些信息优先保留。基本的策略包括：保留最新的对话内容（Recency策略）、保留与当前查询最相关的内容（Relevance策略）、保留系统级指令（System指令通常优先级最高）。

核心策略三：滑动窗口处理。对于超长文本，可以采用滑动窗口的方式分批处理。每一次处理覆盖文本的一个片段，然后将片段的处理结果汇总。这在文档摘要、长篇分析等场景中非常有用。

支柱二：信息压缩

信息压缩是提高上下文效率的关键技术，它解决的是如何用更少的Token表达更多语义的问题。

压缩技术一：摘要生成。对于长文档，可以先使用模型或专门的摘要模型生成压缩版本，再将其注入上下文。摘要可以是抽取式的（直接从原文中提取关键句子），也可以是生成式的（重新组织语言生成新的摘要）。摘要的压缩比可以根据窗口限制动态调整。

压缩技术二：实体和关系提取。将文本转换为结构化的实体-关系表示，可以大幅减少Token消耗，同时保留核心语义信息。例如，将一段描述转换为“人物：[张三]；关系：[是]；对象：[某公司CEO]”的形式。

压缩技术三：Token优化。在保证语义的前提下，使用更紧凑的表达方式。例如，将“根据我们之前的讨论”简化为“前文”，将“请参考以下内容”简化为“参考”。这类优化虽然看起来微小，但在大量使用时效果显著。

支柱三：检索增强生成（RAG）

检索增强生成（Retrieval-Augmented Generation, RAG） 是近年来最重要的上下文工程范式之一，它解决的是如何让模型访问外部知识的问题。

传统的LLM只能基于训练数据来回答问题，这带来了知识时效性和覆盖度的限制。RAG通过在推理时动态检索相关文档，并将其注入上下文，使得模型能够“看见”训练数据之外的信息。

一个典型的RAG流程如下：

1. 用户提出问题 2. 系统使用问题作为查询，从外部知识库检索相关文档 3. 将检索到的文档与用户问题组装成上下文 4. 模型基于完整上下文生成回答

RAG的核心技术挑战包括：检索质量（如何找到真正相关的内容）、上下文组装（如何将检索结果与原始问题有效融合）、去噪处理（如何过滤掉检索结果中的无关信息）。

支柱四：状态维护

状态维护解决的是长期交互场景中的上下文管理问题。在持续对话或多轮任务执行中，如何让模型记住之前的关键信息，是一个既基础又复杂的挑战。

挑战一：对话历史膨胀。随着对话轮次的增加，对话历史会不断累积，可能超过窗口限制。处理策略包括：只保留最近N轮对话、使用摘要模型压缩历史、选择性保留关键信息。

挑战二：跨会话状态。当用户开启新对话时，之前对话中的信息会丢失。如果需要保持长期记忆，需要将关键信息存储在外部存储中，并在新对话开始时重建上下文。

挑战三：多智能体协作。在复杂的AI系统中，多个模型实例可能需要共享状态。如何在分布式环境中有效管理共享状态，是一个新兴的研究方向。

动手实验：体验上下文配置的影响

现在，让我们通过一个实践案例来亲身体验上下文配置对模型输出的影响。这个实验不需要任何编程基础，只需要访问任何支持自定义系统指令的LLM界面（如ChatGPT的GPT Builder、Claude的配置界面、或任何支持OpenAI API的测试工具）。

实验设计

本实验的目标是观察相同的用户输入在不同上下文配置下产生的输出差异。我们将设计三个配置场景：

场景一：通用助手（基准配置）。系统指令保持最小化或使用默认值。

场景二：专业角色。在系统指令中明确设定专业角色和输出风格。

场景三：带示例的专家。在场景二的基础上，增加few-shot示例。

实验步骤

第一步：准备测试问题。选择一个能够体现专业性差异的问题，例如：“解释量子纠缠原理，并用生活中的比喻说明。”

第二步：配置并测试场景一。将系统指令设为：“你是一个有帮助的AI助手。”然后提交测试问题，记录模型输出。

第三步：配置并测试场景二。将系统指令修改为：“你是一位理论物理学家，擅长用通俗易懂的语言解释深奥的物理概念。回答时注重逻辑清晰、层次分明。”提交相同问题，记录输出。

第四步：配置并测试场景三。在场景二的基础上，在用户问题之前添加以下示例：

``` 用户：请解释薛定谔的猫 你：薛定谔的猫是一个著名的思想实验，用来说明量子力学中的"叠加态"概念。想象有一个密封的盒子，里面有一只猫，还有一瓶毒药和一个放射性原子。如果原子衰变，毒药就会被释放，猫就会死；如果原子没有衰变，猫就活着。在打开盒子观察之前，原子处于"衰变"和"未衰变"的叠加状态，对应的，猫也处于"死"和"活"的叠加状态——直到观察者打开盒子，这个叠加状态才会"坍缩"为一个确定的结果。

用户：请解释量子纠缠原理 你： ```

提交完整上下文（包括示例），记录模型输出。

观察与分析

完成三个场景的测试后，你可以通过对比发现以下规律：

关于输出深度的差异。场景一可能给出简短的定义性回答；场景二可能提供更系统、结构化的解释；场景三可能在保持专业深度的同时，更贴近示例的风格和表达方式。

关于一致性的影响。场景三通过示例展示了期望的输出格式和风格，模型通常会模仿这种风格，输出的一致性更高。

关于Token消耗的变化。场景三的上下文明显更长，因为它包含了示例。如果你在使用API，场景三的Token消耗会显著高于前两个场景。

实验延伸：窗口限制的体验

如果你想进一步体验窗口限制的影响，可以尝试以下操作：

1. 在对话进行到一定轮次后，询问模型“还记得我们最开始讨论的量子纠缠吗？”观察模型的回答。 2. 如果模型开始“遗忘”早期内容，这就是窗口限制和信息保留策略在起作用。 3. 尝试在对话中定期插入“你还记得之前的要点吗？请简要总结。”这样的指令，观察模型如何压缩和保留历史信息。

通过这些实验，你可以直观感受到上下文工程在实际应用中的重要性，以及它对最终用户体验的深刻影响。

本章小结

本章从概念本质、物理限制、方法论框架和实践体验四个维度，建立了上下文工程的认知基础。核心洞察可以归纳为以下几点：

第一，上下文是LLM推理的完整信息基础。模型的输出质量直接由它能“看到”的信息决定，而非仅由参数规模决定。上下文不是输入的一部分，而是输入的全体——模型只能在给定的上下文中工作，超出这个范围的信息对它而言不存在。

第二，上下文窗口是刚性的物理限制。Tok