选择RAG架构：朴素型、高级型、CRAG、GraphRAG、智能代理型

为何选择RAG，以及为何单一设计不够用

AI智能体虽具备相应能力，但它们容易产生幻觉，且无法自行获取专业或实时的数据。检索增强生成（RAG）通过将智能体的回答基于经过验证的知识库来生成，从而解决了这两个问题。但RAG并非一种固定不变的方案——对于简单的FAQ机器人而言，普通的向量搜索就已足够；而对于需要处理多份文档的复杂推理或分析任务，向量搜索则表现极差。下文将介绍常见的RAG架构，并根据任务需求提供相应的选择思路。

RAG的功能

RAG从知识库中检索文档，并利用这些文档生成更相关的答案。下图展示了从文档存储、向量检索到LLM生成的全流程。

其核心理念是将图中从存储到检索的信息检索过程与生成式人工智能相结合。通过向提示词中注入相关上下文，可使语言模型始终与真实信息保持关联。它能够在几秒钟内扫描大量领域特定资料，从而让大型语言模型准确且快速地回答用户的查询。

典型的工作流程分为两个阶段。离线阶段负责接收原始数据并将其转换为可搜索的结构化数据。在线阶段则负责检索相关数据并回答查询。此外还有一个值得加入的第三阶段，即反馈循环，通过该循环不断对检索到的上下文进行评估。

第一阶段：数据导入

第一阶段是将原始文件转换为数据库中的结构化、可搜索的记录：

1. 使用 LlamaIndex 或 LangChain 等工具从 PDF、Notion、SQL、Slack 等来源加载数据。
2. 清理页眉、页脚及 HTML 标签等冗余内容。
3. 将长文档分割成有意义的片段，每段约 500 字。片段过大会让模型混淆，过小则会丢失上下文。
4. 使用嵌入模型（如 OpenAI 的 text-embedding-3-small）为每个片段生成嵌入向量，将文本转换为向量形式。
5. 在 Pinecone 或 Chroma 等向量数据库中建立索引，从而实现基于语义的搜索。

第二阶段：检索与生成

当用户提出查询时，整个过程仅需几毫秒即可完成：

1. 查询转换。系统会将诸如“如何重置密码？”这样的问题，通过与第一阶段相同的嵌入模型转换为一个向量。
2. 检索。它在向量数据库中搜索与问题在数学上最接近的3到5个片段。
3. 重新排序。重新排序模型会对结果进行二次核查，确保最佳匹配项位于最顶部。
4. 增强。检索到的片段会被整合到大语言模型的提示词中。典型的提示词会告知模型它是一个乐于助人的助手，将这些片段作为上下文提供给模型，随后提出重置密码的相关问题。
5. 生成。大语言模型会阅读提示词及上下文，仅基于所给信息生成答案。

第三阶段：反馈

应持续评估检索结果以避免产生幻觉。评估功能可判断答案是否真正基于上下文，而可观测性则能显示是哪个部分导致了错误答案。这些分析结果会用于改进第一阶段的分块策略。

按阶段划分的工具

RAG工具是将数据与语言模型相连的基础组件，它们根据所服务的流程阶段进行分类。选择何种工具取决于当前所处的阶段。

该表格按流程阶段对RAG技术栈进行了排序。

是否需要向量数据库？

并非必须如此。构建RAG并不要求使用专用的向量存储，还有两种更简单的方案。采用零数据库方案时，只需将少量文档分割成块并存储在RAM中。这种方式速度快、无需成本且无需额外设置，但重启后会清空内存，且处理大型文档时效率较低。而传统数据库方案则将文本块存储在PostgreSQL之类的数据库中，并通过规则驱动的关键词搜索来实现功能。它擅长处理人名或ID这类唯一短语，但缺乏语义理解能力：用户询问“哺乳动物”时，仅包含“狗”字样的文档不会被匹配到。

六种架构对比

