論文概要（Abstract）
LLMの急速な多様化により、モデルごとに得意タスクとコストが大きく異なる状況が生まれています。RouterBenchは、クエリに応じて最適なLLMを動的選択するLLMルーティングシステムの初の包括的ベンチマークです。12データセット×6モデルで生成した405,000推論インスタンスを用いて、10種のルーティングアルゴリズムを統一条件で評価し、品質とコストのトレードオフを定量化しています。
この記事は Zenn記事: LangGraph Agentic RAGの本番運用設計：マルチソースルーティングと評価駆動リランキング の深掘りです。
情報源
- arXiv ID: 2409.05694
- URL: https://arxiv.org/abs/2409.05694
- 著者: Wangyue Li, Litong Gao et al.
- 発表年: 2024
- 分野: cs.AI, cs.CL
- コード: https://github.com/withmartian/routerbench（MIT License）
背景と動機（Background & Motivation）
LLMの選択肢が急増する中、「すべてのクエリに最も高性能なモデルを使う」アプローチはコスト面で非現実的です。簡単な質問にはLlama-3-8Bで十分であり、複雑な推論タスクにのみGPT-4oを使えば、品質を維持しながらコストを大幅に削減できます。
しかし、ルーティングアルゴリズムを比較するための標準化されたベンチマークが存在しませんでした。既存のRouteLLMやRouterLLMは2モデル間のルーティングに限定されており、実運用で必要な「3つ以上のモデル×多様なタスク」の評価ができません。Zenn記事で解説したSend()APIによるマルチソースルーティングでも、各リトリーバーをどのモデルに割り当てるかの最適化指標が不明確でした。RouterBenchはこのギャップを埋める初の包括的フレームワークです。
主要な貢献（Key Contributions）
- 初の標準化ベンチマーク: 12データセット×6 LLM = 405,000推論インスタンスの大規模評価基盤
- Routing Score（RS）メトリクス: 品質とコストを同時に評価する複合指標の提案
- 10アルゴリズムの統一評価: ランダムベースラインからMatrix Factorizationまで、同一条件で比較
- オフライン・シミュレーション: 全LLM応答が事前計算済みのため、新アルゴリズムをAPI呼び出しなしでテスト可能
- オープンソース（MIT License）: 研究コミュニティの拡張を促進
技術的詳細（Technical Details）
ベンチマーク設計
RouterBenchは以下の6つのLLMを対象としています。
| モデル | プロバイダ | ティア | 特徴 |
|---|---|---|---|
| Llama-3-8B-Instruct | Meta | Small | 最安、簡単なタスクに十分 |
| Llama-3-70B-Instruct | Meta | Medium | バランス型 |
| Mixtral-8x7B-Instruct | Mistral | Medium | MoEアーキテクチャ |
| Mixtral-8x22B-Instruct | Mistral | Large | 高精度MoE |
| GPT-3.5-turbo | OpenAI | Medium | 汎用 |
| GPT-4o | OpenAI | Large | 最高精度・最高コスト |
評価データセットは12種で、小学校レベルの算数（GSM8K）から大学院レベルの科学（GPQA）まで網羅しています。
Routing Score（RS）— コア指標
RouterBenchの核心は、品質とコストを単一の指標で評価するRouting Scoreです。
\[RS(\pi) = \sum_{i=1}^{N} \left[ \text{quality}(\pi(x_i), x_i) \times \left(1 - \frac{\text{cost}(\pi(x_i)) - \text{cost}_{\min}}{\text{cost}_{\max} - \text{cost}_{\min}}\right) \right]\]ここで、
- $\pi$: ルーティングポリシー（クエリ→モデルのマッピング関数）
- $x_i$: $i$番目のクエリ
- $\text{quality}(m, x) \in {0, 1}$: モデル$m$がクエリ$x$に正解したか
- $\text{cost}(m)$: モデル$m$の推論コスト（トークン数ベース）
直感的な意味: 安いモデルで正解するとスコアが高く、高いモデルで正解しても低スコアになります。不正解はどのモデルでもスコア0です。
境界値の定義:
| 指標 | 意味 | 計算方法 |
|---|---|---|
| OUB（Oracle Upper Bound） | 各クエリで最適なモデルを選んだ場合のRS | Ground Truth必要 |
| QOUB | 品質のみの上界（コスト無視） | 常に最高精度モデルを選択 |
| COUB | コストのみの上界（品質無視） | 常に最安で正解するモデルを選択 |
ルーティングの3パラダイム
RouterBenchは3種類のルーティングアプローチを体系化しています。
A. Prediction-based（予測ベース）: 別の分類器モデルがクエリごとにLLMの性能を予測します。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
class PredictionRouter:
"""各LLMの正解確率を予測し、最適モデルを選択"""
def __init__(self, classifier):
self.classifier = classifier # BERT, MF等
def route(self, query: str) -> str:
# 各モデルの正解確率を予測
predictions = {
model: self.classifier.predict_quality(query, model)
for model in self.available_models
}
# RS最大化: quality × (1 - normalized_cost)
scores = {
model: pred * (1 - self.normalized_cost(model))
for model, pred in predictions.items()
}
return max(scores, key=scores.get)
B. LLM-based（カスケード）: 安いモデルから順に呼び出し、信頼度が閾値を超えたら停止します。FrugalGPTが代表例です。
1
2
3
4
5
6
7
8
9
10
class CascadeRouter:
"""安いモデルから順に呼び出すカスケード方式"""
def route(self, query: str) -> tuple[str, str]:
for model in sorted(self.models, key=lambda m: m.cost):
response = model.generate(query)
confidence = self.estimate_confidence(response)
if confidence >= self.threshold:
return model.name, response
# 全モデルで閾値未達→最高精度モデルにフォールバック
return self.most_capable_model.name, response
C. Semantic-based（セマンティックベース）: クエリの埋め込みベクトルの類似度やトピック分類でルーティングします。
評価された10アルゴリズム
| # | アルゴリズム | パラダイム | RS | 品質 |
|---|---|---|---|---|
| 1 | Random | ベースライン | 0.555 | - |
| 2 | Round Robin | ベースライン | - | - |
| 3 | GPT-4o固定 | 単一モデル | 0.548 | 0.813 |
| 4 | Llama-3-8B固定 | 単一モデル | 0.532 | 0.600 |
| 5 | Causal LM | 予測ベース | - | - |
| 6 | Sequence Classification | 予測ベース | - | - |
| 7 | BERT Classification | 予測ベース | 0.581 | - |
| 8 | Matrix Factorization | 予測ベース | 0.598 | 0.689 |
| 9 | Cascade | LLMベース | 0.565 | - |
| 10 | FrugalGPT | LLMベース | 0.565 | - |
Matrix Factorization（MF）が最高RSを達成。クエリとモデルの潜在表現を学習し、クエリ特性に基づくモデル選択を実現しています。
実装のポイント（Implementation）
Matrix Factorizationルーターの概要
MFアルゴリズムは、クエリ×モデルの性能行列を低ランク近似して潜在空間を学習します。
\[\hat{Q}_{ij} = \mathbf{u}_i^T \mathbf{v}_j + b_i + c_j\]ここで、
- $\hat{Q}_{ij}$: クエリ$i$に対するモデル$j$の予測品質
- $\mathbf{u}_i \in \mathbb{R}^k$: クエリ$i$の潜在ベクトル
- $\mathbf{v}_j \in \mathbb{R}^k$: モデル$j$の潜在ベクトル
- $b_i, c_j$: バイアス項
LangGraphとの統合パターン
Zenn記事で解説したSend()APIによるマルチソースルーティングと組み合わせる場合、RouterBenchのアプローチは以下のように適用できます。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
from langgraph.types import Send
def route_to_optimal_source(state: RouterState) -> list[Send]:
"""RouterBenchのスコアリングを適用したルーティング"""
routes = []
for classification in state["classifications"]:
# Routing Score = quality × (1 - normalized_cost)
rs = classification.confidence * (
1 - COST_TABLE[classification.source]
)
if rs >= RS_THRESHOLD: # RS閾値でフィルタリング
routes.append(
Send(classification.source, {
"query": classification.sub_question,
"routing_score": rs
})
)
return routes
オフライン評価の実装
RouterBenchの最大の実用的価値は、事前計算された405K推論結果によるオフライン評価です。
1
2
3
4
5
6
7
8
9
10
11
12
13
import json
def evaluate_routing_policy(policy, test_data):
"""新しいルーティングポリシーをAPIコスト0で評価"""
total_rs = 0.0
for instance in test_data:
# ポリシーがモデルを選択
selected_model = policy.select(instance["prompt"])
# 事前計算された結果を参照（API呼び出し不要）
quality = instance["results"][selected_model]["correct"]
cost = instance["results"][selected_model]["normalized_cost"]
total_rs += quality * (1 - cost)
return total_rs / len(test_data)
ハイパーパラメータと落とし穴
- train/testスプリット: 80/20、データセット・難易度で層化抽出（5シード平均）
- MFの潜在次元: $k=32$が安定。$k$が大きすぎると過学習
- カスケードの信頼度閾値: 0.7が推奨。低すぎると高コストモデルに頻繁にフォールバック
- よくあるバグ: GPQAなど高難度データセットでは、ルーターが安いモデルに過剰ルーティングして品質が低下する
実験結果（Results）
主要ベンチマーク結果
| 手法 | RS | 品質 | コスト削減率 |
|---|---|---|---|
| Oracle Upper Bound | 0.689 | 0.795 | - |
| GPT-4o固定 | 0.548 | 0.813 | 0% |
| Llama-3-8B固定 | 0.532 | 0.600 | 96.5% |
| Random | 0.555 | - | - |
| Matrix Factorization | 0.598 | 0.689 | ~40% |
| BERT Classification | 0.581 | - | - |
| Cascade (FrugalGPT) | 0.565 | - | - |
最良のMFでもOracleとの差は0.091。この差は、クエリ難易度の正確な推定が困難であることに起因します。
データセット別の知見
- 簡単なタスク（ARC, HellaSwag）: 小さなモデルで十分。ルーティングの効果が最大
- 困難なタスク（GPQA, MuSR）: ルーターが安いモデルに過剰ルーティングし、品質低下
- 数学タスク（GSM8K）: GPT-4oが圧倒的に強く、ほぼOracle性能でルーティング可能
- 相関分析: 訓練サンプル数とRSの相関 $r = 0.72$、データセット難易度との負の相関 $r = -0.65$
モデル数の影響
2モデル（最安＋最高精度）のみの設定では、6モデル設定と比較してRSが約8ポイント低下。中間ティアモデル（Mixtral系）の追加がルーティングの柔軟性を大きく向上させます。
実運用への応用（Practical Applications）
Agentic RAGでの活用
Zenn記事で解説したマルチソースルーティングの文脈では、RouterBenchの知見を以下のように適用できます。
- リトリーバー×モデルの組み合わせ最適化: ベクトル検索にはHaiku、キーワード検索にはSonnet、リアルタイムログにはOpusなど、ソースごとに最適なモデルを選択
- RS指標の導入: 本番環境で品質とコストのバランスを定量的にモニタリング
- オフライン評価パイプライン: 新しいルーティング戦略をプロダクション投入前にコスト0でテスト
注意点
RouterBenchはクローズドエンド（選択式）タスクのみを対象としています。RAGの回答生成のようなオープンエンドタスクでは、品質評価にRAGASなどの追加メトリクスが必要です。
関連研究（Related Work）
- RouteLLM (Ong et al., 2024): 2モデル間の強弱ルーティングに特化。RouterBenchの6モデル設定の方が汎用的
- FrugalGPT (Chen et al., 2023): カスケードルーティングの元祖。RouterBenchのCascadeアルゴリズムの基盤
- LLM-Blender (Jiang et al., 2023): 複数LLM出力のブレンディング。ルーティング（1つ選択）とは異なるアプローチ
まとめと今後の展望
RouterBenchは、LLMルーティングの評価を標準化した画期的なベンチマークです。405K推論インスタンスのオフライン評価により、新しいルーティング戦略を低コストで検証可能にしました。Matrix Factorizationが最良RS（0.598）を達成しましたが、Oracle（0.689）との差は依然として大きく、特に高難度タスクでのルーティング精度向上が今後の課題です。
Zenn記事のマルチソースルーティング設計では、RS指標をLangSmithの監視パイプラインに統合し、ソース×モデルの最適組み合わせを継続的に評価する仕組みが有効です。
参考文献
- arXiv: https://arxiv.org/abs/2409.05694
- Code: https://github.com/withmartian/routerbench
- Related Zenn article: https://zenn.dev/0h_n0/articles/f15c5b29dc16ed