【提示词工程系统教程 05】上下文工程：静态指令、动态检索与RAG架构

章节导读：从提示设计到上下文工程

上一章我们讲解了推理增强与工具调用两类进阶提示技术，掌握了通过思维链释放模型推理能力、通过工具调用突破模型能力边界的核心方法，完成了从基础提示到进阶技术的升级。

但提示工程不止是写好指令本身，更核心的是管理输入给模型的全部信息。大模型拥有海量通用知识，但天然和用户的个性化场景、实时数据、私有内容是脱节的。如何系统地向模型投喂信息，是决定应用效果的核心工程问题，也就是 上下文工程（Context Engineering）的核心议题。

本章将从提示内容的两大支柱出发，区分静态内容与动态内容的定位与设计原则，剖析少样本提示的潜在风险；随后深入讲解行业主流的外部知识注入架构------检索增强生成（RAG），拆解两种检索技术的原理、适用场景与完整实现流水线；最后介绍上下文压缩的核心手段：摘要技术，帮助我们在有限的上下文窗口内实现信息效率的最大化。

本章学习目标

在提示工程框架中，区分静态内容（显式指令、少样本示例）与动态内容（用户专属数据）的定位与作用。
评估少样本提示的潜在风险，重点理解锚定偏差与虚假模式识别对输出的影响，掌握对应的缓解策略。
能够设计概念级的检索增强生成（RAG）流水线，结合嵌入模型与向量数据库，解决模型知识截止的局限。
对比词汇检索（如杰卡德相似度）与神经检索（嵌入向量）的效果差异，掌握二者在领域术语等特定场景下的适用边界。

5.1 静态内容：定义游戏规则

5.1.1 提示内容的两大支柱

一个完整的提示词，本质上由两类内容构成，分别承担不同的作用：

静态内容：也就是"游戏规则"，是硬编码的固定指令、格式规范、示例集合。它的目标是清晰定义任务规则、输出格式与风格要求，对所有用户、所有请求都保持一致。
动态内容：也就是"当前状态"，是用户专属数据、实时信息、检索得到的文档片段。它的目标是提供当前任务的具体上下文，随用户和场景动态变化。

直观示例：图书推荐场景

静态内容："请结合用户的阅读偏好，推荐1本合适的书籍，说明推荐理由，控制在200字以内。"

动态内容：用户读过的书目、个人年龄、兴趣爱好、旅行经历等专属信息。

只给静态指令不给动态上下文，模型只能给出通用泛化的推荐；补充了个人动态信息后，推荐结果会精准贴合用户偏好。大模型擅长处理各类杂乱的文本信息，但前提是我们要主动把这些信息提供给它。

5.1.2 问题澄清的两种方式

向大模型澄清任务要求，是静态内容的核心作用，主要有两种实现方式。

1. 显式澄清

通过直接的命令，明确告诉模型该做什么、该避免什么，通常放在系统提示中。

示例：

用户指令："写一段摘要。"

系统显式规则："使用Markdown格式输出，不要使用超链接，不要引用2026年7月17日之后的日期。"

显式澄清的优势是清晰直白，便于修改和维护，适合定义硬性规则与格式要求。

2. 隐式澄清（少样本提示）

通过示例来展示期望的输出行为，对于捕捉语气、风格、格式这类难以用文字描述的要求，效果往往更好。

示例：影评评分场景

复制代码

# 示例1
影评对象：《白鲸记》
评分：5/5 - 一部波澜壮阔的海洋史诗！

# 示例2
影评对象：《黑客帝国》
评分：5/5 - 划时代的数字科幻杰作。

# 主任务
影评对象：《海滩》
评分：

核心洞察：大模型是天生的模式匹配器，隐式示例的优先级往往会高于显式规则------模型会本能地延续示例的模式，而不是遵守文字描述的规则。因此对于风格、语气类要求，用少样本示范比纯文字描述更可靠。

5.1.3 指令设计的三条经验法则

编写静态指令时，遵循三条通用原则，可以显著提升输出的稳定性：

