技術要約: LLMRouter

問題提起

大規模言語モデル（LLM）の急速な普及により、単一のモデルがすべてのクエリや予算制約に対して最適であるとは限らない、不均質なエコシステムが生み出されています。どのモデルが特定のクエリを処理すべきかを決定する「モデル・ルーティング」は、コスト効率の高いデプロイメントに不可欠ですが、現在の分野には統一された基盤が欠けています。既存のアプローチ（バイナリ品質予測器からエージェント型ルーターまで）は、以下の3つの重大な課題を抱えています：

1. 形式の不一致: 手法が異なるフレームワークの下で開発されており、コードベースやインターフェースが分離しているため、性能を左右する設計要素を特定することが困難です。
2. 標準化された評価の欠如: ルーターの評価は単一モデルの評価よりも要求水準が高くなります。なぜなら、監督学習のためのデータ構築とコスト・品質のトレードオフを測定するために、すべての候補モデルをすべてのクエリに対して実行する必要があるからです。既存のベンチマークは固定されたモデルプールに対して回答を事前計算していることが多く、シングルターンのテキストタスクに限定されており、マルチターンやパーソナライズされたシナリオをサポートできていません。
3. 断片化された開発: 新しいルーターやベンチマークを追加する際、単なる設定変更ではなく、実験スタック全体の再設計が必要となります。

手法

1. LLMルーティングの統一的な定式化

著者らは、LLMルーティングを**逐次決定プロセス（sequential decision process）**として定式化することを提案しています。このフレームワークにおいて、ルーターは入力クエリ $q$、オプションのユーザーコンテキスト $u$、および対話履歴 $h_t$ からなる状態 $s_t = (q, u, h_t)$ を観測します。ルーターは、プール $\mathcal{M}$ 内の候補モデル $m$ に状態をディスパッチするか、あるいはエピソードを終了するというアクション $a_t$ を取ります。目標は、応答品質と推論コストの加重目的関数を最大化する方策 $\pi$ を学習することです：
$$\pi^* = \arg\max_{\pi} \mathbb{E}_{q, \tau \sim \pi} [\text{perf}(y|q) - \lambda \cdot c(\tau)]$$
この定式化の下では、あらゆるルーターは以下の5つのコンポーネントによって特徴付けられます：

• コンテキストエンコーダ ($E_q$): ルーティング状態を表現（埋め込みベースまたはテキストベース）にマッピングします。
• モデルエンコーダ ($E_m$): 候補モデルをエンコードします（静的なメタデータ、履歴プロファイル、学習済み埋め込み、または言語化された記述を介して）。
• スコアリング関数 ($g$): 状態と候補モデル間の適合性を測定します。
• 決定ルール ($d$): スコアをルーティングアクションに変換します（例：貪欲選択、閾値処理、または終了）。
• 学習シグナル ($L$): コンポーネントを適合させるために使用される目的関数（教師あり学習、嗜好ベース、または強化学習）。

この抽象化により、既存の手法はシングルターン、マルチターン（エージェント型を含む）、およびパーソナライズドルーティングの3つのファミリーに分類されます。

2. 自動パイプラインと xRouteBench

評価のボトルネックに対処するため、著者らは以下の自動パイプラインを開発しました：

1. クエリのキュレーション: 確立されたベンチマークからサンプリングし、正規化を行います。
2. レスポンスの収集: すべてのクエリを18個の候補モデル（7Bから671Bパラメータまで）にディスパッチし、トークン数を記録します。
3. スコアリングと価格設定: タスク固有の指標でレスポンスを評価し、コストを算出します。

このパイプラインは、監督学習とテストベッドの両方として機能する、高密度なクエリ・モデル行列を生成します。これに基づき、統一されたプロトコルの下で5つのトラックをカバーするベンチマーク、xRouteBenchを構築しました：

• 汎用LLMタスク: 数学、コード、推論、および常識QA。
• メモリ: 長期的な対話型QA。
• ビジョン: 画像およびビデオの理解。
• 時系列: モダリティ選択を伴う時間的データに基づく推論。
• パーソナライズ: ユーザーのペルソナの好みに基づくユーザー条件付きルーティング。

3. LLMRouter インフラストラクチャ

