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