ローカルLLM リランカー（Reranker）モデル比較 2026年版：BGE Reranker v2-m3 / Jina Reranker v3 / Cohere Rerank 3.5 / Ruri Reranker を日本語RAG 精度・速度・VRAM で選ぶ
ローカルLLM RAG の精度を最終的に押し上げるのはリランカー（Reranker）です。BGE Reranker v2-m3 / Jina Reranker v3 / Cohere Rerank 3.5 / Ruri Reranker を日本語RAG の nDCG@10・レイテンシ・VRAM 消費で比較し、pgvector や Qdrant からの再ランキングでどれを選ぶかを整理します。
- #リランカー
- #Reranker
- #BGE Reranker
- #Jina Reranker
- #Cohere Rerank
- #Ruri Reranker
- #ローカルRAG
- #日本語RAG
- #nDCG
- #クロスエンコーダ
結論：日本語ローカルRAG の「まず 1 個で始める」なら BGE Reranker v2-m3、日本語精度最優先なら Ruri Reranker、レイテンシ最優先なら Jina Reranker v3、運用手離れ最優先なら Cohere Rerank 3.5 の API 課金。RAG の精度は埋め込みモデルで 8 割方決まりますが、残りの 2 割を最終的に押し上げるのがリランカーです。埋め込み単体で Top-10 を返すより、埋め込み Top-100 → リランカー Top-10 の 2 段構成のほうが nDCG@10 で 5〜15 ポイント伸びます。
ローカルRAG の精度改善で「もう埋め込みモデルを変えても伸びない」段階に来た人向けの記事です。埋め込みモデルの選び方は「ローカルLLM 埋め込みモデル比較 2026年版」で、ベクトルDB 側は「ローカルLLM RAG用ベクトルDB比較 2026年版」で扱っています。この記事は、その 2 段の後ろにもう 1 段挿すリランカーの選び方に絞ります。
リランカーは埋め込みと何が違うのか
RAG の検索段は 2 種類のモデルで構成できます。
- 埋め込みモデル（Bi-Encoder）：クエリとドキュメントをそれぞれ独立にベクトル化する。1 万件でも 100 万件でもインデックスを事前計算しておけば、検索時はコサイン類似度で瞬時に上位を絞れる
- リランカー（Cross-Encoder）：クエリとドキュメントを 1 組ずつ「連結して同時にトランスフォーマに通す」。ペアごとの相互作用を直接見に行くため精度が高い代わりに、100 万件を全部やると現実的な時間で終わらない
この 2 つは片方だけを使うより、埋め込みで Top-100 に絞ってからリランカーで Top-10 に精選する組み合わせで真価を発揮します。埋め込みは「高速な粗ふるい」、リランカーは「低速だが精密な仕上げ」という分業です。
日本語 RAG の実装で言うと、pgvector や Qdrant で Top-50 〜 Top-100 を出したあと、その結果をリランカーに投げ直して Top-10 を返します。1 検索あたりのリランカー呼び出しは 50〜100 ペアで、これが数十 ms 〜 数秒の追加レイテンシを生みます。ここが選定の主要トレードオフです。
4 モデル + 補足 2 モデルの立ち位置
2026 年 8 月時点で候補になる主要リランカーを並べます。
| モデル | 提供 | ライセンス | パラメータ | コンテキスト長 | 多言語対応 |
|---|---|---|---|---|---|
| BGE Reranker v2-m3 | BAAI | MIT | 約 568M | 8,192 | 100+ 言語 |
| Jina Reranker v3 | Jina AI | Apache 2.0 / API 併用 | 非公開 | 131,072（listwise） | 100+ 言語 |
| Cohere Rerank 3.5 multilingual | Cohere | API 課金のみ | 非公開 | 4,096 | 100+ 言語 |
| Ruri Reranker（v3 large 相当） | cl-nagoya | Apache 2.0 相当 | 約 337M | 512 | 日本語特化 |
| mxbai-rerank-large-v2 | Mixedbread | Apache 2.0 | 約 435M | 8,192 | 多言語 |
| jina-colbert-v2 | Jina AI | Apache 2.0 | 約 560M | 8,192 | 多言語 |
主要 4 モデルはクロスエンコーダ型で、クエリとドキュメントを 1 ペアで再スコアリングします（埋め込みモデルの Bi-Encoder とは対照的な設計です）。jina-colbert-v2 だけ ColBERT 系（トークンレベル多ベクトル）で毛色が違い、インデックスサイズが数十 GB に膨らむ代わりに Bi-Encoder 相当の速度で動くという別軸の選択肢です。
判断軸 1：日本語検索精度（nDCG@10 / JaCWIR / JQaRA）
日本語 RAG で最も重要な指標は、日本語検索ベンチ（JaCWIR、JQaRA、MIRACL-ja）での nDCG@10 と Recall@10 です。2026 年 8 月時点で公表・第三者ベンチから読み取れる傾向は以下の通りです。数値は日々更新されるため、最新値は各モデルカードと MTEB Leaderboard を参照してください。
| モデル | 日本語 nDCG@10 目安 | 総評 |
|---|---|---|
| Ruri Reranker | 高（日本語 SOTA 級） | 日本語のみなら最有力。JaCWIR / JQaRA で上位帯 |
| Cohere Rerank 3.5 multilingual | 高 | 多言語 SOTA 級。API 課金の対価分の精度は出る |
| BGE Reranker v2-m3 | 中〜高 | 汎用トップクラス。日本語も安定してカバー |
| Jina Reranker v3 | 中〜高（listwise 効果あり） | 64 件同時再ランキングで長文コンテキストに強い |
| mxbai-rerank-large-v2 | 中 | BGE に迫る精度、モデルが軽い |
| jina-colbert-v2 | 中 | クロスエンコーダより一歩劣るが、Bi-Encoder 相当の速度 |
日本語 QA / 日本語ドキュメント検索を最大精度で組むなら Ruri Reranker、日英混在 / 英語論文も混ぜたい社内 RAG なら BGE Reranker v2-m3、と使い分けるのが 2026 年時点の穏当な線引きです。Cohere Rerank 3.5 は API 課金で精度と手離れが両立しますが、社内文書を外に出せる契約かどうかで採否が分かれます。
埋め込み側との組み合わせで nDCG がどこまで伸びるかは、埋め込み Top-100 → リランカー Top-10 の構成で、埋め込み単体 Top-10 と比べて 5〜15 ポイント伸びるのが目安レンジです。埋め込みが日本語 SOTA（Ruri-large）でリランカーを外した場合と、埋め込みが汎用（BGE-M3）でリランカーに Ruri Reranker を挿した場合を比較すると、後者のほうが最終 nDCG が上回る事例が公開ベンチで報告されています。「埋め込みを最上位に変える」より「そこそこの埋め込み + 良いリランカー」のほうが最終精度が伸びやすい、というのが日本語 RAG の運用感覚です。
判断軸 2：レイテンシ（1 ペアあたりの ms）
RAG のユーザー体験を決めるのが検索段のレイテンシです。埋め込みでの Top-K 取得は数十 ms で終わりますが、リランカーは 50〜100 ペアを直列で処理するため、ここが体感速度に直結します。
| モデル | GPU 上の 1 ペア推論目安 | 50 ペア再ランキング目安（GPU） | CPU 上の 1 ペア推論目安 |
|---|---|---|---|
| BGE Reranker v2-m3 | 約 10〜15 ms | 約 500〜800 ms | 約 200〜400 ms |
| Jina Reranker v3（listwise） | 約 50〜80 ms（64 件同時） | 約 100〜200 ms（1 リクエスト） | ローカル運用は非推奨 |
| Cohere Rerank 3.5（API） | 平均 約 200〜600 ms（ネットワーク込み） | ネットワーク往復依存 | クラウド API |
| Ruri Reranker | 約 10〜15 ms | 約 500〜800 ms | 約 200〜400 ms |
| mxbai-rerank-large-v2 | 約 8〜12 ms | 約 400〜700 ms | 約 150〜300 ms |
| jina-colbert-v2 | 約 5〜10 ms | 約 250〜500 ms | 約 100〜200 ms |
Jina Reranker v3 の listwise 方式は「64 ドキュメントを 1 回のリクエストで並べ替える」設計のため、単純な pair 換算では他のクロスエンコーダより遅く見えます。ただし 50〜64 ペアを 1 度に処理する全体スループットでは他のクロスエンコーダを上回るケースがあり、長文コンテキスト RAG で相対順位の一貫性が要る用途で効果的です。
Cohere Rerank 3.5 の API はサーバーサイド処理が速いものの、ネットワーク往復のオーバーヘッドが入ります。国内リージョンからの平均往復は 200〜300 ms 程度が多く、リランカー処理そのものと合わせて 400〜600 ms が実測レンジです。「1 検索 1 秒以内」の SLO が厳しい場合は自前ホストのほうが安定します。
判断軸 3：VRAM 消費とディスク
VRAM 要件は、リランカー本体の重みとバッチサイズ・シーケンス長に依存します。バッチサイズ 8・シーケンス長 512 を前提にした目安です。
| モデル | 重みサイズ | 実効 VRAM 消費 | ディスク（インデックス含む） |
|---|---|---|---|
| BGE Reranker v2-m3 | 約 2.3 GB（FP32） | 約 1.5〜2.5 GB | ほぼゼロ（リランカーはインデックス不要） |
| Ruri Reranker | 約 1.4 GB（FP32） | 約 1.0〜2.0 GB | ほぼゼロ |
| mxbai-rerank-large-v2 | 約 1.7 GB（FP32） | 約 1.5〜2.0 GB | ほぼゼロ |
| Jina Reranker v3（ローカル） | 約 3〜5 GB | 約 4〜6 GB（長コンテキスト時） | ほぼゼロ |
| Cohere Rerank 3.5 | API 課金 | 0（クラウド） | 0 |
| jina-colbert-v2 | 約 2.2 GB（FP32） | 約 2.0〜3.0 GB | インデックスが数十 GB に膨らむ |
BGE Reranker v2-m3 と Ruri Reranker は VRAM 12GB の民生 GPU（RTX 3060 12GB や RTX 5060 12GB）に埋め込みモデル + 生成 LLM と同居させても余裕があります。ColBERT 系だけは事情が違って、トークン単位の多ベクトルをインデックスに保持するため、100 万チャンクで数十 GB 級のインデックスを覚悟する必要があります。ディスク側の制約が実務では効きます。
判断軸 4：コンテキスト長
再ランキング対象のドキュメントが長いほど、コンテキスト長制約が効きます。
- 512 トークン：Ruri Reranker（v3 large 相当）。日本語 512 トークンは約 400〜500 字なので、チャンクを長めに切っていると打ち切られる
- 4,096 トークン：Cohere Rerank 3.5
- 8,192 トークン：BGE Reranker v2-m3、mxbai-rerank-large-v2、jina-colbert-v2
- 131,072 トークン（listwise）：Jina Reranker v3。64 件を 1 リクエストで並べ替える設計
チャンクを 512〜1,024 トークンで切っている社内 RAG なら Ruri Reranker で足ります。技術ドキュメントや論文で 1 チャンク 2,000〜4,000 トークンを扱う設計なら BGE Reranker v2-m3 か Jina Reranker v3 が安全です。埋め込みモデル側のチャンク設計は「ローカルLLM 埋め込みモデル比較 2026年版」の判断軸と揃えて選ぶと後戻りが減ります。
判断軸 5：ライセンスと商用利用
社内 / 商用で使う場合はライセンスが実務的な制約になります。
| モデル | ライセンス | 商用利用 |
|---|---|---|
| BGE Reranker v2-m3 | MIT | 可 |
| Jina Reranker v3 | Apache 2.0（ローカル版）/ API 併用 | 可 |
| Cohere Rerank 3.5 | 商用 API | 可（利用規約に従う） |
| Ruri Reranker | Apache 2.0 相当 | 可（モデルカード要確認） |
| mxbai-rerank-large-v2 | Apache 2.0 | 可 |
| jina-colbert-v2 | Apache 2.0 | 可 |
法務レビューが必要な場合は、モデルカード側の最新ライセンス条項を必ず確認してください。
スループットとコスト試算：1M クエリ / 月の場合
現実的な運用規模でのコスト比較です。1 検索あたり Top-100 埋め込み → Top-10 リランカー、月間 1M クエリを想定します。
| 構成 | 初期投資 | 月額運用 | 総額（12 ヶ月） |
|---|---|---|---|
| RTX 3060 12GB + BGE Reranker v2-m3 | 約 5.5 万円（GPU）+ 約 15 万円（本体） | 電気代 約 1,500 円 | 約 22 万円 |
| RTX 5060 Ti 16GB + BGE Reranker v2-m3 | 約 8 万円（GPU）+ 約 18 万円（本体） | 電気代 約 1,800 円 | 約 28 万円 |
| Cohere Rerank 3.5 API（Top-100 → Top-10） | 0 | 約 5〜8 万円 / 月（利用量次第） | 約 60〜100 万円 |
1M クエリ / 月を超えるあたりから、自前ホストのほうが総額で明確に安くなる帯が来ます。逆に月 10 万クエリ未満の試作フェーズでは、GPU の初期投資より Cohere API のほうが軽いです。「試作で Cohere → クエリ量が読めたら自前ホスト」という段階移行が合理的です。
なお、AI 開発機側の GPU 選定は「ローカルLLM 向け GPU 購入ガイド 2026年版」でカバーしています。RAG 用にリランカーを常駐させる 24 時間サーバー設計は「自宅ローカルLLMサーバー構築ガイド 2026年版」を参照してください。
用途別の使い分けフロー
用途別に「まずどれで始めるか」の目安は以下の通りです。
- 社内 QA / 日本語 FAQ 検索：Ruri Reranker（日本語精度が最重要）。埋め込み側も Ruri-large と揃えて日本語一貫性を上げる
- 日英混在 / 論文込みの技術 RAG：BGE Reranker v2-m3（多言語対応の汎用型）。埋め込み側は BGE-M3 で揃えると相性が良い
- 試作フェーズ / 月間 10 万クエリ未満：Cohere Rerank 3.5 API（GPU なしで即動く）。運用が固まったら自前ホストへ移行
- 長文コンテキスト RAG / 論文検索 / 契約書レビュー：Jina Reranker v3（131k コンテキスト、listwise）
- モバイル / エッジ推論：mxbai-rerank-large-v2（軽量で BGE に迫る精度）
- 超大規模検索インデックス（1 億件超）：jina-colbert-v2（Bi-Encoder 相当の速度、ただしインデックス数十 GB）
埋め込みモデルとの組み合わせ表
リランカー単体では機能しません。埋め込みモデルとのペアで RAG の精度が決まります。日本語 RAG での定番組み合わせを整理します。
| 埋め込みモデル | 相性の良いリランカー | ユースケース |
|---|---|---|
| Ruri-large（日本語 SOTA） | Ruri Reranker | 日本語 QA、社内 FAQ、日本語ドキュメント検索 |
| BGE-M3（多言語 SOTA） | BGE Reranker v2-m3 | 日英混在、技術 RAG、論文検索 |
| multilingual-e5-large | BGE Reranker v2-m3 or Cohere Rerank 3.5 | 汎用多言語 RAG、既存 e5 資産の活用 |
| Qwen3-Embedding-8B | BGE Reranker v2-m3 or Jina Reranker v3 | 最新 SOTA を狙う多言語 RAG |
| GTE-multilingual-base | mxbai-rerank-large-v2 | 軽量・長文の RAG |
同一プロバイダで揃えると学習分布が近いため相性が良い傾向はあります。とはいえ絶対条件でもなく、日本語精度が最優先なら「BGE-M3 埋め込み + Ruri Reranker」といった異種組み合わせも実務では有効です。試作段階で 2〜3 パターン評価するのが安全です。
導入時の注意点
- リランカーの Top-K を切りすぎない：埋め込みで Top-100 まで広げてリランカーを効かせるほうが最終 nDCG が伸びます。Top-20 まで絞ってからリランカーを回すと、良い候補が既に落ちている可能性があります
- ゼロショットで使う前提：主要リランカーはすべてゼロショットで実用精度が出ます。自社データでファインチューニングは初期段階では不要です
- バッチ推論を活用する：50〜100 ペアを for ループで直列に回すとレイテンシが大きくなります。sentence-transformers や FlagEmbedding のバッチ推論 API を使うと GPU で 4〜8 倍高速化します
- キャッシュを効かせる：同一クエリ・同一ドキュメントの組み合わせは Redis / メモリキャッシュに保存すると、リランカー呼び出しが減ってコストと遅延の両方が下がります
結論：4 モデル + 補足 2 モデルの決め方（2026 年 8 月時点）
要点をもう一度整理します。
- 日本語のみで最大精度：Ruri Reranker（cl-nagoya、日本語 SOTA 級）
- 日英混在の汎用型：BGE Reranker v2-m3（BAAI、MIT ライセンス、無難な標準）
- 試作の即席 API：Cohere Rerank 3.5（GPU 不要、月間 10 万クエリまでは API のほうが軽い）
- 長文コンテキスト RAG：Jina Reranker v3（131k コンテキスト、listwise）
- 軽量・エッジ：mxbai-rerank-large-v2（BGE に迫る精度で 435M）
- 超大規模検索：jina-colbert-v2（Bi-Encoder 相当の速度、インデックスは大きい）
**RAG の精度は「埋め込みモデル選定で 8 割、リランカーで残り 2 割」**というのが 2026 年時点の運用感覚です。埋め込みを最上位に変えるより、そこそこの埋め込みに良いリランカーを足すほうが最終精度が伸びやすい、と覚えておくと投資対効果を外しません。
あなたに合うPCを診断する
用途や予算をもう少し細かく入力すると、3つの候補構成を提案します。
→ 診断スタート
関連記事
- ローカルLLM 埋め込みモデル比較 2026年版：BGE-M3 / multilingual-e5-large / GTE-large / Qwen3-Embedding / Ruri を日本語RAG 精度・速度・VRAM で選ぶ：リランカーとペアで使う埋め込み側の選び方
- ローカルLLM RAG用ベクトルDB比較 2026年版：Qdrant / Milvus / Weaviate / Chroma / pgvector を埋め込み次元・速度・運用で選ぶ：埋め込み → リランカー前段のベクトルDB 選び
- ローカルRAG構築向けPC構成ガイド 2026年版：埋め込み + リランカー + 生成 LLM を同居させる PC 構成
- 自宅ローカルLLMサーバー構築ガイド 2026年版：リランカー常駐サーバーの設計
よくある質問
- リランカー（Reranker）とは何ですか？埋め込みモデルと何が違いますか？
- リランカーは、埋め込みモデルが返した検索結果 Top-K を「クエリとドキュメントを 1 組ずつ同時に読み直して」精密に並べ替えるクロスエンコーダです。埋め込みモデルはクエリとドキュメントをそれぞれ別々にベクトル化してから距離を測るため大量比較は速い代わりに精度が粗く、リランカーは 1 ペアごとにトランスフォーマを通す代わりに精度が高いという分業関係です。RAG では「埋め込みで Top-100 を絞る → リランカーで Top-10 に精選」の 2 段構成が定石です。
- 日本語 RAG で最初に選ぶリランカーはどれですか？
- 「まず 1 個で始める」なら BGE Reranker v2-m3 が穏当です。多言語対応・MIT ライセンス・VRAM 数百 MB から動く軽さ・日本語 nDCG も上位帯という条件が揃っています。日本語のみを扱う社内 QA を最大精度で組みたいなら Ruri Reranker、レイテンシを最優先するなら Jina Reranker v3、運用の手離れを最優先するなら Cohere Rerank 3.5 の API 課金という順序で検討するのが自然です。
- リランカーを入れると RAG の精度はどれくらい上がりますか？
- 埋め込み Top-100 に対してリランカー Top-10 を挿すと、日本語 RAG の nDCG@10 が 5〜15 ポイント上がるのが公表ベンチと外部評価の目安レンジです。特にクエリが短く曖昧な場合（例: 単語 1〜2 語の検索）ほどリランカーの効きが大きく、逆に長文で意味が明確なクエリでは差が縮みます。「埋め込みだけで RAG の精度が頭打ちになった」段階でリランカー追加を検討するのが投資対効果として合理的です。
- BGE Reranker v2-m3 と Ruri Reranker はどちらが日本語で強いですか？
- 日本語のみを扱うなら Ruri Reranker、日英混在や多言語混在なら BGE Reranker v2-m3、というのが 2026 年時点の穏当な線引きです。Ruri Reranker は cl-nagoya が公開する日本語特化のクロスエンコーダで、JaCWIR / JQaRA といった日本語ベンチで SOTA 級のスコアが目安です。BGE Reranker v2-m3 は 100 言語超対応の汎用型で、日本語もカバーしつつ英語ドキュメントを混ぜても崩れないという安定感があります。
- Cohere Rerank と自前ホスト（BGE / Jina）はどちらが得ですか？
- 運用手離れとレイテンシで Cohere Rerank、コストと制御可能性で自前ホスト、という分岐です。Cohere Rerank 3.5 は API 課金で 1,000 検索あたりの目安が数円〜数十円で、GPU の管理コストが要りません。一方で自前ホストなら RTX 3060 級 GPU 1 枚で BGE Reranker v2-m3 が動き、月間 1M クエリを超えると自前ホストのほうが総額で安くなる帯が来ます。試作は Cohere、本番でクエリ量が読めたら自前ホスト、という段階移行が合理的です。
- リランカーを動かすのに必要な VRAM はどれくらいですか？
- BGE Reranker v2-m3 なら 数百 MB 〜 約 2GB、mxbai-rerank-large-v2 なら 約 2GB、Ruri Reranker（v3 large 相当）なら 約 2〜3GB、Jina Reranker v3 のローカル版で 約 3〜5GB が目安です。埋め込みモデルと LLM 生成側と同居させる場合を含めても、リランカー本体は数 GB のオーダーで、VRAM 12GB クラスの民生 GPU で十分に賄えます。ColBERT 系（jina-colbert-v2 など）はインデックスが数十 GB に膨らむ設計なので、VRAM 制約より必要ディスクとメモリのほうが実務上の主な制約になります。