AIドキュメントアシスタント向けのRAG代替仮想ファイルシステムの構築

 (mintlify.com)
3 ポイント 投稿者 GN⁺ 25 일 전 | 1件のコメント | WhatsAppで共有
  • 従来のRAGベース検索の限界を克服するため、ドキュメントをファイルとディレクトリで構成した仮想ファイルシステム構造へ移行
  • 実際のファイル複製なしにChromaデータベースを基盤としてgrep、cat、ls、findコマンドを実行できるChromaFsを実装
  • この方式により、セッション生成時間を46秒から100ミリ秒へ短縮し、追加の計算コストを0ドル水準まで削減
  • アクセス制御はファイルパスメタデータのRBACフィルタリングで処理され、別個のコンテナやユーザーグループ管理が不要
  • 結果としてMintlifyドキュメントアシスタントは、即時応答、低コスト、ステートレス構造を備えた大規模サービスとして運用可能

RAGの限界を超える仮想ファイルシステムアプローチ

  • 従来のRAGベースのドキュメント検索は、クエリに一致するテキスト断片だけを返すため、複数ページにまたがる回答や正確なフレーズ検索が難しかった
  • これを解決するため、ドキュメント構造をファイルシステムのように探索可能な形へ変換し、各ドキュメントページをファイルに、セクションをディレクトリにマッピング
  • エージェントはgrep、cat、ls、findコマンドでドキュメントを直接探索でき、開発者がコードベースを扱うようにドキュメントを検索できる構造として設計された

コンテナのボトルネック問題

  • 一般的なアプローチは、エージェントに実際のファイルシステムを提供するために隔離されたサンドボックス環境を生成し、リポジトリを複製する方式
  • しかしフロントエンドアシスタントではセッション生成の遅延が深刻で、p90セッション生成時間は約46秒に達していた
  • 月85万回の会話を基準にすると、最小構成（1 vCPU、2GiB RAM、5分のセッション維持）でも年間7万ドル以上のインフラコストが発生
  • このボトルネックを解消するため、即時応答し低コストで動作する仮想ファイルシステムが必要だった

仮想シェルの実装 — ChromaFs

  • 実際のファイルシステムの代わりに、**仮想的なファイルシステムの幻影（illusion）**だけを提供
  • 既存のドキュメントデータはすでにChromaデータベースにインデックスされていたため、それを基盤にChromaFsを構築
  • ChromaFsはUNIXコマンドを横取りしてChromaクエリに変換する
  • その結果、セッション生成時間は46秒から100ミリ秒へ短縮され、追加の計算コストは0ドル水準まで減少
Metric Sandbox ChromaFs
P90 Boot Time 約46秒 約100ms
Marginal Compute Cost 約$0.0137/会話 約$0
Search Mechanism ディスクスキャン DBメタデータクエリ
Infrastructure Daytonaなどの外部サンドボックス 既存DBの再利用
  • **just-bash (Vercel Labs)**を基盤に実装され、grep、cat、ls、find、cdコマンドをサポート
  • just-bashのIFileSystemインターフェースを活用し、パイプ処理やフラグロジックはそのまま維持しつつ、ファイルアクセス呼び出しをChromaクエリへ変換

ディレクトリツリーのブートストラップ

  • ChromaFsは実行前にどのファイルが存在するかを把握する必要があるため、ファイルツリー全体を**圧縮JSON（__path_tree__）**の形でChromaコレクションに保存
  • サーバー初期化時にこれを取得し、2つのメモリ構造へ復元
    • ファイルパスのSet<string>
    • ディレクトリごとの子要素一覧のMap<string, string[]>
  • 以後、ls、cd、findコマンドはネットワーク呼び出しなしでローカルメモリ上で即時処理され、同一サイトの後続セッションではキャッシュされたツリーを再利用

