核心观点：

1. GraphRAG 是结合图数据库和向量数据库的检索增强生成方法，旨在提高检索精度和生成质量。
2. 图数据库能够捕捉实体间的显式关系，弥补向量搜索在某些情况下的不足。
3. 构建高质量的图是 GraphRAG 的关键挑战之一，目前有多种方法可以从非结构化文本中提取实体和关系。
4. GraphRAG 不应被视为单一解决方案，而是一套结合向量检索和图检索的工具和方法。
5. 未来图数据库可能在代理系统和混合符号-统计 AI 系统中发挥重要作用，GraphRAG 只是其应用的一小部分。

在这期 Practical AI 播客中，主持人 Daniel Whitenack 和 Chris Benson 与嘉宾 Prashanth Rao 深入探讨了 GraphRAG 技术的发展现状、应用前景及未来趋势。

/ GraphRAG：超越炒作的实用之道 /

1

引言：回顾与展望

Daniel: 欢迎收听 Practical AI 的又一期节目。我是 Daniel Whitenack，Prediction Guard 的 CEO 兼创始人。今天由我的老搭档 Chris Benson 与我一同主持，他是 Lockheed Martin 的首席 AI 研究工程师。

Chris: 今天状态不错，Daniel。你怎么样？

Daniel: 我感觉棒极了。回想过去几年，我们制作的这些节目不仅影响了我的日常工作，还带来了许多宝贵的人脉。其中一期关于向量数据库的节目特别令人印象深刻，今天我们很高兴能邀请到那期节目的嘉宾重返节目。他就是现在在 Kuzu 担任 AI 工程师的 Prashanth Rao。非常高兴你能再次加入我们，Prashanth。

Prashanth: 嗨，Daniel，嗨，Chris。很高兴能再次参与到节目中来。

2

从向量数据库到图数据库

Daniel: 过去几年里，每当涉及向量数据库的话题，我总会想到你的那系列博客文章。它们真的帮助我建立了正确的直觉。现在你已经转向了另一家数据公司，从事不同类型的数据工作，这也是我们今天要讨论的主题。这一年来有什么新的进展和有趣的项目吗？

Prashanth: 确实有不少新动态。简单回顾一下，去年我们讨论向量数据库时，我还在加拿大皇家银行工作，主要研究向量搜索和各种数据库选项的差异。同时，我也在探索图和图数据库的应用。我对这两个领域如何融合很感兴趣，因为知识图谱和图已经存在很长时间了，而向量语义搜索去年左右才开始引起广泛关注。

在思考这些主题时，我发现了一个新的开源嵌入式图数据库 GUZU，也就是我现在工作的地方。我在多伦多的一次聚会上遇到了 CEO Semih Saliholu，对这个工具和技术产生了浓厚兴趣。GUZU 作为嵌入式和开源数据库的特性很吸引我。

我开始在业余时间研究它，与开发团队交流，也了解社区中其他人如何使用图数据库和图工具。最终，我意识到这是一个深入图和图数据库世界的绝佳机会。今年年初，我加入了 Kuzu，现在负责开发者关系工作，与不断增长的 Kuzu 用户社区互动，这真的很有趣。

我还在研究推动这个领域发展的用例，了解社区如何使用这些工具。值得一提的是，我仍然关注着向量数据库生态系统，在业余时间也在积极实验一些项目。我仍然很喜欢使用去年提到的 LanceDB。看到这些不同类型的工具如何融合真的很令人兴奋。

3

图数据库基础

Chris: 上次我们关于 Lance 和其他向量数据库问题的讨论确实很精彩。对于那些可能不太熟悉图及其用途的人，你能否简单介绍一下什么是图，为什么我们应该关注它，以及它能为我们做什么？

Prashanth: 图有时也被称为知识图谱，是通过节点和边来表示结构化数据的一种很好的方式。节点基本上是现实世界中的实体，比如人或公司，而边是这些实体之间的关系，如"共事"或"是某公司的 CEO"等。

正式一点说，"知识图谱"这个术语实际上指的是比我刚才描述的更复杂的东西。理论上，知识图谱可以用来表达那些很难用表格形式存储的数据，它还支持对图进行一些逻辑推理。这就是你在存储维基百科数据时会用到的方法。

但这超出了我们今天讨论的范围。对于大多数人和开发者来说，"图"和"知识图谱"这两个术语可以互换使用。在这次讨论中，我就交替使用这两个术语。

