知识图谱（Knowledge Graph）能够将零散的文本转化为结构化的关系网络，显著提升 AI 对信息的理解能力。Graph Maker 是一款开源 Python 库，支持 Llama3、Mixtral、Gemma 等主流大模型，帮助用户从文本语料中自动构建知识图谱。本文将通过循序渐进的方式，带你掌握 Graph Maker 的核心功能、操作步骤，并解答实际应用中的常见问题。
一、知识图谱的核心概念
在动手实践之前，先回顾两个关键要素：
- 知识库（Knowledge Base）：你的文本语料库，例如文章、代码库、维基百科摘要等。
- 本体（Ontology）：你关注的实体类型（如人物、地点）以及它们之间的关系类型（如“居住在”“访问了”）。
举例来说，一个简单的本体可以这样定义：
- 实体：Person（人物）、Place（地点）
- 关系：
- Person → related_to → Person
- Person → lives_in → Place
- Person → visits → Place
有了本体和文本，你就能构建出关于人物和地点的知识图谱。如果换成医学文本，本体可能需要包含“化合物”“用法”“反应”等类别。
小提示：如果你已经熟悉知识图谱，可以直接跳到下一节。
二、为什么需要 Graph Maker？—— 旧方法遇到的 5 大挑战
过去直接让大模型（LLM）自由提取实体和关系，虽然灵活，但会带来很多问题。我们用《指环王》的维基百科片段来说明：
1. 实体“意义”混乱
例如句子 “Bilbo Baggins celebrates his birthday and leaves the Ring to Frodo.” 中，LLM 可能提取出 “Celebrates his birthday” 并标记为 “Action”，但更合理的做法是提取 “Birthday” 并标记为 “Event”。
2. 实体一致性差
同一实体可能被不同方式命名：“Sauron”“the Dark Lord Sauron”“the Dark Lord” 本应合并，但 LLM 常把它们当作不同实体，也没有通过等价关系连接。
3. 输出解析不稳定
LLM 输出是非确定性的，常会生成格式不正确的 JSON，导致子图缺失，影响全图连通性。
4. 分类不准确
在特定领域或非标准英语命名中，LLM 容易误判实体类别。即使使用 NER 模型，也受限于训练数据且无法理解关系。
5. 隐含关系挖掘不足
句子 “Bilbo Baggins ... leaves the Ring to Frodo.” 隐含了 “Bilbo → Owner → Ring”“Bilbo → Heir → Frodo”“Frodo → Owner → Ring” 等多层关系，LLM 往往只提取表面关系。
三、Graph Maker 巧妙解决上述挑战
Graph Maker 在“严格性”和“易用性”之间找到了平衡。与旧方法不同，它 强制 LLM 遵循用户定义的本体，而不是让 LLM 自由发现本体，从而大幅提升提取质量。
安装
pip install knowledge-graph-maker
四、五步实现知识图谱构建
第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 有上下文窗口限制，需要把长文本拆分成小块。建议每块 200~500 token，这样能生成更详细的知识图谱。
- 提示词本身消耗约 500 token，剩余空间留给输入文本和输出。
第3步：将文本块转换为 Document 对象
Document 是一个 Pydantic 模型，格式如下：
class Document(BaseModel):
text: str
metadata: dict
可以在 metadata 中添加页码、章节等上下文信息，这些信息会被附加到从该文档中提取的每一条关系上。
第4步：运行 Graph Maker
初始化 LLM 客户端并生成图谱：
from knowledge_graph_maker import GraphMaker, Ontology, GroqClient
## -> 选择一个 Groq 支持的模型
model = "mixtral-8x7b-32768"
# model = "llama3-8b-8192"
# model = "llama3-70b-8192"
# model = "gemma-7b-it" ## 最快但准确率略低
## -> 初始化 Groq Client
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))
## 1503输出图谱是一个边（Edge）列表，每条边是一个 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] = NoneGraph Maker 会自动修复解析失败的 JSON，通过手动拆分字符串来尽可能保留有效边。
第5步：保存到 Neo4j
保存后可用于 RAG、网络算法或使用 Neo4j Bloom 可视化：
from knowledge_graph_maker import Neo4jGraphModel
create_indices = False
neo4j_graph = Neo4jGraphModel(edges=graph, create_indices=create_indices)
neo4j_graph.save()5.1 可视化小技巧
如果想观察角色关系随故事发展的变化，可以利用 Edge 中的 order 属性（自动添加的文档块顺序号）来切片图谱。下面是一个动态演示示例：
（图片占位，原图为动画演示）
五、知识图谱 + RAG：更强大的检索方式
图谱在 RAG（检索增强生成）中的最大优势是提供多种检索路径：
- 将 嵌入向量 添加到节点和关系上，运行语义搜索。
- 或者结合 Cypher 查询、网络算法 和语义搜索，获得比纯向量检索更精准的结果。
六、GitHub 资源与快速上手
GitHub 仓库：rahulnyk/graph_maker
仓库内附有一个完整的 Python 示例 notebook，帮你快速跑通整个流程。
⚠️ 注意：使用前需要在 .env 文件中添加你自己的 GROQ 凭证。
七、常见问题（FAQ）
Q1：Graph Maker 支持哪些大模型？
目前内置支持 Llama3、Mistral、Mixtral、Gemma，通过 GroqClient 调用。你也可以扩展其他 LLM 客户端。
Q2：文本块大小如何选择？
建议每个文本块 200~500 token。太大会超出模型上下文窗口，导致输出不完整；太小可能丢失语义关联。
Q3：如果 LLM 输出 JSON 解析失败怎么办？
Graph Maker 会自动尝试手动拆分 JSON 字符串，将有效部分保留为边。但你也可以考虑适当增加模型温度或使用更稳定的模型（如 Mixtral）。
Q4：如何将图谱用于 RAG？
保存到 Neo4j 后，你可以同时建立向量索引（如使用 LangChain 的 Neo4jVector），然后结合 Cypher 查询进行混合检索。
Q5：本体必须定义得很精确吗？
不一定。定义越精确，提取质量越高。但如果你不确定，可以先给出宽泛的提示（如“Relation between any pair of Entities”），模型会尝试学习。
八、小提示汇总
- 先从小语料开始测试本体定义是否合理。
- 使用
verbose=True参数可以查看每步的 LLM 输出，方便调试。 - 将 metadata 中添加文档来源（如章节编号），后续分析时能追溯上下文。
- 如果图谱边数过多（超过数千条），建议使用 Neo4j 桌面版或 AuraDB 进行可视化。
掌握了 Graph Maker，你就能像搭积木一样，把零散文本变成机器可读的知识网络。快去试试吧！