今回の論文
今回取り上げるのは、Microsoft ResearchのLiang Wang、Nan Yang、Furu Weiによる「Query2doc: Query Expansion with Large Language Models」です。2023年3月14日にarXivで初公開され、EMNLP 2023で発表されました。研究分野は情報検索とLLMによるクエリ拡張です。公開元はarXivとAssociation for Computational Linguistics（ACL）で、会議版の書誌・本文とarXivの初公開情報を参照できます。本記事は会議版に基づきます。
選んだ理由は、検索器そのものを大きく変える前に、検索へ渡す入力を改善するという、試しやすい設計を示しているためです。特に既存のBM25検索へLLMを加える構成は、検索基盤を持つ開発チームにとって具体的な検討材料になります。
どんな技術か
Query2docは、質問に答えていそうな短い文書をLLMに生成させ、その文書と元の質問を組み合わせて検索する技術です。生成した文章は「仮想文書」または疑似文書と呼びます。実在する資料を検索してから文章を作るのではなく、検索する前にLLMの知識で文章を作る点が特徴です。
例えば「接続が途中で切れる」という質問には、資料側では「セッション」「タイムアウト」「再接続」といった語が使われているかもしれません。仮想文書を介してこうした語を補えれば、短い質問だけでは見つからなかった資料へ到達する可能性があります。これは仕組みを説明する独自の例で、論文の実験例ではありません。
処理の流れは「元の質問 → 仮想文書の生成 → 質問と連結 → 実文書を検索」です。RAGに組み込む場合、回答の根拠として使うのは検索で取得した実文書です。仮想文書に書かれた内容が正しいと保証されるわけではありません。
課題
検索の入力は短い一方、検索対象の文書は長く、説明に使う語彙も異なります。ユーザーが症状で尋ね、マニュアルが原因や正式名称で説明していると、語句一致を使うBM25は関連文書を取りこぼします。意味の近さで探す密検索も、短く曖昧な質問から意図を十分に表現できるとは限りません。
従来の疑似適合フィードバックでは、最初に検索した上位文書を関連文書とみなし、そこから語を取り出して質問を拡張します。しかし、初回検索が外れていると、無関係な語でさらに検索がずれることがあります。文書側に想定質問を追加する方法もありますが、文書群を加工し、インデックスへ反映する工程が必要です。
Query2docは、初回検索結果の代わりにLLMの生成文を拡張の材料にします。これにより初回検索への依存を減らせますが、今度はLLMが話題を正しく展開できるかに依存します。RAGや検索エージェントでは、候補に正解資料が入らなければ後段で精査できないため、入口の取りこぼしを減らす意味があります。
用語解説
- クエリ拡張
- 検索質問に関連する語や文脈を追加する処理です。Query2docでは単語の候補を列挙する代わりに、LLMが書いた段落を加えて、質問と文書の表現の差を埋めようとします。
- 仮想文書
- 質問に答える文章としてLLMが生成する中間テキストです。検索先から取得した資料ではなく、事実誤りも含み得ます。検索を誘導する材料と回答の根拠を区別するために重要な概念です。
- BM25と疎検索
- BM25は語の出現頻度、珍しさ、文書長などから関連度を計算する検索方式です。語彙を軸とする疎検索なので、仮想文書に関連語が現れることと、元の質問語の重みを保つことが結果に影響します。
- 密検索とデュアルエンコーダ
- 質問と文書を別々にベクトル化し、内積などで照合する検索方式です。論文では拡張後の質問をエンコーダへ入力し、その形式に合わせて検索器を教師あり学習する実験も行います。
- Few-shot prompting
- 指示と少数の入出力例をプロンプトに含める方法です。この論文は質問・関連段落の例を4組示します。重み更新が不要でも、例となるラベル付きペアは使っている点を押さえる必要があります。
技術の仕組み
4組の例から、回答らしい段落を生成します
LLMへ「与えた質問に答える段落を書く」という指示と、学習集合からランダムに選んだ質問・関連段落の4組を渡します。その末尾へ今回の質問を加え、対応する段落を生成させます。付録Aでは、API呼び出しごとに例を選び直して多様性を持たせています。
主実験の生成器は当時のtext-davinci-003で、温度は1、生成上限は128トークンです。ここではLLM自体を追加学習しません。新しいニューラル構造を提案する研究ではなく、既存の生成器と検索器を接続する入力設計が中心です。原論文2節・3.1節・付録A
BM25では元の質問を5回分にします
元の質問をq、仮想文書をdとすると、疎検索に渡す文字列は次の形です。
拡張質問 = concat(qをn回, d)
仮想文書は元の質問より長いため、そのまま足すと追加された語の影響が強くなりやすくなります。そこで質問を繰り返し、元の語の相対的な重みを高めます。論文ではn＝5を使い、データセットごとの調整はしていません。5回は検索回数ではなく、1回の検索入力に含める質問の反復数です。
実装時には、検索エンジンが重複した検索語をどのように得点へ反映するかを確認します。重複を除く実装なら、文字列を繰り返すだけでは論文と同じ効果になりません。これは検索基盤へ移す際の実装上の注意です。
密検索では質問と仮想文書を区切って学習します
密検索ではconcat(q, [SEP], d)を入力にします。元の質問は1回で、区切りトークンを挟んで仮想文書を加えます。質問側の最大入力長は、仮想文書を収めるため144トークンへ延ばします。
論文のDPR実験では、BERT-baseから検索器を学習します。拡張質問と正解文書の内積が高く、BM25で見つかる紛らわしい負例の内積が低くなるよう、対照損失で更新します。さらに強い検索器の実験では、質問と候補本文を一緒に読む教師モデルのスコア分布を、KLダイバージェンスで生徒へ移す蒸留も併用します。
したがって「Query2docは追加学習不要」という説明は、BM25へ組み合わせた条件と、仮想文書を生成するLLMには当てはまりますが、論文の密検索の主結果全体には当てはまりません。既存の埋め込みAPIへ長文を足すだけで、同じ改善が得られると読み替えないことが大切です。
仮想文書だけに置き換えない設計です
同じく生成文を検索に使うHyDEの仮想文書ベースの密検索は、仮想文書を埋め込んで実文書を探します。Query2docは元の質問を明示的に残し、疎検索にも使う構成です。両者は生成文を使う点で近いものの、入力の組み立て方と検索器の学習条件を区別して理解できます。
実験と結果
BM25では上位の品質と候補到達率が改善しました
主な評価対象はMS MARCO passage rankingとTREC DL 2019・2020です。MRR@10は最初の正解が上位10件の何位に現れるか、Recall@kは上位k件で正解文書をどれだけ取得できるかを測ります。nDCG@10は関連度の高い文書を上位10件へ適切な順序で並べられるかを測る指標です。
以下は原論文の表1から抜粋した値です。いずれも100倍表記で、高いほど良好です。
| 検索方法 | MS MARCO MRR@10 | MS MARCO Recall@1000 | TREC DL19 nDCG@10 | TREC DL20 nDCG@10 |
|---|---|---|---|---|
| BM25 | 18.4 | 85.7 | 51.2 | 47.7 |
| BM25 ＋ Query2doc | 21.4 | 91.8 | 66.2 | 62.9 |
| DPR（著者実装） | 33.7 | 95.9 | 64.7 | 64.1 |
| DPR ＋ Query2doc | 35.1 | 97.2 | 68.7 | 67.1 |
| SimLM（蒸留あり） | 41.1 | 98.7 | 71.4 | 69.7 |
| SimLM ＋ Query2doc | 41.5 | 98.8 | 72.9 | 71.6 |
例えばBM25のDL19は51.2から66.2へ、表記上15.0ポイントの改善です。相対改善率15%という意味ではありません。DPRでも改善しますが、既に強いSimLMではMRR@10の増加は0.4ポイントに縮まります。また、MS MARCOでは別手法docT5queryのMRR@10が27.7で、BM25＋Query2docの21.4を上回ります。提案法がすべての方式に勝つ結果ではありません。原論文の表1
元の質問を残す効果が大きく出ています
BM25の入力を変えた表4では、DL19のnDCG@10は質問だけで51.2、仮想文書だけで48.7、両者を連結すると66.2でした。DL20も47.7、44.5、62.9です。少なくともこの疎検索の条件では、仮想文書への全面置換より、元の語と補助的な文脈を組み合わせる方が有効です。
一方、異分野への評価は一様ではありません。BEIRの5集合でBM25はすべて改善しますが、SimLMのSciFactは62.4から59.5へ、NFCorpusは32.7から32.1へ低下します。MS MARCOの例で生成した文章が別分野の検索に常に合うわけではない、と考える必要があります。原論文の表2・4
精度だけでなく、遅延とばらつきも増えます
表6は、MS MARCOの質問から上位100件を単一スレッドで取得する測定です。インデックス検索はBM25の16msから拡張後177msへ増え、さらにLLM呼び出しが2,000ms超かかりました。これは論文当時の実測であり、別環境の処理時間を予測する値ではありません。LLM待ち時間に加え、検索語が増えること自体にも費用があります。
付録Cの3回のランダム実行では、疎検索のnDCG@10の平均と標準偏差はDL19で64.8±1.14、DL20で60.9±1.63です。主表の66.2・62.9は3回平均ではありません。例の選択と生成のサンプリングが結果を変えるため、少数回の比較だけで導入効果を判断しない方がよいとわかります。原論文の表6・10
何に使える？
以下は論文の結果を踏まえた応用案です。日本語業務データやRAGの最終回答で同じ効果が検証されたわけではありません。
既存のヘルプ検索を改善する
利用者が症状で尋ね、ヘルプ記事が正式な機能名で書かれている場合、仮想文書で両者の語彙をつなぐ使い方が考えられます。BM25のインデックスを作り直さず、入力側の処理として比較できることが利点です。ただし、LLMが知らない製品独自の機能名まで正しく補えるとは限りません。
RAGで根拠候補の取りこぼしを減らす
社内FAQや技術文書RAGでは、元の質問と拡張質問で取得できる根拠がどう変わるかを評価できます。拡張で正解候補が増えれば、後段の再順位付けに判断材料を渡せます。仮想文書を回答根拠に混ぜず、取得した資料の出典を維持する設計が必要です。
元の検索も別経路として残したい場合、RRFによる順位の統合を組み合わせる案もあります。これはQuery2doc原論文の検証結果ではなく、拡張による取りこぼしに備えるための構成案です。
調査エージェントの検索入力を作る
技術調査の指示が短いとき、関連段落を一度生成してから資料を探す処理に使えます。背景知識を含む検索語を増やせるためです。一方、エラーコードや型番のような識別子は元の文字列を保持し、生成によって別の製品や障害へ話題がずれていないか確認します。
開発や事業へのヒント
小さく始めるなら、検索入力だけを比較します
最初の実験では、同じ文書集合・同じ検索器・同じ取得件数で「元の質問」と「Query2docの拡張質問」を比べます。ラベル付き質問と正解資料の小さな評価集合を用意し、上位候補への根拠到達率、順位、応答時間、生成コストを測ります。これなら検索器の変更による効果と混同しにくくなります。
LLMの生成文が読みやすいかより、正解資料が検索されたかを評価するのがポイントです。論文の仮想文書だけでは悪化した結果も、入力を長くすればよいわけではないことを示しています。
元の入力を保つ設計は、他のAI前処理にも使えます
Query2docの実験から得られる具体的なヒントは、LLMによる変換を元入力の補助情報として使うことです。補足された文脈が役立つ一方、ユーザーの固有名詞や限定条件を残せます。業務検索なら、対象製品、バージョン、日付などの条件は別の検索フィルタとして保つ方法も考えられます。
ただし、条件を保つだけで生成の誤りを除けるわけではありません。拡張前後の質問、生成文、使用した例、モデル識別子、取得した文書IDを記録し、失敗時にどこで意図が変わったか追えるようにします。
精度の向上に見合う場面へ限定する案があります
論文では検索器が強いほど改善幅が縮み、遅延も増えました。そこで、すべての検索へ適用する前に、通常検索が苦手な質問群で価値を測ると判断しやすくなります。失敗しやすい質問だけに使う、繰り返し質問の生成結果をキャッシュする、といった運用は応用案であり、論文で有効性が実証された最適化ではありません。
事業上の判断も「LLMを検索へ付けたか」より、「根拠を見つけられる質問がどれだけ増え、その増分に時間と費用を払えるか」で考えると、技術的な評価と結び付きます。
限界
最大の制約は推論コストです。検索の前に逐次的な文章生成が入り、拡張後のBM25検索も重くなります。学習不要のBM25構成であっても、実行コストが不要になるわけではありません。
生成器とプロンプトへの依存もあります。論文のモデル比較では強いLLMほど概して良い結果ですが、モデルの規模だけでなく学習内容も異なります。小型モデルへ置き換えたときに同じ改善が得られる保証はありません。日本語、非公開の社内用語、最新の製品仕様への有効性も、この論文だけでは判断できません。
仮想文書には事実誤りが含まれます。論文の表5にも、番組主題歌の使用開始年を誤った例があります。誤った固有名詞や日付が検索方向を変える危険は残り、実文書を取得することだけで正しい回答が保証されるわけではありません。
密検索の主結果には教師あり学習や蒸留が含まれるため、学習データ作成や検索器の更新が必要です。BM25の手軽さと、密検索実験の構築コストを分けて見ます。また、4組のラベル付き例を使うため、「ラベルを一切使わない手法」とも説明できません。
再現性については、例のランダム選択と生成のばらつきがあり、入力長による切り捨ても影響します。検索の順位指標が改善しても、RAGの最終回答の正確さ、費用対効果、専門分野での有効性は別途検証する必要があります。
よくある質問
Q. Query2docを使うには検索モデルの再学習が必要ですか？
A. BM25への追加なら不要です。LLMの生成文と元の質問を組み合わせて検索します。一方、論文のDPRや蒸留付き密検索の主実験は、拡張質問を使った教師あり学習を含みます。既存の埋め込みモデルへ入力するだけの結果とは区別してください。
Q. 質問を5回繰り返すのはなぜですか？
A. 長い仮想文書へ追加した語に対し、元の質問語の重みを保つためです。論文のBM25構成の設定で、密検索では質問を5回繰り返しません。実装先の検索エンジンが重複語をどう処理するかも確認する必要があります。
Q. HyDEと同じ技術ですか？
A. 生成した仮想文書を使う発想は近いですが、Query2docは元の質問も連結し、BM25と密検索を対象にしています。HyDEは主に仮想文書の埋め込みによるゼロショット密検索です。Query2docの表4は、BM25では仮想文書だけへの置き換えが悪化したことも示しています。
Q. 仮想文書をそのままRAGの回答に使えますか？
A. 検索品質の改善結果を、生成文の正確性の保証として使うことはできません。仮想文書は検索の中間入力として扱い、実際に取得した資料と照合して回答を作る必要があります。特に日付、連絡先、製品固有の仕様は推測が混ざり得ます。
Q. 導入するなら何を最初に測るべきですか？
A. 同じ質問集合で、元の検索と拡張検索の根拠到達率・上位順位・全体の遅延・1質問当たりの生成費用を比較します。既に強い検索器では改善幅が小さくなるため、平均値に加え、専門用語や曖昧な質問などの群別に悪化例も調べます。
今日の学び
この論文は、短い検索質問と文書の語彙・文脈の差による取りこぼしを扱いました。LLMに仮想文書を生成させ、元の質問と連結するクエリ拡張で、BM25や学習済み密検索の改善を狙います。
開発へのヒントは、検索器の変更だけでなく、入力表現の設計も改善対象になることです。元の質問を保ちながら補助情報を加え、検索品質の増分と追加遅延をセットで測ると、RAGや業務検索へ採用する判断につなげられます。