Karpathy 親手終結了RAG的草莽時代

作者｜冬梅

在“每一枚 Token 都要精打細算”的共識下，AI 圈一度流行一種略帶調侃的說法：真正的高手，不是把 Token 用在寫代碼上，而是用在更高杠桿的事情上。

最近，這一理念被再次推向臺前——主角是患上了“AI 精神病”的 Andrej Karpathy。

Karpathy 新項目爆火，
技術細節完整披露

幾天前，Karpathy 在 X 上分享了一套自己正在實踐的工作流，稱之為“LLM Wiki”：他不再把大模型主要用于寫代碼，而是將絕大多數 Token 消耗，轉向構建一個圍繞個人研究興趣的“可演化知識庫”（以 Markdown 和圖片形式存儲）。

這條帖子在 x 上瀏覽量超 1700 萬，圍觀者眾多。

項目地址：https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f

Karpathy 詳細介紹了 LLM Wiki 項目的工程實現、數據采集、工具選擇等技術細節。

從工程實現上看，Karpathy 的方法并不依賴復雜的基礎設施，甚至可以說極其“樸素”。一切始于一個名為 raw/ 的原始目錄。在這個目錄中，他將與研究主題相關的所有素材一股腦地收集進來——包括論文、技術博客、代碼倉庫、數據集，乃至圖片等多模態內容。這一步并沒有任何結構設計，核心目標只有一個：最大化原始信息的完整性。

接著，Karpathy 調用 LLM 對這些素材進行增量“編譯”，生成一個 Wiki。這個 Wiki 本質上是一個具備清晰目錄結構的 Markdown 文件集合，類似一個由 AI 自動撰寫和維護的知識百科系統。

Karpathy 把Obsidian作為這個系統的“前端 IDE”，在這里他可以查看原始數據、編譯好的 Wiki 以及衍生的可視化內容。Karpathy 介紹，這么做的核心點在于：Wiki 中的所有數據都由 LLM 編寫和維護，自己極少直接動手修改。

他還嘗試了一些 Obsidian 插件來以不同方式展示數據，比如用 Marp 插件生成演示幻燈片。

當知識庫規模逐漸擴大，這一系統開始展現出更強的能力。Karpathy 提到，在一個包含約 100 篇文章、總計 40 萬字的研究項目中，他已經可以直接向 LLM Agent 提出復雜的系統性問題。與傳統認知不同，他并沒有引入復雜的 RAG 架構，而是依賴 LLM 對 Wiki 的“內生理解”能力——模型通過自動維護的索引與摘要，可以高效定位相關信息并進行綜合分析。

這一點尤為關鍵。過去一年，RAG 幾乎成為企業級 AI 應用的“標配”，但 Karpathy 的實踐表明，在中等規模的數據集上，LLM 本身已經具備足夠強的“自檢索”與“自組織”能力。這意味著，一部分復雜的系統設計，可能正在被模型能力的提升所“吞噬”。

在輸出層面，Karpathy 同樣不滿足于傳統的文本回答。他將 LLM 生成能力進一步擴展到多種格式：包括 Markdown 文檔、基于 Marp 的演示幻燈片，甚至是通過 Matplotlib 繪制的數據圖表。這些結果統一在 Obsidian 中進行可視化呈現，使知識不再停留在“答案”，而是轉化為可以復用、傳播和沉淀的資產。

更重要的是，這些輸出并不會被丟棄。相反，它們會被重新歸檔進 Wiki，成為知識庫的一部分。換言之，每一次提問與探索，都會對系統進行“增量訓練”——盡管不是傳統意義上的模型訓練，但在知識層面，系統的能力確實在持續累積。

為了維持這一系統的長期健康運行，Karpathy 還設計了一套“自動化運維”機制。他會定期調用 LLM 對整個 Wiki 進行“體檢”：檢測數據不一致、補全缺失信息、通過聯網搜索引入新資料，甚至主動挖掘潛在的關聯關系并生成新的專題文章。

此外，他還通過“Vibe Coding”的方式快速開發了一些輔助工具。例如，一個用于檢索 Wiki 的簡易搜索引擎，可以通過網頁界面或命令行調用。在更復雜的場景下，這些工具甚至可以作為 LLM 的外部能力接口，由模型自主調用完成任務。

隨著知識庫規模的進一步擴大，Karpathy 也在思考下一階段的演化方向：是否可以通過合成數據生成與微調，將這些結構化知識“壓縮”進模型權重之中。換句話說，從依賴上下文窗口的外部知識系統，邁向模型內部的長期記憶。

簡單總結一下，該架構設計極簡，僅包含三個組件：

