RAG検索設計
ベクトル検索だけでは精度が出ない — ハイブリッド検索の設計
「A社の実績を出して」と検索したのに、トップに並んだのは競合のB社・C社の資料だった——ベクトル検索を入れた現場で、この取り違えは驚くほどよく起きます。型番で聞いているのに似た製品が返る、というのも同じ症状です。ベクトル検索はいまのRAGの定番なのに、なぜ肝心なところで外すのか。
答えは、検索を一本に頼っているからです。この記事では、ベクトル検索の弱点をキーワード検索とリランキングで補うハイブリッド検索の設計と、その底に流れる「ルールで解ける所はルールで解く」という考え方を、実装者の視点で書きます。検索は、私たちの経験では本番で最も大きく精度を落とし、かつ直したときの効果が一番大きい層です。全体像はRAG精度の診断ガイドにあり、この記事はその第2層「検索設計」を深掘りするものです。
なぜベクトル検索だけでは固有名詞を取りこぼすのか
ベクトル検索の強みは、言い換えへの強さです。「解約したいときの手続きは」と日常語で聞いても、「中途解約」「契約の解除」と書かれた条項までたどり着く。ここはベクトル検索の独壇場で、キーワード一致では拾えない曖昧な質問に効きます。
問題は、この「意味で寄せる」力が、区別してほしい場面でも働いてしまうことです。会社名・型番・条文番号のように一文字違えば別物になる情報ほど、ベクトルは「近い仲間」としてまとめてしまう。だから「A社の実績は?」に、そっくりなB社・C社の資料が平気で上位に並ぶ。正直に言うと、私も最初はベクトル1本で十分だと思っていました。固有名詞で何度も取り違えて、ようやく限界に気づいたのです。意味が近いことと、指しているモノが同じことは、別だ——これが検索設計の出発点です。
ハイブリッド検索の設計 — 3つを組み合わせる
解決策は、検索を一本に頼らないことです。意味の近さはベクトル検索に任せ、固有名詞や型番のような厳密な一致はキーワード検索(BM25)で押さえ、最後にリランキングで「この質問に本当に答えているのはどれか」という観点で並べ直す。
| 検索手法 | 得意なこと | 苦手なこと | 役割 |
|---|---|---|---|
| ベクトル検索 | 意味の近さ(曖昧な言い換え) | 固有名詞・型番の厳密一致 | 言い換え質問の入口 |
| キーワード検索(BM25) | 固有名詞・型番・条文番号の一致 | 言い換え・曖昧な表現 | 固有名詞の取りこぼしを塞ぐ |
| リランキング | 質問への適合度で並べ替え | 単独では検索しない | 上位の精度を底上げ |
ベクトルとキーワードという2つの検索結果を束ねる方法としては、RRF(Reciprocal Rank Fusion)が古典的で安定します。順位だけを使ってスコアを気にせず統合できるので、実装が単純で壊れにくい(Cormack et al., SIGIR 2009)。商社の案件では、このハイブリッド化が、正答率を38.8%から93.6%へ引き上げた改善の中で最も大きく効いた部分でした。
ルールで解ける所は、ルールで解く
ここで、この記事でいちばん伝えたい考え方に触れます。ハイブリッド検索が効くのは、単に手法を足したからではありません。「意味の曖昧さ」と「厳密な一致」という性質の違う問題を、それぞれ向いた道具に振り分けているからです。
固有名詞の厳密一致は、答えが一意に決まる問題です。ここにLLMや凝った仕組みを持ち出す必要はありません。キーワード検索(BM25)は、統計に基づく確立された手法で、意味を推論しないぶん、ブレず・安く・速く・なぜその順位になったかを説明できる(Robertson & Zaragoza, 2009)。同じ発想で、記号や略称の正規化、通称から正式名称へのクエリ拡張も、まず辞書やルールで解けないかを先に考える。
決定的に解ける処理をルールで固めることには、はっきりした利点があります。測定しやすく、出力がブレず、コストが低く、保守しやすい。LLMの出番は、それでも残る意味の曖昧さを吸収する所——曖昧な言い換えや、自由文の解釈——に絞る。検索の土台をルールで固めるほど、本番は安定します。「AIらしさ」で全部を解こうとせず、ルールで固められる所は固めて、LLMは曖昧さの担当に回す。これが、私たちが本番の検索で繰り返し確かめてきた線引きです。
リランキングで、上位を底上げする
ベクトルとキーワードで候補を広く集めたら、最後にリランキングで並べ直します。集める段階は「取りこぼさない」ことが仕事なので広めに拾い、並べる段階で「質問への適合度」で上位を締める。この役割分担があると、拾いすぎたノイズが上位を汚さずに済みます。
どこまでやるか — 過剰設計を避ける
ハイブリッド検索まで来ると、多くの業務RAGは実用域に届きます。それでも、法令や規程のように条文が準用・参照でつながっている文書では、意味的に遠い準用先が抜けるので、参照をたどるGraph拡張を足す価値があります(法令RAGをGraph拡張で解いた事例)。
逆に、参照構造の無い文書にGraphを足しても、複雑さが増えるだけです。検索は「足せば足すほど良い」ものではありません。症状と文書の性質を見て、必要な分だけ組む。どの系統まで必要かの見立てはRAG精度の診断ガイドの系統ラダーにまとめています。
検索設計の点検リスト
- ベクトル検索だけになっていないか。固有名詞をキーワード検索(BM25)で押さえているか。
- ベクトルとキーワードの結果をRRFなどで安定して統合できているか。
- リランキングで上位の適合度を底上げしているか。
- 一意に決まる処理(厳密一致・正規化・略称展開)を、まずルールで解こうとしているか。
- 文書の性質に対して、検索が過剰・過少になっていないか。
検索の穴を、一緒に塞ぎませんか
「固有名詞で外す」「準用先が抜ける」という症状が出ているなら、検索を見直す余地があります。いまの構成と、どの種類の質問で外しているのかを聞かせていただければ、ハイブリッド化・クエリ拡張・参照辿りのどこに伸びしろがありそうか、当たりをつけてお伝えします。検索を含む全体像はRAG精度の診断ガイド、この検索設計が現場で効いた記録は商社の文書検索事例にあります。
参考文献
- Cormack, Clarke & Büttcher (2009) Reciprocal Rank Fusion outperforms Condorcet and individual Rank Learning Methods, SIGIR — PDF
- Robertson & Zaragoza (2009) The Probabilistic Relevance Framework: BM25 and Beyond, Foundations and Trends in Information Retrieval — link
- Gao et al. (2023) Retrieval-Augmented Generation for Large Language Models: A Survey — arXiv:2312.10997