如何从零开始构建多源知识图谱提取器

推荐语

构建知识图谱的全新自动化方法，为资源有限的组织提供解决方案。

核心内容：
1. 知识图谱的重要性及其在RAG应用中的作用
2. 构建知识图谱的传统挑战与新机遇
3. 大型语言模型在自动化知识图谱构建中的应用和挑战

杨芳贤

53A创始人/腾讯云(TVP)最具价值专家

引言

知识图谱是一种强大的解决方案，用于表示复杂且相互关联的信息。它们通过由实体（节点）和关系（边）组成的图来建模数据，从而能够表示和处理不同事实之间的联系。

尽管知识图谱长期以来已被用于搜索和推荐应用，但近年来由于检索增强生成（RAG）应用的广泛应用，其关注度显著上升。事实上，GraphRAG是一种技术，它通过从知识图谱中检索信息来增强大型语言模型生成前的上下文，有助于提升RAG系统的性能。

Vanilla RAG 系统依赖于密集向量存储来通过语义相似性检索信息。因此，它们在实体消歧、多跳问答以及结合分散在多个来源中的数据方面存在困难。GraphRAG 通过引入知识图谱增强检索过程，能够提升上下文理解，捕捉不同实体之间的关系，并结合多个来源的信息。

虽然将信息结构化为知识图谱具有多种优势，但从大量数据池中创建知识图谱的过程常常受到高成本和资源需求的阻碍。直到最近，构建知识图谱需要大量的手动标注、领域专业知识和复杂的流程，使其仅能为预算充足的大型组织所实现。幸运的是，大语言模型能力的快速进步为以远低于人工标注所需成本和时间的比例自动化知识图谱的创建过程打开了可能性。

虽然由LLMs自动提取的知识图谱可能在质量上不如专家人工标注的知识图谱，但在需要对大量数据进行结构化处理且预算有限的情况下，它们可能是唯一的选择。毕竟，在许多情况下，一个不完美但相当完善且广泛的知识图谱，往往比完全没有知识图谱要好。例如，在图RAG（Graph RAG）应用中，知识图谱被用作检索相关上下文的支持工具。事实上，不相关的信息仍可以被下游LLM忽略，而最终需要生成答案的细节可以直接从原始来源中获取。

有几种方法可以利用大型语言模型来自动化知识图谱的构建，每种方法在成本和质量方面都有一定的权衡，这取决于领域和需要结构化的文本数据的特定特征。一种流行的架构模式是使用多步骤管道，包括提取和聚合阶段。提取阶段利用大型语言模型来提取关系三元组，形式为（主体，关系，客体），可选地指定实体（主体和客体）和关系类型。聚合阶段的重点是统一提取的实体和关系，因为大型语言模型可以以文本变化的形式提取相同的实体和关系。例如，在同一个知识图谱中，一个指向玛丽·居里的实体可能被提取为“Marie Curie”或“Maria Salomea Skłodowska-Curie”。

实体消歧是提取信息来自多个来源或在扩展现有知识图谱时更加关键：在这些情况下，来源本身可能使用不同的术语来指代相同的底层实体和关系，或者可能使用与现有知识图谱中已有的不同术语。

能够处理非常长/多个来源的长上下文模型可能有助于缓解这一问题，但它们仍然会遇到一些限制。事实上，尽管在长上下文检索和针叶草中找针的任务上取得了最近的进展，但LLM在非常长的上下文中性能往往会下降，尤其是在复杂任务中。此外，能够处理百万标记长上下文的模型通常支持的输出长度要小得多，这可能不足以容纳从非常长的上下文中提取的所有关系（除非这些关系在原始来源中非常稀疏）。即使在这种情况下，模型仍可能提取具有细微名称变化的相同实体，尤其是如果这些实体在原始来源中存在的话。此外，仅依赖长上下文本身无法解决扩展现有知识图谱的问题，因为它们是从原始来源中提取的，而这些原始来源并不总是可用的，即使它们可用，仍然需要从头开始提取整个知识图谱，这可能会带来额外的成本。另一个需要考虑的点是，从较小的块中提取关系可以更好地定位关系在原始来源中的位置。这种额外的信息在处理RAG应用时特别有用，允许仅将原始来源中最有意义的部分包含到上下文中，从而提高LLM的性能，并有助于人类评估和验证生成的答案。

