検索系リソースの選び方
「検索」と一口に言っても、キーワードの一致で探す全文検索と、意味の近さで探すベクトル検索では仕組みも適性もまったく違う。まずどちらが必要かを見極めることが、この領域の最初の分岐になる。
全文検索とベクトル検索の使い分け
- 全文検索が向く — 商品名・型番・人名など、利用者が正確な語を知っている場合。結果の理由が説明でき、挙動が予測しやすい
- ベクトル検索が向く — 「こういう内容の資料」といった曖昧な問い合わせ。表記が違っても意味が近ければ拾える
- 両方必要なことが多い — 実務ではハイブリッド構成にして、キーワード一致を優先しつつ意味検索で補うのが定石になる
日本語で必ず確認すること
日本語は単語の区切りが明示されないため、英語圏で評価の高いサービスがそのまま通用するとは限らない。形態素解析の精度、表記ゆれ（カタカナ・ひらがな・漢字・全角半角）の吸収、同義語辞書の登録可否は、実際のデータで確認するしかない。
カタログスペックではなく自分のデータで試してください
検索品質は対象データの性質に強く依存します。想定される検索語を10〜20個用意し、期待する結果が上位に来るかを候補ごとに比べる——この作業を省くと、導入後に「なぜか欲しいものが出てこない」という状態から抜け出せなくなります。
精度改善は生成側より検索側から
RAG 構成で回答の質が悪いとき、生成モデルを高性能なものに替えたくなるが、多くの場合ボトルネックは検索側にある。関連度の低い資料を渡していれば、どんなモデルでも良い回答は作れない。再ランク付けの仕組みを挟む、チャンクの分割単位を見直す、といった検索段の改善のほうが費用対効果は高い。