RAG再ランキングは、第一段検索で見つけた候補の順番を精密に直す第二段処理です。コーパス全体を探し直さないため、正解が候補集合にない失敗は救えません。採用前には、第一段のRecall@K、再配置後のnDCG@10とMRR@10、追加p95遅延、入力切り捨て、権限外0件を別々に測ります。本稿では200問の段階ラベルを使い、候補数20・50・100から運用値を選びます。
RAG再ランキングは候補内の順位だけを直す
第一段検索は、BM25、ベクトル検索、ハイブリッド検索などを使って高速に数十件の候補を集めます。第二段の再ランキングは、質問と候補本文を対にして関連性を詳しく評価し、上位へ並べ直します。Cross-encoderは質問と候補を同時にモデルへ入力できるため、別々に埋め込んだベクトルの距離より細かな語の対応を扱えますが、候補ごとに推論する分だけ計算負荷が増えます。
NogueiraとChoの「Passage Re-ranking with BERT」は、BERTを質問とパッセージの関連性判定へ使う再ランキングを示した原著です。論文はMS MARCO passage retrievalで当時の従来手法に対する改善を報告しています[1]。
この研究結果は2019年の英語データと特定構成に関する実測であり、日本語の社内RAGへ同じ改善率を約束するものではありません。参照すべき中心は、広い候補生成と高価な精密順位付けを分離する設計です。
| 工程 | 入力範囲 | 直せる失敗 | 直せない失敗 |
|---|---|---|---|
| 第一段取得 | コーパス全体 | 候補漏れ、検索範囲 | 候補内の細かな順位 |
| 融合 | 複数検索の順位表 | 語彙と意味の補完 | 全経路で未取得の正解 |
| 再ランキング | 上位K件 | 候補内の順番 | K外の正解、原本欠損 |
| 回答生成 | 最終コンテキスト | 要約、組み立て | 渡されていない根拠 |
再ランキングの評価で最初に問うのは「上位が良くなったか」ではなく、「並べ直す前の集合に正解が入っていたか」です。
候補集合のRecallを入口条件にする
候補数を`K=50`とするなら、Recall@50は「質問に関連する正解チャンクのうち、第一段の上位50件へ入った割合」を質問ごとに求めて平均します。正解が一つの質問200問で、190問の正解が候補に入れば95%です。再ランキング後にtop10へ出たかどうかとは分けます。候補Recallが80%なら、どれほど優れた第二段でも残り20%を発見できません。
MicrosoftのAzure AI Search Semantic Ranker公式資料は、2026年4月24日更新です。同資料は、BM25またはRRFの既存結果上位50件だけを再評価し、コーパス全体を再検索できないと明記しています[2]。同サービス固有の上限と処理ですが、候補集合の上限が再ランキングの上限になる点は、自作cross-encoderや別APIでも共通して検証すべきです。
| 観測値 | 考えられる原因 | 先に試す変更 | 再ランキングの扱い |
|---|---|---|---|
| Recall@20が高くRecall@50と同等 | 候補20で十分 | 遅延重視でK=20 | 少数候補で比較 |
| Kを増やすと大きく改善 | 第一段順位が浅い | 検索重み・融合を調整 | K=50/100を比較 |
| K=100でも低い | 分割・埋め込み・語彙索引 | 正解チャンクの存在を確認 | 第二段を保留 |
| 特定部署だけ低い | ACL投影・条件過多 | 許可集合とフィルターを確認 | 権限修正まで停止 |
入口の合格値は用途で変えます。契約条項や安全手順の検索ならRecall@50 0.98以上、一般FAQなら0.93以上など、誤りの影響へ合わせます。関連チャンクが複数ある質問では、全てを取る必要があるか、一つで足りるかをラベルへ記載します。「一つでも取れば成功」のHit@Kだけでは、複数根拠を必要とする質問の欠落を見逃します。
200問へ0〜3の関連度を付ける
再ランキングは順序を評価するため、二値の正解・不正解だけでは差が見えにくくなります。関連度3を「質問へ直接答え、条件と例外を含む」、2を「答えの重要部分を含む」、1を「主題は近いが単独では答えられない」、0を「無関係または誤解を招く」と定義します。旧版、他製品、権限外は、意味が近くても0とし、別に違反フラグを持たせます。
200問の内訳例は、単一根拠80問、複数根拠40問、型番と状況の混合30問、長い候補で切り捨てを起こしやすい20問、版や日付条件15問、回答不能15問です。候補プールは、BM25、ベクトル、融合の上位100件を結合して重複を除きます。検索方式一つの候補だけを人手評価すると、その方式が見つけなかった難しい負例をラベル集合から落としてしまいます。
BEIRの原著は、多様な検索タスクを同じ枠組みで比較し、段階関連度を順位へ反映できるnDCG@10を主要指標にしています[5]。自社200問はBEIRの代替ではなく、本番の日本語、文書形式、権限、回答目的を測る専用集合です。外部ベンチマークで上位のモデルでも、自社で再判定します。
{ "query_id": "RQ-0098", "query": "2026年度の海外出張で宿泊費が上限を超える場合の承認者", "candidate": "travel-r8#article12-2", "grade": 3, "reason": "現行版の例外条件と承認者を同じ節に含む", "must_cite": ["travel-r8#article12-2"], "forbidden": false, "reviewers": ["finance-02", "hr-policy-01"]}
二人の評価者が独立にラベルを付け、0対3の不一致は必ず解消します。判断が割れる候補は、質問が曖昧、原本が矛盾、チャンクが条件を欠く、のどれかを記録します。モデルの順位だけを直すより、質問UIへ確認項目を追加した方がよい場合もあります。200問のうち40問を調整、160問を最終判定へ固定し、モデル選択後にラベルを変えません。
候補数20・50・100と遅延を比較する
候補を増やすと入口Recallは上がりやすい一方、第二段の推論時間、API費用、タイムアウト、長文切り捨てが増えます。20、50、100件を同じ160問へ通し、候補Recall、再ランキング後nDCG@10、追加p95、1要求当たりの処理文字数またはtokensを並べます。候補100が50よりRecallを0.5ポイントしか改善せず、遅延が1.8倍なら、50を選ぶ根拠になります。
CohereのRerank API v2は、質問と文書列を受けて順位と関連度スコアを返します。参照時点では1要求1,000文書超を推奨せず、`max_tokens_per_doc`の既定を4,096と説明しています[3]。
同社のBest Practicesは現行v4.0系の長いコンテキストと文書分割、最大10,000文書のAPI制約を説明しています[4]。モデル版ごとに制限が違うため、v3.5の数値をv4.0へ混ぜず、採用するAPI版とモデルIDを記録します。
| 観点 | K=20 | K=50 | K=100 | 選択ルール |
|---|---|---|---|---|
| 入口Recall | 低くなりやすい | 基準候補 | 上限確認 | 必要値を満たす最小K |
| 上位品質 | 候補不足の影響 | 改善余地との均衡 | ノイズ増加も確認 | nDCGが頭打ちになる点 |
| 遅延 | 最小 | 中間 | 最大 | p95とp99のSLA内 |
| 切り捨て | 文書長に依存 | 同左 | 総処理量が増える | 重要節の欠落0 |
長い候補を自動で切るサービスでは、タイトル、見出し、本文、版、機密区分をどの順に渡すかが結果を変えます。末尾に答えがある20問を用意し、切り捨て前後の入力を保存します。文書全体を再ランキングへ渡す必要がない場合は、検索チャンクだけを渡し、親文書は最終取得後に展開します。入力が長いほど正確とは限らず、関連の薄い前文が判定をぼかす場合があります。
ピーク時に必要な同時実行枠は、`ピークQPS×平均推論秒`を基礎値にします。想定例で30 QPS、平均0.32秒なら`30×0.32=9.6`なので最低10枠、30%の余力を加えると`ceil(9.6×1.3)=13枠`です。契約上の上限が10枠なら、待ち行列を許容してもp95が悪化するため、再ランキング対象を絞るか上限を増やします。
この概算は平均値を使う容量式であり、文書長の偏りや429後の再試行を表しません。負荷試験では候補20・50・100を実際の長さ分布で混ぜ、キュー待ちを含むp95を測ります。
モデル入力と引用IDの契約を固定する
再ランキングへ渡す文字列は、本文だけ、見出し+本文、構造化YAMLなどの候補があります。初期案では、`title`、`heading_path`、`revision`、`content`を明示的なキーで連結し、内部のACL値や個人識別子は必要がなければモデルへ渡しません。表データは列名を失わない形式にし、モデルが長文を切る場合に重要な本文が末尾へ追いやられない順序を選びます。
Cohereの公式Best Practicesは、Rerank v3.5・v3.0では長い文書を4,093トークン単位へ分け、各部分の最大スコアを文書スコアにする処理を説明しています[4]。この挙動は同社の対象モデルに固有ですが、どの再ランキング基盤でも、入力の分割・切り捨てと引用IDの対応を試験記録へ残す必要があります。入力上限だけを確認し、答えを含む範囲が実際に採点されたかを見ない運用は避けます。
rerank_input: candidate_id: "manual-410:r12:section-7-3" model_text: | title: MX-410 保守マニュアル heading: 第7章 > 7.3 過熱時の緊急停止 revision: 2026-05-14 content: | 温度警告E27が継続した場合は... citation: document_id: "manual-410" revision: "r12" source_block: "page44-block08"
モデルが返す配列位置だけを信頼せず、送信前に付けた`candidate_id`と結果の`index`を対応させます。順位を並べ替えても引用キーは変えません。最終コンテキストへ渡す際は、同じ原本範囲の重複を統合し、生成文の引用が再ランキング後の候補IDへ解決できるかを確認します。順位改善と引用可能性は別の検査です。
権限外候補は再ランキングAPIへ送る前に除外します。外部サービスへ送信した後で結果だけ捨てても、認可境界を守ったことにはなりません。許可済み候補の中だけで順位付けし、テナントID、ポリシー版、候補ID一覧を監査ログへ残します。候補本文を第三者APIへ送れない契約・機密区分では、社内配置モデルか再ランキングなしを選び、セキュリティ担当へ判断を引き継ぎます。
nDCG・MRR・勝敗率を使い分ける
nDCG@10は段階ラベルの高い候補が上位へ来るほど高くなり、理想順位で正規化するため質問間を平均できます。DCGの一例は`Σ(2^grade-1)/log2(rank+1)`で、これを同じ候補集合の理想DCGで割ります。たとえば上位3件の関連度が`[2,3,0]`なら、`DCG=3+7/log2(3)=7.416`です。理想順`[3,2,0]`は`IDCG=7+3/log2(3)=8.893`なので、`nDCG=7.416÷8.893=0.834`となります。
MRR@10は最初の関連度3の順位の逆数を平均し、最初の正答を早く出したいFAQに向きます。複数根拠の順序を評価するならnDCGを優先します。
| 指標 | 測る対象 | 計算の要点 | 単独では見えないこと |
|---|---|---|---|
| Recall@K | 第一段の候補網羅 | 正解の候補内割合 | 候補内の順番 |
| nDCG@10 | 段階関連度と順位 | 理想DCGで正規化 | 遅延、権限違反 |
| MRR@10 | 最初の強い正解順位 | 1/rankを平均 | 二つ目以降の根拠 |
| Win/Loss/Tie | 質問ごとの変化 | 基準順位との差を数える | 改善幅の大小 |
| p95追加遅延 | 利用者待ち時間 | 第二段前後の差 | 検索品質 |
| 引用被覆率 | 必要根拠の採用 | must_citeの最終採用割合 | 生成文の正しさ |
再ランキング利得は、同じ候補集合で`nDCG@10_after – nDCG@10_before`とします。候補数まで同時に変えると、第一段の改善と並べ替えの改善が混ざります。まずKを固定して利得を測り、その後にKを変えます。質問別勝敗は、正解順位が2つ以上上がればWin、2つ以上下がればLoss、それ以外Tieなど、事前規則を置きます。
平均差だけで採用を断定せず、160問を質問単位で対応付けたまま再標本化し、利得の95%信頼区間を出します。想定例として10,000回のpaired bootstrapで平均差0.012、区間が`-0.004〜0.026`なら0を含むため、改善確認とは扱いません。
平均差0.028、区間が`0.015〜0.041`で、遅延と重要質問のLoss条件も合格した場合に採用根拠へ加えます。信頼区間はラベルの偏りや希少な重大事故を消せないため、安全・契約質問のLoss 0件という個別ゲートは残します。
スコア閾値はモデル間で持ち越しません。Cohereの公式資料も、関連度スコアは質問依存で、ある値が別の値の二倍関連するとは解釈できないと注意し、代表的な30〜50組で境界例を評価する方法を案内しています[4]。閾値を使うなら、回答不能15問と境界候補を含む調整40問で決め、モデル更新時に再推定します。
架空試算から採否を判定する
以下は、160問の最終集合をハイブリッド検索とcross-encoderへ通した架空試算です。実在サービスの性能値ではありません。第一段の候補数だけを20、50、100へ変え、再ランキングモデル、入力形式、負荷条件を固定して3回測った中央値と仮定します。
| 構成 | 入口Recall | 再配置前nDCG@10 | 再配置後nDCG@10 | MRR@10 | 追加p95 |
|---|---|---|---|---|---|
| K=20 | 0.931 | 0.718 | 0.806 | 0.842 | 190ms |
| K=50 | 0.981 | 0.721 | 0.847 | 0.881 | 390ms |
| K=100 | 0.988 | 0.723 | 0.851 | 0.884 | 760ms |
入口Recall 0.98以上、再配置後nDCG 0.83以上、追加p95 500ミリ秒以内を合格線にした場合、K=50が採用候補です。K=100はRecallが0.7ポイント、nDCGが0.4ポイント上がりますが、追加p95が370ミリ秒増え、SLAを超えます。高リスク質問だけK=100へ分岐する案は、質問分類の誤りと運用複雑性も加えて再評価します。
改善の内訳も読みます。160問中Win 72、Loss 14、Tie 74なら、14件を型別に確認します。型番、否定表現、短い表、旧版で損失が集中する場合は、入力形式または学習ドメインが原因かもしれません。重要度が高い安全質問で1件でも関連度0を1位へ上げたなら、平均点が合格しても公開せず、ルールによる型番固定やモデル変更を検討します。
費用の計算例
月300万検索の20%だけ再ランキングし、1要求当たり50候補を送るなら、月60万要求、候補判定3,000万件です。APIが要求単位課金かtoken課金かで式は変わるため、`600,000×要求単価`または`総入力tokens÷課金単位×単価`を使います。この値は試算式であり、最新料金、キャッシュ、失敗時再試行、テスト環境を含めて契約直前に更新します。
品質低下を四段階へ戻して調べる
再ランキング後の誤りを、第一段、入力変換、モデル推論、後処理の四段階へ戻します。正解が候補外なら第一段です。候補内にあるが送信文字列から答え部分が切れていれば入力変換です。全文が送られ、関連度3より0を上位にしたならモデルまたはドメイン適合です。API結果は正しいのに最終コンテキストが違えば、ID対応や重複排除の後処理です。
| 症状 | 確認する値 | 原因候補 | 修正後の対象テスト |
|---|---|---|---|
| 正解がK外 | 第一段順位、経路別順位 | 検索・融合・フィルター | Recall@20/50/100 |
| 末尾の答えを見落とす | 送信後の文字列 | token上限、キー順 | 長文20問 |
| 型番を似た製品へ置換 | 質問と候補のtoken | モデルの語彙特性 | 混合30問 |
| 引用IDが別候補になる | indexとcandidate_id | 配列並べ替えの対応不良 | 引用被覆率 |
| 同じ原本が上位を占める | source spanの重なり | チャンク重複 | 重複排除前後のnDCG |
Elasticの公式「Ranking and reranking」は、初段で安価な検索から広い候補を作り、後段で高価なモデルを小さな集合へ適用する多段構成を説明しています[6]。この分離をログにも反映し、`retrieval_run_id`と`rerank_run_id`を別にします。両段の設定を一つの「検索version」へ潰すと、どこが変わったか追えません。
モデルの関連度スコアだけを見て失敗を判断しないことも重要です。順位、入力、ラベル、候補Recallを合わせて見ます。質問不能なのに全候補へ高いスコアが付く場合は、最大スコア閾値だけでなく、上位と次点の差、根拠の版、回答不能分類を組み合わせます。それでも安定しない場合は、人の確認へ渡すか回答を控えます。
モデル変更と再索引を分けて運用する
再ランキングモデルだけを交換し、入力となるチャンク本文と候補生成が同じなら、通常はベクトルの再索引は不要です。200問を新旧モデルへ通し、nDCG、MRR、Win/Loss、p95、費用、スコア分布を再評価します。一方、埋め込みモデル、チャンク規則、本文抽出、語彙アナライザーを変えると第一段の候補集合が変わるため、索引更新と入口Recallの再計測が必要です。
| 変更 | ベクトル再索引 | 再ランキング評価 | 本番切替条件 |
|---|---|---|---|
| reranker model | 不要 | 200問全て | Loss上限、遅延、費用合格 |
| 候補数K | 不要 | 20/50/100比較 | 入口Recallとp95の均衡 |
| embedding model | 別索引を全量構築 | 候補集合を含め再評価 | 第一段と第二段が合格 |
| chunking rule | 対象文書を再生成 | candidate_id対応を更新 | 引用解決と順位回帰なし |
| 入力キー順 | 不要 | 長文・構造化質問 | 切り捨て0、nDCG改善 |
本番では、候補Recallを直接ラベルなしで毎日測れないため、固定カナリア20問を定時実行します。空結果率、再ランキングAPI失敗率、追加p95、入力切り捨て率、縮退率、引用解決失敗を監視します。週次で本番失敗から10件を人手ラベル付けし、月次で200問を再実行します。スコア分布が変わっても順位品質が維持される場合があるため、分布変化だけで即停止せず、カナリアと合わせます。
再評価を起動する条件は、モデルIDまたはAPI版の変更、検索基盤の設定変更、質問構成比が15ポイント変化、Loss率が2週続けて10%超、p95がSLAを3日連続で超過、料金改定で月額予測が20%増加、です。変更通知を受けたら旧モデルを即時削除せず、少なくとも一回の並行比較と戻し試験を行います。
向かないケースと停止条件を明示する
第一段検索の上位5件がすでに安定し、nDCG@10が目標を超える業務には、再ランキングの追加価値が小さい可能性があります。毎秒の検索量が大きく50候補への推論費用を許容できない、応答SLAが200ミリ秒、候補本文を外部APIへ送れない、正解ラベルを用意できない場合にも、そのまま導入しません。ルールで一意に決まる型番検索では、完全一致や業務優先度の固定boostが説明しやすいことがあります。
停止・切り戻しの数値条件
権限外候補を再ランキング先へ一件でも送信した場合は即時停止します。モデル更新後のnDCG@10が旧版より0.03以上低下した場合や、重要質問のLossが1件発生した場合は旧構成へ戻します。候補K=50で入口Recallが0.95未満、追加p95が800ミリ秒超、API失敗率が15分窓で5%超の場合も同様です。低リスクFAQだけを第一段順位で返す縮退と、契約・安全分野で回答自体を止める縮退を分けます。
再ランキングが高スコアを返しても、原本に答えがない質問では生成へ進めない場合があります。回答不能15問で誤受理が10%を超えるなら、閾値、質問分類、回答抑止を調整します。改善できなければ、人が原本を検索する導線へ切り替えます。医療、法務、労務、安全手順など専門判断が必要な領域では、順位上位を自動で最終判断とせず、担当部署の確認条件を別に設定します。
小規模評価を開始する
次に取る行動は、既存検索の失敗ログから50問を選ぶことです。内訳は単一根拠20問、複数根拠10問、型番混合10問、長文5問、回答不能5問とし、各候補へ0〜3のラベルを付けます。まず第一段のRecall@20とRecall@50を算出してください。Recall@50が入口目標を満たしたら、その50問で再配置前後のnDCG@10、Loss件数、追加p95を比較します。品質改善と遅延予算の両方が見えた段階で200問へ拡張します。
参考文献・出典
- Rodrigo Nogueira, Kyunghyun Cho「Passage Re-ranking with BERT」[原著論文] 検索候補をBERTで再ランキングする二段階検索、arXiv:1901.04085、初稿2019年1月13日（参照日: 2026年7月30日）
- Microsoft「Semantic Ranking Overview」[公式ドキュメント] RAG再ランキングの対象が既存上位50件に限られることと入力制約、2026年4月24日更新（参照日: 2026年7月30日）
- Cohere「Rerank API (v2)」[公式APIリファレンス] v2、更新日表記なし（参照日: 2026年7月30日）
- Cohere「Best Practices for using Rerank」[公式ドキュメント] 再ランキングの候補数、長文分割、関連度スコアの解釈、Rerank v4.0・v3.5・v3.0対応、更新日表記なし（参照日: 2026年7月30日）
- Nandan Thakur et al.「BEIR: A Heterogeneous Benchmark for Zero-shot Evaluation of Information Retrieval Models」[原著論文] 再ランキングを含む検索方式を18データセットで比較する評価基盤、arXiv:2104.08663、初稿2021年4月17日、NeurIPS Datasets and Benchmarks 2021（参照日: 2026年7月30日）
- Elastic「Ranking and reranking」[公式ドキュメント] 版表記なし（参照日: 2026年7月30日）
