RAGの精度は順位で決まる: rerankerという「読み直す」考え方¶

対象 / ポイント

対象: RAGを使っているが「なぜか答えがズレる」と悩んでいる人、rerankerという言葉を初めて聞く人。

ポイント:

RAGの精度問題は、生成モデルより検索順位が原因のことが多い
「広く拾う」と「読み直す」を分けるのが、精度改善の基本パターン
Ettin Rerankerは2026年5月公開の新しい選択肢で、既存RAGに追加しやすい

RAGの回答が外れたとき、最初に疑われるのは生成モデルになりやすい。「もっと賢いLLMに変えれば直るのでは」という発想だ。だが、実際の現場ではそうならないケースの方が多い。

この記事の問いは、RAGのズレを直すとき、生成モデルではなく検索順位をどう見るかである。

RAGがズレた答えを返すとき、本当に悪いのは誰か¶

生成モデルを強化しても、RAGの精度が上がらないことは珍しくない。

理由は単純で、LLMは渡された文書しか読まないからだ。手元に間違った資料を渡された人間が、正しい答えを出せないのと同じ構造になる。 LLMがどれだけ賢くても、検索段階で「質問に答えていない文書」が上位に来ていたら、回答は外れる。

つまりRAGの精度は、最後にLLMが何を生成するかだけでは決まらない。その手前で、どの文書をLLMに渡すかでほぼ決まる。

この視点に切り替わると、改善すべき場所が変わる。モデルを大きくする前に、検索結果の上位5件を見直すべきだ。

「広く拾う」と「読み直す」を分ける¶

検索を1段で済ませない理由は、採用プロセスを考えるとわかりやすい。

1000人の応募者から、まず書類で100人に絞る。その後、面接で5人に絞る。最初から全員に長い面接をしないのは、時間がかかりすぎるからだ。

RAGの検索も同じ構造を取る。文書が数万件あるとき、全部を丁寧に読み込んで順位付けするのは時間もコストも合わない。だから最初は「ざっくり似ているもの」を100件ほど拾い、その100件だけを丁寧に読み直して順位を決める。

この「広く拾う」担当がembedder、「読み直す」担当がrerankerだ。

役割	得意なこと	苦手なこと
embedder	大量の文書から速く候補を拾う	細かい意味の違いを見落とす
reranker	候補を読み直して順位を直す	全文書にかけると重い

賃貸物件探しにも近い。条件検索で100件を出し、最終的に内見で5件まで絞る。条件だけでは判断できないことを、後から見直す発想だ。

なぜembedderだけだと足りないのか¶

embedderは、クエリと文書をそれぞれ独立にベクトル化する。そして距離が近いものを「似ている」と判断する。

この方式は速い。ただし、判断が「距離」という1つの数字に圧縮される。

問題は、意味の方向が逆でも距離は近くなることだ。「Macが起動しない」と「Macの起動方法」は、単語の構成も話題もかなり近い。だが質問者が欲しいのは障害切り分けで、起動方法のマニュアルではない。

否定表現、前提条件、対象バージョン、文書の粒度。こうした要素が絡むほど、embedderの粗さが順位に出る。検索結果の上位10件を見て「似てるけど答えてない」が多ければ、embedderの判断限界に当たっているサインだ。

rerankerはこの判断を、クエリと文書を同時に読み込んで再評価する。 embedderが2つの文を別々に見て後で距離を測るのに対し、rerankerは2つを並べて読みながら「これは答えているか」を判定する。

情報量が多いぶん、見抜ける差も多い。その代わり、処理は重くなる。

どこから直せばいいか、という考え方¶

RAGの精度がイマイチなとき、最初に見るべきは生成結果ではなく検索結果だ。

具体的には、次の順番で切り分ける。

上位N件の中に、正解の文書は入っているか
入っていないなら、embedderや検索範囲の問題
入っているが下の方なら、順位の問題
入っていて上位にあるなら、プロンプトや生成側の問題

この切り分けをしないまま「LLMを強くする」「embeddingを変える」と動くと、効かない改善に時間を使ってしまう。 RAGの問題は、検索・順位・生成の3層に分かれている。層が違えば、打ち手も違う。

rerankerが効くのは、正解は拾えているのに順位が低い状況だ。 embedderを差し替えても順位の粗さは残るが、rerankerを足すと後段で補正できる。

最初から完璧なembedderを選ぶ必要はない。「拾う段階は緩めに、絞る段階で精度を上げる」と分けて考える方が、運用も検証もシンプルになる。

具体的な選択肢としてのEttin Reranker¶

rerankerは以前から存在していたが、2026年5月19日にHugging FaceからEttin Rerankerファミリーが公開され、選択肢が広がった¹。 17Mから1Bまでの6サイズが揃い、すべてApache 2.0で配布されている。

注目点は3つに集約できる。

着目点	公式記事での位置づけ	想定される用途
17M	既存のMiniLM系rerankerより小さく、かつ精度が高い	CPU推論、レイテンシ重視
150M	600M未満のレンジで強い中位モデル	GPUありの通常運用
1B	1.54Bの教師モデルにほぼ並ぶ品質	品質優先、夜間バッチ

特に小さいサイズが強いことには、実務上の意味がある。「rerankerを試したいが推論コストが心配」という導入時の壁を、17Mや32Mが下げてくれる。

既存のRAGに追加し、効果が出てから大きいサイズへ上げる。この段階的な検証がしやすい構成になっている。

また、学習データそのものも公開されているため、自社ドメインに合わせて再学習する道もある²。「公開モデルをそのまま使う」と「自社で鍛え直す」の二択ではなく、間を埋める選択肢が用意されている。

日本語RAGで気をつけること¶

公開ベンチマークの強さを、そのまま日本語RAGの強さとは見なさない方がよい。

Ettin Rerankerの評価は、英語ベンチマークであるMTEBを中心に示されている¹。日本語の社内文書、FAQ、議事録、契約書で使うなら、英語での強さがそのまま転用される保証はない。

実務では、まず手元のクエリと文書のセットを30から100ペアほど用意する。人間が「正解の順位」を付けたうえで、rerankerあり・なしで上位N件の正答率を比較する。完璧な評価セットでなくても、傾向は十分つかめる。

英語と日本語で挙動が違ったり、特定の文書タイプで効きが弱かったりすることは珍しくない。公開ベンチマークは期待値を見るための参考だ。自社環境での効果は、あくまで自社データで測る。

まとめ¶

RAGの精度を上げたいとき、生成モデルを変えるより、検索順位を整える方が効くことが多い。検索を「広く拾う」と「読み直す」に分け、後段にrerankerを置くのが基本パターンになる。

Ettin Rerankerは、この2段目を小さく始められる新しい選択肢として位置づけられる。 Apache 2.0、6サイズ、データセット公開、Sentence Transformers互換という条件が揃っているため、既存のRAGに追加して比較しやすい。

次の一歩は、現在のRAGが上位5件のうち何件、本当に質問に答えているかを測ることだ。この数字が見えると、改善すべき場所が検索なのか、順位なのか、生成なのかが分かれる。打ち手の優先順位もはっきりする。