Home 論文解説: RouteLLM — 人間嗜好データによるLLMルーティングの学習
投稿
キャンセル

📄 論文解説: RouteLLM — 人間嗜好データによるLLMルーティングの学習

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

本記事は arXiv:2406.18665 RouteLLM: Learning to Route LLMs with Preference Data の解説記事です。

論文概要（Abstract）

RouteLLMは、LLMへのクエリを「強力だが高コストなモデル」と「弱いが低コストなモデル」のどちらに振り分けるかを動的に決定するルーターを学習するフレームワークである。著者らはChatbot Arenaの人間嗜好データを活用し、4種類のルーターアーキテクチャを提案している。著者らの実験によると、GPT-4レベルの品質を維持しながらGPT-4呼び出しを40-60%削減できると報告されている。

この記事は Zenn記事: Azure AI Foundry Model Routerで社内問い合わせBotのコストを50%削減する実装ガイド の深掘りです。Azure AI Foundry Model Routerが内部で行うルーティング判断の学術的背景を理解するうえで、RouteLLMは最も直接的な関連研究の一つである。

情報源

  • arXiv ID: 2406.18665
  • URL: https://arxiv.org/abs/2406.18665
  • 著者: Isaac Ong, Amjad Almahairi, Vincent Wu, Wei-Lin Chiang, Tianhao Wu, Joseph E. Gonzalez, M Waleed Kadous, Ion Stoica（UC Berkeley, Anyscale）
  • 発表年: 2024年（ICLR 2025に採択）
  • 分野: cs.AI, cs.LG, cs.CL
  • コード: https://github.com/lm-sys/RouteLLM（Apache 2.0ライセンス）

背景と動機（Background & Motivation）

LLMサービスの運用において、モデル選択は常にコストと品質のトレードオフを伴う。GPT-4クラスの大規模モデルは高品質な応答を生成するが、Claude 3 Haikuのような軽量モデルと比較してトークン単価が1桁以上高い。一方で、すべてのクエリが大規模モデルを必要とするわけではない。「有給休暇の申請手順を教えてください」のような定型的な質問は、軽量モデルでも十分に回答可能である。

従来のアプローチには以下の課題があった。難易度ベースのルーティングはタスク固有のラベル付けが必要であり、汎用性に欠ける。コスト見積もりベースのアプローチは実際の品質向上との乖離が生じやすい。人間によるラベル収集はスケールしない。RouteLLMはこれらの課題に対し、既に大規模に収集されているChatbot Arenaの嗜好データを活用するアプローチで解決を図っている。

主要な貢献（Key Contributions）

  • 貢献1: ルーティング問題をChatbot Arenaの人間嗜好データから学習する枠組みの提案。タスク固有のラベル付けが不要で、汎用的に適用可能
  • 貢献2: 4種類のルーターアーキテクチャ（Matrix Factorization、BERT Classifier、Similarity-Weighted Ranking、Causal LLM Classifier）の設計と実装
  • 貢献3: GPT-4 Judgeを用いたData Augmentation手法により、未知のモデルペアへの汎化性能を向上
  • 貢献4: MT-Bench、MMLU、GSM8Kでの定量評価と、OpenAI API互換のオープンソースフレームワーク公開

技術的詳細（Technical Details）

ルーティング問題の定式化

RouteLLMはルーティングを以下の二値分類問題として定式化する。強モデル $M_s$（高性能・高コスト）と弱モデル $M_w$（低性能・低コスト）が与えられたとき、ルーター $r$ はクエリ $q$ に対して最適なモデルを選択する。

\[r_\theta(q) = \begin{cases} M_s & \text{if } P(\text{strong preferred} \mid q) \geq \theta \\ M_w & \text{otherwise} \end{cases}\]

ここで、$\theta \in [0, 1]$ は閾値パラメータであり、コストと品質のトレードオフを制御する。$\theta$ を上げると弱モデルへの振り分けが増えコストが下がるが品質も低下する。$\theta$ を下げると品質は維持されるがコストが増加する。

コスト指標として「% Strong Called」（全クエリのうち強モデルに送られた割合）が用いられる。例えば50%なら半分のクエリのみ強モデルを使用し、弱モデルのコストが十分小さければ約50%のコスト削減となる。

学習データの構築：Chatbot Arenaの活用

学習データはLMSYS Chatbot Arena（https://chat.lmsys.org）から取得した人間嗜好比較データに基づく。原データは $(q, \text{response}_A, \text{response}_B, \text{winner})$ の4タプル形式であり、これを以下のように変換する。

  1. $(M_s, M_w)$ ペアに該当する比較のみを抽出
  2. $M_s$ が勝利した場合は $\text{label} = 1$（強モデルが必要）
  3. $M_w$ が勝利した場合は $\text{label} = 0$（弱モデルで十分）

さらに、GPT-4をJudgeとして用いるData Augmentationにより学習データを拡張している。これにより、Arenaデータに存在しないモデルペアへの汎化が可能になる。著者らの報告によると、Augmentationにより未知のモデルペアでの性能が5-15%向上した。

4種類のルーターアーキテクチャ

1. Matrix Factorization（MF）Router

Bradley-Terryモデルに着想を得た協調フィルタリング的アプローチである。クエリ $q$ とモデル $m$ それぞれに埋め込みベクトルを割り当て、スコアを内積で計算する。

\[\text{score}(q, m) = \sigma(\mathbf{e}_q \cdot \mathbf{e}_m)\]

ここで $\sigma$ はシグモイド関数、$\mathbf{e}_q$ はクエリの埋め込みベクトル（text-embedding-ada-002等で生成）、$\mathbf{e}_m$ はモデルの学習可能な埋め込みベクトルである。推論時は $\text{score}(q, M_s)$ が閾値を超えた場合に強モデルへルーティングする。

軽量かつ推論速度に優れるが、テキスト理解の深さではBERT Routerに劣る。

2. BERT Classifier Router

事前学習済みBERT（またはDeBERTa）をファインチューニングし、クエリの難易度を直接二値分類するアプローチである。

  • 入力: クエリテキスト $q$
  • 出力: 強モデルが必要な確率 $P(\text{strong} \mid q)$
  • 学習: Arenaの嗜好データから構築したバイナリラベルでファインチューニング

テキスト理解に特化した分類器であり、MF Routerより精度が高い傾向がある一方、推論コストはやや高くなる。

3. Similarity-Weighted（SW）Ranking Router

kNN的なノンパラメトリックアプローチである。新しいクエリに対し、学習データから類似クエリをコサイン類似度で検索し、その嗜好パターンを参照する。

\[\text{score}(q_{\text{new}}) = \frac{\sum_{i \in \text{Top-}k} \text{sim}(q_{\text{new}}, q_i) \cdot \text{win\_rate}_s(q_i)}{\sum_{i \in \text{Top-}k} \text{sim}(q_{\text{new}}, q_i)}\]

学習データが増えるほど精度が向上するが、全データとの類似度計算が必要でありスケーラビリティに課題がある。

4. Causal LLM Classifier Router

Llama-2等の小型因果言語モデルをファインチューニングし、クエリの難易度を判定させるアプローチである。最も表現力が高いが、計算コストも最も大きい。ただし使用するLLMは7Bクラスの小型モデルであるため、GPT-4より遥かに安価である。

アルゴリズム

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

from dataclasses import dataclass
from typing import Protocol

import numpy as np


class Router(Protocol):
    """LLMルーターのインターフェース"""
    def predict_strong_probability(self, query: str) -> float: ...


@dataclass
class RoutingResult:
    """ルーティング結果"""
    model: str
    score: float


def route_query(
    router: Router,
    query: str,
    threshold: float,
    strong_model: str = "gpt-4",
    weak_model: str = "claude-3-haiku",
) -> RoutingResult:
    """クエリを適切なモデルにルーティングする。

    Args:
        router: 学習済みルーター
        query: ユーザークエリ
        threshold: ルーティング閾値 (0-1)
        strong_model: 強モデル名
        weak_model: 弱モデル名

    Returns:
        ルーティング結果（選択モデルとスコア）
    """
    score = router.predict_strong_probability(query)
    selected = strong_model if score >= threshold else weak_model
    return RoutingResult(model=selected, score=score)

実装のポイント（Implementation）

RouteLLMはPythonパッケージとしてpip install routellmでインストール可能であり、OpenAI API互換のインターフェースを提供する。既存コードのmodelパラメータを変更するだけで導入できる。

実運用で注意すべき点は以下の通りである。

  • ルーター選択の指針: 推論速度を重視するならMF Router、精度を重視するならBERT Routerが推奨される。MF Routerは埋め込みベクトルの内積計算のみで高速だが、BERT Routerはテキストのセマンティクスをより深く理解する
  • 閾値 $\theta$ のキャリブレーション: 適切な $\theta$ の設定は実運用の課題として論文でも認識されている。ベンチマークデータでのPareto最適点を参考に設定するか、A/Bテストで調整する必要がある
  • 依存ライブラリ: openai, anthropic, transformers, torch, SW Rankingの場合はfaissが追加で必要

実験結果（Results）

著者らはGPT-4（強モデル）とClaude 3 Haiku（弱モデル）のペアで評価を行っている。

MT-Benchでの結果（論文Table 1より）:

ルーター% Strong Called品質維持率（対GPT-4）
MF Router40%約95%
BERT Router45%約97%
SW Ranking50%約95%
Causal LLM42%約96%