在本文中，我将展示如何创建一个简单且直接的代理工作流实现，以从多个来源中提取并扩展一致的知识图谱。该工作流由两个阶段组成：提取和构建。在提取阶段，一个大语言模型（LLM）会对文本片段进行基本的（主体，关系，客体）三元组提取。在构建阶段，LLM会检查在提取阶段中提取的每个关系三元组，并逐步将其添加到正在构建的知识图谱中。在此过程中，LLM可以决定丢弃那些信息已在知识图谱中表示的冗余三元组，或者对三元组进行细化，以更好地与现有关系保持一致。例如，如果一个实体已以不同的名称包含在知识图谱中，模型可以修改新三元组中实体的名称，以保持一致性并确保链接。

我已在该 GitHub 仓库 中分享了完整的代码，你可以在该 Colab Notebook 中尝试工作流。

https://github.com/GabrieleSgroi/knowledge_graph_extraction

https://colab.research.google.com/drive/1st_E7SBEz5GpwCnzGSvKaVUiQuKv3QGZ

工作流

在本节中，我将描述架构和工作流的主要方面。具体细节请参考共享的 GitHub 仓库中的代码。

为了解决从不同输入文档构建一致知识图谱的挑战，该过程被分为两个主要阶段：提取和构建。这是通过一个单一的代理工作流来实现的，该工作流协调提取器和构建器 LLM。我使用“工作流”这一术语，采用 Anthropic 在博客文章 Building effective Agents 中引入的命名方式，以表示一个受预定代码路径约束的受控代理系统。

工作流的架构如下所示

代理工作流的高层次概览。图片来自作者。

提取阶段

首先，文档被分割成较小的文本块。块的大小可以根据源文档的信息密度以及知识图谱需要满足的其他下游任务的需求进行调整。例如，如果知识图谱后来用于图RAG应用的上下文检索，块的大小应为此任务优化。事实上，这些块将与提取的关系链接，以便后续检索。

每个块通过大型语言模型进行处理，以提取以下形式的三元组：

(subject: entity_type, relation, object: entity_type)

实体类型可以由大型语言模型直接选择，但在我的测试中，当模型在提取前被提供需要提取的实体类型时，提取质量会显著提高。这也有助于引导提取过程，仅关注所需的信息。值得注意的是，三元组是定向的：第一个条目是关系的主体，而最后一个条目是关系的宾语，这与英语中常见的主-动-宾结构一致。生成的知识图谱将以有向图的形式包含这一信息。

用于提取器模型的提示如下

你是一名专家助手，负责从文本中自动化创建知识图谱。你将提供一段文本和一些允许的实体类型：你的任务是从提供的文本中提取指定类型实体之间的关系。
指导方针：
- 以三元组形式提供你的输出（实体1:类型1，关系，实体2:类型2）
- 仅提取涉及用户指定类型实体的三元组，不要提取涉及其他类型实体的三元组。
- 不要产生重复的三元组
- 不要提取属性或属性作为实体
- 实体名称应简洁，并包含所有必要的信息以唯一标识实体
- 保持实体名称一致：同一个实体在所有出现的三元组中应有相同的名称
- 仅输出提取的三元组，不要输出其他内容
以下是一些示例：
---
<user>{user_instruction} 金（Au）是一种化学元素，化学符号为Au（源自拉丁语aurum），原子序数为79。纯金是一种明亮的、略带橙黄色、密度大、柔软、可塑性和延展性好的金属。化学上，金是一种过渡金属，属于第11族元素，也是贵金属之一。2023年，世界最大的金生产国是中国，其次是俄罗斯和澳大利亚。
{allowed_types_prompt} 'CHEMICAL', 'COUNTRY'</user>
<assistant>(金:CHEMICAL, 是一种, 化学元素:CHEMICAL), (金:CHEMICAL, 化学符号, Au:CHEMICAL), (金:CHEMICAL, 是一种, 过渡金属:CHEMICAL), (金:CHEMICAL, 是一种, 贵金属:CHEMICAL), (金:CHEMICAL, 用于, 饰品: APPLICATION), (中国:COUNTRY, 最大的生产国, 金:CHEMICAL), (俄罗斯: COUNTRY, 第二大的生产国, 金:CHEMICAL), (澳大利亚: COUNTRY, 第三大的生产国, 金:CHEMICAL) </assistant>
---
<user>{user_instruction} 狮子（Panthera leo）是一种大型猫科动物，属于豹属，原产于非洲和印度。它具有性别二态性；成年雄狮比雌狮大，且有明显的鬃毛。
{allowed_types_prompt} 'ANIMAL', 'LOCATION'</user>
<assistant>(狮子:ANIMAL, 科学名称, Panthera leo:ANIMAL), (狮子:ANIMAL, 属于, 属Panthera:ANIMAL), (狮子:ANIMAL, 原产于, 非洲:LOCATION), (狮子:ANIMAL, 原产于, 印度:LOCATION), (雄狮:ANIMAL, 比, 雌狮:ANIMAL)</assistant>
---

