RAG 07：リランキング ― 拾った候補を並べ直す

2段構え：速く広く拾ってから、丁寧に並べ直す

リランキングの考え方は、2段構えです。

採用試験でたとえると分かりやすいでしょう。応募者が1000人いたら、全員を面接する会社はありません。まず書類選考で50人に絞り、その50人だけを面接して5人を選びます。書類選考は速いけれど大ざっぱ、面接は時間がかかるけれど正確です。

検索も同じです。第4〜6章の検索は、100万件の中から速く候補を拾うのが得意です。でも、「この資料は本当にこの質問に答えているか」を細かく判断するのは苦手です。逆に、次のページから見る並べ直しモデルは、細かい判断が得意ですが、100万件全部に使うには遅すぎます。

だから、得意なところを組み合わせます。速い方法で広く拾い、遅いけれど正確な方法で、拾った候補だけを並べ直すのです。

この「2段構え」は、Web 検索エンジンなどでも昔から使われている定番の設計です。

第1段の読み方：質問と資料を別々に数字にする

2つの段は、何が違うのでしょうか。「読み方」が違います。

第1段の意味の検索（第4章）では、質問と資料を別々に埋め込みモデルに通して、それぞれ数字の並び（ベクトル）にしてから、近さを比べていました。この作りをバイエンコーダーと呼びます。エンコーダー（符号化器）は「文章を数字に変える部品」のことで、バイは「2つ」。質問用と資料用に、別々に通すという意味です。

2つ目が弱点です。埋め込みモデルが資料を数字にするとき、その資料がどんな質問に使われるかを知りません。資料の中身を、あらゆる質問に備えて、1つの数字の並びに押し込んでいます。

たとえるなら、書類選考の担当者が、募集の条件を知らないまま履歴書に点数を付けているようなものです。「だいたい優秀そう」は分かっても、「この仕事に合っているか」は判断できません。

その結果、「E-4012」と「E-4013」の違いや、「できる」と「できない」の違い（第4章）のような、質問にとって大事な細かい違いを取りこぼします。

第2段の読み方：質問と資料を並べて、一緒に読む

第2段の並べ直しモデルは、読み方が違います。質問と資料を1つに並べて、一緒にモデルに入れます。そして、「この資料は、この質問にどれくらい答えているか」を、0〜1 のような1つの点数で返します。この作りをクロスエンコーダーと呼びます。クロスは「交差させる」、つまり質問と資料を混ぜ合わせて1回で読む、という意味です。

一緒に読むので、モデルは質問の言葉と資料の言葉を突き合わせながら読めます。質問の「E-4012」と、資料の「E-4012」「E-4013」を直接見比べられます。質問が「直し方」を聞いていることと、資料に手順が書いてあるかも照らし合わせられます。

面接のたとえで言えば、募集の条件を手元に置いて、1人ずつ話を聞くようなものです。

クロスエンコーダーで検索を並べ直す方法は、2019年に BERT という言語モデル（文章を読んで理解するのが得意な、LLM より小さなモデル）を使った研究で大きな効果が示され、広まりました。ちなみに、両者の中間を狙った作り（ColBERT など。資料は前もって単語ごとの数字にしておき、質問が来てから単語どうしを突き合わせる方式）もあります。

並べ直す前：ハイブリッド検索の順

では、実際に並べ直してみます。まず、並べ直す前の状態です。図は、第6章のハイブリッド検索（RRF）で拾った上位6件です。

どの候補も、「エラー」や「障害」の話という意味では、確かに似ています。第1段の検索は、その「似ている」を正しく拾っています。

でも、質問は「E-4012 の直し方」です。答えているのは4位の資料だけで、1位の一覧表には番号と名前しか載っておらず、2位は別のエラーの話です。

「似ている」と「答えている」の差。これを埋めるのが並べ直しです。次のページで、この6件を並べ直しモデルに掛けます。

並べ直した後：答えている資料が1位に

6件の候補を、1件ずつ質問と組にして並べ直しモデルに渡し、点数をもらって並べ替えました（点数は説明のための例です）。

正解の「E-4012 の対処手順」が1位に上がりました。番号違いの「E-4013 の対処」は、4位に下がっています。質問と資料を一緒に読んだので、「番号が違う」ことに気づけたのです。

リリースノートが3位に上がったのも注目です。「E-4012 は v2.3 で修正済み」という一文があれば、直し方の答えとして役に立つ場合があります。第1段の検索では「リリースノート」という話題の遠さで下にいましたが、中身を読むと関係がありました。

このように、並べ直しは「話題が似ているか」ではなく「質問に答えているか」で順番を付け直します。

上位だけを残して、LLM に渡す

並べ直したら、上位の数件だけを LLM に渡します。図の赤い線より上の3件です。

これで、この章の最初のページで見た問題が解けました。正解は拾えていたのに4位で落ちていた、という問題です。並べ直した後なら、上位3件に正解が入ります。

多くの RAG で使われている定番の形は、次のようなものです。

もう1つ、並べ直しモデルの点数には使い道があります。点数が低すぎる候補は、枠が余っていても捨てることです。たとえば上位5件を渡す設定でも、4位以下の点数がとても低ければ、3件だけを渡します。関係ない資料を LLM に読ませると、それに引きずられた答えが出やすくなるからです（第8章）。

全部の候補の点数が低いときは、「資料の中に答えが無い」という合図として使えます。無理に答えさせず、「資料には見つかりませんでした」と返すほうが誠実です（第8章）。

