文本如何变成知识图谱：两条方法路线与三个开源项目

文本转知识图谱的关键指南：两条方法路线+三个开源项目，覆盖从抽取到治理的完整链路。
核心内容：
1. 知识图谱构建的核心挑战与价值
2. 两条文本建图方法路线解析
3. 三个开源项目功能与应用

知识工程手记2026.08

文本如何变成知识图谱

两条方法路线，三个开源项目，一条从抽取到治理的完整链路

抽取只是起点，可信、可检索、可维护才是终点

Graph RAGOntology

把一篇文章变成一张图并不难，难的是让这张图在下一次检索、问答和建模时仍然可信。

很多知识库仍然停留在“切块、向量化、召回、生成”这条直线上。它适合回答与原文表述相近的问题，却不一定能处理跨段落关系、实体别名、事件顺序和知识缺口。

这组材料从五个维度将问题串联起来：两篇方法类文章探讨了如何从文本中抽取概念和关系；rahulnyk/knowledge_graph提供了一个能够在本地运行的轻量级实现；nashsu/llm_wiki将一次性抽取推进至持续维护的个人知识库；microsoft/Ontology-Playground则把本体设计、可视化以及学习打造成了一个静态的Web工作台。

把它们放到一起，会看到一条清楚的演进路线：

01

PART

为什么要把文本变成图

TEXT TO KNOWLEDGE GRAPH

知识图谱可以先用一个简单模型理解：节点代表实体、事件或概念，边代表它们之间的关系。与只保存段落向量相比，图结构额外记录了“谁和谁有关、通过什么关系有关、关系出现在哪里”。

这会改变检索方式。

• 从相似度走向路径
  ：问题不一定与答案段落使用相同词语，但可能能沿着人物、事件、地点或概念之间的路径找到答案。

• 从局部片段走向跨段落连接
  ：多个段落分别提到同一个对象时，图可以把这些线索聚合起来。

• 从回答问题走向发现问题
  ：节点度数、社区结构、孤立节点和桥接节点，都可以帮助我们发现知识集中在哪里、断在哪里。

• 从单一检索器走向混合检索
  ：图查询、图算法、向量相似度和原文证据可以共同决定送给模型的上下文。

但图谱并不是自动获得的“事实层”。它首先是一套由模型抽取出来的结构化假设，必须保留来源、上下文和人工校验入口。

知识图谱项目横向视觉

02

PART

两种从文本建图的路线

TEXT TO KNOWLEDGE GRAPH

01｜自由发现型：先让模型看见概念之间的关系

第一篇文章采用的是自由发现路线。它不预先规定实体类型和关系枚举，而是让本地大模型阅读文本块，自己找出重要概念及其语义关系。

基本过程如下：

1. 把语料切成多个文本块，并为每块分配 chunk_id。
2. 让 LLM 从每个文本块中抽取概念和语义关系，把这类关系记为权重 W1。
3. 对同一文本块中共同出现的概念增加“上下文邻近关系”，记为权重 W2。
4. 合并同一节点对，累加权重，拼接不同来源的关系描述。
5. 将合并后的节点和边交给 NetworkX 做图分析，再用 Pyvis 生成可交互的可视化结果。

这里有一个很重要的细节：同一对概念之间可能出现多条边。语义关系回答“它们是什么关系”，上下文邻近回答“它们是否经常一起出现”。合并时保留两类证据，图谱才不至于只剩一张漂亮的连线图。

knowledge_graph 方法流程

这条路线的优点是启动快，适合面对没有固定 schema 的文章、论文和资料集。它也比较适合探索阶段：先看图，再决定哪些实体类别和关系值得正式建模。

代价同样明显。模型可能把未明确出现的概念补进来，也可能把同一对象拆成多个名字。上下文邻近关系还容易过重，导致“同段出现”被误读成“存在事实关系”。

02｜本体约束型：先定义要观察什么

第二篇文章把自由度收回来，提出 Graph Maker 路线。用户先定义实体标签和关系类型，模型再按这套本体抽取。

例如，一个人物与地点类知识库可以定义 Person、Place，以及“居住于”“访问”等关系；临床研究则可以换成化合物、用途、效果和反应等领域概念。模型不再完全自由地发明类别，而是被提示集中在应用真正关心的结构上。

Graph Maker 的处理步骤是：