アクセス制御

  • パスツリーにはisPublicおよびgroupsフィールドが含まれており、ユーザーのセッショントークンに基づいてアクセス可能なファイルだけを残す
  • アクセス権のないファイルはツリーから完全に削除されるため、エージェントはそのパス自体を認識できない
  • 従来のサンドボックスではこのためにLinuxユーザーグループ、chmod、コンテナ分離などを管理する必要があったが、ChromaFsでは単純なフィルタリングロジックだけでRBACを実装
Path Access Visible
/auth/oauth.mdx public ✓
/auth/api-keys.mdx public ✓
/internal/billing.mdx admin, billing ✗
/api-reference/users.mdx public ✓
/api-reference/payments.mdx billing ✗

ドキュメント断片の再構成

  • Chromaに保存されたドキュメントは、埋め込みのために複数の断片へ分割されている
  • cat /auth/oauth.mdx実行時には、同じpageスラッグを持つすべての断片を取得し、chunk_index順に並べて結合
  • 結果はキャッシュされるため、繰り返しのgrepワークフローでもDBへの再問い合わせは発生しない
  • 大規模なOpenAPI仕様などは**遅延ロードポインタ（lazy file pointer）**として登録され、アクセス時にのみS3から取得
  • すべての書き込み操作はEROFS（読み取り専用ファイルシステム）エラーを返し、**セッション状態を持たない（stateless）**安全な構造を維持

Grepの最適化

  • grep -rコマンドは単純なネットワークスキャンでは非常に遅いため、2段階フィルタリング構造で最適化
    • 1段階目: Chromaクエリ（$contains、$regex）を用いて候補ファイルを選別
    • 2段階目: Redisキャッシュに事前取得した後、just-bashでメモリ内の精密フィルタリングを実行
  • これにより、大規模な再帰検索もミリ秒単位で完了可能

結論

  • ChromaFsは、1日3万件以上、数十万人のユーザーが利用するMintlifyドキュメントアシスタントを支えている
  • サンドボックスを置き換えることで、即時セッション生成、0に近い追加コスト、組み込みRBAC、ステートレス構造を実現
  • Mintlifyのすべてのドキュメントサイトで直接利用可能（mintlify.com/docs）

関連記事