并没有一种方案能适用于所有场景。有些任务需要快速简便的处理，有些则需要深入分析，还有些任务需要多个数据源或图像、图表等非文本输入。六大主要设计模式可以满足大多数需求：朴素RAG、高级RAG、模块化RAG、修正型RAG（CRAG）、GraphRAG以及智能代理RAG。

朴素RAG

这种最简单的形式会根据查询内容直接提取相关文档，然后原封不动地传递给模型，无需任何调整。

示意图展示的是简单的Top-K向量相似度匹配机制。查询内容会被转换为向量，从向量数据库中获取Top-K个相似的文档片段，再将其传递给大语言模型。搜索属于语义搜索，且复杂度较低。

• 优点：响应速度最快，计算成本最低；使用LangChain或LlamaIndex等库即可轻松实现；适用于从结构清晰的文档中检索基本事实。

缺点：无关内容会带来干扰，使大语言模型混淆；它难以处理复杂或多步骤的问题，且无法自我纠正，因此检索失败会导致生成虚假答案。

最适合的场景：在规模较小且结构清晰的数据集上进行的简单问答，例如个人文档问答、企业内部常见问题解答以及简单的文档对话应用。

高级 RAG

这种改进版本在检索步骤中加入了查询路由和重排序等逻辑，以提高准确性。

图表展示了检索前的查询优化与检索后的结果重排序过程。检索前，查询会被重新撰写以使其更清晰；检索后，会对结果进行排序和合理性检查，从而确保生成的答案尽可能相关且准确。该方法的搜索方式为混合式（向量搜索加关键词搜索），并包含重排序功能，复杂度处于中等水平。

• 优势：更能应对复杂问题，能为不同情况选择合适的方法，且对生成过程有更多控制力。
• 劣势：重新排序会增加延迟，每次查询需要调用多个模型会提高成本，需要维护的组件更多，而且各组件需经过调优才能协同良好工作。
• 最佳适用场景：那些不能容忍错误的高精度系统，比如专业知识库和客户支持机器人。

模块化RAG

模块化RAG采用即插即用的结构，由独立的模块负责工作流程中的不同环节。

重点突出的组件包括搜索模块和内存模块。采用这种架构意味着无需重新构建整个系统即可对任意部分进行定制：团队可以更换不同的检索器、更强大的重排序器或其他生成器。检索功能可以覆盖API、数据库和网络等多种数据源，但由于需要复杂的协调层，其实现难度很高。

• 优势：每个组件都易于调整，且可在不重新开始的情况下升级或更换部件。
• 劣势：部署成本和架构复杂性极高，需要提前规划；必须由实力强的工程团队来负责协调工作，而且不同版本的模块之间可能会出现冲突。

最适合场景：需要深度定制的复杂企业系统，例如能够同时查看Jira、Slack和Google Drive信息的助手。

纠错型RAG（CRAG）

CRAG的设计目的是对答案进行二次核查，一旦发现错误便立即修正。

其处理流程包括评估步骤以及备用的网络搜索功能。评估模型会对检索到的文档进行评分，若评分过低，系统就会放弃内部数据库，转而通过网络搜索在其他地方寻找答案，即图中的虚线路径。由于包含基于逻辑的分支处理以及外部API调用，该方案的复杂度较高。

• 优势：在用户看到不良搜索结果之前就能将其修正，额外的质量控制层提升了响应的可靠性与准确性。
• 缺点：备用搜索需要耗费时间和计算资源，而且如果系统对搜索结果始终不满意，可能会陷入无限循环。
• 最佳适用场景：那些容错率极低、错误或过时信息不可接受的高风险工作，例如医学和法律研究。

GraphRAG

GraphRAG利用知识图谱来构建信息之间的关联，而不仅仅依赖文本相似度。

该图展示了知识图谱的遍历过程以及社区摘要的生成方式。在构建好图谱后，系统会遍历图谱以寻找数据中的模式，而不仅仅是单词匹配，因此即便实体A和实体B出现在不同的文档中，也能确定二者之间的关联。由于需要构建并维护结构化的图数据库，其复杂度非常高。

