📰 来源：Towards Data Science　|　📅 翻译日期：2026年7月1日
🔗 原文：查看原文
🤖 翻译：DeepSeek AI · 仅供参考

本文定位与系列概述

本文是《企业文档智能》系列的独立配套文章，该系列的核心观点是：企业RAG增强的是专家，而非取代专家。架构由此衍生：四个模块（文档解析、问题解析、检索、生成）各自输出类型化片段，最终汇聚到一次LLM调用。业界如今称这一实践为上下文工程。本文范围限于单文档场景；知识库、对话和工具调用扩展属于后续工作。

本文在系列中的位置：第7bis篇（上下文工程），与四个模块的重新框架化配套——作者绘图

📓 可运行笔记本见GitHub：doc-intel/notebooks-vol1

公共配套代码仓库：doc-intel/notebooks-vol1——作者绘图

四个模块与上下文工程的诞生

当单文档RAG的四个模块构建完成后，组装工作便已就绪。解析产生关系型表格；问题解析产生类型化的ParsedQuestion；检索产生经过过滤的行子集以及选择依据的审计记录；生成产生带引证证据的Pydantic答案。整个过程汇聚到一次LLM调用，使用固定的系统提示词和由上游组件拼接而成的用户内容。

这条流水线如今有了正式名称。2025年6月，Tobi Lütke发推称“提示工程”是错误框架，并提出“上下文工程”：“为任务提供所有必要上下文，使其对LLM而言可合理解决的艺术。”一周后，Andrej Karpathy将其赞誉为“用恰到好处的信息填充上下文窗口以支持下一步的微妙艺术与科学”。数月之内，该术语便登上O'Reilly书籍封面，并由LangChain整理为分类体系。

通过上下文工程看单文档RAG流水线

下文通过这一视角审视单文档RAG流水线：每个模块输出类型化片段；组装阶段将它们编织进LLM调用；系统提示词保持固定以利缓存。命名这一实践并不会改变架构。但可以回答审计员关于系统工作原理的提问，并告知读者该架构正是2025年生产团队所趋同的方案。

1. 名称及其涵盖范围

提示工程过去涵盖两件事：调整单个提示的措辞以诱导更优行为，以及编写示例让模型了解良好输出的样子。两者都过于狭隘，只针对单次调用的一块文本。

上下文工程涵盖一次调用中进入模型上下文窗口的所有内容：

• 系统提示词（角色、规则、示例）
• 检索到的文档或行
• 对话历史（如果有）
• 工具定义及其输出
• 记忆、草稿板、代理状态
• 关于文档、知识库、项目的结构化元数据
• 实际的用户输入

在长时间运行的代理中，模型被调用数十次，提示词只是六到八个槽位之一。其余内容来自上游：检索器、工具、记忆存储、用户画像查找。该学科的焦点从“我应该在提示词里写什么”转变为“我应该在上下文里组装什么、每个片段来自哪里、如何跨调用保持组装的稳定性”。

这是工程工作：它类似于软件架构——类型化对象、组件间的契约、审计追踪、缓存。2025年的这个术语来得正是时候，因为实践早已存在于工作中的生产系统里。Lütke和Karpathy只是命名了团队已经在做的事情。

本系列恰好从一开始就逐块践行了这一理念。以下各节将逐步讲解每个模块如何贡献到单文档RAG的有效负载，然后介绍进入LLM调用的四个类型化片段，以及生成每个片段的代码。知识库、对话和工具调用案例将在文末作为超出范围的工作提及，并给出系列中后续处理的指引。

七个类型化模块，按来源分组：问题、文档、基础设施——作者绘图

2. 每个模块输出类型化上下文

四个模块输出类型化上下文通道，汇聚到顶部的组装带上，其中PromptContext、固定系统提示词和用户模板在LLM调用前合并——作者绘图

上述模式图是本系列已交付内容的总结。每个模块都是一个类型化上下文发射器。方框上的名称是代码实际产生的Pydantic类和DataFrame的真实字段。

解析输出关系型表格和一个综合字典：

• line_df：每行一个条目，携带bbox
• page_df：每页一个条目，携带type和column count
• toc_df：目录条目，携带起始页和深度
• image_df：嵌入的图像，携带phash和元数据
• parsing_summary：文档级综合信息：doc_type、n_pages、typical_fields、summary以及机制字段

检索模块消费每行表格；问题解析模块通过DocContext消费parsing_summary的语义子集。

问题解析输出ParsedQuestion。其字段并非自由格式：

• keywords：用于检索的内容名词短语短列表
• intent：固定枚举中的字面标签，驱动生成阶段的形状分派
• structural_hints.pages_hint：当用户说“在第3页”时，携带固定的页码
• answer_shape：预期输出形状（文本、金额、日期、列表、表格、地址），用于生成模式查找

每个字段由不同的下游模块消费。它们都不会作为原始字符串传递给LLM。

检索输出经过过滤的DataFrame和审计字典：

• filtered_line_df：生成模块看到的line_df子集
• anchor_pages：保留的页面ID及原因
• retrieval_audit：胜出的方法（关键词、目录、LLM裁决）、LLM的目录推理（如适用）以及选中的章节

过滤后的框架是LLM读取的内容。审计则是审计员读取的内容。