📄 論文解説: Query Routing for Homogeneous Tools — 同種ツール間の軽量クエリルーティング手法

論文概要（Abstract）

本論文は、同一機能を持つ複数の同種ツール（Homogeneous Tools）間でクエリを最適なツールにルーティングする手法を体系的に調査した初の実証研究です。従来の研究は異種ツール（検索、計算、翻訳など機能が異なるツール）のルーティングに集中していましたが、同種ツール — 同じタスクを解くが性能プロファイルが異なるツール群 — のルーティングは未探索でした。本論文では確率ベースと閾値ベースの2つのルーティング戦略を提案・比較し、5つのツールセット・3つのタスクドメインで実験を実施しています。

この記事は Zenn記事: LangGraph動的検索ルーティング実装：クエリ分類×マルチリトリーバーでQA精度を向上させる の深掘りです。

情報源

• arXiv ID: 2501.09136
• URL: https://arxiv.org/abs/2501.09136
• 著者: Shujian Zhang, Xing Han Lu, Suyuchen Wang, Yanwei Pang, Bang Liu（Mila / Université de Montréal, Tianjin University）
• 発表年: 2025
• 分野: cs.IR, cs.AI

背景と動機（Background & Motivation）

LLMのツール使用能力が向上する中、「どのツールを使うか」を決定するルーティングの重要性が増しています。既存研究は主に異種ツール（例: Web検索 vs 計算機 vs データベース）のルーティングを扱ってきましたが、実務では同種ツールの選択が必要な場面が多く存在します。

同種ツールの具体例：

• 検索エンジン: BM25、ベクトル検索、ハイブリッド検索（Zenn記事の3種のリトリーバー）
• コード生成モデル: CodeLlama、DeepSeek Coder、StarCoder
• 推論モデル: GPT-4o、Claude 3.5 Sonnet、Gemini 1.5 Pro

これらのツールは同じタスクを解くため、機能の違いでルーティングを決定できません。各ツールの「得意分野」に基づいてルーティングする必要があり、これがZenn記事のBM25/ベクトル/ハイブリッド検索のルーティング問題と直接対応します。

主要な貢献（Key Contributions）

• 貢献1: 同種ツール間のクエリルーティングに焦点を当てた初の体系的実証研究
• 貢献2: 確率ベースおよび閾値ベースの2つのルーティング戦略を形式化し、それぞれの適用条件を明確化
• 貢献3: 3つのタスクドメイン（コード生成、言語推論、数学推論）・5つのツールセット・6つのLLMルーターでの包括的な実験結果
• 貢献4: ルーティングによる精度向上が可能となる前提条件（ツール間の誤り相補性）の定量的分析

技術的詳細（Technical Details）

問題定義

クエリ $q$ と同種ツール集合 $T = {t_1, t_2, \ldots, t_N}$ が与えられたとき、各ツール $t_i$ の正答関数を $c(q, t_i) \in {0, 1}$ とします。目標は、期待正答率を最大化するルーター $r$ を学習することです：

\[r^* = \arg\max_r \mathbb{E}_q[c(q, r(q))]\]

上界（Oracle）: 各クエリに対して最適なツールを選択した場合の性能

\[\text{Oracle} = \frac{1}{|Q|}\sum_{q \in Q} \max_i c(q, t_i)\]

下界（Best Single Tool）: 常に最良の単一ツールを使用した場合の性能

\[\text{BST} = \max_i \frac{1}{|Q|}\sum_{q \in Q} c(q, t_i)\]

ルーティングの価値は $\text{Oracle} - \text{BST}$ の差（ルーティングギャップ）に依存します。

戦略1: 確率ベースルーティング

ルーターがクエリに対してツールの確率分布を出力し、最高確率のツールを選択します：

\[P(t_i | q) = \text{softmax}(f_\theta(q))_i\] \[r(q) = \arg\max_i P(t_i | q)\]

学習にはクロスエントロピー損失を使用します：

\[\mathcal{L}_{CE} = -\sum_{q \in Q_{\text{train}}} \log P(t^*_q | q)\]

ここで $t^*_q$ はクエリ $q$ に対する最適ツール（正答したツールの中で優先度が最も高いもの）です。

from pydantic import BaseModel, Field
from typing import Literal

class RoutingDecision(BaseModel):
    """確率ベースルーティングの出力"""
    selected_tool: str = Field(description="選択されたツール名")
    probabilities: dict[str, float] = Field(
        description="各ツールの選択確率"
    )