关系三元组在LLM的回答中被列出。一个基于正则表达式的解析器被用来从文本中提取它们。接下来，它们会被验证，以确保符合所需的格式，并且只包含允许的实体类型。格式错误或实体类型不符合允许类型的三元组将被丢弃。

构建阶段

在构建阶段，从提取阶段中提取出的三元组会被评估，并依次整合到知识图谱中。对于每个候选三元组，LLM会决定：

1.是否需要将关系添加到知识图谱中。如果它所传达的信息已经存在，则会将其丢弃；

2. 是否需要修改三元组的内容，包括实体名称和类型，以确保与现有关系保持一致。

为了做出这个决定，LLM会被提供一组与当前正在考察的三元组最相似的已提取三元组。虽然长上下文模型可能能够将整个知识图谱保留在其上下文中，但仅提供最相似的关系可以使得LLM的任务更简单，同时也能降低成本。

为了简化，我在代码实现中使用了三元组文本的神经嵌入之间的相似性来进行检索。这并不是工作流程的一部分，可以根据所研究问题的最合适的检索方法进行替换。更具体地说，考虑图结构的检索技术很可能会产生更好的结果，尤其是在密集图或存在大量高度节点的情况下。然而，这超出了本教程的范围。

用于添加三元组并构建知识图谱的提示如下

你是一个专家助手，帮助通过新信息扩展知识图谱。你将给定一个三元组（主体:类型，关系，对象:类型），你需要检查该三元组所传达的信息是否已经在图谱中存在。为此，你将获得一组已存在于知识图谱中的类似关系。
指南：
- 如果三元组所传达的信息已经在图谱中明确存在，则丢弃该三元组
- 如果实体不是允许的类型之一，则丢弃该三元组。请注意，所提出的三元组中的类型可能有错误
- 保持图谱的一致性：如果新关系中提到的实体已经在图谱中存在，则三元组应修改以匹配现有实体的名称和类型。如果三元组所传达的信息已经在图谱中存在，则将三元组添加到图谱中，或{discard_triplet_value}。在给出答案前请分享非常简短的思考。
使用以下格式回答：
"""
{thought_start} 你的解释在这里 {thought_end}
{add_key} (主体:类型，关系，对象:类型)
"""
不要在三元组之后写任何其他内容。以下是一些示例：
---
相似提取的关系：
(Maria Salomea Skłodowska-Curie:person, known as, Marie Curie:person)
(Marie Curie:person, nationality, Polish:nationality)
(Marie Curie: person, spouse, Pierre Curie:person)
允许的实体类型：'person', 'nationality'
提出的三元组：(Marie Curie:person, full name, Maria Salomea Skłodowska-Curie:person)
{thought_start} 图谱中已存在该信息作为(Maria Salomea Skłodowska-Curie:person, known as, Marie Curie:person)，因此该三元组不应被添加。{thought_end}
{add_key} {discard_triplet_value}
---
相似提取的关系：
(Marie Curie:person, discovered, polonium:chemical)
(Marie Curie:person, award, Nobel Prize in Chemistry:prize)
(Marie Curie:person, award, Nobel Prize in Physics:prize)
允许的实体类型：'person', 'chemical', 'prize'
提出的三元组：(Maria Salomea Skłodowska-Curie: person, discovery, radium:chemical)
{thought_start} 该关系不在图谱中，应添加到图谱中。主体“Maria Salomea Skłodowska-Curie”已在图谱中作为“Marie Curie”存在，类型为'person'，我将相应地修改三元组。{thought_end}
{add_key} (Marie Curie:person, discovered, radium:chemical)

