LIU HAO / notes
← 回到知识图谱
文章持续完善

从零构建教学知识图谱：论文方法与实践经验

本文总结从原始课程标准和教材出发，结合六份论文与指南，走过需求、材料整理、Schema、抽取、实体对齐、证据审校和增量更新，整理一套可以逐步验收的构建方法。

创建 2026-11-02更新 2026-11-02阅读约 22 分钟
Agent知识图谱本体论信息抽取实体对齐数据治理

此前的整理更接近“系统已经有什么功能”，但从零构建图谱要回答另一组问题：手里只有课程标准、教材和题目时，第一步做什么？节点怎样产生？哪些边能从原文抽出来，哪些边需要另外判断？最后又怎么知道图谱没有做偏？

我带着这些问题查阅了本体开发、知识图谱构建、关系抽取和实体对齐方面的文献。读下来最重要的一点是：目录里的包含关系、文本中的明确陈述、跨材料的语义对应，是三类任务，不能用同一种抽取方法包办。

本文给出的路线是：

先确定要回答的问题，保留材料来源，定义一小套对象和关系，再分路生成候选，完成身份对齐与证据核对，用查询验收，最后逐步扩充。

本文是文献支持的构建方案，不是对参考系统开发历史的还原。此前只读检查能确认它有课程主题、章、节、学习点等对象，以及审校、投影和追溯相关入口；不能据此知道原始数据由谁、用哪个模型、按什么流程生产。下文的材料、编号、提示词和数字均为教学示意；实施建议不代表已经在该系统完成。

这篇在 Agent 体系里的位置

这篇属于 Agent 体系总览 的“知识与记忆”部分，讲的是 知识图谱 如何准备可用的领域知识。它与 RAG 配合，但不是 Agent Loop，也不代替文档证据。

要区分建库和使用：建库时做材料整理、Schema、抽取、对齐和审校；任务执行时由受控的只读工具查询相应范围与版本，返回关系路径和来源，再取原文进入上下文。实际请求怎样交接，见 报销案例；从检索到建图再到执行的动手安排，见 实践路线。这是接入与实验建议，本站没有在线业务图谱服务。

从零构建的建议路线：问题、材料、Schema、候选、对齐、审校、查询与迭代；并非参考系统的实际开发记录从零构建的建议路线：问题、材料、Schema、候选、对齐、审校、查询与迭代；并非参考系统的实际开发记录 · 点击放大

1. 先写问题，别先列几十种节点

Noy 与 McGuinness 的本体开发指南建议先确定领域、用途、使用者，以及系统应当能够回答的问题。这些问题被称为 Competency Questions，也可以作为后续检查本体是否够用的标准（Noy & McGuinness, 2001，§3）。

放到教学场景，我会先写出三个问题：

  1. 某节教材对应哪些课程要求，依据分别在哪？
  2. 某个知识概念在不同章节或材料中出现在哪里？
  3. 某条课程要求修改后，哪些已有对应关系需要复核？

这一步的产物不应只是“支持智能教学”这样的目标，要落到一张能验收的表上：

要回答的问题 必须准备什么 什么样的输出才算完成
小节对应哪些要求 小节、要求、对应关系、双侧依据 返回要求及对应理由，能定位两份材料
概念出现在哪里 概念身份、材料中的出现记录 区分同一个概念与多个不同章节
修改影响什么 来源版本、关系引用与修订记录 找到受影响对象，标出需要重审的连接

我的第一轮范围会刻意做小：一版课程标准、一本教材的一个单元，题目可以后续加入。这是试点建议，不是论文规定的规模。

Hogan 等人的综述也讨论了从初始核心逐步丰富图谱，以及将需求问题转成查询测试的做法（Hogan et al., 2021，公开扩展稿 §6、§6.5.1）。先把一小块从头到尾做通、能核对，比一开始就覆盖所有学科更容易看出模型缺了什么。

2. 整理材料时，就把出处留下来

接下来才是读 PDF、表格或已有 JSON。我的建议是保留两层材料：

  • 原始层：原文件、来源、版本、页码与文件校验值。
  • 处理层：清洗后的文本、段落、标题、表格及其回到原始材料的定位信息。

这两层不能只剩一份“干净文本”。否则 OCR 改错了一个术语，或者切片丢了标题，后面很难查出问题来自哪里。

一个片段记录至少应该能说明：

source_id       这份材料是谁
source_version  用的是哪一版
block_id        当前片段编号
locator         原文件页码、章节或表格位置
text            实际送入处理流程的内容

