## 开篇
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 会话 → 存储笔记 → 自动入图谱
这个闭环是我觉得最有价值的设计。
传统的知识管理是「先写笔记，再查知识」。但我的使用模式是反过来的：
遇到新问题 → 问 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 次）。这些热点提醒我：我的知识重心在哪里，哪些领域我已经积累足够深。
**第三，发现意外关联。**力导向布局有时候会把两个看似无关的领域拉到一起。比如我发现”能源管理”和”数字孪生”在图谱里距离很近——因为我在润众制药项目中同时涉及了这两个领域。这种”意外关联”往往触发新的思考。
图5： 图谱节点查询发现
* * *
## 🛠️ 关于技术实现：简单说几句
前面聊的是”能做什么”，这里快速提一下”怎么做的”——给想动手的人一个参考。
核心链路就一句话：
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）
* * *
## 🕳️ 踩过的坑（精简版）
**坑一：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 抽取的三元组才是知识图谱。但真正的价值不在”图”本身，而在”用图”——问答、积累、推理，让知识自己生长。**
