今回の論文
今回取り上げるのは、Yue Yu、Wei Ping、Zihan Liuらによる「RankRAG: Unifying Context Ranking with Retrieval-Augmented Generation in LLMs」です。2024年にNeurIPSで発表された論文で、公開元はNeural Information Processing Systems、URLは https://arxiv.org/abs/2407.02485 です。研究分野はRAG、情報検索、LLMの命令チューニングです。
選んだ理由は、RAGの実装で頻出する「検索上位の文書を、そのままLLMに渡してよいのか」という問題に、再順位付けと回答生成を分離しすぎない形で答えているためです。検索用モデル、reranker、生成LLMを個別に増やす前に、1つのLLMへ何を学習させ、どの地点で候補を絞るべきかを考える材料になります。
どんな技術か
RankRAGは、RAGの文書再順位付け（ranking）と回答生成（generation）を、同じLLMに命令チューニングで学ばせる技術です。最初の検索器が多めに返した候補文書を、LLMが質問との関連度で並べ替え、上位だけを根拠として回答を生成します。
通常のRAGでは、埋め込み検索器が返したtop-k文書をそのまま入力に連結しがちです。しかし、上位に無関係な断片が混ざると、長い入力が生成モデルの注意を散らし、もっともらしい誤答を誘発します。RankRAGは「答えるモデルに、何を読ませるかも判断させる」ことで、このノイズを減らそうとします。
課題
RAGの検索は、最初から完璧に根拠文書を1位へ置けるとは限りません。高速なbi-encoder検索は大量の文書を扱える一方、質問と文書を別々に埋め込むため、否定、条件、複数段の関係といった細かな対応を見落としやすいです。top-kを増やせば正解根拠を含める確率は上がりますが、無関係な文書も増えます。
既存のcross-encoder rerankerは質問と文書を同時に読めるため精密ですが、検索専用の追加モデル、ラベル付きランキングデータ、運用パイプラインを必要とします。一方で生成LLMに全候補を渡して「参考にして」と指示するだけでは、文書の優先順位が曖昧なままになり、入力長とノイズの問題が残ります。
この課題は、社内規程検索、サポート回答、技術ドキュメントQAのように、似た文書が多く、誤った根拠を一つ混ぜるだけで回答が変わる場面で深刻です。検索のrecallだけでなく、生成直前の少数コンテキストをどれだけ正確に選べるかが必要になります。
用語解説
- bi-encoder検索
- 質問と文書を別々のベクトルへ変換し、近傍検索で候補を高速に探す方式です。RankRAGでは広く候補を拾う一次検索に使い、その粗い順位を後段で修正します。
- リランキング
- 一次検索で得た少数候補を、質問と文書の組をより精密に評価して並べ直す処理です。本論文の中心は、LLMにこの役割と回答生成の両方を学ばせる点にあります。
- 命令チューニング
- 「入力に対し何を出力すべきか」を示す例でLLMを追加学習する手法です。RankRAGはQA例だけでなく、質問・文書・関連度ラベルの例も学習混合物へ加えます。
- Recall@k
- 正解根拠が上位k件に入る割合です。再順位付けでは、生成器に渡す少数の文書に必要な根拠を残せたかを測る重要な指標になります。
- コンテキストノイズ
- 質問への回答に不要、または誤解を招く取得文書です。RAGでは文書数を増やすほど発生しやすく、正解の根拠があっても生成の品質を下げ得ます。
技術の仕組み
RankRAGの基本アイデアは、検索と生成の間にある「候補を読む」能力を、汎用LLMの別タスクとして扱うことです。検索器を置き換えるのではなく、一次検索でrecallを確保し、LLMが精度の高い選別と回答を担います。
1. 多めに取得し、文書ごとに関連度を出す
まずDragonなどのdense retrieverで、質問に対する候補文書を取得します。RankRAGは質問と候補文書を1組ずつ入力し、文書が回答の根拠として関連するかをトークン生成の形で判定します。論文ではTrueが生成される確率を関連度スコアに変換し、候補を並べ替えます。
この形式の利点は、分類ヘッドを別に設計せず、因果言語モデルの次トークン確率をranking scoreとして再利用できることです。実装では、質問と本文をプロンプトへ入れ、Trueなど所定の関連ラベルの確率を記録すれば、同様の再順位付けを構成できます。
2. 上位コンテキストだけで回答を生成する
スコア順の上位文書を選び、質問とともに同じLLMへ与えて回答を生成します。ここで重要なのは、ランキング時と生成時でモデルがまったく別の「関連性」を学ばないことです。回答に使える根拠を選ぶよう訓練された表現を、直後の生成にも活用します。
ただし、文書の順位が高いことと、回答が根拠に忠実であることは同義ではありません。本番では、回答に引用IDを付けさせる、根拠なしの場合は回答保留を許す、といった出力側の制約も組み合わせるべきです。
3. QAとランキングを混ぜた命令チューニング
論文はLlama 3を基盤に、一般的な命令データ、コンテキスト付きQA、RAG形式のQAへ、ランキングデータを少量混ぜて学習します。ランキングだけに特化させるのではなく、生成能力を保ったまま、質問と根拠の対応を読む能力を注入する設計です。
特に示唆的なのは、MS MARCO由来のランキングデータを約5万件、すなわち大規模ランキングデータの一部だけ追加しても有効だった点です。これは「検索専用データを最大限集めなければrerankerは作れない」とは限らず、既存のドメインQAデータと少数の高品質な関連度例の配合が重要であることを示します。
4. 推論時の処理フロー
推論は、(1) 質問で候補を広く検索し、(2) 候補ごとにLLMの関連度スコアを計算し、(3) 上位数件を選び、(4) 選択済みコンテキストで回答を生成する流れです。候補100件すべてをLLMで精査すると遅延は増えるため、サービスでは一次検索の候補数、rerank件数、最終投入件数を別々のパラメータとして測定・調整します。
実験と結果
論文は、Natural Questions（NQ）、TriviaQA、PopQA、HotpotQA、2WikiMultiHopQA、FEVER、Doc2Dial、TopiOCQA、InSCItの9つの知識集約型ベンチマークで評価しました。単一文書で答えられる質問だけでなく、長尾知識、多段推論、事実検証、対話QAを含む構成です。
RAG全体の回答品質
Llama 3 8Bを基盤にしたRankRAGは、論文のゼロショット評価で、比較対象のLlama3-ChatQA-1.5 8Bを9データセットの平均で上回りました。改善は特に、検索器の上位候補にノイズが入りやすいPopQAや2WikiMultiHopQAで大きく、著者らはChatQA-1.5に対して10%以上の改善を報告しています。
論文のTable 2では、RankRAG 8BはNQでEM 50.6、TriviaQAでEM/Accuracy 82.9/89.5、PopQAでEM/Accuracy 57.6/64.1を報告しました。数値の絶対比較では、各モデルのプロンプト、検索コーパス、評価設定が同一かを確認する必要がありますが、単に大きな生成器へ候補を渡すだけでは得られない効果を示しています。
再順位付けの精度
ランキング評価では、NQ、TriviaQA、PopQA、HotpotQA、InSCItについてRecall@5/10/20を比較しました。RankRAG 8Bは、top-100候補を再順位付けする設定で、NQのR@5 80.3、TriviaQAのR@5 93.2、PopQAのR@5 81.6を示しています。大規模なランキング専用データで訓練されたBGE-Rerankerや、汎用GPT-4をrerankerとして使う設定とも競争的でした。
この結果から言えるのは、回答生成タスクと整合した関連度判断を学習させると、最終回答に渡す小さなtop-kの根拠率を高められる、ということです。ただしRecallは「正解根拠を残した」指標であり、引用の正しさや生成の忠実性を単独では保証しません。
アブレーションが示すこと
論文のアブレーションでは、ランキングデータの追加、コンテキスト付きQA、RAG QAの各要素が結果に寄与しました。特にランキングデータを混ぜないモデルは再順位付け能力が落ち、ランキングだけに寄せると回答タスクの性能を十分に得にくくなります。実務でも、rerankerを作る学習データはクリックや検索一致だけでなく、「その文書を渡したときに正しく回答できたか」という下流の信号で評価する必要があります。
何に使える？
RankRAGの考え方は、既存のRAGの一次検索を維持したまま、生成前の候補選択を強くしたい場面で使えます。
社内規程・ナレッジ検索
似た改定履歴や部署別ルールが混在する社内検索では、検索上位に古い版や例外規定が入りがちです。質問と各候補をLLMで比較してから少数を渡せば、検索器だけでは判別しにくい適用条件を考慮しやすくなります。文書の版、部署、公開日をranking入力へ明示すると、実運用の判断条件を取り込みやすくなります。
開発支援のコード・ドキュメントRAG
バグ調査では、関数名が似た複数ファイル、古いIssue、API仕様が同時にヒットします。候補を再順位付けして、質問への関係と変更対象の近さで絞れば、LLMに読ませるトークンを減らしつつ、無関係なコードへ引っ張られるリスクを下げられます。ランキング対象には本文だけでなく、パス、言語、最終更新、呼び出し関係も含めると有用です。
高精度なサポート回答
問い合わせに近いFAQを検索しても、対象プランや製品バージョンが違えば誤回答になります。RankRAG型のrerankerは、質問文と候補文書に加え、契約プランや製品バージョンを条件として読めます。最終回答では選んだ文書IDを保存すれば、監査・改善時に「どの候補選択が失敗したか」を追跡できます。
開発や事業へのヒント
この論文の価値は、RAGの改善を「検索器を変えるか、より大きなLLMを使うか」の二択から外すことです。生成直前の文書選択を独立した品質レイヤーとして設計できます。
まずは学習なしのLLM rerankで失敗を観察する
小規模プロダクトでは、既存のLLMへ質問と上位10〜30候補を一つずつ与え、関連度をJSONで返させるだけでも検証できます。ここで重要なのは、回答の正誤だけでなく、正解根拠がrerank後のtop-3に残る率、rerankで落とした有用文書、追加遅延をログに残すことです。効果が確認できた後に、専用rerankerやRankRAG型の追加学習へ進むのが安全です。
データを「答え」だけで終わらせない
既存のQAログがあるなら、正答と一緒に使われた引用文書を関連例へ変換できます。逆に、誤答で参照した文書や、同じ検索結果から人が選ばなかった文書は負例候補になります。RankRAGのような学習は、回答ペアだけでなく、質問と候補の対応を資産に変える視点を促します。
予算配分をサービス要件に合わせる
100件をLLM rerankすることは、100件の生成ほど重くなくても無料ではありません。低遅延の対話画面ならtop-20からtop-5へ、高リスクな社内調査ならtop-100からtop-10へ、といったように、候補数と最終コンテキスト数を用途別に設定します。高精度モードだけrerankを深くする設計も現実的です。
限界
RankRAGは、一次検索で正解根拠を候補集合へ入れられなければ救えません。再順位付けはrecallを新たに作る処理ではないため、まずコーパス整備、チャンク設計、ハイブリッド検索を適切に行う必要があります。
また、候補ごとにLLMを実行するため、cross-encoderや埋め込みrerankerより遅く高価になる場合があります。候補数が多い、文書が長い、同時リクエストが多いサービスでは、バッチ処理、短いpassageへの切り出し、軽量モデルへの蒸留、キャッシュを検討すべきです。
論文のランキングデータは主に一般ドメインです。医療、法務、社内固有略語のような領域へそのまま適用しても、関連性の基準が合うとは限りません。著者らは生物医学ベンチマークへの一般化も報告していますが、実サービスでは対象ドメインの質問で、検索評価と回答の根拠忠実性を別途検証する必要があります。
さらに、関連度ラベルを生成させるスコアは、プロンプト形式やラベル語の選び方に影響されます。JSON形式の出力失敗、モデル更新、候補文書の長さによるバイアスも起こり得るため、固定した評価セットとバージョン管理を用意して運用することが重要です。
よくある質問
Q. RankRAGは通常のrerankerと何が違いますか？
A. 通常は検索専用のモデルが文書を再順位付けし、別のLLMが回答します。RankRAGは同じLLMをランキングと生成の両方へ命令チューニングし、回答に使える根拠を選ぶ能力と回答能力を整合させようとします。推論パイプライン自体は、一次検索、rerank、生成という段階を持ちます。
Q. RankRAGを使えばベクトル検索器は不要ですか？
A. 不要にはなりません。RankRAGは候補を精査する後段なので、まず高速な検索器で広いコーパスから候補を集めます。一次検索のrecallが低ければ、LLMは正解文書を上位へ動かせません。
Q. 少ないデータでも自社向けに学習できますか？
A. 論文は大規模ランキングデータの一部を混ぜるだけでも有効性を示しました。ただし自社データでの効果は別問題です。まず質問、正解文書、紛らわしい候補を含む数百件程度の評価セットを作り、学習前後のRecall@kと回答の根拠性を比較することを勧めます。
Q. LLM rerankは遅くなりませんか？
A. 候補ごとに質問と文書を処理するため遅くなります。対策は、一次検索の候補を絞る、rerank用に短いチャンクを作る、小型モデルを使う、ランキング結果をキャッシュすることです。精度が必要な操作だけ深いrerankを有効にする方法もあります。
Q. 再順位付けだけでハルシネーションを防げますか？
A. 防げません。RankRAGは関連する根拠を選びやすくしますが、モデルが根拠外を補完したり、文書を誤読したりする可能性は残ります。引用の強制、根拠不足時の回答保留、回答と引用の整合性評価を併用してください。
今日の学び
この論文は、RAGで「検索候補には正解があるのに、生成LLMがノイズに惑わされる」という課題を扱いました。RankRAGは、一次検索の後にLLM自身で候補を再順位付けし、少数の根拠から回答する能力を同時に学習します。
得られるヒントは、RAGの品質を検索・生成の二段だけで捉えず、その間の文書選択を測定・改善することです。小さく始めるなら、まずrerank後の根拠Recallと追加遅延を可視化し、回答ログから関連度データを蓄積するところが実装への第一歩になります。