说实话大多数人用 Obsidian 的状态是这样的——记了一大堆点开图谱一看挺好看然后下次想找那篇笔记愣是想不起来放哪儿了。这也不能全怪自己。Obsidian 的图谱确实好看但图谱好看不等于知识库有用。存进去容易用起来难这是高级收藏夹的通病。但如果接上了 RAG情况就不一样了。Vault 不再是静态的文档仓库变成了一个能回答问题、能主动关联、能越用越懂你的东西。具体怎么搞这篇文章说清楚。Obsidian 凭什么适合做 RAG其实 Obsidian 天然就有三个东西是专门给 RAG 准备的条件。双向链接这个事比你想的值钱。[[分布式共识]]这种写法表面上是在连笔记实际上是在手动画知识图谱。普通 RAG 只看文字像不像不看这两篇笔记之间有没有关系。Obsidian 的链接不一样——它告诉 AI这两篇是相关的哪怕它们用的词完全不一样。Karpathy 之前说过一句话挺准的wiki 加上 backlinks本质上就是手动版的 Graph RAG。Frontmatter 这个东西大家都懒得写但真的有用。每篇笔记开头那几行 YAML看着麻烦其实是你给笔记打的标签。写了之后就能按 tags、date、project 精确过滤不用每次都全库扫一遍。纯 Markdown 这个格式本来就是最 AI 友好的方案。数据不锁平台Git 能版本管理增量更新随便做跨设备同步也成熟。跟那些闭源的知识库工具比起来Markdown 至少不会哪天公司倒闭了数据全没。整体思路三层不用想太复杂就是三层东西叠起来Vault 结构层 → RAG 处理层 → 应用层Vault 结构层管的是笔记本身长什么样、链接关系怎么连、文件怎么组织。RAG 处理层管的是怎么把笔记读进来、切成块、向量化、存进向量数据库。应用层管的是怎么检索、怎么让 LLM 生成回答、用户怎么跟它交互。后面每一步都对应这三层里的一环。第一步把 Vault 结构搞利索很多人直接跳过了这步上来就搞 RAG结果效果很差。其实 Vault 结构没设计好后面 RAG 效果的上限就被卡死了。目录结构推荐用 PARA 方法大致是这样的vault/ ├── 00-Inbox/ # 随手记的碎片待整理 ├── 10-Projects/ # 在做的项目 ├── 20-Areas/ # 长期关注的领域比如技术、工作、生活 ├── 30-Resources/ # 参考资料文章摘录什么的 ├── 40-Archive/ # 彻底不动的归档 └── _templates/ # 笔记模板这样组织有个直接好处——检索的时候可以按目录来不用每次都全库搜。第二步写一个专门解析 Obsidian 的加载器普通 Markdown 加载器会把[[链接]]当成普通文字处理那样的话 Obsidian 最大的优势就没了——链接关系全丢了。加载器核心就做两件事一是正确解析 YAML frontmatter 和各种 wikilinks 语法包括[[名字|显示文字]]和[[名字#标题]]两种变体二是把所有笔记扫一遍之后反向构建 backlinks——每篇笔记被谁链接了这个关系也要有。写起来大概这个样子class ObsidianVaultLoader: def load_vault(self): # 第一遍把所有笔记加载进来 for md_file in self.vault_path.rglob(*.md): note self._parse_note(md_file) self.notes[note.title] note # 第二遍构建反向链接索引 self._build_backlinks() def _parse_note(self, file_path): # 解析 YAML frontmatter # 提取 [[wikilinks]] # 清理语法保留纯文本 # ... def _build_backlinks(self): # 每篇笔记指向谁就把谁的反向链接加上 for note in self.notes.values(): for linked_title in note.wikilinks: if linked_title in self.notes: self.notes[linked_title].backlinks.append(note.title)第三步按标题层级切块别按字数切RAG 效果好不好切块策略占一大半。按字数切的问题在于它不知道 Markdown 里哪些是标题、哪些是正文结果经常把一段完整的解释切成两半。最离谱的是代码块——切成两半之后 AI 看到的代码就是残的根本跑不通。用 Obsidian 的话按标题层级切更合理。每个块都是以一个标题开头的完整段落语义是完整的代码块也不会被切断。切好的块要带上完整的 metadata来源文件、标题、标签、wikilinks、backlinks、status、project、date。这些字段后面做混合检索的时候全用得上。第四步三种检索一起用这才是 Obsidian RAG 的精髓普通 RAG 就是向量相似度检索。Obsidian RAG 可以玩得更大一点。简单说就是三条路同时跑向量检索找语义上相关的这是基础。然后通过 wikilinks 和 backlinks 做图谱扩展——相关笔记链接的那些笔记也一起拉进来。元数据过滤兜底比如 statusarchived 的直接排除已经归档的笔记就别来捣乱了。最后去重按相关度排序返回给 LLM。有个真实会遇到的问题图谱扩展有时候反而是噪音。因为你的链接不一定都是深思熟虑的有些可能就是随手连的。这种情况下图谱扩展召回来的东西可能跟问题一点都不相关。处理方法是给图谱扩展的结果降权向量检索的结论优先。第五步接本地 LLM本地跑不上云Ollama 跑个 qwen7b 模型就够了专门给 Obsidian 知识库写一个 Prompt你是一个基于个人知识库的 AI 助手。 以下是从知识库中检索到的相关笔记 {context} 请基于以上笔记内容回答问题。如果有明确答案就引用如果没有就说没有不要编造。简单粗暴但管用。核心就一条别让 AI 自由发挥它不知道的东西就说不知道。第六步增量更新别每次全量重建Vault 是天天在变的不可能每次都把所有笔记重新向量化一遍。做法也不复杂记录每个文件的修改时间下次跑的时候只处理有变化的文件。先把旧版本从向量数据库里删掉再写入新版本。用 cron 每天自动跑一次基本就不用管了。还有个小问题LLM 不知道今天是哪天。你问最近的笔记它不知道当前日期。解决方案是在 Prompt 里把当前日期注入进去或者检索的时候按 date 字段排序。两种用法看你习惯哪个在 Obsidian 里直接问。Smart Connections 这个插件支持直接在 Obsidian 里接本地 Ollama装上配一下地址就能用。优点是体验最顺不用切换窗口缺点是定制空间比较小。独立 Web UI。用 Streamlit 搭一个界面自己做RAG 逻辑随便改。可以显示检索到了哪些笔记、来源是什么、快捷问题怎么设计。灵活很多但需要自己维护。两种不矛盾可以同时跑。几个真实的坑wikilinks 那几个语法变体一定要全覆盖。[[名字|显示文字]]和[[名字#标题]]这两种格式正则写不对就全匹配失败了。用\[\[([^\]|#])(?:[|#][^\]]*)?\]\]这个能覆盖掉。代码块在分块的时候要跳过检测不能切。标题切完了之后块里面遇到 标记就不要再动了不然 AI 看到的就是残代码。图谱扩展降权这个事很多人不知道但真的重要。随手连的链接召回来的内容可能一点都不相关给这些降权整个检索质量会好很多。LLM 不知道当前日期这个事很小但问最近的时候会很奇怪。注入一下就行。效果大概是这样场景不用 RAG普通 RAGObsidian RAG找某个笔记CtrlF 全凭记忆能找到但不太准关联笔记一起给跨笔记关联手动翻链接做不到wikilinks 自动扩展按项目过滤进目录翻不支持frontmatter 直接过滤增量更新不用管全量重建只处理变化文件数据隐私本地看工具完全本地最后Obsidian 那些双向链接、图谱、Frontmatter平时用的时候确实感觉就是存进去了没什么实际的。但接上 RAG 之后这些东西全变成了检索的武器。本质上你平时在笔记里建立的那些关联AI 都会用到。你的 Vault 越丰富、链接连得越认真AI 给你的答案就越靠谱。第二大脑这个说法被说烂了但如果你真的按这套方法做下来你会发现它真的像个大脑——不是静态的存储是活的会自己关联越用越准。参考Obsidian Smart Connections 插件Karpathy: LLM Knowledge Bases - wiki backlinks Graph RAGObsidian as AI Infrastructure