Daniel: 这有点像区分机器学习和 AI，在实际应用中，它们的界限并不那么重要。

4

图数据库与关系数据库的对比

Chris: 在我们继续之前，你提到了图与关系数据库的关系。考虑到关系数据库已经存在很长时间了，很多人可能都是从那里开始的。你谈到图的边描述了这些关系，在某些方面比关系数据库做得更好。你能稍微谈谈它们之间的区别吗？这样人们就能理解为什么有时候应该从传统的数据库转向图数据库方法。

Prashanth: 在讨论数据库方面之前，我想先指出图的用途。因为大多数人需要先理解图的用途，然后才会考虑如何存储它。

图的优势在处理高度互连的数据时变得显而易见。例如，在医学领域，你可以有患者与症状、疾病、治疗疾病的药物及其副作用之间的关系。这些都有复杂的相互关系。

同样，在金融领域，你可以有直接或间接交易的链条，比如说在岸和离岸账户之间的交易，这些最终都会连接到世界上的某些个人。

你可以选择使用关系数据库中的表来建模这些数据，也可以选择在图数据库中将其建模为图。无论哪种情况，都有利有弊。

但是，当你分析模式并且想以分析的方式理解这些复杂的关系时，使用图数据库可能会非常强大。它更直观，构建能回答这些问题的查询也更容易。这就是将数据建模为图的强大之处。

回到数据库的概念。图数据库可以被认为是一种专门的数据库，允许你可扩展地管理和查询组织为图的数据。这些图数据库的性能优势来自于专门的数据结构和运算符，允许你表达复杂的连接并高效地遍历数据中的路径。

很多听众可能已经听说过图数据库。最流行的图数据库模型是属性图数据模型，它是由 Neo4j 发明和推广的。我自己过去也使用过 Neo4j。今天，你有很多其他的图数据库，比如 Kuzu，也实现了属性图数据模型。

但总的来说，你从一个更概念化的数据模型开始，它允许你表达如何存储和查询你的数据。图数据库基本上是允许你表达所选图数据模型的底层系统。

对于某些涉及连接数据和这种相互关联数据的查询，它比关系数据库更直观的原因是，它允许你使用图数据库提供的查询语言以更简洁和直观的方式表达查询，同时还有遍历数据路径的性能优势。

5

图数据的实际应用

Daniel: 为了具体说明这一点，你能给出一些例子吗？比如说，除了典型的人员相关的事物，如 Daniel 是一个节点，他是 PredictionGuard 的 CEO，这是另一个节点，还有组织等。对于那些可能无法理解这种结构如何与他们企业中的数据相关的人来说，你能给出一些其他例子吗？也许是在不同的垂直领域，或者你在 Kuzu 的用例中遇到的一些超出社交网络类型数据的数据？

Prashanth: 当然可以。我认为社交网络获得了过多的信誉，被认为是我们所知的原始图。当然，它们很强大，而且图在社交网络中被广泛使用。

但是，我之前提到的医疗场景就是一个例子。在这个场景中，你不仅有个人或患者的网络，还有药物和被这些药物治疗的不同疾病症状。这些都可以延伸出更复杂的关系。

在医疗保健或生物医学场景中，你可以想象这些数据在许多不同的来源中以结构化形式预先存在。你可能实际上在关系数据库或某个地方的数据湖中有人们的医疗记录。

许多处理这类数据集的现有工作流程倾向于坚持使用已经作为主要存储的数据库。其中很多恰好是关系数据库，这很好，因为当你有人的记录，比如说他们一直在服用什么药物以及这些药物可能导致什么症状等时，它们是存储这种数据最高效和方便的方式。

所以，这里的想法是，你实际上可以将关系数据库中存在的相同数据视为图，将其存储在图数据库中，并以一种方式应用你的图查询逻辑，使你能够回答在关系数据库中使用 SQL 可能相当复杂的特定问题。

我已经提到了金融交易场景，在那里你有个人之间的交易图，他们与之互动的商家，他们在账户之间进行的资金转移，这些账户是如何连接的。金融机构大量使用图来回答这些类型的问题。

交通网络是另一个常见的用例。如果你与市政当局合作，想要了解交通流量和人们在不同地点之间移动的数量，这实际上可以很好地在图中建模。

你可以回答的问题类型也可能会根据你选择将其建模为表格还是图而改变。还有许多其他例子。

我想强调一点，我之前提到的 Wikipedia 作为图的例子，我认为它强化了这样一个观点：知识图谱是一个需要谨慎使用的术语。一般来说，图是节点（或实体）如何在网络中与其他节点连接的一般表示。

