企业RAG主流教程中常搞错的10个要点

构建企业级RAG的方法，并且在过程中与许多标准实践持不同意见。RAG不是机器学习；嵌入不是魔法；分块大小扫描优化了错误的目标；答案模式比模型更重要。这些都不是中立的，每一个都会改变你构建的东西。本文汇集了本系列其余部分所论证的立场，然后按文章映射整个系列，以便您可以直接跳转到您想要核实的论点。

本文是企业文档智能的宣言，该系列从四个构建块构建企业RAG系统。十个立场，系列在这些立场上与主流RAG教程分道扬镳，随后是整个系列通过它们的地图。

📓 该系列的配套笔记本位于GitHub上的doc-intel/notebooks-vol1。每个笔记本在一个真实的PDF上端到端运行一个构建块，因此您可以观察这些立场如何实际运作：结构优先检索在任何嵌入之前触发，带行级引用的类型化答案返回，按失败模式而非单一总分进行评估。

标准的RAG教程读起来千篇一律。对文档进行分块，将块推入向量存储，嵌入问题，通过余弦相似度检索top-k，可选地重排序，将结果发送给LLM。供应商演示、框架快速入门和会议演讲都在重复它。该模式在hello-world示例上有效，并开始在一个真实的企业文档遇到它时动摇。

以下是本系列针对该方案所捍卫的十个立场。每一个都是架构所依赖的反复出现的编辑选择。没有一个是单独属于我的。一些实践者的声音推动了这些立场中的一些，这里所做的贡献是将它们视为一个连接的系统，而不是孤立的观点。

如果您只阅读本系列中的一篇文章，并且想要每个具体选择背后的编辑立场，那就是这篇。

这十个分为三个层次。前四个针对教程的检索方案：结构优先、字典先于模型、重排序作为工具而非阶段、永远不要一个向量存储用于所有。接下来的三个设定了方案忽略的框架：企业的真正含义、系统放大了谁、谁在运行时选择路由。最后三个涵盖审计维度：按失败模式评估、构建块之间的关系、引用作为证据。

1. 向量存储是后备，而非基础

默认教程将向量存储作为管道的入口点。一切都通过余弦相似度，然后重排序修补余弦错误的地方。本系列将其反转。结构优先检索处理企业语料库上大多数真实问题的核心。嵌入作为剩余情况的保障，而非默认的第一阶段。

论证不是基准测试，而是可解释性。通过关键字匹配和对照文档声明的目录进行过滤，您可以阅读为什么检索到某个段落：匹配的术语、章节路径、行范围。

使用余弦相似度，您无法做到。向量表示“这两个段落在某些768维空间中接近”，这就是可用的全部解释。

在企业文档上，每一次检索都必须向审计员或领域专家证明其合理性，可解释性差距是驱动架构的因素，而不是recall@k数字。嵌入仍然有其位置，但作为漏斗中的最后方法，而非第一。

出现位置：文章2、7、9、14。

2. 专家字典胜过更好的嵌入模型

同义词问题是嵌入本应解决的问题。Premium匹配cost。Termination匹配cancellation。Franchise匹配deductible。在实践中，由领域专家维护的概念关键词表比现成的嵌入模型更可靠地解决同义词问题，并且通常比微调模型在专家已知的词汇上更好。微调模型在字典尚未捕获的未见措辞和语言上仍然胜出，这就是为什么嵌入作为后备保留在漏斗中。专家知道这些。

Recall@k是人们用来从基准中挑选嵌入模型的指标。它不是生产管道优化的指标。一旦您接受同义词工作属于专家字典，微调就变成了一种奢侈，嵌入变成了一种发现工具。

出现位置：文章2、6、7。

3. 重排序是次要工具，而非主要阶段

交叉编码器重排序在文献中有一席之地。它们位于便宜的嵌入相似度和昂贵的LLM判断之间，并且当候选池很大时，它们才值得其成本。那是重排序论文出现的背景。