1件のコメント

 
GN⁺ 25 일 전
Hacker Newsのコメント

  • ファイルシステムベースの検索が再び注目されている理由は、埋め込みベースではない意味検索の形を再発見しているからだと思う
    図書館司書がテーマごとに本を書棚に整理するように、ファイルをドメイン別に構成する方法のほうが解釈しやすい
    昔から存在した検索方式だが、その価値をようやく再認識している
    関連ブログ記事

    • 伝統的な図書館情報学は、情報構造の深いパターンをすでに捉えていた
      PixarのRalph Wrecks The Internetでもこの概念がうまく表現されていた
      参考ツイート1, 参考ツイート2
    • 400個を超えるPythonファイルがあるコードベースで作業しているが、埋め込みベースのRAGは単語が似ている的外れなコード断片をよく持ってきた
      その代わりにエージェントがディレクトリツリーを直接たどれるようにしたところ、30秒でモジュール構造を把握し、正しいファイルを要求し始めた
      ディレクトリ階層そのものが、すでに人間が作った知識グラフだったことを忘れていた
    • LLM検索システムを作っていたら、結局逆引き索引(concordance) を再発明することになった
      これはGoogleのinverted indexと同じ概念で、実際にはまったく新しいものではない
    • 誰かがRAGは必ずベクトル検索を使うものだと仮定し、みんながその流れに乗ったように見える
    • AIアシスタントは結局、LLMが自動補完する仮想の登場人物なので、人間の言語的相互作用のように解釈可能なメカニズムのほうが有利だ

  • RAGでは、私に内容を直接読む手段が与えられなかった
    そこで今は、知識をMarkdownベースの静的ページとして統合し、修正後にJSONファイルをビルドして、エージェントがこのソースに問い合わせるようにしている
    説明リンク

  • ファイルシステム検索がRAGより優れているという主張は混乱を招く
    grepのようなキーワード検索は古いやり方で、RAGはベクトル検索を使う
    しかしデータベースでは、コンテンツを階層、タグ、任意の構造でインデックス化できる
    検索はキーワード、ベクトル、tf-idf、BM25など、さまざまな組み合わせが可能だ
    ファイルシステムに戻るのは、60年代レベルの技術に逆戻りするようにも感じる

    • その通りだが、実際にはエージェントがファイルベースで作業すると性能が良くなる
      CLIベースのコーディングエージェントは、ファイルにアクセスするときのほうがずっと賢く振る舞う
    • 私はデータベースベースのagentic searchで良い結果を得ている
      重要なのは、エージェントが多様なad-hocクエリを自分で実行できることだ
      埋め込みと全文検索の両方をサポートするDBで、エージェントが自由に問い合わせられれば十分にagenticだ
    • 実際のところ、ほとんどのファイルシステムも内部的にはデータベース構造を使っている
      ファイルシステムをDBのように使うこと自体は新しい話ではない
    • 記事で述べられていたアプローチは、結局これなのではないかと思う
    • 複数のデータソースをエージェントが直接探索できるようにするほうが良いと思う

  • 月85万件の会話で年間7万ドル以上かかるという計算は奇妙に聞こえる
    CPUとメモリをどこでそんなに使うのか気になっていたが、Vercel Labsのjust-bashベースChromaFsが原因だった

    • 各エージェントに隔離されたコンテナを与えると、何もしなくてもメモリを占有し続けるため、コストが膨らむ

  • CLIアプリケーションの復興期を楽しんでいる
    FUSEでMacの実ファイルシステムをミラーする仮想ファイルシステムを作り、エージェントをそのツリーの中だけに制限している
    各リポジトリごとに長時間実行のエージェントを置き、権限は仮想ファイルシステムで制御する
    プロジェクト bashguard

  • 私たちは仮想ファイルシステム(VFS) とRAGの両方を使っている
    RAGの核心はデータ品質であり、文書を意味単位に分割し、メタデータとリンクを生成する
    voyage contextual embeddingで各チャンクを文書と一緒に埋め込む
    検索時には、エージェントはリンクをたどるか、原文を解析できる
    rerankingの品質が性能に大きく影響する

    • 私たちのVFSはPostgresベースで、ファイル/ディレクトリの形に投影される
      grep、bm25、jq、プレビュー用ツールなどをサポートし、Pydantic AI上で動作する

  • POSIXシェルをTypeScriptでエミュレートして階層検索を行うのは、過剰設計に見える
    lsやgrepを実行するたびに推論サイクルが増え、レイテンシが大きくなる

    • チャンクの上にFUSEを載せる方式なら、シェルのエミュレーションは不要な気がする

  • 技術スタックはよく分からないが、なぜわざわざ偽のシェルを作ったのか気になった
    FUSEソリューションのほうが自然に見える

    • 実際にFUSEアダプタは検討したが、速度が遅すぎた
      POSIX完全互換は必要なく、読み取り専用の文書探索だけできればよかった
      そのため、bashコマンドの一部だけをサポートする方式のほうが簡単だった

  • 文書をファイルシステムツールでアクセス可能にする文脈では、VercelのAI SDKが興味深い
    npmパッケージのルートに.mdx文書を含め、エージェントがまずローカル文書をgrepするよう促している
    SKILL.mdの例

  • Mintlifyのようなスタートアップには良いアプローチだが、複雑な組織では実用性が落ちるかもしれない
    構造が非階層的だったり、文書が入り混じっていたりする環境では、RAGのほうが有用だ

    • ここではコード検索という明確なユースケースがあるので単純だ
      RAGは万能ではなく、Claude Codeチームも同じ結論に達していた
    • OCR技術が十分進歩しているので、文書がOCR可能ならこのアプローチも一般化できる
    • 複雑な文書組織の上にVFSを被せると、結局はインデクサの変形にすぎず、アクセス制御がなければセキュリティ上の問題が生じる