文本转知识图谱的关键指南：两条方法路线+三个开源项目，覆盖从抽取到治理的完整链路。

核心内容：

• 知识图谱构建的核心挑战与价值
• 两条文本建图方法路线解析
• 三个开源项目功能与应用

知识工程手记2026.08

文本如何变成知识图谱

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

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

Graph RAGOntology

把一篇文章变成一张图并不难。

难的是让这张图在下一次检索、问答和建模时仍然可信。

很多知识库仍然停留在“切块、向量化、召回、生成”这条直线上。

它适合回答与原文表述相近的问题，却不一定能处理跨段落关系、实体别名、事件顺序和知识缺口。

这组材料从五个维度将问题串联起来。

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

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

自由发现概念 → 用本体约束抽取 → 把知识持续写回 Wiki → 用可视化工具治理 schema。

为什么要把文本变成图

知识图谱可以先用一个简单模型理解：节点代表实体、事件或概念，边代表它们之间的关系。

与只保存段落向量相比，图结构额外记录了“谁和谁有关、通过什么关系有关、关系出现在哪里”。

这会改变检索方式。

• 从相似度走向路径：问题不一定与答案段落使用相同词语，但可能能沿着人物、事件、地点或概念之间的路径找到答案。
• 从局部片段走向跨段落连接：多个段落分别提到同一个对象时，图可以把这些线索聚合起来。
• 从回答问题走向发现问题：节点度数、社区结构、孤立节点和桥接节点，都可以帮助我们发现知识集中在哪里、断在哪里。
• 从单一检索器走向混合检索：图查询、图算法、向量相似度和原文证据可以共同决定送给模型的上下文。

但图谱并不是自动获得的“事实层”。

它首先是一套由模型抽取出来的结构化假设，必须保留来源、上下文和人工校验入口。

知识图谱项目横向视觉

两种从文本建图的路线

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

第一篇文章采用的是自由发现路线。

它不预先规定实体类型和关系枚举，而是让本地大模型阅读文本块，自己找出重要概念及其语义关系。

基本过程如下：

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

这里有一个很重要的细节：同一对概念之间可能出现多条边。

语义关系回答“它们是什么关系”，上下文邻近回答“它们是否经常一起出现”。

合并时保留两类证据，图谱才不至于只剩一张漂亮的连线图。

knowledge_graph 方法流程

这条路线的优点是启动快。

它适合面对没有固定 schema 的文章、论文和资料集。

它也比较适合探索阶段：先看图，再决定哪些实体类别和关系值得正式建模。

代价同样明显。

模型可能把未明确出现的概念补进来，也可能把同一对象拆成多个名字。

上下文邻近关系还容易过重，导致“同段出现”被误读成“存在事实关系”。

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

第二篇文章把自由度收回来，提出 Graph Maker 路线。

用户先定义实体标签和关系类型，模型再按这套本体抽取。

例如，一个人物与地点类知识库可以定义 Person、Place，以及“居住于”“访问”等关系。

临床研究则可以换成化合物、用途、效果和反应等领域概念。

模型不再完全自由地发明类别，而是被提示集中在应用真正关心的结构上。

Graph Maker 的处理步骤是：

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

安装和初始化非常直接：

pip install knowledge-graph-maker

边模型带有 metadata，因此可以记录页码、章节、文章名或其他来源信息。

order 字段则可以按文本块顺序观察关系如何逐步出现。

这对于书籍、长报告和时间线材料尤其有用。

它还针对工程中最常见的三个问题做了处理：

• 用提示词约束实体类别，尽量减少别名漂移。
• 在 JSON 解析失败时拆分输出并恢复可解析的边。
• 为关系保留上下文，避免最终图谱完全脱离原文。

知识图谱三层架构

不过，本体约束也不是免费午餐。

schema 需要领域知识，关系定义得太宽会失去约束，定义得太窄又会漏掉有用信息。

更稳妥的做法是先用小样本建立本体，再用真实抽取结果反过来修订标签、关系和别名规则。

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

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 三个操作组织工作流。

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

• 第一步：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 对接数据管道、存储和权限体系。

五类能力如何逐层补齐

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

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