本系列捍卫的企业方法在由专家词汇检索、结构感知过滤和分类-之前-检索产生的小型、有范围限制的候选集上工作。到重排序运行时，池子已经很小且已有范围限制，交叉编码器为边际精度增加了延迟和复杂性。该系列将重排序视为边缘案例的备用，而非默认阶段。列表型问题是典型的重排序失败模式。

出现位置：文章2、2bis、7、9、14、20。

4. 拒绝“将所有内容连接到向量存储”

供应商模式是将每种文档类型连接到一个大向量索引中。这是为客户准确性而优化的。该系列将其替换为语料库规模架构：

在索引之前对文档进行分类。

在摄取时将结构化字段提取到语料库索引中。

在检索之前在索引上过滤。

将聚合问题路由到SQL代理，而非RAG。

RAG处理内容查找。SQL处理计数和过滤。语料库索引位于它们之间。向量存储是该索引中的一个可能列，在其赢得位置的地方使用。

出现位置：文章14-20。

5. 公司不是谷歌

“我们是谷歌”的剧本无法转移到企业环境。典型的企业有几百种文档类型、几十个领域专家和一组重复出现的问题，而不是一千万个异构网页的语料库。

本系列中的大多数架构选择都源于拒绝复制粘贴。超大规模风格的检索为网络规模召回和按次计费优化，而非客户的准确性。对几百种文档类型和已知受众的正确架构看起来与谷歌的完全不同。一旦您接受这一点，系列的其余部分就自然随之而来。

出现位置：文章3、14。

6. 放大专家，而非取代他们

企业RAG不是网络上的开放域问答。它在领域专家已经了如指掌的文档上运行。那些专家有词汇、一组消歧义、将问题路由到特定文档类型的习惯。系统的工作是扩展这种判断，而不是绕过它。

大多数架构错误都源于忘记这一点。自主代理绕过专家，未分化语料库上的通用向量搜索忽略他们，微调嵌入模型试图取代他们已经免费知道的东西。本系列捍卫的每一个选择都回到了这个前提。

出现位置：文章3、4、6、13、15。

7. 确定性调度器优于自主代理

“代理式RAG”的推动将代理作为灵活性出售。在实践中，代理在演示上节省了工程精力，并在第一次无法重现的事件中花费十倍。

确定性调度器做了代理所做的事情，除了人类可以阅读代码、审计员可以重播决策、团队的积累智慧活在版本控制中。自主性适合开放工具集和探索性工作。在受监管的企业环境中是错误的，在那里每个路由决策都必须可检查。

出现位置：文章6、13。

8. 按失败模式评估，而非汇总

汇总准确性会撒谎。一个总体95%的系统可能在困难子集上隐藏50%。信任汇总数字的团队会逐个客户投诉地发现那50%。

该系列使用按问题类型和失败模式切分的精选参考数据集。每个失败指标说明真相。RAGAS、ARES、Trulens各自提出自己的指标集；本系列捍卫的原则是按切片的纪律，而非特定框架。

出现位置：文章3、20。

9. 每个构建块产生关系型结构化数据，而非原始字符串

解析返回DataFrames的关系集，而不是带有文本块和元数据的文档对象。问题解析返回question_df中的一行加上卫星表。检索产生带方法出处的类型化候选集。生成写入带有行级引用、排除项和答案模式的类型化行。

构建块之间的连接是表，而非字符串。这有实际后果：每个构建块都可以使用前一个构建块保存的输出独立测试，检索可以针对同一解析重新运行而无需重新解析，审计跟踪是对类型化行的连接而非自由文本片段的日志。

出现位置：文章5、6、7、8、13、16、22。

10. 引用是证据，而非装饰

每个生成的答案都返回起始页、起始行、结束页、结束行以及从这些行中提取的逐字引用。注释的PDF在源页面上突出显示被引用的区域。引用不是UI点缀；它是解释。

