リランキング（Rerank）とは｜RAGの検索精度を上げる仕組みと実装
最終更新日：2026/10/15
リランキングとは、検索で拾った候補文書をクエリとの関連度で評価し直し、上位数件に絞り込む処理です。ベクトル検索だけでは「近いが答えではない」文書が上位に残る問題を補正します。ただし前段の候補に正解が入っていなければ効きません。RAG改善に取り組むエンジニア向けに、仕組み・モデル選定・候補件数の決め方・切り分けを整理します。
先に結論
リランキングは「広く雑に取る1段階目」と「狭く正確に選ぶ2段階目」を分ける設計で、検索側のボトルネックに効く施策です
入れるなら最初の一手は候補件数の見直し。1チャンク300〜800トークン程度の一般的な構成なら、1段階目で上位20件しか取っていないところを50〜100件に広げ、リランカーで上位3〜5件に絞る形が起点になります
日本語データが中心なら、公開ベンチマーク（JQaRA・JaCWIR）で日本語特化モデルが高いスコアを示す例があるため、多言語モデルと並べて候補に入れる価値があります
マネージド検索基盤（Azure AI Search・Amazon Bedrock・Pinecone）を使っているなら、自前でモデルを建てる前に標準機能のリランクを試すほうが早いです
1段階目の候補集合に正解チャンクが入っていない場合、リランキングを足しても改善しません。先にチャンク設計と検索方式を疑ってください
この記事でわかること
リランキングの仕組みと、ベクトル検索だけでは精度が頭打ちになる理由
候補件数（取得件数）と返却件数の決め方、レイテンシ・コストとの釣り合い
主要リランカーの選択肢と、日本語RAGでの選定基準
Azure・AWS・Pineconeそれぞれの実装パスと制約
「入れたのに効かない」ときの原因切り分けと打ち手
対象は、RAGを一度構築したことがあり、検索結果の質を上げたいエンジニアです。RAGそのものが初めての方は、先に「RAGとは？仕組み・活用事例・導入メリットをわかりやすく解説」で全体像を押さえてから読むとつながります。
目次
リランキング（Rerank）とは｜2段階検索の後半を担う処理
RAGパイプラインでのリランキングの位置と処理の流れ
候補件数と返却件数の決め方
リランカーモデルの選択肢｜API型とセルフホスト型
主要リランカーの選択肢まとめ
実装パターン｜検索基盤に任せるか自前で挟むか
リランキングで精度が上がらないケースと対策
導入手順と検証チェックリスト
フリーランス案件でリランキングの知見はどう扱われるか
まとめ
よくある質問
リランキング（Rerank）とは｜2段階検索の後半を担う処理
リランキングは、検索システムが返した候補を別のモデルで評価し直し、関連度の高い順に並べ替える処理です。情報検索の世界では以前から使われてきた考え方で、RAGの普及にあわせて再び注目された形になります。
条件としては、1段階目の検索（Retrieval）が存在することが前提です。リランカー単体では検索できません。あくまで「候補を絞り込む係」であり、候補を作る係ではない。ここを取り違えると設計がねじれます。
例外として、候補件数が最初から5件以下しかないようなケースでは、並べ替える余地が小さいため効果は限定的です。
ベクトル検索だけでは上位が荒れる理由
ベクトル検索は、クエリと文書をそれぞれ独立にベクトル化し、距離で近さを測ります。この方式はバイエンコーダ（Bi-Encoder）と呼ばれます。
文書側のベクトルは事前計算できるため、数百万件規模でも高速に検索できます。その代わり、クエリと文書を「突き合わせて」判断してはいません。クエリの意図と文書の内容が交差する箇所を見ずに、全体の意味の近さだけで測っている。結果として、トピックは合っているが質問に答えていない文書が上位に混じります。
具体的には、こうした症状が出ます。
同じ製品名が頻出するだけの目次ページや改訂履歴が上位に来る
質問の否定形（「〜できないケース」）を無視して肯定形の説明が選ばれる
似た文体の文書が固まって上位を占め、答えのある文書が7〜15位あたりに沈む
クロスエンコーダとバイエンコーダの違い
リランカーの多くはクロスエンコーダ（Cross-Encoder）という構造を取ります。クエリと文書を連結してひとつの入力としてモデルに通し、関連度スコアを1つ出力する方式です。
クエリと文書のトークン同士が相互に影響するため、判定は精度が高くなります。一方で、事前計算が効きません。候補1件ごとにモデルを走らせる必要があり、計算量は候補件数に比例します。
観点 | バイエンコーダ（ベクトル検索） | クロスエンコーダ（リランカー） |
|---|---|---|
入力の扱い | クエリと文書を別々にベクトル化 | クエリと文書を連結して1本で評価 |
事前計算 | 文書ベクトルを事前に作れる | 事前計算できない（クエリ依存） |
速度 | 数百万件でも高速 | 候補件数に比例して遅くなる |
精度 | 意味の近さは取れるが取りこぼしあり | 関連度の判定が細かい |
役割 | 候補を広く集める | 候補を正確に絞る |
この表のとおり、両者は競合ではなく分担の関係です。速いほうで広く集め、遅いが正確なほうで絞る。これが2段階検索の基本設計になります。
ミニFAQ：ベクトル検索をやめてリランカーだけにはできませんか。
できません。クロスエンコーダは候補1件ごとに推論するため、全文書を対象にすると現実的な応答時間に収まらないからです。数万件のコーパスでも全件評価は非現実的で、必ず前段で候補を絞る必要があります。
RAGパイプラインでのリランキングの位置と処理の流れ
リランキングは、検索とLLMへのコンテキスト投入のあいだに入ります。順序としては「検索 → リランク → プロンプト組み立て → 生成」です。
候補取得・再評価・絞り込みの3ステップ
処理の流れを分解すると、次の3つになります。
候補取得：ベクトル検索や全文検索で上位50〜100件を取る。ここは再現率（正解が候補に入っている割合）を優先する
再評価：リランカーがクエリと各候補の関連度をスコア化し、並べ替える
絞り込み：上位3〜5件だけをLLMに渡す。ここは適合率（渡した文書が本当に関連している割合）を優先する
1段階目と3段階目で最適化する指標が違う点がポイントです。1段階目で件数を絞りすぎると、リランカーがどれだけ優秀でも正解を拾えません。逆に最終的にLLMへ渡す件数を増やしすぎると、関係ない文書がノイズになり、回答がぶれます。
LLMに渡す件数を絞ることは、トークン削減にも直結します。コスト面の設計は「LLMコスト最適化案件の単価相場｜トークン削減・推論設計のフリーランス実務」でも扱っています。
ハイブリッド検索・スコア融合との関係
1段階目をベクトル検索だけにせず、キーワード検索（BM25など）と組み合わせる構成もよく使われます。両者の結果をRRF（Reciprocal Rank Fusion）などで融合し、その融合結果をリランカーに渡す形です。
型番・エラーコード・固有名詞など、ベクトル検索が苦手な文字列一致を全文検索側が拾ってくれます。全文検索の基盤としては、Elasticsearchとは？全文検索エンジンの仕組み・ELKスタック・案件単価をフリーランス視点で解説で整理したようなエンジンが使われます。
ハイブリッド検索とリランキングは排他ではありません。候補の作り方を改善するのがハイブリッド検索、候補の選び方を改善するのがリランキングです。両方入れている構成も珍しくありません。
候補件数と返却件数の決め方
結論から言うと、候補取得は50件、最終返却は3〜5件を起点にして、評価指標を見ながら動かすのが実務的です。
条件として、これはチャンクサイズが300〜800トークン程度の一般的な構成を想定した数字です。1チャンクが極端に大きい場合は候補件数を減らす方向に調整します。
例外もあります。FAQのように1問1答が短く独立している文書群では、候補20件でも十分なケースがあります。逆に、長文マニュアルを細かく割っている場合は100件以上取らないと正解が入りません。
起点にする数値と調整の方向
症状 | 調整の方向 | 具体的な動かし方 |
|---|---|---|
リランク後も正解が入らない | 候補件数を増やす | 50→100→200と広げ、再現率が頭打ちになる点を探す |
回答に関係ない話が混ざる | 返却件数を減らす | 5→3に絞る。スコア下限でのカットも併用する |
応答が遅い | 候補件数を減らす | 100→50。モデルを軽量なものへ落とす選択肢も |
候補を増やしても精度が変わらない | 件数以外を疑う | チャンク設計・埋め込みモデル・クエリ拡張を見る |
候補件数を増やすほど再現率は上がりますが、どこかで頭打ちになります。その点を超えてもレイテンシとコストだけが増えるので、再現率のカーブが寝る位置を実測で押さえておくと判断が早くなります。
レイテンシとコストのトレードオフ
リランカーは候補件数に比例して時間がかかります。候補100件を再評価する構成は、50件の構成のおおむね2倍の計算量です。
APIで提供されるリランカーは、多くが検索リクエスト単位の従量課金です。1リクエストあたりの候補件数に上限がある点も設計に効きます。たとえばPineconeがホストするモデルでは、Rerank resultsに記載のとおり、1リクエストで扱える文書数の上限がモデルごとに異なります（bge-reranker-v2-m3で100件、cohere-rerank-4-fastで250件）。
セルフホストの場合は課金ではなくGPUリソースが制約になります。軽量モデルならCPUやApple Siliconでも動きますが、バッチサイズと同時実行数の設計は必要です。
ミニFAQ：候補件数はベクトル検索とキーワード検索で別々に決めるべきですか。
別々に決めて融合後に重複排除するのが扱いやすいです。それぞれ30〜50件ずつ取って融合し、重複を除いた60〜80件をリランカーに渡す構成なら、片方が外したときにもう片方が拾う余地が残ります。
リランカーモデルの選択肢｜API型とセルフホスト型
選択肢は大きく2つ、マネージドAPIとセルフホストに分かれます。運用体制とデータの扱いで決まる部分が大きいところです。
マネージドAPIの主な選択肢
APIを叩くだけで使えるため、検証の立ち上がりが速いのが利点です。社内データを外部に出せるかどうかが判断の分かれ目になります。
Cohereは専用のリランクモデルを提供しており、公式ドキュメントでは2026年10月時点でrerank-v4.0-proとrerank-v4.0-fastが最新系統として案内されています。モデル名とバージョンは入れ替わるため、採用時は必ず公式のモデル一覧で現行版を確認してください。旧世代のv3.5系は4096トークンのコンテキスト長で、クエリと文書の合計がこれを超えると自動的に分割される仕様でした。
Pineconeは自社のインデックスとセットでリランクを提供しており、2026年10月時点の公式ドキュメントではcohere-rerank-4-fast、bge-reranker-v2-m3、独自のpinecone-rerank-v0が選べます。旧版のcohere-rerank-3.5は廃止予定として案内されているため、新規採用時は現行モデルを確認してください。ベクトルDB側の選定も含めて検討する場合は「ベクトルDBの選び方｜Pinecone・Weaviate・Qdrant・pgvectorの使い分け」が参考になります。
セルフホストの主な選択肢
オープンライセンスのモデルを自社環境で動かす方式です。データを外に出さずに済み、従量課金も発生しません。
多言語で広く使われているのがBAAIのbge-reranker-v2-m3です。日本語を含む多言語に対応し、ライセンス面でも採用しやすい部類に入ります。
日本語に特化したモデルも選択肢があります。名古屋大学の研究グループが公開するruri-v3-reranker-310mは、Hugging Faceのモデルカードによるとパラメータ数315M、最大系列長8192トークン、Apache License 2.0で公開されています（2026年10月時点の記載）。同カードの比較表では、日本語Q&A検索の評価データセットJQaRAでnDCG@10（上位10件の順位品質を測る指標）が0.869と、同表に掲載された他の日本語リランカーより高い値が示されています。これはモデル提供側が同一条件で測った公開値であり、自社データでの実測とは分けて見る必要があります。
日本語RAGでのモデル選定
日本語データが中心なら、多言語モデルを選ぶ前に日本語特化モデルを候補に入れる価値があります。評価用のデータセットとしてはJQaRA（日本語Q&Aの検索評価用）とJaCWIR（Webタイトルと概要を使った日本語情報検索の評価用）が公開されており、モデル公開側もこれらのスコアを添えていることが多いため、横比較の手がかりになります。
サイズ違いのモデル群も公開されています。japanese-reranker v2シリーズは作者の公開記事で層数・隠れ層サイズ・ベンチマークスコアが整理されており、tiny-v2からbase-v2まで4段階あります。同記事に掲載されたJQaRAのスコアはtiny-v2で0.6455、base-v2で0.7845。同じベンチマークを同一条件で流したときの処理時間はtiny-v2が約2秒、base-v2が約33秒とされており、精度と速度が引き換えになる関係が読み取れます。いずれも作者環境での公開値のため、絶対値ではなくモデル間の相対差として扱ってください。
精度を取るか速度を取るかは、ユースケースの許容レイテンシ次第です。社内ナレッジ検索のように数秒待てる用途なら大きいモデル、チャットUIで即応性が要るなら軽量モデル、という切り分けになります。
主要リランカーの選択肢まとめ
ここまでの選択肢を、選定時の判断軸で1枚に整理します。記載内容は2026年10月時点で各提供元の公開ドキュメント・モデルカードを確認したものです。仕様・モデル名・上限値はいずれも変更されうるため、採用前に必ず一次情報で最新を確認してください。
選択肢 | 提供形態 | 日本語対応 | 向いているケース | 注意点 |
|---|---|---|---|---|
Cohere rerank系 | API | 多言語モデルあり | 検証を最短で立ち上げたい | 外部送信の可否確認。モデル版が入れ替わる |
Pineconeホストモデル | API（DB同梱） | モデルによる | すでにPineconeを使っている | 1リクエストの文書数上限がモデル別 |
Amazon Bedrock Rerank | API | モデルによる | AWS中心・Knowledge Bases利用中 | テキストデータのみ対応 |
Azure AI Search セマンティックランカー | 検索基盤の機能 | 多言語モデル | Azure中心・全文検索も必要 | 再ランク対象は上位50件まで |
bge-reranker-v2-m3 | セルフホスト | 多言語 | データを外に出せない | GPUリソースの確保が前提 |
ruri-v3-reranker系 | セルフホスト | 日本語特化 | 日本語精度を優先したい | 多言語混在データでは要検証 |
japanese-reranker v2系 | セルフホスト | 日本語特化 | 軽量環境・CPUで動かしたい | サイズで精度が明確に変わる |
実装パターン｜検索基盤に任せるか自前で挟むか
結論としては、すでにマネージド検索基盤を使っているなら標準機能から試すほうが速いです。自前でモデルを建てるのは、データを外に出せない場合か、日本語特化モデルを使いたい場合に絞ると判断がぶれません。
Azure AI Search のセマンティックランカー
Azure AI Searchは、セマンティックランカーという名称でリランク機能を持っています。Microsoft Learnの解説によると、BM25（キーワードの出現頻度をもとにしたスコアリング方式）またはRRFでスコア付けされた初期結果に対し、二次ランキングを追加する仕組みです。
実装上、押さえておきたい制約が3つあります（いずれも2026年10月時点の公式ドキュメント記載）。
再ランク対象は既定のランキングで上位50件まで。51位以下は対象外になる
各文書は要約モデルで最大2,048トークンの要約文字列にまとめられ、そのうちタイトル128トークン、キーワード128トークンという配分がある
スコアは0〜4の範囲で返る。4が「質問に完全に回答している」、0が「無関係」という定義
上位50件という上限は設計に直接効きます。1段階目の検索で正解が51位以下に沈んでいる場合、セマンティックランカーでは救えません。そのときはクエリ側やインデックス側の改善が先になります。
Azure上でLLMを動かす構成全体は「Azure OpenAI Serviceとは｜料金・モデル選定と企業LLM導入案件の実務」で整理しています。
Amazon Bedrock の Rerank
Bedrockは、リランカーモデルへのアクセスを2通りで提供しています。AWS公式ドキュメントによると、Rerank操作を直接呼ぶ方法と、Knowledge Basesに対するRetrieveまたはRetrieveAndGenerate呼び出しの中でリランカーを指定する方法です。後者ではリランクの結果が既定の並び順を上書きします。
対応するのはテキストデータのみという制約があります。画像や表を含むマルチモーダルなRAGを組んでいる場合は、テキスト化した部分にしか効きません。
AWS側の全体像は「Amazon Bedrockとは｜主要モデル・料金とAWS LLM開発案件」にまとめています。
自前パイプラインに挟む
LlamaIndexやLangChainを使っている場合、検索結果に対する後処理としてリランカーを差し込む構成が取れます。検索器の出力をリランカーに渡し、上位n件だけを次の段に流す形です。
フレームワーク側の設計思想は「LlamaIndexとは｜RAG構築の仕組み・LangChainとの違いを解説」で解説しています。
この方式の利点は、検索基盤とリランカーを独立して差し替えられる点です。ベクトルDBを変えてもリランカーは据え置ける。逆に、推論環境の運用は自分たちで持つことになります。
リランキングで精度が上がらないケースと対策
導入したのにスコアが動かない、という相談は珍しくありません。原因はだいたい3つに分類できます。
症状 | 考えられる原因 | 打ち手 |
|---|---|---|
リランク後も正解が出ない | 候補集合に正解が入っていない | 候補件数を増やす。ハイブリッド検索を導入する |
スコアが全体的に低く横並び | チャンクが文脈を失っている | チャンクサイズとオーバーラップを見直す |
体感は変わったが数値が動かない | 評価指標が検索側を見ていない | 検索段と生成段を分けて測る |
一部のクエリだけ悪化する | クエリの性質とモデルの相性 | クエリ種別ごとにスコアを分解する |
候補集合に正解が入っていない
最も多いパターンです。リランカーは候補の中から選ぶだけなので、候補に正解がなければ何もできません。
切り分けは単純で、1段階目の検索結果の上位100件に正解チャンクが含まれているかを手で確認します。含まれていなければ、リランキングの話ではなく検索の話です。埋め込みモデルの変更、ハイブリッド検索の導入、クエリ拡張などが先に来ます。
チャンク設計が壊れている
チャンクの切り方が悪いと、1つのチャンクに答えが収まらず、どのチャンクもスコアが中途半端になります。この状態ではリランカーが選びようがありません。
見分け方は、リランカーのスコア分布を見ることです。上位と下位で差がつかず全体が横並びなら、チャンク側を疑います。「RAGのチャンク分割｜サイズ・オーバーラップの決め方と検証手順」に検証手順をまとめてあります。
評価指標を見ずに入れている
「入れたら良くなった気がする」で止まると、次の判断ができません。検索段の指標（正解が上位n件に入っている割合など）と、生成段の指標を分けて測る必要があります。
評価の進め方は「RAGの評価方法｜Ragasの評価指標とボトルネック特定・精度改善」が詳しいです。LLM出力そのものの品質評価は「LLM評価（Evals）とは｜LLM-as-a-Judgeと品質保証の実務まで解説」を参照してください。
検索精度が上がると、根拠のない回答も減らしやすくなります。この観点は「ハルシネーション対策｜LLMの誤回答を減らす実装と運用設計」と合わせて考えると設計が整理されます。
導入手順と検証チェックリスト
実際に入れるときの順番です。いきなり本番に入れず、評価セットを先に作るのが遠回りに見えて速い進め方になります。
評価セットを作る：実際に来る質問を30〜50問、正解チャンクとセットで用意する
ベースラインを測る：リランキングなしで、正解が上位5件に入っている割合を記録する
候補件数を広げる：1段階目を50〜100件に増やし、正解が候補に入る割合を確認する
リランカーを1つ試す：まずは1モデルだけ。複数を同時に比べると原因が切り分けられない
返却件数を調整する：上位3件と5件で生成結果を比較する
レイテンシを測る：候補件数ごとに応答時間を記録し、許容値と突き合わせる
モデルを比較する：ここで初めて複数モデルを横並びにする
検証時のチェックリストも置いておきます。
評価セットの質問が、実際のユーザー質問の分布を反映しているか
検索段と生成段の指標を分けて測っているか
候補件数を変えたときの再現率カーブを記録したか
レイテンシの測定にリランカー以外の処理時間が混ざっていないか
日本語以外のデータが混在していないか（混在する場合は多言語モデルを優先）
本番相当のデータ量で測っているか（小さいコーパスでは差が出にくい）
グラフ構造を使った別アプローチと比較したい場合は「GraphRAGとは｜通常RAGとの違い・仕組み・構築案件の実務」も選択肢に入ります。
フリーランス案件でリランキングの知見はどう扱われるか
RAG構築案件では、「作ったが精度が出ない」フェーズの相談が一定数あります。検索段と生成段を分けて切り分けられること、候補件数やチャンク設計を数値で検証した経験があることは、面談で具体的に話せる材料になります。
逆に、モデル名を並べられるだけでは差がつきにくい領域でもあります。どの指標をどう測り、何を変えてどう動いたかを言語化できるかどうかが見られます。
案件の種類や必要スキルの整理は「RAG構築案件の実情｜単価相場・必要スキル・獲得方法」、エージェント開発寄りの案件は「AIエージェント開発案件の単価相場｜必要スキル・獲得ルートを解説」にまとめています。単価の考え方を体系的に押さえたい場合は「【2026年最新版】フリーランスエンジニアの単価相場と単価の上げ方とは？」が入口になります。
自分のスキルセットでどのくらいの単価を狙えるか気になる方は、無料のフリーランスエンジニア単価診断で市場単価の目安を確認できます。実際の募集内容は案件一覧から確認してください。
まとめ
リランキングは、RAGの検索段で「広く取る」と「正確に選ぶ」を分業させる設計です。候補件数を広げたうえで上位3〜5件に絞る構成が、最初に試す価値のある形になります。
要点を整理します。
リランカーはクロスエンコーダでクエリと文書を突き合わせ、ベクトル検索の取りこぼしを補正する
候補50〜100件を取得し、リランク後に上位3〜5件をLLMへ渡す構成を起点にする
候補集合に正解が入っていなければリランキングでは救えない。先に検索段を疑う
マネージド検索基盤を使っているなら標準機能から試す。Azure AI Searchは上位50件という上限がある
日本語中心のデータでは、日本語特化リランカーが選択肢に入る
評価セットを先に作り、検索段と生成段を分けて測る
次のステップとしては、手元のRAGで「1段階目の上位100件に正解が入っているか」を30問ほど手作業で確認するところから始めると、リランキングが効く構成かどうかが判断できます。
参照した一次情報は以下のとおりです。
よくある質問
リランキングを入れるとどのくらい遅くなりますか
候補件数・モデルサイズ・実行環境で変わるため、一律の目安は出せません。候補件数に比例して増える、という関係だけが共通です。候補を200件に広げたり大きいモデルを使ったりすると、1段階目の検索より時間がかかることもあります。許容レイテンシを先に決め、自分の環境で候補件数ごとに実測してから件数を詰めるほうが手戻りが少なくなります。
ハイブリッド検索とリランキング、どちらを先に入れるべきですか
候補に正解が入っていないならハイブリッド検索、候補には入っているが順位が低いならリランキングです。1段階目の上位100件に正解チャンクが含まれているかを数十問で確認すれば、どちらが先かは判断できます。
マネージドAPIとセルフホスト、コストはどちらが安いですか
クエリ数と候補件数で変わるため、どちらが安いかは一概には言えません。APIは検索リクエスト単位の従量課金、セルフホストはGPUなどの固定的なリソース費用という違いがあり、課金の形が異なります。リクエストが少ないうちは常時リソースを確保する構成の単価が割高になりやすく、リクエストが多い場合は逆転しうる、という関係です。実際の損益分岐はクエリ数と候補件数の積、各社の最新の料金表で変わるため、両方を自分の想定ボリュームで見積もって比較してください。
日本語特化モデルと多言語モデル、どちらを選ぶべきですか
データがほぼ日本語なら日本語特化モデルを先に試す価値があります。公開ベンチマークのJQaRAやJaCWIRでは、日本語特化モデルが高いスコアを示している例が見られます。ただし英語ドキュメントや多言語マニュアルが混在する場合は、言語ごとに精度が割れるリスクがあるため多言語モデルのほうが扱いやすいです。
リランカーのスコアで足切りはすべきですか
用途によります。「該当する文書がないときは答えない」挙動を作りたい場合、スコア下限での足切りは有効です。ただしスコアの分布はモデルやクエリによって変わるため、固定のしきい値を決め打ちすると取りこぼしが出ます。評価セットで分布を確認してから設定してください。Azure AI Searchのように、スコア分布が環境要因で変動しうることを公式が明記しているケースもあります。
ベクトルDBを変えればリランキングは不要になりますか
なりません。ベクトルDBの違いは主に検索速度・スケール・運用性で、クエリと文書を突き合わせて判定する仕組みを持つわけではないためです。候補の作り方が変わっても、候補の選び方の課題は残ります。
チャンクサイズを小さくすればリランキングの効果は上がりますか
上がるケースと下がるケースがあります。チャンクが小さいほど1チャンク内のノイズは減りますが、文脈が切れて意味が取れなくなると逆効果です。親子チャンク（小さい単位で検索し、親の大きい単位をLLMに渡す）のような構成と組み合わせる方法もあります。
リランカーの学習（ファインチューニング）は必要ですか
多くのケースでは既製モデルで足ります。ドメイン固有の言い回しが強く、既製モデルのスコアが頭打ちになったときに初めて検討する順序が現実的です。学習データとして、クエリと正解チャンクのペアを数百〜数千件用意する必要があり、準備コストは小さくありません。
既存のRAGに後から追加できますか
できます。リランキングは検索とプロンプト組み立ての間に挟む処理のため、検索基盤やベクトルDBを入れ替えずに追加できます。マネージド検索基盤の標準機能を使う場合は、クエリ側のパラメータ指定だけで有効化できるケースもあります。
候補件数を増やし続ければ精度は上がりますか
どこかで頭打ちになります。再現率は候補件数とともに上がりますが、一定を超えると新しい正解がほとんど入ってこなくなる一方、レイテンシとコストだけが増えます。再現率のカーブが寝る位置を実測で押さえ、その手前に設定するのが効率的です。
リランキングとクエリ拡張はどちらが効きますか
課題の所在が違います。クエリ拡張は「クエリの表現が検索に向いていない」問題に効き、リランキングは「候補の順位が適切でない」問題に効きます。ユーザーの質問が曖昧で短い用途ではクエリ拡張、質問は明確だが上位が荒れる用途ではリランキングが先になります。
関連するタグ：