LLMRouterは、この定式化を実装したオープンソースライブラリです。このシステムを、データエンジン、ルーターライブラリ、トレーナー、ルートエンジン、評価、およびデプロイメントの6つのコンポーネントにモジュール化しています。

• モジュール性: ユーザーは MetaRouter インターフェースをサブクラス化し、ルーティング手法と損失関数のみを定義することで、新しいルーターを実装できます。データの構築、学習、推論、および評価は変更されません。
• 網羅性: このライブラリには、3つのファミリーすべてにわたる16以上の代表的なルーターが含まれています（例：kNN、SVM、グラフベース、エージェント型、およびパーソナライズド・ルーター）。
• デプロイメント: OpenAI互換サーバーを介したデプロイをサポートしており（Slack/Discord用のOpenClawとの統合）、コードフリーのプロトタイピングのためのComfyUIベースのビジュアルインターフェースも備えています。

主な結果

著者らは、18個の候補モデルと16以上のルーティング手法を用いて、xRouteBenchにおける系統的な実証研究を行いました。主な知見は以下の通りです：

1. 単一の支配的なルーターは存在しない: 最良のルーターは、タスクやコスト予算によって大きく異なります。GraphRouterはxRouteBenchにおいて最高の平均性能を達成しましたが、すべての特定のタスクで優れていたわけではありません（例：RouterDCは汎用LLMタスクで優れ、SVMRouterはメモリタスクで最高の性能を示しました）。
2. 学習されたルーティング vs 固定モデル: 学習されたルーターは、最強の固定モデルベースライン（常に最大のモデルを選択する）に対して14.6%の相対的な改善を達成しました。最大のモデルは最も高いコストを要しましたが、性能は平凡でした。一方、学習されたルーターは、最大のモデルが正しく答えられなかった多くのクエリを、より小さく安価なモデルへと適切にルーティングすることに成功しました。
3. マルチターンの限界: マルチターン・ルーティングがシングルターン・ルーティングを一貫して上回ることはありませんでした。分解と集約の追加ラウンドは、しばしば冗長な情報と計算オーバーヘッドを導入しました。その有効性は、分解を実行するベースモデルの能力に強く依存していました。
4. パーソナライゼーションの価値: ユーザー条件付きルーティングは一貫した利点をもたらしました。GMTRouterは、ペルソナ・ジャッジの下でのパーソナライズ・トラックにおいて最高の精度（68.78%）を達成し、ユーザー非依存のベースラインを上回りました。しかし、研究では、検証対象がシミュレートされたペルソナ・ジャッジか実際の人間による好みかによってランキングが変化するため、ユーザーコンテキストの具体的なモデリングが重要であると指摘されています。
5. 性能とコストのトレードオフ: ルーターのランキングは、異なるコスト制約の下で逆転しました。コスト予算が厳しい状況では軽量な設計が優位となり、コストを無視した場合には品質重視のルーターが優位となりました。
6. マルチエージェントシステム: マルチエージェントシステム（MAS）のデプロイメントにおいて、個々のノードを独立してルーティングすることは、すべてのエージェントに単一のベースモデルを使用することよりも優れた性能を発揮しました。MFRouterは、5つのコーディネーション・トポロジー全体で最高の平均性能（76.48）を達成し、「最大のモデル」ベースライン（71.48）を上回りました。

意義と主張

本論文は、LLMRouterが、LLMルーターの開発、評価、およびデプロイメントを標準化する最初の統一されたインフラストラクチャであることを主張しています。多様なアプローチを単一の逐次決定プロセスとして位置づけることで、公平な比較とモジュール式の拡張を可能にします。

著者らは、以下の点を通じて、自らの研究がオフラインの研究と実世界のアプリケーションの間の溝を埋めるものであることを強調しています：

• 以前はサポートされていなかったマルチモーダルおよびパーソナライズされたシナリオをカバーする、標準化されたコスト認識型の評価フレームワーク（xRouteBench）を提供すること。
• 新しいルーター開発のためのエンジニアリング・オーバーヘッドを、フルスタックの再実装ではなく、設定の変更へと削減すること。
• 学習されたルーティング・ポリシーが、異種混合のタスクやマルチエージェントシステムにおいて、コスト効率と性能を体系的に向上させられることを実証すること。

論文は、LLMルーティングの分野における体系的な進歩を促進するために、ライブラリとベンチマークを公開して締めくくっています。