Dropbox社のエンジニアは、Dropbox Dashの背後にあるコンテキストエンジンをどのように構築したかを詳述した。そこでは、インデックスベースの検索、ナレッジグラフ由来のコンテキスト、そして継続的評価への移行が示され、企業向けAI知識検索を大規模に支える仕組みが明らかになった。この設計は、企業向けアシスタント全体に広がりつつある傾向を示している。すなわち、チームはライブでのツール利用を意図的に制約し、事前処理され権限を考慮したコンテキストにより強く依存することで、レイテンシを短縮し、品質を向上させ、トークン消費の圧力を軽減しているのである。
最近のエンジニアリング講演の一環として、Dropbox社のエンジニアリング担当VPであるJosh Clemm氏は、このアプリケーションが、企業の業務が多数のSaaSアプリケーションに分散している状況への対応であると説明した。それぞれのSaaSは独自のAPI、権限構造、レート制限を持つ。最新の言語モデルは推論能力を備えているものの、Clemm氏は、企業データへの直接的なアクセスをコンテキストとして持たないと述べた。このため、機密性の高い情報を安全に取得するための追加インフラが必要になるのである。
Dashの中核となるアーキテクチャは、実行時推論による検索ではなく、コンテンツの事前処理に依存している。接続された知識アプリケーションからのデータは、クエリが発行される前に正規化、拡張、インデックス化される。その後、語彙検索とDense Vectorを組み合わせて検索が行われる。この仕組みにより、クエリ時にAPI呼び出しのクモの巣を作ることなく結果を返せる。
この方法は複雑性とストレージコストの増加を伴うが、Dropbox社は、オフラインでのランキング実験、関連性シグナルの改善、予測可能なクエリ時パフォーマンスという利点を考慮すると、投資する価値があると判断したのである。
Dashアプリケーションの主要コンポーネントの一つが、ナレッジグラフを用いて、人、文書、会議などの業務中心のメディア間の関係性モデルを作成する点である。ただし、実行時にグラフデータベースを直接クエリするのではなく、「knowledge bundles」が生成され、前述のインデックス化パイプラインに投入される。Clemm氏は、初期のグラフデータベース実験ではレイテンシやクエリパターンの変化が発生したため、グラフ情報を追加のクエリ層ではなく、コンテキスト拡張の一部として扱うようになったと述べている。
チームはまた、MCP(Model Context Protocol)を通じて複数のツールを言語モデルに直接公開することに伴う課題についても説明した。コンテキストウィンドウの消費を理由に、Dropbox社は、多数のツールを非同期に使用した場合にエージェント性能の低下やクエリの遅延が生じることを観測した。これを回避するため、チームは検索機能を少数の高レベルツールの背後に集約した。これらのツールは、プロンプト外でコンテキストを取得し、より複雑なリクエストをスコープの狭いエージェントにルーティングできる。
MCPの開発者も、複数ツール使用時のコンテキストウィンドウ消費について懸念を表明している。彼らは、ツールを一つ追加するごとに慎重な管理が必要だと述べている。
検索以外の領域では、Dropbox社は大規模なラベル評価の重要性にも触れた。クエリ結果は人間ではなく言語モデルによって消費されるため、従来のクリックベースの関連性シグナルは機能しない。Dropbox社は、言語モデルを審査役として用い、検索品質を測定しスコアリングできた。これにより、プロンプトとランキングロジックを洗練させ、人間ユーザーとのラベリング不一致を減らせた。
Dashチームは、プロンプト最適化フレームワークであるDSPyを用いて評価プロセスを運用化した。Clemm氏は、DSPyが全ワークフローにわたる30以上のプロンプトを管理できたと述べている。これにより、各モデルのプロンプトを手動で書き直すことなく、迅速なモデル切り替えが可能になった。
Dashチームのアプローチは、他の企業向け知識アシスタントで見られるパターンと非常に近い。マイクロソフトのMicrosoft 365 Copilotも、Microsoft Graphから導出された事前計算済みのセマンティックインデックスに依存して、効率的にコンテキストを取得している。
これらの設計は総じて、企業向けAIにおいてコンテキストを推論時にその場で組み立てるものではなく、第一級のシステムとして扱うという潮流が強まっていることを示している。大規模組織内で内部検索やエージェント機能を拡張するにつれ、コンテキストを事前計算し、制約し、継続的に評価するアーキテクチャが、より一般的な基盤となりつつある。