多用正向指令，少用负向禁令：用"应该做什么"替代"不要做什么"。比如不说"不要伤害生命"，而说"应当尊重生命"。
给指令补充理由：说明规则背后的原因，模型会更好地理解并遵守。比如不说"不要泄露内部数据"，而说"不要泄露内部数据，以免造成商业信息泄露的风险"。
避免绝对化表述：不用非黑即白的绝对命令，保留合理的弹性空间。比如不说"绝对不能使用专业术语"，而说"尽量使用通俗表达，仅在必要时使用少量专业术语"。

5.1.4 少样本提示的三类风险

少样本提示虽然效果强大，但并非没有副作用，使用时需要警惕三类典型风险。

风险1：上下文扩展性差

少样本示例需要和当前问题高度相关才有效，但如果用户的上下文属性非常多、内容很长（比如大量历史评价），示例+上下文会迅速撑满模型的上下文窗口。

即便窗口足够大，过多冗长的相似信息也会让模型混淆，反而降低输出质量。因此少样本提示不适合上下文维度极多的复杂场景。

风险2：锚定偏差

示例会给模型建立一个初始的概率分布，将输出锚定在示例的风格、数值、年代范围内，也就是锚定偏差（Anchoring Bias）。

经典示例：婴儿名字流行年份

如果示例里的名字流行年份都在1910年代，模型对新名字的预测也会偏向20世纪初；

如果示例里的年份都在2010年代，模型的预测就会锚定在21世纪。
哪怕任务逻辑本身和年代无关，示例的数值特征也会潜移默化地影响模型输出。

风险3：虚假模式识别

模型会主动捕捉示例里的偶然规律，比如顺序、情绪流向，而这些规律并不是你想教给它的，这就是虚假模式（Spurious Pattern）。

常见虚假模式1：顺向成功偏差。如果前3个示例都是成功案例，模型会倾向于给后续问题也输出成功结果，哪怕按逻辑应该失败。
常见虚假模式2：顺序递增偏差。如果示例的数值是1、2、3依次递增，模型会本能地猜测下一个是4，忽略背后的业务逻辑。

缓解策略：打乱示例的顺序，或者使用系统化的提示优化框架，消除偶然的虚假模式。

5.2 动态内容：上下文的来源与管理

5.2.1 动态内容的核心特性

静态内容是预先写好的固定规则，而动态内容是在请求发生时实时获取的，会随着用户身份、时间、世界状态的变化而变化。

动态内容最核心的约束是延迟（Latency）：我们有多少时间来收集上下文，直接决定了可以采用的检索策略。

根据延迟要求从低到高，分为三类场景：

低延迟要求（有充足时间）：比如邮件摘要工具，用户处于非活跃等待状态，可以花较长时间做深度上下文检索。
中等延迟要求（秒级响应）：比如图书推荐应用，用户在线等待，通常要求1-3秒内返回，只能做有限的检索。
高延迟要求（实时响应）：比如代码自动补全，每毫秒都很关键，必须提前预加载好上下文，否则直接放弃检索。

和延迟相关的另一个属性是可预处理性：上下文信息能不能提前准备好。越稳定、变化越慢的信息，越容易提前预处理；变化越快的信息，越难缓解延迟压力。

5.2.2 上下文来源的分类框架

我们可以从两个维度，对所有潜在的上下文数据源进行分类：

稳定性维度：信息变化的快慢，从快速变化到缓慢变化。
距离维度：和用户当前问题的远近程度，从紧邻用户到远离用户。

分类维度	变化快（不稳定）	变化慢（稳定）
距离用户近	当前页面内容、输入的问题	用户档案、过敏信息、个人偏好
距离用户远	天气、股价、实时新闻	城市餐厅列表、公共知识库

整体规律是：信息源越不稳定，就越难提前准备，延迟优化的难度就越高。

思维导图示例：图书推荐场景的上下文来源

围绕"我接下来该读什么书"这个核心问题，可以向外发散出大量潜在数据源：