ただし、どこで切るかの値（しきい値）は、モデルごとに違います。自分の資料と質問で実際の点数を見て決めます。

並べ直しの道具は3種類

並べ直しに使う道具は、大きく3種類あります。

この本では、特定のモデルや製品を勧めません。名前と順位はすぐに入れ替わるからです。選ぶときは、次の点を確かめます。

日本語への対応：英語中心で訓練されたモデルは、日本語で大きく精度が落ちることがあります。一度に読める長さ：並べ直しモデルにも入力の上限があり、長いチャンクは後ろが切られます。速さと料金：候補の数だけ計算するので、1回の質問あたりの時間とお金に直結します。

そして最後の決め手は、埋め込みモデルのとき（第4章）と同じです。自分の資料と実際の質問で、「正解が上位に来るか」を測ることです（第12章）。並べ直しを入れる前と後で比べれば、効果がはっきり分かります。

LLM に並べさせる：1件ずつ採点するか、まとめて並べるか

汎用の LLM も、並べ直し役になれます。質問と候補を渡して、「質問に答えている順に並べて」と頼むのです。やり方は大きく2通りあります。

まとめて並べる方法は、2023年の研究（RankGPT）で、うまく指示すれば専用のモデルに並ぶ、あるいは上回る結果が出せることが示され、広く知られました。

LLM の強みは、賢さと柔軟さです。「新しい版を優先して」「手順が書いてあるものを優先して」のような条件も、プロンプトに書くだけで反映できます。

弱みは、遅く、高いことです。候補が50件あれば、LLM に50件分の文章を読ませることになります。さらに、候補の並び順によって結果が揺れる（最初や最後に置いたものが有利になる）ことも知られています。

実務では、「専用の並べ直しモデルで50件を10件に絞り、必要なら LLM で最後の並べ替えをする」のように、段を重ねる使い方もあります。

何件拾って、何件残すか：時間とお金の取り引き

リランキングは、答えの質を大きく上げる代わりに、時間とお金を使います。並べ直しは候補の数だけ計算するので、拾う数に比例して遅く、高くなります。

図は、1回の質問にかかる時間のイメージです（実際の長さは、モデルや環境で大きく変わります）。検索そのものは速く、並べ直しがそれに上乗せされ、いちばん長いのはたいてい LLM の回答です。

特に大事なのは、「並べ直しは、拾った候補の中でしか順番を変えられない」ことです。100位にある正解を、拾う数を50件にしていたら、どんなに賢い並べ直しモデルでも救えません。拾う数は、第1段の検索の質（第4〜6章）と、並べ直しにかけられる時間の両方から決めます。

決め方は、他の章と同じく測ることです。拾う数を 20、50、100 と変えながら、「正解が最終的に上位に残ったか」と「応答にかかった時間」を並べて見れば、ちょうどいいところが見つかります（第12章）。

コードで見る：拾って、並べ直して、残す

ここまでを、TypeScript の短いコードにすると図のようになります。hybridSearch() は第6章のハイブリッド検索、rerank() は並べ直しのモデルや API を呼び、候補ごとの点数を返す関数だとします。

並べ直しは、仕組みとしては「質問と資料の組」を渡して点数をもらうだけです。前後はいつもの検索とプログラムなので、既存の RAG に後から足しやすいのが良いところです。

注意点を2つ。1つ目は、MIN_SCORE の値です。点数の分布はモデルごとに違うので、別のモデルの値を使い回さないこと。2つ目は、並べ直しの呼び出しが失敗したときの扱いです。API が落ちたら、並べ直しを飛ばして第1段の順番のまま使う、といった逃げ道を用意しておくと、RAG 全体が止まらずに済みます。

似たものばかり並んだら：多様性も見る（MMR）

並べ直しにはもう1つ、よく起きる問題があります。上位が似たものばかりになることです。

たとえば、同じ手順書が版違いで何部も保存されていたり、同じ文章があちこちに写されていたりすると、図の左のように、上位5件がほとんど同じ中身になります。5件渡したつもりでも、LLM が得る情報は実質1件分です。原因や回避策といった、答えに役立つ別の情報が押し出されてしまいます。

これを防ぐ方法の1つが MMR（Maximal Marginal Relevance、最大周辺関連性）です。名前は「すでに選んだものに上乗せされる役立ち度（関連性）が最大のものを、次に選ぶ」という意味です。1998年の論文で提案された考え方で、候補を1件ずつ選ぶときに、次の2つを両方見ます。

「質問に近い、でも、すでに選んだものとは似ていない」候補を優先して選ぶので、図の右のように、手順書、原因、回避策、告知、連絡先と、違う角度の情報がそろいます。2つのどちらをどれだけ重く見るかは、つまみ（λ、ラムダと読むギリシャ文字）で決めます。1 に近づけるほど「質問との近さ」だけを見て、0 に近づけるほど「すでに選んだものとの違い」を重く見ます。

MMR は多くのライブラリやベクトルデータベースに用意されています。ただ、同じ文書の重複が多いなら、索引を作る段階で重複を取り除いておく（第3章）のが根本の対策です。

よくある落とし穴

リランキングで、実際によく起きる失敗をまとめます。

1つ目と2つ目は、特に気づきにくい失敗です。「並べ直しを入れたのに良くならない」ときは、並べ直しモデルを疑う前に、候補の中に正解が入っているか、正解の部分がモデルに届いているかを確かめてください。