Obsidian + LLM Wiki 新手實戰：從零建立會搜尋、會連結、會回查來源的 AI 知識庫

1. 先看懂整體：Wiki 是教材，檢索是圖書館員，LLM 是會說明的助教

把 Obsidian + LLM Wiki 想成一座小型圖書館：Obsidian 保存原始 Markdown 筆記，內部連結與屬性像索引卡，檢索層先找出可能相關的頁面，LLM 再把這些頁面整理成回答。大型語言模型（Large Language Model，LLM）很會組織文字，但不會自動知道哪一份私人筆記才是正確教材；因此這套系統的核心不是「把全部資料塞給 AI」，而是「先找到對的資料，再要求 AI 依來源回答」。

檢索增強生成（Retrieval-Augmented Generation，RAG）就是把搜尋與生成串在一起：先檢索，再把結果放進模型的上下文。這能降低憑空作答的機率，但不能消除錯誤；搜尋可能找錯筆記，模型也可能誤讀內容。

新手的第一個成功標準不是「它講得很像專家」，而是三件事：能指出用了哪些筆記、找不到資料時會明說不知道、你可以點回來源確認。

• Wiki 負責保存可閱讀、可搬移、可備份的知識。
• 檢索層負責縮小範圍，不應把整個 Vault 無差別丟進模型。
• LLM 負責摘要、比較與解釋；原始筆記與來源才是查核起點。

2. 先選路線：純 Obsidian、雲端 LLM 與本機 Ollama 各解決不同問題

AI 新手不需要第一天就完成全本機 RAG。建議先用 20 至 50 篇不敏感的示範筆記建立可查核流程，再依隱私、成本與硬體條件選擇雲端或本機模型。純 Obsidian 是必要基線；雲端模型設定較少，但被選入上下文的內容會送往你設定的模型供應商；Ollama 可把聊天模型與嵌入模型留在本機執行，但要自行承擔模型下載、記憶體、版本與連線除錯。

AI 建議：個人公開學習筆記可先走雲端路線，快速學會範圍限定與來源回查；含有病人、客戶、公司內部、憑證或未公開專案資訊的內容，不應直接拿來當入門測試資料。即使使用本機模型，也要先確認外掛本身是否還會呼叫其他網路服務。

不確定性：模型供應商、外掛版本、訂閱方案與資料處理條款會變動。設定前應重新閱讀當前版本的隱私揭露與服務條款。

3. 第一步：建立 Vault，並在安裝 AI 外掛前先做好備份

Obsidian 的 Vault 本質上是本機檔案系統中的資料夾，筆記以 Markdown 純文字檔保存，Vault 根目錄下的 .obsidian 資料夾則存放快捷鍵、主題與外掛等設定。第一次開啟 Obsidian 時，選擇建立新的空白 Vault，名稱可用 AI-Wiki；位置放在你清楚知道、容易備份的資料夾，不要把一個 Vault 再放進另一個 Vault。

先建立真正的備份，再談同步。Obsidian 官方明確提醒：同步服務可以讓多台裝置取得相同檔案，但不等於獨立備份。至少保留一份和主要工作資料夾分離、可測試還原的副本。

AI 建議：一開始只用一個 Vault，資料夾維持少而穩定。你需要的是可預測的收納規則，不是漂亮但難維護的分類樹。

• 設定附件預設位置為 99-Attachments，避免圖片散落。
• 設定新筆記預設位置為 00-Inbox，降低建立筆記時的決策負擔。
• 備份時包含 .obsidian，才能一併保留外掛與設定；還原前仍應檢查第三方外掛。

4. 第二步：用最小屬性與模板，讓人和 LLM 都看得懂每篇筆記

屬性（Properties）是筆記頂端的結構化資料，Obsidian 會以 YAML 保存；模板（Templates）是內建核心外掛，可把固定欄位與段落插入新筆記。新手只需要少量、一致的欄位：筆記類型、狀態、建立日期、來源、別名與標籤。欄位太多會讓你停止寫筆記，也會讓檢索結果充滿空白或不一致資料。

一篇永久筆記最好回答一個主要問題。把「外部來源說了什麼」、「我怎麼理解」與「仍待確認」分開，之後 LLM 才比較不會把你的推測誤認為來源事實。

Obsidian 的模板變數可自動填入標題與日期；在 YAML 內使用日期變數時加上引號，可避免 Live Preview 對模板內容做非預期改寫。

5. 第三步：用內部連結、MOC 與 Bases 建立可走動的知識網路