用户属性：年龄、职业、爱好、旅行经历、阅读历史、评分偏好

外部信息：畅销榜、好友在读、同类型热门书籍
上下文工程的第一步，就是从众多潜在来源中，筛选出真正有价值的信息。

5.2.3 契诃夫之枪谬误

上下文不是越多越好，无关的上下文反而会带来负面影响，这就是提示工程中的契诃夫之枪谬误（Chekhov's Gun Fallacy）。

这个概念来自戏剧创作原则："如果第一幕的墙上挂了一把枪，那第二幕它就必须开火，否则就不该挂在那里。"

对应到提示工程中：只要你把一段信息放进了上下文里，大模型就会默认它是重要的，一定会在输出中用到它。

风险

无关的上下文会导致模型产生幻觉、过度解读，强行把不相关的信息关联起来，得出错误的结论。

经典反例

提供的上下文：

用户评价："我讨厌泰国的食物，太辣了。"

用户评价："航班延误了4个小时。"
用户问题："我该不该读《海滩》这本以泰国为背景的小说？"
模型幻觉输出："你大概率不会喜欢这本书，因为它以泰国为背景，而你之前说过讨厌泰国常见的辛辣食物。"
本质就是无关的上下文误导了模型，让它强行建立了错误的因果关系。

核心结论：检索必须精准，盲目堆砌数据是危险的。上下文不是越多越好，只有相关的信息才有价值。

实战讨论：晚餐推荐应用的上下文分诊

现有可选项：A.用户GPS定位 B.城市所有餐厅列表 C.用户5年的飞行记录 D.当前天气 E.用户档案里的过敏信息

高优先级核心信息：A、E，直接决定推荐的范围和安全性。

容易触发契诃夫之枪的信息：C，飞行历史和晚餐推荐几乎无关，放入上下文很容易引发错误关联。

动态不稳定但距离远的信息：D，天气是实时变化的，且和晚餐推荐有一定关联，但距离用户核心需求较远。

5.3 检索增强生成（RAG）

5.3.1 核心问题：被冻结的模型

大模型的知识是被冻结在训练完成的时间点的，天然存在两个无法突破的硬边界：

知识截止问题：模型不知道训练数据收集完成之后发生的事件，比如昨天的股价、今天的新闻。
私有数据问题：模型无法获取用户的邮件、消费记录、企业内部文档，这些数据都在隐私墙之后。

没有外部信息补充的话，模型无法访问任何公开训练数据之外的内容。检索增强生成就是解决这个问题的行业标准架构。

5.3.2 RAG的定义与核心思想

**检索增强生成（Retrieval-Augmented Generation, RAG）**是一种架构设计模式：在让大模型生成回答之前，应用先从知识库中检索出相关内容，再把问题和检索到的上下文一起组装成提示词，交给模型生成答案。

简单来说，它把搜索引擎和文本生成器结合在了一起。

形象类比：开卷考试

没有RAG的模型，相当于参加闭卷考试，全靠脑子里的记忆答题，遇到没学过的内容就只能瞎编。

有了RAG，模型相当于参加开卷考试，可以先在参考资料里查到对应的知识点，再基于资料写答案，准确率和真实性大幅提升。

5.3.3 两类主流检索技术

根据匹配逻辑的不同，检索分为两大技术路线：词汇检索与神经检索。

1. 词汇检索（Lexical Retrieval）

核心逻辑：关键词匹配，检索和查询字符串包含完全相同单词的片段，本质就是常用的Ctrl+F搜索的升级版。
相似度计算：杰卡德相似度（Jaccard Similarity）
分数 = 两个文本的交集词数 / 两个文本的总不重复词数
计算前通常需要先做预处理：移除停用词（the、and这类无意义虚词）、词干提取（walking还原为walk），提升匹配的准确度。
优点：速度极快，结果可解释性强；对于零件编号、专有名称、ID、精确引文这类场景效果极佳。
缺点：无法处理同义词。比如搜索"背包（backpack）"，匹配不到"帆布背包（rucksack）"，哪怕二者意思完全一样。