知识图谱是你可以认为是该领域中所有可用知识的集合。在 Wikipedia 的情况下，你可以想象在某些情况下，很难将每一条信息都制成表格。例如，如果你有，比如说，美国现任总统是乔·拜登。

基于当前的政治结构和乔·拜登所代表的不同政党，以及那些政党中代表的所有其他人，然后是政党与州之间的关系，州与国家之间的关系，你可以想象这变成了一个非常复杂的分支结构，并不是所有内容都能很好地呈现在表格中，因为你无法想象一个表连接到另一个表，当你有这种复杂的数据时。

所以在某些情况下，你构建图的数据模型和方式实际上可能对你可以问的问题类型产生很大影响。

这就是为什么我倾向于以更专业的方式使用"知识图谱"这个术语。一般来说，我会说你可以很方便地使用属性图模型将你的表格数据或记录视为图，并模拟交易网络、社交网络、药物相互作用网络等。

6

GraphRAG 简介

Daniel: Prashanth，在我们深入讨论我一直很兴奋要在节目中谈论的话题——GraphRAG 之前，我认为有必要简单回顾一下大多数人在提到 RAG 工作流程时指的是什么。我昨晚参加了一个 CIO 晚宴，其中一位演讲者说："我们都听说过 RAG、raggedy rag、ragged、rag、rags。"每个人都在谈论这些东西，但也许值得花 30 秒到一分钟的时间来提醒一下。当大多数人提到 RAGs 或 RAG 工作流程时，他们指的是什么？

Prashanth: 这确实是一个非常有趣的话题。让我们从头说起。RAG 代表检索增强生成（Retrieval Augmented Generation）。需要注意的是，RAG 这个术语出现在 LLM（大型语言模型）这个术语之前。

RAG 源于 2019 年底到 2020 年初生成语言模型的改进。2020 年初有两篇论文，一篇来自谷歌，另一篇来自 Facebook Research，首次提出了检索增强生成这个术语。值得注意的是，检索本身并不新鲜。信息检索作为一个领域已经存在了几十年，我们也已经有了基于关键词的信息检索系统几十年了。

现在的新之处在于生成模型变得比以前更好了。所以，生成能力是新的。当你看 RAG 这个术语时，"检索增强"在那个缩写中排在"生成"之前。我希望这能清楚地表明，生成部分是我们强调的新颖方面。

7

RAG 的发展历程

2020 年，RAG 的实现方式是将序列到序列的语言模型（当时语言建模的标准方式）与密集嵌入的检索能力相结合。这些模型可以相当令人信服地生成文本。Facebook Research 的论文将他们的工作建立在维基百科文章的密集嵌入基础上。

这就有了我们今天认为理所当然的基于向量嵌入检索的初步雏形。后来在 2020 年，GPT-3 发布了。于是有了 LLM 或大型语言模型这个术语的创造。你可以把 GPT-3 看作是当时真正扩展了现有模型能力的第一个大型语言模型之一。

但在我看来，真正让 RAG 从 2021 年开始起飞的是一大批我们称之为向量数据库的新系统的出现。它们开始提供专门的功能，使从这些密集嵌入中进行检索变得更加容易，而且更具可扩展性。这导致了我们去年讨论的所有那些向量数据库公司的爆发。

我希望这能为 RAG 这个术语本身以及它如何发展到今天的样子提供一些背景。

8

GraphRAG 的概念与实现

Chris: 我们一直在节目中暗示这个话题。我们已经讨论了图，也简单谈了一下 RAG，让大家做好准备。现在每个人都在等着我们问你关于 GraphRAG 的问题。所以，如果你想深入探讨这个话题，给我们一个介绍，我们很乐意听听。

Prashanth: 当然。让我们先了解我们用 RAG 做了什么，然后再谈 GraphRAG。早期的 RAG 方法，我们现在称之为朴素 RAG。在这种方法中，你只是创建数据的块，用嵌入模型对其进行嵌入，然后将它们存储在向量数据库中。基本上，你只是将块和块嵌入存储在向量数据库中。

当你进行检索时，你使用相同的嵌入模型将你的查询转换成嵌入。这会返回与查询向量最相似的块。你通常会返回前 K 个，比如说前 5 个或前 10 个，无论你选择多少。然后，这些前 K 个块可以作为上下文发送给 LLM，以合成自然语言的回应。

