企业文档智能：从最小到语料库规模逐砖构建RAG系列

标题：企业文档智能：从最小规模到语料库规模，逐步构建 RAG 的系列文章

来源网址：https://towardsdatascience.com/document-intelligence-a-series-on-building-rag-brick-by-brick-from-minimal-to-corpus-scale/

发布时间：2026-05-22T15:00:00+00:00

Markdown 内容：

生成式 AI 全面爆发，RAG 成为了“我们有文档，想提出问题”这一需求的标准答案。这个概念听起来近乎神奇。而每个人描述的实现方式都一模一样，一遍又一遍地重复着：

• 对文档进行切块，
• 将这些文本块推入向量存储中，
• 对问题进行嵌入，
• 使用余弦相似度检索前 k 个最相关项，可选地重新排序，
• 将结果发送给大语言模型（LLM）

供应商们趋之若鹜，咨询公司的演示文稿趋同于此，会议演讲也莫不如此。

_大家所描述的 RAG 方法：切块、向量存储、top-k 余弦相似度、可选重排、LLM —— 图片由作者提供_

然后部署开始上线，但结果往往令人失望。

• 用户对答案缺乏信任。
• 引用模糊或缺失。
• 检索出的内容常常与主题无关，而非真正有用。

团队的第一反应总是从同一个工具箱里拿出更多工具：

• 更强的模型，
• 更长的上下文窗口，
• 更好的重排器，
• 生产端更多的 MLOps 工作。

框架始终如一：“这是个 IT 问题。更好的基础设施、更好的工具、更好的模型就能解决。”

我开始亲自研究这个问题，在真实的企业文档上操作，并邀请真正的领域专家参与其中。我的经验并不符合这种说法。

真正产生实际效果的工作并不是基础设施层面的改进，而是工程实践，加上对业务领域的理解，再加上一点底层数学知识——不是高深的数学，只是足够了解嵌入向量到底衡量了什么，重排器究竟做了什么，为什么某种技巧在某些情况下有效而在另一些场景下却适得其反。此外还有一个大多数团队忽略的部分：深入了解系统需要回答问题的那些文档本身。谁会阅读它们？里面包含哪些内容？专家使用什么样的词汇？每周都会出现哪些问题？

大多数公司不是谷歌，也不是科研实验室。 它们不会在整个开放网络上运行开放式问答任务，也不会训练自己的嵌入模型。它们只有几种核心类型的文档，几十位已经对该语料库非常熟悉的领域专家，以及一组反复出现的问题，这些问题的答案必须附带引用和审计轨迹。在这种背景下，正确的架构既不是厂商宣传的那种方案，也不是研究论文追求的方向。它应该是一种能够增强专家能力、并在可行之处采用低成本且可预测的检索机制的架构。

我在企业生产环境中见过的大部分 RAG 系统还不如一个一百行左右的 Python 脚本。 基础环节存在缺陷，往上叠加再多东西也无法改善。嵌入表示的意义太模糊以至于无法选出正确段落；解析过程粗糙导致 LLM 输入垃圾输出也是垃圾。

当这样的系统开始出现问题时，标准做法就是增加层级结构：

• 加入一个重排器，
• 微调一个没人能判断是否有效的嵌入模型，
• 添加查询改写代理，
• 设置评分代理，
• 引入编排框架使得每个问题都要触发十次 LLM 请求。

每一层都让演示看起来更合理一些。然而没有一层解决了根本问题：仍然无法确认检索出来的段落是否正确，也无法向用户解释为何返回特定页面。

我们在第一篇文章中构建的那个脚本大约只有一百行代码，而且不依赖任何向量数据库、框架或者代理组件。

该脚本接收一份 PDF 和一个问题作为输入，经过解析后通过简单的余弦相似性找出前三页相关内容，将其连同 Pydantic 模式定义一起送入 LLM 处理，最后以结构化形式返回答案并标注出处及高亮源文件中的对应位置。

比起许多我近距离接触过的正式上线系统而言，这个脚本更加可靠也更有价值。两者之间的差距并非源于提示词工程技巧，也不在于采用了更高明的检索算法。真正区别来自于业界普遍忽视的三个习惯：熟悉文档本身、了解专家已有的知识储备，以及不把 RAG 错误地当作机器学习来看待。