常见反驳是“但LLM仍然是不透明的，所以引用难道不是黑匣子上的装饰吗？”答案是引用并不使LLM不那么不透明。它们使LLM的不透明度与企业工作中重要的问题无关。

用户不是问“模型为什么选择这些词”。他们在问“这个答案来自源文件的哪里”。行级引用完全且可验证地回答了第二个问题：段落就在那里，行号就在那里，高亮在页面上，读者可以一键检查源。第一个问题仍然悬而未决，在企业环境中，它不需要被回答即可上线。

这就是为什么SHAP、LIME、注意力可视化以及ML可解释性堆栈的其余部分解决的是引用接地RAG架构没有的问题。

后续要求是系统存储足够的状态，以便在六个月后重现任何答案。这使得引用在审计中站得住脚。没有存储纪律，引用只是摆设；有了它，引用是企业系统需要的唯一解释。

出现位置：文章1、3、8、22。

该系列，逐篇文章

这十个立场在整个系列的五部分中进行了论证。以下是地图，以便您可以跳转到您想检查的论点。

第一部分：什么有效，什么无效。

文章1，基线。整个管道一次通过：一个PDF进去，一个类型化答案出来，其源行在页面上高亮显示。每个构建块都是几行可读代码，因此您在进行任何深入探讨之前就看到整个链条。后续每篇文章都改进此基线的恰好一个构建块，您始终知道您在哪里。

文章2，嵌入。教程跳过的测量：余弦相似度在同义词、拼写错误和改述上胜出，并在未知术语、否定以及匹配问题的词语与包含答案之间的差距上可预测地失败。您离开时知道您的哪些问题在投入生产前嵌入就会失败。文章2bis对重排序运行相同的诚实测量。

文章3，RAG不是机器学习。本系列所依据的框架。RAG失败是可识别的有缺陷的构建块造成的工程故障，而非需要训练消除的模型弱点，因此分块大小扫描和微调优化了错误的目标。富有成效的做法是按问题类型路由并修复故障的构建块。

文章4，技术网格。两个轴，文档复杂性和问题控制，告诉您哪种技术适合哪个问题。要点是拒绝“一种技术适用于所有”：一个固定的情况网格，每种情况使用能解决它的最便宜工具。文章4bis收集了我们不断看到的十个生产错误，按构建块组织，每个都附有修复方法。

第二部分：四个构建块。

文章5，文档解析。解析作为一种关系数据模型，而非文本提取。这是使行级引用成为可能的原因，并且每个下游构建块都读取这些表。

解析配套。每种方法一种，附有其确切的失败模式。最近的两个仍然活跃。

文章6，问题解析。大多数管道中缺失的步骤：在搜索任何内容之前解析问题。五个类型化字段将用户的字符串转化为一个简报，指导检索和生成。在检索之前运行的小循环添加了循环层：阅读文档，弄清楚问题未说出的内容，再次解析它，刻意限定范围。

文章7，检索。检索作为过滤，而非搜索：文档声明的结构第一，专家关键词第二，嵌入最后作为更便宜方法遗漏的保障。这是立场1的完整论证，附每种方法的可解释性案例。

文章8，生成。生成作为针对类型化合约的受控执行，而非自由形式写作。三个配套是活的：类型化合约的七种模式；何时top-1足够以及何时迭代top-k；以及从便宜的本地模型到托管旗舰的LLM级联。

第三部分：单个文档上的管道。

文章9，端到端。四个升级后的构建块连接成一次调用并在真实文档上运行。四个上下文工程构建块如何阻止RAG幻觉通过幻觉镜头阅读相同的管道。

文章10，自适应解析。从五毫秒解析开始，并且仅对需要更重解析器的页面升级。免费确定性检查在生成之前标记大多数失败的解析；LLM自身的自我评估捕获其余部分，管道重新解析一页，而非整个文档。