这是我的工程记录模板，不是某篇论文规定的协议。如果字符位置来自 OCR 或规范化文本，要说明它定位的是哪个副本，不能假装它就是原 PDF 的字符位置。

教材和标准里还有大量结构信息。章号、节号、表头、合并单元格、学段说明都不能在转文本时随手丢掉。Hogan 等人的综述分别讨论了文本预处理、表格结构识别，以及结构化和半结构化材料的映射（Hogan et al., 2021，扩展稿 §6.2–6.4）。

例如，表格某列标题写着“第二学段”，单元格里写着“比较两种表示方式”。如果只抽出后一句，就丢掉了这条要求的适用范围。

这一阶段的验收：随机选一个处理后的片段，能够找回原文件、版本与位置；表格记录能够解释其表头和层级。做不到这些，先别急着抽三元组。

3. Schema 做小，但对象边界要讲清

Schema 是实体类型、关系类型和约束的约定。第一版不必复杂，但要能解释为什么两段相似文字是同一个对象，或者不是。

一个试点模型可以区分：

对象 在示意模型中表示什么
主题 课程内容的组织范围
标准条目 某版课程标准中的一项具体要求
章、节 某本教材中的具体位置
学习点 这一位置要求理解或完成的细分内容
知识概念 可以在不同材料中重复出现的概念

最容易混淆的是“知识概念”和“教材里的出现位置”。两本教材都讲“电流与电压”，可以关联到同一个概念，但它们仍然是两本书里的两个小节。不能为了去重，把小节合成一个节点。

参考系统中能看到主题层次与教材层次，通过跨结构关系连接。这个观察可以帮助我们理解建模目标，但不等于它完整采用了上表的概念与出现记录划分。

主题层次与教材层次通过语义映射连接，节点文字为教学示意主题层次与教材层次通过语义映射连接，节点文字为教学示意 · 点击放大

关系也先少一些，下面只是试点 Schema 的示意命名：

章       --包含--> 节
节       --包含--> 学习点
学习点   --围绕--> 知识概念
节       --对应--> 标准条目

“节属于章”不表示“节是章的一种”。Noy 与 McGuinness 区分了类的继承关系与其他属性关系：只有某类的每个实例同时也是另一类的实例，才应当考虑子类关系（2001，§4.1）。把 part-of 写成 is-a，后面的推理和查询都会被误导。

必须先固定 Schema 吗？

不一定。AutoSchemaKG 展示了另一种路线：先抽取实体、事件和关系，再通过概念归纳形成 Schema。它也有类型结构，只是结构在抽取之后才形成（Bai et al., 2026，方法部分）。

不过，它也讨论了专业领域概念组织、模型偏差以及图谱矛盾和缺口等限制。不能把开放语料上的结果直接当成中文教材效果。

我的选择是：课程标准和教材已有较明确的组织方式，先固定一小套核心类型；暂时无法归类的候选进入待扩展队列。之后根据真实材料修订 Schema，不在第一天就把所有概念设计完。这是结合领域特点的建议，不是“Schema-first 一定优于 Schema induction”的实验结论。

这一阶段的验收：拿几个真实片段试标，类型能解释对象差别，关系能读成清楚的陈述；分不清的地方先改定义。

4. 节点和边要分三条生产线

这一步才真正开始生产图谱数据。

生产线 示例 我会采用的方法
文档结构 某章包含某节 目录、编号和表格解析
原文明示关系 文段明确陈述某对象与另一对象的关系 受 Schema 约束的文本抽取
跨材料语义对应 某节教材对应某条课程要求 候选召回、双侧材料比较和领域审校

第一条：结构能直接读取，就别让模型重新猜

已有目录编号、表格主键或 JSON 字段时，我会优先做映射。例如根据“章号、节号、教材版本”建立章与节，再生成包含关系。

Hogan 等人讨论了从结构化材料映射图谱的方法，也指出机械地把 JSON/XML 转成一串 child 边，只是在复刻文档结构（2021，扩展稿 §6.4）。因此解析之后，还要把字段映射到有领域含义的对象，而不是把每个标签都变成知识概念。

第二条：原文抽取先产生候选

REBEL 将关系抽取做成序列生成：输入文本，输出线性化三元组，再还原实体端点和关系。但其端点采用文本中的实体表面形式，抽到名字并不等于已经完成跨文档身份对齐（Huguet Cabot & Navigli, 2021，§3）。

这篇论文里还有一个判断我觉得要记住：知识库里存在某条关系，而且两端实体都出现在文本中，不代表这段文本表达了该关系。作者为银标数据使用了文本蕴含相关过滤，同时承认仍有噪声（§3.2）。