简而言之，这就是传统 RAG 所做的。现在，理论上，这种朴素的 RAG 方法很好。但很快就显现出了局限性。

9

朴素 RAG 的局限性

第一个限制是，密集嵌入通常是在句子级别进行的。而许多用户查询使用关键词，像 BM25 这样的基于关键词的搜索方法在这方面做得很好，而且它们已经存在很长时间了。

所以去年年底，你可以看到很多这些向量数据库供应商开始提供混合搜索方法的组合，"混合搜索"这个术语本身也变得更加流行。在混合搜索中，你同时执行基于关键词的搜索（这是一种稀疏向量搜索形式）和基于密集向量的搜索，然后将从这两种方法检索到的块传递给重新排序模块。所以你有专门的模块进行重新排序，给你从这两种检索中得到的最相关的块。

这就是你如何将稀疏向量和密集向量结合成所谓的混合搜索。

10

混合搜索的局限性

现在，即使是混合搜索也有其局限性，这就是人们今年早些时候，也许更早，开始探索进一步选择的地方。因为无论是稀疏嵌入还是密集嵌入都不能很好地捕捉实体之间的显式关系。在某些情况下，你真的可以受益于明确地模拟这些实体。让我用一个例子来说明这一点。

考虑一个教授和他指导的博士生的例子。假设你有一段文本，谈论这些学生和教授，以及他们在大学里的其他工作。

在自然语言中，我们理解教授和学生之间的关系如下：学生 X 与教授 Y 共事，因为我们知道作为教授的学生意味着你与他们共事。

但在文本本身中，可能并没有这样表达。文本可能写成："某某人，X 是 Y 的学生。"现在，如果你试图用"X 与谁共事？"这个查询来搜索，这在自然语言中是一个非常直观的问题。我们人类立即就能将两者联系起来，知道共事和学生关系在这里在语义上是相似的。

所以我们能够将这些信息拼凑起来，知道一个人是某人的学生，本质上他们就是与那个人共事。

然而，如果你试图用向量搜索来搜索这个，密集嵌入可能无法正确捕捉这种关系，因为在向量空间中，"是某人的学生"可能与"与某人共事"不够接近。

所以你的向量搜索可能无法检索到这个答案，因为你没有以那种明确的方式建模关系。

然而，如果你选择将其建模为图，你就会明确地用三元组的概念捕捉这种关系，即人 X 与人 Y 共事。这就是三元组的概念所在。

三元组本质上是通过关系连接的两个节点。你有一个源和一个目标，人 X 是源，人 Y 是目标，"共事"代表关系。

11

GraphRAG 的优势

这里的一个非常强大的想法是，图在整个画面中的重要性，以及它与 RAG 的相关性在于，你实际上可以通过同时从密集嵌入向量搜索和图遍历中进行检索，为 LLM 提供额外的有价值的上下文。

然后，你可以将这些检索结果结合起来，为生成 LLM 提供额外的上下文，这样你就可以在你的答案中包含这种明确的关系。

这在实践中已经得到了证明，最近有一些工作就是这样做的。

Chris: 我想问一个可能有点延伸的问题，但当你描述这种无法明确表达的失败时，这是否可能导致模型输出中的幻觉？因为它无法明确表达，所以它仍然试图提供信息，最后得出了它能得出的任何结论。这是否可能？

Prashanth: 这是一个很好的观点。你绝对是对的。幻觉，我认为在某些情况下绝对是很有可能的。你显然无法预测幻觉何时会发生，这是 LLM 普遍存在的一个大问题。

我想我绝对要在这一点上多说一些。顺便说一下，我刚才谈到的过程基本上就是你可以松散地定义为 GraphRAG 的东西，即你将图作为检索过程的一部分。

现在，所谓的 GraphRAG 的卖点，正如它在过去几个月里被各种来源"营销"的那样，是它减少了幻觉。重要的是要注意，无论何时为生成目的向 LLM 提供上下文，本质上都是提供一个提示，提示是 LLM 用来提供响应的。

在提供这样一个提示的情况下，总是有可能在某个时候会出现幻觉。无论信息来自图还是来自向量检索，都无关紧要。使用 LLM 生成文本的行为本身意味着存在固有的幻觉机会。

所以我不会说 GraphRAG 的好处是它消除或减少了幻觉。我会说它的好处是，它实际上增加了事实准确性的机会，因为一个在这个向量嵌入中没有明确捕捉到的关系现在在图中被明确捕捉到了。

