Posted by 
🎯 MVP Demo：llm-wiki-frontend-mvp.vercel.app — 直接打開體驗
Andrej Karpathy 前陣子提了一個概念：LLM Wiki——把 wiki 的結構化知識和 LLM 的語言能力結合，讓 AI 不只是生出看似合理的文字，而是基於你真正寫過的、整理過的、沉澱過的知識來回答問題。
老實講，這概念一看就覺得「對啊，為什麼沒有人這樣做？」於是我自己刻了一個。
核心想法
說穿了很簡單。你有寫筆記的習慣——Obsidian、Notion、乃至 markdown 檔——這些都是你腦袋的外部硬碟。問題是，你要用的時候找不到，或是找到了但上下文不對。
LLM Wiki 做的事：把你的筆記全部丟進一個 pipeline，讓 AI 幫你整理成結構化的 wiki，然後你就可以用自然語言搜尋。不是 vector search 那種「語意相近就丟給你」的模糊比對，而是真的讓 LLM 讀過你的筆記後，引用原文回答你。
Karpathy 的原始想法：不要做 RAG，做 Wiki
Karpathy 的核心論點很簡單：不要做 RAG，改做 wiki。RAG 是每次查詢時才臨時從 raw 文件找答案 —— stateless，什麼都不留。他的做法是讓 LLM 當 compiler，把 raw 文件增量編譯成一份持久化的 markdown wiki，然後一直維護它。
說真的，人會放棄 wiki 就是因為維護太累。cross-reference 要手動更新、矛盾要自己比對、過時內容沒人清。Karpathy 的洞察是：LLM 不會累。把 bookkeeping 外包給 AI，人只要負責 curation 跟思考。
整個知識消化流程長這樣：
raw/（你寫的原始筆記）→ ingest（LLM 分析概念、標矛盾、建 cross-reference）→ compile（合成結構化 wiki page）→ lint（定期掃 wiki 做健康檢查：孤立 page、過期內容、概念缺口）→ wiki/（持續維護的知識庫）
跟傳統 RAG 最大的差別：RAG 是用 grep 的邏輯在 raw 文件裡撈 —— 關鍵字匹配 → 丟給 LLM 生答案。LLM Wiki 是先把 raw 消化成結構化知識（wiki），查詢時直接從整理過的知識庫取答案。前者每次都從零開始推導，後者把推導結果存起來、持續累積。
Karpathy 把這個 pattern 一路連回 Vannevar Bush 1945 的 Memex 願景 —— 80 年前就想做「人的延伸記憶系統」，但卡在一件事：誰來維護？LLM 終於把這塊補上了。
如果你想看更完整的分析（包括 LLM Wiki vs 卡片盒筆記法的對比、Model Collapse 的風險、Vibe Thinking 的辯論），WenHao Yu 的這篇實測是目前中文圈寫得最好的。
Wiki 裡面有什麼？
目前 wiki 的內容是 LifestyleWiki——台灣親子旅遊、景點、公園的結構化知識庫。86 篇原始文章（sources）、348 個概念（concepts），涵蓋新北市到屏東的親子景點、玩水秘境、特色公園。
建議你先點進 Sources 和 Concepts 頁面逛一下，會比較有感覺。
Source vs Concept
Source 是原始文章——爬蟲抓下來的部落格文、旅遊筆記。保留原文結構，含 frontmatter（來源 URL、日期、tags）。像是「五股體健防災公園完整攻略」這種就是你會 Google 到的原文。
Concept 是 AI 從 sources 消化出來的結構化知識頁。例如從 10 篇不同部落客的文章中，AI 整理出「中和員山公園」的概覽、特色設施、交通資訊、注意事項，變成一張乾乾淨淨的 wiki page。
整個流程：raw 筆記 → OLW pipeline 用 Gemini ingest（分析概念與關係）→ compile（合成 wiki 文章）→ lint（品質檢查）→ publish（上 GCS）。一鍵跑完，人只要決定哪些 raw 要餵進去。
Wiki Only vs Full（LLM+Wiki）
搜尋時可以選兩種模式，流程相同：
- Query Expansion：LLM 把你的自然語言問題展開成多組 grep 關鍵字
- Metadata Grep：用關鍵字在 index 裡搜，找出相關的 source/concept（取 top-10）
- LLM 合成：把 top-10 的全文餵給 LLM，產生帶 citation 的回答
差別在 LLM 的 system prompt：
Wiki Only：LLM 只能從 wiki 內容回答，不允許用外部知識（”Do not use external knowledge”）。適合你想確認「wiki 裡有什麼」的時候。
Full（LLM+Wiki）：LLM 可以補充一般知識（”You may supplement with general knowledge”）。適合你需要綜合答案的場景——AI 會引用 wiki 內容，也會補上自己的理解。
跟 NotebookLM 比呢？
Google 的 NotebookLM 最近很紅——丟文件進去，AI 幫你摘要、回答、甚至生 podcast。它的底層機制是 RAG（embedding + vector search）搭配 Gemini 的超大 context window（1M+ tokens），檢索到的相關段落遠比傳統 RAG 多，再透過嚴格的 grounding prompt 確保回答只來自你給的資料。
但它有一個硬限制：每個 notebook 最多 50 個 sources。這比較像是產品級決策（底層 Gemini File Search API 每個 corpus 上限約 1GB），對多數人一個主題丟 50 篇已經很夠。
LLM Wiki 走的是另一條路：不在查詢時做 embedding retrieval，而是先把 raw 預先消化成結構化 knowledge。
查詢時只走兩步：
- Metadata grep：用 query expansion 的關鍵字在 index 裡搜，找出相關的 source/concept（通常 5-10 篇），不碰全文。
- LLM 合成：只把「跟問題有關」的那幾篇餵給 LLM 生答案。
因為 concept 已經是 pipeline 預先消化好的結構化知識（一篇 concept body 約 1KB），就算全讀進來 grep 也才 300-500KB——遠低於 NotebookLM 的 1GB 上限。而且實際上不讀全部，只讀 metadata index 找相關的 5-10 篇。未來甚至可以全部 concept 存成單一 JSONL，一口氣拉進來 grep（參考 LWC-8），完全不碰 embedding。
所以 86 sources + 348 concepts 完全不是問題。未來加到幾千篇也一樣，因為 cost 不隨總量線性成長。
NotebookLM 擅長單一主題、50 篇內的深度研究（embedding 檢索 + 超長 context 雙重保障）。LLM Wiki 擅長長期累積、跨主題、大規模的個人知識庫——預消化 > 即時檢索。兩種工具解決不同階段的問題，不是誰取代誰。