Mintlify、docs assistantのRAGを virtual filesystemに置き換え

Hacker Newsのfront pageでは、Mintlifyがdocs assistantで使っていた chunked RAG を virtual filesystem に置き換えたという記事が強く反応を集めた。問題設定は明快で、top-K の snippet retrieval は短い質問には強い一方、答えが複数ページにまたがる場合や、agent が正確な syntax を探す必要がある場合にはすぐ限界が出るというものだ。原文は Mintlify の engineering blog にあり、議論は Hacker News で広がった。

Mintlifyは、assistant に chatbot 的な検索ではなく、developer が codebase をたどるような探索をさせたかったと説明している。そのため、毎回 repo を sandbox に clone する代わりに、既存の Chroma database 上に ChromaFs という virtual filesystem を構築した。grep、cat、ls、find、cd のような UNIX-style command を受け取り、それを docs index への metadata/content query に変換する仕組みだ。

• 公開された数値では、sandbox session creation の p90 は約 46 秒だった。
• ChromaFs 導入後は session creation が約 100ms まで短縮された。
• 月 85 万 conversation 規模で naive な micro-VM を使うと、年間コストは 7 万ドル超になり得ると試算している。
• ChromaFs は既存の docs DB を再利用するため、marginal compute cost はほぼ 0 と位置付けている。

HN の読者が特に評価したのは、filesystem mental model は保ちつつ、read-heavy workflow のために本物の sandbox を毎回起動しないという点だった。Mintlify は gzip された __path_tree__ ドキュメントを Chroma に保持し、初期化時に in-memory tree を組み立てたうえで、権限のない path を事前に取り除く。agent から見ると repo tree のように振る舞うが、backend は mounted disk ではなく database だ。

コメント欄でもこの設計は概ね支持された。embedding retrieval ではない、agent にとってより解釈しやすい search pattern が再発見されているという指摘があり、任意コードを実行する agent では VM が必要でも、documentation I/O が中心なら full VM は過剰だという声も目立った。この話が響いたのは、agent tooling を prompt の問題ではなく systems engineering の問題として整理したからだ。interface が fast で interpretable で cheap なら、assistant は vector index から snippet を拾うだけの bot ではなく、docs を歩き回る engineer に近づけるという提案になっている。