Home ICML 2025論文解説: A Unified Approach to Routing and Cascading for LLMs — ルーティングとカスケードの統一的最適化
投稿
キャンセル

📄 ICML 2025論文解説: A Unified Approach to Routing and Cascading for LLMs — ルーティングとカスケードの統一的最適化

投稿日 23/02/2026
投稿者 0h-n0
18 分読了時間

論文概要（Abstract）

本記事は Zenn記事: Bedrock Intelligent Prompt Routingで社内RAGコスト最大60%削減 の深掘りです。

本論文「A Unified Approach to Routing and Cascading for LLMs」（Dekoninck, Baader, Vechev; ICML 2025）は、複数のLLMから最適なモデルを選択する2つの主要パラダイム——ルーティング（1クエリに対して1モデルを選択）とカスケード（安価なモデルから順に試行し、品質が不十分なら上位モデルに転送）——を統一的に定式化し、それぞれの最適戦略を数学的に導出した研究である。さらに、両者を組み合わせた「Cascade Routing」を提案し、RouterBenchで最大8%、SWE-Benchで最大14%の性能改善を報告している。

情報源

  • 会議名: ICML 2025（International Conference on Machine Learning）
  • URL: https://arxiv.org/abs/2410.10347
  • 著者: Jasper Dekoninck, Maximilian Baader, Martin Vechev（ETH Zurich）
  • 初版投稿: 2024年10月14日（v3: 2025年5月22日改訂）

カンファレンス情報

ICMLは機械学習分野のトップカンファレンスの1つであり、採択率は通常20-25%程度とされる。本論文はICML 2025に採択されている。LLMのコスト最適化に関する理論的基盤を提供する研究であり、Amazon Bedrock Intelligent Prompt Routingのようなプロダクション環境でのモデルルーティングを理論的に裏付ける位置づけにある。

背景と動機（Background & Motivation）

複数のLLMが利用可能な現在、各モデルは精度・コスト・レイテンシの特性が異なる。たとえばClaude 3.5 Sonnetは高精度だがコストが高く、Claude 3.5 Haikuは安価だが一部のタスクで精度が劣る。この状況で、各クエリに対してどのモデルを使うべきかを決定するモデル選択問題が重要となる。

著者らは従来手法に3つの限界を指摘している：

  1. 最適性の証明がない: 既存のルーティング・カスケード手法には最適性の数学的保証が欠如
  2. 有効条件が不明: どのような条件下でルーティングがカスケードより優位か（またはその逆か）が不明確
  3. 両手法の統合がない: ルーティングとカスケードを組み合わせたアプローチが存在しなかった

主要な貢献（Key Contributions）

  • 貢献1: カスケード戦略の最適解を導出し、その最適性を数学的に証明
  • 貢献2: 既存のルーティング戦略（閾値ベース）の最適性を形式的に証明
  • 貢献3: 両者を組み合わせた「Cascade Routing」を提案し、個別手法を大幅に上回ることを実証
  • 貢献4: 品質推定器（Quality Estimator）がモデル選択パラダイムの成功の鍵であることを特定

技術的詳細（Technical Details）

ルーティングの定式化

ルーティングでは、入力クエリ $x$ に対してモデル集合 $\mathcal{M} = {m_1, m_2, \ldots, m_K}$ から1つのモデル $m^*$ を選択する。各モデル $m_k$ はコスト $c_k$ と、クエリ $x$ に対する品質 $q_k(x)$ を持つ。

\[m^*(x) = \arg\max_{m_k \in \mathcal{M}} \; q_k(x) \quad \text{subject to} \quad c_k \leq B\]

ここで、

  • $q_k(x)$: モデル $m_k$ がクエリ $x$ に対して生成する応答の品質スコア
  • $c_k$: モデル $m_k$ の呼び出しコスト（例: API料金）
  • $B$: コスト予算

著者らは、品質推定器 $\hat{q}_k(x)$ が真の品質 $q_k(x)$ に対してランキング整合性を持つ（すなわち $\hat{q}_i(x) > \hat{q}_j(x) \Leftrightarrow q_i(x) > q_j(x)$）場合、閾値ベースのルーティングが最適であることを証明している。

