Obsidian Wiki知识库双链远远不够——从知识双链到知识图谱的升级之路

原文链接：https://mp.weixin.qq.com/s/ogvTf9i153v-Ov4Tsmb7qg

实测 Obsidian Graph View 仅能模糊展示笔记关联，无法区分实体关系、解答业务提问。我意识到单纯双链可视化并非真正知识图谱。利用端午 3 天搭建全新系统，实现知识自动入库、自然语言问答、工作方案关联推演，打造可落地的智能知识引擎。

开篇

5月30号，我发了一篇文章——《「RAG已死」是炒作？实测后我转向Obsidian+LLM Wiki重构个人知识库》。

那篇文章里，我用了一个词：知识图谱。当时我用的是 Obsidian 的 Graph View——52个词条、3大分类、节点连线、力导向布局，看着就是那么回事。我管它叫”知识图谱”，还配了图做了对比表。

文章传播得还行。但接下来一个月左右，我每天都在用这套系统写笔记、做项目、整理方案。用得越深，越觉得不对劲。

Graph View 只是个花瓶，只能告诉我「这篇笔记和那篇笔记相关」，但它从不告诉我「是什么关系」。虽然我也用了Copilot插件，借助LLM检索回答一些知识库内容，但如果问它”工业AI落地需要哪些关键工具”，它给不了答案。我想让它帮我把新写的内容自动纳入知识网络，它做不到。

那一刻我意识到：我之前对”知识图谱”的理解，太浅了。

我真正想要的不只是”看着像个图谱”——我想要的是：

• • 知识能自动积累：写进去的笔记，自动变成可查询、可推理的知识
• • 知识能问答交互：用自然语言提问，系统能在知识网络里 traversal 找到答案
• • 知识能辅助工作：做方案、写标书、给客户讲 PPT 的时候，知识图谱能帮我推导出我遗漏的关联点

也就是说，我想做的不是”关系图”，而是”知识引擎”。

这个念头一起，就停不下来。我利用端午节假期3天搭了第一版，又花了几天做数据清洗和增量更新。现在系统已经稳定运行，可以正常使用了（需要花费一些token，目前还在薅阿里百炼的免费token）。

这篇文章是一篇使用心得——记录一个从”觉得双链够用了”到”发现远远不够”再到”自己动手搭一个”的探索过程。

🤔 我的观察：关系图与知识图谱，差的不只是名字

先快速说清楚两者的区别，然后重点聊后面真正重要的部分——使用场景。

Obsidian 的关系图告诉你「这篇笔记和那篇笔记相关」，但不告诉你「是什么关系」。关系类型永远是”关联”，没有语义。

真正的知识图谱核心构建块（Building Blocks）是 实体（Entity）、关系（Relation） 和 属性（Property）的三元组。举个例子：

「RAG 技术通常使用向量数据库来存储和检索知识，并在工业 AI 场景中落地。」

在关系图里：[[RAG]] 文档 — 关联 — [[向量数据库]] 文档。仅此而已。

在知识图谱里，应该拆成：

• • (RAG, REQUIRES, 向量数据库) — RAG 需要向量数据库
• • (RAG, BELONGS_TO, 大模型) — RAG 属于大模型技术
• • (RAG, USED_IN, 工业AI) — RAG 应用于工业AI

三条独立的、可推理的、带语义的三元组。基于这些，你可以问系统：「工业 AI 落地需要哪些关键工具？」——它能在图谱里顺着关系链推导出答案。

一句话：旧版是「关系图」，新版是「知识图」。 前者帮你发现”相关的”，后者帮你理解”为什么相关”。

对比维度

关系图（旧版）

知识图谱（新版）

实体

预定义关键词，52个

LLM自动抽取，5,010个

关系

共现=「关联」

10种语义关系类型

存储

Markdown+JSON

SQLite+图结构

查询

双链跳转

图遍历、邻域查询

推理

无

A→B→C 链式推理

增量更新

手动脚本

定时自动构建

图1：能力雷达对比
好了，区别说清楚了。接下来进入重点——这个系统真正跑起来之后，我每天都在用它做什么。

💡 我的思考：从”能看”到”能用”，知识图谱的真正价值在使用场景

很多人构建知识图谱，做到”能可视化”就停下了。但我很快发现——看图谱不是目的，用图谱才是。

所以我在系统里做了三个核心使用场景：QA 问答、知识自动积累、可视化探索。一个一个说。

场景一：QA 问答——不是搜索引擎，是知识推理

这是我最常用的功能。不是”关键词匹配”，而是”图谱推理”。

系统的 QA 模块基于 ReAct Agent 架构，配备了 5 个工具函数：

工具函数

