RAG与代理式RAG与图结构RAG：如何选择合适的检索架构

了解天真的RAG在多跳查询和结构化数据处理上为何会失败，以及代理循环与基于图的检索分别如何弥补不同的缺陷。

1606 词

RAG旨在解决的问题

任何大型语言模型所掌握的知识在训练结束后就会停止积累，且只能处理其上下文窗口内的内容。检索增强生成通过为模型添加外部记忆来解决这一问题，使模型在回答问题时能够查阅这些外部信息。模型不再仅仅依赖训练期间学到的知识，而是从文档集合中获取相关文本，并利用这些材料来构建回答。

其基本步骤你可能已经很熟悉了：

将源文档拆分成更小的片段，并转换为向量嵌入。
将这些嵌入保存在向量数据库中——Pinecone、Weaviate、pgvector等工具是常见的选择。
当用户提交查询时，也会使用相同的方法对其进行嵌入处理。

系统会选取向量与查询向量最接近的前k个片段。

这些片段会被插入提示语中，与用户原始问题一同呈现。

模型会以这些检索到的文本作为依据来生成回复。

整个流程从开始到结束只运行一次：一次检索，一次生成。它的成本较低，行为易于理解，对于各种应用场景——搜索内部文档、根据知识库回答支持问题，或基于固定文档集处理问答——都能表现出色。

简单RAG方法的局限性

当这种简单的流程出现故障时，问题通常可归为几类常见的类型：

需要结合多条事实的查询。比如“在第三季度政策更新后，哪些供应商续签了合同？”这类问题需要两段独立的信息，而这些信息几乎肯定分布在不同的内容片段中。向量相似度算法寻找在语义上与查询相似的内容片段，而非回答该问题实际所需的特定事实组合。
没有内置的停止条件。无论这些内容片段是否真正包含答案，系统总会返回排名靠前的k个片段。当真实答案不在这k个片段之中时，模型要么编造一些看似合理的内容，要么给出含糊不清、毫无帮助的回复。
没有反馈机制。如果最初的检索结果有误，整个流程中没有任何机制能够检测到这一点并尝试使用更精准的查询语句，只会继续使用已获取的结果。

结构关系的丧失。将文档拆分成多个片段后，它就变成了一堆相互独立的文本碎片，原有的层次结构、交叉引用以及实体间的关联都会被丢弃——而这些信息往往正是包含真正答案的关键。

这些其实都不是错误，而是该架构核心假设所导致的自然结果——即认为对相互独立的文本片段进行相似度搜索就足以替代真正的关联性判断。Agentic RAG与Graph RAG分别针对这一假设中的不同弱点进行了改进。

Agentic RAG：为信息检索添加决策循环

Agentic RAG摒弃了传统的“先检索再生成”的固定流程，转而采用一种循环机制，由大语言模型充当协调者，决定需要检索什么、是否还需要进一步检索，以及何时已收集到足够的信息来生成答案。

这个过程并非只有一步检索，而是更像这样：

模型首先读取查询内容，并分析自己实际需要哪些信息。
它判断是否真的有必要进行检索，如果需要，则构建搜索查询——可能会将复杂的问题拆解为多个较小的子问题。
它检索结果后，会评估这些结果是否足够，如果不够，则重新编写查询并再次检索。
根据问题的需求，它可以从不同的数据源中获取信息——向量存储、SQL数据库、网络搜索API或内部服务等。
只有在确认拥有足够的证据后，它才会给出最终答案。

实际上，这是将RAG嵌入到代理循环中，采用了代码辅助工具所用的相同调用模式：规划、执行、观察结果，然后决定是否继续。信息检索不再是一个必须的第一步，而只是众多工具之一，会根据需要选择性调用，而非在每次请求时自动执行。

其优势在于灵活性。简单的问题只需一次检索；需要依次在多个系统中进行三次检索的问题也会得到相应的处理。该架构还支持自我修正——如果检索到的内容明显有误，代理能够识别这一点并发起新的查询，而非基于不可靠的上下文给出答案。

