超出简单流程的七种RAG架构及其适用场景

大多数人最初构建的RAG流程都很简单：将文档分割成若干块，生成嵌入向量，获取最匹配的几条结果，将其放入提示词中，再让大语言模型给出答案。演示时一切正常，回复也看似合理。但当遇到实际问题时，就会出现问题——返回的却是错误的文档块；虽然找到了正确的文档，却找不到所需的段落。有时相关数据其实存在于数据库中，只是模型根本无法看到它。

奇怪的是，所有组件都没有故障。该流程完全按照设计初衷运行。相关教程很少强调真正的要点：填充向量数据库很容易，而将正确的信息呈现给模型才是难题。最初的那种设计属于简单的RAG架构。作为自然的起点，它确实有一定用途，但当文档变得复杂、问题变得更难解决或可靠性变得重要时，这种检索与回答的循环就会达到极限。此后又出现了七种更先进的架构，每种都有其解决的特定问题、可能的故障点，以及判断某个系统是否需要它的方法。

RAG存在的理由

大型语言模型仅知晓其在训练过程中学到的内容。若询问公司内部文件或近期发生的事件，它要么承认不知情，要么更糟糕的是编造出看似可靠的答案。RAG技术解决了这一问题，其原理类似于允许学生在考试时携带笔记。系统会先找到相关资料并作为参考提供给模型，这样模型就不必仅凭记忆来作答。

基本流程如下。

当用户提出问题时，系统会执行四个步骤：

1. 在外部知识库中搜索相关资料
2. 检索最匹配的片段
3. 将这些片段附加到问题旁边的提示语中
4. 将所有内容发送给大型语言模型，由其根据这些上下文生成答案

简而言之：提问、搜索、检索、补充上下文、LLM生成答案。这种方法适用于规模较小且结构清晰的文档集。但真实数据往往并非如此，通常会出现五种缺陷：

• 片段会丢失上下文。仅说明“收入增长3%”的文字无法表明具体是哪家公司或哪个季度的数据。
• 信息会被遗漏。表格、图表及扫描页往往无法在基于文本的检索中保留下来。
• 首次搜索就可能出错，而基础的RAG系统不会尝试再次检索。
• 之前的对话会消失。由于没有记忆功能，每次会话都从零开始。
• 事实之间缺乏关联。当信息分散在多份文档中时，可能需要先建立联系才能得出有意义的答案。

这些并非随机出现的五个问题，它们解释了为何存在不同的架构，而下面提到的每一种方案都是针对基础处理流程中的特定缺陷设计的。

1. 上下文片段说明

在存储某个文本片段之前，会附上一条简短说明，说明其内容主题，这样即使脱离原始文档后仍能理解其含义。想象一下从书中撕下一段文字交给陌生人，却既没有标题也没有章节编号——对方根本无法知道它指的是什么。此时先附上一张便条：这是来自第4章，内容关于该公司第二季度的业绩。这就是整个思路。

未经说明的原始片段仅提到营收较上一季度增长了3%，但未说明具体公司和年份。而加上说明后，就能明确这是来自ACME公司2023年第二季度的财报内容，随后仍是同一句话。

Raw chunk:        "revenue grew 3% over the previous quarter"
                   -> which company? which year? unclear

With a note attached:  "From ACME Corp's Q2 2023 filing.
                        Revenue grew 3% over the previous quarter."
                   -> now it makes sense on its own

优点在于检索到的片段本身具有可理解性，且搜索方法本身无需改变，因为只有存储的内容会发生变化。缺点在于成本：在开始搜索之前，每段内容都需要耗费时间和金钱来生成描述，而且编写不当的描述很容易使搜索方向出错，就像优秀的描述能引导搜索走向正确方向一样。

2. 多模态检索

文档往往根本不是纯文本。将PDF页面转换为文本并进行搜索可能会破坏表格和图表的结构，因此另一种方法是让系统以图像形式查看页面。想象一下，阅读别人对图表的描述与直接查看图表有何不同——描述可能会遗漏细节或错误标注数值，而原始图表则不会如此。

在旧的处理流程中，首先将PDF页面转换为文本，再推测表格布局，最后对文本进行搜索，因此数字和结构在转换过程中可能会混乱。而在多模态处理流程中，则直接将页面作为图像进行搜索。

Old way:  PDF page -> extract text -> guess at the table layout -> search the text
          (numbers and structure can get scrambled along the way)

Multimodal way:  PDF page -> search the page as an image directly
                 (the table stays a table, the chart stays a chart)

该方法能够处理表格、图表以及文本提取会弄乱的扫描内容，同时还能省去一个脆弱的处理步骤。其代价是计算成本高于纯文本搜索，而且相关技术生态尚不成熟，可用的工具较少，社区知识积累也有限。

3. 混合搜索

两种搜索方式同时运行，一种理解语义，另一种匹配精确词汇，然后将两者的结果合并。想象一下两位图书管理员：一位即便你用词不当也能理解你的意图；另一位则没有上下文意识，但总能找到包含你所输入的特定代码的文档。正是有了这两者的结合，混合搜索才具有价值。

以查询“error E0502 borrow checker”为例，基于语义的搜索即使没有完全相同的短语也能找到相关概念的文档，而精确词汇搜索则会找出“E0502”这一确切字符串，最终合并后的结果会整合这两类信息。

Query: "error E0502 borrow checker"

Meaning-based search:   finds docs about a similar concept, even without that exact phrase
Exact-word search:      finds the literal string "E0502"
Combined:               merges both into one final list