在 Obsidian 輸入兩個左方括號即可建立內部連結，例如 [[檢索增強生成]]；連結到尚未存在的名稱，也可以先建立待補筆記。內部連結把零散檔案變成可導覽的知識網路，而且重新命名檔案時，Obsidian 可自動更新相關連結。標籤適合粗略分群，屬性適合保存可篩選欄位，MOC 則適合人工策展一個主題的閱讀順序。

Bases 是 Obsidian 的核心外掛，可依筆記屬性建立類似資料庫的表格、清單或卡片檢視；底層資料仍在本機 Markdown 與屬性中。新手不必先寫複雜語法，等同類筆記超過十幾篇，再用介面建立一個簡單表格即可。

AI 建議：每完成一篇概念筆記，至少加入一個上位 MOC 連結與一個相關概念連結。這比追求華麗 Graph View 更能改善日後檢索。

6. 第四步：安全安裝 Copilot，先用免索引搜尋而不是立刻向量化全部筆記

Copilot for Obsidian 是第三方社群外掛，不是 Obsidian 官方功能。安裝路徑為設定、社群外掛、開啟社群外掛、瀏覽，搜尋 Copilot for Obsidian 後安裝並啟用。Obsidian 官方提醒，社群外掛會以第三方程式碼在你的環境中執行，而且不會自動更新；因此應先備份、閱讀外掛說明、定期手動檢查更新。

截至 2026-07-24，Copilot GitHub 的最新正式版為 3.3.3。其目前文件說明，Vault 搜尋可先不建立向量索引，Semantic Search 是選配；這很適合新手先確認基本搜尋與來源流程，再承擔嵌入模型、索引更新與重建成本。

介面名稱會隨版本變動，本文使用的是功能概念而不是保證不變的按鈕名稱。看不到相同選項時，先確認 Obsidian、Copilot 版本與當前 README／Releases。

• 先以 @ 加入目前筆記、指定筆記或資料夾，確認回答範圍。
• 不要把 API key 寫進筆記；使用外掛設定提供的祕密儲存機制。
• 先保持 Semantic Search 關閉；基本問答通過後再建立嵌入索引。
• 安裝後記錄版本與設定變更，發生問題時才能重現。

7. 路線 A：雲端模型用五個步驟完成第一個可回查來源的問答

雲端路線適合先學會工作流。進入 Copilot 設定，新增你已同意其條款的模型供應商與 API key，選擇一個聊天模型，先不要開啟 Semantic Search。接著打開一篇你非常熟悉的示範筆記，用 @ 把該筆記加入上下文，再提出一個答案明確、可人工核對的問題。

Copilot 的目前揭露表示，免費層的訊息與筆記會送到使用者設定的 LLM 供應商，而不是送到 Brevilabs；Plus 的特定檔案轉換功能在使用者明確觸發時可能由 Brevilabs 處理。這些條款可能更新，所以每次導入真實資料前都要重讀當前揭露。

AI 建議：先用公開技術文件、讀書筆記或自己寫的示範資料。不要用真實病人、客戶、公司內部文件、未公開專案、私人信件或憑證測試雲端問答。

• 步驟 1：新增供應商金鑰，確認金鑰沒有出現在任何 Markdown 檔。
• 步驟 2：選定聊天模型，輸出長度先保持適中。
• 步驟 3：只附加一篇已知內容的筆記。
• 步驟 4：要求列出使用的筆記名稱與資料不足處。
• 步驟 5：逐句回到原始筆記核對，再擴大到資料夾或 Vault。

8. 路線 B：用 Ollama 建立本機聊天與可選的語意嵌入

Ollama 可在 macOS、Windows 或 Linux 執行本機模型。以下用 qwen3:4b 作為較小的多語言聊天模型示例，並用 embeddinggemma 作為語意搜尋示例；它們不是唯一或保證最佳的選擇。模型下載大小、執行記憶體、速度與回答品質都會依模型量化、硬體和上下文長度改變。

先安裝並更新 Ollama，再下載模型。若 Ollama 桌面程式已經啟動服務，不必重複執行 ollama serve；可用 ollama ls 確認已下載模型，用 ollama ps 檢查執行中的模型。

在 Copilot 新增自訂模型時，優先選擇原生 Ollama provider 並填入與 ollama ls 完全相同的模型名稱。若外掛只提供 OpenAI-compatible 欄位，Ollama 官方相容端點是 http://localhost:11434/v1/，API key 欄位可填 ollama；官方說明此值為相容性所需但會被忽略。

