クエリ分解
クエリ分解は、1つの複雑なクエリを、それぞれ個別に回答できるいくつかのより単純なサブクエスチョンに分割する手法です。各サブクエスチョンは個別に検索・推論され、その結果が最終回答として組み合わされるため、複数の文書にまたがって証拠が分散しているマルチホップ質問における検索精度と回答品質が向上します。
Query decomposition は、難しい複合クエリをいくつかのより簡単なサブクエスチョンに分割します。
各サブクエスチョンは個別に検索・推論され、その結果を統合して元のクエリに回答します。これは、証拠が複数のドキュメントに分散しているマルチホップ質問に特に有効です。
LangChain、NVIDIA、Haystack などの主要な RAG フレームワークは、これを標準的な手法として搭載しており、追加の学習なしに LLM のプロンプティングだけで適用できます。
2025年の arXiv 論文では、MultiHop-RAG と HotpotQA のベンチマークで、検索（MRR@10）において +36.7% の向上、回答精度（F1）において +11.6% の向上が報告されています。
これはquery fan-outやquery rewritingと並ぶ手法ですが、decomposition の本質は複雑なクエリをサブクエスチョンに分割することです。
Query Decomposition とは？
Query decomposition は、1つの複雑なクエリを、それぞれ独立に回答できる複数のより簡単なサブクエスチョンに分割し、それぞれを個別に処理したうえで、結果を統合して最終回答を作る手法です。1回の検索では十分な証拠を集められない質問を、答えやすい単位に分解して解くという考え方です。
この手法が重要なのは、multi-hop questionsに対応できるからです。マルチホップ質問とは、裏付けとなる事実が1つのドキュメントにまとまっておらず、複数のドキュメントに散在している質問です。たとえば、「去年の収益は Microsoft と Google のどちらが多かったですか？」という質問は、両社の収益を並べて示した1つのドキュメントだけで答えられることはほとんどありません。元の表現のまま検索すると、片方の証拠しか出ないか、両方とも見逃すことがよくあります。Query decomposition はこれを、「Google の去年の収益はいくらでしたか？」と「Microsoft の去年の収益はいくらでしたか？」という2つの簡単な質問に分け、それぞれに適したドキュメントを取得し、最後に比較して統合します。LangChain のドキュメントでも、「Web Voyager と reflection agents はどう違いますか？」のような比較質問を使って同じ原理が説明されています。それぞれを説明するドキュメントはあっても、両者を直接比較するドキュメントがない場合、元のクエリで検索するよりも、「Web Voyager とは何ですか？」と「reflection agents とは何ですか？」を個別に取得して統合するほうが効果的です。
隣接する概念との違い
Query decomposition は、検索の前にクエリを再構成する複数の「query transformation」手法の1つです。隣接する概念と目的が異なるため、混同されやすいものとの違いを整理しておく価値があります。
Technique | Core action | Output |
|---|---|---|
Query decomposition | 複雑なクエリを、より答えやすいサブクエスチョンに分割する | それぞれ異なる側面を問う、複数のサブクエスチョン |
検索性能を高めるために、意味を保ったまま表現を洗練する | 改善された単一クエリ | |
1つのクエリを、関連する複数のバリアントまたは拡張クエリへ展開する | 関連クエリを複数、並列で実行する | |
ステップバック・プロンプティング | 特定の質問を、より上位の概念的な質問へ抽象化する | より一般的で、より上位の質問を1つ |
重要な違いはここにあります。クエリ書き換えは、同じ質問をより良く検索できる単一のクエリに変えることにとどまり、クエリ・ファンアウトは1つのクエリを複数の関連する分岐へ「広げる」ことに重点を置きます。これに対し、クエリ分解は本質的に、元の質問を解くために「まず何を知る必要があるか」を問い、それを意味的に独立したサブクエスチョンに分割することです。LangChainのブログでも、書き換えは「単一の改善されたクエリを生成すること」、分解は「並列で実行される複数の検索クエリを生成すること」と区別しています。
仕組み
RAGパイプラインでは、クエリ分解は通常3段階で進みます。これは、NVIDIAのRAGドキュメントとarXivの研究が共通して示しているフローです。
サブクエスチョンを生成する: LLMが元のクエリを受け取り、個別に回答できる複数のサブクエスチョンへ分解します。
サブクエスチョンごとに検索する: 各サブクエスチョンに対して、証拠を集めるために個別にパッセージを検索します。
統合、再ランク付け、要約: 収集した候補ドキュメントを統合して再ランク付けし、ノイズを減らしたうえで、包括的な回答を生成します。
分解の構造にはトレードオフがあります。サブクエスチョンを順次に解く方法では、各ステップの結果を次へ引き継ぐため情報の流れを最大化できますが、初期の誤りが後続に蓄積する「エラーカスケード」を生む可能性があります。これに対して、並列に解く方法は、ステップ間の誤りを切り分けられる一方で、各ステップ間の依存関係を活用できません。そのため、比較のように部分ごとに独立している質問では並列分解が適しており、連鎖的な推論では順次分解が有利です。
エビデンスと例
クエリ分解の有効性は、学術研究によって裏付けられています。Ammann、Golde、Akbik の「Question Decomposition for Retrieval-Augmented Generation」（arXiv:2507.00355、2025）では、上記の3段階パイプライン（分解 → サブクエリごとの検索 → 結合と再ランキング）を MultiHop-RAG および HotpotQA ベンチマークで評価しました。その結果、標準的な RAG と比較して、検索指標 MRR@10 が +36.7%、回答精度 F1 が +11.6% 向上したと報告しています。著者らは、この手法を「追加学習や特別なインデックス作成なしにすぐ適用できる」“drop-in” の改善と位置づけ、「マルチホップ質問における検索のギャップを埋める」と説明しています。
分解を個別の学習なしで適用できることは、初期の研究から強調されてきました。Perez らの「Unsupervised Question Decomposition for Question Answering」（arXiv:2002.09758）では、1つの難しいマルチホップ質問を複数の簡単なシングルホップのサブクエスチョンへ、教師なしで変換する手法（ONUS）を提案し、分解によって複雑な質問応答の性能を向上させられることを示しています。実務面では、NVIDIA の RAG ドキュメントでもこれを「multi-step, compound queries」に適した手法として分類しており、サブクエスチョン生成 → 反復処理 → 応答合成、という3段階で実装した例を示しています。
実装チェックリスト
まず、質問がマルチホップ（根拠が複数文書に散在）、比較、または複数ステップの推論を要するものかを判定し、分解すべき対象を見極めます。単一の事実を尋ねる簡単な質問には分解は不要です。
LLM の分解プロンプトには、「独立に回答可能なサブクエスチョンに分割する」という指示と、過剰分割を防ぐためのサブクエスチョン数の上限を含めます。
比較質問は並列分解で、連鎖的推論が必要な質問は順次分解で扱い、依存関係の喪失とエラーの連鎖のバランスを取ります。
サブクエスチョンごとの検索結果を統合した後、再ランキングを実行して、重複とノイズを除去します。
分解の前後で検索指標（MRR、Recall）と回答精度（F1、EM）を測定し、実際に改善していることを確認します。