Redditで興味深い投稿を見かけました。
RAG（Retrieval-Augmented Generation）の検索精度を上げようとした話です。
3ヶ月かけて埋め込みモデルを次々試したそうですが、結果はほぼ無駄足だったとのこと。
本当に効いたのは、別の場所にある一手だったのです。
本記事では、その投稿と寄せられたコメントから読み取れる、RAG改善の実践的な知見を整理します。
1. 60%という数字の落とし穴
投稿者のチームは、約12,000件の社内文書を対象にRAGを運用していました。
Top-1のヒット率は60%。
一見、悪くない数字に思えます。
しかし、外れた40%の中身に問題が潜んでいました。
多くが「似ているけれど違う文書を、自信たっぷりに返す」パターンだったそうです。
とくに、ポリシー関連の質問で目立ったといいます。
何も返してくれないなら人間が気づけます。
一方で、もっともらしい誤回答は厄介です。
LLMがその誤った文脈をもとに、流暢な文章を生成してしまうからです。
答えそのものが自然に読めてしまうため、気づくには正解を知っている必要があります。
2. 埋め込みモデル交換に費やした3ヶ月
最初の打ち手は、当然のように埋め込みモデルの変更でした。
text-embedding-3-large から jina-v3、さらにファインチューニング済みの bge モデルへ。
順番に切り替えていったそうです。
ところが、得られたのは1〜3ポイント程度の改善だけ。
これでは、評価セット上のノイズと見分けがつきません。
それでも「次のモデルなら効くはず」と信じて続けてしまった。
これが、投稿者の正直な振り返りでした。
同じレバーを引いても結果が変わらない。
それなのに、レバーを変える発想に至らない。
よくある罠だと思います。
3. 効いたのはクロスエンコーダーのリランカー
突破口になったのは、再ランク付け（リランキング）の段を追加することでした。
パイプラインはシンプルです。
まず、ベクトル類似度でTop-50の候補を取り出します。
次に、bge-reranker-large というクロスエンコーダーで並び替え。
最後にTop-5を返します。
たったこれだけ。
結果は、Top-1ヒット率が60%から81%へ。
一晩で20ポイント以上の改善です。
しかも、埋め込みもチャンク戦略も、上流は何ひとつ変えていません。
4. なぜ気づけたのか
投稿者がリランカーを試そうと思ったきっかけ。
これが、個人的には一番の学びでした。
マネージド型の検索サービスがどう設計されているか、観察したそうです。
BM25とベクトルのハイブリッド検索があり、リランカーがある。
これらは「オン・オフを切り替える機能」ではありませんでした。
デフォルトで組み込まれていたのです。
つまり、検索品質を本気で出している人たちにとって、リランカーは標準装備だった。
問題は「どの埋め込みモデルを選ぶか」ではなかったのです。
「アーキテクチャに何が欠けているか」のほうでした。
5. なぜ多くのチュートリアルにリランカーが登場しないのか
投稿者が違和感を覚えていたポイントが、ここでした。
LangChainやLlamaIndexの標準的なチュートリアル。
これらには、リランカー段がほとんど登場しません。
コメント欄に納得感のある説明がありました。
チュートリアルは「30行で動くRAG」を見せることに最適化されている。
プロダクションで運用するための設計とは、目的が違うわけです。
リランカーを入れると、サービス依存が増えます。
レイテンシーも伸びます。
インフラの複雑度も上がります。
記事としての見栄えが悪くなるので、削られてしまうのですね。
その削られたピースのコストは、後から実装するチームが払うことになります。
投稿者と同じように、何ヶ月も埋め込みモデル選定に費やしてしまうわけです。
6. コメント欄からの補足知見
このRedditスレッドは、コメントも学びの宝庫でした。
重要な指摘をいくつか紹介します。
候補集合の質がリランカーの効果を決める
リランカーに渡す候補が、ただのテキスト塊だけだと、判断材料が乏しくなります。
各候補に、以下のような情報を添えると性能が変わってくるとのこと。
- セクションタイトルや親見出し
- ソースURL、文書タイプ、バージョンや日付
- 隣接セクションの文脈
理想的な流れは、「候補取得 → 構造・メタデータによるフィルタリング → リランキング → 最終的な文脈組み立て」です。
リランカーは強力ですが、それ単体で全部を背負わせるのは得策ではありません。
埋め込みは再現率、リランカーは正確性
別のコメントが、二つの役割をきれいに整理していました。
埋め込みは「正解候補を取りこぼさない」ための仕組みです。
つまり、再現率の担当。
一方、リランカーは「複数の妥当候補から正解を選び出す」ための仕組みです。
こちらは、局所的な正確性の担当となります。
性質の違うものを混同していたから前進しなかったのですね。
片方で全部解決しようとしていたわけです。
クエリの「枠組み」がずれていると、リランカーでも救えない
リランカーを入れても、残る失敗モードがあります。
クエリ自体の前提がずれているケースです。
ユーザーの意図やワークフロー上の位置を取り違えていると、いくら正しくランクしても無意味です。
引いてくる文脈そのものが間違っているわけですから。
これは見た目こそ検索の問題ですが、実態は別物です。
上流の状態管理や文脈選択の問題なのです。
信頼度しきい値の併用
実運用しているエンジニアの一人が、リランカーに加えて「信頼度しきい値」を組み合わせていました。
仕組みはこうです。
検索結果が質問にどれだけ合致しているかをスコア化します。
しきい値を下回る場合は、答えずに人間へエスカレーションするのです。
リランカーはTop-1を正確にする仕組み。
しきい値は、そのTop-1すら誤っている場合の最終防御線。
役割が補完的で、よく考えられた設計だと感じました。
クエリの書き換え
ユーザーの自然な質問を、ドメイン固有の用語に合わせて事前に書き換える。
これだけで、検索精度が大きく伸びるケースもあるそうです。
エンドユーザーの言葉と、ドキュメントの言葉のギャップを埋める発想ですね。
7. このスレッドから読み取れる教訓
整理すると、いくつかの普遍的な学びが残ります。
メトリクスが伸び悩んだとき、同じレバーを引き続けるのは危険です。
改善幅がノイズと区別できない。
これは、違うレバーを探すべきというサインなのです。
検索品質の問題は、多くの場合「モデル選定」ではありません。
「アーキテクチャ」の問題です。
リランカー、ハイブリッド検索、クエリ書き換え、信頼度ゲート。
これらを組み合わせて初めて、本番運用に耐える検索が実現します。
そして最も警戒すべき失敗は「自信を持って間違える」ことだという認識。
これは投稿全体を貫く重要な視点でした。
まとめ
RAGの検索品質を上げたいなら、次の埋め込みモデルを試す前に、まずリランカーを入れてみてください。
試してみる価値は大いにあります。
Top-1ヒット率が60%から81%へ跳ね上がった事例。
これが、その効果を雄弁に物語っています。
新規にRAGを構築するなら、最初からリランカー段を組み込んだ前提で設計すると良いでしょう。
後から後悔せずに済みそうです。
標準チュートリアルがそこを省いていること。
この点を知ったうえで、自分の構成に追加するかを判断するのがおすすめです。
埋め込みモデルの細かい比較で消耗する前に、パイプライン全体を見渡してみる。
これが、検索品質改善における一番効率の良い一手かもしれません。