2. 神经检索（Neural Retrieval）

核心逻辑：语义匹配，基于嵌入向量匹配含义，而不只是拼写。它能理解"犬类"和"狗"是相关的，甚至能实现用英文查询匹配法语文档。
实现原理 ：
通过嵌入模型（Embedding Model）将文本转换成高维向量（一组浮点数），语义相近的文本，在高维空间中的距离也更近。
这项技术的基础可以追溯到Word2vec模型，它首次实现了将单词的含义编码为向量空间中的位置。
优点：支持同义词匹配、跨语言匹配，能理解语义相似度，适配自然语言查询的模糊需求。
缺点：对于精确编号、冷僻术语的匹配效果弱于关键词检索；可解释性差，无法直观说明为什么匹配了这段内容。

场景选型建议

有大量领域术语、产品编号、精确名称的场景，优先用词汇检索；

用户用自然语言提问、查询语义模糊的场景，优先用神经检索；

工业级的RAG系统，通常会将二者结合使用，兼顾精准度和语义匹配能力。

5.3.4 神经检索的完整流水线

一套标准的神经检索RAG，分为三个核心步骤。

步骤1：片段化（分块）

将长文档切割成大小合适的小块，每个块对应一个嵌入向量。

分块原则：长度不超过词元限制、每个块只讲一个核心意思、大小适合放进提示词。
常见分块方式：
- 滑动窗口：固定窗口大小+步长，支持重叠，避免内容被截断；
- 自然边界：按段落、章节等天然结构拆分。
重叠设计：块与块之间保留一定的重叠区域，可以提升内容的连续性，但会增加片段数量与存储成本。
补充上下文：如果片段是一个函数，最好附带周围的类定义、初始化信息，让嵌入向量能更准确地表达完整语义。

步骤2：嵌入（向量化）

将所有文本片段传入嵌入模型，转换为对应的向量。

嵌入模型 ≠ 大语言模型：它的输出是向量而不是文本，通过对比预训练的方法训练而成，目标就是让相似的输入对应相近的向量。
特点：参数量和成本远低于大语言模型，因此可以用来处理海量的文本语料库。
选型建议：入门优先使用托管API，简单易上手；对延迟和成本有要求的场景，可以考虑自托管。通用场景下现代嵌入模型都能同时处理文本和代码；特殊语言或垂直领域，可以选用专用嵌入模型，甚至自行训练，难度远低于训练大模型。

步骤3：索引与检索

将所有向量存储在向量数据库中，查询时先把用户问题也转成向量，再在向量库中查找距离最近的若干个片段，也就是最近邻搜索。

向量检索的技术演进

基础方案：K近邻（KNN）
原理简单直观，但时间复杂度是O(n)，数据量越大速度越慢，只适合小数据集。
优化方案：空间划分（KD树）
通过空间划分将时间复杂度降到O(log n)，是近似最近邻（ANN）搜索的经典方案。
工业主流：HNSW
基于图的近似最近邻索引，是当前的主流方案。FAISS等开源库已经实现了成熟的快速向量检索，足以支撑常规的RAG工作流。
产品形态：不想自己搭建运维向量存储，可以使用Pinecone这类托管式向量数据库服务，降低运维成本，更易扩展。

5.3.5 RAG演化

RAG技术从诞生到现在，已经经历了三代架构的演进，能力逐步增强。

第一代：朴素RAG（Naive RAG）

最基础的三段式流程：

索引阶段：文档均匀分块 → 生成嵌入 → 存入向量库
检索阶段：用户查询向量化 → 检索Top K相关片段
生成阶段：查询+检索片段组装成提示 → 交给大模型生成答案

结构简单、容易实现，但检索准确率有限，容易出现无关内容、遗漏关键信息。

第二代：高级RAG（Advanced RAG）

在朴素RAG的基础上，在检索前后都增加了优化环节：

