obsidian-llm-wiki-local: Obsidian本地AI知识图谱自动构建¶
Ch03.090 obsidian-llm-wiki-local: Obsidian本地AI知识图谱自动构建¶
📊 Level ⭐⭐ | 7.7KB |
entities/obsidian-llm-wiki-local-kytmanov.md
核心问题：笔记孤岛¶
大多数人的 Obsidian 图谱视图是"孤岛"——剪藏容易（点一下），整理难（大脑满负荷）。输入和整理成本差 100 倍，系统天然失衡。
传统 RAG 本质是"搬运工"：你问问题，AI 翻笔记、拼答案，知识不积累，第二天一切从头来过。
LLM Wiki 的思路是"管理员"：AI 主动读笔记，提炼概念，写成结构化 wiki 条目，建立双向链接。你只管往里扔，它负责整理。
obsidian-llm-wiki-local 工作流¶
三步流水线（全程本地 Ollama）：
- 读取：指定 raw/ 或 inbox 文件夹，遍历所有 .md 文件
- 提炼：对每篇笔记调用 Ollama，提取 3-7 个核心概念、识别人物/实体、判断是否已有对应页面
- 写入：新概念创建 wiki 页面；已有概念追加引用；同时建立双向链接
单篇处理时间：10-30 秒（7B 模型 + RTX 3060 12G）。
实测效果¶
| 指标 | 数据 |
|---|---|
| 输入笔记 | 400 篇 |
| 处理时间 | ~20 分钟 |
| 生成概念页 | 60+ |
| 生成双向链接 | 200+ |
| 中文概念提取准确率 | ~85%（Qwen 2.5 7B） |
最有价值的发现：跨时间跨领域的隐含关联被 AI 挖掘出来（如"认知负荷理论"文章 + "Obsidian文件夹扁平化"笔记 → AI 自动关联），人脑受限于近期上下文，AI 没有这个限制。
另一个价值：笔记质量审计——写不出精准概念的笔记，通常是随手剪藏、只看了标题没读完的文章。
可纠错反馈循环¶
AI 第一版生成的概念页可能太泛（"这是一篇关于效率的文章"）。用户在页面标注 rejected 并重新触发 → AI 换角度重新生成，第二版质量明显更高。这个拒绝-重生成循环是质量保障的关键机制。
局限性与适用边界¶
| 限制 | 说明 |
|---|---|
| 需手动触发 | 不是安装后自动跑，需手动指定目录触发 |
| 模型质量决定上限 | 7B 准确率 ~70-80%；14B/32B 精度更高 |
| 不做向量检索 | 擅长"编译"（零散笔记→结构化 wiki），不擅长"搜索"（问"有没有提到 xxx"） |
| CPU 限制 | 16G 内存笔记本可 CPU 跑 7B，但慢 |
两种需求互补：脚本整理（LLM Wiki）+ Obsidian 内置搜索（RAG），配合使用。
与 Karpathy LLM Wiki 的关系¶
本文实践了 Karpathy LLM Wiki 的核心理念，具体实现为 Alexander Kytmanov 的 obsidian-llm-wiki-local 开源项目（60 次提交，活跃维护），100% 本地运行、不依赖任何云端 API。
→ Karpathy LLM Wiki 概念 → RAG vs LLM Wiki 对比
技术栈¶
- 运行时: Ollama（本地大模型推理）
- 推荐模型: qwen2.5:7b（中文效果好、门槛低）或 deepseek-r1:8b（推理能力强）
- 依赖: Python 3.10+
→ 原文存档
深度分析¶
Insight 1：跨时间关联挖掘是最大价值 AI 能发现人类受限于"近期上下文"的隐含连接——去年9月的"认知负荷理论"文章与今年4月的"Obsidian文件夹扁平化"笔记，AI 将其关联为"认知负荷理论实践案例"，因为扁平化本质是减少分类带来的认知负荷。这种跨时间跨领域的关联挖掘是传统笔记系统无法实现的。
Insight 2：笔记质量审计的无意实现 AI 提炼概念时天然暴露了笔记质量差异——能写出5个精准概念的笔记 vs 只能憋出"这是一篇关于某话题的文章"的笔记。后者共同点：都是随手剪藏、只看了标题没读完的文章。AI 无意中完成了一次全面的笔记质量审计。
Insight 3：本地运行的隐私与成本优势 100%本地运行、不依赖任何云端API，意味着笔记内容永不离开本地设备。在知识管理工具频繁数据泄露的背景下，这个特性对关注隐私的用户是核心差异化价值。
Insight 4：可纠错设计是质量保障关键 rejected 标签 + 重新触发的机制，将 AI 生成的不确定性转化为可控的质量提升流程。第一版可能太泛（"效率文章"），标 rejected 后第二版立刻精准化（"52/17节律应对深度工作中注意力衰减问题"）。这个 Human-in-the-loop 设计值得借鉴。
Insight 5：RAG 与 LLM Wiki 是互补需求 两者解决的问题不同：LLM Wiki 擅长"编译"（零散笔记→结构化 wiki），RAG 擅长"搜索"（问"有没有提到 xxx"）。这不是非此即彼的选择，而是不同阶段不同场景的配合使用。
实践启示¶
-
采用周末编译节奏：日常剪藏到 inbox/，周六跑一次脚本处理本周新增笔记。15分钟完成以往2小时的手动整理，效率提升一个数量级。
-
用 rejected 标签把控质量：打开 AI 生成的 wiki 页面发现理解偏差时，在页面标注
rejected并重新触发。AI 会换角度重新生成，第二版质量通常显著提升。 -
手动补 AI 漏掉的链接：AI 生成的双向链接可能有遗漏，完成编译后在 Obsidian 图谱视图检查新增概念页面，对明显关联但未建立链接的手动补充。
-
根据硬件选择模型规格：RTX 3060 12G 以上用 7B 可流畅运行；更高精度需求上 14B 或 32B 模型；16G 内存笔记本可 CPU 跑 7B 但较慢。
-
LLM Wiki 整理 + Obsidian 内置搜索配合：用脚本做系统性概念整理，用内置搜索做临时性信息检索，两者配合覆盖"编译"和"搜索"两类需求。