Mintlify 用虛擬檔案系統取代 RAG，改變了什麼？

RAG 真的解決了文件檢索的所有問題嗎？

這個問題在 AI 文件助理的開發社群裡越來越常被問到。檢索增強生成（RAG）過去兩年成為標準做法：先把文件切成小塊，用向量資料庫儲存，當使用者問問題時，找出最相關的幾塊餵給 AI。這個方法看起來很合理，但實際使用時卻常遇到問題——AI 有時候只拿到片段資訊，看不到完整的上下文，導致回答不夠精準或缺乏連貫性。

Mintlify，這個專注於技術文件的平台，最近做了一個有趣的實驗：他們用一個虛擬檔案系統 ChromaFs 取代了傳統的 RAG 架構。這個改變不是為了炫技，而是為了解決一個實際的問題：讓 AI 文件助理能夠像真正的開發者一樣「瀏覽」文件，而不是只拿到幾個被切斷的段落。

為什麼 RAG 不夠好

要理解 Mintlify 的創新，先得看清楚 RAG 的局限。

傳統的 RAG 流程是這樣的：你把文件切成小段（比如每段 512 個 token），用嵌入模型轉成向量，存到向量資料庫。使用者提問時，系統根據問題的向量相似度，找出最相關的幾段（通常是 5-10 段），然後把這些段餵給大語言模型，讓它基於這些資訊回答問題。

這個方法在很多場景下都很好用，但它有幾個明顯的問題：

第一，上下文被切斷了。

開發者查閱文件時，往往會在多個頁面之間跳轉，追蹤一個 API 的使用範例，然後翻到參數說明，再跳到相關的錯誤處理指引。這是一個連續的探索過程。但 RAG 只是把幾個看似相關的片段拼在一起，這些片段之間的關聯性可能已經被切斷了。AI 看到的是「第 3 段、第 15 段、第 42 段」，而不是一個完整的敘事。

第二，探索路徑無法調整。

想像你在查一個複雜的問題。讀了第一段後，你可能發現自己看錯方向了，需要調整查詢詞，或者你發現某個關鍵字很重要，想專門查這個關鍵字。傳統的 RAG 一次查詢就定死了，AI 無法「發現」新線索後再深入。但真正的檢索過程應該是互動的——你得到一些資訊，然後基於這些資訊調整你的下一步行動。

第三，無法理解檔案結構。

技術文件通常有明確的組織結構：章節、子章節、程式碼範例、API 參考、最佳實踐。RAG 把所有東西扁平化處理，當作獨立的段落。這意味著 AI 無法利用這個結構——它不知道某個參數的說明是哪個 API 的一部分，也不知道某個範例屬於哪個章節。

這些問題在很多實際場景中會顯現出來。舉例來說，當使用者問「如何設定 API 金鑰」時，RAG 可能會找回幾個提到「API 金鑰」的段落，但如果真正關鍵的資訊分散在認證章節、環境變數設定範例和錯誤處理說明中，RAG 的回答可能就會不夠完整。

ChromaFs：虛擬檔案系統的思路

Mintlify 的解法是：給 AI 一個「虛擬檔案系統」。

這個概念的核心很簡單：不要讓 AI 只能「讀取幾個段落」，而是讓它能夠「瀏覽一個檔案系統」。就像你在本機瀏覽資料夾和檔案一樣，AI 可以列出目錄、讀取檔案內容、根據需要深入特定子目錄。

技術實作上，ChromaFs 建立在 Chroma 向量資料庫之上，但提供了一個檔案系統的介面。從 AI 的角度來看，它不是「查詢向量資料庫」，而是「操作一個檔案系統」：

# AI 可以執行類似這樣的操作
ls /api/authentication/     # 列出認證相關的檔案
cat /api/authentication/setup.md  # 讀取設定的說明文件
find "API key"              # 搜尋包含 "API key" 的檔案

這個設計有幾個關鍵的優勢：

上下文連續性。

當 AI 決定「我需要看認證章節」時，它讀取的是整個認證章節的內容，而不是被切斷的幾個段落。這樣它能看到完整的流程：從註冊帳號、產生金鑰、設定環境變數，到錯誤處理。AI 可以像人類一樣「讀完這個章節再決定下一步」。

動態探索能力。

如果 AI 在讀取某個檔案時發現了一個新的關鍵字，它可以基於這個發現調整搜尋策略。舉例來說，它在讀「OAuth 2.0 設定」時，看到「refresh token」很重要，它可能會專門搜尋關於 refresh token 的文件。這是一個真正的「探索過程」，而不是一次性的查詢。

結構化理解。

虛擬檔案系統保留了原本文件的組織結構。AI 知道某個參數說明檔案是哪個 API 端點的一部分，也知道某個範例程式碼屬於哪個章節。當使用者問「參數 X 的格式是什麼」時，AI 可以精確地找到 /api/endpoint-x/parameters.md 而不是泛泛地搜尋整個資料庫。

實際運作：30 天的流量分析

Mintlify 在 2026 年 3 月發布了一份分析報告，追蹤他們文件網站 30 天的流量來源。這份數據很有意思，因為它反映了 AI agent 正在如何使用文件資源。

根據 Mintlify 的分析，文件訪問來源可以分為幾個類別：瀏覽器（人類使用者）、AI agents（像是 ChatGPT、Claude 等工具的自動訪問）和其他來源。這個數據顯示，AI agents 的流量正在顯著增加——愈來愈多的開發者在使用 AI 工具來查閱文件，而不是直接瀏覽。

