@akshay_pachaar: RAG vs. Graph RAG vs. Agentic RAG，清晰说明！标准RAG将文档嵌入向量并检索最相关…

X AI KOLs Timeline 新闻
rag graph-rag agentic-rag knowledge-graph vector-database retrieval-augmented-generation explainer

摘要

清晰解释标准RAG、Graph RAG和Agentic RAG，涵盖它们的区别、用例以及如何处理单跳与多跳查询。

RAG vs. Graph RAG vs. Agentic RAG，清晰说明！ 标准RAG将文档嵌入向量，并通过相似性搜索检索最相似的片段。对于直接的事实查询，这种方法效果很好。 但当查询需要连接分布在多个文档中的事实时，这种方法就会失效。相似性搜索检索的是单个片段，而不是它们之间的关系。 Graph RAG在其之上添加了一个知识图谱层。 → 在索引阶段，LLM从文档中提取实体和关系。 → 在检索阶段，系统遍历这些连接，而不是仅仅依赖嵌入相似性。 这正是实现多跳查询的关键。 假设一个向量数据库存储了关于内部服务的三个事实： ↳ "checkout service 使用 payments API。" ↳ "payments API 运行在 cluster-3 上。" ↳ "cluster-3 计划在周五进行维护。" 有人问："checkout service 会受到周五维护的影响吗？" 向量搜索可能能够检索到事实1和事实3，因为查询中提到了 "checkout service" 和 "周五维护"。 但它会错过事实2，因为它连接了 payments API 和 cluster-3。 中间的事实嵌入空间中距离查询太远。它既没有提到 "checkout"，也没有提到 "maintenance"，因此永远不会进入检索上下文。 知识图谱将这些作为链接实体连接起来，而图遍历可以在一次查询中找到完整路径。 Agentic RAG 则采取了完全不同的方法。 不同于固定的检索流程，LLM agent 在查询时决定调用哪些工具、查询哪些来源以及按什么顺序进行。 请查看下面的图示以全面了解这三种架构。 这里需要注意的是，这三种并非你需要逐步进阶的复杂度层级。 相反，它们解决不同类型的查询。 ↳ 单跳事实查询 → 标准 RAG ↳ 多跳关系查询 → Graph RAG ↳ 使用工具的动态多源任务 → Agentic RAG ---- 当底层检索层高效时，每种架构的效果都会更好。 我最近写了一篇关于一种新的RAG方法的文章，该方法将语料库大小减少了40倍，每次查询的token数量减少了3倍，并将向量搜索相关性提高了2.3倍。 该文章引述如下。
查看原文
查看缓存全文

缓存时间: 2026/07/02 20:25

RAG vs. 图RAG vs. 智能体RAG，清晰讲解！

标准RAG将文档嵌入为向量，并通过相似度搜索检索最相似的片段。对于直接的事实查找，这种方法效果良好。

但当查询需要连接分布在多个文档中的事实时，它就会失效。相似度搜索只会检索独立的片段，而不会考虑它们之间的关系。

图RAG在此基础上增加了知识图谱层。

→ 在索引阶段，LLM从文档中提取实体和关系。

→ 在检索阶段，系统会遍历这些连接，而不是仅仅依赖嵌入相似度。

这就是实现多跳查询的原理。

假设向量数据库存储了关于内部服务的三个事实：

↳ “结账服务使用了支付API。” ↳ “支付API运行在集群-3上。” ↳ “集群-3计划在周五进行维护。”

有人问：“周五的维护会影响结账服务吗？”

向量搜索很可能检索到事实1和3，因为查询中提到了“结账服务”和“周五维护”。

但它会漏掉事实2——即连接支付API与集群-3的那个事实。

这个中间事实在嵌入空间中离查询太远。它既没有提到“结账”，也没有提到“维护”，因此永远不会进入检索到的上下文。

知识图谱将这些事实作为关联实体连接起来，而图遍历则能在一次查询中找到完整路径。

智能体RAG则采取了完全不同的方法。

它不再使用固定的检索流程，而是由LLM智能体在查询时决定调用哪些工具、查询哪些来源以及按什么顺序执行。

请查看下方的示意图以彻底理解这三种架构。

需要注意的一点是，这三种架构并非需要逐步进阶的复杂级别。

相反，它们解决的是不同类型的查询。

↳ 单跳事实查找 → 标准RAG ↳ 多跳关系查询 → 图RAG ↳ 使用工具的动态多源任务 → 智能体RAG

当底层检索层高效时，这些架构中的每一种都能变得更好。

我最近写了一篇关于一种新RAG方法的文章，该方法将语料库大小减少了40倍，每次查询的token数减少了3倍，并将向量搜索相关性提高了2.3倍。

文章引用如下。

相似文章