所以抽取结果我会先放进候选区，不直接当成正式知识。

ChatIE 提供了一个不用先训练专用模型的参考：先从预设类型列表中识别本段出现的类型，再按模板抽取具体槽位；类型缺失时允许返回 NONE（Wei et al., 2023，§2，实际阅读 v2）。零样本并不是让模型随意创造关系名。

下面是我为工程试点设计的提示约定，不是 ChatIE 原论文模板：

输入：当前片段、必要的标题上下文、允许的实体和关系类型。
输出：实体提及、候选关系，以及支持它们的原文片段。
只依据所给材料，不用常识补充未出现的关系。
不满足类型约定或证据不足时，返回空结果或待核验原因。
原文摘录必须来自输入；不要在此阶段分配最终实体身份。

附出处与定位信息是我增加的工程措施；允许空结果则与 ChatIE 的 NONE 约定一致。多轮抽取也会传播前一步错误，且有调用成本，不能因为流程拆成几轮，就默认比一次结构化输出更准确。

第三条：跨材料对应不能冒充原文抽取

课程要求通常不会直接写“我对应某教材第几节”，这条边没法从同一句话里抽出来。

我会先用标题、关键词、别名或向量检索找候选，再把两侧内容放在一起检查：讨论对象是否一致，要求的行为是否一致，深度与学段是否匹配。

例如两份示意材料都提到“电流与电压”，但标准要求“依据实验数据解释关系”，教材却只介绍仪表读数。关键词重合，并不足以支持“这节教材覆盖了该要求”。

这类边要标明属于跨材料对应判断，保存双侧依据，并说明对应程度或不足。关系抽取论文的成绩不能直接用来证明这类教学映射已经解决。

这一阶段的验收：每条候选能说明来自哪条生产线。明确抽取、规则映射与语义判断不要混在一起。

5. 实体对齐：相似、同名、同一对象是三回事

现在可能得到很多“电流与电压”的提及。哪些应该合并？

我会把“提及记录”和“规范实体”分开：先保留文本里出现了什么，再决定它指向哪个稳定编号。

判断时至少考虑：

  • 名称与别名是否一致。
  • 定义、类型和上下文是否一致。
  • 教材、年级、学段与版本是否影响对象边界。
  • 两个记录是同一个概念，还是分别讨论这个概念的两个位置。

Sun 等人的实体对齐基准研究讨论了名称、语言和模式差异，以及稀疏、长尾实体的困难；所比较的嵌入方法也没有普遍优于传统方法（Sun et al., 2020，§6.3、§7）。这并不说明规则总是更好，只说明不能预设向量方法一定胜出。

因此，向量相似度适合帮助召回候选，不应独自决定合并。试点可以先用别名和规则建立基线，再用人工标注的样本比较不同方法；歧义项保留为待确认，不强行合并。

还要分清两个任务：

  • 实体对齐：两条记录是不是指向同一个对象？
  • 语义映射：两个不同对象之间是否存在“对应”“围绕”等关系？

把教材小节与课程要求合并成一个节点，显然不能叫作“对齐成功”。Sun 等人的研究以图谱间同一对象的对齐为主要设置，也不能直接证明多对多教学映射有效。

这一阶段的验收：同物多名能归到一起，同名异物能够分开；误合并可以回退；改标题不需要重建所有引用。

6. 证据、校验和审校要在入库前设计好

对象身份确定之后，候选关系才能引用稳定编号。对于跨材料对应，我会保存类似下面的记录：

{
  "candidate_id": "edge-demo-01",
  "source": "urn:demo:section:01",
  "target": "urn:demo:standard:01",
  "relation": "maps_to",
  "basis_kind": "cross_document_alignment",
  "review_status": "pending",
  "evidence": [
    {
      "source_id": "textbook-demo",
      "source_version": "示意版",
      "locator": "示意第 1 单元",
      "quote": "通过测量和表格分析研究电流与电压的关系"
    },
    {
      "source_id": "standard-demo",
      "source_version": "示意版",
      "locator": "示意要求 01",
      "quote": "依据实验数据说明电流与电压的关系"
    }
  ],
  "reason": "两侧都要求基于实验数据分析关系，仍需核对深度和学段"
}

这份记录是建议的候选格式，不是参考系统的接口响应，也不是可以直接上传的既有协议。

接着分别过两种检查：

结构检查：编号是否存在，类型是否允许这样连接，方向是否正确，同一条关系是否重复，原文摘录是否真的出现在指定材料中。