這個趨勢帶來一個重要的啟示：文件不再只是為了「人類閱讀」而設計，它們也必須是「機器可讀」的。如果 AI agent 能夠更有效地理解和使用文件，那麼使用 AI 查閱文件的開發者就會有更好的體驗。

ChromaFs 正是為了這個目標而設計：讓 AI agent 能夠用更「像人類」的方式瀏覽文件，從而給使用 AI 工具的開發者帶來更準確、更有用的答案。

技術細節：如何實作虛擬檔案系統

從技術實作的角度來看，ChromaFs 有幾個值得關注的設計決策。

檔案系統的映射。

ChromaFs 需要一個機制把原本的文件結構映射到虛擬檔案系統。Mintlify 的做法是：每個文件頁面對應一個虔擬檔案，檔案路徑反映原本的章節結構。舉例來說，一個原本在 https://docs.example.com/api/authentication/setup 的頁面，在虛擬檔案系統中可能會是 /api/authentication/setup.md。

搜尋和瀏覽的平衡。

ChromaFs 仍然利用 Chroma 的向量搜尋能力，但搜尋不是一次性「拿回幾個段落」，而是「建議可能的檔案路徑」。AI 可以根據搜尋結果決定要讀取哪些檔案，或者搜尋結果本身就可以作為「瀏覽的起點」。

上下文管理。

因為 AI 可以多次讀取檔案，ChromaFs 需要管理上下文——哪些檔案已經被讀取過了、當前的瀏覽路徑是什麼、哪些資訊已經累積。這樣 AI 就可以避免重複讀取相同的檔案，也能夠記住之前讀到的資訊，建立更連貫的理解。

效率考量。

給 AI 一個虛擬檔案系統聽起來像是會增加操作次數（因為可能要讀取多個檔案），但實際上效率可能反而更高。因為每次讀取的資訊更有針對性，AI 不需要處理大量不相關的段落。而且虛擬檔案系統可以快取已經讀取的檔案，重複使用時就不需要重新檢索。

對開發社群的啟示

Mintlify 的這個實驗，提供了一些值得深思的啟示。

RAG 不是唯一途徑。

過去兩年，RAG 幾乎成了 AI 檢索的標準答案，但我們開始看到更多創新的方法。虛擬檔案系統、圖譜檢索（graph retrieval）、多輪檢索（iterative retrieval）——這些方法各有優勢，適合不同的場景。選擇什麼方法，應該根據實際的需求和問題。

AI 的「瀏覽模式」值得研究。

人類瀏覽文件的模式經過幾十年演化，已經形成一些固定的習慣：從目錄開始、跳轉到相關章節、尋找範例程式碼、查看參數說明。AI 的瀏覽模式應該模仿人類嗎？還是應該發展出更適合它自身能力的方式？Mintlify 的虛擬檔案系統是一種折衷——讓 AI 能夠用類似人類的方式瀏覽，但仍然充分利用它的計算和記憶能力。

文件設計需要重新思考。

如果 AI agents 會成為文件的重要使用者，那麼文件的設計應該如何調整？標題應該更清楚嗎？範例程式碼應該更容易提取嗎？相關連結應該更明顯嗎？這些問題在未來會變得愈來愈重要。

開發者工具的演進。

從 Git 到 GitHub、從 Stack Overflow 到 ChatGPT，開發者獲取資訊的方式一直在演進。虛擬檔案系統這種創新，代表了一個新的方向：不是「給開發者更好的搜尋工具」，而是「讓開發者使用的 AI 工具有更好的檢索能力」。這個差別雖然微妙，但影響可能很深遠。

實際應用的考量

對於考慮採用類似技術的團隊，有幾個實際面向值得思考。

何時適用虛擬檔案系統？

如果你的文件有明確的結構、使用者需要深度探索、問題往往需要跨越多個章節才能解答，那麼虛擬檔案系統可能是個好選擇。但如果你的文件內容很分散、結構不明確，或者使用者問的問題都很簡單直接，那麼傳統的 RAG 可能就足夠了。

實作成本。

ChromaFs 類似的系統需要額外的實作工作：設計檔案系統的映射、管理上下文、優化搜尋和瀏覽的平衡。如果你的資源有限，可以先從簡單的 RAG 開始，再逐步優化。

效能監控。

無論採用什麼技術，都需要監控實際的效果：使用者的回饋、答案的準確度、回應速度。數據會告訴你什麼地方需要改進。

逐步迭代。

Mintlify 的實驗不是一次到位的。他們可能先試了純 RAG，發現問題後再嘗試改進。對大多數團隊來說，逐步迭代、基於實際數據做決定，比一開始就追求「完美解法」更實際。

看著 Mintlify 的這個創新，不禁讓人想到一個有趣的可能性：未來的文件瀏覽器可能會長什麼樣樣？它會是今天的瀏覽器加上一個 AI 機器人嗎？還是會是像 ChromaFs 這樣的虛擬檔案系統介面，讓你（或你使用的 AI 工具）用更靈活的方式探索資訊？

技術的演進往往不是直線的。我們以為 RAG 是終極答案，但可能只是起點。虛擬檔案系統、多輪檢索、圖譜搜尋——這些方法可能會互相結合，產生我們今天還想像不到的新模式。重要的是保持開放的心態，從實際問題出發，而不是追隨某個「標準答案」。

畢竟，最好的技術不是最流行的那個，而是最能解決你問題的那個。