通过向 LLM 提供这两部分上下文，你基本上是在增加得到事实正确或更相关响应的机会。

12

GraphRAG 的实际实现

Daniel: 我在想的一件事是，人们可能会有一些想法，比如说他们可能已经建立了某种朴素的 RAG 系统，或者甚至实现了一些高级的 RAG 方法。但大多数时候，他们拥有的是一组文档，就像你说的，它们被分成块。他们对这些块进行嵌入，然后检索一个或多个块，也许是以混合方式或某种高级方式。

但在这里，你说的是结合向量方法和图方法。我想知道你能否非常具体地为我们分解数据方面的内容。所以如果我有文档或内部数据，我需要准备什么，如何构建数据方面的内容以准备进行 GraphRAG。

然后，假设我在聊天机器人或其他什么地方收到用户查询问题，实际上检索到的是什么？以及它是如何与提示结合到模型中的？或者它可能如何结合？所以只是带我们了解这些非常具体的事情可能对人们有帮助。

Prashanth: 当然，这很有道理。所以在任何 RAG 应用中，不仅仅是 GraphRAG，有两个关键阶段，即你将其分为索引阶段和检索或服务阶段。

所以将数据输入并存储和索引是我们称之为索引阶段的内容。这是前期或上游阶段，在这里你有已经存在于不同结构化或非结构化来源中的数据。

现在你可以应用各种技术，包括使用 LLM 本身来进行这个阶段，从非结构化数据或已经存在的结构化数据中提取实体或所谓的命名实体，并将它们作为实体或节点存储在图数据库中。

同时，你还可以从这个非结构化文本中提取关系。有许多不同的方法可以用来提取关系。

现在，我最近注意到的是，很多最近的论文都在使用 LLM 来帮助这个信息提取步骤。你实际上使用 LLM 来提取你的块的部分。

然后从这些部分，你进一步细化它，说，好的，从这个文本块中，告诉我存在哪些三元组，即通过关系连接的节点。

一旦所有这些三元组被提取出来，它们基本上被存储在一个图数据库中。同时，你还可以有一个并行的管道，将向量嵌入存储在向量数据库中。

在某些情况下，你可以在同一个数据库中同时拥有向量和图实体。某些数据库具有这些功能。在其他情况下，你可能不想把它们都放在同一个数据库中。

你可能想利用图数据库的优势和向量数据库的优势。你可能还有已经将数据存储在这些系统中的预先存在的工作流程。

所以将你的独立数据源移动到各自的数据库中是完全有效的。例如，你的图实体会进入你的图数据库，向量嵌入会进入向量数据库。

在此之后，你可以做额外的后处理，比如将块引用 ID 链接到图中的单个实体。基本上，在图中表示实体的节点可以有一个 ID，将其链接回它所属的块，这样当你检索特定块时，你实际上可以指出该块中存在哪些实体。

所以这些是人们在构建图和向量存储时都在做的许多额外的前期步骤。

一旦这个索引阶段完成，检索阶段就可以开始了，这是我们非常熟悉的阶段。你有一个以自然语言形式出现的用户查询。你将其转换为嵌入。

你对该嵌入进行相似性搜索，这会从向量数据库中返回最相似的向量。然后同时，你还可以使用你拥有的任何方法将该查询转换为图查询，并从图中检索回答该问题的实体和关系，然后使用重排序器以一种为 LLM 生成提供额外上下文的方式组合这些检索结果。所以再次总结一下，RAG 管道中的两个关键阶段包括索引和服务。每个阶段都有一套工具，可以帮助用户实现所需的结果。

13

GraphRAG 的实际应用示例

Chris: 在休息之后，我还在思考你在休息前告诉我们的内容，试图自己理解它。我在想如何以实际的方式使用它。为了帮助我理解，并将其从概念层面转化为我们结束播客后可以去做的实际事情，你能给我一个例子吗？一些人们可能正在做的非常实际的事情，这真正将其置于"好的，我明白了，现在我要去做"的背景中。

Prashanth: 我实际上有一个仓库，我可以在我们结束对话后分享。我很乐意看到人们拿起这个并进行实验。显然，因为我在一家构建图数据库的公司工作，我非常热衷于与使用这些类型工具的用户交谈。

对于我的实验，我使用了 Kuzu 作为图数据库，LanceDB 作为向量数据库，因为正如我提到的，这些在各自的领域都有自己的优势。我想展示的一个实际例子是这样的。

