RAG 05：ベクトル検索 ― 何百万の点から近い点を速く探す

ベクトルデータベース＝点をしまって、近い点を速く出す棚

ベクトルデータベースは、ベクトルをしまっておき、「この点に近いものを k 個ください」という問い合わせに速く答えるためのデータベースです（k は取り出したい件数。k=5 なら近い順に上位5件）。

しまうのは、ベクトルだけではありません。図のように、1つのチャンクについて次のものを一緒に置きます。

ベクトルデータベースの仕事は、大きく3つです。しまう、近い順に k 個出す、そして付箋で絞る。

2つ目を速くするのが索引です。本の巻末の索引が「この言葉は何ページ」と教えてくれるように、ベクトルの索引は「この辺りの点はこれ」と見当を付けてくれます。索引の作り方にはいくつか流派があり、この章の中心はそこです。

「ベクトルデータベース」という名前の専用製品もありますが、普段使っているデータベースにベクトルの機能を足すこともできます（後で見ます）。

いちばん素直な方法：全部と比べる（総当たり）

まず、いちばん素直な方法から。質問の点と、全部の点との近さを1つずつ計算して、近い順に並べます。近さの測り方は、第4章で見た「矢印の向きがどれだけそろっているか」（コサイン類似度）です。これを総当たり（全件検索、フラット検索とも）と呼びます。第4章のコード例はこの方法でした。

図では、質問（赤い点）から全部の点に線が引かれています。この1本1本が、1回の近さの計算です。

総当たりには、大きな長所があります。必ず本当に近い順が出ることです。取りこぼしがありません。索引も要らないので、仕組みも単純です。

短所は、件数に比例して遅くなることです。点が10倍になれば、時間も10倍です。

とはいえ、コンピュータは掛け算がとても速いので、数千〜数万件くらいなら総当たりで十分なことも多いのです。試作の段階や、部署ごとの小さな資料庫なら、索引を入れずに始めるのは良い選択です。取りこぼしが無いので、後で索引を入れたときの「正解」としても使えます（再現率の計算、後で見ます）。

問題になるのは、数十万〜数億件の規模になったとき、あるいは質問の数がとても多いときです。

発想の転換：少しの取りこぼしを許して、ずっと速く

大きな規模で使われているのは、近似最近傍探索（Approximate Nearest Neighbor、略して ANN）という考え方です。

「最近傍」は「いちばん近いもの」、「近似」は「だいたい」という意味です。つまり、「いちばん近いものを、だいたい正しく見つける」方法です。

図書館でたとえます。探している本の内容に近い本を探したいとき、全部の本を1冊ずつ開く人はいません。「この話なら、たぶんこの辺りの棚」と見当を付けて、その周りだけを見ます。ほとんどの場合、それで見つかります。ただし、たまに、別の棚に置かれていた本を見逃すことがあります。

ANN も同じです。図の赤い囲みのように、質問の近所だけを調べます。比べる回数は、100万回から数百〜数千回に減ります。その代わり、たまに本当の1位を逃します。

RAG では、この取引はたいてい割に合います。検索で拾う候補は5件、10件と複数あり、1位を少し逃しても、他の候補に同じ情報があることが多いからです。さらに後ろの段階で並べ直すこともできます（第7章）。

では、「見当を付ける」をどうやって実現するのか。代表的な2つの方法、HNSW と IVF を見ていきます。

HNSW の考え方①：近所どうしを道でつなぐ

いまいちばん広く使われている索引が HNSW（Hierarchical Navigable Small World、直訳すると「階層になった、たどりやすい小さな世界」）です。名前は長いですが、考え方は「道路網」です。「小さな世界」は、知り合いの知り合いをたどると少ない手数で誰にでも届く、という性質のことです。

まず、点どうしを道でつなぎます。それぞれの点は、自分に近い点の何個かと道でつながっています。図の灰色の線が道です。

探すときは、決まった入口の点から出発します。そして、次の手順を繰り返します。

図の赤い矢印が、入口から質問の近くまでたどった道です。比べたのは、通った点の隣だけです。全部の点とは比べていません。

この方法がうまくいくのは、「質問に近づくほど、隣の点も質問に近い」からです。坂を下るように、近いほうへ近いほうへと進めば、たいてい底（いちばん近い点）に着きます。

ただし弱点もあります。道が近所どうしだけだと、入口が遠いときに何十回も小さな一歩を重ねることになります。これを解決するのが、次のページの「階」です。

