第5章 — 検索パイプラインの設計
LLM Primer III: RAGで強化するエンタープライズAI を章ごとに紹介していくウォークスルー、第5回です。単発のベクトル検索は、プロトタイプが止まる場所であり、本番の失敗が始まる場所でもあります。今回は、半分しか形になっていないクエリから、生成器に届く最終候補までの道のりを歩きます — そして、各段階がなぜ要るのかを順に見ていきます。
この章がなぜあるのか
第2章から第4章で、ベクトルストアができあがりました — パースされ、丁寧にチャンクされ、埋め込まれ、インデックスされた文書。素朴な次の一手は、ユーザーのクエリを埋め込み、最近傍を引き、上位kを生成器に渡すことです。些細なコーパスなら動きます。本番ではほぼ動きません。クエリは指定不足のまま、見たことのない固有名詞混じりで到着します。コーパスにはニア重複が多く、どの単一ランキングの上位もそれで埋まります。識別子やコードは、埋め込みが均す意味を保ったままです。
第5章は、成熟したシステムが収斂する形について書きます。研究のための形ではありません。再現率、精度、レイテンシのすべてを同時に保たなければならないとき、チームが実際に動かしている形です。
5.1 単発のベクトル検索では足りない
密検索は検索の経済学を書き換えますが、埋め込みを役立たせている言い換えへの寛容さが、そのまま脆さでもあります。数字トークン、条文の引用、トランザクションコード、部品番号 — 表層形そのものが意味であるもの — はベクトル空間のあちこちの隅に着地します。あるものを数えるだけの BM25 には、この問題は起きません。
2つの手法は、互いに素な入力で失敗します。この一観察が、ハイブリッド検索の根拠のすべてで、本章が立つ第一原理です。残りはそこから従います — 単一の検索器で足りないなら、パイプラインは複数を組み合わせ、ランキングを正直に融合し、最終的に精密な一段に実コストを払い、そのすべての前にクエリを整える必要がある。
5.2 ハイブリッド検索 — 密ベクトルと BM25 を並列に
同じチャンク群に対して2つのインデックス: 埋め込みからの密 HNSW か IVF、そして BM25 か SPLADE からの疎な転置インデックス。両方が引かれ、両方がランキング済みリストを返し、取り込みパイプラインは両方に整合して書き込みます。BM25 はレガシーではありません — これまで考案されたなかでもっとも信頼できるキーワードランキング関数で、パラメータは少なくもゼロではなく、BEIR ベンチでドメイン外タスクの過半数で密オンリーを上回ります。ドメインが埋め込みの訓練分布から離れるほど差は広がります。
名指ししておきたい失敗モードがあります: BM25 は対象言語ごとに正しくトークナイズしないといけません。日本語コーパスを英語の既定アナライザで出すと、BM25 側は静かに純粋なノイズになります。密側がすべてを引き受けているように見えて、システムは動いているように見える。疎検索も進化しています — SPLADE 系の学習型疎モデルは、BM25 の運用シンプルさと、密検索の再現率の双方を継承します。
5.3 Reciprocal Rank Fusion とクロスエンコーダ再ランキング
2つのランキングを結合する素朴な方法はスコアを足すことですが、これはうまくいきません — BM25 の絶対値は無上限でコーパス依存、コサイン類似度はおよそ [-1, 1]。同じスケールではなく、固定の重み付けは永続的なチューニング問題になります。Reciprocal Rank Fusion (RRF) はスコアを捨てることで回避します。各候補について、融合スコアは検索器をまたいで 1/(k + rank) の和で、k = 60。形は上端で急、尾で平らで、結果は k に対して鈍感です。アルゴリズムは多クエリ拡張とも自然に合成します — 3つの言い換え × 2つの検索器で得た6本のリストが、同じ1行で融合できます。
RRF はどちらの検索器も浮上させなかった文書を救えません。その仕事はクエリ書き換えに属します。RRF が安価でハイパーパラメータなしに行うのは、独立にアップグレードされ差し替えられる検索器の調停です — 1脚を入れ替えたときに融合を再チューニングしなくてよいパイプラインは、維持コストが大きく違います。
これらのランキングを作ったバイエンコーダは、クエリとチャンクを同時には見ていません。クロスエンコーダ再ランカー は見ます — ペアを連結し、関連度を出力するよう微調整されたトランスフォーマーに同時に通します。各注意ヘッドが両側を同時に見ていて、クエリ中の特定の語句とチャンク中の特定の語句を結びつけられます。前計算できないので一次検索器としては遅すぎますが、ハイブリッド検索が出す50〜200候補に対しては絶妙にはまります。NDCG@10 のリフトは典型で5〜15点 — バイエンコーダの埋め込みモデルを差し替えるよりも大きい。
5.4 クエリ理解 — 書き換え、拡張、HyDE
これまでは、クエリが整っていることを暗黙に仮定していました。実際にはまず整っていません。ヘルプデスクのユーザーは「休暇」と打ち、ポリシーは「年次有給休暇の付与」と書いてある。開発者は「auth が500を返す」と打ち、ランブックは「認証サービスがトークン検証エラーで HTTP 500 を返す」と書いてある。仕事はクエリ側で起きる必要があります。3つのパターンが合成できます: 書き換え でクエリを自己完結にする(代名詞の解消、略語の展開、コーパスに合わせた言語の切り替え)。拡張 で複数の言い換えを得て、両方の検索器に手分けする。HyDE は、小さなモデルに仮想的な答えを書かせ、質問ではなくそれを埋め込む。コーパスは答えで満ちていて、答えは別の答えに似ていて、質問よりも近い。
守りのパターンは、書き換え版と一緒に元のクエリも残し、両方を発射しておくことです。書き換え器の出力は仮説であって、置き換えではありません。エージェント系で起きる「検索の劣化」のほとんどは、実は書き換えの劣化で、段階ごとの計装がないと見えません。
第5章を踏まえて
描いたパイプラインは、攻撃者が侵すための表面そのものでもあります。各段は入力を取り、出力を作り、操作しているデータを信頼する。コーパスは取り込み時に汚染されうる。埋め込みは敵対的チャンクで操作されうる。リランカーには偏りが入りうる。生成器は検索文書に紛れ込んだ命令にだまされうる。ここから本書は第IV部に入り、フレーミングは「どうよく検索するか」から「検索が攻撃されたら何が起きるか」へ移ります。
次回 — 第6章: RAGの脅威モデルと脆弱性。 RAG を有用にする開放性は、敵対者が利用する表面でもある — コーパス汚染、敵対的検索、間接プロンプトインジェクション、埋め込み反転、そして「混乱した代理人」。