本系列将这三个良好习惯整合进一套四步构建流程之中：文档解析、问题解析、信息检索、内容生成，并可选择性加入一步 PDF 注解处理来把引文反馈给读者查看。

_四个步骤加 PDF 注释功能，各箭头上均标示数据名称 —— 图片由作者提供_

1. RAG 在企业中的应用[](file:///C:/Users/shike/Documents/Github/rag/book/00_announcement.html#how-rag-is-used-in-enterprise)

1.1 2020 年论文：将检索视为上下文[](file:///C:/Users/shike/Documents/Github/rag/book/00_announcement.html#the-2020-paper-retrieval-as-context)

2020 年 5 月，Facebook AI Research 的 Patrick Lewis 及其同事在论文《_面向知识密集型 NLP 任务的检索增强生成_》(Lewis 等人，2020，arXiv 预印版) 中首次提出了这一术语。摘要部分明确指出了该架构旨在解决的三大弊端，现直接引用如下：

预训练模型“难以轻松扩展或更新记忆、不能直观展示预测依据，还可能产生‘幻觉’”。解决方案结合了一个生成器（BART）和维基百科上的密集向量索引，在推理阶段实时访问。关键性的架构创新在于：从语料库中提取一段文字，交给 LLM，让它基于这段上下文而不是仅凭训练期间的记忆来进行生成。

这三个缺陷恰好对应企业级 RAG 所追求的三个特性：语料库的新鲜度、引用溯源、基于事实的回答。本系列正是延续了 2020 年提出的思路，并将其应用于企业场景中的限制条件。

1.2 本系列中“RAG”的含义 [](file:///C:/Users/shike/Documents/Github/rag/book/00_announcement.html#what-rag-means-in-this-series)

对今天的大多数开发者来说，“RAG”已经特指一种具体的做法：使用向量存储、通过嵌入相似性检索，最后由一个大语言模型（LLM）生成答案。

但本系列仍会使用“RAG”这个词，不过是在其更广泛的原始意义上：从一组文档中提取信息、搜索信息并回答问题。

检索机制是一种架构允许的设计选择，而不是定义的一部分。本系列所讨论的企业流程很多根本不用向量存储；有些即使用了，也只是多个通道之一，而非基础组件。因此当本文说“RAG”时，请理解为其广义上的概念。

1.3 在企业应用中，信息抽取优先于其他环节 [](file:///C:/Users/shike/Documents/Github/rag/book/00_announcement.html#extraction-comes-first-in-enterprise)

目前流行的 RAG 描述方式（即让 LLM 基于检索到的内容写出一段自然流畅的答案），其实低估了企业在实际工作中是如何使用它的。

大部分工作其实是信息抽取：从文档中提取特定值，此时 LLM 更像是结构化阅读器，而不是写作工具。

• 一位承保人需要保险金额、免赔额和生效日期；
• 合规官需要列出合同终止后仍然有效的条款清单；
• 法务助理则需要知道合同双方当事人的名称。

在这种情况下，LLM 阅读检索出的段落，识别出所需答案，并以带行号引用的形式返回结构化的数据格式。这就是信息抽取，可能伴随一些轻量级的格式调整与清理，但它不是真正意义上的文本生成。

只有在系统已提取并验证过内容的前提下，才允许 LLM 进一步组合新文本。本系列坚持明确划分两个阶段：第一阶段负责提取相关信息并附上引用来源，然后加以校验与审计；第二阶段在此基础上构建更长篇幅的叙述性文字（例如草拟通知或撰写报告摘要）。

这两个阶段分别调用两次 LLM，也形成两层可审计界面。如果一次 LLM 调用同时混合了检索、抽取和创造性写作，则整个审计轨迹就会崩塌。而我们的架构拒绝这种混淆不清的做法。

1.4 从“增强”转向“基于事实” [](file:///C:/Users/shike/Documents/Github/rag/book/00_announcement.html#the-shift-from-augmented-to-grounded)

2020 年那篇论文选择了 Augmented（增强）而不是像 _Grounded_ 或 _Conditioned_ 这样的替代词。“增强”这个词汇的选择是有意义的。在 2020 年的框架下，生成器可以自由地将参数记忆与其检索到的片段融合在一起。也就是说，LLM 继续利用预训练期间学到的知识，同时也参考检索结果——两种记忆交织在一起。_Augmented_ 表示已有某种东西存在，而检索只是在其之上增加补充；相比之下，_Grounded_ 则意味着相反的情况：生成完全建立在检索的基础之上，锚定其中，且模型受到约束不能偏离检索所得的事实。

而在企业生产实践中，假设正好相反：每一个事实陈述都必须有对应的检索依据支持；LLM 的参数记忆被排除在答案的事实内容之外，仅用于程序性用途：语法处理、遵循 schema 结构、逐字摘录、对引用数值做算术运算以及推理分析等操作。从 _augmented_ 到 _grounded_ 的转变虽然在术语层面很小，在实践层面却影响深远。比如当 LLM 将一条检索到的条款重新表述成 JSON 字段 coverage_amount: 50000 时，这属于语法和 JSON 格式的程序性转换，我们接受它；但如果它填写了一个字段如 valid_until: "2027-12-31"，而该日期并未出现在检索文本中，这就涉及到了新的事实创造，我们就要阻止这种情况的发生。

本系列沿用了 2020 年论文中的整体架构设计，但进一步限定了 LLM 对其参数记忆的具体使用范围。

_学术型 RAG 混合了内部知识与外部检索信息；而企业级 RAG 只依赖检索来支撑最终输出 —— 图片作者原创_

1.5 大上下文窗口并不能取代 RAG 功能 [](file:///C:/Users/shike/Documents/Github/rag/book/00_announcement.html#long-context-isnt-a-substitute)

即使拥有百万 token 上下文长度的能力，也无法把整个企业的语料库压缩进单一提示词中。因为企业语料通常包含数千至数十万份文件，找到正确的那份仍是每次 LLM 推理前必须完成的任务。此外，即便能从百万 token 中得出一个长上下文的答案，也无法告诉用户哪一页支撑着哪个主张。唯有具备逐行引用能力的 RAG 才能做到这一点。

2. 为何称作“企业文档智能”，而不叫“企业 RAG”？ [](file:///C:/Users/shike/Documents/Github/rag/book/00_announcement.html#why-enterprise-document-intelligence-rather-than-enterprise-rag)

每当介绍这一系列内容时都会反复遇到一个问题，促使我们将命名扩展得更加宽泛些。接下来两个关于作用域的问题有助于完整描绘全貌：一是“企业级”作为架构约束到底意味着什么，二是本系列适用于哪种类型的语料形态。

2.1 RAG 是这项工作的其中一个模式，而非全部 [](file:///C:/Users/shike/Documents/Github/rag/book/00_announcement.html#rag-names-one-mode-of-the-work-not-all-of-it)

严格来说，RAG 是指检索增强问答。本系列所阐述的架构涵盖的内容远不止于此。摄取时的分类、大规模字段提取、版本控制、SQL 聚合、评估、安全：其中多项从任何标准意义上都不属于 RAG 的范畴。第 17 章中的 SQL Agent 完全不是 RAG；它是检索结束、数据系统接管的地方。后续卷中还增加了翻译、摘要、并排比较、涂黑处理等功能，这些同样也不属于 RAG。“文档智能”才是这项更广泛工作的名称；而“RAG”只是它的一种模式，特指问答模式。

_第一卷：深入探讨基于 PDF 的 RAG 问答。第二卷：其他任务，相同方法论——作者供图_

2.2 将“企业级”视为一种架构约束[](file:///C:/Users/shike/Documents/Github/rag/book/00_announcement.html#enterprise-as-an-architectural-constraint)

“企业级”这一限定词并非市场细分概念，而是一种约束条件。语料库是受控的，而非开放网络；专家始终参与其中，系统的作用在于放大他们已有的知识；审计轨迹是强制性的，因为每个答案都可能受到质疑；调度器必须是确定性的，因为结果可重现性至关重要。开放式领域的助手会做出不同的权衡。本系列面向的是在此类约束条件下构建系统的工程师，所有架构选择均由此推导而来。

2.3 本系列处理的语料形态[](file:///C:/Users/shike/Documents/Github/rag/book/00_announcement.html#the-shape-of-the-corpus-the-series-handles)

本系列的主要案例是一个由同质且独立文档组成的语料库：几千到几十万份相同类型的 PDF 文件。当语料混合了多种类型时，第一步是对它们进行分类（见第 15 章），然后对每组分别运行一个同质化处理流程。每份文档单独读取；整个语料索引建立在所有文档之上。

一份案件档案（信贷申请、合同续签、保险理赔）是一小组关于单一实体的不同种类 PDF 文件集合。由于本系列全程专注于 PDF 处理，因此少量小型文件可以简单地拼接成单个文档来对待。这时目录就发挥了作用：多个各自带有目录的 PDF，在合并后就像一个具有嵌套章节的大文档一样被阅读，并且检索模块（第 7 章）已经知道如何导航这样的结构。后续卷会在捆绑包过于复杂或庞大无法粘合时，构建真正的案件档案路由机制，并利用针对不同文档类型的信号。

更复杂的场景则是大量案件档案，每个档案内含多种文档类型：数百个案件，每个包含五至五十份异构文档。在这种情况下所需的编排能力超出了单一语料索引所能提供的范围。出于诚实界定适用范围的目的，本系列明确指出这一点，并将完整解决方案留给后续卷去展开；第四至第五部分构建的基本组件将在那里继续使用。

如果你的数据归档符合上述任一同质化形态之一，则本系列能为你提供端到端覆盖。如果是案件档案形式，请预期本系列带你走完大部分路程，剩下的工作则由后续卷完成。

3. 本系列是什么[](file:///C:/Users/shike/Documents/Github/rag/book/00_announcement.html#what-this-series-is)

《企业文档智能》是一个面向工程师与数据科学家的逐步构建系列，旨在帮助企业文档上的 RAG 构建：包括合同、技术报告、监管申报材料等，错误的回答可能会引发监管调查、合同纠纷或客户退款的情形。该系列聚焦于 PDF 作为文档格式，这是企业在实际查询中最常使用的文档形式。其他格式（如 Word、Excel、PowerPoint 和电子邮件）需要各自的解析和结构逻辑，相关内容将在后续工作中介绍。

“增强专家能力”的立场转化为一系列具体的架构决策，这些决策贯穿整个系列，并与特定章节紧密相关：

• 确定性调度器优于自主代理。 专家可以审查一个确定性的流程。他们无法审查一个自行决定调用哪个工具、提出哪个子问题以及何时停止的代理。代理在演示中节省了工程投入，但在事件发生时却因路由是非确定性的而无法复现，从而付出代价。本系列主张一种调度架构，其中每个路由决策都是显式的、记录在案且可检查的。第 13 篇文章构建了这一架构。
• 向量存储是备选方案，而非基础。 专家已经知道关键词。当基于关键词的检索失败时，向量存储才体现出价值：例如同义句、跨语言、多义词，“夜间停放的车辆”匹配“整夜停车”。它不应作为检索的起点。对于大多数企业语料库来说，结构优先的检索方式（目录、分类、专家关键词）比余弦相似度更有效。第 2 和第 7 篇文章对此进行了深入探讨。
• 专家词典胜过更好的嵌入模型。 领域词汇是系统中最宝贵的资产。同义词、消歧项、交叉等价关系（如“免赔额 = 自付额”，“ShieldPro Elite = 高端房主保险计划”）无法通过 IDF 公式或嵌入相似度恢复；必须从每天使用这些术语的人那里提取出来。第 6 篇文章将词典设为问题解析的核心对象。
• 在企业级 RAG 中，重排序器大多是多余的。 它们只在一种特定场景下值得投入（候选池庞大且通用，上游没有经过策划的处理管道）。本系列所支持的架构设计（专家词典、结构感知检索、先分类再检索）使得它们在关键问题上变得冗余。第 2 bis 篇文章进行了实证测试。
• 拒绝“把一切都连接到向量存储”的模式。 这种模式是为了超大规模云服务商的商业模式优化，而不是为了客户的准确性。应在索引前进行分类，在检索前进行过滤。如果问题是统计性质的，则使用 SQL 聚合。RAG 处理内容查找；SQL 处理计数；语料库索引位于两者之间。第 14 至 17 篇文章将其作为语料库规模架构的核心。

这些选择背后有三个积极原则贯穿每一篇文章。这项工作是实用主义且以专业知识为导向：每一个选择都取决于它是否建立在那些已经理解文档人员积累的知识之上。该架构采用的是金字塔式工程方法：四个命名模块（解析、问题解析、检索、生成），每个模块包含若干个具有明确输入输出的函数，因此资深工程师可以在几分钟内追踪整个请求过程。数据在每个模块中都是关系型的：解析产生表格，问题解析也产生表格，检索查询这些表格，生成写回类型化的行，任何环节都不出现原始字符串。

_一份 PDF 输入，八个关联表输出。后续所有模块均读取这些表——作者供图_

由此衍生出三种哲学立场，并在整个系列中反复出现：嵌入不是魔法（第 2 篇）、RAG 不是机器学习（第 3 篇）、评估应按故障模式进行，而非整体平均（第 20 篇）。

这些观点来源于在受监管行业（保险、法律、金融服务）中构建 RAG 的经验。它们并不是唯一有效的立场，但却是那些错误答案会引发退款、罚款或诉讼的实际生产环境中经得起考验的观点。

4. 系列内容概览[](file:///C:/Users/shike/Documents/Github/rag/book/00_announcement.html#whats-in-the-series)

第一部分：什么有效，什么失效[](file:///C:/Users/shike/Documents/Github/rag/book/00_announcement.html#part-i-what-works-what-breaks)

_构建最小化流水线，观察其破裂点，重新定义学科框架，然后定位自己的案例后再继续推进。_ 每篇文章都会引导进入下一篇文章，因此这四篇可在引入任何工具或框架之前一次性阅读完毕。

_来自第 4 篇文章的 5×5 案例网格。在选择技术前，请先定位你的问题——作者供图_

• 第 1 篇：极简 RAG，从 PDF 到高亮答案。 整个流水线约 100 行代码。PDF 输入，结构化 JSON 输出，并在 PDF 上高亮显示源文本行。
• 第 2 篇：嵌入并非魔法。 RAG 检索中的可预见失败模式：否定、精确值、内部缩写、主题邻近性。这是极简版本开始出现问题的地方。
• 第 2 bis 篇（配套篇）：重排序器也不是魔法。 交叉编码器重排序器能解决嵌入导致的一些字面 token 陷阱，但也共享相同的结构性失败模式（否定、确切标识符、列举、领域外词汇）。编辑立场：仅适用于狭窄情况下的后备手段，不应成为主要阶段。
• 第 3 篇：RAG 并非机器学习。 导致 RAG 项目成本最高的误解之一。RAG 是搜索加上一层生成层，而不是需要训练的模型。
• 第 4 篇：哪种 RAG 技术适合哪类问题。 在做出任何技术选择之前的诊断步骤。将你的问题放置于 5×5 网格中（文档复杂度 × 问题控制程度），然后选择最简单有效的技术。

第二部分：四大构件[](file:///C:/Users/shike/Documents/Github/rag/book/00_announcement.html#part-ii-the-four-bricks)

_解析 → 问题解析 → 检索 → 生成。_ 构成整个系列其余部分的四大构件。使该架构区别于通用 RAG 的地方在于：每个构件都产出关系型结构化数据（链接的数据框、类型化行），绝不会输出原始字符串。整个流水线在各个节点都可以被检查、重放和审计。

_Brick 2 镜像 Brick 1：一个问题，一行数据，关键词和范围的卫星表 – 作者供图_

• 文章 5：优秀 RAG 解析器的丰富输出。 Brick 1：行、表、图像、列、目录、交叉引用。解析时丢失的内容无法在下游恢复。

• 文章 5 附加篇（配套文章）：当 PyMuPDF 看不到表格时。使用 Azure Document Intelligence 进行解析。 同样的八个 DataFrame，第二个引擎。Azure 增加了原生表格单元格、图内 OCR 文本、确定性标题，并在没有原生书签时从段落角色重建目录。parsing_method 列跟踪每行来源，因此自适应解析可以在同一文档上混合使用 fitz 和 Azure。
• 文章 6：RAG 中的问题解析。先结构化再搜索。 Brick 2：问题作为非结构化输入被解析成一组关系型表格，与文档解析对称。
• 文章 7：为什么嵌入在生产环境 RAG 检索中是最后的选择。 Brick 3：检索是过滤结构化 DataFrame，而不是搜索自由文本。嵌入是备选方案，不是默认选择。
• 文章 8：生成即受控执行。 Brick 4：类型化输入（段落加问题），类型化输出（Pydantic）。模式就是契约；每个答案形式对应一个提示模板。

第三部分：单个文档上的流水线[](file:///C:/Users/shike/Documents/Github/rag/book/00_announcement.html#part-iii-pipelines-on-a-single-document)

_由第二部分改进组装而成的完整流水线，然后进一步扩展。_ 文章 1 运行了最小化的端到端流水线；第二部分随后单独改进了每个砖块。文章 9 完成了这个循环：与文章 1 相同类型的演示，在同一篇论文上，整合了所有第二部分的改进。文章 10-12 然后添加特定的复杂性模式：自适应解析（生成告诉解析需要升级）、交叉引用、列表。文章 13 将所有模式组装到协调器中，连接限制迭代的反馈回路，这里是团队积累智慧的地方。

_来自文章 4 的 5×5 案例网格。在选择技术前先定位你的问题 – 作者供图_

• 文章 9：完整的端到端流水线，整合第二部分。 文章 1 最小化运行了流水线。第二部分说明了每个砖块如何独立做得更好。本文运行与文章 1 相同类型的演示，在相同的 Transformer 论文上，整合了所有第二部分的改进：更丰富的解析、带错别字处理的专家关键词问题解析、组合的检索方法（目录加关键词加嵌入，采用分数融合和可选的 LLM 仲裁者）、带有完整模式的结构化生成。在同一组问题上展示从最小化到集成的差距。
• 文章 10：自适应 PDF 解析。 先进行廉价解析；仅在问题需要时才进行高级解析。由生成反馈驱动的自适应升级。
• 文章 11：RAG 如何处理合同和标准中的交叉引用。 "复杂"文档的真正挑战不是长度，而是相互连接。跟随引用的两跳检索。
• 文章 12：当 RAG 需要找到所有答案时：列表问题。 "所有的 X 是什么？" 答案不在一个段落中，而是分布式的。扫描而非 top-k，带有明确的完整性信号。
• 文章 13：从单一 RAG 流水线到多个：复合流水线模式。 将所有模式组装成单一工作系统。协调器和调度器是团队以代码形式积累的智慧；有界的反馈回路、漂移检测和完整审计轨迹也在这里。

第四部分：从单个文档到整个档案库[](file:///C:/Users/shike/Documents/Github/rag/book/00_announcement.html#part-iv-from-one-document-to-a-whole-archive)

_对数千份文档进行天真的嵌入搜索会失败。同样的四个砖块仍然适用，但每个都需要在其前面加上结构性索引。_ 文章 14 通过在五个 NIST PDF 上运行最小语料库流水线来确立论点，这种基线浪费了五次 LLM 调用中的四次，因为没有任何东西预先过滤语料库。文章 15 修复了输入端：层次化的问题级联填充关系型 corpus_index，每份文档一行，列为可搜索字段。文章 16 正式化了驱动级联的本体论，将其定义为由专家手工策划的五个小型表格，并解释了为什么策划的关系层在每个操作轴上都优于 LLM 提取的知识图谱。文章 17 连接查询端：解析问题，过滤索引，仅在 SQL 代理返回的候选文档上运行文档级流水线。

_来自文章 4 的 5×5 案例网格。在选择技术前先定位你的问题 – 作者供图_

• 第14条：你的 RAG 能处理一个 PDF。现在让它能处理一万个。 第四部分论文。朴素向量 RAG 在大规模下的五种失败模式，镜像原理（一份文档用 4 个砖块 → 整个语料库也用 4 个砖块），在五个 NIST PDF 上运行的最小 corpus_qa_baseline 实验展示了浪费所在。
• 第15条：从一堆 PDF 到可查询的 RAG 语料库，一次一个问题。 砖块 1 升级版。通过一系列层级化的问题来填充每个文档的 corpus_index，包含两条执行路径（文件名正则匹配，否则走单文档流水线）以及命名规范化（原始提取 → 规范实体）。在 24 份 NIST PDF 和 30 篇 arXiv 论文上的真实运行结果。
• 第16条：为什么企业级 RAG 需要本体论，而不是知识图谱。 关键基石。专家的知识以五张关系表形式编码（级联规则、概念关键词、概念关系、概念到文档类型的路由、命名规范）。在审计性、成本、维护、时效性和所有权方面均有优势。三个领域（NIST 网络安全、arXiv 自然语言处理/信息检索、虚构保险经纪商）证明该模式具有通用性。“反 GraphRAG” 是其结果，而非口号。
• 第17条：RAG 如何跨语料库回答问题：先 SQL 过滤，再检索。 砖块 2-3-4 升级版。协调器识别意图（列 / 文档 / 混合），运行 SQL Agent 或“过滤后检索”，并调度生成过程。在 NIST 的 corpus_index 上三次真实运行完成了整个架构闭环。

第五部分：生产环境运行[](file:///C:/Users/shike/Documents/Github/rag/book/00_announcement.html#part-v-operating-in-production)

_系统已建成。现在要运行多年。_ 支持多位开发者并行工作的代码架构，存储层保存可重放的产物，针对精心策划的数据集按失败模式评估（避免聚合精度幻象），成本与延迟作为同一存储上 SQL 聚合的结果，并由安全边界包裹整体系统。这些是通用机器学习运维和安全指南未涉及的 RAG 特有问题。

_历经多年演进仍稳定的四层包结构。第18篇文章绘制了函数映射图 —— 图片来自作者_

• 第18条：企业级 RAG 的代码架构：四层结构与函数映射。 经得起时间考验的包布局。四个层次（核心、存储、标注、流水线）依赖方向单一，每脚本一方法，并配有函数映射将每个砖块与其调度器及子功能锚定。
• 第19条：企业级 RAG 的存储设计：一切测量的基础。 包含约三十张关系表分布在五个子模式中，基于两个哈希标识符锚定（file_id, question_id）。采用长格式用于存储，宽视图用于输出。llm_raw_json 字段和 query_log 表是所有评估、成本计算和审计操作读取的目标。
• 第20条：企业级 RAG 的评估方式：衡量流程，而非模型。 基于第19条存储中的结果表连接而成的按失败模式分组的评估（pandas.groupby）。聚合指标会误导；而按问题类型细分的指标才揭示真相。
• 第21条：企业级 RAG 中的成本与延迟：基于存储的度量。 使用与第20条相同的源数据表，但不同的聚合逻辑。包括 Token 数、延迟、告警、版本控制等内容。在经纪域内自托管 Ollama 的一级基准测试。
• 第22条：企业级 RAG 的安全性与合规性。 结尾章节。文档引发提示注入攻击、租户隔离、派生数据的 GDPR 合规、审计追踪、文档级别的访问控制、自托管保密边界：这些都是通用安全指南未曾覆盖的企业专属层面。

加餐文章[](file:///C:/Users/shike/Documents/Github/rag/book/00_announcement.html#bonus-articles)

每一篇都是贯穿多个主要章节的实际关切点，但不属于任何一个独立的部分。

• B01：RAG 中的拼写变体。为何仅靠拼写检查还不够。 四十年的经典拼写纠错技术（编辑距离 Levenshtein、BK树、Soundex、SymSpell）可以解决大多数单词拼写错误。嵌入模型和大语言模型吸收其余部分。对企业级 RAG 来说实用划分在于：解析时对问题进行拼写校正使其符合语料库词汇；对于文档，则一次性清理标准引用即可，保留大量噪声并在检索阶段围绕噪声设计策略。
• B02：FAQ 形式的 RAG。当你能够设计语料库的时候。 相较于系列其他内容而言是一种受控语料库的对照方案。标准 RAG 假设你继承了一个混乱的语料库；而 FAQ 正好相反。解析变得简单，检索本身就起到缓存作用，少样本提示也成为一种检索问题。最后介绍反馈循环机制，使 FAQ 成为由提问流驱动的动态语料库。
• B03：当 RAG 回答“我不知道”。如何解释没有答案的原因。 明确给出错误答案是一个 bug；而没有任何解释地只回复“无答案”几乎同样糟糕。四个砖块各自应向用户提供一条证据：解析了什么、搜索了哪些词汇、扫描了哪些页面、为何没有匹配项。“我不知道”的回应因此具备可审计性而非黑箱状态。
• B04：PDF 中表格用于 RAG。不要展平网格结构。 表格正是大多数 RAG 流水线静默失效的地方。试图使用线性的决策树跨越不同表格类型并不奏效，因为维度相互交叉。正确的做法是四级表示法（line_df 中行即一行、单独的 table_df、带命名且有类型的列式结构、异构列式结构），对每个表格沿五个正交轴做诊断，并提供少量幂等操作实现级别间转换。大部分表格停留在最简单的层级；只有少数真正需要升级才会付出更高代价。

每篇文章都独立成篇。每篇都在前一篇的基础上以一种自然的方式构建：从第一篇文章中的极简流水线，逐步发展为第十八至十九篇文章中的架构以及第二十二篇文章中的安全封装，每个新增部分都是由之前观察到的具体失败所驱动的。

5. 这是写给谁的[](file:///C:/Users/shike/Documents/Github/rag/book/00_announcement.html#who-this-is-for)

正在企业文档上构建 RAG 系统的工程师们。 法律、保险、金融服务、受监管行业等任何错误答案的成本可以衡量的地方。如果你已经部署了一个在演示中有效但在真实用户面前崩溃的 RAG 系统，那么这个系列就是为你准备的。

感觉机器学习直觉与 RAG 不太匹配的数据科学家们。 它们确实不匹配。本系列清楚地阐明了这种差异，并提供了可操作的方法。

需要做出架构决策的技术负责人。 何时使用向量数据库，何时不用；何时值得采用代理模式，何时不值得；何时投资更深入的解析。该系列对这些选择持明确观点并解释其理由。

6. 这不是写给谁的[](file:///C:/Users/shike/Documents/Github/rag/book/00_announcement.html#who-this-isnt-for)

没有内部文档专家的团队。 本系列假设你有或能够接触到那些已经了解你的语料库的人：

• 阅读合同的律师，
• 设定免赔额的承保人，
• 跟踪法规的合规官。

系列中的几乎每一个架构选择都会放大这种专业知识。如果你是在一个内部无人理解的开放领域语料库上构建问答系统，这里的选项将不会适用。有些场景下通用检索和自主代理更有意义；但此系列并不涉及这些情况。

前沿研究人员。 此系列关注的是生产工程实践而非新方法的研究。它会在相关时引用近期研究，但并不会试图推进这些研究。

寻找神奇框架的人。 本系列恰恰相反。它是关于深入了解框架背后的内容，以便做出深思熟虑的选择。有时这意味着使用某个框架。但通常意味着编写一百行简单的代码，比框架提供的效果更好。

7. 本系列未涵盖的内容[](file:///C:/Users/shike/Documents/Github/rag/book/00_announcement.html#what-this-series-doesnt-cover)

本系列专注于基于 PDF 文档 的 RAG：用于问答的搜索和生成。它不包括其他文档格式（Word、Excel、PowerPoint、电子邮件）、并排文档比较、结构化数据与文档结合（数据库）、翻译管道、大规模摘要、文档生成或针对文档的自主代理等内容。

这些都是实际的企业需求。之所以省略它们是因为它们的操作方式不同于“PDF 上的 RAG”。混合在一起会导致混乱的架构，而这正是本系列希望帮助读者避免的问题。

计划在本系列结束后推出的后续卷册会分别处理这些问题：其他文档格式（Word / Excel / PowerPoint / 电子邮件）、并排对比、翻译、摘要、结构化数据与文档结合、文档生成。同样的工程原则应用于不同的问题形态。

8. 如何跟进本系列[](file:///C:/Users/shike/Documents/Github/rag/book/00_announcement.html#how-to-follow-the-series)

文章将以每日一篇的频率按顺序发布，从第一篇开始：_《最小化的 RAG：从 PDF 到高亮答案》_

这篇文章用大约一百行 Python 代码构建了整个流程。通过提出一个工作的最小版本自然引发的问题，为后续所有文章打下了基础。

如果你正在生产环境中构建 RAG，并且认为行业的默认做法是错误的，那么这个系列就是你应该采取的行动指南。