GraphRAG + GPT-4o-Mini 是 RAG 的天堂

Vatsal Saglani

第2部分：GraphRAG与基于语义/关键词的RAG

图片来源于DALL-E 3

免责声明: 本文中GraphRAG的实现灵感来源于Darren Edge等人撰写的论文从局部到全局：一种基于图的RAG方法用于查询聚焦摘要。该代码与论文的代码库并不完全相同，尽管某些任务的提示来自论文的代码库。

这是关于GraphRAG的多部分博客系列中的**第二篇博客**。在这个博客系列中，我们的目标是实现以下内容：

理解GraphRAG的基本原理
GraphRAG的必要性：GraphRAG与基于语义/关键词的RAG
从头开始用Python实现GraphRAG组件
将GraphRAG应用于基于内容的电影推荐：“GraphRAG4Reccomendation”
使用GPT-4o-Mini创建图形并提供推荐

我们将在这个多部分博客系列结束时实现以下输出。

作者实现输出

以下是GraphRAG4Rec代码库的GitHub存储库。

其他部分

第 1 部分： GraphRAG 介绍
第 3 部分：提取 — 实体、关系和声明以构建图 (敬请期待)
第 4 部分：批量社区和准备总结报告 (敬请期待)
第 5 部分：通过 map-reduce 提示进行查询处理和推荐生成 (敬请期待)

在这篇博客中，

我们将快速了解基于图的检索增强生成（GraphRAG）方法的必要性。我们将把这种方法与基于语义或关键词的RAG方法进行比较。

理解基于语义/关键词的RAG

在基于语义/关键词的RAG中，我们将传统的信息检索策略与语言生成相结合，以产生更准确和更具上下文相关性的响应。

语义/关键词基础的 RAG 组件

以下是语义/关键词基础的 RAG 组件。

文档语料库 是一个文本或文档的集合，作为知识库。
嵌入模型 将文本转换为捕捉语义意义的向量表示。
向量数据库 存储和索引文档的嵌入表示。
检索器 根据查询查找相关文档。
（大型）语言模型 根据检索到的信息和查询生成响应。

以下流程表示传统的 RAG（语义/关键词基础）过程。

传统 RAG 流程（作者提供）

现在，我们不会深入讨论分块策略或检索策略，如查询分解、重新排序等。这些确实有助于提高最终输出的质量。

我们现在理解了 GraphRAG 和传统 RAG（语义/关键词基础）的基本原理，以及各自方法的组件。现在是时候用一个例子来比较这些方法了。

我们将使用相同的电影场景，并假设性地比较这两种方法。

比较

我们将在以下几点上比较这些方法。

知识表示
检索机制
上下文理解
可扩展性
查询解释
信息综合

1. 知识表示

在 GraphRAG 中，我们将电影、演员、导演和主题表示为相互关联的实体。例如，“黑客帝国”与“科幻”和“动作”类型相连，与“沃卓斯基兄弟”作为导演，以及“基努·里维斯”作为演员。
在 传统 RAG 中，我们可能将“黑客帝国”存储为文本块： “黑客帝国是一部1999年由沃卓斯基兄弟执导，基努·里维斯主演的科幻动作电影。”

知识解释的表示（作者）

GraphRAG 的优势在于它可以通过遍历图形轻松回答诸如“还有哪些科幻电影由《黑客帝国》的演员主演？”这样的问题。

传统 RAG 在没有具体文本提到这种连接的情况下会很困难。为了使传统 RAG 能够处理这样的查询，我们可能需要实施某种查询分解和依赖规划。

2. 检索机制

在 GraphRAG 中，如果我们有一个查询如“科幻反乌托邦电影”，检索可以从与“科幻”节点相似或有关的社区开始，并遍历到一个更本地的社区，找到一个如“反乌托邦”的节点，最终返回电影——“黑客帝国”。
而在 传统 RAG 中，如果没有块提到“科幻”或“反乌托邦”以及电影“黑客帝国”或其他电影，则输出可能非常通用，即与关键字“科幻”相关，或者可能有一些主题为“反乌托邦”的电影（在块中提到），但不是“科幻”。