文章11，交叉引用。当答案说“见第7.2节”而不是答案本身时：企业文档不断指向自身，停在第一个段落的管道返回指针，而非内容。一个有限循环跟随引用并带回真正的答案。

文章12，列表问题。“列出每个排除项”在结构上破坏top-k：答案是每个相关段落，任何排名截断都会悄悄地丢弃其余部分。列表策略为完整性检索，而非排名。

文章13，调度器。单文档弧的关键：一个可读的decide.py读取解析后的问题并路由到正确的子管道，决定何时循环和何时停止。立场7在运行代码中：代理承诺的一切，在一个人类可读且审计员可重播的文件中。其配套概括了模式：每个步骤内部的小循环，管道之间的大循环。

操作闭环。通过减少调用LLM来降低延迟和成本，而非购买更快的模型：调度器的廉价路径意味着大多数问题从一开始就不需要为昂贵的调用付费。

第四部分：从一个文档到整个档案。

文章14，语料库问题。天真的RAG在语料库规模上悄然死亡：回答您问题的段落存在于30个文档中，只有一个是正确的。您的档案有三种形状之一，问同事三个问题告诉您您有哪一种，每种形状得到不同的架构。

文件夹形状。少数不相关的PDF根本不需要索引。

同质形状。数千个几乎相同的PDF需要相反的：一个索引。该索引是一个简单的SQL表，您的管道在摄取时填充一次，每文档一行，从那时起大多数问题在任何检索运行之前过滤行。

案卷形状。索赔卷宗混合了两者：文件夹本身有结构。因此文件夹也被解析为关系表，而不仅仅是其中的PDF。

文章15，文档索引。一个真正的索引需要存储什么才能值得信赖：身份、类型、日期、各方、版本、每个字段的来源。手写维护的电子表格无法承载它，文章展示了当团队尝试时什么会坏。

免费填充索引。值已经写在PDF中的四个地方，因此大部分索引零LLM调用填充。提取是后备，而非默认。

提取陷阱。向每个PDF询问每个字段是一个索引充满自信错误答案的方式。级联只询问文档类型实际携带的字段。

原始和规范。保留文档写的名称和您清理后的名称。将它们折叠成一列，索引悄悄地撒谎：您再也无法证明源说了什么。

文章16，词汇表。语料库在知识图谱之前需要一个词汇表：您的专家使用的词，映射到文档使用的词。这种映射，而非图谱，决定了问题是否到达正确的PDF。

精选表。五个手写小表，几十行，将问题路由到文档类型并将专家术语扩展为文档术语。构建便宜、可检查，并且在其覆盖的词汇上胜过通用语义搜索。

GraphRAG，经过测量。图谱管道为您构建知识图谱，账单在第一次搜索之前到达：语料库的每一页在摄取时被LLM读取。文章测量了这在相同语料库上相对于精选表购买了什么。

增长中的字典。词汇表不是静态的：一次失败的搜索提出一个新的别名，领域专家确认它，字典一次增长一个经过验证的行。专家保持在循环中；系统在实际失败的地方变得更好。

文章17，查询语料库。一次廉价的路由调用在运行任何内容之前对问题进行分类：一些答案直接从索引中得出，一些需要一个文档，一些需要完整的机制。大多数语料库问题比您想象的要便宜，一旦有东西决定。

SQL问题。“今年有多少合同到期”不是检索问题，它是对索引的一次SELECT。将其发送给RAG会产生缓慢、昂贵、错误的答案；将其路由到SQL产生精确的答案。

不变地扩展。第三部分的单文档管道在语料库上无需修改即可运行：索引选择文档，管道在每个文档上回答。模块独立性在这里得到了回报。

语料库表。该弧的标志性输出：每PDF一行，每问题一列，每单元格一引用。SQL选择行，RAG写入单元格，领域专家阅读一个电子表格，其中每个数字都可点击回其源行。

