我們為 AI 文檔助手開發了虛擬文件系統來取代傳統 RAG 架構

背景

Mintlify 團隊分享了他們如何捨棄傳統的 RAG（檢索增強生成）架構，轉而為 AI 助手開發一套虛擬檔案系統 ChromaFs。他們發現傳統 RAG 在處理跨頁面資訊或精確語法檢索時效果不佳，因此決定將文件結構映射為目錄與檔案，讓 AI 代理透過 grep、ls、cat 等標準 UNIX 指令來探索文件。為了兼顧效能與成本，他們並未採用真實的容器沙盒，而是開發了一個能將 Bash 指令轉譯為資料庫查詢的虛擬層，成功將啟動延遲從 46 秒降至 100 毫秒。

社群觀點

這篇技術分享在 Hacker News 引發了關於檢索技術本質的深度討論。許多留言者指出，這其實是業界對「語義搜尋」的一種重新發現。長期以來，開發者過度迷信向量資料庫與嵌入模型，認為這就是 RAG 的全部，但事實上 RAG 的核心在於「檢索」，而檢索並不等同於向量搜尋。社群普遍認同將文件組織成層級化的檔案系統，能讓 AI 代理更直觀地理解資訊脈絡，這種做法回歸了圖書館員組織知識的傳統邏輯，比單純的碎片化塊狀檢索更具可解釋性。

然而，對於 Mintlify 選擇「模擬」檔案系統而非使用真實環境的作法，社群出現了分歧。有評論者質疑，如果目標只是為了執行 grep 或 ls，直接提供對應的工具接口給大型語言模型即可，何必大費周章模擬整個 Bash 環境。對此，作者回應指出，模擬層能極大地降低基礎設施成本與延遲，且能更輕易地實作基於用戶權限的存取控制。另一派意見則認為，如果資源充足，使用 FUSE 掛載或是 RAM Disk 可能會是更標準且高效的解決方案。

此外，部分資深開發者感嘆，當前 AI 領域似乎遺忘了布林運算與倒排索引等成熟技術的威力。他們認為，大型語言模型在構建查詢語句上表現優異，若能結合 Lucene 等傳統搜尋引擎，往往能比純向量檢索達到更好的效果。討論中也提到，這種「代理式搜尋」雖然強大，但也對模型的提示詞工程與護欄機制提出了更高要求，因為 AI 必須自主決定探索路徑，而非僅是被動接收檢索結果。整體而言，社群達成了一項共識：向量搜尋不應被視為萬靈丹，而應只是 AI 代理工具箱中的眾多工具之一。

延伸閱讀

在討論串中，參與者分享了幾項值得關注的資源。首先是 softwaredoug 撰寫的部落格文章《Semantic Search Without the Vector DB》，深入探討了非向量式的語義搜尋可能性。其次是 Vercel Labs 開發的 just-bash，這是 Mintlify 虛擬檔案系統底層所使用的 TypeScript 版 Bash 實作。另外，也有人提到 Claude Code 團隊近期也得出了類似結論，即傳統 RAG 在複雜工程場景中並非銀彈。最後，對於想在本地端建立知識庫的用戶，討論中推薦了 Ollama 與 Gemini 等工具作為替代方案。