检索机制比较（作者）

因此，GraphRAG 即使在查询术语与存储文本不完全匹配的情况下也能找到相关内容。

3. 上下文理解

GraphRAG 可以理解“盗梦空间”和“黑客帝国”是相关的，因为它们共享“科幻”类型和“心灵扭曲概念”主题，即使在任何文本块中没有明确提到。
传统 RAG 可能无法将这两部电影联系起来，除非有特定的文本块进行比较。

上下文理解比较（作者）

在这种情况下，这两部电影——_盗梦空间和黑客帝国——_之间的关系通过它们共享的类型和主题得以暗示。在图中，这两部电影之间将有一个连接，它们甚至可能形成一个社区。因此，GraphRAG 的隐含上下文理解可以帮助提供更有洞察力的推荐。

4. 可扩展性

随着我们的电影数据库的增长，**GraphRAG** 中的层次结构（C0 — C1 — C2）允许高效导航。我们可以快速从“电影”缩小到“科幻与动作”，再到“纯科幻动作”。这也取决于我们设计检索器的方式——基于实体或通过社区报告的映射-归约。
在 传统 RAG 的情况下，当回答广泛查询时，我们可能会遇到困难，因为可能会有许多无关但匹配的块，类似于查询的各个部分。我们需要引入重新排序来过滤这些块。

因此，GraphRAG 可以更高效地处理大型复杂数据集，特别是对于探索性查询。

5. 查询解释

对于诸如“像盗梦空间但更注重动作的电影”这样的查询，**GraphRAG** 通过社区报告的映射-归约，可以理解它需要寻找“科幻惊悚”类别中的电影，但更接近“纯科幻动作”类别，可能建议“黑客帝国”。
对于相同的查询，**传统 RAG** 可能难以捕捉查询的细微差别，可能返回提到“盗梦空间”和“动作”的电影。

查询解释比较（作者）

因此，GraphRAG 可以处理更细致、依赖上下文的查询。

6. 信息综合

对于关于“90年代到2010年代的科幻电影演变”的查询，**GraphRAG** 通过社区报告的映射-归约可以收集与“科幻”电影及其发行年份相关的信息。然后有效地使用这些信息来回答这样一个广泛的问题。
传统 RAG 可能会得到类似于“科幻”、“90年代”或“2010年代”的块，但在编织演变叙事方面会遇到困难。

信息综合比较（作者）

凭借在相关实体之间遍历的能力，GraphRAG 可以为复杂查询提供更全面、综合的响应。

没有一种方法适合所有情况

虽然 GraphRAG 是回答更细致、广泛和探索性问题的更好方法，但在某些用例中，传统的 RAG 更为合适。

GraphRAG 的成本非常高，无论是从 token 的数量、嵌入还是检索时间来看。

如果在本地系统上使用 LLM 时使用 GraphRAG，那么成本因素就不是问题，但与计算文档块的嵌入相比，索引（提取 + 嵌入）时间仍然相当高。

传统的 RAG 仍然是更好的选择：

简单、基于事实的查询: 对于“《黑客帝国》是什么时候上映的？”这样的提问，**传统 RAG** 将更快且更直接。
更容易实施: 对于较小的数据集或更简单的用例，**传统 RAG** 可能更容易设置和维护。

实施 GraphRAG 用于基于内容的电影推荐用例的原因很简单，已经通过上面的不同查询示例进行了说明。

我们希望我们的 RAG 方法能够回答高度广泛（全球性）、细致（地方性）和复杂的查询。使用传统的 RAG 方法，很难始终如一地满足如此广泛的查询范围。

结论

虽然 GraphRAG 在理解我们电影领域的上下文、关系和复杂查询方面提供了显著的优势，但传统的 RAG 仍然有其存在的价值，特别是在更简单、直接的用例中。

从下一个博客开始，我们将开始在 Python 中实现 GraphRAG 的关键组件。随后，将所有组件结合起来，根据用户查询推荐电影。

软件开发

人工智能

技术

生成式人工智能工具

大语言模型

Barry's Home