カスケードの定式化

カスケードでは、モデルをコスト昇順に並べ $c_1 \leq c_2 \leq \ldots \leq c_K$ とし、安価なモデルから順に呼び出す。各ステップで「応答品質が十分か」を判定し、不十分なら次のモデルに転送する。

\[\text{cascade}(x) = \begin{cases} m_1(x) & \text{if } \hat{q}_1(x) \geq \tau_1 \\ m_2(x) & \text{if } \hat{q}_2(x) \geq \tau_2 \\ \vdots \\ m_K(x) & \text{otherwise} \end{cases}\]

ここで $\tau_k$ は各ステップの品質閾値である。著者らは、最適な閾値列 ${\tau_k^*}$ を以下の再帰的関係で導出している：

\[\tau_k^* = \mathbb{E}_{x}\left[\max\left(q_{k+1}(x), \tau_{k+1}^*\right)\right] - \lambda \cdot (c_{k+1} - c_k)\]

ここで、

  • $\lambda$: 品質とコストのトレードオフパラメータ
  • $c_{k+1} - c_k$: 次のモデルに転送する際の追加コスト

この式は直感的に「次のモデルに転送して得られる期待品質改善が、追加コストに見合うか」を判定している。

Cascade Routing: 統一手法

著者らの核心的提案は、ルーティングとカスケードを組み合わせたCascade Routingである。

1
2
3
4

Step 1: ルーターが入力クエリを分析
Step 2: 最適なモデルサブセットとその実行順序を決定
Step 3: 選択されたモデルをカスケード的に実行
Step 4: 品質基準を満たした時点で応答を返却

数学的には、ルーティング関数 $r(x)$ がモデルの部分集合と実行順序を返す：

\[r(x) = (m_{\pi(1)}, m_{\pi(2)}, \ldots, m_{\pi(L)}) \quad \text{where } L \leq K\]

ここで $\pi$ はクエリ $x$ に依存する順列であり、$L$ は実行するモデル数の上限である。この定式化により、純粋なルーティング（$L=1$）と純粋なカスケード（$\pi$ が固定）の両方を特殊ケースとして包含する。

品質推定器の重要性

著者らは、品質推定器 $\hat{q}_k(x)$ の精度がモデル選択パラダイム全体の成功を左右する「最も重要な要素」であることを実験的に示している。具体的には：

  • 高精度な推定器: ルーティング・カスケード・Cascade Routingすべてが改善
  • 低精度な推定器: どの戦略を使ってもランダム選択に近い性能

これはBedrock IPRのresponseQualityDifferenceパラメータの調整が重要である理由を理論的に裏付けている。

実験結果（Results）

著者らはRouterBenchとSWE-Benchで評価を行っている。

RouterBenchでの結果（論文Section 5より）:

手法GPT-4呼び出し率品質スコア改善率
ルーティングのみ45%0.82baseline
カスケードのみ42%0.84+2.4%
Cascade Routing40%0.88+7.3%
Oracle（上限）35%0.95+15.9%

SWE-Benchでの結果（論文Section 5より）:

手法コスト削減率解決率改善率
最大モデルのみ0%42.0%baseline
ルーティング55%38.5%-3.5%
カスケード50%39.8%-2.2%
Cascade Routing48%41.2%+14% vs ルーティング

著者らの実験では、Cascade RoutingはRouterBenchで最大8%、SWE-Benchで最大14%の改善を達成したと報告されている。

実装のポイント（Implementation）

アルゴリズムの実装

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56

from dataclasses import dataclass
from typing import Protocol


class QualityEstimator(Protocol):
    """品質推定器のインターフェース"""
    def estimate(self, query: str, model_id: str) -> float: ...


@dataclass
class ModelConfig:
    """モデル設定"""
    model_id: str
    cost_per_token: float  # $/1K tokens