索引优化：滑动窗口分块、细粒度拆分、保留文件结构、补充元数据
检索前处理：查询重写、问题澄清、检索路由、查询扩展
检索后处理：重排序、内容过滤、提示压缩

整体流程：索引优化 → 检索前处理 → 检索 → 检索后处理 → 生成

效果比朴素RAG大幅提升，是当前企业级应用的主流方案。

第三代：模块化RAG（Modular RAG）

将RAG拆分为多个独立可替换的模块，比如检索、重排序、改写、融合、记忆等，可以根据需求自由组合、替换模块，适配不同的业务场景。代表方案如DSP、Rewrite-Retrieve-Read等，灵活性和扩展性最强。

5.3.6 RAG的三大核心问题

RAG领域的前沿研究，基本都围绕三个核心问题展开：

检索什么？：检索的粒度是什么？是词元、短语、块、段落、实体，还是知识图谱？
什么时候检索？：多久检索一次？是单次搜索，还是每生成N个词元就检索一次，或是自适应按需检索？
检索结果怎么用？：检索到的信息用在哪一层？是直接放在输入层，还是注入模型中间层，或是用于输出层校验？

5.3.7 主流RAG技术栈

目前行业内有四类成熟的RAG开发框架，各有优劣：

框架名称	优势	劣势
LangChain	模块化、功能全面	行为一致性差，API封装过深，复杂度高、灵活性低
LlamaIndex	专注RAG场景，深度优化	需要配合其他框架使用，自定义程度有限
FlowiseAI	上手简单，可视化工作流	不支持复杂场景
AutoGen	适配多智能体场景	效率较低，需要多轮对话

5.3.8 RAG的适用场景

RAG并非万能方案，它在以下场景中价值最突出：

数据呈长尾分布，大量低频内容无法通过微调覆盖
知识更新频繁，需要快速迭代知识库
答案需要可验证、可追溯来源
垂直领域的专业知识问答
需要保护数据隐私的场景

它的应用范围覆盖了问答、摘要、事实核查、对话、机器翻译、代码生成、常识推理等众多领域。

实战落地示例：图书推荐系统的RAG实现

检索阶段：根据当前书籍信息，从用户历史评价库中检索出相关的过往评论。

提示组装：把书籍简介、相关历史评价组合成提示词，要求模型按1-5分打分。

生成阶段：模型结合用户历史偏好，给出评分和理由。

运行效果：系统检索到用户"讨厌背包旅行题材""不喜欢热带背景"，模型基于这些信息给《海滩》打出2/5分，并给出贴合用户偏好的理由，推荐精准度远高于通用模型。

5.4 摘要技术：上下文压缩

5.4.1 上下文瓶颈与压缩方案

哪怕是128k词元的大窗口模型，也不可能把整个图书馆、整个代码库都塞进单次提示里。同时，词元越多，调用成本越高、响应速度越慢。

这就是上下文瓶颈 ，对应的解决方案就是摘要（Summarization） 。

摘要是一种信息压缩手段，而所有压缩都是有损的------压缩率越高，丢失的细节就越多。

5.4.2 分层摘要：分治式压缩

当文本特别长的时候，我们可以采用分层摘要（Hierarchical Summarization）的分治策略：

将长文本拆分为多个语义块（比如按章节、文件拆分）
对每个块分别生成摘要
再对所有摘要做二次摘要，得到最终的总摘要

这种递归压缩的方式，可以处理任意长度的文档。

风险：谣言问题

分层摘要有一个天然的缺陷：每一次摘要都有概率产生误解、偏差，而上层的摘要会基于下层的错误继续生成，误差会逐层累积放大，这就是"谣言问题 "。

就像传话游戏一样，传的次数越多，内容和原意的偏差就越大。因此分层的级数不宜过多，要在压缩率和准确率之间做平衡。

5.4.3 通用摘要 vs 特定摘要

根据用途不同，摘要分为两类，适用场景完全不同：

通用摘要

目标：捕捉文本的核心主旨
优点：可以在不同查询中重复使用，离线生成一次即可
缺点：信息损耗大，可能会漏掉特定查询关心的细节
示例："我的泰国旅行总结"，不会提到在飞机上读了什么书。

