Karpathy 親手終結(jié)了 RAG 的草莽時代

作者 | 冬梅

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

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

Karpathy 新項目爆火，技術(shù)細(xì)節(jié)完整披露

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

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

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

Karpathy 詳細(xì)介紹了 LLM Wiki 項目的工程實現(xiàn)、數(shù)據(jù)采集、工具選擇等技術(shù)細(xì)節(jié)。

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

接著，Karpathy 調(diào)用 LLM 對這些素材進(jìn)行增量“編譯”，生成一個 Wiki。這個 Wiki 本質(zhì)上是一個具備清晰目錄結(jié)構(gòu)的 Markdown 文件集合，類似一個由 AI 自動撰寫和維護(hù)的知識百科系統(tǒng)。

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

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

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

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

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

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

為了維持這一系統(tǒng)的長期健康運行，Karpathy 還設(shè)計了一套“自動化運維”機(jī)制。他會定期調(diào)用 LLM 對整個 Wiki 進(jìn)行“體檢”：檢測數(shù)據(jù)不一致、補(bǔ)全缺失信息、通過聯(lián)網(wǎng)搜索引入新資料，甚至主動挖掘潛在的關(guān)聯(lián)關(guān)系并生成新的專題文章。

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

隨著知識庫規(guī)模的進(jìn)一步擴(kuò)大，Karpathy 也在思考下一階段的演化方向：是否可以通過合成數(shù)據(jù)生成與微調(diào)，將這些結(jié)構(gòu)化知識“壓縮”進(jìn)模型權(quán)重之中。換句話說，從依賴上下文窗口的外部知識系統(tǒng)，邁向模型內(nèi)部的長期記憶。

簡單總結(jié)一下，該架構(gòu)設(shè)計極簡，僅包含三個組件：

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

2、每個文件內(nèi)部結(jié)構(gòu)一致。優(yōu)秀的 LLM Wiki 文檔采用一致的內(nèi)部格式——標(biāo)題、簡短摘要、標(biāo)簽主題以及正文內(nèi)容。模型利用這種結(jié)構(gòu)更快地找到相關(guān)信息。

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

就是這樣，無需數(shù)據(jù)庫，無需向量嵌入也無需服務(wù)器。只需文件和一個功能強(qiáng)大的模型。

LLM Wiki “殺死了”RAG？

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

因此有 X 用戶認(rèn)為，LLM Wiki “殺死了”RAG。

過去三年，為 LLM 提供專有數(shù)據(jù)訪問的主要范式是檢索增強(qiáng)生成（RAG）。在標(biāo)準(zhǔn)的 RAG 設(shè)置中，文檔被分割成任意的“塊”，轉(zhuǎn)換為數(shù)學(xué)向量（嵌入），并存儲在專門的數(shù)據(jù)庫中。

當(dāng)用戶提出問題時，系統(tǒng)會執(zhí)行“相似性搜索”來查找最相關(guān)的數(shù)據(jù)塊，并將它們輸入到 LLM 中。Karpathy 的方法，他稱之為 LLM 知識庫，摒棄了中等規(guī)模數(shù)據(jù)集的向量數(shù)據(jù)庫的復(fù)雜性。

相反，它依賴于 LLM 對結(jié)構(gòu)化文本進(jìn)行推理能力的不斷提高。

系統(tǒng)架構(gòu)（由 X 用戶 @himanshu 在對 Karpathy 帖子的廣泛回應(yīng)中可視化呈現(xiàn)）分三個不同的階段運行：

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

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

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

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

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

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

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

