Karpathy 親揭：用 LLM 打造個人知識庫的完整方法

OpenAI 創辦團隊成員、Tesla 前 AI 總監 Andrej Karpathy 在 X 上發布「LLM Knowledge Bases」工作流程、解釋他近期把大量 token 用量從「操控程式碼」轉向「操控知識」—用 LLM 把分散的論文、文章、資料夾、影像、整理成一個自動維護的個人 wiki。整套流程已在他自己的研究專案上累積 ~100 篇文章、~40 萬字、且全程由 LLM 寫入與更新。本文整理 Karpathy 的完整 setup、給想自己複製的開發者一張可實作清單。

核心理念：raw 資料 → LLM 編譯 → wiki → Q&A

Karpathy 的設計哲學可以濃縮成一句話：「raw data 進來、LLM 編譯成 wiki、wiki 再供 LLM 查詢、查詢結果繼續寫回 wiki」。整個系統的關鍵是把人類的角色從「寫筆記」轉成「監看 LLM 寫出的筆記」、knowledge base 不再是手動維護的 Notion 或 Roam Research、而是 LLM 自動寫入並維護的 markdown 檔案集合。

他描述自己很少直接編輯 wiki—寫入、補連結、抽取結構、檢查一致性、全是 LLM 做。這個「LLM 主導內容、人類監看」的模式、與多數人手動寫 Obsidian／Notion 的習慣完全不同、是這個工作流程的核心轉變。

Step 1：Data Ingest—把所有 raw 資料丟進一個 raw/ 資料夾

Karpathy 的入口很簡單：建一個 raw/ 資料夾、把所有來源資料倒進去—論文 PDF、新聞文章、code repo、資料集、影像、講稿。LLM 會以這個資料夾為輸入、逐步「編譯」出 wiki。

他特別提到兩個工具：

Obsidian Web Clipper 擴充套件—把網頁文章直接轉成 .md 檔放進 raw/

自訂 hotkey—把網頁的相關圖像下載到本地、讓 LLM 能在後續引用時直接讀

關鍵設計：所有外部資料以「離線、本地」形式存在、確保 LLM 後續查詢時不會卡在「找不到原始連結」的問題。

Step 2：LLM 編譯 wiki—自動產生分類、文章、反向連結

raw/ 資料就緒後、Karpathy 用 LLM 增量地（incrementally）「編譯」一個 wiki—就是一堆 .md 檔案組成的目錄結構。LLM 會做四件事：

對 raw/ 中所有資料寫摘要

把資料分類成概念（concepts）

為每個概念寫一篇文章

在文章之間建立反向連結（backlinks）

這個過程是「增量」的—新加入 raw/ 的資料、LLM 只更新受影響的 wiki 區塊、不必整個重編。對長期累積的研究主題（Karpathy 自己的研究 wiki 已經有 ~100 篇、40 萬字規模）、這種增量更新比一次性大編譯實用得多。

Step 3：用 Obsidian 作為 IDE「前端」、Marp 等外掛擴充

Karpathy 用 Obsidian 作為這套系統的視覺化前端—可以同時看 raw/ 資料、編譯出的 wiki、與衍生的視覺化（slide、圖表）。Obsidian 的好處是它本身就是 markdown 編輯器、與 LLM 寫出的 .md 檔天然相容、且支援 plugin 擴充。

他特別提到 Marp 這個 plugin—可以把 markdown 直接渲染成投影片格式、讓 LLM 不只能輸出文字、還能輸出簡報。

Step 4：Q&A—把整個 wiki 當 LLM 的查詢對象

Karpathy 的 wiki 進入「~100 篇文章、~40 萬字」規模後、最有趣的能力浮現：可以對 LLM agent 提任意複雜的問題、它會自己跑去研究答案、引用 wiki 中的相關段落。

原本他預期需要用「fancy RAG」（向量檢索、嵌入模型、re-ranking 等）才能跑這個規模、但實測發現：LLM 自己會維護 index 檔與每篇文章的簡短摘要、查詢時靠這些 index 與摘要就能找到相關段落、在「~40 萬字」這個尺度下、不必複雜的 RAG 也能跑得不錯。

這個觀察與 2024 年以來「向量 DB 過熱、實際很多場景不必用」的產業共識一致—當你的 knowledge base 在百萬字以下、structured markdown + LLM 自管 index 已足夠。

