利用LLM构建非结构化文本的知识图谱，复杂数据知识图谱

非结构化数据，如文本文档和网页，蕴藏着大量有价值的信息。挑战在于如何挖掘这些见解，并连接分散来源之间的点。

知识图谱将这些非结构化数据转化为结构化表示。它们绘制出关键实体、关系和模式，支持高级语义分析、推理和推断。

但是，如何从一堆非结构化文本文档构建一个有组织的知识图谱呢？以前，这需要耗时的手动工作，但大型语言模型（LLM）使得自动化大部分过程成为可能。

在这篇博客中，我们将探讨一种简单但强大的方法，通过使用LLM从非结构化数据构建知识图谱，步骤如下：

该项目的代码可以在 GitHub (https://github.com/neo4j/NaLLM) 上找到。

1. 提取节点和关系

我们采用最简单的方法，将输入数据传递给LLM，让它决定提取哪些节点和关系。我们要求LLM以特定格式返回提取的实体，包括名称、类型和属性。这使我们能够从输入文本中提取节点和边。

然而，LLM存在一个被称为上下文窗口的限制（大多数LLM的上下文窗口在4000到16000个token之间），这个限制可能会因较大输入而导致处理受阻。为克服这一限制，我们将输入文本划分为适合上下文窗口的更小、更易处理的块。

确定文本的最佳分割点本身就是一个挑战。为了简化操作，我们选择将文本划分为尽可能大的块，以充分利用每个块的上下文窗口。

我们还引入了一些来自前一块的重叠部分，以应对某些句子或描述跨越多个块的情况。这种方法使我们能够从每个块中提取节点和边，表示其中包含的信息。

为了在不同块中保持对不同类型实体的标签一致性，我们向LLM提供了从前几块中提取的节点类型列表。这些类型开始形成提取的“模式”。我们发现，这种方法增强了最终标签的一致性。例如，LLM不再为“公司”和“游戏公司”生成单独的类型，而是将所有类型的公司统一为“公司”标签。

在我们的方法中，一个显著的障碍是重复实体的问题。由于每个块是半独立处理的，在组合结果时，不同块中相同实体的信息会创建重复的实体。显然，这一问题引出了我们的下一个步骤。

现在我们有了一组实体。为了解决重复问题，我们再次使用LLM。首先，我们根据实体类型将其组织成集合。随后，我们将每个集合提供给LLM，使其在合并重复实体的同时整合它们的属性。

我们使用LLM来完成这一任务，因为我们无法确定每个实体的名称是什么。例如，最初的提取可能生成了两个节点：（Alice {name: “Alice Henderson”}）和（Alice Henderson {age: 25}）。

这些引用相同的实体，应合并为一个包含名称和年龄属性的节点。我们使用LLM来完成这一任务，因为它们擅长快速理解哪些节点引用相同的实体。

通过对所有实体组重复这一过程，我们获得了一个结构化的数据集，准备进一步处理。

在最后一步中，我们将LLM的结果导入Neo4j数据库。这需要将生成的文本解析并转换为Neo4j可以理解的格式。为此，我们将LLM生成的文本解析为对应不同节点和关系类型的独立CSV文件。

这些CSV文件随后映射为与Neo4j数据导入工具兼容的格式。通过这种转换，我们可以在导入Neo4j数据库之前预览数据，利用Neo4j导入工具的功能。

最终，我们完成了一个由三部分构成的应用程序：一个用于输入文件的用户界面、一个执行上述过程的控制器，以及一个与控制器通信的LLM。源码可在 GitHub(https://github.com/neo4j/NaLLM)上找到。

我们还创建了一个基本相同但带有模式选项的管道版本。此模式就像一个过滤器，用户可以限制LLM在结果中包含哪些类型的节点、关系和属性。

我通过给应用程序提供詹姆斯·邦德系列的维基百科页面，并检查它生成的知识图谱来测试该应用程序。

该图谱子集展示了生成的内容，我认为它合理准确地反映了维基百科文章。图谱主要由代表书籍及与这些书籍相关的个人（如作者和出版商）的节点组成。

然而，图谱中存在一些问题。例如，伊恩·弗莱明在他所写的大部分书中被标记为出版商而非作者。这种差异可能归因于语言模型在理解维基百科文章的这一特定方面时遇到的困难。

另一个问题是书籍节点与同名电影导演之间的关系得到了包括，而没有为电影创建单独的节点。

最后，值得注意的是，LLM在解读关系时显得非常字面化。例如，使用“使用”这个关系类型来连接詹姆斯·邦德角色与他驾驶的汽车。这种字面化的方式可能源于文章中使用了动词“使用”而非“驾驶”。

这种方法在演示中效果相当不错，我们认为它表明使用LLM创建知识图谱是可行的。然而，这种方法也面临一些问题：

• 不可预测的输出：这是LLM的固有特性。我们无法预知LLM将如何格式化其结果。即使我们要求其以特定格式输出，它也可能不遵循。这可能在解析生成内容时导致问题。我们在数据分块时曾遇到过一个例子：大多数情况下，LLM生成了一个简单的节点和边列表，但有时LLM会对列表编号。像Guardrails和OpenAI的函数API等工具正在发布，旨在解决这个问题。虽然LLM工具的发展还处于早期阶段，但我们预计这不会成为长期问题。
• 速度：这种方法较慢，处理单个较大的网页通常需要几分钟。可能存在一种从根本上不同的方式来加快提取过程。
• 缺乏可追溯性：我们无法知道LLM为什么从源文档中提取了某些信息，或者这些信息是否真的存在于源文档中。因此，使用LLM生成的知识图谱的数据质量远低于未使用LLM的流程生成的图谱。