发帖
雷达卡
2025年，托比·拉特克与安德烈·卡帕西正式提出并定义了**上下文工程（Context Engineering）**这一概念。针对单文档场景，四大模块会输出标准化结构化片段，最终汇聚为单次大模型调用的完整上下文；而语料库、多轮对话、工具调用等拓展场景，将在后续文章展开讲解。
本文是《企业文档智能》系列独立配套文章。本系列的核心观点为：企业级RAG是赋能专家，而非替代专家。整套架构依托四大核心模块构建：文档解析、问题解析、检索、生成。各模块均输出标准化结构化数据，最终汇总完成单次大模型调用，这一整套标准化实践，正是行业如今定义的「上下文工程」。本文聚焦单文档RAG场景，多文档语料、多轮对话、工具调用的进阶拓展方案，将在后续更新中详解。
📓 可运行代码笔记已开源至 GitHub：doc-intel/notebooks-vol1
单文档RAG四大模块的架构流程已完全定型：解析模块输出结构化关系数据表；问题解析模块输出标准化结构化解析问题对象；检索模块输出筛选后的文本行数据及检索审计日志；生成模块输出带溯源证据、基于Pydantic结构化校验的答案。整套流程收敛为单次大模型调用，搭配固定系统提示词，结合上游各模块输出组装用户输入内容。
这套成熟流水线如今拥有了专属行业定义。2025年6月，托比·拉特克在社交平台提出：「提示工程（Prompt Engineering）是错误的认知框架，应替换为上下文工程」，并将其定义为：为大模型补齐全部所需上下文，让任务可被合理求解的工程方法。一周后，安德烈·卡帕西对此表示认可，将其诠释为：精准填充上下文窗口、为模型下一步推理匹配最优信息的精细工程科学。短短数月后，该概念登上奥莱利（O’Reilly）技术图书封面，LangChain 也为其搭建了完整的技术分类体系。
本文将基于这一全新视角，重构解读单文档RAG流水线：各模块输出标准化结构化上下文，统一汇总组装后送入大模型；同时固定系统提示词，适配缓存优化。概念的更新并未改动原有架构，但统一了行业表述——让团队能够向审计人员清晰解释系统运行逻辑，也标志着该架构已成为2025年工业界落地的标准化RAG方案。
一、核心概念：定义与覆盖范围
传统提示工程的内涵局限于两点：微调单条提示词的措辞以优化模型效果、编写示例样本让模型对齐输出规范。二者均聚焦单次调用的文本内容本身，边界极窄。
而上下文工程覆盖了单次大模型调用、送入上下文窗口的全部信息，包含：
系统提示词（角色定位、运行规则、示例模板）
检索召回的文档、数据行
多轮对话历史（如有）
工具定义与工具返回结果
记忆数据、临时计算缓存、智能体状态信息
文档、语料库、项目的结构化元数据
用户原始输入指令
在动辄数十次模型调用的长链路智能体场景中，提示词仅为上下文八大组成部分之一，其余全部来自上游模块：检索器、工具、记忆存储、用户画像查询等。工程核心也从「如何撰写提示词」，转变为如何组装上下文、明确各信息来源、保障多次调用的上下文稳定性。
这是真正的标准化软件工程：包含结构化对象定义、组件交互契约、可审计日志、缓存优化机制。2025年诞生的这一概念，只是对工业界早已落地的成熟实践做了标准化命名，拉特克与卡帕西精准总结了一线工程师的通用落地经验。
本系列文章从开篇起，便逐模块落地这套实践。下文将详解单文档RAG中各模块的上下文输出、最终汇聚为模型调用的四类标准化结构，以及对应的落地代码。文末将简要介绍本文未覆盖的拓展场景：多语料库、多轮对话、工具调用，并标注系列后续更新的对应章节。
二、所有模块均输出标准化结构化上下文
上图为本系列架构的核心总结：每个模块都是结构化上下文输出单元，图中模块名称均为代码中真实的 Pydantic 类、数据表字段名，完全对齐工程落地。
1. 文档解析模块
输出结构化关系数据表与全局汇总字典：
line_df：逐行存储文档内容，附带坐标边界信息（bbox）
page_df：逐页存储文档信息，包含页面类型、列数
toc_df：目录结构数据，记录章节起始页、层级深度
image_df：文档内嵌图片数据，包含感知哈希值与元信息
parsing_summary：文档级全局汇总，包含文档类型、总页数、通用字段、内容摘要及解析状态参数
其中，检索模块逐行读取数据表数据，问题解析模块通过文档上下文（DocContext）调用解析摘要的语义信息。
2. 问题解析模块
输出标准化 ParsedQuestion（解析问题对象），所有字段均为固定结构化定义，无自由文本：
keywords：检索专用核心名词短语短列表
intent：固定枚举值的用户意图标签，决定生成阶段的输出结构分发逻辑
structural_hints.pages_hint：用户指定的固定页面定位（如“第三页”）
answer_shape：预期输出格式（文本、数值、日期、列表、表格、地址等），用于匹配生成模型的结构化范式
各字段分别对应下游不同模块的调用逻辑，全程不直接以原始字符串送入大模型。本功能由三篇系列文章完整拆解：
6A 期（问题解析原理）：先解析、后检索的核心逻辑，检索摘要与生成摘要的拆分依据
6B 期（问题解析提取）：从用户输入中提取关键词、范围、输出格式、问题拆解、模糊澄清信息的完整规则
6C 期（问题解析分发）：基于解析结果，自动选择分块策略、模型精度档位、功能启停标记
3. 检索模块
输出筛选后的结构化数据表与审计日志字典：
filtered_line_df：最终送入生成模块的筛选后文本行数据
anchor_pages：锁定的核心页面ID及筛选依据
retrieval_audit：最终选用的检索策略（关键词/目录/大模型仲裁）、目录推理过程、选中章节明细
筛选后的数据用于模型生成，审计日志用于人工复核与问题溯源。该模块的完整落地逻辑分为三篇文章：
7A 期（检索即筛选）：企业RAG核心思维——缩小候选集范围，而非盲目全局搜索
7B 期（锚点检测）：并行运行关键词、向量嵌入、目录检索，精准定位核心页面
7C 期（大模型仲裁）：通过单次大模型调用，筛选最优候选页面并输出可解释理由
4. 生成模块
唯一的消费型模块（无独立结构化输出）。该模块接收解析问题、筛选文本、上下文聚合对象、输出范式，调用大模型后返回经过 Pydantic 结构化校验的标准化答案。模块虚线边框即代表这一核心定位。
右侧紫色「提示词组装」区域，是上下文工程的核心代码实现层，依托三大基础组件落地：
PromptContext 聚合器：基于基础模型构建，为各类上下文预留独立字段（文档上下文、未来语料库上下文、未来项目上下文）
模块级固定系统提示词：各模型调用模块均配置全局固定系统提示词常量
用户模板：内置占位符，通过字符串格式化动态填充上下文内容
本系列往期文章逐步搭建了这套体系：第1期搭建基础四模块流水线；6A期实现问题解析结构化；8A期实现生成输出范式结构化。本文将基于全新的上下文工程视角，重构解读整套架构：各模块如何输出独立上下文、如何无损汇聚至模型调用层、如何实现上下文隔离无干扰。架构代码不变，核心认知全面升级。
三、单文档RAG的四类标准化上下文输入
单文档RAG的单次模型调用，仅包含四类结构化输入，每类由独立代码生成，具备专属的成本与缓存特性。以下按模型读取顺序逐一详解。
3.1 固定系统提示词
第一类为系统指令，包含模型角色定位、执行规则、示例范式，全局调用统一固定。工程实现上，将其定义为Python模块级常量，同时支持传参覆盖，适配不同业务场景，无需修改底层代码：
（示例代码）
PARSE_QUESTION_SYSTEM_PROMPT = (
"You extract content noun phrases from the user's question..."
)
def parse_question(question, *,
system_prompt: str = PARSE_QUESTION_SYSTEM_PROMPT,
user_template: str = PARSE_QUESTION_USER_TEMPLATE,
context: PromptContext | None = None):
...
该设计带来两大工程优势：一是可被大模型服务商缓存，缓存推理成本仅为全新输入的十分之一；二是可审计、可追溯，支持版本比对、全局检索，便于迭代管控。
3.2 调度器筛选后的召回文本行
第二类为模型最终读取的文档文本。调度器基于解析问题的关键词、结构提示，匹配最优检索策略（关键词/目录/大模型仲裁），输出筛选后的文本数据与审计日志。
（核心调用代码示例）
retrieved, filtered_line_df, audit = dispatch_page_retrieval(
question, line_df, page_df,
toc_df=toc_df, keywords=keywords,
top_k=5, use_toc=True,
)
送入模型的仅为筛选后的核心内容，而非完整文档。一份200页的合同文档，最终仅保留十余页有效文本，严格控制上下文token总量。审计日志完整记录页面筛选依据，支持人工核验、争议复盘，无需重复调用模型。
3.3 紧凑JSON文档上下文块
第三类为文档全局结构化摘要，包含文档类型、总页数、核心字段、内容摘要，以极简JSON格式嵌入用户输入，帮助模型结合文档属性消解歧义。
工程上通过Pydantic模型统一实现，自动过滤空值、空字段，最小化传输体积：
class DocContext(BaseModel):
doc_type: str | None = None
n_pages: int | None = None
typical_fields: list[str] = []
summary: str | None = None
def as_prompt_json(self) -> str:
payload = {k: v for k, v in self.model_dump().items()
if v is not None and v != []}
return json.dumps(payload, separators=(",", ":"))
以单页简历文档为例，该JSON报文体积不足200字符；若无有效文档信息，则返回空对象并自动省略该模块。后续拓展的语料库上下文、项目上下文，均复用该标准化极简渲染逻辑。
3.4 顶层PromptContext聚合器
第四类为顶层上下文聚合容器，所有模型调用模块均支持可选传入该对象。当前仅启用文档上下文字段，同时预留语料库上下文、项目上下文扩展字段，适配后续迭代升级。
class PromptContext(BaseModel):
doc_context: DocContext | None = None
# corpus_context: CorpusContext | None = None # 预留拓展字段
# project_context: ProjectContext | None = None # 预留拓展字段
工具函数自动遍历非空上下文字段，分层渲染独立JSON块并嵌入用户输入。新增上下文类型时，仅需启用预留字段、补充少量渲染逻辑，所有模型调用模块可自动适配，接口签名全程稳定，无兼容性破损。
四、落地价值：概念更新带来的三大工程优化
即便底层代码无任何改动，上下文工程的标准化定义，依然带来了审计、成本、架构拓展三大维度的规范化升级。
1. 可审计性升级
模型回答出错时，排查逻辑从「提示词写了什么」升级为「本次调用的完整上下文窗口包含了什么」。本架构持久化存储所有模块输出数据：解析结果、结构化问题、检索页面、审计日志，可完整复现每一次调用的上下文全貌。
问题定位精准落地到具体模块：文档上下文信息错误、检索页面筛选失误、系统提示词版本漂移、用户模板过期，不同问题对应专属修复方案，彻底告别模糊排查。
2. 推理成本可控可量化
双重优化叠加降本：固定系统提示词全程复用，享受服务商缓存低价策略；用户输入上下文通过结构化压缩、精准检索筛选，动态变量体积最小化。
百份文档、单文档10次提问的千次调用场景中，可变成本成为核心开销。上下文工程让每一段上下文的来源、生成逻辑、成本消耗清晰可追溯，预算管控精细化。
3. 架构可拓展、无破坏性迭代
顶层聚合器预留拓展字段，后续新增多文档语料、项目维度上下文时，无需重构现有代码、无需改写历史逻辑。仅需新增字段、补充渲染分支，所有原有模块自动适配新上下文能力，完美实现版本平滑迭代，规避架构破碎风险。
五、本文未覆盖的拓展场景与后续规划
本文仅聚焦单文档RAG场景，完整的上下文工程还包含三大核心拓展方向，将在系列后续文章详解：
1. 语料库上下文
跨多文档问答场景中，模型需要感知整体语料范围、文档共性与关联特征。后续将推出专属CorpusContext结构化模型，基于所有单文档解析摘要聚合生成，预留字段可无缝接入现有架构，无需改动接口。
2. 多轮对话历史
多轮聊天场景需要留存历史问答对，作为新问题的推理依据。这不仅是上下文问题，更是状态管理问题（历史存储、摘要压缩、冗余裁剪），后续将独立作为核心模块详解。
3. 工具调用上下文
智能体循环会将工具定义、工具返回结果、中间运行状态送入上下文窗口，多轮迭代极易造成上下文溢出，带来信息筛选、压缩、隔离的核心难题，后续将专项讲解智能体场景的上下文工程实践。
LangChain 提出的四大上下文工程策略（编写、筛选、压缩、隔离）中，编写、筛选可直接适配单文档RAG；压缩、隔离的核心价值将在多语料、多轮对话场景中充分体现，因此本文不做强行对齐。
在线演示
ShipAI 仪表盘上线实时演示功能：可在审计轨迹中选中核心页面，切换锚点/段落/章节/全文四种上下文范围，直观对比推理精度与调用成本的权衡关系。
四种范围定义：锚点（单行核心内容）、段落（前后5行上下文）、章节（基于目录的完整章节）、全文（整页内容），将抽象的工程取舍转化为直观可调试的可视化操作。
六、结语
2025年兴起的上下文工程，为单文档RAG的成熟落地实践赋予了标准化定义。整套架构逻辑清晰闭环：解析模块输出结构化文档数据，问题解析模块输出可分发的标准化问题，检索模块输出精准筛选结果与审计日志，生成模块依托固定提示词、模板化用户输入、分层聚合上下文，完成标准化推理。
概念升级的核心价值在于统一行业沟通语言，便于审计、招聘、技术对接，无需额外翻译解释。而底层的模块架构、结构化范式、成本缓存取舍逻辑完全不变。多语料库、多轮对话、工具调用等进阶场景，均已预留标准化拓展字段，可无缝迭代升级。
推荐学习书籍 《CDA一级教材》适合CDA一级考生备考，也适合业务及数据分析岗位的从业者提升自我。完整电子版已上线CDA网校，累计已有10万+在读~ !
京公网安备 11010802022788号
