別再讓 AI 每次都重新找答案！LLM-WIKI推動大模型從「資料檢索」走向「知識經營」

LLM-WIKI 是什麼？

過去我們使用 AI 問文件，多半還是「先找資料，再生成回答」的模式。學術上所說的 RAG，本來就是把語言模型和外部知識庫結合起來：先檢索，再生成。Lewis 等人在 2020 年把它描述為把生成模型和外部的非參數記憶結合，讓模型在回答時可以從外部資料中抓取資訊。Karpathy 在 2026 年提出的 LLM-WIKI，則把重點往前移：不是每次有人提問時才去翻原始文件，而是平常就讓 LLM 把新資料整理進一套持久存在的 wiki中。

Karpathy 在原始文件裡把這個 wiki 描述成一組互相連結的 Markdown 頁面，位在使用者與原始資料之間。當新資料加入時，LLM 不只是把它「加進索引」而已，而是會讀取內容、抽出關鍵資訊、更新既有頁面、修正主題摘要，並標記新舊資訊可能出現的矛盾。換句話說，LLM-WIKI 的重點不是讓 AI 回答得更像人，而是讓 AI 開始扮演一個持續整理知識的管理員。

傳統 RAG 像臨時查資料，LLM-WIKI 像長期寫筆記

Karpathy 在 gist 裡直接點出一個很關鍵的差別：多數文件問答式的體驗，常常是每次問題來了，才重新找片段、重新拼答案；知識沒有真正累積起來。Lewis 等人的原始 RAG 論文也提到，對這類系統來說，如何提供資料出處，以及如何更新世界知識，本來就是重要但尚未完全解決的問題。這也是為什麼 LLM-WIKI 聽起來會特別吸引人：它想做的，不只是讓回答更有根據，而是讓整理過的知識本身變成一個可以持續使用的產物。 

          表1、傳統RAG與LLM-WIKI之差異

資料來源：本文作者整理及繪製

LLM-WIKI 的三層結構

如果把它拆開來看，LLM-WIKI 大致可以想成三層。第一層是 原始資料，也就是 PDF、網頁、研究論文、會議記錄、筆記、聊天紀錄這些來源；Karpathy 特別強調，這一層最好保持不變，因為它是你的證據層。

第二層是 Wiki 知識頁，也就是 AI 產生並持續更新的 Markdown 頁面，可能是概念頁、人物頁、摘要頁、比較頁，或跨來源的綜合頁。

第三層是 Schema／規則層，它負責告訴 LLM：頁面如何命名、什麼時候新增頁面、什麼時候更新舊頁、引用怎麼放、回答如何回寫、維護流程怎麼跑。Karpathy 在文件裡把這一層視為讓 LLM 從「普通聊天模型」變成「有紀律的知識維護者」的關鍵。

圖1：LLM-WIKI三層架構圖, Generated by ChatGPT

圖片來源：本文作者與AI協作產出

為什麼這件事重要？

因為很多人真正缺的，不只是搜尋工具，而是把資料慢慢沉澱成知識的能力。這不是抽象焦慮。伊利諾大學收錄的一份 2024 年研究指出，在調查的 716 位員工中，22.34% 的受訪者表示自己每週大約要花半個工作天找資訊，還有 10.47% 表示要花到一個半工作天；研究也發現，搜尋時間變長，和資訊管理品質下降之間有顯著關聯。另外，Atlassian 在 2024 年針對 5,000 名知識工作者和 100 位 Fortune 500 高階主管 的調查則寫得很直接：團隊「比以前更忙，卻做得更少」，而工具、資料與分散團隊越來越多，會一起拉低生產力、對齊程度與專注工作的時間。

所以，LLM-WIKI 之所以讓人感興趣，不是在於它多了一個花俏的新名詞，而是在於它試著回答一個很現實的問題：當資料到處都是時，能不能先把它整理成一層比較穩定、比較可讀、比較可追溯的知識？這也是為什麼這個概念不只對研究者有吸引力，對企業內部知識庫、顧問工作、教育整理、長期主題研究，甚至個人第二大腦系統，都有吸引力。

它不是要取代 RAG，而是把整理前移

更準確的說法不是「LLM-WIKI 打敗 RAG」，而是：它把知識整理的工作，從問題發生之後，往前移到資料進來的當下。這是一個架構上的理解，不是單一論文的正式定義，但從 Karpathy 的描述來看，很適合這樣理解。事實上，相關研究也正在往同一個方向延伸：像 Microsoft Research 的 GraphRAG，就是先用 LLM 從文件建立實體知識圖，再預先生成各個社群的摘要，讓系統不只會回答局部問題，也比較能處理「整體資料集到底在講什麼」這種全局型問題。

GraphRAG 的論文甚至報告，在 100 萬 token 等級 的資料集上，對這類全局 sensemaking 問題，它比傳統 RAG baseline 可以產生更完整、更多樣的答案。這也代表，LLM-WIKI 並不排斥搜尋。小規模時，它可以先靠整理過的 wiki 頁面和 index 工作；規模變大後，它仍然可以搭配全文搜尋、向量搜尋、重排序，甚至圖譜檢索。它比較像是在搜尋前面，多加了一層持久知識層。

一個簡單例子：如果你有一堆 AI 文章

