打造第二大腦，不用資料庫也能完成－實做 Karpathy 的 LLM Wiki 概念

幾個月前看到一個概念：查詢知識庫不一定要用向量資料庫（RAG），就可以讓 AI 自己維護一套 Markdown 檔案結構來做查詢。這是 OpenAI 創始團隊成員、前 Tesla AI 總監 Andrej Karpathy 提出的想法，他把這個概念寫成一份公開說明放在 GitHub 上。

當時覺得有 NotebookLM(現在叫做 Gemini Notebook)就夠了，所以沒有太多感觸。最近有機會照著一個公開的實作範例做了一次，拿一份公開資料測試，記錄一下學到的東西。如果擔心隱私，或是覺得免費版 NotebookLM 不夠用的話，可以試試看!

RAG 和 LLM Wiki 差在哪

一般做知識庫查詢，解決大量知道與長文的做法，常見做法是 RAG：把文件切成一小塊一小塊（chunk），轉成向量存進資料庫，查詢時算相似度，抓最像的幾塊丟給 AI。

這個做法常被詬病幾個問題：

每次查詢都要撈一堆原始文字塊給模型，Token 用量高
向量相似度抓到的東西有時候「語意像但邏輯不相關」
每次對話都是重新拼湊，知識庫本身不會累積、不會變聰明

Karpathy 提的 LLM Wiki 概念不是查詢時才處理資料，而是資料放進去的時候就先整理好：AI 維護一套結構化的 Markdown 檔案，原始資料放著不變動，查詢時先看索引，再精準跳到需要的地方，不用把整份資料塞給模型。

照著做了一次

實際用的目錄結構大致是這樣：

raw/            # 原始資料，AI 只讀不改
assets/         # 圖片等附加素材
wiki/
├── index.md    # 內容總索引
├── log.md      # 操作日誌
├── concepts/   # 整理出來的概念說明
├── entities/   # 人物、專有名詞等條目
├── sources/    # 各個原始資料的摘要
└── syntheses/  # 跨資料整合出的結論
CLAUDE.md       # 給 AI 的規則說明

我拿教育部公開的《成語典》已轉換過的 JSON 檔案（約 16 MB，幾千條成語資料）放進 raw/ 底下當測試對象，看它會怎麼處理。

查詢「九牛一毛」的時候，AI 沒有把整份 16 MB 檔案讀進來，也沒有查什麼向量資料庫，而是：

先看 wiki/index.md，找到這份成語資料記錄在哪
到 wiki/sources/ 底下對應的摘要檔案，知道原始檔案的欄位結構（成語、釋義、典故說明等）
自己寫了一小段 Python，直接在 JSON 裡篩出符合的那一條

python -c "import json, sys; sys.stdout.reconfigure(encoding='utf-8'); data=json.load(open('raw/dict_idioms_2020_20260625.json', encoding='utf-8')); matches = [x for x in data if '九牛一毛' in x.get('成語', '')]; print(json.dumps(matches, ensure_ascii=False, indent=2))"

這段程式碼是它自己寫的，我沒有教它要怎麼查——這是讓我覺得有意思的地方：規則給的是「查詢前要先看索引」，但實際判斷「這個檔案太大，寫程式篩選比整份塞進 context 划算」是模型自己的推理。

Karpathy 原文提到這樣做能大量節省 Token、查詢速度也快很多——這是原文的說法，我自己沒有另外做基準測試比對數據，但的確在使用上有第二大腦的感覺了，速度也真的很快!

是規則的功勞，還是模型自己厲害

這個問題我自己想了一下，跟 AI 討論過後，覺得蠻值得記下來：答案是兩者都要。

CLAUDE.md 這類規則檔提供的是「規矩」——強制要求查詢前先看索引，避免 AI 憑空瞎猜；也規定查完要更新 log.md、把新概念記進 concepts/，讓知識庫本身會累積、會連結。

模型負責的是「判斷」——看到 16 MB 的 JSON，自己意識到直接塞進 context 太浪費，主動選擇寫程式篩選。這個判斷力不是規則寫死的，是模型自己推理出來的。

我的理解：這個方法適合什麼情境

這不是要取代 RAG，是另一個選擇。

如果資料庫是完全非結構化、內容量非常大又沒什麼規律，向量檢索還是有它的優勢。但如果是企業內部 SOP、產品文件、API 規格、或是個人自己整理的筆記——這種本來就有一定結構、資料量不算誇張的情境，LLM Wiki 這種先整理、後查詢的方式，聽起來比每次都撈一堆向量塊划算。

心得

原本在使用 Obsidian 時，也會去做一些分類，但直到現在照著 Karpathy 與參考他人的方式，實作了才發現可以改進的方法很多，學到不少東西。雖然測試也只用了一份成語字典而已，不算嚴謹。但親手跑一次之後，比單看文章更能理解「查詢前先整理」和「查詢時才處理」這兩種思路的差別。

如果你也在建自己的知識庫、或考慮怎麼查詢大量資料，可以參考以下的來源來動手試一次建立個人的第二大腦!

RAG 和 LLM Wiki 差在哪

照著做了一次

是規則的功勞，還是模型自己厲害

我的理解：這個方法適合什麼情境

心得

參考來源