支持私有化部署
AI知识库

53AI知识库

学习大模型的前沿技术与行业应用场景


Graph Maker轻松创建知识图谱

发布日期:2025-07-27 07:14:25 浏览次数: 1550
作者:知识图谱工坊

微信搜一搜,关注“知识图谱工坊”

推荐语

开源工具Graph Maker让知识图谱构建更简单,结合LLM智能发现本体,轻松处理非结构化数据。

核心内容:
1. 知识图谱构建的两大要素:知识库与本体论
2. LLM自动发现本体的创新方法及优势
3. 实际应用案例与当前技术挑战分析

杨芳贤
53AI创始人/腾讯云(TVP)最具价值专家

一个开源库,用于从文本语料库构建知识图谱,使用像Llama 3和Mixtral这样的开源大型语言模型。

这里有一个示意图,它简洁地总结了知识图谱的概念。

要创建一个知识图谱,我们需要两个信息。

  1. 知识库这可以是文本语料库、代码库、文章集合等。
  2. 本体论:我们关心的实体的类别以及它们关系的类型。我在这里可能过于简化了本体论的定义,但它适用于我们的目的。

这是一个简单的本体。

实体:人,地点
关系:
人与 → 人
人居住于 → 地点
人访问 → 地点

根据这两条信息,我们可以从提到人物和地点的文本中构建一个知识图谱。然而,假设我们的知识库是关于处方药物及其相互作用的临床研究。我们可能会使用不同的本体,其中化合物、用法、效果、反应等可能构成我们的本体。

在上一篇文章中,我们讨论了如何使用LLM提取知识图谱,而不需要为其提供本体。这个想法是让LLM自己发现最适合给定文本语料库的本体。

尽管这种方法缺乏生成知识图谱的传统方法的严谨性,但它有其优点。它可以比传统方法更容易地用非结构化数据生成KG。它生成的KG在某种意义上也是非结构化的。然而,它们更容易构建并且信息更丰富。它们非常适合于图检索增强生成(GRAG)之类的应用。

为什么选择图形制作工具?

让我列出我在上一篇文章的反馈中收到的一些挑战和观察。这将帮助我们理解在创建具有大型语言模型的知识图谱时面临的挑战。让我们以《指环王》书籍的百科摘要为例。毕竟,人们不可能不爱《指环王》!

有意义实体

在自由运行的情况下,大型语言模型提取的实体类别可能过于多样化。它可能会错误地将抽象概念标记为实体。例如在文本“比尔博·巴金斯庆祝他的生日并将戒指留给弗罗多”中,大型语言模型可能会提取“比尔博·巴金斯庆祝他的生日”或“庆祝他的生日”作为‘动作’。但如果它能提取“生日”作为‘事件’,可能会更有用。

一致性实体

它也可能错误地在不同上下文中标记相同的实体。例如:

“索伦”、“黑暗领主索伦”和“黑暗领主”不应被提取为不同的实体。或者如果它们被提取为不同的实体,它们应该用一个等价关系连接起来。

解析中的弹性

大型语言模型的输出本质上是不可预测的。为了从大型文档中提取知识图谱,我们必须将语料库分割成较小的文本块,然后为每个块生成子图。为了构建一个一致的图,大型语言模型必须根据给定的模式一致地为每个子图输出JSON对象。即使缺少一个也可能对整个图的连通性产生不利影响。

尽管大型语言模型在响应格式良好的JSON对象方面取得了很大进步,但它们仍然远非完美。具有有限上下文窗口的LLMs也可能生成不完整的响应。

实体的分类

大型语言模型在识别实体时可能会犯很多错误。当上下文特定于某个领域,或者实体没有用标准英语命名时,这个问题就更大了。命名实体识别模型在这方面做得更好,但它们也仅限于训练数据。此外,它们无法理解实体之间的关系。

在提示工程中,强迫一个大型语言模型与类别保持一致是一门艺术。

隐含关系

关系可以明确提及,也可以由上下文暗示。例如:

“比尔博·巴金斯庆祝他的生日并将戒指留给弗罗多”暗示了以下关系: 1. 比尔博·巴金斯→所有者→戒指 2. 比尔博·巴金斯→继承人→弗罗多 3. 弗罗多→所有者→戒指

我认为在某个时刻,大型语言模型(LLMs)将比任何传统的关系提取方法都要好。但就目前而言,这是一个需要巧妙的提示工程挑战

图表制作器

我在这里分享的图表制作库改进了之前的方法,它在严谨和简便之间走了一半的路——在结构和缺乏结构之间走了一半的路。它在我讨论过的上述大多数挑战上都表现得比之前的方法要好得多。

与之前的方法相反,在之前的方法中,LLM可以自由地发现本体,而图构建器试图强迫LLM使用用户定义的本体。

我们可以用简单的pip命令安装知识图谱制作库

pip install knowledge-graph-maker

下面是如何用5个简单的步骤来操作的。

这些步骤被编码在一个笔记本里,我将在本文的结尾分享。

1. 定义你的图的本体

图书馆理解以下本体模式。在幕后,本体是一个pydantic模型