1、一個 Markdown 文件文件夾。 這是你的知識庫。它可以包含任何內容：研究筆記、會議紀要、項目文檔、讀書筆記、個人參考資料、帶有解釋的代碼片段。

2、每個文件內部結構一致。優秀的 LLM Wiki 文檔采用一致的內部格式——標題、簡短摘要、標簽主題以及正文內容。模型利用這種結構更快地找到相關信息。

3、使用 Claude Code 作為查詢界面。打開終端，導航到你的 wiki 文件夾，啟動 Claude Code，然后向它提出問題。Claude 會讀取所需的文件，綜合生成答案，甚至可以根據你的要求更新或添加注釋。

就是這樣，無需數據庫，無需向量嵌入也無需服務器。只需文件和一個功能強大的模型。

LLM Wiki “殺死了”RAG？

Karpathy 的這一實踐之所以能夠迅速引發關注，是因為它并非只是一個效率工具的升級，而更像是對“個人知識管理”（PKM）體系的一次重構。從 Notion、Roam Research 到 Obsidian，過去十年里，人們始終在尋找更好的知識組織方式，而在 LLM 的加持下，這一問題的解法，正在從“如何記錄”轉向“如何自動生成與演化”。

因此有 X 用戶認為，LLM Wiki “殺死了”RAG。

過去三年，為 LLM 提供專有數據訪問的主要范式是檢索增強生成（RAG）。在標準的 RAG 設置中，文檔被分割成任意的“塊”，轉換為數學向量（嵌入），并存儲在專門的數據庫中。

當用戶提出問題時，系統會執行“相似性搜索”來查找最相關的數據塊，并將它們輸入到 LLM 中。Karpathy 的方法，他稱之為 LLM 知識庫，摒棄了中等規模數據集的向量數據庫的復雜性。

相反，它依賴于 LLM 對結構化文本進行推理能力的不斷提高。

系統架構（由 X 用戶 @himanshu 在對 Karpathy 帖子的廣泛回應中可視化呈現）分三個不同的階段運行：

1. 數據導入：原始資料——研究論文、GitHub 代碼庫、數據集和網絡文章——被導入到一個 raw/ 目錄中。Karpathy 使用 Obsidian Web Clipper 將網頁內容轉換為 Markdown.md 文件，確保即使是圖像也存儲在本地，以便 LLM 可以通過視覺功能引用它們。

2. 編譯步驟：這是核心創新點。LLM 不僅僅是對文件進行索引，而是對文件進行“編譯”。它讀取原始數據并生成結構化的維基百科頁面。這包括生成摘要、識別關鍵概念、撰寫百科全書式條目，以及——至關重要的是——在相關概念之間創建反向鏈接。

3. 主動維護（代碼檢查）：該系統并非一成不變。Karpathy 描述了運行“健康檢查”或“代碼檢查”的過程，LLM 會掃描 wiki 以查找不一致之處、缺失數據或新連接。正如社區成員 Charly Wargnier 所觀察到的，“它就像一個活的 AI 知識庫，能夠自我修復?！?/p>

Karpathy 將 Markdown 文件視為“真理之源”，從而避免了向量嵌入的“黑箱”問題。AI 做出的每一項聲明都可以追溯到特定的.md 文件，而這些文件可以由人閱讀、編輯或刪除。

在 Youtube 上，也有不少關于 “LLM Wiki killed RAG”相關話題的討論。

一位 ID 名為 DIY Smart Code 的博主闡述了為什么他認為有了 LLM Wiki 后，就不再需要 RAG 了。

該博主表示：“人類并不缺少信息，缺的是對信息的持續組織與有效利用。”

研究顯示，人類在獲取新知識后的短時間內就會遺忘其中的大部分內容，而現代知識工作者每天平均需要花費近兩個小時，去查找那些“自己曾經讀過”的信息。這不僅意味著巨大的時間浪費，也揭示了一個現實困境——無論是筆記工具、收藏夾，還是所謂的“第二大腦”，在長期使用后，往往都會演變為一個信息堆積卻難以調用的“知識墓地”。

過去幾年，AI 行業嘗試通過 RAG 等技術路徑解決這一問題，即通過向量數據庫對海量文檔進行索引，在需要時檢索相關片段并生成答案。然而在實際應用中，這類方案往往面臨落地難題：檢索可以做到，但理解不足；信息可以找到，但難以形成結構化認知。某種程度上，這類系統只是讓用戶“更快地搜索混亂”，卻沒有真正解決知識組織的問題。

Karpathy 的思路則截然不同。他并沒有繼續優化“檢索”，而是從源頭出發，提出“寫出更好的文檔”。在他的體系中，原始數據被視為“源代碼”，大語言模型則充當“編譯器”，而最終生成的 Wiki 知識庫，則是可以直接使用的“可執行產物”。

