ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 14px;letter-spacing: 0.1em;color: rgb(63, 63, 63);">在我之前的文章中，我探讨了如何利用基于智能体（Agent）的方法来模块化文档到知识图谱（KG）的构建流程。我们可以将这种方法进一步拓展，不仅利用大型语言模型（LLMs）进行信息抽取，还能让它们参与到本体（Ontology）的设计中。
ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 14px;letter-spacing: 0.1em;color: rgb(63, 63, 63);">这开启了构建一个真正端到端框架的可能性：LLMs 辅助定义本体，然后直接从文本中提取信息并构建知识图谱。但同时我也意识到，构建一个有效的本体并非易事，它不仅取决于领域的复杂性，还与知识图谱的使用目的（例如推荐、问答、探索等）紧密相关。
ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 14px;letter-spacing: 0.1em;color: rgb(63, 63, 63);">因此，我没有赋予系统完全自主权，而是引入了一种
ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 14px;letter-spacing: 0.1em;color: rgb(63, 63, 63);">我也注意到，使用知识图谱进行问答（QA）比传统 RAG 方法更复杂，也更具挑战性。在本文中，我将介绍如何在统一的智能体驱动框架内实现 GraphRAG，并通过集成路由机制动态选择最佳策略。通过将基于智能体（Agent-based）的设计与路由相结合，我们可以为每个问题动态选择最适合的策略。
ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 14px;letter-spacing: 0.1em;color: rgb(63, 63, 63);">总而言之，本文主要包含两大部分：ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 14px;color: rgb(63, 63, 63);" class="list-paddingleft-1">• 数据集 本次，我将使用 CORD-19(https://github.com/allenai/cord19?tab=readme-ov-file) 数据集，这是一个关于 COVID-19 及相关冠状病毒研究的学术论文语料库，用于构建知识图谱。由于资源限制，我随机抽取了 1,000 篇论文，并提取了它们的摘要，将每篇摘要保存为一个独立的.txt文件。希望尽管数据量有限，我们仍能从中发现有价值的信息。
第一部分：用于从文本构建知识图谱的人工参与的多智能体系统 1. 探讨与概念澄清 在深入探讨系统设计之前，我想先澄清几个关键概念。我研究了 Neo4j，他们将知识图谱分为两种类型：文档结构图（Document Structure Graphs） 和领域图（Domain Graphs） 。
我在之前的文章中所做的是这两种类型的结合。实际上，这样做是可行的 ，并且适用于大多数情况。而选择哪种类型，很大程度上取决于知识图谱的具体用途。领域图虽然缺乏上下文信息，但它非常擅长解决聚合（Aggregation）查询。聚合查询就像是把分散在不同地方（文档段落）的关于同一个主题（例如药物 B 的症状）的信息汇集到一起。例如：针对 药物 B 的症状，有多篇 研究资源进行了探讨。通过使用领域图，我们可以聚合这些信息，并通过一个名为药物 B 的共同实体将那些分散的段落关联起来。所以当用户询问：药物 B 有什么症状？我们可以通过类似这样的查询来获取答案：
MATCH(a)-[:HAS_SYMPTOM]->(b)WHEREa.name="drugB"RETURNb 这也解决了 RAG 的一个局限性：RAG 通常需要截取 top-k 个相关段落，但有时我们需要的信息不止于此。使用图查询，我们则不需要使用“top-k”参数。然而，为了提供完整且有依据的答案，我们仍然需要将子图查询结果追溯到其原始文本段落，并将这些段落输入 LLMs。这时，文档结构图便能发挥作用。
接下来，我们进一步探讨实体间的**关系（Relationship）**类型，我将其分为两类：
• 开放关系（Open Relationship）：这类关系没有预设的约束，关系类型也不是预先定义好的，通常以自然语言的形式表达。 • 封闭关系（Closed Relationship）：这类关系则从一个固定的、预定义好的类型集合中选取。 选择哪种关系类型取决于下游任务。封闭关系适用于许多机器学习问题，如链接预测、推荐、探索等。而当实体间的关系过于复杂、灵活甚至未知，无法用一个预定义的关系列表来表达时，则会使用开放关系。
2. 实践方法 在本次工作中，我将继续结合 领域图和文档结构图，并采用封闭关系类型。
具体来说，我们将涵盖医学（Medical）领域，重点关注药物（DRUG）、疾病（DISEASE）、症状（SYMPTOM）这三类实体以及治疗（TREATS）、引起（CAUSES）、有副作用（HAS_SIDE_EFFECT）、有症状（HAS_SYMPTOM）这些关系。我们还将介绍如何确保提取出的知识图谱满足本体的约束条件 ，例如，HAS_SIDE_EFFECT关系仅存在于药物（DRUG）和症状（SYMPTOM）实体之间，从而使知识图谱更加可靠。
这次我选择了文档解析方法（适合处理短文档），而不是分块方法，来生成文档结构图。我相信将分块选项添加到框架中是可行的，但本文中不做展示。
回顾上一篇文章，我已经在models/schema.py中定义了本体模式（Ontology Schema）。现在我们无需再手动定义它们了。
fromtypingimportList,Literal,Optional,Type,Any, get_args, get_origin,Union下面是我们的新工作流程图：
我们设计了一个包含三个主要智能体 以及若干辅助工具的系统，用于协助构建本体和模式：
本体初始化智能体（Ontology Initialization Agent）
该智能体负责分析数据，以确定领域知识 ，包括相关的实体类型 和关系类型 。它利用了两个关键的辅助工具：
•数据检索工具（Retrieve data） ：由于无法将所有数据都输入 LLMs，智能体将使用此工具随机选取样本进行分析。 •搜索工具（Search Tool） ：一旦初步确定了领域知识，智能体可以使用此工具在线搜索该领域的常见实体和关系，以辅助最终决策。 重要的是，该智能体还支持人工反馈（Human Feedback） ，允许用户改进或调整本体，使其更好地符合他们的具体目标。这是“人在环路”的关键环节。
模式设计智能体（Schema Design Agent）
该智能体读取原始数据和前一个智能体生成的本体，以设计一个符合文档结构的模式（Schema） 。例如，如果输入文档是学术论文，模式可能包含诸如title（标题）、authors（作者）、publication date（发表日期）、sections（章节）、figures（图表）和tables（表格）等属性。与本体智能体类似，该智能体也支持交互式反馈（Interactive Feedback） ，允许用户根据需要修改模式。这一步的输出是一个伪代码定义（Pseudo Code Definition） ，它概述了本体和文档结构。
模式生成智能体（Schema Generation Agent）
该智能体接收上一步生成的伪代码，并将其转换为JSON 模式（JSON Schema） 。然后可以使用此模式通过Pydantic 等库生成模型。这一步是自动化生成代码模式的关键。
实际上，步骤 2 和步骤 3 可以合并为一步，但我发现当代码生成智能体收到关于模式模型定义的更清晰输入时，其性能会更好。
人工参与（Human-in-the-loop）示例：
首先，我们定义ontology_init_agent（本体初始化智能体）。以下代码片段展示了智能体的基本结构，包括名称、使用的模型、输出类型、指令以及可用的工具。
# agents/ontology_init_agent.py所以流程是一个循环：智能体生成本体 -> 将本体展示给用户 -> 征求用户确认。只有当用户同意设计时，循环才会终止。你可以简单地要求用户输入“agree”来中断循环，但这里我将使用一个“人工偏好智能体（Human Preference Agent）”来将用户意图解析成结构化对象，从而使对话更自然。以下是用于表示人工评审结果的 Pydantic 模型：
frompydanticimportBaseModel, Field只有当is_agreed为True时，循环才会终止。
（可选）你可以使用一个“接口智能体（Interface Agent）”来与非技术用户沟通，用自然语言解释本体。以下代码展示了本体初始化节点的主要逻辑，包括与用户交互和调用智能体：
# nodes/ontology_init_node.py我们对模式设计节点（Schema Design Node）采用同样的方式，该节点负责设计并生成 JSON 模式。这是一个输出示例：
{为了确保当 LLMs 未能正确生成 JSON 时流程不会中断，我们可以添加一些后处理/验证和重新生成的循环。例如，为模式生成智能体添加一个输出验证器：
importre根据我的经验，使用单次提示（One Shot Prompting），qwen2.5 coder 或gpt4o-mini 通常能在第一次尝试时就生成正确的结果。以下代码展示了模式设计节点如何使用这些智能体并集成人工反馈：
# nodes/schema_design_node.py这就是模式设计（Schema Design）部分。
现在我们进入信息抽取（Information Extraction）阶段，这部分与上一篇文章中的做法非常相似。但由于我们没有预定义的 Mention 模型，数据模型只能在运行时（runtime）定义。因此，与其在智能体中显式定义输出模型，我们可以通过Type[BaseModel]对其进行抽象，并将output_type作为函数的参数传递。以下是用于提及检测智能体的定义：
fromtypingimportList,Type,Any类似地，我们创建relation_extraction_agent（关系抽取智能体）。我也使用了output_validation来确保抽取出的关系符合本体的约束。这是为确保知识图谱质量设置的“质量控制关卡”。
# agent/relation_extraction_agent.py信息抽取节点（Information Extraction Node）中的逻辑流程如下。它协调文档蒸馏、提及检测和关系抽取这三个步骤：
importasyncio这就是信息抽取（Information Extraction）的全部过程。
3. 集成 Neo4j 将提取出的三元组集成到 Neo4j 时，我们需要注意的另一点是创建节点和节点间关系有两种方式：CREATE（创建）或MERGE（合并）节点。CREATE模式会创建两个独立的节点，即使它们指向的是同一个概念；而MERGE模式则会在表面形式相同时仅保留一个节点，但这要求你确保它们确实指向的是同一个实体。
在实践中，在医学等某些领域存在许多歧义，一个术语可能指代不同的概念。我们需要一个链接（Linking）步骤，在一个词汇表/参考集中识别某个提及的唯一标识符。我们将在后续的文章中更深入地探讨这个话题。目前，我将使用MERGE方法来在提及之间构建桥接关系。
以下是一个将三元组导入 Neo4j 的示例代码片段。请注意，您需要根据实际的文件结构和三元组格式加载数据。
fromneo4jimportGraphDatabase, basic_auth结果展示
我原本期望能提取到更多药物副作用的信息，但目前看来，语料库中关于副作用的提及较少。未来可以通过扩展数据集或优化模型来改善这一情况。
总结 在本文中，我展示了如何将“人工参与（Human-in-the-loop）”设计集成到用于知识图谱构建的多智能体系统中，并以 CORD-19 数据集为例进行了案例研究。通过结合领域图 和文档结构图 ，并借助封闭关系（Closed Relationship）强制执行本体约束 ，我们可以构建出更准确、结构化的知识图谱表示。
iteral["LOCATION","TIME","PERSON","EVENT","ORGANIZATION"]
ict[str,List[Dict[str,str]]]) -> Agent: