← 返回部落格

Markdown 維基正在悄悄取代 RAG，原因如下

· Save Team
ragllmknowledge-basekarpathymcpaisave-vaultmarkdown

兩年來，「如何將我的知識提供給 LLM？」的預設答案是 RAG。建構向量資料庫。分塊文件。嵌入它們。在查詢時執行最近鄰搜尋。將結果拼接回提示詞。

它有效，某種程度上。任何真正交付過 RAG 系統的人都知道失敗模式：失去上下文的塊、擷取錯誤段落的嵌入、不透明的排名、沒有溯源、當使用者問了一些索引未調優的問題時出現奇怪的邊緣案例。

2026 年 4 月，Andrej Karpathy 發布了一個幾乎不做這些但對個人知識效果更好的工作流程。他稱之為 LLM 知識庫。架構只是一個 Markdown 資料夾、一個有檔案系統存取權限的 LLM 和一個習慣。VentureBeat 稱之為「由 AI 維護的不斷演化的 Markdown 庫」——這個描述抓住了真正新穎之處。

後 RAG 模式已經到來。本文解釋它是什麼、為什麼有效，以及 Save Vault 如何讓它無需開發者設定就能使用。

RAG 試圖解決的問題

最初的問題：LLM 有固定的上下文視窗，你的知識庫比視窗大，所以你需要一種為每個問題擷取相關部分的方法。

2023 年，向量是顯而易見的答案。嵌入一切，按相似度搜尋，注入前 k 個塊。它與 GPT-3.5 和 Claude 1 的小上下文視窗很好地組合。整個「AI 新創」模式是「X 上的 RAG」。

三件事發生了變化。

  1. 上下文視窗爆炸。 Claude 今年推出了 100 萬 token 上下文。Gemini 和 GPT-5 類似。100 萬 token 大約相當於 75 萬詞——足以將小型維基完全保存在記憶體中。
  2. 檔案系統 MCP 推出。 LLM 現在可以直接開啟磁碟上的檔案。它們不需要預先索引的塊。它們可以像人類一樣導覽、閱讀和重新閱讀。
  3. LLM 在閱讀上變得更好。 Claude Opus 4 可以在一個會話中摄取數百個檔案並連貫地跨它們推理。瓶頸從「擷取品質」移到了「人類實際需要什麼」。

一旦這三件事成真，RAG 開始看起來像是對已不再存在的限制的一種變通方法。

Markdown 維基模式是什麼樣的

Karpathy 的設定，簡化版：

  1. 原始資料夾。 他想保留的每個網頁都作為 .md 檔案儲存在 raw/ 目錄中。他用 Obsidian Web Clipper 來做這件事。
  2. 編譯過程。 定期地，一個 LLM 代理（他使用的是 Claude Code）讀取 raw/ 中的所有內容，生成概念頁面，寫摘要，建立反向連結。這在原始材料之上產生了一個結構化的維基。
  3. 查詢迴圈。 當他有問題時，他向 LLM 提問。它搜尋維基，開啟相關檔案，用內容回答。
  4. 程式碼檢查過程。 偶爾 LLM 會掃描維基，尋找不一致、缺失資料或值得記錄的新連接。

他目前的研究維基有約 100 篇文章和約 40 萬詞。他向它提出複雜問題，得到帶有來源的答案。

沒有向量資料庫。沒有嵌入模型。沒有分塊策略。沒有擷取排名。只是 Markdown 檔案、資料夾結構和能讀取它們的 LLM。

為什麼它比 RAG 更好（對此而言）

維基模式具有 RAG 無法在不成為維基的情況下匹敵的結構優勢。

溯源是免費的。 每個答案都引用一個檔案。你可以開啟它、閱讀它、編輯它、刪除它。沒有「嵌入如此說」。

編輯是微不足道的。 Markdown 檔案是文字。在任何編輯器中開啟它。修改錯別字。添加筆記。刪除一個部分。下一次查詢立即反映變化。沒有重新嵌入步驟。

結構在複利增長。 當 LLM 編譯維基時，它建構反向連結和概念頁面。隨著你儲存更多，維基會變得更好，因為 LLM 有更多上下文將新條目與現有內容連接。向量索引只是變得更大。

可攜帶性是完全的。 一個 .md 資料夾在 Obsidian、VS Code、GitHub、Logseq、vim 或 cat 中都能工作。向量資料庫是一個黑箱，你需要特定的執行時間來讀取它。

你自己也可以讀它。 這聽起來很明顯，但這是最大的優勢。你有時會想知道你的知識庫裡有什麼。用 RAG，這是一個報告查詢。用 Markdown，這是 ls。

誠實的權衡：RAG 在你有數百萬文件、多租戶存取或硬延遲限制時仍然勝出（想想在數百萬幫助文章語料庫上的客戶支援聊天機器人）。對於個人知識——你的閱讀、你的研究、你的領域——維基模式現在嚴格地更好。

缺失的部分：攝取

Karpathy 的模式有一個靜默的假設：將乾淨的 Markdown 放入 raw/ 資料夾是容易的。對於已經使用 Obsidian Web Clipper 的開發者來說，某種程度上確實如此。對其他人來說，這是工作流程死亡的步驟。

Web Clipper 可能在付費牆頁面、重度 JavaScript 網站、影片內容、X 推文線程以及任何動態內容上遇到困難。人們儲存了亂碼的 HTML，放棄了，並得出結論「維基這個東西不適合我」。

Save 擴充功能專門用於修復這一步驟。它使用 Gemini 從任意頁面擷取乾淨內容，包括：

  • 你有存取權限的付費牆後的文章
  • YouTube 影片（完整字幕 + AI 摘要）
  • X/Twitter 推文線程
  • Instagram Reels 和 TikTok 字幕（已轉錄）
  • Reddit 討論
  • 程式碼區塊完整的文件
  • 傳統爬蟲無法處理的動態 SPA

一次點擊。乾淨的 Markdown 輸出。放入資料夾。

另一個缺失的部分：MCP 設定

Karpathy 的模式還假設你可以配置 MCP 伺服器。對於 Claude Code 使用者，這是一行 cd。對於使用 Claude Desktop 的所有人，這意味著編輯 JSON 配置檔案並重啟應用——還要確保路徑正確，並記住在移動資料夾時重做。

Save Vault 將兩個缺失部分整合為一個應用程式：

  • Save 擴充功能自動將乾淨的 Markdown 輸入 Save Vault
  • Save Vault 寫入 ~/Documents/Save Vault/，組織成知識庫（子資料夾）
  • 內建 MCP 伺服器將 list_knowledge_bases、list_files、read_file 和 search 暴露給 Claude
  • 選單列中的「連接到 Claude」切換按鈕將 MCP 伺服器連接到 Claude Desktop 和 Claude Code，無需編輯 JSON

結果是磨平了粗糙邊緣的 Karpathy 模式。儲存頁面 → 它落入你的 Vault → Claude 可以回答關於它的問題。沒有向量資料庫，沒有分塊，沒有嵌入。

實踐中是什麼樣的

想像你在研究一個競爭對手。

第 1 天。 你儲存了他們的定價頁面、三篇部落格文章和一個關於他們種子輪的 Hacker News 貼文。你的 Competitors 知識庫中有五個檔案。

第 5 天。 你問 Claude：「這家公司去年做了哪些定價變化，客戶是如何反應的？」 Claude 搜尋你的 Competitors 知識庫，讀取相關檔案，引用定價頁面，呈現 HN 貼文情緒，並回答——全部帶有來源。

第 30 天。 你有 40 個檔案分布在 Competitors、Customers 和 AI Research 中。你讓 Claude 將每個知識庫編譯成維基。它寫概念頁面，連接它們，標記矛盾。你現在擁有三個活生生的維基，你可以像搜尋引擎一樣查詢，但更好——因為它們只包含你策劃的內容。

第 90 天。 你的維基比你購買的任何分析師報告都更大，比任何顧問簡報都更新，完全屬於你。每一個主張都有源於你儲存的檔案。

這就是當摩擦消失後，個人知識庫真正的感覺。RAG 應該實現這個但沒有。Karpathy 模式實現了——一旦攝取和 MCP 部分為你連接好了。

試試看

  1. 安裝 Save Chrome 擴充功能
  2. 從 savemarkdown.co 安裝 Save Vault
  3. 在選單列中切換連接到 Claude
  4. 儲存 10 件你一直想閱讀的東西
  5. 開啟 Claude 並提出一個將它們聯繫在一起的問題

這就是後 RAG 工作流程。它已經在取代個人知識的向量資料庫。唯一剩下的就是開始建構你自己的。

Save Vault 是免費的。Save 擴充功能每月 3 次免費儲存，無限次 3.99 美元/月。savemarkdown.co。