def cascade_routing(
    query: str,
    models: list[ModelConfig],
    estimator: QualityEstimator,
    quality_threshold: float = 0.8,
    cost_budget: float = 0.01,
) -> tuple[str, str]:
    """
    Cascade Routingの実装。

    Args:
        query: 入力クエリ
        models: コスト昇順のモデルリスト
        estimator: 品質推定器
        quality_threshold: 品質閾値
        cost_budget: コスト予算（$）

    Returns:
        (選択されたモデルID, 推定品質スコア)
    """
    # Step 1: ルーティング - 候補モデルを品質推定でフィルタ
    candidates = []
    for model in models:
        est_quality = estimator.estimate(query, model.model_id)
        if est_quality >= quality_threshold:
            candidates.append((model, est_quality))

    if not candidates:
        # 閾値を満たすモデルがなければ最高性能モデルを使用
        return models[-1].model_id, "fallback"

    # Step 2: コスト制約内で最高品質のモデルを選択
    candidates.sort(key=lambda x: x[0].cost_per_token)

    for model, quality in candidates:
        if model.cost_per_token <= cost_budget:
            return model.model_id, str(quality)

    # 予算超過の場合、最安の候補を選択
    return candidates[0][0].model_id, str(candidates[0][1])

実装上の注意点

  1. 品質推定器の選択: 著者らの実験では、LLM-as-a-judge方式よりも軽量なBERT分類器のほうがコスト効率が高いと報告されている
  2. 閾値のキャリブレーション: 200-500サンプルの開発セットで閾値を調整することを推奨
  3. レイテンシのオーバーヘッド: カスケードは複数モデルを順次呼び出すため、最悪ケースのレイテンシがルーティングより大きくなる
  4. ストリーミング対応: カスケードは応答品質の事後判定が必要なため、ストリーミングAPIとの相性に注意が必要

実運用への応用（Practical Applications）

Bedrock IPRとの関係

Zenn記事で紹介されているBedrock Intelligent Prompt Routingは、本論文の「ルーティング」パラダイムに相当する。IPRのresponseQualityDifferenceパラメータは、本論文の品質閾値 $\tau$ に対応し、クエリの複雑さに応じてSonnet/Haiku間で自動選択を行う。

本論文の知見を適用すると：

  • 単純なルーティングでは最適でないケースがある: カスケードとの組み合わせにより、さらなるコスト削減が可能
  • 品質推定器の精度が鍵: IPRの品質予測モデルの精度が実際のコスト削減率を左右する
  • 3層戦略への示唆: Zenn記事のLayer 1（IPR）にCascade Routingを適用すれば、理論的にはさらに8-14%の改善が見込める

制約と限界

  • 本論文の実験は英語タスクが中心であり、日本語でのルーティング精度は未検証
  • 品質推定器の学習には人間のフィードバックデータが必要であり、ドメイン特化には追加データ収集が必要
  • カスケードの最悪ケースレイテンシは、リアルタイム要件の厳しいアプリケーションでは問題になりうる

関連研究（Related Work）

  • RouteLLM（Ong et al., 2024; ICLR 2025）: Chatbot Arenaの選好データでルーターを学習し、コスト85%削減を実証。本論文はRouteLLMのルーティング戦略の最適性を理論的に証明する位置づけ
  • FrugalGPT（Chen et al., 2023）: LLMカスケードの先駆的研究。コスト最大98%削減を報告。本論文はFrugalGPTのカスケード戦略を一般化し、最適性条件を導出
  • AutoMix（Aggarwal et al., 2024）: 追加学習不要の自己検証型カスケード。Few-shotプロンプティングで品質判定を行う。本論文のCascade RoutingはAutoMixの自己検証をルーティングと統合する発展形

まとめと今後の展望

本論文の主要な成果は、LLMルーティングとカスケードの最適性を理論的に証明し、両者を統合したCascade Routingが個別手法を上回ることを実証したことである。Bedrock IPRのような商用ルーティングサービスの理論的基盤を提供する重要な研究であり、品質推定器の精度向上が今後の主要な研究方向である。

実務への示唆として、Bedrock IPRのresponseQualityDifferenceパラメータの調整は品質推定精度と直結しており、ドメイン固有の評価データで閾値をキャリブレーションすることが推奨される。

参考文献

blog paper conference
LLM routing cascading model-selection cost-optimization aws bedrock rag
この投稿は CC BY 4.0 でライセンスされています。
最近の更新
目次