AI Ark LLM Wiki

LLM Wiki：Karpathy 知識庫模式

Properties2
descriptionAI Ark 知識頁：LLM Wiki：Karpathy 知識庫模式。
tagsconcept, analysis, guide

閱讀時間約 9 分鐘

LLM Wiki：Karpathy 知識庫模式

由 andrej-karpathy（OpenAI 共同創辦人、前 Tesla AI 總監）提出的知識庫概念。核心思想是讓 AI 增量構建一個「持久化」的知識庫（Wiki），而非每次從零開始 RAG 檢索。

核心問題：RAG 的無積累困境

傳統 RAG（Retrieval-Augmented Generation）如 ChatGPT、NotebookLM：每次提問，AI 搜索文檔 → 抓取相關片段 → 臨時拼湊答案。問一個類似問題，全部重來。Nothing was saved. Nothing compounds.

解決方案：LLM Wiki

AI 讀取文檔 一次，建立結構化的 Wiki（互連的 Markdown 檔案）。新來源加入時，AI 不只是儲存，而是：

  • 讀取並提取關鍵概念
  • 整合進現有 Wiki：更新既有頁面、為新概念建立新頁面
  • 連結相關概念
  • 標註矛盾（若新來源與 Wiki 既有內容衝突）

隨著時間推移，Wiki 持續增長、越來越豐富。提問時 AI 基於已建構好的知識庫回答，而非從零搜索。

Karpathy 的類比

「把 Obsidian 想像成 IDE，LLM 是程式設計師，Wiki 是程式碼庫。你很少自己寫 Wiki，AI 負責寫和組織。你專注於放什麼進去、問什麼問題。」

三層架構

層內容特性
Raw Sources原始文檔（PDF、文章、會議記錄）唯讀，AI 不可修改
WikiAI 建立維護的 Markdown 頁面index、concept、entity、comparison 頁面，互相連結
Schema規則文件（CLAUDE.md）定義 wiki 結構、ingest 流程、格式規則

Schema 文件內容（CLAUDE.md）

  1. Purpose — 知識庫的主題（唯一需要客製化的行）
  2. Folder structure — raw/ 與 wiki/ 位置
  3. Ingest workflow — 讀文檔 → 萃取概念 → 建立/更新頁面 → 更新 index → 記錄異動
  4. Page formatting rules — 摘要置頂、每個主張引用來源、頁面間互相連結
  5. QA behavior — 優先查 Wiki、標註來源、不確定時明確告知

Linting（Wiki 健診）

定期請 AI 檢查 Wiki 健康度，類似程式碼 lint：

  • Contradictions — 頁面間的矛盾主張
  • Outdated claims — 過時資訊
  • Orphan pages — 無任何頁面指向的孤立頁面
  • Missing pages — 被提及但無獨立頁面的概念

Zettelkasten vs LLM Wiki：容器之爭

WenHao Yu（余文豪）在其分析中提出 LLM Wiki 與 Zettelkasten（卡片盒筆記法）的核心分歧 — 一張卡片到底是什麼？

維度Zettelkasten / LYTKarpathy LLM Wiki
單元原子概念（一張卡一件事）主題聚合（一張 page 裝主題 best-of）
分類決策邊界由概念本身決定，免分類須決定主題邊界、哪些 source 併進同一 page
優點歸檔不用多想打開一張就看到全貌
代價靠連結拼出主題全貌重現 folder/tag 時代的分類問題

「Evernote 時代你在問『這個筆記放哪個 folder』。Notion 早期你在問『這個頁面打哪些 tags』。Karpathy wiki 現在在問『這個 source 併進哪張 wiki page』。三個問題的形狀一模一樣：對一個新進來的東西，你要決定它屬於哪個容器。」

OKF：把 pattern 變成可攜標準

Google Cloud 後來提出 OKF（Open Knowledge Format），把 LLM Wiki 這個 pattern 標準化成 folder + Markdown + YAML frontmatter 的最小共同規則。

OKF 的重點不是改變 LLM Wiki 的核心思路，而是解決「每個人做出來的 wiki 都長得不一樣，換工具就不容易讀」這個可攜性問題。open-knowledge-format 把這層標準化整理成獨立概念。

Model Collapse 風險

HN 社群指出 LLM 反覆 ingest 自己寫的 wiki 可能造成 Model Collapse — 細節被磨平、風格單一化（Nature 2024 論文論證）。

Vibe Thinking 風險

「把整理外包 = 把思考外包」— 若只讓 AI 產出而不親自理解，wiki 看似有組織但人未內化。

使用情境

  • 學生／研究者：論文閱讀過程中累積結構化知識庫
  • 教師：累積課程資料與發展素材
  • 企業：會議記錄、客戶對話、專案文件 → 新人 onboarding 直接瀏覽 Wiki
  • 個人學習：書摘、Podcast、文章 → 自建百科全書

已知限制

  1. 適合個人規模（~100 篇文檔），大規模需要更多基礎設施
  2. Garbage in, garbage out — 必須策劃來源品質
  3. 需要 coding agent（Claude Code / Codex / Cursor）作為 AI 引擎
  4. AI 可能犯錯（誤分類、錯連結），需定期 lint

社群實作的取捨

AIHAO 對 2026 年 4–5 月 LLM Knowledge Base 熱潮的整理，把 Karpathy 原始 pattern 放到多個實作裡比較：Elvis Saravia / DAIR.AI 適合作為最小教學版，Yanhua 強調 CLAUDE.md 與 index.md 的防腐化規則，范凱的四層工作流加入 brainstorming / artifacts，Tim Feng 用 JSON index 做 progressive disclosure，GBrain 則把規模推到 Postgres、pgvector 與 typed knowledge graph。這個比較補強一個判準：先用 raw / wiki / schema 與索引檔跑通，不要在個人規模一開始就上向量資料庫或知識圖譜；等 index.md、全文搜尋或 QA 回寫真的成為瓶頸，再升級搜尋層或資料庫。

這篇也把 LLM Wiki 和 open-knowledge-format 的共同底線講清楚：raw source 必須唯讀、derived wiki 要可查詢可回寫、schema 要明確約束命名、引用、衝突處理與 lint。對 hermes-lmwiki-obsidian-workflow 與本 wiki 的 watch loop 來說，最小可行解不是增加 registry 或資料庫，而是確保每次 ingest 都留下 raw、更新頁面、更新 index / log，並用 hash 與 wikilink 檢查防止知識庫腐化。

LLM Wiki 的適用邊界：personal + immutable + synthesis-heavy

AIHAO 2026-07-25 導讀把 LLM Wiki 的適用條件收斂成 personal + immutable + synthesis-heavy：個人使用可避免跨來源 ACL 傳遞，原始資料穩定可避免合成頁面因 source 變更而過期，而任務若本來就需要跨文件綜合，ingest 時先整理便是需求而非額外負擔。這是對「LLM Wiki 能否取代企業 KB」更精確的判準，不是宣稱單一知識庫模式適用所有 retrieval。

對企業場景，快速查找、數值查詢、跨文件綜合、持續變動資料與不同 ACL 往往同時存在；此時合成頁面的隱性依賴、過期資訊與權限合併會放大維護成本。較穩的設計是先按 sub-domain 檢查規模、資料穩定性、權限一致性、綜合需求與實際查詢頻率，再決定哪些區域採 LLM Wiki，其他區域回到 metadata、BM25、vector、rerank、graph 與 ACL 的 hybrid retrieval。

相關連結

參考連結

Graph View

反向連結