假設你收集了 100 篇 AI 文章、研究論文、工具介紹。傳統做法通常是把它們放進可檢索系統，等你問「什麼是 LLM-WIKI？」時，再去撈出最相關的幾段文字來回答。LLM-WIKI 則更像是：在你把文章放進去之後，它就先整理出概念頁、來源摘要、實體頁和綜合頁，並在之後回答問題時，優先從這些已整理過的頁面出發。Karpathy 在文件中列出的典型頁面也很接近這種想法：summary、entity pages、concept pages、comparisons、overview、synthesis，甚至把好的回答再回寫成新頁面，讓探索本身也會累積。這樣做的價值，在於資料不是只有被「存起來」，而是被結構化、連結化、版本化。下次再遇到類似問題時，系統不用每次都從零開始重讀一堆片段，而是可以從已經整理好的頁面繼續往前走。

實作方式其實可以很樸素

LLM-WIKI 很有趣的一點，是它不一定要從龐大的雲端架構開始。Karpathy 的原始 idea file 就給了一個很務實的方向：原始來源放一個資料夾，wiki 頁面放另一個資料夾，再加上 index.md、log.md，以及一份規則文件。Karpathy 自己提到，中等規模時，像是約 100 份來源、數百個頁面，光靠這種索引頁就可能已經夠用，甚至可以先不碰 embedding-based RAG infrastructure。

如果你想讓它更好維護，Git 幾乎是天然搭配。Git 官方文件把版本控制定義為一種記錄檔案變化、讓人能回想與還原舊版本的系統；它也把 Git 描述成儲存一組檔案歷史與快照的工具。這種特性剛好對應到 LLM-WIKI 最怕失去的東西：修改紀錄、版本比較、回滾能力。而如果你用 Obsidian 之類的 Markdown 工具，還能直接用 Graph view 看筆記之間的連結，因為 Obsidian 的官方說明就把 Graph view 定義為用來可視化 vault 內筆記關係的核心功能。

等規模再大一點，才逐步加搜尋層也不遲。Karpathy 在原文裡提到，wiki 成長後可以接上搜尋工具；他點名的 qmd 就是一個例子。qmd 把自己描述成一個用於 Markdown 文件的本地搜尋引擎，支援 BM25 全文搜尋、向量語意搜尋、LLM reranking，而且也能用 MCP server 和 agent 整合。這很適合拿來當「wiki 長大之後的第二階段」。

真正的挑戰：AI 整理出來的內容可信嗎？

這裡才是事情真正困難的地方。LLM-WIKI 的價值來自於它會把東西寫回知識庫，但這同時也是風險來源：如果整理錯了，錯誤就可能不只是一句聊天回答，而會變成一段被長期保存、之後還可能被反覆引用的系統記憶。

也因此，成熟版的 LLM-WIKI 不能只追求「自動化」，還要追求可追溯、可審核。在學術界，Rashkin 等人提出的 AIS 框架，核心就是：當生成內容涉及外部世界時，應該可以被一個獨立且提供好的來源驗證。另一篇 EMNLP 2023 的研究也提醒，即使系統已經附上 reference，要判斷「這個引用是否真的支撐了那句話」本身，仍然是一個開放問題，而且人工評估很花時間。NIST 的 AI Risk Management Framework 則把 accountable and transparent、explainable and interpretable、privacy-enhanced 與人類監督都列為可信 AI 的重要特徵。簡單說，LLM-WIKI 不能只有「會寫」，還要有一套讓人看得懂它為什麼這樣寫、從哪裡來、誰改過、能不能退回的流程。

現階段發展狀態

截至目前為止，LLM-WIKI 還是非常新的概念，但工程社群已經開始快速實驗。Karpathy 的 gist 建立於 2026 年 4 月 4 日；之後 GitHub 上已經能看到不同方向的專案，例如 Labhund/llm-wiki 把自己描述成「wiki over RAG」的 agent-first knowledge base，帶有 background quality agents 與 MCP server；emakhov/llm-wiki-agent 直接把 ingest、query、lint 和 Obsidian vault 結構包成一個個人知識庫 agent；SamurAIGPT/llm-wiki-agent 則主打把 source 丟進 raw/ 之後，讓 agent 維護一個 persistent interlinked wiki，還能輸出 graph 檔案。這些專案形式不同，但方向非常一致：Markdown、索引、日誌、交叉引用、持續更新、圖譜或關聯視圖、以及 agent 工具整合。

FIND觀點

筆者也實際嘗試以全本地方式搭建 LLM-WIKI，並搭配本地模型運行。雖然在知識整理過程中 token 消耗不小，但有趣的是，對模型本身的性能要求反而沒有想像中高。特別是在面對大量資料時，它更像是一個耐心的整理者，而非追求極致推理能力的系統。未來若能進一步優化成本與流程，這類本地化、可控的知識整理方式，或許會成為個人與團隊管理資訊的重要基礎。

封面圖片來源：本文作者以AI生成

參考資料來源：

1karpathy/llm-wiki.md

2.P. Lewis et al., "Retrieval-augmented generation for knowledge-intensive NLP tasks," in Advances in Neural Information Processing Systems, 2020, vol. 33, pp. 9459–9474.

3. M. Nakash and D. Bouhnik, "How much time does the workforce spend searching for information in the ‘new normal’?," in iConference 2024 Proceedings, 2024. [Online].

4. H. Rashkin et al., "Measuring attribution in natural language generation models," Computational Linguistics, vol. 49, no. 4, pp. 777–840, Dec. 2023, doi: 10.1162/coli_a_00486.