最后，知识图谱中包含的每条关系都链接到其提取自的原始段落。这对于进一步应用（如GraphRAG）非常有用，这些应用可以从语义搜索与图搜索的结合中受益，或者可以从上下文中的原始文本中受益。

示例

在本节中，我将使用本文中描述的工作流来展示一些示例。所有示例均使用 gemini-2.0-flash 作为LLM引擎生成，因为它具有良好的理解能力、长上下文支持以及丰富的免费试用计划。我尝试了多种“小型”开源模型，这些模型可以在免费的Colab笔记本上运行，但结果并不令人满意，执行时间成为瓶颈。

这些示例的源文本是通过 wikipedia Python包获取的维基百科页面摘要。知识图的可视化表示是使用 networkx 包创建的。

工作流识别了关键的跨公司联系。此外，我们可以看到知识图谱在整合文档中未直接出现的实体之间的间接关系方面的有效性。使用 networkx，我们可以轻松地从知识图谱的连通组件中提取任意两个实体之间的最短 无向 路径。例如，包含 Mike Krieger 的节点与代表 Mark Zuckerberg 的节点之间的关系如下：

('mike krieger', 'launched', 'instagram'),
 ('facebook', 'acquired', 'instagram'),
 ('mark zuckerberg', 'created', 'facebook')

示例 2

让我们通过从一些著名吉卜力电影的维基百科页面摘要中提取的关系来可视化另一个示例：《如何移动的城堡》（电影）、《男孩与仙鹤》和《幽灵公主》。

从维基百科页面“Howl’s Moving Castle (film)”、“The Boy and the Heron”和“Spirited Away”的摘要中提取的知识图谱，提取的实体类型为：‘人物’、‘电影’和‘公司’。

再次可以看到，主要实体如何相互关联，以及知识图谱中如何出现间接关系。

示例3

另一个有趣的例子是考虑不同疾病之间共同的症状集。这可能有用，例如，可以获取所有具有相同症状集的疾病列表。

以下知识图谱是从维基百科页面“Chest pain”（胸痛）和“Shortness of breath”（呼吸困难）的摘要中创建的。

从维基百科页面“Chest pain”和“Shortness of breath”提取的知识图谱。图片由作者提供。

结论

在本文中，我展示了如何创建一个知识图谱提取器，该提取器能够在从多个来源提取实体时保持一致性。该方法由一个代理工作流组成，分为两个阶段：第一阶段用于提取关系，第二阶段用于将这些关系整合到现有的知识图谱中。在将关系整合到知识图谱之前增加一个额外的验证步骤，可以提高一致性，并减少不同文档/段落之间的格式提取冲突。

与所有基于大语言模型的工作流一样，该方法受到底层模型的能力和限制的制约。例如，幻觉可能导致在知识图谱中包含虚构的关系，或者模型可能无法正确识别两个名称不同但指代同一实体的节点，导致实体重复未被纠正。

另一个固有于所提出工作流结构的限制是，无法修改已整合到知识图谱中的三元组。这可能在知识图谱规模扩大时，对信息整合和优化变得尤为重要。解决这个问题的一个可能方法是通过扩展工作流添加一个修订机制，使其在构建阶段能够修改现有的三元组。

需要考虑的一个因素是，与单步知识图谱提取器相比，该工作流的成本会增加。事实上，在构建阶段需要在将新提取的关系添加到图中之前对其进行评估，这会显著增加计算量和API调用次数。因此，评估质量的相对提升是否值得相应的成本增加就变得非常重要。然而，总成本仍然只是人工标注的一小部分。

作为下游应用的最终考虑因素，值得强调的是，所讨论的工作流程将知识图谱中的关系链接到它们最初从其中提取的原始文档或段落。这对于诸如GraphRAG这样的受益于扩展上下文的应用程序非常有用，同时也使人工评估和修正变得更加容易。事实上，自动化提取技术的全部力量，如本文中讨论的技术，在与人工监督结合时会得到充分发挥：LLM可以承担分析大量文本信息的重担，而人工监督者则可以确保事实的准确性，并优化提取结果。

随着大型语言模型在性能上的持续提升和成本的不断降低，自动化知识图谱的创建将变得越来越普遍，从而从大量非结构化文本数据中释放出更多的价值。