我正在考虑的数据集，我可以在仓库中展示，是关于科学家玛丽·居里的一段文字。你知道，她发现了镭和钋，赢得了两次诺贝尔奖。她与皮埃尔·居里有关系，他们是配偶。她还与整个生态系统中的其他科学家有关系。

所以我有一个文本样本，包含了玛丽·居里对科学的贡献和她生活中存在的关系。这是非结构化文本。所以第一步是，我们可以做两件事。

我们可以进行传统的朴素 RAG 检索，我试图问一个问题，"皮埃尔·居里与谁共事？"这是一个非常简单的问题。如果你对文本进行嵌入并执行所需的步骤，向量搜索肯定会给你一个答案。我在这个数据集中注意到的是有一个隐含的关系。

这就是为什么我之前给出了关于教授和学生的例子。在这个数据集中有一个特定的人，保罗·朗之万，他是皮埃尔·居里的学生，后来在皮埃尔·居里去世后与玛丽·居里有了关系。

所以在文本中提到保罗·朗之万是皮埃尔·居里的学生。现在，问题是问皮埃尔·居里与谁共事？我们显然知道皮埃尔·居里与玛丽·居里一起工作发现了这些元素。

现在，我们也隐含地知道皮埃尔·居里与保罗·朗之万一起工作，因为他是他的学生。向量搜索，如果你天真地将这些分块并存储在向量数据库中，这是我在 LanceDB 中做的，会给我一个答案。

它告诉我玛丽·居里与皮埃尔·居里一起工作。

但是图搜索，由于我明确插入了关系，我有一些代码显示了如何使用 LLAMA index 框架从非结构化数据中提取信息。所以一旦你实际安装了所需的包，开始实验就非常直观和容易。

所以，我在这里说的是，在图中我能够检索到两个答案，即保罗·朗之万和玛丽·居里，他们都与皮埃尔·居里一起工作。而不是仅仅使用图的结果，可能还有其他场景，我的问题可能有点模糊或不清晰，向量搜索可能会给我一个更好的结果。

我确信如果你调整数据集和这里的问题，你会找到这样的例子。所以我在向量搜索和图搜索的下游加入了一个重排序器。

当我检索结果并将其作为上下文传递给 LLM 时，我添加了那个重排序步骤，这样我就能得到最相关的图搜索结果以及最相关的向量搜索结果。

在这种情况下，向量搜索错过了其中一个实体，但图搜索捕捉到了它。所以来自这两个检索的组合上下文使我能够让生成模型给我正确的响应。

如果你想进一步实验，我认为很容易想出其他查询，这些查询会显示相反的结果，即向量搜索和查询之间的语义匹配可能更接近，你可能从向量搜索得到一个更相关的结果，而图搜索由于不匹配而错过了结果。所以这就是我在这里要说的。

有很多方法可以结合向量搜索和图检索来提高检索准确性。所以我希望社区能思考这些个别部分。

我认为，从过去几个月阅读文献和与质疑 GraphRAG 是什么的人交谈中得到的最大收获是，人们倾向于将 GraphRAG 仅仅视为基于图的解决方案，而我越思考，我认为这两种方法，使用密集向量检索和使用图，对于 RAG 的目的来说是齐头并进的。

话虽如此，你可能会在网上看到很多相互矛盾的文章和博客文章，声称这就是做 GraphRAG 的方式。

每个人的关键收获应该是，将其视为一套工具和方法的组合，这些工具和方法结合在一起以增强检索，从而获得更好的生成。

14

构建图数据的挑战与解决方案

Daniel: 我想深入探讨你提到的一点，这也是我心中的想法，我想其他人可能也有同样的想法。主要是因为我不知道多少年前，五六年前，我做过一些与图相关的数据工作。我知道我当时看了很多东西，甚至有一整个研究领域叫做自动或自动化知识图谱创建。

有一种想法是，一旦你有了一个图，在查询和丰富结构方面就会为你打开很多可能性。但有时候从头开始构建图可能会让人望而生畏。你提到了围绕 llama index 的这些不错的工具。

当然，我们之前在节目中也邀请过 Jerry，那是一个如此了不起的项目，帮助了很多人。但我想深入探讨这一点，就是你在图构建部分的经验是什么，当前的状态如何？除此之外，还有多少工作量，有多难？

因为我认为人们喜欢 RAG 的一个原因是，你只需放入一堆文档，然后轻松处理，你构建这些块，然后哇，你就从中得到一些很棒的东西。