作用
search_entities
在图谱中搜索实体，返回匹配列表
get_entity_details
查询单个实体的完整信息（属性、类型、来源）
get_neighbors
获取某实体的邻域关系（关联了哪些实体、什么关系）
find_path
查找两个实体之间的最短路径（知识链条）
answer_by_reasoning
基于关系链进行推理，回答复杂问题

你可以用自然语言提问，Agent 会拆解意图、调用工具、在图谱里 traversal，最后给出带推理过程的答案。

举几个我实际问过的例子：

Q1：「我写过关于 AI Agent 的笔记里，哪些提到了具体的落地工具？」

Agent 的逻辑：先搜”AI Agent”实体 → 获取邻域关系 → 筛选出 USED_IN 或 REQUIRES 类型的关系 → 列出关联的工具实体（如 LangChain、AutoGen、Dify 等）。

图2：QA问答场景1 — 实体搜索与邻域查询

Q2：「IIMP 和能源数字化之间，知识链条是什么？」

Agent 的逻辑：查找 IIMP 和 能源数字化 两个实体之间的路径 → 用 BFS 最短路径算法找到连接链 → 返回完整的知识链路（如：IIMP →[PART_OF]→ HolliCube →[RELATED_TO]→ 能源管理）。

图3：QA问答场景2 — 路径推理与知识链条

Q3：「我笔记里提到的AI Agent，哪些在智能制造项目中实际用过？」

Agent 的逻辑：搜索”AI Agent”实体，会有两条链路：

AI Agent USED_IN → 智能制造→ 整体智能制造领域

工业AI Agent IS_A → AI Agent，BELONGS_TO → 工业AI 工业互联网、设备语义理解、工艺推理、AI安全约束执行

图4：QA问答场景3 — 复杂条件查询

这三个问题的共同点是：你没法通过全文搜索得到答案。因为搜索只能找到”包含这些词”的文档，但无法回答”这些词之间有什么关系”。而知识图谱可以。

场景二：知识自动积累——QA 会话 → 存储笔记 → 自动入图谱

这个闭环是我觉得最有价值的设计。

传统的知识管理是「先写笔记，再查知识」。但我的使用模式是反过来的：

1

`遇到新问题 → 问 QA Agent → 得到答案 → 觉得有价值 → 一键保存为笔记                                                                      ↓定时增量构建 ← 自动抽取三元组 ← 新笔记进入图谱 ← 存储为 Markdown`

具体操作：

• 1. QA 问答过程中，如果 Agent 的回答我觉得有价值，系统支持「导出会话」——把问题和答案自动保存为 Markdown 文件，放进 Vault 的指定目录。
• 2. 定时增量构建（通过 .workbuddy/automations 配置每天凌晨执行）扫描 Vault 中新增/变更的文件。
• 3. 自动抽取：新文件被送入 llm_kg_extract.py，LLM 读取内容、抽取三元组、去重对齐。
• 4. 自动入库：新的实体和关系写入 SQLite 数据库，第二天打开图谱，新知识点已经出现在图谱里。

这意味着：你的每一次深度问答，都在自动丰富知识图谱。 你不需要手动标注、不需要手动建关系，系统自己帮你完成。

举个例子。上周我在 QA 里问了一个问题：「智能制造项目中，MES 和 MOM 的区别是什么？」Agent 给出了一个很详细的答案。我点了「导出会话」，系统自动生成了 MOM_vs_MES_QA_20260620.md。第二天凌晨，增量构建跑完，我在图谱里搜”MOM”，发现它跟”MES”、”智能工厂”、”生产调度”等实体已经建立了新的关系。

这就是知识自动积累——不是人追知识，是知识追人。

场景三：图谱可视化——不是为了好看，是为了发现盲区

当然，可视化本身也有价值。但不是「发朋友圈好看」那种价值。

我用图谱可视化主要做三件事：

第一，发现知识孤岛。 图谱里有一类节点是”孤立的”——只连了一两条边，孤零零地飘在外围。这些节点通常代表我知道但还没深入理解的概念。我会优先去补这些盲区。

第二，发现知识热点。 节点越大，说明关联越多。目前我的图谱里最大的节点是”AI Agent”（1,187 次关联），其次是”智能制造”（892 次）和”大模型”（756 次）。这些热点提醒我：我的知识重心在哪里，哪些领域我已经积累足够深。

第三，发现意外关联。 力导向布局有时候会把两个看似无关的领域拉到一起。比如我发现”能源管理”和”数字孪生”在图谱里距离很近——因为我在润众制药项目中同时涉及了这两个领域。这种”意外关联”往往触发新的思考。

图5： 图谱节点查询发现

🛠️ 关于技术实现：简单说几句

