知識庫新革命：從 RAG 走向 Andrej Karpathy 的 LLM Wiki
在生成式 AI 與大型語言模型（LLM）爆發的時代，為 AI 代理（Agent）構建一個高效、可信任的知識庫，已成為企業與個人開發者的核心課題。
過去幾年，**RAG（Retrieval-Augmented Generation，檢索增強生成）**一直是建構 AI 知識庫的黃金法則。然而，2026年4月初，OpenAI 聯合創辦人、前 Tesla AI 總監 Andrej Karpathy 在社交平台 X 上分享了他的全新嘗試，並釋出了一份概念設計的 GitHub Gist，迅速在 Hacker News、Substack 及整個 AI 社群引爆熱烈討論。
Karpathy 提出了 一個極具顛覆性的核心主張：「不要做 RAG，改做 wiki。」（“Don’t do RAG, build a wiki.”）
本文將深入探討 RAG 與 Karpathy 倡導的 LLM Wiki 技術、兩者的底層邏輯與優劣對比，並手把手教你如何導入與使用 LLM Wiki，幫助你打造具備「持續複利」能力的個人或企業 AI 知識中樞。
一、 RAG 技術介紹與使用方式
1. 什麼是 RAG（檢索增強生成）？
**RAG（Retrieval-Augmented Generation）**是一種結合「資訊檢索系統」與「大語言模型（LLM）」能力的 AI 技術架構。
傳統的 LLM 雖然擁有強大的語言理解與推理能力，但其回答完全受限於預訓練數據。這會導致兩個致命缺點：
- 知識落差與時效性限制：模型無法即時得知訓練截止日之後的新資訊。
- AI 幻覺（Hallucination）：當面對未知的專業領域或私有數據時，模型容易編造出通順卻不準確的錯誤資訊。
RAG 的出現完美彌補了 LLM 的劣勢。它的運作就像是「開書考試」：當使用者提出問題時，系統先從外部知識庫（如向量資料庫、文檔庫）中檢索出與問題最相關的內容，然後將這些「課本內容」與原始問題一起打包，提供給 LLM 作為上下文背景，讓 LLM 據此生成可靠且精準的回答。
2. RAG 的核心運作架構
一個完整的 RAG 管道主要包含以下三個階段：
- 📘 索引（Indexing）： 將原始非結構化文件（如 PDF、Word、技術手冊等）進行分塊（Chunking），利用 Embedding 模型將這些分塊轉換為高維度的語義向量，並儲存至向量資料庫（如 Pinecone、pgvector 等）中。
- 📘 檢索（Retrieval）： 當用戶提問時，系統同樣將問題轉換為向量，並在向量資料庫中進行語義相似度計算（如餘弦距離），快速撈出前 K 個最相關的文本片段。
- 📘 生成（Generation）： 將檢索到的文本片段融入 Prompt，引導 LLM 在限制範圍內生成流暢、附帶來源依據的回答。
3. RAG 的主流分類
隨著技術演進，RAG 在企業端的應用已分化為以下三種主流架構：
- Vector RAG（向量型）： 最基礎且入門門檻低的架構，主要將 PDF、Word 等非結構化文檔向量化後進行語義比對。適合 FAQ、內部一般文檔檢索，但在面對複雜的關聯查詢時精度較低。
- Graph RAG（圖譜型）： 針對結構化或半結構化資料（如財務報表、供應鏈、生產紀錄）設計。它會將實體、概念及其關係轉化為「語意式圖資料結構」（Semantic Graph），讓 LLM 能夠進行高精度的「多跳推理」（Multi-hop Reasoning），大幅降低幻覺，適合決策精度極高、零容忍幻覺的專業領域。
- Hybrid RAG（混合型）： 結合 Vector RAG（右腦，處理非結構化文字）與 Graph RAG（左腦，處理結構化資料）的混合架構，能同時查詢 ERP/CRM 等結構化系統與 PDF 手冊，提供最完整全面的商業洞察。
二、 什麼是 Karpathy 的 LLM Wiki？
1. 「編譯」而非僅僅「檢索」
Andrej Karpathy 提出的 LLM Wiki 模式與 RAG 存在本質上的哲學分歧。
RAG 的檢索是 「無狀態、臨時性（Stateless & Transient）」 的。每次用戶提問，系統都要重新從海量 raw 文檔中搜索片段、拼湊答案。這種模式下，AI 的知識沒有真正地沉澱與累積。
而 Karpathy 的核心主張是把 LLM 當作一個「編譯器（Compiler）」。 新資料（Raw Sources）進來後，LLM 不僅僅是將其向量化，而是去讀懂、摘要、分類、交叉連結，將這些碎片化的知識「編譯」並「增量寫入」到一座結構化的 Markdown 知識庫（Wiki）中。
- Obsidian 是 IDE（人用來瀏覽與思考的介面）
- LLM 是寫程式的人（負責編譯、更新與維護 Wiki 的代筆者）
- Wiki 就是程式碼庫（持續維護、可版本控制的持久化資產）
「Wiki 是一個持久的、會累積的產物。交叉引用已經建好了，矛盾已經被標出來了。」 —— Andrej Karpathy
2. LLM Wiki 的三層核心架構
LLM Wiki 主要是由以下三層緊密配合所組成的極簡系統：
- 🔹 raw/（原始素材層）： 唯讀的原始文檔、網頁剪藏、論文或音檔逐字稿。這是系統的「不變事實來源（Source of Truth）」。
- 🔹 wiki/（編譯知識層）： 由 LLM 全權維護的結構化 Markdown 文件目錄，包括概念頁、實體頁（人、公司、項目）、主題頁以及一個全局索引文件（
index.md）和日誌檔案（log.md）。人類基本上不直接編輯這層。 - 🔹 Schema/規則憲法層（如 CLAUDE.md 或 AGENTS.md）： 控制 LLM 運作的最高憲法。明確定義了命名規範、引用規則、矛盾處理流程、健檢流程等。它是讓 LLM 從「胡思亂想的聊天機器人」轉化為「有紀律的 Wiki 檔案管理員」的關鍵。
3. LLM Wiki 作為 AI 代理的「長期記憶（Long-term Memory）」
在 Agentic AI（代理人工智慧）架構中，LLM Wiki 扮演著極致的長期記憶角色。它可以完美映射並支持以下多種記憶功能：
- 語義記憶（Semantic Memory）： 儲存跨來源提煉出的事實、概念與大趨勢（如
trends/目錄）。 - 實體記憶（Entity Memory）： 記錄人、項目、組織等實體及其相互關係（如
speakers/、projects/目錄）。 - 情節記憶（Episodic Memory）： 透過
log.md保存每一次匯入、查詢、變更的歷史軌跡。 - 程序記憶（Procedural Memory）： 將
AGENTS.md規則作為 Agent 維護與自動更新知識庫的行為準則。
三、 RAG 與 LLM Wiki 的深度對比
為了幫助你釐清兩者的設計取捨，我們從六個關鍵維度進行 side-by-side 的對比：
| 評估維度 | RAG (檢索增強生成) | LLM Wiki (知識編譯模式) |
|---|---|---|
| 底層技術複雜度 | 高：需要配置 Embedding、向量資料庫、Chunking 策略及 Reranking 檢索管線。 | 低：完全基於標準檔案系統（如 Markdown）與 LLM 讀寫能力，無須資料庫運維。 |
| 時間維度與狀態 | 無狀態 (Stateless)：每次查詢臨時拼湊，知識無法累積與複利。 | 有狀態 (Stateful)：一次編譯、持續增量維護，知識庫隨時間「滾雪球」式增長。 |
| 檢索精準度 | 語義相似度 (相似但不精準)：依賴向量餘弦距離，容易受到模糊語句干擾，可能遺漏結構（如表格）。 | 結構與意圖導向 (極精準)：LLM 透過目錄或索引直接路由到正確文檔，保留完整表格與層級結構。 |
| 版本控制與審計 | 黑盒子：難以直接對向量庫進行 Git 版本控制與 Change Log 審查。 | 原生友好：純 Markdown 檔案，可直接進行 Git 版控、Diff 對比與人工安全審計。 |
| 適用資料規模 | 海量規模 (無上限)：適合數萬篇、PB 級以上的異構、非結構化歷史存量資料。 | 中小規模 (~100-1000篇)：受限於 LLM 的 context window 與編譯成本（通常40萬字內表現最佳）。 |
| 抗腐化與幻覺性 | 中：容易受到 Chunk 斷章取義或檢索雜訊影響，引發二次幻覺。 | 高：在 Ingest 階段即由 LLM 進行新舊矛盾偵測，將衝突在寫入時予以標記與阻斷。 |
決策框架：何時該選 RAG？何時該選 LLM Wiki？
- 選擇 LLM Wiki 的情境： 你的知識庫規模在 1000 篇文檔以內，資料結構化程度高（如 SOP、政策、FAQ、產品定價表），需要極高的準確性與可驗證性，希望能夠輕鬆實施 Git 版本管理，且工程開發資源有限。
- 選擇 RAG 的情境： 你的資料量龐大且高度雜亂（如數萬封歷史客服郵件、龐大的學術論文庫、法規大庫），用戶查詢方向極度隨機且不可預測。
- 黃金複合模式 (Hybrid Approach)： 在實際生產環境中，領先的 AI Agent 往往採用混合架構——將核心 SOP、當前最佳產品定價置於 LLM Wiki（確保 100% 準確路由），而將龐大的歷史存檔、使用者日誌放在 RAG（解決長尾搜索需求），由最上層的 Routing 模組分流。
四、 LLM Wiki 要怎麼導入與使用？
如果你想立刻動手打造屬於自己的 LLM Wiki，社群裡目前已經累積了許多優秀的開源模版。以下以目前社群最完整、最適合「生產者兼消費者」的開源範本——范凱的 llm-knowledge-base 架構為基礎，為你拆解導入步驟與操作方法。
1. 建立標準資料夾結構
在你的本地端（通常推薦搭配 Obsidian）建立以下目錄結構：
my-llm-wiki/
├── CLAUDE.md # 核心憲法：規範 LLM 行為的最高規則檔
├── raw/ # 原始素材庫（唯讀），放置你剪藏的網頁、PDF 或論文
├── wiki/ # LLM 編譯的結構化知識庫
│ ├── index.md # 全局目錄，每篇筆記一行摘要，用於快速路由
│ ├── log.md # 匯入、健檢與變更的活動日誌
│ ├── concepts/ # 核心概念主題頁
│ └── entities/ # 人物、公司、項目等實體頁
├── brainstorming/ # 探索與討論紀錄，存放你與 LLM 進行深度思考的草稿
└── artifacts/ # 最終產出，如以此 Wiki 為底蘊編寫出來的文章、簡報、報告2. 撰寫最高憲法 CLAUDE.md (或 AGENTS.md)
這是整個系統運作的靈魂，你必須明確指示 LLM 在扮演「Wiki 檔案管理員」時要遵守哪些原則。以下是必備的**「防腐化規則」**：
# Wiki Maintenance Rules (CLAUDE.md)
1. **增量編譯而非默默覆蓋**：當 raw/ 有新文件匯入時，比對 wiki/ 現有頁面。若發現資訊衝突或矛盾，禁止直接覆蓋，必須在 wiki 頁面頂端插入 `!!! CONTRADICTION` 標籤，並記錄於 `log.md`，交由人類決策。
2. **嚴格的來源追溯 (Source Lineage)**：在 wiki/ 生成的任何結論或斷言，必須在末尾以角括號標註原始 raw 文件的連結（例如：[raw/paper-01.md]），絕不允許無來源的幻覺。
3. **區分事實與推論**：客觀事實（Raw 記載）與 AI 的推理或外推結論必須明確分開（例如：使用 > [!NOTE] 區隔）。
4. **概念收斂與原子化**：定期掃描，如果某一概念在多個頁面被反覆提及超過 3 次，應主動建議在 `concepts/` 下為該概念新建獨立的 wiki 頁。3. LLM Wiki 的四個核心工作流 (Closed Loop)
要讓你的 LLM Wiki 持續增值、避免退化，你必須定期或在工作流中運行以下四個核心動作：
🚀 第一步：匯入與編譯 (Ingest & Compile)
當你透過 Web Clipper 或手動將新資料丟進 raw/ 後，呼叫 AI Agent 工具（如 Claude Code 或基於 CLI 的 API 腳本）執行：
- LLM 動作： 閱讀
raw/new-doc.md-> 檢查wiki/index.md與現有檔案 -> 修改/更新/新建對應的 5~10 個 wiki 頁面 -> 自動在index.md補上新的條目摘要 -> 將此次變更計入log.md。
🚀 第二步：查詢與檢索 (Query & Retrieve)
當你需要向知識庫提問時，Agent 不用去掃描數百個檔案。
- LLM 動作： 優先加載
wiki/index.md（包含所有頁面的標題與單行摘要，體積極小、節省 token） -> LLM 決定哪 2-3 個主題文件與你的提問最相關 -> 精準加載該 2-3 個文件進行全面解答。這種「漸進式披露」能把 Token 消耗壓到極低。
🚀 第三步：高值問答回寫 (File Back)
我們每天與 LLM 聊天、Brainstorming 時，經常會誕生極具價值的洞察、程式碼片段或商業企劃。如果只留在對話歷史中，這些知識便死去了。
- LLM 動作： 定期整理對話中的精華結論，將其整理為 Markdown 格式，自動寫回
wiki/concepts/或新開專案檔案。讓每次提問與對話的結果在知識庫中沉澱並持續複利。
🚀 第四步：自動健康檢查 (Lint & Health Check)
這是 Karpathy 最推崇的自動化機制。你可以設定排程（如每週一次）讓 Agent 在後台自主運行 Lint PASS：
- LLM 動作： 遍歷整個 wiki 檔案系統 -> 尋找孤立頁面（沒有任何連結指向它） -> 尋找損壞的雙向連結 -> 發現知識矛盾 -> 尋找概念缺口（例如：「偵測到你在 5 篇不同的 raw 素材中提到了『Agent Long-term Memory』，但你目前沒有專屬的 Wiki 頁，建議建立！」）。
結語：人機協作的最終形態
傳統的知識管理工具（如 Notion、Roam Research、Obsidian）都把「整理與維護」的苦工甩給了人類。許多人最終放棄使用「第二大腦」，不是因為沒有毅力，而是因為知識庫的維護成本增長速度，遠遠超過了它能帶來的價值。
Karpathy 的 LLM Wiki 模式徹底顛覆了這一點。它將繁瑣的 bookkeeping、交叉鏈接、排版、甚至矛盾檢查，通通交給了不知疲倦、擅長模式匹配的 LLM；而將**「篩選優質素材、定航研究方向、提出好問題、思考事物的本質與意義」**等最核心的智慧工作，留給了人類。
現在，不妨花半個小時，建構起你自己的第一個極簡 LLM Wiki 目錄，把最近手邊的研究素材丟進去，體驗一場由 LLM 擔任有紀律維護員的「知識複利之旅」吧！
