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

开篇

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 落地需要哪些关键工具？」——它能在图谱里顺着关系链推导出答案。

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

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

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

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

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

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

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

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

你可以用自然语言提问，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]→ 能源管理）。

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

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

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

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

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

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

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

具体操作：

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

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

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

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

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

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

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

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

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

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

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

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

核心链路就一句话：

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

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

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

技术栈简单列一下：

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

跑出来的数据：

🕳️ 踩过的坑（精简版）

坑一：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 和 P3 是后续优化方向，不急着上。

一句话总结

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