当然，你强调的一个元素是，有时候人们很难获得那最后一点朴素 RAG 无法捕捉到的性能。

但是在图数据构建这一块，现在看起来怎么样，你发现什么是有用的？

Prashanth: 你说到点子上了。我认为人们在谈到 GraphRAG 和一般使用图时面临的最大问题是，如何从你已有的其他形式的现有数据中创建图？

是的，我本来就要谈到这一点，这是我的下一个要点，GraphRAG 绝不是完美的。最大的挑战确实是围绕图的构建。

关于图构建，我们可以深入研究两件事。首先是图的质量绝对至关重要，因为我们知道，在任何 RAG 系统中，检索的质量极大地影响了下游生成的质量，糟糕的检索结果会导致生成模型输出垃圾。

所以首先，我们必须强调，要充分利用 GraphRAG，我们需要一个高质量的图。但是然后你再往前走一步，那就是你如何从非结构化文本中获得图？

正如你提到的，Lama Index 和我认为 Lanchain 也是，这些框架提供了有价值的工具来帮助你从非结构化文本中提取三元组或实体和关系。

他们主要通过使用 LLM 来做这个。但是我们知道，LLM 本身存在幻觉问题，或者它们一般存在可重复性的问题。

你不能保证如果你多次运行同一个 LLM 会得到相同的结果。虽然一些 API 提供种子，你可以控制可重复性，但这仍然不意味着它不是随机的。

LLM 的输出仍然或多或少是不可预测的。所以有很多其他的平行工作正在进行，不使用 LLM 从非结构化文本源中提取三元组。

我可以谈谈我发现真正令人兴奋的几个。事实上，这就是我一直在这个领域探索的东西。我很乐意与也在做这个的人聊天。

所以有一些定制的机器学习模型正在出现。其中一个叫做 Rebel，R-E-B-E-L。它已经存在一段时间了，但我认为他们现在正在为新版本升级内部结构。

所以那是一个专门为图的目的训练的模型，用于提取三元组。还有另一个模型，我认为叫做 Relik，R-E-L-I-K。

这也是最近发布的一个开源模型，人们一直在使用它从非结构化文本中提取关系。现在，这并不是说这些是成熟的模型。

它仍然需要一些调整，人们需要理解它们的输出和从中得到的东西。但这里的想法是，这些模型在你可以从中输出的内容上更可控。

它不像 LLM，你就是不知道你会得到什么。当然，我认为因为它们是小模型，你实际上可以在非常大的数据上大规模使用它们。所以这是一个角度。

我相信很多用户都听说过 NLP 库 spaCy。我自己已经使用 spaCy 多年了。它是一个非常棒的库。

spaCy 本身没有从文本中提取关系和实体的工具。当然，你可以提取命名实体或进行命名实体识别（NER）。

但最近出现了一些插件模块或库，可以插入到 spaCy 中。其中两个，我在这里会提到，它们叫做 Gliner 和 Glirel。G-L-I-N-E-R 和 G-L-I-R-E-L。

正如它们的名字所暗示的，一个是用于从文本中提取命名实体，另一个是用于从文本中提取显式关系。

但它们插入到底层的 spaCy 分词器和底层的 spaCy 数据表示中。我感觉它更易用。我一直在做一些实验性的笔记本。

我将进行更多实验，看看它们与仅使用 LLM 提取数据相比如何。所以是的，我认为这是一个非常活跃的领域。在如何使用这些工具方面没有正确的答案。

但我觉得已经有足够的选择和方法，人们不必觉得我完全依赖于完全黑箱的、不可靠的 LLM 来做事情。

15

GraphRAG 的未来展望

Chris: 你到目前为止讲的内容真的很吸引我。我在这次对话中学到了很多。当我们即将结束这个话题时，你知道，我们已经讨论了 GraphRAG，以及构成它的组件，还谈到了如何结合向量搜索和图搜索。

感觉我们正在跃入一个勇敢的新世界，即使对于 AI 这个本来就是这样的话题来说也是如此。这个领域的发展速度非常快，只需几个月就会有很大的变化，但如果你能选择几个点告诉我们你认为可能会发生什么。

如果你错了，也没关系，但我很想看看你的想象力为我们准备了什么。

Prashanth: 是的，我很想看看一年后的情况，因为我知道我说的一半东西可能会过时或错误。

Chris: 当然，但这就是这个话题的特点。