def probability_based_routing(
    query: str,
    tools: list[str],
    router_model,
) -> RoutingDecision:
    """確率ベースルーティング

    常に1つのツールを選択する（棄権なし）。
    レイテンシ重視のユースケースに適する。

    Args:
        query: ルーティング対象のクエリ
        tools: 利用可能なツール名リスト
        router_model: ルーティング用のLLM

    Returns:
        ルーティング決定（選択ツール＋確率分布）
    """
    prompt = f"以下のクエリに最適なツールを選択:\n{query}\n選択肢: {tools}"
    result = router_model.invoke(prompt)
    return RoutingDecision(
        selected_tool=result.tool,
        probabilities=result.scores,
    )

戦略2: 閾値ベースルーティング

確信度が閾値 $\tau$ 以上の場合のみルーティングを実行し、未満の場合はフォールバック（デフォルトツール or エスカレーション）します：

\[r(q) = \begin{cases} \arg\max_i P(t_i | q) & \text{if } \max_i P(t_i | q) \geq \tau \\ t_{\text{fallback}} & \text{otherwise} \end{cases}\]

閾値 $\tau$ はバリデーションセットで最適化します：

\[\tau^* = \arg\max_\tau \text{Acc}_{\text{val}}(\tau)\]

def threshold_based_routing(
    query: str,
    tools: list[str],
    router_model,
    threshold: float = 0.7,
    fallback_tool: str = "hybrid_search",
) -> RoutingDecision:
    """閾値ベースルーティング

    確信度が閾値以上の場合のみルーティング。
    精度重視のユースケースに適する。

    Args:
        query: ルーティング対象のクエリ
        tools: 利用可能なツール名リスト
        router_model: ルーティング用のLLM
        threshold: ルーティング確信度の閾値
        fallback_tool: 閾値未満時のデフォルトツール

    Returns:
        ルーティング決定
    """
    result = probability_based_routing(query, tools, router_model)
    max_prob = max(result.probabilities.values())

    if max_prob >= threshold:
        return result
    else:
        return RoutingDecision(
            selected_tool=fallback_tool,
            probabilities=result.probabilities,
        )

Zenn記事との対応

Zenn記事のCommand APIによるルーティングは、本質的に確率ベースルーティングに相当します。Structured Outputで分類結果を取得し、最も適合するリトリーバーにルーティングする方式です。

本論文の知見を適用すると、以下の改善が可能です：

1. 閾値ベースの導入: 分類の確信度が低い場合はハイブリッド検索（最も安全な選択）にフォールバック
2. ツール相補性の測定: BM25とベクトル検索の誤り相関を事前に測定し、ルーティングの効果を予測

実装のポイント（Implementation）

ルーター学習のデータ効率

論文の重要な知見として、300-500件のラベル付きデータで実用的なルーターを学習できることが示されています。これは以下のプロセスで自動生成できます：

def generate_routing_labels(
    queries: list[str],
    tools: dict[str, callable],
) -> list[tuple[str, str]]:
    """ルーティングラベルの自動生成

    各クエリを全ツールで実行し、正答したツールをラベルとする。

    Args:
        queries: 評価用クエリリスト
        tools: ツール名→実行関数のマッピング

    Returns:
        (クエリ, 最適ツール名) のペアリスト
    """
    labels = []
    for query in queries:
        results = {}
        for name, tool_fn in tools.items():
            results[name] = tool_fn(query)

        # 正答したツールの中で優先度最高のものを選択
        best_tool = select_best_tool(results)
        if best_tool:
            labels.append((query, best_tool))

    return labels

前提条件：ツール間の誤り相補性

ルーティングが有効になるには、ツール間で「誤りパターンが異なる」必要があります。相関が0.85以上の場合、ルーティングの効果は無視できる水準になります。

\[\text{ErrorCorr}(t_i, t_j) = \frac{\sum_q (1-c(q,t_i))(1-c(q,t_j))}{\sqrt{\sum_q (1-c(q,t_i))^2 \cdot \sum_q (1-c(q,t_j))^2}}\]

実装上の注意点

1. ルーターモデルのサイズ: 単純なタスク（言語推論）では小規模ルーターで十分。複雑なタスク（数学推論）ではルーターの精度がボトルネックになりうる
2. 閾値のチューニング: 不適切な閾値は「ほぼ全てルーティング（＝確率ベースと同等）」または「ほぼ全てフォールバック（＝単一ツールと同等）」に退化する
3. オンライン学習: 本番環境でのフィードバックを継続的にルーターの学習データに追加し、分布シフトに対応

Production Deployment Guide

AWS実装パターン（コスト最適化重視）

規模	月間リクエスト	推奨構成	月額コスト	主要サービス
Small	~3,000 (100/日)	Serverless	$50-150	Lambda + Bedrock + DynamoDB
Medium	~30,000 (1,000/日)	Hybrid	$300-800	Lambda + ECS Fargate + ElastiCache
Large	300,000+ (10,000/日)	Container	$2,000-5,000	EKS + Karpenter + EC2 Spot

