LLM Wiki vs RAG

兩者都解決「如何讓 LLM 存取外部知識」，但 underlying mechanism 差距極大。

知識表示方式 — 最根本的差異

• RAG：text → embedding model → vectors。儲存在向量資料庫，人類無法解讀。
• LLM Wiki：text → LLM → structured markdown + [[wikilinks]]。人類可直接閱讀、修正、學習。

這是兩種完全不同的中間產物：一個是數字，一個是人類語言。

人類可解釋性

Wiki 的極大優勢：中間產物可被人類解讀。

• 每個 claim 可追溯到具體 .md 檔案
• 發現錯誤時，打開檔案改一行就好
• 向量資料庫出錯時，無法理解錯誤來源，更無法直接修正
• Wiki 不只是給 LLM 用的 — 人類自己也能從中學到東西

處理模式

兩者 ingest 和 query 都需要 LLM，成本結構類似，但產出不同：

	RAG	LLM Wiki
Ingest	text → vectors（機器用）	text → markdown（人機皆用）
Query	similarity search → chunks → LLM 合成	讀 index → 讀相關頁面 → LLM 合成
知識累積	無，每次從零開始	有，wiki 是 compounding artifact

本質上是 write-time-vs-read-time-compute 的不同選擇。

真正的成本差異

可解釋性是優勢，但也帶來成本：Wiki 絕對需要人類審查。LLM 生成的頁面可能有錯誤、遺漏、或不符合你的理解，你必須花時間讀、檢查、修正。這是 RAG 沒有的成本 — RAG 的中間產物（vectors）人類反正看不懂，也不需要審查。

所以 trade-off 是：

• Wiki：人類可解釋 → 人類必須審查 → 成本較高，但品質可控
• RAG：人類不可解釋 → 無法審查 → 成本低，但品質是 black box

選擇 wiki 就是選擇用人類時間換品質和可控性。

各自適用範圍

• Wiki 勝出：個人知識庫、~100 sources、需要深度合成、人類想參與審查
• RAG 勝出：大規模（數千文件）、頻繁變動、不需要人類審查中間產物
• 混合（GraphRAG）：用 knowledge graph 保留結構化關係，同時支援大規模檢索

規模臨界點

~50,000-100,000 tokens 左右，wiki 的 index 無法塞進 context window，需要引入檢索層。此時兩種方法開始趨同。