在這種情況下，基本就不會再需要 RAG 了。

技術社區和企業反響熱烈

雖然 Karpathy 自己將 LLM Wiki 描述為“一堆蹩腳的腳本”，但它在技術社區和企業級市場還是引發了不少的關注。

企業家 Vamshi Reddy (@tammireddy) 在回應 Karpathy 帖子時表示：“每個企業都有一個原始目錄。從來沒有人把它整理過。這就是產品?！?/p>

Karpathy 對此表示贊同，并認為這種方法代表了一種“令人難以置信的新產品”類別。

目前大多數公司都“淹沒”在非結構化數據中——Slack 日志、內部維基和 PDF 報告，沒有人有時間去進行綜合分析。

“Karpathy 式”企業層不僅會搜索這些文檔，還會主動編寫實時更新的“公司圣經”。

AI 教育家兼簡報作者 Ole Lehmann 在 x 上發帖稱：“我認為，誰能把這個功能打包成普通用戶都能用的東西，就掌握了一項巨大的技術。一個應用就能與你已經使用的工具、書簽、稍后閱讀應用、播客應用、保存的討論串同步?！?/p>

AI 企業 Agent 構建和編排初創公司 Edra 的聯合創始人兼首席執行官 Eugen Alpeza 在一篇 X 帖子中指出： “從個人研究維基到企業運營的飛躍才是真正的挑戰所在。成千上萬的員工，數百萬條記錄，以及團隊間相互矛盾的經驗知識。的確，企業級市場需要一款新產品，而我們正在打造它?！?/p>

AI 代理創建平臺 Secondmate 的創始人 @jumperz 最近發布的一份架構分解報告，通過“群體知識庫”展示了這一演變過程，該知識庫將 wiki 工作流程擴展到通過 OpenClaw 管理的 10 個代理系統。

另一位 x 用戶還將 Karpathy 的腳本方案成功“產品化”了。她推出了一款名為：Claudeopedia（Claude 百科）的產品，并說明了她構建該產品的幾大步驟，她寫道：

1. 我采納了 @karpathy 的 “llm-wiki” 構想（這占了本項目 90% 的功勞，所以大頭要歸功于 Karpathy）； 2. 結合了過去 30 天的技能（感謝 @mvanhorn 的靈感）； 3. 新增了一個 /wiki 技能，支持截圖和下載參數，能更飛速地傳輸原始素材； 4. 構建了一個交互式可視化界面來搜索我的知識庫（甚至帶日期范圍，可以對比知識隨時間演進的變化！）； 5. 設置了一個“質疑自我假設”的定時任務（cron job），自動將我最近的隨筆和客戶郵件與 Wiki 內容進行比對復核。 目前這一切都在 Obsidian 中運行。包括測試在內，所有這些都是在這個周末搞定的。我會繼續添加更多功能。我重點構建的是：企業級 AI。我已經非常期待了。

整體來看，Karpathy 提出的這一方法的意義不僅在于提升效率，更在于重構知識工作的底層邏輯。當大模型能夠持續維護并擴展一個結構化知識體系時，傳統意義上的“筆記”正在演變為一種動態系統。對于個體而言，這意味著可以將認知能力部分外包給機器；而對于行業而言，這也預示著一個潛在的新產品方向——將“知識編譯”本身，作為核心能力進行產品化。

在信息不斷膨脹的時代，這種從“存儲信息”到“演化知識”的轉變，或許正是下一階段 AI 應用的重要突破口。

https://www.youtube.com/watch?v=RQsLXmenr48

https://x.com/NickSpisak_/status/2040448463540830705

https://x.com/alliekmiller/status/2040884878229565816

https://www.mindstudio.ai/blog/andrej-karpathy-llm-wiki-knowledge-base-claude-code

https://obsidian.md/clipper

https://venturebeat.com/data/karpathy-shares-llm-knowledge-base-architecture-that-bypasses-rag-with-an

聲明：本文為 InfoQ 原創，不代表平臺觀點，未經許可禁止轉載。

會議推薦

QCon 全球軟件開發大會·2026 北京站將于 4 月 16 日 -18 日正式舉辦。本屆大會以“Agentic AI 時代的軟件工程重塑”為主題，聚焦 100+ 重磅議題，匯聚來自阿里、騰訊、字節跳動、小米、百度等一線科技企業與創新團隊的技術專家，圍繞 AI 工程化、系統架構與研發模式演進展開深入探討。更多詳情可掃碼或聯系票務經理 18514549229 進行咨詢。