1. 通过 Pydantic 模型定义 Ontology。
2. 将语料切成约 200～500 token 的文本块，具体大小取决于模型上下文窗口和输出复杂度。
3. 把每个文本块封装成带有 text 和 metadata 的 Document。
4. 逐个文档生成子图，再汇总成完整图。
5. 把节点标签、名称、关系、来源 metadata 和顺序信息保存到边模型中。
6. 将结果写入 Neo4j，用 Cypher、图算法、Bloom 或向量检索服务后续查询。

安装和初始化非常直接：

.bash

pip install knowledge-graph-maker

边模型带有 metadata，因此可以记录页码、章节、文章名或其他来源信息；order 字段则可以按文本块顺序观察关系如何逐步出现。这对于书籍、长报告和时间线材料尤其有用。

它还针对工程中最常见的三个问题做了处理：用提示词约束实体类别，尽量减少别名漂移；在 JSON 解析失败时拆分输出并恢复可解析的边；为关系保留上下文，避免最终图谱完全脱离原文。

知识图谱三层架构

不过，本体约束也不是免费午餐。schema 需要领域知识，关系定义得太宽会失去约束，定义得太窄又会漏掉有用信息。更稳妥的做法是先用小样本建立本体，再用真实抽取结果反过来修订标签、关系和别名规则。

03

PART

三个项目分别解决什么问题

TEXT TO KNOWLEDGE GRAPH

1. `rahulnyk/knowledge_graph`：轻量的概念图谱实验场

项目定位很明确：把任意文本转换成知识图谱，用于 Graph Augmented Generation（图增强生成）或基于知识图谱的问答。

它的核心实现集中在 Notebook 和 Python 图处理工具上：

• 用 Mistral 7B OpenOrca 等本地模型从文本块提取概念。
• 用 Ollama 承载本地模型，减少对远程模型 API 的依赖。
• 用 Pandas DataFrame 暂存节点、边、权重和 chunk_id。
• 用 NetworkX 计算节点度数、社区等图指标。
• 用 Pyvis 生成可缩放、可拖拽的 Web 图谱。
• 提供 Docker 启动方式，方便在个人机器上复现实验。

它有一个值得注意的判断：有时“概念”比“实体”更适合作为节点。例如，“Bangalore”是实体，而“Bangalore 的宜人天气”是一个更能表达语义的概念。这个选择会让图谱更丰富，但也提高了归一化和质量控制的要求。

：想理解文本建图原理、快速做本地实验、验证 GRAG 想法的人。

：它更像研究型原型，不负责完整的知识库生命周期。要用于长期生产，还需要补上实体去重、别名归一化、规则校验、增量更新、权限和证据追踪。

2. `nashsu/llm_wiki`：把图谱放进持续维护的知识库

llm_wiki 的重点不是生成一张图，而是建立一个能够不断吸收新资料的 Wiki。它沿用“原始来源、Wiki 内容、Schema 规则”的三层设计，并围绕 Ingest、Query、Lint 三个操作组织工作流。

它最有价值的地方，在于把一次导入拆成了两个阶段：

.text

第一步：LLM 阅读来源，形成结构化分析

提取实体、概念、论点、已有连接、矛盾和结构建议

第二步：LLM 根据分析生成 Wiki 页面

写入摘要、实体页、概念页、索引、日志、交叉链接和待复核事项

这套拆分让“理解来源”和“改写知识库”分开，便于追踪和复核。系统还提供增量缓存、持久化导入队列、失败重试、文件夹导入、来源目录监听和源文件删除后的级联清理。

图谱部分也更接近一个可用的检索层。它把直接链接、共享来源、Adamic-Adar 邻居相似度和页面类型亲和度组合成相关性模型，再用 Louvain 算法发现社区；孤立页面、稀疏社区和跨社区桥接节点会被转成可行动的知识洞察。

进行检索时，项目可以先开展关键词搜索，然后根据实际需求添加向量搜索，接着以种子节点为基础进行图扩展和两跳遍历，同时对上下文预算加以控制。它还提供了本地HTTP API、MCP Server和Agent Skill，以便外部编码Agent或研究Agent能够读取Wiki、搜索来源、遍历图谱并触发重新扫描。

LLM Wiki 架构

LLM Wiki 知识图谱

：需要把论文、网页、PDF、Office 文档和个人笔记积累成长期知识资产的人，也适合希望 Agent 拥有可查询工作记忆的团队。

：系统能力已经很宽，部署和模型配置的复杂度也随之上升。长期质量取决于来源追踪、页面生成、链接维护和人工 Review 是否真的被纳入日常流程。

3. `microsoft/Ontology-Playground`：把本体设计变成可视化工作台