这种灵活性确实需要付出代价。每一个规划步骤和评估步骤都相当于一次独立的模型调用，因此每次查询都会触发更多次大语言模型调用，导致延迟增加，且成本状况更难以提前预测。当查询的复杂度在不同请求之间差异很大时，代理式RAG表现较好，因为固定的单次处理流程要么在简单问题上浪费资源，要么在复杂问题上力不从心。而当需要始终保持较低延迟，或查询范围足够狭窄、经过精心调优的单次检索器已能很好地处理它们时，代理式RAG就不是最佳选择。

图结构RAG：恢复被分块破坏的结构

图结构RAG针对的是另一种完全不同的限制：基于分块的普通向量搜索无法内置实体之间关联关系的概念。

Graph RAG并非仅依赖向量索引（尽管它仍可同时使用向量索引），而是直接从原始材料中构建知识图谱。这包括提取实体——如人物、产品、组织、概念——以及连接这些实体的关系，例如“在……工作”、“依赖于”、“由……引起”或“是……的版本”。这样一来，信息检索就不再仅仅是相似度搜索，还部分变成了图遍历问题：系统可以从某个相关实体出发，跳转到与之相连的实体，并获取那些仅通过关键词或嵌入匹配永远无法找到的信息，因为这些信息位于完全不同的文档中，且通过若干层关系才与之关联。

微软的GraphRAG研究是这种实现方式中被引用最广泛的，它还引入了一项对某类查询尤为有价值的额外功能：社区检测。该系统会将图结构划分为由紧密关联的实体组成的群组，并为每个群组预先计算出摘要。这使得Graph RAG在处理涉及整个数据集的广泛问题时具有明显优势——比如“这些报告整体中反复出现的主题是什么？”这类问题，而这正是传统RAG最难以处理的类型，因为没有任何单个片段能包含完整答案，只有通过整合整个数据集才能得出答案。

这里的成本是结构性的，而非偶然产生的。构建该图谱成本高昂，因为需要使用大语言模型对整个语料库进行实体与关系抽取，还需额外步骤生成社区摘要。此外，它也不适合那些频繁变化的语料库，因为每当文档有变动时就必须重新构建或逐步更新图谱——这一操作远比直接将新向量插入嵌入索引要复杂得多。

三种方法的比较

需要指出的是，这些方法并非相互排斥。实际应用中常见的模式是采用代理循环结构，配备向量检索器和图检索器作为可选工具，让代理根据查询需求在两者之间选择或同时使用二者。代理层实际上是一种编排策略，位于你所使用的任何检索机制之上，因此它会自然地叠加在图RAG之上，而非与其竞争。

实用的决策框架

与其因为某种方法当前流行就选择它，不如通过具体的决策流程来做出判断：

从简单的 RAG 开始。这是构建和调试成本最低的方案，对于大多数实际应用而言已经足够好用。在确信确实需要更高复杂性之前，请避免添加不必要的复杂度。
一旦发现特定的故障模式，再升级到代理型 RAG：比如那些需要从多个来源获取信息的查询，因模型必须先搜索、评估找到的内容后再再次搜索而导致答案出错的场景，或是任务中简单查询与复杂查询混杂，使得单一固定流程显得过于冗余或不够用的情况。

当问题本质上涉及实体间的关系或需要覆盖整个语料库时，建议升级到 Graph RAG——即用户希望了解各实体之间的关联，或需要基于整个数据集的综合答案而非单份文档中的事实——且前提是您的数据足够稳定，维护图结构不会带来持续负担。

这一核心观点反映了系统设计中反复出现的规律：更复杂的架构并非天生就更优，它只在应对特定类型的缺陷时才具有优势。传统的 RAG 在处理多跳推理和关系型问题时会遇到困难，而代理式 RAG 通过引入迭代机制来弥补推理上的不足；Graph RAG 则通过引入结构化方式来解决关系处理问题。正确诊断自己实际面临的是哪种缺陷才是关键所在。