语义审校：摘录是否支持这条关系，是否漏掉限制条件，是完整对应还是部分对应，推断强度是否超过材料。

字段齐全只证明记录完整，摘录存在只证明引用没有凭空编造，两者都不能代替语义判断。Hogan 等人将语法、语义、完整性等质量维度分开讨论（2021，扩展稿 §7）；证据优先 和 人在回路 也应当落在这一步。

怎么评测，而不只是看看图漂不漂亮？

我会在试点阶段做一份人工核对的参考集，包含容易判断的关系，也包含同名异义、少见概念、只有关键词相同但不对应的负例。

至少分开记录：实体边界错误、类型错误、身份对齐错误、关系与方向错误、无依据关系、漏抽。ChatIE 的误差分析区分了类型、边界、漏识别和多识别，说明只看一个总分很难定位问题（Wei et al., 2023，§7）。

手算一个示意例子：在同一材料与版本范围内，人工参考集已经核对完整，包含 15 条应当识别的关系。按规范端点、关系类型和方向一对一匹配，系统产生 20 条去重后的候选，其中 12 条正确。

  • 精确率是 12 / 20 = 60%：产出的候选里有多少正确。
  • 召回率是 12 / 15 = 80%：该识别的关系找回了多少。

提高召回可能让审校队列更长；只保留最容易的关系，又可能漏掉重要知识。这需要按实际用途权衡，不能用“节点增加了多少”替代 质量评测。

参考集只评估所选材料与标注范围，不等于覆盖了全学科。模型评审可以辅助筛查，但不能包装成人工金标准；也不能将论文 benchmark 的成绩写成当前系统的准确率。

这一阶段的验收：错误有分类、有样例、有对应修复手段，不能只拿到一个好看的平均分。

7. 入库之后，先用最初的问题验收

到这里，才决定用什么保存数据，以及怎么提供查询。

小规模试点可以先保存实体表、关系表、来源记录和审核记录，用 JSON 或关系型存储先把流程跑通。如果真实查询需要频繁多跳遍历，再比较图数据库方案。这个选型是我的建议，不是某种技术天然更可靠。

无论用哪种存储，我都会保留三条边界：

  1. 候选数据与正式可用数据分开。
  2. 审核结论绑定它实际检查过的内容版本。
  3. 发布版本、查询索引和可视化结果能说明彼此是否一致。

参考系统提供实体与关系数据包格式、审校状态和投影接口，页面还会提示数据修改后尚未同步到可视化。这些是能观察到的管理入口，不能证明它已完整执行上面的发布门槛。Neo4j 导入接口也不足以说明整个系统以 Neo4j 为主存储。

验收则回到第一步：

给定小节 ID：
查正式版本中的“对应”关系；
返回标准条目、双侧来源和审校记录；
找不到就明确返回缺口，不靠模型补一个答案。

再检查“概念出现在哪里”“来源修改影响什么”。这些查询应进入回归检查，后续改 Schema、模型或解析规则，都重新跑一遍。

查询通过后，再用画布辅助阅读。坐标、分层、颜色与直线连边可以让关系更易读，但不应生成新的语义关系，也不应改变已有身份。图谱能展示一条路径，只说明当前数据与查询规则找到了连接，不证明某道题具备测量效果，更不证明学生掌握了某项能力。

这一阶段的验收：具体问题能够返回有依据的结果；数据缺口与读取范围能够明确说明。

8. 图谱会反复修改，增量流程要早一点准备

如果每次换一版教材都全量重跑，旧编号、旧审核与新抽取结果很容易混在一起。每次生成结果时，我会记录来源、Schema、解析规则、提示词或模型的版本，以便判断变化来自哪里。我的增量方案是：

  1. 比较来源版本和文件校验值，也检查 Schema、规则、提示词或模型版本变化，确定需要重处理的范围。
  2. 定位受影响片段、实体出现记录和依赖关系。
  3. 对受影响范围重解析或重抽取，保留未变部分。
  4. 核对新旧身份；内容变化时复核旧审核是否仍适用。
  5. 生成新版本，重跑查询与评测，再更新读取结果。

这是工程综合建议，不是本次已经验证的参考系统流程。保留来源链路，也是为了让这种影响分析做得出来。

图谱缺口同样会反过来改 Schema。不能归类的关系，可能是抽错了，也可能是现有关系定义太窄。先看样例，再决定扩类型、补规则，还是只保留原文不建边。

如果让我重新做第一轮，我会按产物验收，而不承诺几天内全自动完成：