一次搜索即可涵盖模糊的概念性问题与精确的技术术语，从而解决了一个常见的问题：仅基于含义的搜索在处理代码、标识符和行话时往往效果不佳。其代价是需要运行两个搜索系统，并且要确定每个系统产生的结果应被赋予多大的权重，这需要仔细调整。

4. 图谱与地图式检索

这种方法不存储孤立的信息片段，而是描绘文档中人物、公司及理念之间的关联关系，将相关内容归类，并提前为每个类别撰写简短摘要。当问题过于宽泛，无法用单个信息片段回答时，系统会调用这些类别摘要，甚至能自行判断哪些类别值得进一步查看。

假设有人希望了解今年发布的所有内容中的核心主题。单篇文章无法满足这一需求。如果将机构划分为多个部门，每个部门都提供一页的工作总结，只需阅读这些页面就能快速得到答案。这就是“地图”。更智能的版本则像助手一样，首先判断哪些部门与问题相关，而非盲目阅读所有总结。

这一过程分为两步。第一步是提前构建“地图”：找出人员与想法之间的关联，将相关内容归类，并为每个类别撰写总结。第二步则是根据这些总结来回答宏观问题。

Step 1, build the map (done once, ahead of time):

  Documents -> find how people/ideas connect -> group related ones
            -> write a short summary for each group

Step 2, answer a broad question:

  "What are the big themes here?"
  -> pick the relevant groups (a smart version does this pick automatically)
  -> read just their summaries -> combine into one answer

优点：当单个数据片段无法回答广泛的主题性问题时，它能够给出答案；可以同时追踪多份文档之间的关联；自选版本会跳过无关的摘要。缺点：构建这样的映射需要一个实际项目作为基础；每当文档内容发生重大变化时，部分内容就需要重新构建；而在分组选择环节，系统也有可能做出错误的选择。

5. 智能迭代检索

地图能帮助解答宏观层面的问题，但有些问题无论地图多么完善，都需要多次搜索才能找到答案。系统会进行搜索，查看搜索结果，判断是否足够，必要时再重复操作。这就好比将搜索引擎比作研究助手：搜索引擎只会返回一份列表后就停止，而研究助手会仔细查看结果，发现不够后便再次搜索，并利用之前获得的经验更巧妙地查找。

这个循环流程如下：有疑问出现后，系统先进行一次搜索，然后判断这次搜索是否足够。如果不够，它就会利用之前学到的经验再次搜索；如果还是不行，就会尝试其他方法。

Question comes in
     -> Search once -> "Is this enough to answer?"
     -> No: search again, using what was just learned
     -> No, still not enough: search again, from a different angle
     -> Yes: now answer

它能够处理那些确实需要多次查询的问题，不会像固定流程那样在一次失败的搜索后就停止。但其代价是每次额外搜索都需要进行一轮往返操作，从而增加成本和等待时间；如果选择不当的查询角度，可能需要多次尝试才能发现错误。

6. 多智能体检索

在这种方式中，一个系统不会独自完成规划、搜索、核查和撰写所有工作。这些任务会被分配给多个小型专业系统，每个系统负责一项工作，由一个协调器来管理整个流程。而一个人同时承担研究、撰写和事实核查的工作，往往在三项任务上都无法做到尽善尽美。一个由一人负责规划、一人负责搜索、一人负责核查、一人负责撰写的小组，通常在各项工作中都能表现得更好。

有人提出问题后，规划者会决定需要查询什么内容，搜索人员便去查找，有时会同时从不同来源获取信息，最后由审核员检查所得结果的准确性。

Question comes in
  -> Planner decides what needs to be looked up
  -> Searchers go look, sometimes from different sources at the same time
  -> Checker reviews what came back for accuracy
  -> Writer puts together the final answer

工作的每个环节都能得到充分关注，而非由单一系统同时处理所有事务，而且并行搜索能节省时间。但另一方面，协作的系统越多，每个问题的处理成本就会上升；一旦得出错误答案，就需要通过多步流程才能追溯纠正。

7. 基于记忆的检索

在这种设计中，系统不仅会搜索固定的文档集，还会查询与用户之间的历史对话记录，将过去的交流视为可参考的资料而非一旦结束就予以遗忘的内容。这就好比医生每次就诊前都会查看你的病历，而不是要求你每次都重新讲述全部病史。上一次就诊时你说过的大部分内容仍然保存在某个文件夹中，优秀的系统也会将重要信息留存备用，在需要时随时调取。

它能让系统回忆起几天或几周前提及的内容，而无需一次性加载所有信息，不仅适用于一次性文档查询，还能帮助处理各种个人事务或持续进行的工作。其缺点是在文档搜索基础上增加了额外的记忆系统，从而导致组件更多；同时为了节省空间，较旧的记忆内容有时会被压缩或概括，进而导致细节丢失。

选择

Naive RAG会悄无声息地出错。它既不会崩溃也不会报错，用户收到的只是基于错误信息的答案，直到有人仔细核查才会发现问题。

上述每种架构的出现，都是因为有人将错误的答案归因于某个特定且可修复的原因。因此，最新的选项并不一定就是最佳选择。应挑选与检索出错方式相匹配的架构。仔细审视当前的流程，并诚实地问自己：当它给出错误答案时，是因为搜索找错了内容、某个片段丢失了上下文，还是系统根本没有再次核查？仅凭这个问题就能确定接下来需要采用的架构。