研究顯示，人類在獲取新知識后的短時間內(nèi)就會遺忘其中的大部分內(nèi)容，而現(xiàn)代知識工作者每天平均需要花費近兩個小時，去查找那些“自己曾經(jīng)讀過”的信息。這不僅意味著巨大的時間浪費，也揭示了一個現(xiàn)實困境——無論是筆記工具、收藏夾，還是所謂的“第二大腦”，在長期使用后，往往都會演變?yōu)橐粋€信息堆積卻難以調(diào)用的“知識墓地”。 過去幾年，AI 行業(yè)嘗試通過 RAG 等技術(shù)路徑解決這一問題，即通過向量數(shù)據(jù)庫對海量文檔進(jìn)行索引，在需要時檢索相關(guān)片段并生成答案。然而在實際應(yīng)用中，這類方案往往面臨落地難題：檢索可以做到，但理解不足；信息可以找到，但難以形成結(jié)構(gòu)化認(rèn)知。某種程度上，這類系統(tǒng)只是讓用戶“更快地搜索混亂”，卻沒有真正解決知識組織的問題。 Karpathy 的思路則截然不同。他并沒有繼續(xù)優(yōu)化“檢索”，而是從源頭出發(fā)，提出“寫出更好的文檔”。在他的體系中，原始數(shù)據(jù)被視為“源代碼”，大語言模型則充當(dāng)“編譯器”，而最終生成的 Wiki 知識庫，則是可以直接使用的“可執(zhí)行產(chǎn)物”。

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

技術(shù)社區(qū)和企業(yè)反響熱烈

雖然 Karpathy 自己將 LLM Wiki 描述為“一堆蹩腳的腳本”，但它在技術(shù)社區(qū)和企業(yè)級市場還是引發(fā)了不少的關(guān)注。

企業(yè)家 Vamshi Reddy (@tammireddy) 在回應(yīng) Karpathy 帖子時表示：“每個企業(yè)都有一個原始目錄。從來沒有人把它整理過。這就是產(chǎn)品。”

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

目前大多數(shù)公司都“淹沒”在非結(jié)構(gòu)化數(shù)據(jù)中——Slack 日志、內(nèi)部維基和 PDF 報告，沒有人有時間去進(jìn)行綜合分析。

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

AI 教育家兼簡報作者 Ole Lehmann 在 x 上發(fā)帖稱：“我認(rèn)為，誰能把這個功能打包成普通用戶都能用的東西，就掌握了一項巨大的技術(shù)。一個應(yīng)用就能與你已經(jīng)使用的工具、書簽、稍后閱讀應(yīng)用、播客應(yīng)用、保存的討論串同步。”

AI 企業(yè) Agent 構(gòu)建和編排初創(chuàng)公司 Edra 的聯(lián)合創(chuàng)始人兼首席執(zhí)行官 Eugen Alpeza 在一篇 X 帖子中指出： “從個人研究維基到企業(yè)運營的飛躍才是真正的挑戰(zhàn)所在。成千上萬的員工，數(shù)百萬條記錄，以及團(tuán)隊間相互矛盾的經(jīng)驗知識。的確，企業(yè)級市場需要一款新產(chǎn)品，而我們正在打造它。”

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

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

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

整體來看，Karpathy 提出的這一方法的意義不僅在于提升效率，更在于重構(gòu)知識工作的底層邏輯。當(dāng)大模型能夠持續(xù)維護(hù)并擴(kuò)展一個結(jié)構(gòu)化知識體系時，傳統(tǒng)意義上的“筆記”正在演變?yōu)橐环N動態(tài)系統(tǒng)。對于個體而言，這意味著可以將認(rèn)知能力部分外包給機(jī)器；而對于行業(yè)而言，這也預(yù)示著一個潛在的新產(chǎn)品方向——將“知識編譯”本身，作為核心能力進(jìn)行產(chǎn)品化。

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

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

（https://kcnrpnk9jqxn.feishu.cn/wiki/LDSUwt1Gfi5uOmkhRXScfIExnBb）

會議推薦

世界模型的下一個突破在哪？Agent 從 Demo 到工程化還差什么？安全與可信這道坎怎么過？研發(fā)體系不重構(gòu)，還能撐多久？

AICon 上海站 2026，4 大核心專題等你來：世界模型與多模態(tài)智能突破、Agent 架構(gòu)與工程化實踐、Agent 安全與可信治理、企業(yè)級研發(fā)體系重構(gòu)。14 個專題全面開放征稿。

誠摯邀請你登臺分享實戰(zhàn)經(jīng)驗。AICon 2026，期待與你同行。

今日薦文

你也「在看」嗎？