特定摘要

目标：针对某个具体问题提取信息
优点：针对当前任务准确率很高
缺点：成本高，用户换一个问题就要重新生成一次摘要
示例："总结我这次泰国旅行中提到的所有书籍"

选型原则：如果是通用背景介绍，用离线通用摘要；如果是回答具体问题，用按需生成的特定摘要。

本章完整总结

本章系统讲解了上下文工程的完整知识体系，核心结论如下：

提示内容分为静态内容与动态内容两大支柱：静态内容定义任务规则，通过显式指令与少样本示例实现；动态内容提供专属上下文，随用户与场景实时变化。
少样本提示存在三类风险：上下文扩展性差、锚定偏差、虚假模式识别，使用时需要注意示例的多样性与顺序随机性，避免误导模型。
RAG是注入外部知识的行业标准架构，解决了模型知识截止与私有数据访问两大问题，相当于让模型从闭卷考试变成开卷考试。
检索分为词汇检索与神经检索两类：词汇检索靠关键词匹配，精准高速，适合编号与专有名词；神经检索靠语义向量匹配，支持同义词与跨语言，适配自然语言查询。工业场景通常二者结合使用。
神经检索RAG包含分块、嵌入、索引检索三个核心步骤，架构从朴素RAG、高级RAG演进到模块化RAG，灵活性与效果持续提升。
摘要是解决上下文瓶颈的核心手段，分层摘要可处理超长文本，但存在误差累积的谣言问题；通用摘要与特定摘要各有优劣，需根据场景选型。

课后思考与参考答案

思考题1

为什么说"少样本示例的优先级往往高于显式文字规则"？请结合大模型的底层特性说明原因。

参考答案

核心原因和大模型的模式匹配本质直接相关：

大模型的底层是词元预测器，天生的行为逻辑是"延续前文的模式"，而不是"理解并遵守文字规则"。示例是直接的模式范本，和训练数据的形式高度一致，模型本能地会去匹配延续。
显式的文字规则是抽象的描述，需要模型先理解语义再约束自身行为，对模型来说是更弱的引导信号。当示例模式和文字规则冲突时，模型通常会优先遵循示例的模式。
因此对于语气、格式、风格这类难以精准描述的要求，用示例示范比写规则更可靠。

思考题2

某企业要搭建内部产品手册问答机器人，产品包含大量型号编号、规格参数，同时员工也会用自然语言提问。请问检索方案应该如何设计？说明理由。

参考答案

应当采用词汇检索+神经检索结合的混合检索方案，理由如下：

产品手册包含大量型号编号、规格参数，这类精确内容适合用词汇检索（关键词匹配），可以精准命中对应编号的文档，不会出现语义偏差，准确率高、速度快。
员工用自然语言提问的场景，适合用神经检索做语义匹配，可以理解用户的模糊表述，即使用词和手册里不完全一致，也能找到对应的相关内容，提升问答的容错性。
混合方案可以兼顾两种场景的优势：精确查询靠词汇检索保证准度，模糊查询靠神经检索保证召回，最终结果经过重排序后再送入模型，整体效果最优。

思考题3

什么是契诃夫之枪谬误？在搭建RAG系统时，为什么"检索召回的内容不是越多越好"？

参考答案

契诃夫之枪谬误指的是：只要被放进提示上下文里的信息，大模型就会默认它是重要的，倾向于在输出中使用它；无关信息会误导模型，让它强行建立错误的关联，引发幻觉。
检索内容并非越多越好，原因有三点：
- 无关内容会触发契诃夫之枪谬误，引入错误的关联逻辑，降低答案准确率；
- 过多内容会挤占上下文窗口，挤占指令与输出的空间，同时增加词元成本；
- 冗余信息会稀释核心内容的权重，干扰模型的判断，反而让关键信息被淹没。
  因此RAG的检索核心是"精准"而非"量大"，只召回最相关的内容，效果才最好。