obsidian ollama 本地知识库

你可能已经在本地用 Ollama 跑起了模型，笔记也堆在 Obsidian 里，但两边是断开的：笔记是笔记，模型只会闲聊。想把它们接成「能对着自己笔记提问」的本地知识库，卡点通常不在装模型，而在笔记格式太杂、切块太碎、检索召回不准，问出来的答案要么胡编，要么只复述半句话。这篇不讲原理，只给一条从整理笔记到验证效果的动作顺序，以及在哪种笔记结构下这套做法会失效。

你可能已经在本地用 Ollama 跑起了模型，笔记也堆在 Obsidian 里，但两边是断开的：笔记是笔记，模型只会闲聊。想把它们接成「能对着自己笔记提问」的本地知识库，卡点通常不在装模型，而在笔记格式太杂、切块太碎、检索召回不准，问出来的答案要么胡编，要么只复述半句话。

这篇不讲原理，只给一条从整理笔记到验证效果的动作顺序，以及在哪种笔记结构下这套做法会失效。整条链路拆下来就三段：笔记能不能被机器读懂、切块检索召回得准不准、模型有没有守住「只依据给定内容」的底线。哪一段塌了，最后那句回答都会飘。

先改笔记结构，再谈接模型

很多人一上来就装插件、拉模型，结果效果差，回头发现是笔记本身太碎。检索类工具吃的是「一块内容说清一件事」，你的笔记如果全是没主语的短句和缩进符号，切出来模型读不懂，向量也匹配不上。所以动手顺序应该是先改笔记，再动模型。

• 把长笔记尽量拆成「一主题一文件」，标题写成人能读懂的问句或名词短语，切块和召回都靠它；
• 避免纯大纲式、无主语的碎片笔记，这类内容切出来模型读不懂，检索也匹配不上；
• 给每篇笔记加统一的前置属性（标签、来源、时间），后面过滤检索范围时用得上；
• 同一主题的笔记合并成一篇，比散在五个文件里更容易被完整召回；
• 在动手前先想清楚：这套只在笔记本身有可读的完整句时成立，纯脑图式笔记先别做。

切块与向量化：决定召回质量的两步

切块和嵌入是这条链路里最影响结果、又最容易被草草带过的两步。切块决定「模型看到什么」，嵌入决定「系统能不能把对的块找出来」。两步都不需要你懂模型内部，但都需要你拿自己的笔记反复试。

嵌入模型和对话模型要分开看，别默认用同一个。中文笔记对嵌入的中文语义表现更敏感，选型思路可以到 /embeddings 对照当时的模型清单和说明。判断标准很朴素：随机挑几个你自己真提过的问题，看能不能召回对应笔记；召回不到就先调切块，别急着换模型。

把模型和笔记接起来，然后做三组验证

链路本身不复杂：提问 → 检索相关笔记块 → 拼进提示词 → 本地模型基于这些块回答。中间任何一环弱，答案都会飘。接起来之后别急着用，先按下面三组问题验一遍，比装十个插件都管用。

1. 验证一：问笔记里明确写过的事实答案对不上或答不上来，基本是检索问题，回去调块粒度和召回数量，不是模型笨。
2. 验证二：问笔记里没写的东西看它是否硬编。会硬编就在提示词里明确要求「只依据给定内容回答，找不到就说找不到」。
3. 验证三：换个问法重复问同一件事答案不稳定说明检索阈值或块粒度需要调，别急着下结论说这套不可用。

如果你只是想尽快用上，而不是从头搭这套链路，可以先到 /ai-nav/category/ai-note 看看同类笔记型工具的常见做法，再决定自己搭还是用现成的。自搭的好处是数据不出本地、可控，代价是切块和检索参数要自己调。

什么情况下别硬上这套

这套做法有明确的失效边界。不算清楚边界就动手，最后多半是折腾半天、效果还不如直接翻笔记。下面几种情况尤其要提前判断。

• 笔记量很少（几十篇以内）时，直接把相关笔记贴进对话框比整套检索更快，搭 RAG 是过度工程；
• 笔记里大量是图片、手写扫描、表格截图时，纯文本检索基本失效，得先做 OCR 或换多模态路线；
• 需要严格引用来源、要求答案可追溯到具体段落的场景，得自己把出处一并返回，不能只信模型转述；
• 对回答准确率要求极高的法律、财务类笔记，把它当检索入口而不是结论来源，最终判断仍要回原文核对。

本地知识库的价值是帮你更快找到那页笔记，而不是替你下结论。