【要約】MCPツールが多すぎてLLMが壊れる問題をBM25で解決した話 — tool-search-oss [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
MCPサーバーを複数利用する開発者が、ツール定義の肥大化によるLLMの性能低下という問題に直面している。便利なツールを追加し続けるほど、LLMの推論能力は著しく損なわれる。
- ・コンテキスト崩壊：ツール定義が膨大になると、LLMの注意機構が機能せず誤ったツールを呼ぶ。
- ・レイテンシの悪化：2,000ツール環境では、最初のレスポンスまで55秒もの時間を要する。
- ・トークン消費の増大：全定義をコンテキストに詰め込むと、入力トークン数が数万規模に達する。
- ・運用コストの増大：トークン使用量の増加は、API利用料金の直接的な上昇を招く。
// Approach
開発者が「tool-search-oss」を導入することで、必要なツールのみをLLMに渡す動的な仕組みを実現する。これはAnthropicが提唱した「defer_loading」パターンをOSSとして再実装したものである。
- ・Strategy Patternの採用：BM25や将来的な手法への差し替えを容易にする設計。
- ・BM25による検索：クエリをトークン化し、IDF（逆文書頻度）に基づきツールをスコアリング。
- ・段階的ロード：検索結果の上位ツール定義のみをLLMのコンテキストへ注入する。
- ・ゼロ依存の設計：MCPサーバー側のコードを変更せずに、ルーターとして機能させる。
// Result
開発者がこのルーターを導入することで、大規模なツール環境でも実用的な速度と精度を維持できる。これにより、ツール数に依存しないスケーラブルなエージェント構築が可能となる。
- ・高速化：2,000ツール環境でTTFTを135.7倍改善（55秒 $\to$ 408ms）。
- ・コスト削減：入力トークン数を99.8%削減（31,526 $\to$ 59トークン）。
- ・精度向上：ルーティング精度を34.0%から56.7%へ引き上げ。
- ・低遅延な検索：BM25の検索レイテンシは1.12msであり、外部API呼び出しも不要である。
Senior Engineer Insight
> 大規模エージェント開発において、ツール管理は避けて通れない課題だ。BM25による軽量な検索は、低レイテンシが求められる現場で極めて実用的である。ただし、現状の英語特化型トークナイザーは日本語環境では機能しない。次期バージョンのVisual Topology Routerによる視覚的アプローチが、多言語対応と複雑な依存関係の解決に寄与するか注視すべきだ。