ontology = Ontology(# labels of the entities to be extracted. Can be a string or an object, like the following.labels=[{"Person""Person name without any adjectives, Remember a person may be referenced by their name or using a pronoun"},{"Object""Do not add the definite article 'the' in the object name"},{"Event""Event event involving multiple people. Do not include qualifiers or verbs like gives, leaves, works etc."},"Place","Document","Organisation","Action",{"Miscellaneous""Any important concept can not be categorised with any other given label"},],# Relationships that are important for your application.# These are more like instructions for the LLM to nudge it to focus on specific relationships.# There is no guarantee that only these relationships will be extracted, but some models do a good job overall at sticking to these relations.relationships=["Relation between any pair of Entities",],)

我已经调整了提示以产生与给定本体一致的结果。我认为它做得相当好。然而,它仍然不是100%准确的。准确性取决于我们选择生成图表的模型、应用程序、本体和数据的质量。

2. 将文本分割成块。

我们可以使用尽可能大的文本语料库来创建大型知识图谱。然而,目前大型语言模型(LLMs)的上下文窗口是有限的。因此,我们需要适当地分割文本,一次一个片段地创建图谱。我们应该使用的片段大小取决于模型的上下文窗口。本项目中的提示大约消耗了500个标记。其余的上下文可以分为输入文本和输出图谱。根据我的经验,较小的200到500个标记的片段可以生成更详细的图谱。

3. 将这些块转换为文档。

该文档是一个具有以下模式的Pythonic模型。

## Pydantic document modelclass Document(BaseModel):text: strmetadata: dict

我们在这里添加到文档中的元数据被标记到从文档中提取出的每个关系上。

我们可以将关系的上下文信息添加到元数据中,例如页面号、章节、文章名称等。通常情况下,每个节点对会在多个文档中有多个关系。元数据有助于将这些关系具体化。

4. 运行图表制作器。

图生成器直接取一个文档列表,并迭代每个文档以创建一个子图。最终输出是所有文档的完整图。

这里有一个简单的例子说明如何做到这一点。

from knowledge_graph_maker import GraphMaker, Ontology, GroqClient
## -> Select a groq supported modelmodel = "mixtral-8x7b-32768"# model ="llama3–8b-8192"# model = "llama3–70b-8192"# model="gemma-7b-it" ## This is probably the fastest of all models, though a tad inaccurate.
## -> Initiate the Groq Client.llm = GroqClient(model=model, temperature=0.1, top_p=0.5)graph_maker = GraphMaker(ontology=ontology, llm_client=llm, verbose=False)
## -> Create a graph out of a list of Documents.graph = graph_maker.from_documents(docs)## result: a list of Edges.
print("Total number of Edges", len(graph))## 1503

图构建器将每个文档通过LLM处理并解析响应以创建完整的图。最终图形是一个边列表,其中每条边都是一个类似于以下的pydantic模型。

class Node(BaseModel):label: strname: str
class Edge(BaseModel):node_1: Nodenode_2: Noderelationship: strmetadata: dict = {}order: Union[intNone] = None

我已经调整了提示语,现在它们生成的JSON相当一致。如果JSON响应无法解析,图制作器还会尝试手动将JSON字符串分割成多条边字符串,然后尝试挽救尽可能多的内容。

5. 保存到Neo4j

我们可以将模型保存到Neo4j中,以创建RAG应用程序、运行网络算法,或者可能只是使用Bloom可视化图表。

from knowledge_graph_maker import Neo4jGraphModelcreate_indices = Falseneo4j_graph = Neo4jGraphModel(edges=graph, create_indices=create_indices)neo4j_graph.save()

图的每条边都保存到数据库中作为一个事务。如果你这是第一次运行此代码,请将`create_indices`设置为true。这通过在节点上设置唯一性约束来准备数据库。

5.1 仅为了好玩,如果在之前的文章中我们没有使用 networkx 和 pyvis 库来可视化图表,那么在这里,因为我们已经将图表保存到了 Neo4J 中,我们可以直接利用 Bloom 来可视化图表。

为了避免重复我们之前文章中的内容,让我们生成一个不同的可视化效果。

比如说我们喜欢看书中人物之间的关系是如何发展的。

我们可以通过跟踪在图制作者遍历书籍时边缘是如何逐步添加到图中来做到这一点。为了实现这一点,边缘模型有一个名为“顺序”的属性。这个属性可以用来给图添加时间或时间顺序维度。

在我们的例子中,图构建器自动将特定文本块在文档列表中出现的顺序号添加到它从中提取的每条边上。因此,要查看字符之间的关系如何演变,我们只需按边的顺序横截该图即可。

这里有一个这些横截面的动画。


图表和RAG

这种知识图谱的最佳应用可能是用于推荐系统(RAG)

本质上,图提供了多种不同的方式来检索知识。根据我们如何设计图和我们的应用程序,这些技术中的一些可能比简单的语义搜索更有力。

在基础层面上,我们可以在节点和关系中添加嵌入向量,并对向量索引进行语义搜索以检索信息。然而,我认为图在RAG应用中的真正力量在于我们将Cypher查询和网络算法与语义搜索相结合时。

我自己也在探索这些技术。我希望能在下篇文章里写一写它们。

法典

这里是GitHub仓库。请随意尝试。我还包括在仓库中一个示例Python笔记本,可以帮助您快速上手。

请注意,在开始之前,您需要在 .env 文件中添加您的 GROQ 凭据。

如果你觉得你可以对这个开源项目做出贡献,请去做吧,并让它成为你自己的。

我希望你能发现这个图表制作器有用。感谢阅读。

53AI,企业落地大模型首选服务商

产品:场景落地咨询+大模型应用平台+行业解决方案

承诺:免费POC验证,效果达标后再合作。零风险落地应用大模型,已交付160+中大型企业

联系我们

售前咨询
186 6662 7370
预约演示
185 8882 0121

微信扫码

添加专属顾问

回到顶部

加载中...

扫码咨询