Prashanth: 我去年说的东西，我认为仍然是准确的，因为我去年也谈到了图和向量，现在仍然相关。所以这次我会再冒险一试。

所以是的，你说得对。事情变化得太快了。我个人的看法是，GraphRAG 是一个时间点，我们甚至不知道在未来三到五年的时间框架内，RAG 是否会像今天这样热门，对吧？我不认为 LLM 会消失，让我们面对现实。我的意思是，它们会一直存在。而且它们会继续发展。我们刚刚看到 OpenAI 推出的 GPT-4 模型，它们能够进行推理，能够做的事情比人们给予的信任还要多得多。

随着这种能力不断发展，LLM 不断进化成其他形式，无法保证今天使用自定义模型、机器学习模型所做的那些任务不会被 LLM 完成。现在，我看到的一些狂野的想法包括，你不需要在数据库中索引任何东西，你可能会让你的 LLM 参数以一种非常模糊的方式存储索引。

假设研究朝着某个方向发展，你可以从那个索引中检索。但显然，这还有很长的路要走。我不认为在未来几年内会发生这种情况。

16

代理系统的兴起

在未来几年内，我特别兴奋的是每个人都在谈论的代理系统。如果你看看所有这些框架公司在过去一年中的转变，像 Langchain 和 Lama Index，他们都在努力推动这个领域向前发展，探索代理如何帮助构建更强大的系统。现在，RAG 只是代理在协调的事物中的一小部分。

它们实际上可以做许多其他与推荐相关的事情，可以说像搜索和检索以及一系列其他活动。所以做代理的传统方式或标准方式一直是使用一个叫做 ReAct 的框架，你可以说它有点像基于图的框架，但它是静态的，你通过编程这些路径来决定系统的行为，代理根据它行动，然后你在推理步骤结束后把它送回去，等等。

但我认为图在未来实际上会被非常有趣地使用的地方，我已经看到一些框架的例子已经在这样做了，是你能否使用底层的图表示动作空间来指导你的代理？

也就是说，代理能否通过图结构主动更新动作空间？一旦发生这种情况，你基本上就可以拥有某种更强大的代理，它们不受僵化静态框架的约束。

你有一个动态更新的代理系统，但它不像我们今天所拥有的那种开放式递归代理调用那样开放。你仍然有一个框架。

图某种程度上充当了代理采取行动的基本结构。所以这绝对是代理发展方向的一个方面。

17

符号系统与统计模型的融合

话虽如此，知识图谱及其在符号系统中的作用已经存在很长时间了。它已经存在很久了。在未来，可能会出现利用图与基于 LLM 的统计模型结合的符号系统，以及结合这些工具的混合符号-统计系统。

这在技术上可能不被称为代理，但它仍然是一种混合型 AI 系统，因为你可能利用了 LLM 的语言能力，但然后使用符号系统来完成其他任务。

所有这些都是为了说明，我认为图比我们今天看到的用途要广泛得多。还有许多其他用例，我们在这次讨论中无法涉及。

GraphRAG 显然只是其中很小的一部分。所以我会说我现在对 GraphRAG 很兴奋，但我不认为这会是一个长期被广泛讨论的话题。

但是图作为一个实体和图数据库，这些系统实际上将成为未来许多系统的核心组件。

Daniel: 这是一个很好的视角，因为这是一个如此广泛的话题。当然，我们期待你回到节目中给我们更深入的探讨，或者阅读你的博客文章。

我强烈建议人们查看 Prashanth 博客文章的链接，我们也会确保在节目注释中包含我们讨论过的内容的链接。但是，再次感谢你的加入。

这真的很愉快，我感觉我现在有很多东西想去检查、尝试和学习更多。所以感谢你激发了我对这个话题的好奇心。

Prashanth: 是的，非常感谢，Daniel。非常感谢，Chris。我想以说 Kuzu 是一个嵌入式数据库来结束。所以你可以直接用 pip 安装 Kuzu，它非常容易上手。你可以在 Twitter 和 LinkedIn 上找到我。

我相信 Daniel 会分享这些链接，我们随时可以和任何对图感兴趣的人聊更多。

Daniel: 是的，一定要去看看。我们也会链接你提到的一些例子，这样人们就可以亲自动手尝试一些东西。

我喜欢这些嵌入式工具的这个特点，它们既让你可以在本地尝试东西，又提供了将这些东西投入生产的途径。所以，也要感谢你构建了这么棒的工具。

这是一个很大的贡献。谢谢，我们很快会再聊的。