来源：https://arxiv.org/abs/2403.11996
我们本应从“为什么需要图谱”开始。不过在我之前的文章中已经简要讨论过这一点。如果你需要复习，可以回去阅读那篇文章。这里我们只简单回顾与当前主题相关的关键概念。
如果你已经对知识图谱很熟悉，可以跳过这一节。
下面这张图很好地总结了知识图谱的核心思想：
来源：https://arxiv.org/abs/2403.11996
要创建一个知识图谱（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）任务。
我在上一篇文章后收到了很多反馈，其中指出了一些在用 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 库在之前方法的基础上改进，处于严格性与易用性之间，在结构化与非结构化之间。在上文列出的大多数挑战中，它的表现都显著优于我之前提出的方法。
与之前方法不同的是：
•旧方法让 LLM自由发现本体；•Graph Maker 则试图强制 LLM 遵循用户定义的本体。
我们可以通过一条简单的 pip 命令安装：
pipinstallknowledge-graph-maker
这些步骤都已封装在作者分享的 notebook 中。
该库要求的本体格式如下，本质上是一个 Pydantic 模型：
ontology=Ontology(#需要抽取的实体标签，可以是字符串或对象labels=[{"Person":"不带形容词的人名。注意：人可能用名字或代词引用"},{"Object":"对象名称中不要加'the'这样的定冠词"},{"Event":"涉及多人的事件。不要包含限定词或动词，如gives,leaves,works等"},"Place","Document","Organisation","Action",{"Miscellaneous":"无法归类到以上标签的重要概念"},],#应用中重要的关系#这些更像是对LLM的提示，引导其关注特定关系#并不能保证只抽取这些关系，但一些模型总体表现不错relationships=["RelationbetweenanypairofEntities",],)我们可以使用任意大的语料来构建知识图谱，但LLM 的上下文窗口是有限的。因此需要将文本切分成合适大小的块，每个块单独生成子图。
块的大小取决于模型的上下文窗口。
•本项目中使用的提示词大约消耗500 个 token；•剩余的上下文空间可以分配给输入文本和输出图谱。•在我的经验中，200 到 500 token 的小块能够生成更详细的知识图谱。
Document 是一个pydantic 模型，其 Schema 如下：
classDocument(BaseModel):text:strmetadata:dict
我们在 Document 中添加的 metadata 会被附加到该文档中抽取出的每一条关系上。
例如，可以将 页码、章节、文章名称 等上下文信息加入 metadata。 在实践中，节点对之间往往会在多个文档中出现多种关系，metadata 能够帮助为这些关系提供上下文。
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 字符串为多个边，并尽可能修复结果。
我们可以将结果保存到 Neo4j，用于：
•构建 RAG 应用；•运行网络算法；•或直接用 Neo4jBloom[1]可视化图谱。
示例代码：
from knowledge_graph_makerimportNeo4jGraphModelcreate_indices=Falseneo4j_graph=Neo4jGraphModel(edges=graph, create_indices=create_indices)neo4j_graph.save()
在之前的文章中，我们使用networkx和pyvis库对图谱进行了可视化。
这一次，由于我们已经将图谱保存到了Neo4j，因此可以直接借助Bloom来进行可视化。
为了避免重复，我们来生成一种不同的可视化方式。
假设我们想看看角色之间的关系在整本书中的演变过程。
我们可以通过跟踪图谱在遍历书籍过程中逐步添加的边来实现这一点。
为此，Edge 模型中有一个order属性，可以为图谱引入时间或顺序维度。
在本例中，Graph Maker 会自动将文档块在文档列表中出现的顺序号，添加到从该块中抽取的每一条边上。
因此，如果想要观察角色关系的演变，只需要根据边的order来对图谱做切片即可。
下面是这些切片的一个动画演示：
这种知识图谱（KG）最好的应用场景可能就是RAG（检索增强生成）。 Medium 上已经有大量文章介绍了如何在 RAG 应用中引入图谱。
图谱的优势在于，它提供了多种不同的知识检索方式。
•具体采用哪种方式取决于图谱的设计和应用的需求；•在很多情况下，它们比单纯的语义搜索更强大。
最基本的做法是：
•将嵌入向量添加到节点和关系中；•然后在向量索引上运行语义搜索进行检索。
但我认为，图谱在 RAG 中的真正威力体现在：
•将 Cypher 查询、网络算法与语义搜索结合使用。
这是 GitHub 仓库地址，请随意尝试：
GitHub - rahulnyk/graph_maker[2]
我在仓库中附带了一个Python 示例 notebook，可以帮助你快速上手。
⚠️ 注意：在开始使用前，你需要在
.env文件中添加自己的GROQ 凭证[3]。
| 欢迎光临 链载Ai (https://www.lianzai.com/) | Powered by Discuz! X3.5 |