リランキング（再ランク付け）とは、retrieval が取り出した文書候補を、より高精度なモデルで評価し直し、関連度の高い順に並べ替える工程です。retrieval が速さ重視で広めに集めた候補には玉石が混じります。リランキングはそれを一段精密に選別し、本命を上位へ、無関係なものを下位へと組み替えます。生成AIは上位の少数を重視して答えを書くため、この並び順の精度が、そのまま回答の正しさと引用の質を左右します。
リランキングは、retrieval が出力した候補リスト（例：上位数十件）を入力として受け取り、各候補と質問の関連度を測り直し、その新しいスコアで並べ替える処理です。ポイントは「候補を新たに探すのではなく、すでにある候補の順番を精密化する」点にあります。retrieval が「集める」工程なら、リランキングは「選び直す」工程です。多くの場合、並べ替えたうえで上位の少数（例：数件）だけを残し、それを後段の生成AIに渡します。
retrieval とリランキングで関連度の測り方が違うのが要点です。retrieval のベクトル検索は、質問と文書をそれぞれ独立に埋め込み（＝意味の数値ベクトル）に変換し、その距離で近さを測ります。大量候補を高速にさばけますが、質問と文書を別々に見るため、細かなかみ合いを取りこぼすことがあります。一方リランキングでよく使われるクロスエンコーダ（＝質問と文書を一組にしてモデルに同時入力し、両者の関係を直接見て関連度を出す方式）は、質問と文書を突き合わせて評価するため精度が高い代わりに計算が重く、大量には掛けられません。
この「精度は高いが重い」という性質ゆえに、リランキングは全文書ではなく、retrieval が絞り込んだ候補だけに適用されます。全件にクロスエンコーダを掛けるのは非現実的だからこそ、まず retrieval が速い方式で候補を数十件に絞り、その少数にだけ重い精密評価を掛ける、という二段構えが合理的な設計になります。retrieval が広く浅く、リランキングが狭く深く、という分担がここに現れます。
AI検索対策でリランキングが重要なのは、この工程が「retrieval で拾われた自社文書が、実際に答えの根拠として使われるか」の最終関門になるからです。retrieval の網に掛かっても、それだけでは引用されません。生成AIは上位の少数を重視し、下位の候補は読み込まれすらしないことが多いため、リランキングで上位に押し上げられて初めて、答えに反映される現実的なチャンスが生まれます。「拾われる」と「使われる」の間にある壁が、このリランキングです。
クロスエンコーダによるリランキングは、質問と文書を突き合わせて評価するため、「質問に正面から答えているか」を retrieval より厳しく見ます。したがって、キーワードは近いが実は論点がずれている文書は、リランキングで下げられやすくなります。逆に、質問の意図に的確に答え、結論が明確な文書は上位に来やすいです。これは、AIO実務で言われる「質問に直接答える」「結論を先に置く」といった書き方が、なぜ引用の確度を上げるのかを説明します。リランキングの評価軸が、そうした書き方を評価する方向に働くからです。
また、リランキングは引用の「質」にも効きます。並び順が精密になれば、AIはより的確な文書を根拠に答えられ、結果として誤り（＝ハルシネーション。もっともらしい嘘）が減りやすくなります。AI検索が出典付きで答える設計では、上位に来た文書がそのまま引用元として表示されることも多く、リランキングでの順位が、自社が「出典として名前を出してもらえるか」に直結します。
リランキングが候補を並べ替えて生成に渡すまでの流れは、おおむね次の順序で進みます。
- retrieval が、質問に対して関連しそうな候補を広めに（例：上位数十件）取り出します。
- リランキング用のモデル（多くはクロスエンコーダ）に、質問と各候補を一組ずつ入力します。
- モデルが、質問と候補の関係を直接見て、関連度スコアを一件ずつ算出します。
- その新しいスコアで候補を並べ替え、上位の少数（例：数件）だけを残します。
- 残した少数を後段の生成AIに渡し、AIがそれを根拠に回答を書きます。
この二段構えは「二段階検索」とも呼ばれ、速さと精度を両立させるための定番設計です。retrieval が速さで候補を絞り、リランキングが精度で仕上げます。どちらか一方では、全件を精密評価する重さか、粗い並びのまま生成に渡す危うさか、どちらかの問題を抱えます。二段に分けることで、現実的なコストで高い精度を得ています。
retrieval とリランキングの役割分担| 観点 | retrieval（前段） | リランキング（後段） |
|---|
| 役割 | 大量から候補を集める | 候補を精密に並べ替える |
| 対象件数 | 数百万件から数十件へ絞る | 数十件を数件へ絞る |
| 重視するもの | 速さ・取りこぼしの少なさ | 精度・並び順の正しさ |
| 代表的な方式 | 埋め込み＋近似最近傍探索 | クロスエンコーダ |
| 質問と文書の見方 | 別々に埋め込んで距離を測る | 一組にして関係を直接評価する |
横にスクロールできます
リランキングの効き方は、retrieval だけでは本命が埋もれる場面で最もよく分かります。
- retrieval が「解約」に関する候補を30件集めたが、キーワードだけ近くて実は料金の話をしている文書が上位に混じっている場合、リランキングが「解約手続きに正面から答える文書」を上位へ押し上げます。
- 質問「返品はできますか」に対し、retrieval が返品・交換・キャンセルの文書を混在して取り出したとき、リランキングが返品に直接答える文書を1位に、周辺の交換・キャンセルを下位に整えます。
- 同じ話題でも、結論を冒頭に置き質問に直接答える文書は、途中まで前置きが長い文書よりリランキングで上位に来やすいです。
- 本命が retrieval で20位付近に埋もれていても、リランキングがスコアを付け直すことで数位以内に繰り上がり、生成に渡る候補に入れます。
これらが示すのは、リランキングが「近く見えるだけの文書」と「本当に答えている文書」を選り分ける工程だということです。AI検索に引用されたい立場からは、キーワードの近さで retrieval に滑り込むだけでなく、質問に正面から答える中身でリランキングを勝ち抜くことが求められます。
リランキングは精度を上げる一方で、計算コストと応答時間を増やします。クロスエンコーダは質問と文書を一組ずつ評価するため、候補が多いほど処理が重くなります。そのため実務では「retrieval で候補を何件まで絞ってからリランキングに渡すか」の調整が重要になります。候補を多く渡せば取りこぼしは減りますが遅く高くなり、少なく渡せば速く安いが、本命を retrieval 段階で落とすリスクが残ります。
この綱引きに唯一の正解はなく、用途ごとに落としどころを探します。回答の正確さが最優先の場面では候補を広めに取ってしっかりリランキングし、速さや低コストが優先の場面では候補を絞る、といった判断です。リランキングは「掛ければ掛けるほど良い」ものではなく、retrieval の絞り込みと合わせて全体最適を考える工程だと理解しておくのが正確です。
リランキングの精度の源泉は、質問と文書を「一緒に」見る点にあります。retrieval のベクトル検索は、質問と文書をそれぞれ独立に埋め込みへ変換してから距離を測るため、変換した時点で細かな文脈が失われ、両者の細かなかみ合いを取りこぼすことがあります。これに対しクロスエンコーダは、質問と文書を一組にしてモデルへ同時入力し、「この質問に対して、この文書は本当に答えているか」を最初から突き合わせて判断します。両者の関係を直接見るぶん、字面は近いが論点がずれた文書を見抜きやすく、質問に正面から答える文書を的確に高く評価できます。
この「同時に見る」評価方式が精度をもたらす一方で、計算の重さも生みます。候補ごとに質問との組を作ってモデルに通すため、件数に比例して負荷が増えるのです。だからこそ全文書には掛けられず、retrieval が絞った少数にだけ適用する、という設計上の制約が生まれます。精度の高さと適用範囲の狭さは、同じ性質の裏表であり、この理解が二段構え設計の必然性を腑に落とします。
もうひとつの注意点は、リランキングを万能視しないことです。リランキングはあくまで「retrieval が渡した候補の中で並べ替える」工程であり、retrieval が本命を最初から取りこぼしていれば、その文書を後から救うことはできません。リランキングは候補の外から新しい文書を連れてこないからです。したがって、まず retrieval で取りこぼさないこと、そのうえでリランキングで正しく並べること、という順序の依存関係を押さえる必要があります。後段だけを強化しても、前段の取りこぼしは埋められません。
- 自社コンテンツが、想定質問に「正面から答えている」かを点検します（キーワードが近いだけで論点がずれていないか）。
- 結論を各ブロックの冒頭に置き、質問への答えが最初の数行で分かる形にします（リランキングの評価軸に合わせます）。
- 1見出し1論点に整理し、1つのチャンクが1つの問いに集中して答えるようにします（混在は関連度を薄めます）。
- 前置きや背景説明で答えが後ろに追いやられていないか確認し、必要なら答えを前倒しします。
- 公開後は、どんな質問のときに引用されるかを観察し、拾われても使われない（=リランキングで下がる）質問があれば中身を見直します。
リランキングも各AI検索サービス側の内部工程で、運営者が直接調整できるものではありません。運営者にできるのは、「質問に正面から的確に答える中身」を用意し、リランキングに評価されやすい書き方に整えることです。retrieval で拾われる工夫と、リランキングで選ばれる工夫は重なる部分も多いものの、後者では特に「質問への直接的な回答性」が問われる、と押さえておくと対策の精度が上がります。
実務でもう一段踏み込むなら、1つのページに多くの問いへの答えを詰め込みすぎないことも有効です。リランキングは質問と各チャンクを突き合わせて評価するため、1つのチャンクが複数の問いに広く浅く触れていると、どの質問に対しても関連度が中途半端になりがちです。逆に、想定する問いごとに答えを明確なブロックへ分けておけば、その問いが来たときに該当ブロックが強く反応し、リランキングで上位に立ちやすくなります。「1つの問いに、正面から、完結して答えるブロック」を積み重ねる設計が、retrieval とリランキングの両工程を同時に味方につける近道です。
retrieval があるのに、なぜリランキングが必要なのですか。
retrieval は速さ重視で候補を広めに集めるため、並び順が粗く、本命が下位に埋もれがちです。生成AIは上位の少数しか実際には読まないので、並び順を精密化するリランキングがないと、良い候補が拾われていても答えに使われません。集めることと正しく並べることは別の工程です。
リランキングは候補にない文書も連れてきてくれますか。
いいえ。リランキングは retrieval が渡した候補の中で並べ替えるだけで、候補の外から新しい文書を追加することはありません。したがって retrieval が本命を最初から取りこぼしていると、リランキングでは救えません。まず取りこぼさないこと、次に正しく並べること、という順序の依存があります。
リランキングは掛ければ掛けるほど回答は良くなりますか。
一概には言えません。リランキングは精度を上げる反面、計算コストと応答時間を増やします。候補を多く渡せば取りこぼしは減りますが遅く高くなり、少なく渡せば速く安いが本命を落とすリスクが残ります。用途ごとに、retrieval の絞り込みと合わせて全体で最適点を探すのが実務です。
