上下文工程：让 LLM 用好「上下文」
📅 主题：Context Engineering — 上下文设计、窗口管理与少样本
一、什么是上下文工程
上下文工程（Context Engineering） 指的是：有意识地设计、组织和管理输入给大语言模型（LLM）的整段内容，使模型在有限上下文窗口内获得最有助于完成任务的背景与指令。
和「只写好一句 Prompt」不同，上下文工程关注的是：
- 整段输入：系统提示、历史对话、文档片段、示例等如何组合
- 上下文窗口：如何在长度限制下取舍、裁剪、排序
- 信息密度与结构：什么该放、什么不该放、谁先谁后
可以说：Prompt 工程管「说什么」，上下文工程管「整体摆什么、怎么摆」。
二、上下文的构成
一次请求里，模型看到的「上下文」通常由几部分组成（不同产品命名不一，本质类似）：
| 部分 | 作用 | 常见内容 |
|---|---|---|
| 系统提示 / System | 定角色、规则、格式 | 身份设定、禁止事项、输出规范 |
| 用户消息 / User | 当前轮次的真实请求 | 问题、任务描述、附加材料 |
| 历史对话 / History | 多轮对话的过往内容 | 上一轮 Q&A、澄清、修正 |
| 检索 / 注入内容 | 从外部注入的知识 | RAG 查到的文档、数据库结果 |
| 示例 / Few-shot | 输入输出样例 | 1～N 个 (输入, 输出) 对 |
| 思维过程 / CoT | 推理步骤（若保留） | 「让我们一步步思考」后的中间推理 |
上下文工程要做的，就是合理设计每一块的内容与顺序，并在不超长的前提下保证关键信息不被截断。
三、上下文窗口与长度管理
3.1 上下文窗口是什么
上下文窗口（Context Window） 是模型单次请求能接受的最大 token 数（含输入 + 输出）。例如 8K、32K、128K、200K 等。超出部分会被截断或拒绝。
- 输入：系统提示 + 历史 + 当前用户消息 + 检索/示例等，全部算在「输入 token」里。
- 输出：模型生成的回复单独算「输出 token」，一般也受 max_tokens 限制。
3.2 长度管理原则
优先保证「必须有的」
- 系统提示里的硬性规则（安全、格式、角色）尽量保留。
- 当前用户问题与直接相关的检索片段不要裁掉。
历史对话可裁剪
- 保留最近几轮或与当前问题明显相关的轮次。
- 更早的可以总结成一小段「背景摘要」再放入，而不是全文堆叠。
RAG 结果要精选
- 检索 Top-K 后，可再做重排序或摘要，只把最相关的几段放进上下文，避免「塞满文档、淹没问题」。
示例求精不求多
- Few-shot 示例 1～3 个往往足够；示例过长会挤占空间，且可能干扰对当前任务的关注。
长文档策略
- 超长文档：先分块、检索再注入，而不是整篇塞进上下文。
- 若必须用长上下文模型「整篇读」，可把问题放在文档之后，并明确写出「请根据上文回答」。
四、上下文设计实践
4.1 顺序与结构
常见且稳定的顺序是：
[系统提示] → [可选：少样本示例] → [历史对话摘要或最近几轮] → [当前轮：检索内容 + 用户问题]- 系统提示在前：先定调角色与规则，再给具体任务。
- 示例紧跟系统：让模型先「学会格式/风格」，再处理真实输入。
- 检索内容靠近问题：和当前问题相关的文档片段放在同一轮、问题附近，便于模型对齐「依据」与「问题」。
- 历史在后或摘要：避免最早几轮把「当前轮」挤到窗口末尾（有些模型对末尾更敏感）。
4.2 少样本（Few-shot）在上下文中的用法
Few-shot 即在上下文中放入若干「输入→输出」示例，不更新模型参数，仅通过示例引导生成。
- 作用：规范格式、展示推理风格、约束输出结构。
- 建议：
- 示例与当前任务高度相关、格式一致。
- 1～3 个典型示例即可；过多会占 token 且可能过拟合到示例风格。
- 示例可放在系统提示后、用户问题前，便于模型「先学后做」。
4.3 思维链（Chain-of-Thought）与上下文
思维链（CoT） 是在上下文里引导模型「先推理、再给结论」，例如：
- 在系统或用户消息中加入：「请先一步步分析，再给出最终答案。」
- 在 Few-shot 示例里展示「推理过程 + 最终答案」的写法。
这样，模型会倾向于在生成的前半段输出推理步骤，后半段输出答案。若你只关心答案，可解析最后一段；若需要审计或教学，可保留完整 CoT 在上下文/日志中。
五、与 RAG、Prompt 的关系
- RAG：负责「从外部知识库里选出该放进上下文的内容」；上下文工程负责「把这些内容放在哪、放多少、以什么形式放」。
- Prompt 工程：负责单条指令的表述（清晰、具体、无歧义）；上下文工程负责整段输入的布局、长度和优先级。
三者配合：好的 Prompt + 合理的 RAG 检索结果 + 有意识的上下文设计，才能在高 token 成本下得到稳定、可控的生成效果。
六、小结：上下文工程要点
- 明确「整段输入」的组成：系统、历史、检索、示例、当前问题，各占多少、谁先谁后。
- 在窗口限制内做优先级：必保留的（系统规则、当前问题、关键检索）优先；历史与示例可裁剪或摘要。
- 少样本求精：1～3 个高质量、同格式示例，紧接系统提示。
- 思维链可显式要求：在系统或示例中体现「先推理再答案」，便于复杂任务。
- 长文档用检索+注入：避免整篇塞入；检索结果精选后再放入当前轮，靠近问题。
把「上下文」当作一种可设计、可迭代的工程对象，而不仅是「把能想到的都塞进去」，就是上下文工程的核心思路。