Small構成の詳細 (月額$50-150):

• Lambda: 512MB RAM, 15秒タイムアウト ($15/月) — ルーティング判定
• Bedrock: Claude 3.5 Haiku ($60/月) — ルーター＋ツール実行
• DynamoDB: On-Demand ($10/月) — ルーティングログ保存
• CloudWatch: 基本監視 ($5/月)

コスト削減テクニック:

• 確率ベースルーティングでルーター呼び出しを1回に限定
• Simple クエリの検索スキップとの組み合わせ
• Bedrock Prompt Caching: ルーターのシステムプロンプト固定で30-90%削減

コスト試算の注意事項:

• 上記は2026年2月時点のAWS ap-northeast-1（東京）リージョン料金に基づく概算値です
• 最新料金は AWS料金計算ツール で確認してください

Terraformインフラコード

# --- ルーティング用Lambda ---
resource "aws_lambda_function" "query_router" {
  filename      = "router.zip"
  function_name = "query-router"
  role          = aws_iam_role.router_lambda.arn
  handler       = "router.handler"
  runtime       = "python3.12"
  timeout       = 15
  memory_size   = 512

  environment {
    variables = {
      ROUTER_MODEL_ID  = "anthropic.claude-3-5-haiku-20241022-v1:0"
      ROUTING_THRESHOLD = "0.7"
      FALLBACK_TOOL    = "hybrid_search"
    }
  }
}

# --- ルーティングログ保存 ---
resource "aws_dynamodb_table" "routing_log" {
  name         = "query-routing-log"
  billing_mode = "PAY_PER_REQUEST"
  hash_key     = "query_id"

  attribute {
    name = "query_id"
    type = "S"
  }

  ttl {
    attribute_name = "expire_at"
    enabled        = true
  }
}

コスト最適化チェックリスト

• ルーターモデルは最小サイズ（Haiku相当）を使用
• 確率ベース/閾値ベースの選択をユースケースに応じて決定
• ツール間の誤り相補性を事前測定（相関>0.85なら単一ツール推奨）
• 閾値はバリデーションセットで最適化
• ルーティングログをDynamoDBに保存しオンライン学習に活用

実験結果（Results）

3ドメイン・5ツールセットでの包括的な実験結果です。

ルーティングによる精度改善:

• ツール間の誤り相補性が高い場合: Best Single Tool比 +3%〜+8% の精度向上
• 誤り相補性が低い場合: ほぼ改善なし（≈0%）

確率ベース vs 閾値ベース:

戦略	ルーティング精度	カバレッジ	適用場面
確率ベース	基準	100%	レイテンシ重視
閾値ベース ($\tau$ 最適)	+2〜5%	60-80%	精度重視

ルーターモデルサイズの影響:

• 単純タスク（言語推論）: 小規模ルーターでOracle近似を達成
• 複雑タスク（数学推論）: 大規模ルーターが有意に優位

データ効率:

• 200-500件のラベル付きデータで実用的な精度を達成
• ラベルはツール実行結果から自動生成可能

実運用への応用（Practical Applications）

Zenn記事のBM25/ベクトル/ハイブリッドの3種リトリーバーは、まさに「同種ツール」です。本論文の知見を直接適用できます：

1. 誤り相補性の確認: BM25とベクトル検索の正答パターンが異なることを確認（相関<0.85であればルーティングの価値あり）
2. ルーティング戦略の選択: リアルタイムQAなら確率ベース、精度重視のバッチ処理なら閾値ベース
3. フォールバック: 閾値未満の場合はハイブリッド検索（RRF統合）にフォールバック — Zenn記事のretrieve_hybridに相当

関連研究（Related Work）

• RouteLLM (Ong et al., 2024): 異種モデル間のルーティング（強いモデル vs 弱いモデル）。コスト最適化が主目的
• FrugalGPT (Chen et al., 2023): カスケード方式で安いモデルから試行し、必要に応じて高品質モデルにエスカレーション
• AdaptiveRAG (Song et al., 2025): クエリ分類に基づく検索深度の適応的選択

まとめと今後の展望

同種ツール間のクエリルーティングにおいて、確率ベースと閾値ベースの2戦略を体系的に比較した本論文は、Zenn記事のマルチリトリーバールーティングに直接的な理論基盤を提供します。特に「ツール間の誤り相補性がルーティング効果の前提条件」という知見は、リトリーバー選定時の重要な判断基準となります。

参考文献

• arXiv: https://arxiv.org/abs/2501.09136
• Related Zenn article: https://zenn.dev/0h_n0/articles/3b9f2fd87ffb09
• RouteLLM: https://arxiv.org/abs/2406.18665