LLM Wiki 理論篇 part01 | Karpathy 的 LLM Wiki 是什麼？和 RAG 到底差在哪裡？

關於「LLM Wiki 理論篇」

目前我正在製作一個 Knowledge Engine，完成後會整理成開源專案。

這套系統依照 Google Open Knowledge Format（OKF）v0.1 Draft 組織知識，結合 LLM Wiki 的持久知識層與 RAG 的檢索能力，再透過控制層（Harness）規定 AI 如何搜尋、閱讀、驗證來源與組合答案。

人類可以透過 Obsidian 閱讀和維護知識頁，也能使用 Sigma.js 查看知識之間的關聯。

這個小系列分成兩篇。第一篇談 LLM Wiki 為什麼出現，以及它和 RAG 的差異；第二篇再拆解 OKF、Markdown、Obsidian、Sigma.js、搜尋索引與 Harness 各自負責哪一層。

假設你手上有一百份文件。

裡面有研究報告、產品規格、訪談、會議紀錄、PDF 和零散筆記。你把它們放進一套文件問答系統，接著開始提問：

某份合約的終止日期是哪一天？
客戶最常遇到的問題是什麼？
過去半年，產品策略出現過哪些互相矛盾的判斷？
A 報告的結論，是否被後來的 B 和 C 推翻？

這些問題都需要查文件，難度卻完全不同。

找出合約日期，通常只需要定位一段文字。比較數份報告的假設、定義和結論，則要同時處理多份來源、時間差異和互相衝突的資訊。

前者主要是檢索問題。

後者已經接近一項小型研究工作。

Karpathy 提出的 LLM Wiki，主要處理的是第二類問題。

LLM Wiki 是一種知識架構

2026 年 4 月，Andrej Karpathy 發布了一份名為〈LLM Wiki〉的 Gist。他將它描述為一種使用 LLM 建立個人知識庫的架構模式，而不是一套已完成的軟體。

它沒有規定必須使用哪個模型、向量資料庫、圖資料庫或 Agent framework。Obsidian、BM25、向量搜尋和 Git 都可以成為其中的零件，但不是 LLM Wiki 本身。

Karpathy 關心的是一個很實際的問題：

模型每次回答問題時，都重新從原始文件裡找資料、理解內容，再臨時拼出答案。這些整理成果為什麼不能留下來？

一般文件問答系統常把最後的比較和判斷留在聊天紀錄裡。下一次遇到相似問題，系統又重新搜尋、重新閱讀、重新整理。

LLM Wiki 在原始文件和使用者之間，加入一個由 LLM 持續維護的知識層。

新資料進來時，Agent 不只建立搜尋索引，也可能：

建立來源摘要
更新既有概念頁
補上人物、公司或事件頁
記錄新資料支持或反駁了哪些舊結論
保存值得重用的比較與分析
建立知識頁和原始來源之間的連結

最後留下來的不只有一次回答，而是一批可以繼續閱讀、修改和查詢的知識頁。

三層架構：來源、Wiki 與 Schema

Karpathy 將 LLM Wiki 分成三層。

Raw sources：保存原始證據

這一層放原始文章、論文、圖片、資料檔和其他來源。

LLM 可以閱讀它們，但不應任意修改。Wiki 裡的內容若有問題，人類和 Agent 必須能回到原文，確認是摘要過度、漏掉條件，還是把不同概念錯誤合併。

沒有原始來源，Wiki 很容易變成一批無法驗證的二手敘述。

Wiki：保存整理過的知識

Wiki 是一組由 LLM 建立和維護的知識頁，可以包含：

來源摘要
人物、公司和事件
概念與定義
時間線
多份來源的比較
互相矛盾的觀點
尚未確認的問題

新增一份資料時，Agent 不一定只新增一篇摘要。它也可能修改現有頁面、補上一項新證據，或將舊結論標示為過期。

先前完成的整理，因此能被後續查詢重用。

Schema：規定 Agent 怎麼工作

Schema 可以是一份 AGENTS.md、CLAUDE.md 或其他操作規則，告訴 Agent：

檔案如何命名
每種頁面有哪些欄位
什麼時候建立新頁面
什麼時候更新舊頁面
如何保存來源和引用
遇到矛盾時怎麼處理
哪些分析值得寫回 Wiki
如何找出孤立、過期或缺少來源的頁面

缺少這一層時，LLM 只是在資料夾裡自由發揮。資料量小時看不出問題，頁面增加後，命名、格式和引用方式很快就會分裂。

Schema 將一般聊天模型變成受規則約束的知識維護者。

常見 RAG 做了什麼？

RAG 是 Retrieval-Augmented Generation 的縮寫，通常翻譯為「檢索增強生成」。

它的基本概念是：模型回答問題前，先從外部資料找回相關內容，再把這些內容放進 context。

原始文件
   ↓
切成段落
   ↓
建立搜尋索引
   ↓
收到問題
   ↓
找出相關段落
   ↓
交給 LLM 產生答案

現代 RAG 還可能加入關鍵字與向量混合搜尋、重新排序和多步查詢。因此，RAG 不能被簡化成「只用向量找幾個 chunks」。

本文比較的是常見的文件問答型 RAG。這類系統主要保存：

原始文件
切分後的段落
metadata
關鍵字或向量索引

它通常不會把每次查詢產生的比較、結論和知識整理，自動變成一個長期維護的主要知識層。

LLM Wiki 多保存了這一層。

差異在於知識何時被整理

常見 RAG 主要在收到問題後組合資訊。

文件 → 索引

問題 → 找段落 → 臨時理解與組合 → 答案

LLM Wiki 會在資料進入系統和日常維護時，先完成一部分整理。

文件
  ↓