这个项目的重点不在于批量 ingest 文档，而在于让人理解、设计和分享 ontology。它是 React + TypeScript 的静态 Web 应用，使用 Cytoscape.js 渲染图谱，使用 Zustand 管理状态，主要运行时不依赖后端。

它提供了三种不同于“直接让 LLM 抽取”的能力：

• 目录
  ：浏览 Retail、E-Commerce、Healthcare、Finance、Manufacturing、Education 等领域的预置 ontology，并通过深链接分享具体模型。

• 设计器
  ：创建实体类型、属性、关系和基数，实时查看图预览，支持撤销/重做、校验以及 RDF/XML 和 JSON 导出。

• 学习与协作
  ：提供课程、实验、测验、Quest、演示模式，以及通过 GitHub 登录提交 ontology PR 的路径。

它还支持 RDF/XML 往返校验、自然语言查询映射演示、可嵌入的 Ja vaScript Widget、命令面板和快捷键。换句话说，它更适合回答“我们到底要怎样描述这个业务世界”，而不是回答“从一批新文档里自动抽出什么”。

Ontology Playground 交互图谱

：做领域建模、知识图谱培训、Fabric IQ 相关探索、ontology Demo 或需要向团队解释 schema 的人。

：静态站点带来低部署成本，但它本身不是文档摄取、图数据库或生产级检索服务。要接入真实业务，还需要把导出的 ontology 对接数据管道、存储和权限体系。

04

PART

五类能力如何逐层补齐

TEXT TO KNOWLEDGE GRAPH

把五个来源放到同一张架构图里，会发现它们覆盖的是不同层，而不是互相替代的五个产品。

1. 抽取：从“模型自由发挥”到“模型按 schema 工作”

自由发现型方法适合探索未知语料，能够把抽象概念、隐含关系和上下文联系先捞出来。本体约束型方法更适合已经知道业务重点的场景，可以降低类别漂移和关系失控。

实践中可以采用两阶段策略：先用自由抽取寻找候选概念，再让领域专家把高频概念收敛成标签、属性和关系，最后用约束型抽取重跑。

2. 归一化：没有统一名字，图就会碎

“Sauron”“the Dark Lord Sauron”和“the Dark Lord”可能指向同一个角色。若不做别名、同义词、大小写、单复数和跨语言归一化，图的度数、社区和检索结果都会被稀释。

最低限度应保留：规范名称、别名列表、来源片段、置信度和人工合并记录。实体合并最好能撤销，而不是直接覆盖原始抽取结果。

3. 持久化：一次生成和长期维护是两种产品

Pandas + NetworkX 足以完成一次实验；Neo4j 等图数据库适合持久化、索引、图算法和可视化；Wiki 文件层则更适合版本控制、人工阅读和跨工具协作。

因此，持久化选择取决于更新方式：临时分析重视启动速度，团队知识库重视可追踪和可恢复，在线应用则需要查询性能、并发、权限与备份。

4. 检索：图不是向量库的替代品

向量搜索擅长找语义相近内容，图搜索擅长沿着明确关系扩展上下文。较稳妥的检索链路是：关键词或向量召回种子节点，再做受限的图扩展，最后回到原文片段核对证据。

文本到知识图谱流程

.text

问题 → 关键词/向量召回 → 图关系扩展 → 原文证据核对 → 生成回答

图扩展要有预算和边类型过滤。否则一个高连接度节点会把大量低相关内容带进上下文，检索结果反而变得嘈杂。

5. 本体治理：把“想抽什么”说清楚

Ontology Playground 展示了本体的可视化一面，Graph Maker 展示了本体如何进入抽取链路，LLM Wiki 则展示了 schema 如何参与知识库维护。三者组合起来，形成了从设计、生成到运行时治理的闭环。

本体不应该只是一份静态文档。它需要版本号、变更说明、样例数据、校验规则和迁移策略。关系名称、基数和实体属性一旦改变，已有图谱如何重算，也必须提前想清楚。

05

PART

项目对比：不要用一个尺子量三种工具

TEXT TO KNOWLEDGE GRAPH

`knowledge_graph`

• 优势
  ：代码路径短，依赖直观；本地模型路线清晰；适合 Notebook 教学和快速实验。

• 不足
  ：知识库生命周期、实体归一化、权限、增量更新和生产检索需要自行补齐。

• 最佳场景
  ：验证“概念图谱是否能改善某类问答”，或为后续系统挑选抽取策略。

`llm_wiki`