另一张来自微软研究院插图的图片展示了使用GPT-4 Turbo在私有数据集上构建的由大语言模型生成的知识图谱。

• 优势：能够处理涉及多个概念的复杂问题，避免零散的答案，还能通过关联不同信息点呈现出意外但相关的结果。
• 劣势：构建该知识图谱需要大量工作，其速度慢于普通的RAG技术，且性能受图谱质量限制，因为它的表现仅取决于图谱中的连接关系。
• 最佳应用场景：适用于需要从多个数据源中进行全局视角分析及多步推理的情况，比如调查性新闻报道、欺诈检测或药物发现领域。

代理型RAG

在这种动态设计中，人工智能代理充当协调者，负责规划、检索并优化响应内容。

该工作流程展示了一个协调代理如何运用工具进行多步骤推理。它不会直接获取首个相关文档，而是先规划处理方案，决定需要调查的内容，再通过工具采取行动。它会将任务分解为更小的步骤，搜索各种数据源，检查所得结果是否能回答查询，若不能则继续搜索。

• 优势：适用于多步骤推理，能在信息收集方面做出明智选择，且能提升复杂查询的处理效果。
• 劣势：多次搜索会增加成本，且研究式的处理方式会降低响应速度。
• 最佳适用场景：需要系统化规划的任务，例如法律研究中的全面案例分析，或是结合市场数据与监管信息的财务分析。

四步决策路径

没有一条规则能适用于所有情况，但一个通用的方法有助于完成当前任务。

该流程图根据任务需求为架构师提供简单型、图形型、纠错型以及高级型RAG四种选择。具体步骤如下：

第一步：复杂度测试。答案是否存在于单份文档中？如果是，对于小型文档，最佳选择是无数据库RAG；而对于大型文档，则简单型RAG更为合适，因为它速度快、成本低，且构建起来几乎毫不费力。

第二步：关联度测试。回答问题是否需要理解多个数据源之间的深层层级结构或隐藏关联？如果是这样，GraphRAG能够映射这些资源与关联关系，而普通文本搜索则无法做到这一点。例如“哪些部门会受到政策A的影响，这些部门的负责人是谁？”这类问题就需要将部门数据与员工数据关联起来，GraphRAG则能将二者作为相互关联的实体来处理。

第三步：可靠性与推理测试。系统能否承受出错的风险？在需要极高精确度的场景中，Corrective RAG或Self-RAG会增加专门步骤，在数据呈现给用户之前先验证所检索到的内容是否真正能回答问题。如果该任务还需要多步推理，Agentic RAG则可通过其智能体实现规划与自我优化。

第四步：性能与成本之间的权衡。当延迟是首要考虑因素时，如No-DB、Naive或Simple RAG这类较为简单的架构最为适用。而当质量比成本更重要（但尚未达到第三步所需的极高精确度）时，Advanced RAG能比简单设计更好地理解查询背后的意图，但代价是更高的处理时间。

何时不应使用RAG

RAG使大型语言模型能够无需持续重新训练，就能从庞大的私有数据集中给出具备上下文意识的答案。不过，它并非在所有情况下都适用，尤其是当任务需要深度推理、创造性综合或对语言规律的熟练掌握，而非仅仅查找文档时。在这些场景下，不使用RAG往往效果更好：

• 关于常识、伦理细节或人类普遍行为的广泛推理。这类任务应依赖预训练模型内部已固化的权重。
• 关于数十年来未发生变化的事物的通用知识查询。预训练模型就已足够，使用RAG只会增加延迟而不会提升准确性。
• 具有特定语气和风格的创意写作。这类任务应使用预训练模型或进行微调，因为RAG属于过度设计。

复杂的数学或逻辑问题，需要多步骤计算。微调或思维链（CoT）提示法更为适用。

极低延迟需求，要求近乎即时的响应。嵌入、搜索和注入操作都会增加额外开销。

小型数据集，可完全包含在提示词中。直接粘贴数据比构建处理流程更高效。

最后的表格对比了RAG、微调模型和推理模型的性能。