閱讀、比對與整理
  ↓
知識頁、來源與關聯
  ↓
搜尋與索引

問題 → 找知識頁 → 補讀來源與相關頁面 → 答案

這不是絕對分界。

進階 RAG 也能在索引階段建立摘要、階層結構或實體關係。LLM Wiki 比較明顯的特徵，是將整理結果保存成人類和 Agent 都能直接閱讀、修改和長期維護的知識層。

一個例子：WAU 增加 18%，代表產品變好了嗎？

假設知識庫裡有三份文件：

產品指標規格
每週營運報告
新版埋點遷移文件

營運報告寫著：

本週 WAU 增加 18%。

如果系統只找到這一段，很容易回答：

使用者活躍度明顯提升。

但埋點遷移文件可能同時寫著：

從 7 月 1 日起，WAU 從「完成登入」改成「完成核心操作」才計算。

兩個時期採用的定義不同，18% 不能直接代表使用者真的變得更活躍。

一般 RAG 需要在這次查詢中，同時找回營運報告和定義變更文件。

LLM Wiki 則可能已經保存：

WAU 指標頁
舊版與新版的活躍使用者定義
指標變更時間線
埋點遷移事件
指向原始文件的引用

Agent 找到 WAU 頁後，可以沿著關係繼續檢查定義、版本和來源。

這種結構不會替 Agent 自動得出正確答案，但能提醒它還有哪些內容不能漏看。

LLM Wiki 仍然需要 RAG

知識被整理成 Wiki 後，Agent 仍要找到合適的頁面。

資料量小時，可以先閱讀 index.md，再沿著連結導航。資料量增加後，仍可使用：

全文搜尋
BM25
向量搜尋
reranking
graph traversal

原始來源
    ↓
知識編譯
    ↓
Wiki 頁、metadata、引用與關聯
    ↓
關鍵字索引、向量索引與圖索引
    ↓
Agent 搜尋與閱讀
    ↓
回到原始來源驗證
    ↓
回答

向量搜尋適合找出語意相關的候選頁面。

BM25 適合處理專有名詞、錯誤碼、版本號和精確名稱。

圖結構則能補充「相關」之外的資訊，例如：

某個指標由哪個定義決定
某份規格已被哪個版本取代
某項結論由哪些來源支持
某項決策依賴哪些條件

LLM Wiki 沒有淘汰 RAG。它讓 RAG 可以搜尋和導航更完整的知識結構。

一張表看懂主要差異

面向	常見文件問答型 RAG	LLM Wiki
主要保存內容	文件、段落和索引	知識頁、關聯、來源和索引
常見檢索單位	段落或 chunk	頁面、段落、概念及其關聯
知識整理時間	多在查詢時	資料進入、維護和查詢時
跨來源分析	每次重新處理	可以保存並持續更新
人類可讀性	索引多為系統內部資產	知識頁本身可以閱讀
主要風險	找錯內容、排序錯誤、context 不足	摘要失真、頁面過期、錯誤關聯累積
維護成本	檢索管線和索引	再加上頁面、引用和知識生命週期

成熟的 Agentic RAG 也能執行多步查詢、保存 memory 和建立結構。

反過來說，一個沒有可靠來源和維護規則的 Markdown Wiki，也不會因為多了幾條連結就變得可信。

LLM Wiki 會怎麼失敗？

LLM Wiki 會將原始內容整理成較短、較容易使用的知識頁。這個過程一定存在資訊損失的風險。

摘要漏掉條件

原文可能寫：

在樣本少於 500、沒有控制季節性，並排除特定產業的情況下，A 與 B 呈現相關。

Wiki 最後若只留下：

A 與 B 有相關性。

句子更短，重要限制也一起消失。

不同概念被錯誤合併

兩個團隊都使用「活躍使用者」，一個以登入計算，另一個以完成交易計算。

如果 Agent 把它們合併成同一個定義，後續分析可能讀起來很順，結果卻是錯的。

舊結論沒有失效

系統若只會新增內容，不會追蹤取代、過期和有效時間，Wiki 裡就可能同時存在數個看起來都正確的版本。

因此，可靠的 LLM Wiki 不能只保存頁面之間的連結，也要保留回到原始來源的證據路徑。

什麼情況值得建立 LLM Wiki？

情況	較適合的方式
從文件找一個明確日期或數字	RAG
文件會反覆查詢，但彼此關係不複雜	RAG 或查詢快取
需要跨多份來源比較，而且結果值得保存	LLM Wiki
同一批知識會持續加入新資料	LLM Wiki
需要追蹤定義、版本、來源和失效關係	LLM Wiki 加圖與 Harness
資料量小，可以直接放進模型 context	長 context 可能更簡單

實際系統通常會採取混合架構：

原始來源
   ├── RAG：找回精確段落
   └── LLM Wiki：保存概念、比較與跨來源整理
                     ↓
           Agent 根據問題選擇路徑
                     ↓
             回到來源驗證答案

Wiki 提供地圖，RAG 在需要時挖出原文。

結語

RAG 讓 LLM 在回答問題時取得外部資料。

LLM Wiki 再增加一個持久知識層，讓摘要、概念、比較、矛盾和關聯不必在每次查詢時重新建立。

它換來知識重用，也帶來新的維護責任。系統除了檢索品質，還要處理：

摘要是否失真
概念是否重複或混淆
頁面是否過期
關係是否正確
結論是否能回到來源
Agent 是否有過大的修改權限

LLM Wiki 值不值得做，可以先問一個實際問題：

同一批知識，未來還會不會被反覆研究、比較和重新使用？

如果不會，一套好的 RAG 通常已經足夠。

如果會，每次查詢都重新從原始文件開始整理，可能才是成本更高的選擇。