LLM Wiki 與 RAG 的差異

← 總索引

討論「個人知識庫 LLM Wiki 移植為團隊使用」時整理出的理解，記錄 DragonsHoard 採用的 LLM Wiki 模式跟業界常見的 RAG（檢索增強生成，如 Glean、Notion AI、Confluence Rovo）架構本質上差在哪。跟知識庫建設哲學的差異：那頁記的是毓文個人的設計信念，這頁記的是 LLM Wiki 這個模式本身相對於另一種主流做法的技術定位，屬於一般性理解、不限於 DragonsHoard 這個實例。

兩者各自賭在哪裡

RAG 賭的是檢索演算法夠準。寫入端幾乎不做事——文件丟進去，切段落（chunking）、算向量（embedding）、存進向量資料庫，原始內容長什麼樣就是什麼樣，沒有人重寫、去重、拉關聯。查詢時把問題也轉成向量，撈語意最接近的段落塞進 context。回答品質完全取決於「切得好不好、embedding 準不準、原始文件本身乾不乾淨」——如果來源裡本來就有三份互相矛盾的舊文件，RAG 照樣把三份都撈出來，不會先幫你解決矛盾。

LLM Wiki（DragonsHoard 這套）賭的是內容本身先被整理乾淨。真正費工的動作發生在 Ingest 那一步——AI 跟使用者討論、判斷這筆內容以後會不會被想起來、寫進哪個分類、跟既有頁面矛盾要標注、要不要互相連結，Lint 還會回頭抓矛盾跟過期內容主動清掉。查詢時 AI 靠的不是向量相似度，是「檔案系統操作」——讀 index.md、grep frontmatter 的 tags、開實際檔案，走的是人類（跟 AI）事先設計好的導航結構，不是統計上的語意接近。

具體後果

維護機制的有無：RAG 沒有「維護」這個概念，語料只會累積、不會被主動清理；LLM Wiki 的「持續運作」（lint／archive／raw 保護，見觸發機制演變「九」、架構與流程「十二」）在 RAG 世界裡沒有對應機制。
失敗模式不同：RAG 的失敗模式是「切錯段落、撈錯內容」，出在 chunking/embedding 策略；LLM Wiki 的失敗模式是「結構設計得不好、AI 找不到路」，出在 index/wikilink 設計。
「知識庫≠資料庫」是分道揚鑣的起點：RAG 不需要先把資料整理成知識才能查，來什麼就丟進去；LLM Wiki 的核心命題是資料要先被篩選、結構化才算真正進庫。

兩者不互斥

實務上常見混用：大量、非結構化、沒空人工策展的語料用 RAG 撈；少量、高價值、需要長期維護正確性的核心知識走 LLM Wiki 這種策展式的路。業界的知識庫 AI 產品（Glean、Notion AI、Confluence Rovo 等）多半走 RAG 路線，因為要覆蓋的來源系統又多又雜，不可能逐篇策展；LLM Wiki 適合規模小、單一使用者或小團隊、內容值得被慢慢養的場景。

移植團隊使用時的斷點

個人版 LLM Wiki 假設「單一使用者、AI 可以直接拿到完整檔案/bash 存取權限」，團隊化時這個假設會斷：wiki 開放直接編輯的前提（沒有需要保護的對象）不成立，Query 若要保留 AI 參與，得把讀（可以放心給所有人）跟寫（要收在少數維護者手上）分開，讀的一端可以用 MCP server 或自建 API 工具層架給團隊共用。真的要做時再展開細節。

什麼時候會需要向量搜尋

整場「該不該導入 qmd（本機 BM25＋向量混合檢索）」的討論最後把問題拆成兩條獨立的軸，過程見觸發機制演變「四十三」：

成本軸（AI 讀進的 context 會不會爆）：有機械解，不需要向量搜尋。候選集合出爐、開檔案精讀前先量總位元組數、跟預算比較，直接量測目標資源本身；只要導航結構還能有效收斂候選，候選集合大小就不會隨知識庫總量長大而失控，任何規模下都不需要向量搜尋。
正確性軸（結構找不找得到答案）：有制度解，也不需要向量搜尋。真正的領先指標不是「wiki 變大」，是語意路徑（index 範圍宣告／頁面摘要／wikilink）持續找不到答案、答案持續要靠全文 grep 保底補救，變成常態而不是例外——這代表導航結構已經失去存在意義：已經在做 RAG 該做的事（關鍵字比對找內容），卻沒有 RAG 的效率（持久索引、相似度排序）。這種失效該用「補策展」（補齊缺的交叉引用、範圍宣告）修，不是換檢索演算法——策展／可追溯性正是 LLM Wiki 存在的理由，換成 RAG 等於放棄這個理由。

單純「wiki 變大」不是觸發條件，qmd／向量搜尋要解決的是結構失效，不是內容量大。

RambleWiki

探索

llm-wiki-與-rag-的差異