Step 5：輸出—不是純文字、而是 markdown／slides／圖表

Karpathy 的另一個設計：他不要 LLM 只回 terminal 文字、而是讓 LLM 產出有結構的輸出—markdown 檔、Marp 簡報、matplotlib 圖、視覺化資料。這些輸出在 Obsidian 內檢視。

更關鍵的是循環：產出的結果常常被 Karpathy 「歸檔」回 wiki、強化未來的查詢。他形容「自己的探索與查詢永遠都在累加（add up）到 knowledge base」—這是 stateful、會長大的、與 ChatGPT 對話「每次都從零開始」的模式相反。

Step 6：Linting—LLM 自我健檢、找一致性問題與新文章候選

Karpathy 對 wiki 跑 LLM「健康檢查」、處理三類問題：

找出資料不一致（同一概念在不同篇章的描述衝突）

用網路搜尋補上缺失資料

找出有趣的跨概念連結、推薦新的文章候選

這個 linting pass 是讓 wiki 隨時間「越來越乾淨」的關鍵—沒有它、自動編譯出來的 wiki 會逐漸累積矛盾與雜訊。LLM 在這個任務上表現不錯、是 Karpathy 認為這套工作流程可長期運行的原因之一。

Step 7：自製額外工具—例如自架 wiki 搜尋引擎

Karpathy 提到他「vibe coded」一個小型搜尋引擎、跑在自己的 wiki 上。這個工具有兩個用法：（1）他自己直接用 web UI 查；（2）更常見的是把這個搜尋引擎透過 CLI 介面、丟給 LLM 當作工具、讓 LLM 在大型查詢時能精準命中相關段落。

這個模式（人類搭一個 CLI、LLM 把它當工具用）、是 Claude Code、OpenAI Codex 這類 agent 框架下的核心設計—LLM 不直接讀全部資料、而是透過工具（CLI、search engine、file system）取得需要的子集。

Step 8：未來方向—合成資料生成、模型微調

當 wiki 規模夠大、Karpathy 提出兩個進階方向：

用 wiki 生成合成資料（synthetic data）—讓 LLM 為某些主題自動產出 Q&A 配對、教學文、範例

用合成資料微調一個專屬 LLM—讓你的個人 LLM「在權重中知道」這些資料、而不只是在 context window 中讀

這個方向把 knowledge base 從「外部記憶」推進到「內化記憶」、是個人化 AI 的下一步。但 Karpathy 自己也承認這需要更多基礎建設、目前還是探索階段。

Karpathy 的「Idea File」想法：分享構想、不分享 code

該則貼文爆紅後、Karpathy 在後續貼文提出新概念「idea file」—在 LLM agent 時代、與其分享具體 code、不如分享「想法」、讓對方的 agent 為他客製化、為他打造。

他把這套 LLM Knowledge Bases 的「idea file」放在一個 GitHub gist、刻意保持抽象、留空間給每個人的 agent 自由發揮。這可能是未來 dev community 的新分享模式—不是 GitHub repo、不是 npm 套件、而是「指令文件」、給 LLM 看的開源規格。

實作建議：台灣讀者怎麼開始

對想複製這套系統的台灣開發者、實務上的入門路徑：

Obsidian 是免費軟體、macOS／Windows／Linux 皆可、可從官網下載

Web Clipper 擴充套件可在 Chrome／Firefox／Edge 安裝

LLM 端可選 Claude Code（CLI）、ChatGPT（API）、或本地 Ollama（如果你有強顯卡）

raw/ 與 wiki/ 兩個資料夾建議放 Obsidian vault 同層、且加入 .gitignore 之外的版本控制（萬一 LLM 寫壞可以救回）

從一個你最熟悉的研究主題開始—例如「2026 加密交易所合規動態」「LLM 推論架構」、累積到 30–50 篇後 Q&A 能力會明顯改善

Karpathy 在貼文最後說：「這裡有打造一款厲害新產品的空間、不是現在這種粗糙腳本拼湊的形式。」對 builder 來說、這條 thread 既是工作流程說明、也是創業題材—LLM 自動 wiki、是個還沒有明確產品贏家的市場。

這篇文章 Karpathy 親揭：用 LLM 打造個人知識庫的完整方法 最早出現於 鏈新聞 ABMedia。