知识图谱的构建，始终离不开两大核心要素：知识库与本体论。知识库可以是文本语料库、代码库或任何文章集合；而本体论，则规定了我们需要关注的实体类别及其关系类型。这里的定义虽有所简化，但已足够实用。
构建知识图谱，本质上就是基于这两者，从非结构化数据中提取结构化信息。传统方法虽然严谨，但实施门槛往往较高。能否让大语言模型（LLM）来简化这一过程，甚至让它自主“发现”最适合当前文本的本体？这正是我们接下来要探讨的方向。
根据该示意图，一个简单的本体可以这样定义：实体包括“人”和“地点”，关系则有“认识”、“居住于”、“访问”等。基于此本体，任何提及人物和地点的文本都能转化为知识图谱。但若面对临床研究文献，本体就必须围绕“化合物”、“用法”、“效果”、“反应”等概念来构建。
在之前的文章中，我们探讨了如何让LLM在没有预定义本体的条件下自行提取知识图谱。这种方法虽缺乏传统方法的严谨性，但其优势在于能更轻松地处理非结构化数据，生成的知识图谱虽然也相对“非结构化”，但信息更丰富、构建更便捷，非常适合用于图检索增强生成（GRAG）等应用。
为何需要Graph Maker？
首先来看看在LLM驱动知识图谱构建时，会遇到哪些典型挑战。以《指环王》的百科摘要为例，这能帮助我们更直观地理解问题所在。
有意义的实体
在自由模式下，LLM提取的实体类别可能过于发散。例如，它会将“比尔博·巴金斯庆祝他的生日”这个动作本身标记为实体，这远不如将其中的“生日”识别为“事件”来得有用。
一致的实体
同一个实体在不同上下文中可能被错误地标记为不同对象。例如，“索伦”、“黑暗领主索伦”和“黑暗领主”很可能被提取为三个独立实体，而它们本应是同一个。如果非得以不同实体出现，那么至少需要用等价关系将它们连接起来。
解析中的弹性
LLM的输出本质上是不可预测的。为了处理大型文档，需要将语料库分割成小文本块，再为每个块生成子图。这就要求LLM必须严格遵循给定模式，为每个子图输出格式正确的JSON。哪怕缺失一个子图，都可能影响整个图的连通性。尽管LLM在生成结构化JSON方面进步显著，但远非完美，尤其对于上下文窗口有限的模型，生成不完整响应的情况时有发生。
实体的分类
LLM在识别实体时仍会犯错，尤其是在特定领域或实体名称非标准的情况下。传统的命名实体识别（NER）模型在这方面表现更好，但它们受限于训练数据，且无法理解实体间的语义关系。在提示工程中，引导LLM与特定类别保持一致，本身就是一门艺术。
隐含关系
关系可能被明确提及，也可能由上下文暗示。例如，“比尔博·巴金斯庆祝他的生日并将戒指留给弗罗多”这句话，就隐含了“比尔博 → 所有者 → 戒指”、“比尔博 → 继承人 → 弗罗多”、“弗罗多 → 所有者 → 戒指”这三层关系。可以预见，LLM未来将超越任何传统的关系提取方法，但就目前而言，这仍然是一个需要精巧提示工程来应对的挑战。
Graph Maker：一个务实的解决方案
本文介绍的Graph Maker库，正是在严谨与简便之间找到了一个平衡点。与之前让LLM自由发现本体的方法不同，Graph Maker会引导LLM使用用户定义的本体，从而在应对上述挑战时表现得更为出色。
安装非常简单：
pip install knowledge-graph-maker接下来，通过五个步骤即可完成整个流程。
1. 定义你的图的本体
该库能够理解以下本体模式。在后台，本体本质上是一个Pydantic模型。
ontology = Ontology(
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, lea ves, works etc."},
"Place",
"Document",
"Organisation",
"Action",
{"Miscellaneous": "Any important concept can not be categorised with any other given label"},
],
relationships=[
"Relation between any pair of Entities",
],
)提示已调整，以生成与给定本体一致的结果。效果相当不错，但依然无法保证100%的准确率，具体取决于所选模型、应用场景、本体质量以及数据本身。
2. 将文本分割成块
我们可以使用任意大小的文本语料库来构建知识图谱。由于LLM的上下文窗口有限，必须将文本适当分割，然后逐个片段地构建图谱。片段大小取决于模型的上下文窗口，本项目中的提示大约消耗500个token，剩余的上下文可分配给输入文本和输出图谱。经验表明，200到500个token的较小片段，能生成更详细的图谱。
3. 将这些块转换为文档
文档是一个Pydantic模型，其结构如下：
class Document(BaseModel):
text: str
metadata: dict添加到文档中的元数据，会被标记到从该文档中提取出的每一条关系上。我们可以将页面号、章节、文章名称等上下文信息放入元数据，这样有助于将不同文档中同一节点对之间的关系具体化。
4. 运行图生成器
图生成器直接接收一个文档列表，并逐个迭代处理每个文档以创建子图，最终输出所有文档的完整图。
from knowledge_graph_maker import GraphMaker, Ontology, GroqClient
model = "mixtral-8x7b-32768"
llm = 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))图构建器将每个文档通过LLM处理，并解析响应以创建完整的图。最终输出是一个边列表，每条边都是一个Pydantic模型：
class Node(BaseModel):
label: str
name: str
class Edge(BaseModel):
node_1: Node
node_2: Node
relationship: str
metadata: dict = {}
order: Union[int, None] = None提示已调整，生成的JSON相当一致。如果JSON响应无法解析，图制作器还会尝试手动将JSON字符串分割成多条边字符串，尽可能挽回损失。
5. 保存到Neo4j
我们可以将模型保存到Neo4j，用于创建RAG应用、运行网络算法，或者使用Bloom进行可视化。
from knowledge_graph_maker import Neo4jGraphModel
neo4j_graph = Neo4jGraphModel(edges=graph, create_indices=False)
neo4j_graph.sa ve()图上的每条边都会作为一个事务保存到数据库中。如果是首次运行，请将`create_indices`设置为`true`，这会在节点上设置唯一性约束，为数据库做好准备。
为了不再重复之前的内容，这里展示一个不同的可视化效果。例如，我们可以观察书中人物之间的关系是如何逐步演变的。图构建器会自动为每条边添加一个`order`属性，该属性记录了该边在文档列表中的出现顺序。因此，只要按边的顺序截取图，就能看到人物关系的演变过程了。
图与RAG
知识图谱在RAG（检索增强生成）应用中潜力巨大。图提供了多种多样的检索方式，其中一些技术可能比简单的语义搜索更强大。在基础层面，我们可以为节点和关系添加嵌入向量，然后对向量索引进行语义搜索来检索信息。但图在RAG应用中的真正力量，在于将Cypher查询和网络算法与语义搜索相结合。这方面还有不少值得探索的空间。
代码仓库
完整的代码和示例笔记本已上传至GitHub仓库，欢迎尝试。需要注意的是，在开始之前，请确保在`.env`文件中添加了你的GROQ凭据。