前面聊的是”能做什么”，这里快速提一下”怎么做的”——给想动手的人一个参考。

核心链路就一句话：

1

`MD源文件 → 文本分段 → LLM抽取三元组 → 去重对齐 → SQLite存储 → 可视化+查询`

这里要说明一点：这个系统不是独立的，它直接基于我的 Obsidian Vault 构建。

我给这套系统起了个名字——「数智知穹」。它的数据源就是我的 Obsidian Vault 目录，系统会定时扫描 Vault 里的每一个 Markdown 文件，增量抽取新文件和变更文件的三元组。换句话说，我继续在 Obsidian 里正常写作，「数智知穹」在后台默默把笔记变成知识图谱。文件管理页面里看到的目录树，就是我的 Vault 真实目录结构。

图6：数智知穹系统 — 主界面

图7：数智知穹系统 — 文件管理页面
技术栈简单列一下：

• • LLM：百炼千问（qwen-turbo），中文效果好、成本低，配合多模型 fallback
• • 存储：SQLite（entities/relations/extract_history 三表），轻量但够用
• • 后端：Flask REST API，13 个端点，支持图谱查询、文件管理、QA Agent
• • 前端：vis-network 9.1.2 纯前端 SPA，四个 Tab：图谱浏览 / 文件管理 / QA 问答 / 系统设置

跑出来的数据：

数据指标

数值

实体总数
5,010
关系总数
7,698
实体类型

19 种

关系类型

10 种（Schema 定义）

已处理文件

108 个

来源溯源覆盖

38%（1,926/5,010）

图8：实类型分布饼图

🕳️ 踩过的坑（精简版）

坑一：LLM 会自创关系类型。 我 Schema 只定义了 10 种，它自己发明了 140+ 种。V2.0 修复：Prompt 加了一句「禁止自创」，+ 入库时校验层拦截。现在已解决。

坑二：实体去重。 “大模型””大语言模型””LLM”——同一个东西三个写法。修复方案：别名表 + 向量相似度。现在已解决。

坑三：增量更新。file_hashes.json 编码损坏，每次都是全量扫描。修复方案：重新实现 md5 计算 + 增量判断。现在已解决，配合 .workbuddy/automations 每天定时跑。

坑四：图谱太密。 5,010 节点 + 7,698 条边，前端一次渲染卡死。解决方案：默认限制 500 个 + 类型筛选。够用，但长期还是要上 Neo4j。

🎯 所以呢：从”能用”到”好用”，知识图谱的真正价值

回到这篇文章的初衷。

我不是因为”之前的描述不够准确”才去升级——我是因为每天都在用，用着用着发现”不够用了”。

想做的三件事（知识积累、问答交互、辅助工作），Obsidian 双链给不了。RAG 给不了（它只能检索，不能推理）。只有真正把知识结构化、语义化、图化，才能实现。

这次升级本质上是一次认知驱动的实践：从”知道有个概念叫知识图谱”到”动手建一个真正能用的知识图谱”。从 52 个词条到 5,010 个实体，从”只能看”到”能问答、能积累、能推理”。

现在这套系统每天都在跑，定时增量构建凌晨自动执行，QA 问答是我查资料的首选入口。它不再是一个”项目”，而是一个基础设施——就像我的 Obsidian Vault 一样，成了日常工作的默认环境。

后续任务状态更新

V2.0 方案里的任务，目前进展如下：

优先级

任务

状态

说明

P2

API 成本追踪

⏳ 待做

记录每次 LLM 调用的 Token 和费用

P2

图谱路径查询 API

⏳ 待做

BFS 最短路径，回答”X 和 Y 有什么关系”

P2

QA Agent 增强

⏳ 待做

从关键词搜索升级到图遍历推理

P3

智能双链建议

📋 规划中

基于图谱关系发现缺失的 [[双链]]

P3

Neo4j 迁移

📋 规划中

从 SQLite 到专业图数据库

目前系统运行稳定，数据质量可控，增量更新自动跑。

P2 和 P3 是后续优化方向，不急着上。

一句话总结

Obsidian 的双链是关系图，LLM 抽取的三元组才是知识图谱。但真正的价值不在”图”本身，而在”用图”——问答、积累、推理，让知识自己生长。

💬 互动话题

你平时怎么管理知识？有没有试过”问答→笔记→自动积累”的闭环？还是觉得太复杂了，双链够用？评论区聊聊你的做法 👇

完整代码和方案我后续整理开源。如果你也在折腾知识管理，或者有类似的好奇心，欢迎一起交流。

数智知客 · 以知为客，以智为造深耕 AI+智能制造的实践与思考

💬 本文评论区已开启，但暂无读者留言。

本文转载自微信公众号，如有侵权请联系删除。