Agentic RAGクエリルーティング（エージェンティックラグクエリルーティング）
ユーザークエリの意図・複雑度・必要な情報源を分析し、最適な検索戦略や処理パイプラインに動的にルーティングするAgentic RAGの中核機能。
クエリルーティングとは
Agentic RAGにおけるクエリルーティングは、入力されたユーザークエリを分析し、最適な処理パスに振り分ける制御機構である。すべてのクエリを同一のパイプラインで処理するのではなく、クエリの特性に応じて検索戦略・使用するデータソース・処理の深さを動的に決定する。
これは人間の情報検索行動に類似している。「東京タワーの高さは？」という単純な質問と「過去10年のAI研究動向を分析して」という複雑な質問では、まったく異なるアプローチが必要である。クエリルーティングはこの判断をシステムが自動で行う仕組みである。
ルーティング戦略の分類
意図ベースルーティング（Intent-based Routing）
クエリの意図を分類し、それに応じた処理パスを選択する。
| 意図分類 | 処理パス | 例 |
|---|---|---|
| 事実確認（Factual） | 単発検索 + 直接回答 | 「Python 3.12のリリース日は？」 |
| 比較分析（Comparative） | 複数検索 + 表形式回答 | 「React vs Vue vs Svelteの違い」 |
| 手順説明（Procedural） | 段階検索 + ステップ形式 | 「DockerでNext.jsをデプロイする方法」 |
| 探索的調査（Exploratory） | 反復検索 + 構造化レポート | 「LLMのセキュリティリスクを調査して」 |
| 創造的生成（Creative） | 最小検索 + 生成重視 | 「このデータからブログ記事を書いて」 |
複雑度ベースルーティング（Complexity-based Routing）
クエリの複雑度をスコアリングし、処理コストを最適化する。
- Low（スコア0-3）: 直接回答またはキャッシュヒット → 従来型RAG
- Medium（スコア4-6）: 2〜3回の検索 + 軽量な検証 → 簡易Agentic RAG
- High（スコア7-10）: 完全なAgentic RAGワークフロー → フルスペック実行
ソースベースルーティング（Source-based Routing）
クエリの内容に基づいて、最適な情報源を選択する。
- 構造化データ: SQL/GraphQLクエリに変換 → データベース
- 非構造化テキスト: ベクトル検索 → ドキュメントDB
- リアルタイム情報: API呼び出し → 外部サービス
- コード関連: コード検索エンジン → GitHubリポジトリ
ルーター実装パターン
LLMルーター
LLM自体にルーティング判断を委ねる最も柔軟なアプローチ。Function CallingやStructured Outputを用いて、ルーティング結果を構造化データとして取得する。
分類器ルーター
軽量な分類モデル（BERT系やfastText等）でクエリを高速に分類する。LLMルーターより低コスト・低レイテンシだが、分類精度はトレーニングデータの質に依存する。
ルールベースルーター
正規表現やキーワードマッチングによる決定的なルーティング。最も高速で予測可能だが、曖昧なクエリへの対応力が低い。
ハイブリッドルーター
ルールベースで明確なケースを高速処理し、曖昧なケースのみLLMルーターに委ねるカスケード方式。コストと精度のバランスが優れている。
ルーター実装比較
| 実装方式 | レイテンシ | コスト | 精度 | 柔軟性 | 推奨場面 |
|---|---|---|---|---|---|
| LLMルーター | 高（500ms-2s） | 高 | 高 | 高 | プロトタイプ、複雑なドメイン |
| 分類器ルーター | 低（10-50ms） | 低 | 中〜高 | 中 | 大量トラフィック |
| ルールベース | 極低（1-5ms） | 極低 | 低〜中 | 低 | 明確なパターン |
| ハイブリッド | 中（50-500ms） | 中 | 高 | 高 | 本番環境 |
クエリ分解（Query Decomposition）
複雑なクエリを処理可能な単位に分解する技術は、クエリルーティングと密接に関連する。
サブクエリ分解
「AとBの違いを踏まえてCを推薦して」→ 3つのサブクエリに分解
- Aについての情報を検索
- Bについての情報を検索
- A vs Bの比較結果に基づいてCを推薦
ステップバック分解（Step-back Decomposition）
具体的な質問を一度抽象化し、より広い文脈から情報を収集する。
- 具体的質問: 「GPT-4oのマルチモーダル精度は？」
- ステップバック: 「マルチモーダルLLMの評価指標と最新ベンチマーク結果は？」
HyDE（Hypothetical Document Embedding）
クエリに対する仮想的な回答文書を生成し、その埋め込みで検索する。キーワード不一致問題（vocabulary mismatch）を緩和する効果がある。
よくある質問（FAQ）
Q1: ルーティングの判断にどのくらいのレイテンシが許容されますか？
A1: ルーティング自体のレイテンシは全体の処理時間の10%以内が目安です。全体のSLA（例: 5秒以内に回答）から逆算して、ルーターに割り当てられる時間を決定します。ハイブリッドルーターであれば、80%のクエリを50ms以内で処理し、残り20%のみLLMルーター（500ms程度）に回すことで、平均レイテンシを低く抑えられます。
Q2: ルーティング精度をどう測定しますか？
A2: 人間がアノテーションしたテストセットで、ルーターの分類結果と正解ラベルを比較します。重要なのは精度だけでなく、誤分類のコストも考慮することです。「複雑なクエリを単純と誤判定」（品質低下）と「単純なクエリを複雑と誤判定」（コスト増）では前者の方がユーザー体験への悪影響が大きいため、再現率（Recall）重視の閾値設定が推奨されます。
Q3: クエリ分解で生成されるサブクエリが多すぎる場合どうしますか？
A3: サブクエリ数の上限（通常3〜5個）を設定し、優先度の高いものから処理します。また、サブクエリ間の依存関係を分析し、独立したものは並列実行、依存するものは逐次実行とすることで効率化できます。