• 优势
  ：覆盖来源导入、Wiki 生成、图谱分析、向量检索、MCP、Agent 和 Review；有持久化队列与源文件追踪。

• 不足
  ：能力面广，配置和运维成本更高；生成知识的质量仍需要人审和来源核对。

• 最佳场景
  ：个人研究库、团队资料库、需要被编码 Agent 调用的长期上下文层。

`Ontology-Playground`

• 优势
  ：交互式理解和设计 ontology 的门槛低；静态部署轻；RDF/XML 往返和分享路径清楚。

• 不足
  ：不负责大规模文档抽取、图数据库存储和完整 RAG 运行时。

• 最佳场景
  ：领域建模、培训、方案演示、schema 评审和 Fabric IQ 生态探索。

一句话选型

想先做实验，选 knowledge_graph；想管理会持续增长的资料，选 llm_wiki；想把业务概念、属性和关系讲清楚，先用 Ontology-Playground 设计 schema，再接入抽取和存储系统。

06

PART

真正落地时，建议采用这条组合链路

TEXT TO KNOWLEDGE GRAPH

.text

原始文本/网页/PDF

↓

自由发现：寻找候选概念与关系

↓

本体设计：确定实体、属性、关系、基数和别名

↓

约束抽取：分块生成子图，保留来源与顺序 metadata

↓

归一化与校验：合并别名，过滤低置信关系，保留证据

↓

Wiki/图数据库：分别服务人工维护与结构化查询

↓

混合检索：向量召回 + 图扩展 + 原文核对

这条链路里，LLM 负责提取候选结构和生成辅助内容；schema、规则、来源和人工 Review 负责约束它。把所有判断都交给模型，系统会很快；把所有判断都交给人工，系统会很慢。两者之间需要一套可回放的中间产物。

07

PART

几个容易被忽略的风险

TEXT TO KNOWLEDGE GRAPH

1. 幻觉关系

模型可能根据常识补出原文没有说过的关系。边必须带来源片段或 chunk_id，回答时优先回到原文核对。

2. 共现不等于事实

两个概念出现在同一段，只能说明它们有上下文邻近性。展示时最好区分语义边、共现边和推断边，检索时也不要把三者混成同一类。

3. 图的规模会失控

概念过细、关系过宽、邻近边过多，都会让图变成“毛线团”。需要设置最小权重、关系白名单、节点合并和分层展示策略。

4. JSON 能解析不代表结果可信

结构化输出只是格式检查，不是事实检查。即使 Pydantic 校验通过，也要核对实体类别、关系方向、时间顺序和来源证据。

5. ontology 设计会产生维护成本

标签、属性和关系一旦进入数据管道，就会影响抽取提示词、数据库约束、查询语句和前端展示。先用小样本验证，再扩大范围，成本更可控。

6. 可视化不等于可用知识

节点会动、颜色好看、社区边界清楚，都只能说明图被渲染出来了。真正的验收标准应是：能否找到证据、能否解释路径、能否修正错误、能否随着来源更新而保持一致。

08

PART

结语：从“生成一张图”走向“维护一套知识系统”

TEXT TO KNOWLEDGE GRAPH

这五个来源放在一起看，重点不在谁提供了最漂亮的网络图。它们分别补上了知识工程的一段链路：

• 自由发现型方法降低了文本建图的起点。
• Graph Maker 把本体和结构化输出带进抽取过程。
• knowledge_graph 让这套方法可以在本地快速试起来。
• llm_wiki 把一次性抽取变成带来源、可检索、可持续更新的知识库。
• Ontology-Playground 把 schema 设计变成可观察、可讨论、可复用的工作台。

下一代知识增强 Agent 的差异，可能不只在模型参数量，而在它是否知道哪些关系有证据、哪些只是候选、哪些知识已经过期，以及当 schema 改变时该如何重建索引。

图谱的价值，不是节点会动，而是每条关系都能回到证据。

把模型抽取、schema 约束、来源追踪和人工复核放进同一条链路，知识图谱才会成为 Agent 可以依赖的记忆层。

本文由山行整理自：以下来源：

https://medium.com/data-science/how-to-convert-any-text-into-a-graph-of-concepts-110844f22a1a

https://medium.com/data-science/text-to-knowledge-graph-made-easy-with-graph-maker-f3f890c0dbe8

https://github.com/rahulnyk/knowledge_graph

https://github.com/nashsu/llm_wiki

https://github.com/microsoft/Ontology-Playground

如果对您有帮助，请帮忙点赞、关注、收藏，谢谢～

点赞关注收藏

登录查看剩余 70% 内容