放棄RAG吧！LLM知識庫新範式 | Karpathy的新思路

頻道： 為什麼叫QQ（@whycallqq）

逐字稿來源： Groq Whisper-large-v3 STT（原影片字幕已關閉）

---

大家好，我是為什麼叫QQ。

你以為RAG就是現在最好的知識庫方案？你以為把一堆PDF扔給大模型讓它幫你檢索，這就是AI時代的知識管理？錯得離譜。

最近前Tesla AI總監、OpenAI創辦成員Andrej Karpathy分享了他自己構建個人知識庫的方法。看完他的方案我倒吸一口涼氣，因為他根本不用傳統的RAG。他用大模型構建了一個會自己生長的持久化Wiki，這個方法直接把現在市面上90%的知識庫產品按在地上摩擦。

你可能會問，為什麼RAG雖然能檢索但總覺得不夠聰明？你有沒有遇到過這種情況：你存了一年的資料，問一個需要綜合五篇文章的複雜問題，結果大模型總是漏掉關鍵資訊，或者給你一個似是而非的答案？為什麼？因為在傳統的RAG系統裡，大模型每次回答你的問題都是在重新發現知識。它沒有記憶、沒有積累。你的知識庫用了一年，本質上還是一堆散亂的文件，它從來沒有真正變成你的知識。

我們先來看看現在的知識庫是怎麼工作的。不管是NotebookLM還是ChatGPT的文件上傳，本質上都是RAG。你上傳文件，系統把文件切成小塊。你提問，系統找出最相關的幾塊丟給大模型讓它總結。這套邏輯跑得通，但有一個致命缺陷：知識沒有複利。

Karpathy發現了這個問題。他最近把大量的精力從寫程式碼轉移到了處理知識上。他發現最新的大模型能力已經強到可以做一件更偉大的事：他們不僅能檢索知識，還能編譯和維護知識。

這個思路其實可以追溯到1945年Vannevar Bush提出的Memex構想。只不過當年Memex解決不了誰來維護這些知識連結的問題。現在Karpathy找到了完美的苦力——大模型。

關鍵點一：持久Wiki vs 臨時檢索

傳統的RAG每次查詢都是臨時的，就像你每次遇到問題都要重新去圖書館翻一遍書，找出幾頁紙臨時拼湊一個答案，看完就扔了，下次遇到類似問題還得重來一遍。

但Karpathy的方法完全不同：它讓大模型增量構建和維護一個持久的Wiki。這是一個由Markdown檔案組成的、結構化、相互連結的集合。當你添加一篇新文章時，大模型不是簡單地把它存起來等以後檢索——它是去閱讀這篇文章，提取關鍵資訊，然後把它整合到現有的Wiki裡：更新實體頁面、修改主題摘要、甚至標記出新資料和舊觀點的矛盾。

關鍵來了：知識被編譯了一次，然後保持更新。 交叉引用已經存在了，矛盾已經被標記了。你的每一次閱讀都在讓這個Wiki變得更豐富。這才是真正的知識複利。

關鍵點二：優雅的三層架構

Karpathy把這個系統設計成了非常優雅的三層架構：

• 第一層：Raw Sources（原始資料層） — 這裡放著你收集的所有文章、論文、圖片。這一層是不可變的，大模型只能讀不能改。這是你的真理之源。
• 第二層：The Wiki（知識庫層） — 這裡全是大模型生成的Markdown檔案：摘要、概念、對比分析。大模型完全擁有這一層，它創建頁面、維護連結、保持一致性。你只管讀，大模型負責寫。
• 第三層：The Schema（規則層） — 這是一個設定檔（如CLAUDE.md），告訴大模型這個Wiki的結構是什麼，遇到新文章該怎麼處理。

這個分離的設計徹底改變了人機協作的模式：原始資料保持純淨，大模型有了明確的工作邊界。你不再是一個整理資料的苦力，你變成了一個知識架構師。

