Mintlify 虛擬檔案系統：當技術文件檢索不再等於向量搜尋，讓模型自己 grep/cat/find

核心觀點

Mintlify 這篇最值得看的，不是單純「幫 AI 造一個假的檔案系統」，而是它提醒了一件更重要的事：

RAG 不等於向量搜尋。

對技術文件這類內容，使用者很多時候需要的不是「語意差不多」，而是：

• 精確字串
• 正確語法
• 分散在不同頁面的上下文

這種情境下，讓模型自己去 grep、cat、find，有時反而比預先餵 top-K chunks 更接近人類真的查資料的方式。

---

Mintlify 原本的做法

他們一開始走的是很標準的 RAG pipeline：

• chunk
• embedding
• 丟進 Chroma
• 撈 top-K 給模型

問題是：

• 如果答案跨頁
• 或問題是在問非常精準的 code syntax
• 或需要從不同頁面拼接上下文

那向量檢索就不一定可靠。

---

後來的做法：給模型一個虛擬檔案系統

Mintlify 沒有繼續把 retrieval pipeline 調得更花，而是換了思路：

讓模型以為自己在操作 shell 檔案系統。

模型看到的是：

• ls
• cd
• find
• cat
• grep -r

但實際上每個命令都被攔截，背後轉成資料庫查詢。也就是說，它不是在真的碰磁碟，而是在一個為文件檢索設計的「假檔案系統」上工作。

---

這個方法為什麼強

1. 對技術文件的隱喻很自然

Mintlify 面對的是結構清楚的技術文件：

• 頁面像檔案
• 章節像目錄
• 文件之間本來就有路徑層級

在這種資料形狀下，用檔案系統當檢索介面非常順。

2. 精準檢索能力更強

• cat：把同一頁的 chunks 重新拼回完整頁面
• grep -r：先用 Chroma metadata 粗篩，再把候選內容抓進 Redis，最後做精確匹配
• ls / cd / find：靠預先建立的路徑樹在記憶體裡快速解

這表示它不是只靠 semantic similarity，而是把結構、路徑、全文匹配、頁面重建都納進來。

3. 權限控制更乾淨

初始化時先依使用者身分把整棵檔案樹修掉：

• 沒權限的路徑直接不存在
• 所有寫操作一律回 EROFS

也就是：agent 能看，但不能改。

---

效能與成本數字

這不是只有概念漂亮，數字也真的有差：

• p90 啟動時間：從沙箱方案約 46 秒 → 降到約 100 毫秒
• 每月約 85 萬次對話
• 若每次都啟一個小沙箱，一年額外算力成本超過 7 萬美元
• ChromaFs 因為沿用既有 Chroma 基礎設施，邊際計算成本幾乎趨近 0

這不是小優化，而是整個產品體感都換掉了。

---

更重要的啟示：Retrieval 本來就不只一種樣子

這篇真正有價值的地方，是把一件很容易被忽略的事講清楚：

RAG 的 R 是 Retrieval，不是 Vector Search。

Retrieval 可以是：

• web search
• SQL
• 全文搜尋
• grep
• 結構化檔案遍歷

前幾年大家很快把 RAG 綁死在向量搜尋上，很大一部分只是因為當時模型還不太會用工具，所以先走最省事的路。

但現在模型已經比較會：

• 自己找
• 自己試
• 自己修正檢索路徑

此時，給模型一套好的探索介面，可能比你先替它猜好應該看哪幾段還重要。

---

場景限制

這套方法很吃資料形狀。

適合：

• 結構清楚的技術文件
• 有明顯頁面/章節/路徑層級的知識庫

未必適合：

• 命名混亂
• 結構鬆散
• 層級不明顯
• 文件品質參差不齊的企業內部知識庫

所以它不是萬用解法，但至少把一件事往前推了一步：

做 AI 文件助手時，檢索不需要只長成向量資料庫那一種樣子。