自由发现型方法适合探索未知语料，能够把抽象概念、隐含关系和上下文联系先捞出来。

本体约束型方法更适合已经知道业务重点的场景，可以降低类别漂移和关系失控。

实践中可以采用两阶段策略：

• 先用自由抽取寻找候选概念。
• 再让领域专家把高频概念收敛成标签、属性和关系。
• 最后用约束型抽取重跑。

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

“Sauron”“the Dark Lord Sauron”和“the Dark Lord”可能指向同一个角色。

若不做别名、同义词、大小写、单复数和跨语言归一化，图的度数、社区和检索结果都会被稀释。

最低限度应保留：

• 规范名称
• 别名列表
• 来源片段
• 置信度
• 人工合并记录

实体合并最好能撤销，而不是直接覆盖原始抽取结果。

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

Pandas + NetworkX 足以完成一次实验。

Neo4j 等图数据库适合持久化、索引、图算法和可视化。

Wiki 文件层则更适合版本控制、人工阅读和跨工具协作。

因此，持久化选择取决于更新方式：

• 临时分析重视启动速度。
• 团队知识库重视可追踪和可恢复。
• 在线应用则需要查询性能、并发、权限与备份。

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

向量搜索擅长找语义相近内容，图搜索擅长沿着明确关系扩展上下文。

较稳妥的检索链路是：关键词或向量召回种子节点，再做受限的图扩展，最后回到原文片段核对证据。

文本到知识图谱流程

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

图扩展要有预算和边类型过滤。

否则一个高连接度节点会把大量低相关内容带进上下文，检索结果反而变得嘈杂。

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

Ontology Playground 展示了本体的可视化一面，Graph Maker 展示了本体如何进入抽取链路，LLM Wiki 则展示了 schema 如何参与知识库维护。

三者组合起来，形成了从设计、生成到运行时治理的闭环。

本体不应该只是一份静态文档。

它需要版本号、变更说明、样例数据、校验规则和迁移策略。

关系名称、基数和实体属性一旦改变，已有图谱如何重算，也必须提前想清楚。

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

`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，再接入抽取和存储系统。

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

• 原始文本/网页/PDF
• 自由发现：寻找候选概念与关系
• 本体设计：确定实体、属性、关系、基数和别名
• 约束抽取：分块生成子图，保留来源与顺序 metadata
• 归一化与校验：合并别名，过滤低置信关系，保留证据
• Wiki/图数据库：分别服务人工维护与结构化查询
• 混合检索：向量召回 + 图扩展 + 原文核对

这条链路里，LLM 负责提取候选结构和生成辅助内容。

schema、规则、来源和人工 Review 负责约束它。

把所有判断都交给模型，系统会很快；把所有判断都交给人工，系统会很慢。两者之间需要一套可回放的中间产物。

几个容易被忽略的风险

1. 幻觉关系

模型可能根据常识补出原文没有说过的关系。

边必须带来源片段或 chunk_id，回答时优先回到原文核对。

2. 共现不等于事实

两个概念出现在同一段，只能说明它们有上下文邻近性。

展示时最好区分语义边、共现边和推断边，检索时也不要把三者混成同一类。

3. 图的规模会失控

概念过细、关系过宽、邻近边过多，都会让图变成“毛线团”。

需要设置最小权重、关系白名单、节点合并和分层展示策略。

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

结构化输出只是格式检查，不是事实检查。

即使 Pydantic 校验通过，也要核对实体类别、关系方向、时间顺序和来源证据。

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

标签、属性和关系一旦进入数据管道，就会影响抽取提示词、数据库约束、查询语句和前端展示。

先用小样本验证，再扩大范围，成本更可控。

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

节点会动、颜色好看、社区边界清楚，都只能说明图被渲染出来了。

真正的验收标准应是：

• 能否找到证据
• 能否解释路径
• 能否修正错误
• 能否随着来源更新而保持一致

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

这五个来源放在一起看，重点不在谁提供了最漂亮的网络图。

它们分别补上了知识工程的一段链路：

• 自由发现型方法降低了文本建图的起点。
• 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

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

点赞关注收藏