MMLUでの結果: GPT-4のMMLU精度86.4%に対し、著者らの実験では40%のStrong Calledで85.8%の精度を達成したと報告されている。

ベースラインとの比較: すべての提案ルーターがランダムルーティングを一貫して上回る。クエリ長ベースのヒューリスティックルーティングはランダムよりわずかに良い程度であり、テキスト内容の理解が重要であることが示されている。GPT-4による難易度事前推定は高精度だが、GPT-4を事前に呼ぶコスト自体が問題となり実用的でない。

実運用への応用（Practical Applications）

RouteLLMの知見は、Azure AI Foundry Model Routerのようなマネージドサービスの理論的基盤を理解するうえで有用である。Zenn記事で紹介されているModel RouterのBalanced/Cost/Qualityモードは、RouteLLMの閾値 $\theta$ の設定に相当する概念と捉えることができる。

社内問い合わせBotへの適用では、以下の点が実務上重要である。

  • 質問の多様性: 社内Botでは質問の70-80%が定型FAQであり、RouteLLMのMF Routerのような軽量ルーターでも十分なルーティング精度が期待できる
  • キャッシュとの併用: 同一カテゴリの質問が連続する場合、プロンプトキャッシュとの併用でさらなるコスト削減が見込める
  • レイテンシへの影響: ルーター推論自体のレイテンシは、MF Routerで数ミリ秒程度であり、ユーザー体験への影響は小さい

Bradley-Terryモデルとの関係

RouteLLMのMF Routerの理論的根拠はBradley-Terryモデルにある。Chatbot Arenaではモデル間の対戦結果をBradley-Terryモデルで集約しEloレーティングを算出している。

\[P(M_s \text{ beats } M_w \mid q) = \sigma(\beta_s(q) - \beta_w(q))\]

ここで $\beta_m(q)$ はクエリ $q$ におけるモデル $m$ の強さパラメータである。MF Routerはこれを $\mathbf{e}_q \cdot \mathbf{e}_m$ で近似する。つまり、クエリの埋め込み空間とモデルの埋め込み空間の内積が、そのクエリに対するモデルの適性を表現する。

この定式化の利点は、クエリの「意味的な難しさ」をモデルの「得意・不得意」と明示的に対応付けられる点にある。例えば、コーディングに関するクエリではコード生成に強いモデルが選ばれ、創作文では文章力に優れるモデルが選ばれるような学習が可能になる。

Data Augmentationの効果

著者らが提案するData Augmentation手法は、RouteLLMの汎化性能を大きく向上させている。Arenaデータには特定のモデルペア（例：GPT-4 vs ChatGPT）の比較しか存在しないため、新しいモデルペアへの適用時に性能が劣化する問題がある。

この課題に対し、GPT-4をJudgeとして用いて既存クエリに対する品質ラベルを自動生成する手法が提案されている。著者らの報告（論文Section 5.3）によると、Augmentationにより学習データを数倍〜数十倍に拡張でき、未知のモデルペアへの汎化で5-15%の性能向上が得られた。

この手法はAzure AI Foundry Model Routerにおいても関連性が高い。Model Routerは18種類のモデルにルーティング可能であり、すべてのモデルペアに対して人間の嗜好データを収集することは現実的でない。Augmentation手法により、限られたデータから多数のモデルペアへの汎化が可能になる。

関連研究（Related Work）

  • FrugalGPT（Chen et al., 2023）: LLMカスケードによるコスト最適化の先駆論文。安価なモデルから順に試行し、品質スコアが閾値を超えたら停止する。RouteLLMとは異なり複数モデルの逐次呼び出しが発生するためレイテンシが増加する可能性がある
  • Hybrid LLM（Ding et al., 2024）: 品質制約を明示的にモデル化したルーティングフレームワーク。DeBERTaベースのルーターで弱モデルの品質を事前予測する。RouteLLMが嗜好データに基づくのに対し、品質スコアの直接予測を採用している点が異なる
  • BEST-Route（Agarwal et al., 2025）: Microsoft Researchによる手法で、モデル選択とBest-of-Nサンプリングを同時最適化する。Azure AI Model Routerに統合されている

まとめと今後の展望

RouteLLMは、Chatbot Arenaの人間嗜好データを活用してLLMルーターを学習する実用的なフレームワークを確立した論文である。4種類のルーターアーキテクチャの提案と定量評価により、GPT-4レベルの品質を維持しながら40-60%のコスト削減が可能であることを著者らは示している。

今後の課題として、マルチターン会話への対応、マルチモーダル入力への拡張、オンライン学習によるルーターの動的更新が挙げられている。また、学習データの偏り（Chatbot ArenaはGeneral会話中心）やルーターの分布外汎化も残された課題である。

参考文献

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