はじめに: Reranker何使う？問題
ELYZAで機械学習エンジニアのインターンをしている見目です。
本記事では、RAG システムにおける Reranker のモデル選定の考え方と、LLM を用いた Reranker のコスト削減手法をご紹介します。
Rerankerとは、Embeddingやキーワード一致を用いた初期検索の結果を、より精密な方法で再評価するRAGの主要コンポーネントです。Rerankerには様々なモデル形式がありますが、現在一般的に利用されているのは「Cross Encoder型」と「汎用LLM型」の2種類だと考えています。
- Cross Encoder型
- クエリと文書のペアを同時に入力し、文書ごとの関連度スコアを推定するモデル
- Rerankingタスクに特化した小~中規模モデルが使われることが多く、オープンソースモデルを自前の推論環境で運用するのが一般的。（API経由で使用可能なモデルも存在するがセキュリティ等の観点より選択肢が限定的となる。）
- 汎用LLM型
- RankGPT 論文で提案された、クエリと文書群を一括でLLMに入力し、関連度順に並び替える手法
- 汎用LLMの言語理解・推論能力に依存するため大規模モデルが必要になりやすく、自前環境で運用するとコストパフォーマンスが合わない場合も多い。一方、プロプライエタリモデルの選択肢が豊富なためAPI経由で手軽に利用可能
この2つの方式は、推論方法やモデルサイズなどの観点で定性的に差別化できるものの、実際の運用では「どんな場面でどちらを選ぶべきか」や、「同じ方式の中でもどのモデルが適しているのか」を判断するのは容易ではありません。
本記事の第1章では、その悩みを解消することを目的とし、各方式の代表的なモデルを 検索精度・応答時間・運用コスト の観点から比較したうえで、利用シナリオに応じたモデル選択の指針を示します。さらに第2章で、汎用LLM型 Rerankerをより手軽に運用するためのコスト削減手法をご紹介します。精度を維持したまま最大 40% のコスト削減を達成できたため、その具体的な方法や実験結果について詳しく解説します。
盛りだくさんの内容となってはいますが、最後まで目を通していただけると幸いです。
0. 評価方法
評価用データセット
改善施策の評価には、以下の2つデータセットを採用しました。
まず、質の高い多様な日本語Q&Aデータセットとして信頼性の高いJQaRA を使用し、加えて、Multi-hop質問に対する性能も検証するため、弊社で独自に作成した Multi-hop FAQデータセットを使用しました。Mutli-hop質問を含む高品質なデータセットとしてはJEMHopQA などがありますが、質問に紐付く正解ドキュメントがwikipediaページ全体であることから、RecallやnDCGなどで評価するためには、チャンキング処理後に改めて正解ラベルを振り直す必要があります。よって実験コストと工数の問題より、弊社作成のものを使用しました。
質問の作成方法については本ブログでは割愛しますが、基本的にJEMHopQAの手法に基づき、手動で作成しています。
- JQaRA データセット
- Retrieverの評価を目的に、AI王 公式配布データセット (JAQKET) の検索データに正解ラベル付けを行ったもの
- 1,667件の質問データにそれぞれ100件ずつ候補ドキュメントが紐付いており、その候補からのReranking性能を直接評価することが可能
- ※ 本実験では、Cross Encoderとの比較時以外は、コスト削減のため、ランダムに100件に絞った質問を使用した
- 弊社作成のMulti-hop FAQデータセット
-
官公庁FAQデータセット を元に、手動作成したMulti-hopな質問のデータセット
-
50件の質問に対し、OpenAI/text-embedding-3-small とBM25を用いた検索の上位200件をRRF (Reciprocal Rank Fusion) によって再ランク付けし、スコアが高い上位100件を候補ドキュメントとした。100位内に正解が含まれなかったデータ (8件) については、80〜100位のランダム位置に正解を挿入して評価可能性を担保した。
-
データインスタンス
[ { "qid": 13, "doc_id": [3956, 16728], "query": "税金をネットやATMで払えるサービスを利用する場合手数料はかかりますか？", "type": "compositional", "answer": "原則かからない", "derivations": [["税金", "ネットで支払いができるサービス", ["ペイジー"]], [["ペイジー"], "手数料", "原則無料"]] }, { "qid": 46, "doc_id": [21975, 22020], "type": "comparison", "answer": "約3ヶ月", "query": "公認会計士の論文試験の実施日から合格発表まで何ヶ月ありますか？", "derivations": [["論文試験実施", ["時期"], "8月下旬"], ["論文試験発表", ["時期"], "11月中旬"]] }, ... ]
-
評価指標
nDCG@10 [Järvelin+2002]
上位に正解（高関連）文書が並ぶほど高得点になるランキング指標です。上位 10 件が同じ文書集合でも並び順の良し悪しに敏感なため、僅かな Reranking 性能の改善もスコアに反映できるのが特徴です。
Complete-set Recall@10 [Zhang+2025]
各クエリについて、「回答に必要な全てのドキュメントが上位10件に含まれているか」を 0/1 で判定する指標です。nDCGのように細かな順位変化を捉えられませんが、その分解釈性の高い指標となります。特に複数ドキュメントがそろって初めて回答可能になる Multi-hop クエリ においては、RAGの出力品質により直結した性能を測ることができます。
1. 性能比較 汎用LLM VS. Cross Encoder
LLMとCross Encoderモデルの性能について、検索精度・応答時間・運用コストの観点から比較を行いました。汎用LLM側はGPT-4.1, 5.1とClaude 4.5 系列を代表モデルとして採用し、下記のプロンプトによるListwise手法でRerankingを実施しました（※ 実験時期の関係でややモデルが古いですが、最新モデルとの大幅な性能差はないと考えてます）。Cross Encoder側は、日本語対応のOpen Sourceモデルを網羅的に採用し、JQaRAのスコアが公式に公開されているモデルについては、その値を転記しています。
-
参考: LLMのReranking用プロンプト
次の検索クエリに対して、回答に必要な情報を、次のキュメント群の中から{{ top_k }}個を選択して、関連度の高い順に出力してください。 必要な情報がない場合でも、関連度の高い順に必ず{{ top_k }}個選択してください。 出力は必ず出力形式に従い、document_idのみを出力してください。 # 出力例 [4,3,6,2,~~] # ドキュメント群 document_id : document {% for doc in documents %} {{ doc.id }} : {{ doc.text }} {% endfor %} # クエリ {{ query }}
検索精度
JQaRAデータセットにおけるnDCG@10とMultihop FAQにおけるComplete-set Recall@10を用いて検索精度を評価し、以下に一覧化しました。
全体として、汎用LLMとCross Encoderのスコアは拮抗した結果となりました。最も高い精度を記録したのはCross Encoderモデル (cl-nagoya/ruri-v3-reranker-310m) ですが、全体的にモデルタイプ間で明確なスコアの優劣は見られませんでした。ただし、タスクの特性によって両者の得意領域が異なる傾向が見られました。JQaRAのように質問と文書の表層的な類似度で十分判断できるケースでは、Cross Encoderの方が安定して高スコアを示す傾向があります。一方でMutlihop FAQのように、要件分解や複数文書の突き合わせが必要な設定では 汎用LLM が相対的に高いスコアとなりました。要因の仮説としては、プロンプトで「回答に必要な情報」という類似度以外の観点を指示している点や、1回の推論で文章間の相対評価が可能な点にあると考えています。
| type | Model | JQaRA (nDCG@10) | Multi-hop FAQ (Complete-set Recall@10) |
|---|---|---|---|
| CE | cl-nagoya/ruri-v3-reranker-310m* | 0.869 | 0.88 |
| CE | cl-nagoya/ruri-reranker-large* | 0.771 | 0.74 |
| LLM | Claude-4.5-Sonnet | 0.762 | 0.88 |
| CE | cl-nagoya/ruri-reranker-base* | 0.743 | 0.72 |
| LLM | Claude-4.5-Haiku | 0.719 | 0.82 |
| LLM | GPT-5.1 | 0.717 | 0.84 |
| CE | hotchpotch/japanese-reranker-cross-encoder-large-v1* | 0.710 | 0.82 |
| CE | Qwen/Qwen3-Reranker-8B | 0.700 | 0.88 |
| LLM | GPT-4.1 | 0.697 | 0.86 |
| CE | hotchpotch/japanese-bge-reranker-v2-m3-v1 | 0.692 | 0.82 |
| LLM | GPT-4.1-mini | 0.688 | 0.84 |
| CE | hotchpotch/japanese-reranker-cross-encoder-base-v1 | 0.671 | 0.80 |
| CE | Qwen/Qwen3-Reranker-4B | 0.659 | 0.82 |
| CE | cl-nagoya/ruri-reranker-small* | 0.645 | 0.68 |
| CE | jinaai/jina-reranker-v3 | 0.643 | 0.74 |
| CE | hotchpotch/japanese-reranker-cross-encoder-small-v1* | 0.625 | 0.80 |
| CE | hotchpotch/japanese-reranker-cross-encoder-xsmall-v1* | 0.614 | 0.78 |
*はJQaRAの学習用データで訓練されているためin-domainの評価となる
応答時間
幅広いモデルサイズのCross Enoderモデルと各種LLMのレイテンシを測定しました。測定条件はJQaRAの各クエリ（平均58token）と100件の候補ドキュメント（平均225token）のスコアを計算して並び替えるまでの時間とし、ランダムに抜粋した100件のクエリで平均をとりました。
下表の結果から、小規模モデルであっても実用レイテンシを出すにはGPUが必須であり、LLMと同等精度のモデルを使用するにはL4 ~ A100クラスの推論環境は必要であることがわかりました。LLM APIのレイテンシはネットワーク状況等に大きく依存するため、あくまで参考値ですが、Claudeの方が遅い傾向にあり、精度とのトレードオフで慎重に選択する必要がありそうです。
| model | #Param. | CPU | T4 (15GB) | L4 (23GB) | A100 (40GB) |
|---|---|---|---|---|---|
| GPT-4.1 (Azure Open AI Service) | - | 1.812秒 | - | - | - |
| GPT-4.1-mini (Azure Open AI Service) | - | 1.245秒 | - | - | - |
| GPT-5.1 (Azure Open AI Service) | - | 1.755秒 | - | - | - |
| Claude-4.5-sonnet (Amazon Bedrock) | - | 3.062秒 | - | - | - |
| Claude-4.5-haiku (Amazon Bedrock) | - | 2.298秒 | - | - | - |
| Qwen3-Reranker-8B | 8B | - | - | 4.808秒* | 1.030 秒* |
| Qwen3-Reranker-4B | 4B | - | - | 2.766秒* | 0.641 秒* |
| ruri-reranker-large | 337M | - | 5.843秒 | 2.585 秒 | 1.168秒 |
| ruri-v3-reranker-310m | 315M | - | 3.778秒 | 0.881秒* | 0.404秒* |
| ruri-reranker-base | 111M | 109.2秒 | 1.687秒 | 0.806秒 | 0.377 秒 |
| ruri-reranker-small | 68M | 58.14秒 | 0.944秒 | 0.457秒 | 0.245 秒 |
*はFlash Attention-2を使用
運用コスト
プロプライエタリLLMのAPI料金と各種GPUインスタンス費用を、次の仮定をもとに比較しました。
- API料金: JQaRAの平均token数をもとに、指示プロンプト(176token) + クエリ(58token) + ドキュメント群(225token × 100件)の入力と、25tokenの出力を仮定し1リクエストあたりの料金を算出
- GPU料金: Google Compute Engineのus-centralリージョンで、以下のマシンを1台常時起動する想定で、1日あたりの固定費を算出
- T4: n1-standard-4 (1GPU + 4vCPU + 15GiB RAM)
- L4: g2-standard-4 (1GPU + 4vCPU + 16GiB RAM)
- A100: a2-highgpu-1g (1GPU + 12vCPU + 85GiB RAM)
結果としては、Claude 4.5 Sonnetは 196 req/day で T4 の日額を上回り、1308 req/day で A100 を上回りました。一方、安価なGPT-4.1 mini は 1474 req/day でようやく T4 を超えるなど、モデルによってコストの分岐点が大きく異なることが確認できました。実際は同時接続数や信頼性の要件を踏まえた複雑な試算が必要になるかとは思いますが、大まかな判断ラインを掴むうえで有用な目安になるかと思います。
-
各LLM APIとGPUのコスト分岐点
T4 GPU L4 GPU A100 (40GB) GPU Claude 4.5 Sonnet 196 req/day 255 req/day 1308 req/day Claude 4.5 Haiku 589 req/day 767 req/day 3924 req/day GPT-5.1 470 req/day 612 req/day 3129 req/day GPT-4.1 294 req/day 383 req/day 1964 req/day GPT-4.1 mini 1474 req/day 1919 req/day 9820 req/day
性能比較を踏まえた使い分けの指針
以上の比較結果をまとめると、検索精度の観点では明確な優劣が見られなかった一方、Latencyの評価によりCross EncoderにはGPU環境が必要であることが判明し、運用コストの面で差別化可能な特性が得られました。それを踏まえて、各モデルタイプの使い分けは以下のようにまとめることができます。
-
1日あたりのリクエスト数が少数、または事前に見積もりづらい利用シナリオにおいて、手軽に高精度なRerankerを導入したい場合
→ 汎用LLM 型のRerankerをAPI経由で利用
-
1日あたり数百以上のリクエストが見込まれる中~大規模な利用シナリオにおいて、運用コストを抑えつつ高精度なモデルを運用したい場合
→ Cross Encoder型のRerankerを運用（特にcl-nagoya/ruri-v3-reranker-310mをL4 GPUで）
2. LLM Rerankerコスト削減実験
前章では、LLMとCross Encoderの比較を行い、トラフィックの規模や不確実性の観点による使い分けを提案しました。トラフィックが小規模なシナリオに限らず、大規模な利用が想定される場合であっても、導入の初期段階では負荷の見通しが立ちにくいことから、まずは LLM 型の Reranker を採用するという選択も考えられます。そのような場合に、やはり課題になるのがAPIコストです。GPUを借りるより安価とはいえ、1回の検索あたり数円のコストが継続的に発生する点は無視できません。
そこで本ブログの後半では、LLM APIをRerankerとして利用する際のコスト削減手法について提案し、その実験結果を紹介します。具体的には、「軽量モデルを用いた段階的Reranking」と「AdaptiveなEarly Stop戦略」という2つの手法を提案し、いずれも約3~4割ほどのコスト削減を達成しました。手軽に実装できることもメリットなので、ぜひお試しいただければ幸いです。
手法1. 軽量モデルを用いた段階的 Reranking
軽量モデルでドキュメント候補を事前に絞り込み、その後に高性能モデルで精緻に並び替えを行う 段階的なReranking手法です。本実験では、以下の2つの絞り込み手法を比較しました。
-
手法A: Full-Filtering
- 軽量モデル (GPT-4.1-mini) で100件の候補から関連度の高い上位
N - 高性能モデル (GPT-4.1) で
N
- 軽量モデル (GPT-4.1-mini) で100件の候補から関連度の高い上位
-
手法B: Partial-Filtering
- 100件の候補を「
N-10 - 下位クラスタのみを軽量モデル (GPT-4.1-mini) に入力し、関連度の高い上位10件を出力
- その10件を上位クラスタに結合し、高性能モデル (GPT-4.1) で最終10件に絞り込み
- 100件の候補を「
Full-Filtering は全候補を対象にする最も単純なベースラインであるのに対し、Partial-Filtering は上位候補を保持しつつ、下位クラスタの再評価にリソースを集中させることで、効率的に性能向上を狙う設計となっています。より具体的には、以下のような利点が期待できます。
- 軽量モデルの入力件数が少ないため、低コスト
- 軽量モデルの出力件数が
N N - 軽量モデルの役割を「低順位に埋もれた正解ドキュメントの発掘」に集中させることで、Reranking精度の向上が見込める
結果 ①: 検索コスト
下記のグラフに、2つのデータセットで測定した各手法の1件あたりの平均検索コスト (軽量モデルと高性能モデルのAPI料金の和) を円換算 (1$=150円) で示しました。横軸のFiltered size
これらの結果から、Partial-Filtering 手法の方が全体として高いコスト削減率を示していることが分かります。具体的には、
なお、Full-Filtering 手法においてコストの増加率が非線形な挙動を示している要因については、次章の考察にて詳しく述べています。
結果 ②: 検索精度
下記のグラフに2つデータセットで測定した検索精度を示しました。前章と同様、JQaRAではnDCG@10、Multi-hop FAQではComplete-set Recall@10の指標を採用しました。また、点線で示したBaselineは、全件を一括でRerankした場合のスコアを表しています。
これらの結果より、Partial-Filtering手法の方が全ての
一方で、Partial-Filtering手法ではBaselineに届かないだけでなく、
考察: Full-Filteringの精度悪化原因の分析
実験で観測された、
その主因は軽量モデルの出力の不安定さにあると考えています。下図は、Full-Filtering手法において、軽量モデルで「
グラフから、出力件数が増えるほど変動が大きくなることが分かります。緑の線で示された実際の出力ID数は本来出力すべき件数を上回る一方で、uniqueなID数が大幅に下回っているため多くの重複IDが生成されていることがわかります。
このような出力の不安定さが、精度低下やコストの非線形的な増加を引き起こしていると考えられます。対策としては、
まとめ
Partial-Filtering による段階的 Reranking 手法を用いることで、同等あるいはそれ以上の検索精度を維持しつつ、検索コストの削減を実現できました。本実験では、
表:
-
JQaRA
検索コスト(1$=150円換算) 検索精度 nDCG@10 応答時間 一括Reranking 5.12 円 0.750 1.812 秒 Partial-Filteringによる段階的Reranking 3.69 円 (-27.9%) 0.752 (+0.02) 1.911 秒 (+0.099秒) -
Multihop FAQ
検索コスト (1$=150円換算) 検索精度 Complete-set Recall@10 応答時間 一括Reranking 7.60 円 0.86 2.145 秒 Partial-Filteringによる段階的Reranking 5.34 円 (-29.8%) 0.90 (+0.04) 2.213 秒 (+0.068秒)
手法2. Adaptiveな Early Stop戦略
一般的なRerankingでは、低順位に正解が潜んでいる可能性を考慮し、候補ドキュメントを 100 件前後まで厚めに用意することが多いです。質を担保するには一定の冗長性が必要ですが、理想的には、質問の難易度や一次検索の質に応じて候補数を Adaptive に調整できれば、必要最小限のコストで同等の結果を得られます。
下のグラフは、Multi-hopデータセットにおけるRerank前の候補ドキュメントについて「上位
手法の詳細
一次検索の結果に基づき、候補ドキュメント数を Adaptive に調整するため、次のシンプルな手順を設計しました。
-
100件のドキュメント候補を
L -
順位の高いブロックから順にRerankし、都度「回答に必要な情報が全て得られたか」を判定する
-
プロンプト: クエリから必要な事実情報を分解 → 情報十分性を判断
# 指示 次の検索クエリに対して必要な資料を、次のドキュメント群の中から{{ top_k }}個を選択して、関連度の高い順に出力してください。 - クエリに対して回答に必要な情報を分解し、"required_info" にリスト形式で記述してください。 - 例: 2028年にオリンピックが開催される国の初代大統領は誰ですか？ - required_info: ["2028年にオリンピックが開催される国A", "国Aの初代大統領"] - 必要な情報がない場合でも、関連度の高い順に必ず{{ top_k }}個選択してください。 - また、ユーザーの質問に回答するために、十分な情報が得られたかどうかも判断し、得られた場合はTrue、得られなかった場合はFalseとフラグを立ててください。 # 出力形式 (重複したdocument_idがdoc_idsに含まれないように) {"required_info": [<必要な情報>, ...], ,"doc_ids": [<document_id>, ..], "flags": True/False} # ドキュメント群 document_id : document {{ faq }} # クエリ {{ query }}
-
-
情報が揃ったと判定された時点でRerankを停止。情報不足と判断された場合は暫定の上位10件に次のブロックを結合し、手順 2 を繰り返す
-
100 件まで到達した場合は、その時点の暫定上位 10 件を採用する。
この方法により、LLM の情報十分性判定が正確であれば、簡単なクエリのコストを大幅に削減できます。難しいクエリでも、一度に 100 件を比較せず段階的に評価できるため、精度向上も期待できます。
結果①: 検索コスト
下図に、2つのデータセットで測定した各手法の平均検索コストを示しました。横軸のRerank Step Lは分割ステップ数を表しており、
グラフから分かるように、Reranking をより細かいステップに分割するほど、平均検索コストは一貫して低下する傾向が確認できます。
結果②: 検索精度
下記のグラフは、各データセットで測定した検索精度を示しています。本手法では、JQaRA データセットについても Complete-set Recall@10 を用いて評価しました。これは、必要な情報が揃った時点で処理を停止するという手法の性質上、それ以降に登場する追加の正解文書は参照されず、nDCG@10 では正当な評価が行えないためです。
結果を見ると、
一方で、
まとめ
AdaptiveなEarly stop戦略を採用することで、同等あるいはそれ以上の検索精度を維持しつつ、検索コストの削減を実現できました。本実験では、
表:
-
JQaRA
検索コスト (1$=150円換算) 検索精度 Complete-set Recall@10 応答時間 一括Reranking 5.12 円 0.99 1.812 秒 Adaptive Early stop 2.90 円 (-43.4%) 1.00 (+0.01) 1.838 秒 (+0.026秒) -
Multihop FAQ
検索コスト (1$=150円換算) 検索精度 Complete-set Recall@10 応答時間 一括Reranking 7.60 円 0.86 2.145 秒 Adaptive Early stop 4.55 円 (-40.1%) 0.90 (+0.04) 2.258 秒 (+0.113秒)
手法1, 2の結果比較と使い分け
本記事で紹介した2つのコスト削減手法について、定量的な評価結果をまとめると以下のようになります。検索精度および応答時間は両手法でほぼ等しく、コスト削減率に関しては手法2 (Adaptive Early Stop) の方が 10% 程度優位という結果になりました。
| 手法1: 軽量モデルによる段階的Reranking | 手法2: Adaptive Early Stop | |
|---|---|---|
| コスト削減率 | 約30% | 約40% |
| 検索精度 | + 約0.03 pt | + 約0.03 pt |
| 応答時間への影響 | + 約0.1 秒 | + 約0.1 秒 |
これらの結果だけを見ると手法2が優れているように見えますが、実運用においては必ずしもそうとは限りません。手法2はクエリごとに適応的な処理をしている分、コスト削減率や検索精度の安定性で手法1に劣る可能性があります。以下の表は各手法のパフォーマンスを左右する主な要因を整理したものです。
| 手法1: 軽量モデルによる段階的Reranking | 手法2: Adaptive Early Stop | |
|---|---|---|
| コスト削減率を決定する要素 | 軽量モデルのAPI料金 | クエリの難易度（一次検索の精度） |
| 検索精度のボトルネック | 軽量モデルのReranking精度 | LLMの情報十分性の判断 |
手法2は、「一次検索の上位に正解が含まれる比較的簡単なクエリが一定数存在する」ことを前提とした設計です。そのため、全てのクエリが等しく難しい場合には、コスト削減の効果が得られにくく、場合によっては応答時間や精度が悪化する可能性もあります。一方、手法1はAPI料金や軽量モデルの性能といった、より決定的で安定した要素に依存しているので、クエリ難易度や分布に左右されにくく、安定したパフォーマンスを得やすいという特徴があります。
推奨される使い分け
-
手法1（軽量モデルによる段階的Reranking）が適しているケース
- コスト削減率や検索精度の安定性を最優先したい場合
- 実装をシンプルに保ちたい場合
-
手法2（Adaptive Early Stop）が適しているケース
- クエリの難易度が比較的低く、早期に必要な情報が得られやすい場合
- コストの大幅な削減を狙いたい場合
- AgenticなRAGとして、リランキングと同時に「不足している情報」も知りたい場合
おわりに
本記事では、RAG システムにおける Reranker のモデル選定の考え方と、LLM 型 Reranker のコスト削減手法をご紹介しました。Reranker の運用やコスト最適化に悩んでいる方にとって、少しでも参考なれば幸いです。
ELYZA では引き続き、最先端の研究開発から実用レベルの技術課題まで幅広く取り組み、国内における LLM の社会実装を推進してまいります。
そのために、機械学習エンジニアやソフトウェアエンジニアなど、様々な職種で一緒に事業を前に進めてくれる仲間を募集しています。記事内容に興味を持っていいただけた方は、ぜひ下記をご覧ください。
Discussion