批次 核心产物 暂时不追求什么
确定试点 问题清单、材料清单、最小 Schema 全学科本体
跑通生成 来源片段、结构映射、抽取及对应候选 所有候选直接入库
做好质量 对齐规则、证据记录、审校队列、参考集 用模型评分替代领域核对
跑通全程 可查询版本、回归检查、变更与回退记录 用节点数量证明完成度

经验可以归纳成六句话：

  • 从问题确定边界，从真实片段修订 Schema。
  • 能读取的结构先映射，文本陈述再抽取。
  • 跨材料对应单独判断，不冒充原文中的明示关系。
  • 相似度用于找候选，同一身份需要额外核对。
  • 证据、审校、版本和错误样例是构建流程的一部分。
  • 先让一组问题可重复地答对，再扩大数据范围。

这套顺序也适用于未来的 研究 Agent：论文提及的概念、实验对象、主张与证据不能只靠同名合并，模型生成的连接先当候选。检索 帮助找到材料，知识图谱负责显式记录对象与连接，两者都不能代替来源核验。

参考文献与实际阅读范围

以下六份来源分别用于方法归纳，不是教学效果证明。正文中的提示词、字段模板、试点规模和流程门槛是工程建议，未归给某一篇论文。

  1. Noy, N. F., & McGuinness, D. L. (2001). Ontology Development 101: A guide to creating your first ontology. Stanford Knowledge Systems Laboratory。官方指南 PDF。技术报告；重点读 §3、§4.1、粒度及逆关系讨论，用于需求问题、对象边界与约束设计。
  2. Hogan, A., et al. (2021). Knowledge graphs. ACM Computing Surveys, 54(4), Article 71。DOI；公开扩展稿 v6。重点读扩展稿 §6–7 的构建与质量部分；本文章节编号指扩展稿，不是 ACM 37 页版。
  3. Huguet Cabot, P.-L., & Navigli, R. (2021). REBEL: Relation Extraction By End-to-end Language generation. Findings of EMNLP 2021, 2370–2381。官方论文及 PDF。重点读 §3–4，用于生成式抽取、表面形式、文本支持与评测边界。
  4. Wei, X., et al. (2023). ChatIE: Zero-Shot Information Extraction via Chatting with ChatGPT. arXiv:2302.10205。论文记录；实际阅读的 v2 全文。按预印本引用；v2 更新于 2024-05-27，重点读 §2、§3、§7 的方法、实验设置与误差分析。
  5. Sun, Z., Zhang, Q., Hu, W., Wang, C., Chen, M., Akrami, F., & Li, C. (2020). A benchmarking study of embedding-based entity alignment for knowledge graphs. Proceedings of the VLDB Endowment, 13, 2326–2340。DOI；官方 PDF。重点读 §1–2、§6.3、§7，用于实体对齐设置、基线比较与长尾困难。
  6. Bai, J., et al. (2026). AutoSchemaKG: Autonomous Knowledge Graph Construction through Dynamic Schema Induction from Web-Scale Corpora. ACL 2026, 20557–20584。正式论文及 PDF。重点读方法、评测与限制部分；交叉阅读预印本 v3。用于抽取后归纳 Schema 的路线对比，不将论文数值转用为中文教学材料效果。

检索方法与局限

检索日期为 2026-11-02。按“本体开发、文本关系抽取、Schema 归纳、实体对齐、图谱质量”做定向检索，再通过 Stanford、ACL Anthology、arXiv、PVLDB 官方材料与 Crossref 元数据核对标题、作者、年份和版本。检索词包括 Ontology Development 101、knowledge graph construction information extraction、ChatIE Zero-Shot Information Extraction、AutoSchemaKG schema induction、embedding-based entity alignment benchmarking。

优先选能读到方法或限制正文的论文及指南，不以搜索摘要代替全文。部分搜索引擎结果无关、Semantic Scholar 接口限流，未作为不存在文献的证据，改用官方来源核对。这是定向文献整理，不是穷尽式系统综述。

通用抽取与对齐研究不能直接证明中文教学材料的适用性；跨材料教学对应、抽取质量、更新成本与真实使用效果都需要本地数据和领域审核者验证。本文未读取新的内部材料，未将内部文档上传给外部模型服务，也未执行写入、审校或发布。

本文使用 Codex AI 助手协助检索、来源核对、整理和写作，尚待作者独立复核。对未获授权的内部资料，应先解决使用权限、隐私和外发边界，再选择解析或模型服务。

这是一篇可以继续生长的笔记。沿着关系继续阅读 ↗