ベクトル検索とは？意味の近さで情報を探し出す技術

100 万件のチャンクと、1 件ずつ比べていられない

ここから Retrieval の話です。質問をベクトルに変えるところまでは前回のとおりで、残るのは、そのベクトルに近いチャンクをデータベースから取り出す作業です。

原理としては、質問のベクトルと全チャンクのベクトルを 1 つずつ比べ、近い順に並べるだけです。ところがチャンクが 100 万件あれば、比較も 100 万回になります。1 件あたりの計算は千次元以上の掛け算ですから、質問のたびにこれをやっていては回答が返るまでに何秒もかかります。

そこでベクトルデータベースは、近似最近傍探索（ANN）という方法を使います。事前にベクトルをグループ分けしておき、質問が来たら見込みのあるグループだけを調べます。全件は見ないので速い。その代わり、本当の 1 位を取りこぼすことがまれにあります。

この「近似」という言葉に不安を覚えるかもしれませんが、RAG では上位数件をまとめて渡すので、1 位が 2 位になったところで結果は変わりません。速度と引き換えに厳密さを少し手放す取引は、ここでは十分に割に合います。

取ってくるのは、上位の数件だけ

検索が返すのは「近い順に k 件」です。この k をいくつにするかは、後で必ず調整することになる数字で、まずは 3 から 5 件あたりから始めます。

多く取れば、正解が含まれる確率は上がります。同時に、関係の薄いチャンクも一緒に渡ることになり、LLM がそちらに引きずられます。プロンプトが長くなる分、料金も上がります。少なく取れば逆で、余計なものは減りますが、正解ごと落ちる危険が増えます。

もう 1 つ、頭に入れておきたいことがあります。検索が返すのは「意味が近いもの」であって「正しいもの」ではありません。近さは計算できますが、書かれている内容が事実かどうかは誰も見ていません。古い規程も、間違ったメモも、質問に近ければ同じように上位に来ます。

意味で探すやり方は、型番と人名に弱い

ベクトル検索は言い換えに強い代わりに、はっきりした苦手があります。

「AX-2200R の設定方法」と聞かれたとき、ベクトル検索は「AX-2200R」と「AX-2100R」の区別がつきません。どちらも似た形の型番として、近い位置に置かれてしまうからです。人名や社内の略称、プロジェクトのコードネームでも同じことが起きます。学習の中でほとんど出てこない文字列は、意味の空間で置き場所が定まらないのです。

実務での答えは、どちらか一方を選ぶことではありません。キーワード検索とベクトル検索を両方走らせ、それぞれの結果を混ぜて上位を決めるハイブリッド検索が使われます。型番はキーワード側が確実に拾い、言い換えはベクトル側が拾う。互いの苦手を埋め合う構成です。

自社の資料に型番や固有名詞が多いなら、最初からハイブリッドを前提に設計しておくほうが、後から取りこぼしを 1 件ずつ追いかけるより早く済みます。