HNSW の考え方②：道を何階にも重ねる

HNSW の「H」は Hierarchical、階層です。道路網を何階にも重ねて作ります。

探すときは、上の階から始めます。上の階は点が少なく、道が長いので、少ない手数で「だいたいこの辺り」まで一気に移れます。それ以上近づけなくなったら、1つ下の階に降りて、そこから続けます。いちばん下の階に着いたら、全部の点がある細かい道で、質問のすぐ近くまで寄せます。

図の赤い矢印は、上の階で右へ大きく移り、降りて、また移り、最後に下の階で細かく寄せる様子です。

東京から大阪の知らない住所へ行くとき、まず新幹線、次に在来線、最後に歩く、というのと同じです。

HNSW は 2016年に発表された手法で、速さと正確さのバランスが良く、いまのベクトル検索の主流です。多くのベクトルデータベースや、PostgreSQL の拡張 pgvector も対応しています。

弱点は、道の情報を持つのでメモリ（コンピュータの作業用の記憶場所）を多く使うことと、索引を作るのに時間がかかることです。

もう1つの方法 IVF：地図を区画に分け、近い区画だけ調べる

もう1つの代表的な方法が IVF（Inverted File、転置ファイル）です。こちらは「区画分け」です。名前の「転置（逆引き）」は、「区画 → その区画に入っている点の一覧」という逆引き表を持つことから来ています。

あらかじめ、全部の点をいくつかの区画に分けておきます。区画の分け方は、点の集まり方から自動で決めます（クラスタリング＝近い点どうしを自動でグループにまとめること）。そして、それぞれの区画にどの点が入っているかを覚えておきます。

探すときは、まず質問がどの区画に近いかを調べ、その区画の中の点とだけ比べます。区画が1000個あって1つだけ調べるなら、比べる点はおよそ1000分の1です。

弱点は境目です。図では、質問は区画 A にいます。区画 A だけを調べると、A の中でいちばん近い点は見つかります。でも、本当は2番目に近い点が、境目のすぐ向こうの区画 D にあります。これを見落とします。

対策は、調べる区画を増やすことです。近い区画を2つ、3つと調べれば、境目の点も拾えます。そのぶん遅くなります。

HNSW と比べると、IVF は一般にメモリが少なく、索引を作るのが速い一方、同じ正確さでの検索の速さでは HNSW に分があることが多い、と言われます。また、区画は最初の点の集まり方で決まるので、後から資料が大きく増えたり変わったりすると、区画を作り直す必要が出ます。

つまみ1つで「正確さ」と「速さ」を取り引きする

HNSW も IVF も、「どれくらい丁寧に探すか」を決めるつまみを持っています。

つまみを決めるには、「どれくらい正確か」を測る物差しが要ります。それが再現率（リコール）です。ここでは「総当たりで出した本当の上位10件のうち、何件を拾えたか」です。10件中9件なら、再現率は 0.9 です。

測り方は単純です。実際に来そうな質問をいくつか用意し、総当たりと索引の両方で検索して、結果を突き合わせます。総当たりは遅いですが、測るときだけなら問題ありません。

大事なのは、速さだけを見てつまみを決めないことです。索引を入れて「速くなった」と喜んでいたら、実は再現率が 0.6 まで落ちていて、答えの質が下がっていた、ということが起きます。しかもエラーは何も出ません。

ここでの再現率は「索引が総当たりにどれだけ近いか」です。「質問に本当に答えている資料を拾えたか」という意味の再現率は、第12章でもう一度出てきます。

いくつ取り出すか（top-k）

検索で「近い順に何個取り出すか」を k と書き、top-k と呼びます。k をいくつにするかは、意外と大事な決めごとです。

k が小さすぎると、答えの載った資料を取りこぼします。埋め込みは完璧ではないので（第4章）、本当に必要な資料がいつも1位に来るとは限りません。

逆に k が大きすぎると、関係の薄い資料がたくさん混ざります。LLM に全部渡すと、読むお金と時間が増えるだけでなく、関係ない資料に引きずられた答えが出やすくなります。

よく使われる形は、「多めに拾って、並べ直して、少しだけ渡す」です。たとえば検索で50件拾い、第7章の並べ直しで上位5件に絞って LLM に渡します。

数字は目安です。自分の資料と質問で、k を変えながら「答えの載った資料が入っているか」を数えて決めます（第12章）。

付箋で絞る：「人事部の資料だけ」から探したい