只有在基本 Vault 搜尋通過後才新增 embeddinggemma 並開啟 Semantic Search。Ollama 官方建議索引與查詢使用同一個嵌入模型；切換嵌入模型後，應在 Copilot 內強制重建索引。

9. 第五步：先縮小檢索範圍，再決定是否需要 Semantic Search

向量嵌入會把文字轉成數值向量，用來尋找語意相近內容。它適合處理同義詞、不同說法與較模糊的問題，但不是越早開越好：索引可能過期、相似內容可能被誤選、不同嵌入模型的向量也不能直接混用。對新手而言，最穩定的順序是目前筆記、指定多篇筆記、指定資料夾、Vault 智慧搜尋，最後才是整庫語意搜尋。

AI 推論：多數『模型答錯』其實先發生在檢索階段。先檢查模型看到了哪些筆記，再決定要不要換聊天模型；若來源本身找錯，換成更大的模型也可能只是把錯誤講得更流暢。

語意搜尋啟用後，每次新增或大量修改筆記都要確認索引是否更新。更換嵌入模型、維度或供應商時，直接重建索引，不要沿用舊向量。

10. 第六步：把提示詞寫成回答契約，強制區分筆記事實、推論與建議

提示詞無法保證模型完全遵守，但可以把驗收條件寫清楚。重點不是堆疊華麗角色設定，而是限定資料來源、要求回傳筆記名稱、允許回答不知道，並把來源事實、模型推論與下一步建議分開。每次開始新的 Wiki 問答時，都可把以下模板貼入自訂提示或對話開頭。

11. 第七步：用五個驗收測試，判斷你的 Wiki 是否真的可用

不要只用『感覺回答不錯』驗收。先建立一組你知道答案的測試筆記，記錄問題、預期來源、實際來源與結果。每次更換聊天模型、嵌入模型、外掛版本或索引設定，都重新跑同一組案例。這是把 AI 玩具變成可維護系統的分水嶺。

12. 常見卡關：先看來源與索引，再懷疑模型不夠大

找不到筆記時，先確認附加範圍、排除規則、檔名與資料夾，再檢查索引狀態；Copilot 文件建議可用 Force Re-Index 或列出已索引檔案排查。回答超出內容時，縮小到單篇筆記並使用『找不到就明說』的提示。發生 token limit 時，先減少附加資料與輸出長度，而不是直接提高最大輸出。

Ollama 連不上時，依序確認 ollama ls 能看到模型、ollama ps 或應用程式顯示服務運作、模型名稱完全一致、Base URL 指向 localhost。CORS 錯誤應依 Copilot 當前本機指南設定允許來源；不同作業系統的設定方式不同。

更換嵌入模型後結果混亂時，停止查詢、清除舊索引並完整重建。Copilot 的 FAQ 明確警告不要在既有索引上直接切換 embedding model。

外掛更新後畫面或功能不同時，先查看 Releases。社群外掛不會自動更新，因此『我沒有動設定』不代表環境沒有版本落差。

• 答錯但引用正確：檢查筆記措辭、來源衝突與提示詞。
• 答錯且引用錯誤：優先修正範圍、搜尋與索引。
• 完全找不到：檢查檔案是否被排除、索引是否完成、檔名是否一致。
• 本機速度太慢：縮小模型、縮短上下文、先關閉 Semantic Search。
• 設定愈改愈亂：回到單篇筆記、單一模型、無語意索引的最小基線。

13. 十四天上手路線：每天完成一個可驗證的小成果

不要把知識管理、雲端模型、本機模型、向量資料庫與自動代理一次全部打開。用十四天把資料層、問答層與驗證層分開完成；任何一天的成果都應是可看見、可還原、可測試的小步驟。

第十四天的完成定義：你有至少二十篇結構一致的示範筆記、一頁 MOC、一份備份、可限定範圍的問答、一組五題驗收紀錄，以及清楚知道目前內容會送到哪裡。是否開啟本機模型或 Semantic Search，反而是次要決定。

AI 建議：之後每週安排十五分鐘清理 Inbox、修正失效來源、更新過時日期、檢查外掛更新並抽查備份可還原性。

• 資料層先穩定：筆記即使沒有 AI 也能被搜尋、連結與備份。
• 問答層可替換：雲端或本機模型都不應綁死你的 Markdown 資料。
• 驗證層持續存在：任何新模型與新外掛都必須重新跑來源回查測試。