一个开源库，可基于文本语料构建知识图谱，支持使用 Llama 3、Mixtral 等开源大模型。
在这篇文章中，我将分享一个 Python 库 —— Graph Maker。 它可以根据指定的本体，从文本语料中构建知识图谱（KG）。Graph Maker 使用的开源大模型包括 Llama3、Mistral、Mixtral 或 Gemma 来完成 KG 的抽取。
我们将依次介绍以下内容：
•为什么需要 Graph Maker•Graph Maker 能做什么•对上一篇文章的简要回顾•本文方法如何解决之前的挑战
文章最后，我会分享 GitHub 仓库链接。
简要回顾
我们本应从 “为什么需要图谱” 开始。不过在我之前的文章中已经简要讨论过这一点。如果你需要复习，可以回去阅读那篇文章。这里我们只简单回顾与当前主题相关的关键概念。
如果你已经对知识图谱很熟悉，可以跳过这一节。
下面这张图很好地总结了知识图谱的核心思想：
要创建一个知识图谱（KG），我们需要两类信息：
1.知识库（Knowledge Base）•这可以是文本语料、代码库、文章集合等。2.本体（Ontology）•我们关心的实体类别，以及它们之间的关系类型。•（这里的定义可能有点简化，但足够适用。）
例如，一个简单的本体可以这样表示：
•实体（Entities）：Person（人物）、Place（地点）•关系（Relationships）：•Person → related to → Person•Person → lives in → Place•Person → visits → Place
给定这两类信息，就可以从文本中构建一个涉及人物与地点的知识图谱。
如果我们的知识库换成一份关于 处方药及其相互作用的临床研究，那么本体就可能需要包括 化合物（Compounds）、用法（Usage）、作用（Effects）、反应（Reactions） 等类别。
我曾讨论过另一种思路：不事先提供本体，让 LLM 自行从语料中发现合适的本体。
这种方法虽然缺乏传统 KG 生成方法的严谨性，但也有优势：
•更容易处理 非结构化数据；•生成的知识图谱本身也相对“非结构化”；•但构建更轻松，信息更丰富；•特别适合应用于 GRAG（Graph Retrieval Augmented Generation） 任务。
为什么需要 Graph Maker？
我在上一篇文章后收到了很多反馈，其中指出了一些在用 LLM 构建知识图谱时的挑战。这里我们用 《指环王》三部曲的维基百科摘要 来说明这些问题（毕竟谁能不爱《指环王》呢！）。
实体的“意义”问题
在自由提取时，LLM 抽取出的实体类别可能过于多样，甚至把抽象概念错误标注为实体。
例如，在这句话中：
“Bilbo Baggins celebrates his birthday and leaves the Ring to Frodo.”
LLM 可能抽取出：
•“Bilbo Baggins celebrates his birthday” 或•“Celebrates his birthday”
并标记为 Action（动作）。
但更有意义的做法是：
•抽取 “Birthday” 并标记为 Event（事件）。
实体一致性问题
LLM 也可能在不同上下文中，将同一个实体标记为不同的对象。
例如：
•“Sauron”•“the Dark Lord Sauron”•“the Dark Lord”
这些不应被抽取为不同的实体。
即便抽取为不同的实体，也应该通过 等价关系（equivalence relationship） 将它们连接起来。
解析的鲁棒性
LLM 的输出本质上是 非确定性的。为了从一份大型文档中抽取 KG，我们必须将语料拆分成较小的文本块，并为每个块生成子图。要构建一致的图谱，LLM 必须在每个子图的输出中严格遵循给定的 JSON Schema。如果缺少哪怕一个子图的结构化输出，整个图谱的连通性都可能受到影响。
虽然 LLM 在输出格式良好的 JSON 方面正在不断进步，但仍然远未完美。特别是上下文窗口有限的模型，可能生成不完整的结果。
实体的分类
LLM 在识别实体时可能会出现大量错误。这在 领域特定语境 或 非标准英语命名的实体 情况下尤为严重。NER 模型在这方面可能表现更好，但它们也受限于训练数据，并且无法理解实体之间的关系。
要让 LLM 在分类上保持一致性，本质上是一种 提示工程的艺术。
隐含关系
关系可以是 显式提及的，也可以是 隐含在上下文中的。例如：
“Bilbo Baggins celebrates his birthday and leaves the Ring to Frodo.”
这句话隐含了以下关系：
•Bilbo Baggins → Owner → Ring•Bilbo Baggins → Heir → Frodo•Frodo → Owner → Ring
我认为，未来的某个时刻，LLM 在提取关系方面会比任何传统方法都强大。但就目前而言，这仍然是一个需要 巧妙提示设计 来解决的挑战。
Graph Maker
这里介绍的 Graph Maker 库 在之前方法的基础上改进，处于 严格性与易用性之间，在 结构化与非结构化之间。在上文列出的大多数挑战中，它的表现都显著优于我之前提出的方法。
与之前方法不同的是：
•旧方法让 LLM 自由发现本体；•Graph Maker 则试图 强制 LLM 遵循用户定义的本体。
我们可以通过一条简单的 pip 命令安装：
pip install knowledge-graph-maker
Graph Maker 的五步使用流程
这些步骤都已封装在作者分享的 notebook 中。
第1步：定义图谱的本体（Ontology）
该库要求的本体格式如下，本质上是一个 Pydantic 模型：
ontology =Ontology(# 需要抽取的实体标签，可以是字符串或对象 labels=[{"Person":"不带形容词的人名。注意：人可能用名字或代词引用"},{"Object":"对象名称中不要加 'the' 这样的定冠词"},{"Event":"涉及多人的事件。不要包含限定词或动词，如 gives, leaves, works 等"},"Place","Document","Organisation","Action",{"Miscellaneous":"无法归类到以上标签的重要概念"},],# 应用中重要的关系# 这些更像是对 LLM 的提示，引导其关注特定关系# 并不能保证只抽取这些关系，但一些模型总体表现不错 relationships=["Relation between any pair of Entities",],)第2步：将文本切分为块
我们可以使用任意大的语料来构建知识图谱，但 LLM 的上下文窗口是有限的。因此需要将文本切分成合适大小的块，每个块单独生成子图。
块的大小取决于模型的上下文窗口。
•本项目中使用的提示词大约消耗 500 个 token；•剩余的上下文空间可以分配给输入文本和输出图谱。•在我的经验中，200 到 500 token 的小块能够生成更详细的知识图谱。
第3步：将这些块转换为 Document 对象
Document 是一个 pydantic 模型，其 Schema 如下：
classDocument(BaseModel): text: str metadata: dict
我们在 Document 中添加的 metadata 会被附加到该文档中抽取出的每一条关系上。
例如，可以将 页码、章节、文章名称 等上下文信息加入 metadata。 在实践中，节点对之间往往会在多个文档中出现多种关系，metadata 能够帮助为这些关系提供上下文。
第4步：运行 Graph Maker
Graph Maker 接收一个 文档列表，并逐个处理，为每个文档生成一个子图。最终结果是所有子图合并后的完整知识图谱。
简单示例如下：
from knowledge_graph_maker importGraphMaker,Ontology,GroqClient## -> 选择一个 Groq 支持的模型model ="mixtral-8x7b-32768"# model = "llama3–8b-8192"# model = "llama3–70b-8192"# model = "gemma-7b-it" ## 这是最快的模型，但准确率略低## -> 初始化 Groq Clientllm =GroqClient(model=model, temperature=0.1, top_p=0.5)graph_maker =GraphMaker(ontology=ontology, llm_client=llm, verbose=False)## -> 从文档列表生成图谱graph = graph_maker.from_documents(docs)## 结果：一个边的列表print("Total number of Edges", len(graph))## 1503
Graph Maker 会将每个文档传入 LLM，并解析返回结果，最终生成完整的图谱。 输出的图谱以 边（Edges）列表 表示，其中每条边是一个 pydantic 模型：
classNode(BaseModel):label: strname: strclassEdge(BaseModel):node_1:Nodenode_2:Noderelationship: strmetadata: dict ={}order:Union[int,None]=None
我已经调优过提示词，使生成的 JSON 比较一致。如果 JSON 解析失败，Graph Maker 会尝试手动拆分 JSON 字符串为多个边，并尽可能修复结果。
第5步：保存到 Neo4j
我们可以将结果保存到 Neo4j，用于：
•构建 RAG 应用；•运行网络算法；•或直接用 Neo4j Bloom[1] 可视化图谱。
示例代码：
from knowledge_graph_maker importNeo4jGraphModelcreate_indices =Falseneo4j_graph =Neo4jGraphModel(edges=graph, create_indices=create_indices)neo4j_graph.save()
5.1 可视化（哪怕只是为了好玩）
在之前的文章中，我们使用 networkx 和 pyvis 库对图谱进行了可视化。
这一次，由于我们已经将图谱保存到了 Neo4j，因此可以直接借助 Bloom 来进行可视化。
为了避免重复，我们来生成一种不同的可视化方式。
假设我们想看看角色之间的关系在整本书中的演变过程。
我们可以通过跟踪 图谱在遍历书籍过程中逐步添加的边 来实现这一点。
为此，Edge 模型中有一个 order 属性，可以为图谱引入时间或顺序维度。
在本例中，Graph Maker 会自动将文档块在文档列表中出现的顺序号，添加到从该块中抽取的每一条边上。
因此，如果想要观察角色关系的演变，只需要根据边的 order 来对图谱做切片即可。
下面是这些切片的一个动画演示：
图谱与 RAG
这种知识图谱（KG）最好的应用场景可能就是 RAG（检索增强生成）。 Medium 上已经有大量文章介绍了如何在 RAG 应用中引入图谱。
图谱的优势在于，它提供了多种不同的知识检索方式。
•具体采用哪种方式取决于图谱的设计和应用的需求；•在很多情况下，它们比单纯的语义搜索更强大。
最基本的做法是：
•将 嵌入向量 添加到节点和关系中；•然后在向量索引上运行语义搜索进行检索。
但我认为，图谱在 RAG 中的真正威力体现在：
•将 Cypher 查询、网络算法与语义搜索结合使用。
代码
这是 GitHub 仓库地址，请随意尝试：
GitHub - rahulnyk/graph_maker[2]
我在仓库中附带了一个 Python 示例 notebook，可以帮助你快速上手。
⚠️ 注意：在开始使用前，你需要在
.env文件中添加自己的 GROQ 凭证[3]。