文章18和19，架构和存储。保持四个构建块在语料库规模下独立的代码布局，以及存储映射：每个工件的位置，因此任何答案都可以在数月后重播和审计。

第五部分：在生产中操作。

文章20，评估。汇总准确性隐藏了失败的子集；评估按问题类型和失败模式切分，在精选参考数据集上。立场8转变为工作实践。

文章21，成本和延迟。没有可观察性堆栈：管道已经在表中存储了每次调用、模型、令牌计数和持续时间，因此成本和延迟分析是您已经知道如何编写的SQL查询。

文章22，安全。数据驻留、GDPR和被遗忘权跨存储的解析和答案、审计跟踪以及泄露的提示：企业安全实际上对RAG系统的要求，逐个构建块。

超越编号主线。更多深入探讨与各部分并列排列：

嵌入弧，四部分。当嵌入返回错误块时以及为什么更大的模型不会修复它；如何在生产中实际使用它们；一旦它们不再是基础，嵌入在管道中扮演的真正角色；以及重排序在引擎盖下如何真正工作。

行级检索。表不是段落：检索整个表会埋没回答问题的行，因此分块单位变为行，带有其标题。

分块策略。切割PDF的七种方式，以及在相同文档上测量的每种方式破坏什么。

挑选模型。十三个模型在相同的四砖管道和相同的五十个问题上。不是排行榜，是一个可重现的基准，您可以在自己的语料库上重新运行。

本地LLM。模型可以变得多小，砖块才开始失败，对于不能离开机器的语料库。

Harness工程。整个构建背后的宣言：四个砖块是脚手架，模型是其中的一次调用，脚手架是您拥有的东西。

从这里开始：系列中最新的

如果您想在承诺上面的地图之前先试读该系列，这些是您现在应该阅读的文章，最新的优先：

RAG的循环工程：每个步骤内部的小循环，管道之间的大循环，系列构建的每个循环背后的一般框架。

通过减少调用LLM来降低企业RAG管道的延迟和成本，而非购买更快的模型，调度器的运营回报。

在完整的代理式RAG之前：知道您如何决定，以及在将循环交给代理之前您选择的解析方法。

RAG工作流和循环工程：决定何时循环和何时停止的调度器，立场7在运行代码中。

提示、上下文、循环：每个RAG系统构建的三个工程层，整个系列所依赖的概念框架。

结论

在阅读关于RAG的博客文章、框架教程或供应商推销时，逐条对照十个立场，并检查这些文章默默地假设了哪些。供应商推销通常跳过立场1、4和9；框架快速入门跳过7和1；学术论文跳过6和5。这个网格不是对这些文章的判断，它是在采纳建议之前值得问的问题列表。

这十个没有一个是本系列单独原创的。贡献是将它们视为相互关联的。如果您从这些文章中什么都不记得，请记住，您所拥有的文档上的问题，由需要答案的人提出，应该驱动每一个架构选择。系列中的其余一切都源于此。

进一步阅读和来源

本文是立场总结，而非实证文章。独立落在大多数十个立场上的实践者写作是Husain、Yan和Liu。Anthropic的Building Effective Agents是支持立场7的行业框架。在本系列定义的四个砖块之上的代理方面是后续工作。

与本宣言方向相同：

Husain，Field Notes from the AI Engineering Trenches。关于RAG评估的实践者写作，落在立场6、5和8上；生产中按失败模式评估最有用的单一来源。

Yan，Patterns for Building LLM-based Systems & Products。检索和生成模式的目录；与立场1、3和9的有用搭配。

Liu，Instructor: Structured outputs for LLMs。Python库及其关于模式即合约的写作；直接支持立场9。

Anthropic，Building Effective Agents。工作流与代理的区别；支持立场7和4的行业框架。

Khattab等人，DSPy: Compiling Declarative Language Model Calls into Self-Improving Pipelines。编译的声明式管道；与立场4和8一致。