關鍵點三：大模型做記帳，人類做策劃

維護一個知識庫最痛苦的是什麼？不是閱讀，不是思考，是記帳：更新交叉引用、保持摘要最新、發現兩篇文章觀點衝突時去打個補丁。

人類之所以總是放棄維護Wiki，就是因為維護成本遠遠大於收益。大模型簡直就是天生的記帳員：他不會覺得無聊、不會忘記更新連結、可以一次性處理15個檔案。

在Karpathy的工作流裡，人類的工作只剩下：挑選高品質的資訊源、指導分析方向、提出好問題。剩下的所有髒活累活全部交給大模型。

Obsidian是IDE，大模型是程式設計師，Wiki就是你的程式碼庫。

很多人會覺得RAG現在的痛點是因為檢索演算法不夠好，只要用了更牛的向量資料庫、用了更複雜的rerank演算法，問題就解決了。但真相是：檢索再好也解決不了知識不積累的根本問題。即使你的檢索準確率達到100%，大模型依然是在臨時拼湊答案。為什麼會這樣？因為知識的本質不是資訊的堆砌，而是資訊之間的連結。

Karpathy的實驗證明了這一點：他的個人Wiki已經積累了大約100篇文章，將近40萬字。在這個規模下，他根本不需要什麼複雜的RAG基礎設施，就靠簡單的索引檔案加上大模型自動維護的摘要，就能回答極其複雜的問題。

四個核心動作

看到這裡你可能會想，這套方法聽起來很牛，但我該怎麼落地？

你需要建立一套基於大模型的知識編譯工作流，包含四個核心動作：

1. 攝入（Ingest）

看到好文章，用Obsidian Web Clipper抓取下來，讓大模型閱讀、和你討論要點，然後讓它去更新相關的Wiki頁面。一篇文章可能會觸及10到15個Wiki頁面。

2. 查詢（Query）

向你的Wiki提問。大模型會搜尋相關頁面、合成答案。它可以給你輸出Markdown、可以畫matplotlib圖表、甚至可以直接生成Marp幻燈片。把你的Wiki當成一個可以互動的知識圖譜。

3. 歸檔（Filing）

這是最重要的一步。大模型給你生成的精彩回答、對比表格、深度分析——不要看完就關掉，把它們作為新的頁面存回Wiki裡。讓你的每一次探索都成為知識庫的新資產。你的問題也在給Wiki增值。

4. 體檢（Lint）

定期讓大模型給Wiki做健康檢查：找出矛盾的資料、找出沒有連結的孤島頁面、甚至讓它聯網搜尋補充缺失的資訊。大模型還特別擅長建議你下一步應該研究什麼。

換一個角度來看：你不是在用一個工具，你是在僱用一個不知疲倦的知識管家。開源社群已經有人實現了這套引擎，比如GitHub上的Agent Memory專案，這套模式完全可以開箱即用。

未來展望

• 短期內：會有越來越多人意識到RAG的局限性，大家會開始從臨時檢索轉向持久編譯。我們會看到更多專門為這套工作流設計的Obsidian外掛和本地工具。
• 中期來看：這套模式會殺入企業市場。Karpathy說了一句非常扎心的話：「每個企業都有一個ROM，但從來沒有人編譯過它。」未來的企業知識庫不再是員工手動填寫的Confluence，而是由大模型自動從Slack、會議記錄、客戶回饋中編譯出來的活體Wiki。
• 長期來看：這會改變大模型本身的形態。隨著合成資料生成和微調技術的發展，你的個人知識庫最終會融入到大模型的權重裡。它不再需要透過上下文視窗來讀取你的知識，它會真正記住你的知識。到那時，每個人都會擁有一個真正懂你的數位分身。

好了，這就是今天的全部內容。我是為什麼叫QQ，如果你覺得對你有幫助，可以一鍵三連。謝謝！