実際の RAG では、「全部の資料から近いもの」ではなく、「条件に合う資料の中から近いもの」が欲しい場面がたくさんあります。「人事部の資料だけ」「2026年度版だけ」「この利用者が見てよい資料だけ」などです。ここで付箋（メタデータ）を使います。

絞り方には2通りあります。

図の左が後絞りです。近い8件を取ったら、人事の資料は2件しかありませんでした。欲しかったのは8件なのに、2件しか残りません。条件が厳しいほど（資料全体に占める割合が小さいほど）、ひどくなります。最悪は0件で、LLM は「資料が見つかりません」と答えてしまいます。

右が先絞りです。人事の資料の中から8件を取るので、ちゃんと8件そろいます。

最近のベクトルデータベースの多くは、この問題に対策を持っています。たとえば pgvector は 0.8.0 から、条件を満たす結果が足りるまで索引を追加で探し続ける設定を持っています。使っている製品が、絞り込みをどう扱うかを確かめてください。

1つだけ、絶対の約束があります。見てよい資料かどうか（権限）の絞り込みは、必ず検索の段階で行うことです。LLM に「この人には見せないで」と頼むのは守りになりません（第13章）。

コードで見る：PostgreSQL（pgvector）の場合

具体例として、広く使われるデータベース PostgreSQL に後から足せる追加機能（拡張）、pgvector を使った場合を見ます。いつもの SQL の中で、ベクトルを列として扱えます。

図のコードでは、次のことをしています。

「コサイン距離」は「1 − コサイン類似度」のことで、向きがそろっているほど小さくなります。だから「距離の小さい順」＝「近い順」です。

注意点が1つあります。索引の距離の種類と、並べるときの演算子をそろえることです。pgvector では、コサイン距離は <=>、内積（第4章で見た「掛け算の足し合わせ」）は <#>、ふつうの距離（定規で測る直線の長さ、ユークリッド距離）は <-> です。索引をコサイン用に作ったのに、別の演算子で並べると、索引が使われず総当たりになります。

埋め込みモデルがどの距離を前提にしているかは、モデルの説明に書いてあります。多くのモデルは長さ1にそろえた（正規化した）ベクトルを返すので、コサインと内積は同じ順位になります（第4章）。

置き場所の選び方：いまの DB に足すか、専用にするか

ベクトルの置き場所には、大きく3つの選び方があります。この本では特定の製品の良し悪しは比べません。考え方だけを見ます。

選ぶときの決め手は、次のようなものです。

規模：件数（数万か、数億か）と、1秒あたりの質問数。機能：付箋での絞り込みがうまく動くか、キーワード検索（第6章）と組み合わせられるか。運用：権限、バックアップ、障害のときに誰が見るか。

迷ったら、まずは手持ちのデータベースで始めるのがおすすめです。資料の本文、権限、更新日といった情報は、たいてい既にどこかのデータベースにあります。同じ場所にベクトルも置けば、データが二重になりません。規模や要件が合わなくなってから専用のものを考えても、遅くはありません。

資料が変わったら：古い点を消し、新しい点を足す

資料は毎日変わります。規程が改定され、マニュアルが書き直され、古い文書は廃止されます。ベクトルデータベースも、それに合わせて更新しなければいけません。

いちばん安全な考え方は、「差し替え」です。

図の灰色の点は、改定前の古い版のチャンクです。消し忘れると、質問によっては古い版が上位に来て、古い規程で答えます。新旧が両方ヒットして、LLM が矛盾した資料を読まされることもあります（第13章）。

このために、チャンクの付箋には元の文書のIDを必ず入れておきます。文書が変わったら、その ID のチャンクを全部消して、新しく切って埋め込み直します。

索引の側にも注意があります。HNSW のような索引では、点を消しても道の中に跡が残ることがあり、削除や更新が積み重なると、速さや正確さが少しずつ落ちます。IVF では、区画の分け方が資料の変化に合わなくなります。製品によって扱いは違いますが、ときどき索引を作り直す運用を考えておきます。

よくある落とし穴

ベクトル検索で、実際によく起きる失敗をまとめます。どれもエラーが出ないのが厄介なところです。

特に「後絞り」と「消し忘れ」は、テストのときは資料が少なく条件もゆるいので気づかず、本番で資料が増えてから表に出ることが多い失敗です。本番に近い量の資料で試しておくのが一番の予防です。あわせて、検索が返した件数と、つまみの値、かかった時間を記録に残しておくと、おかしな答えが出たときに原因を追えます（第13章）。