ベクトル検索とベクトルインデックス

生成 AI の (検索拡張生成) やでは、文章や画像を数値の (埋め込み) に変え、意味の近いものを探します。データエンジニアは、ベクトルを作るパイプライン、保管するデータストア、速く探すためのインデックスを用意します。DEA-C01 では、となどのベクトルインデックスの違い (スキル 2.1.8)、 PostgreSQL などのストアの使い分け (スキル 2.1.3)、ナレッジベースによるベクトル化の考え方 (スキル 2.4.6) が問われます。

Point

埋め込み (embedding): 文章などを、意味の近さが距離の近さになるような数値の並び (ベクトル) に変えたものです。
HNSW = Hierarchical Navigable Small Worlds (階層化された航行可能なスモールワールド) です。グラフをたどって近いベクトルを探すインデックスです。
IVF = Inverted File (転置ファイル) です。ベクトルをクラスターに分け、近いクラスターだけを探すインデックスです。
ANN = Approximate Nearest Neighbor (近似最近傍探索): 厳密さを少し犠牲にして、速く近いものを探す方式です。

概要

のパイプラインは、ドキュメントの取り込みから始まります。

全件と1つずつ距離を比べる厳密な検索 (総当たり) は、が数百万件を超えると遅すぎます。そこで、少しの精度と引き換えに速く探す近似最近傍探索 (ANN) のインデックスを作ります。

用語	意味
次元数	ベクトルの数値の個数。で決まる (保存時と検索時で同じでなければならない)
距離の指標	コサイン類似度、ユークリッド距離、内積
(recall)	本当に近い上位 k 件のうち、どれだけ見つけられたか。ANN の精度の指標

主要技術

①HNSW と IVF の違い ⚠️ 頻出

観点
仕組み	を多層のグラフでつなぎ、上の層から近いノードをたどる	ベクトルをクラスター () に分け、近いクラスターの中だけを探す
検索の速さと精度	速く、が高い	HNSW より再現率が下がりやすい。nprobes を増やすと精度が上がり遅くなる
メモリ	多い (グラフのつながりを持つ)	少ない (圧縮と組み合わせやすい)
インデックスの作成	時間がかかる	事前の学習 (クラスターの中心を決める) が必要。代表的なデータがそろってから作る
データの追加	追加しやすい	分布が変わるとクラスターの作り直しが必要になる
主なパラメータ	m (つながりの数、メモリに効く)、ef_construction (作成時の探索の広さ)、ef_search	nlist (クラスターの数)、nprobes (探すクラスターの数)
向くケース	低遅延・高精度が必要、メモリに余裕がある	非常に大量のベクトル、メモリとコストを抑えたい

ベクトルを (直積量子化 PQ、スカラー量子化など) して圧縮すると、メモリを大きく減らせますが、精度が少し下がります。

Point

HNSW = 「グラフをたどる、速くて正確、メモリ多め」
IVF = 「クラスターに分ける、学習が必要、メモリ少なめ」
試験で「最も低い遅延と高い再現率」なら HNSW、「メモリを抑えて大量に」なら IVF (+量子化) を選びます。

②ベクトルストアの選び方 ⚠️ 頻出

ストア	インデックス	向くケース
PostgreSQL / for PostgreSQL ()	、IVFFlat	既存のリレーショナルデータと同じ DB でを持ち、で結合・絞り込みしたい
/ Serverless (k-NN)	HNSW (Faiss・Lucene)、 (Faiss)	全文検索とを組み合わせる、大規模なベクトル検索
Amazon MemoryDB	HNSW など	ミリ秒未満の応答が必要なベクトル検索、データを失えない
Analytics	グラフ + ベクトル	関係性とベクトルの類似を組み合わせる
	HNSW、IVFFlat	ドキュメントと一緒にベクトルを持つ
	のベクトル	大量のベクトルを低コストで保管し、問い合わせの頻度が低い

pgvector では、CREATE INDEX ... USING hnsw または USING ivfflat でインデックスを作ります。IVFFlat はクラスターを作るためにデータが入ってから作成し、HNSW は空のテーブルにも作れます。OpenSearch の k-NN では、NMSLIB のエンジンは非推奨になり、Faiss か Lucene を選びます。IVF を使えるのは Faiss で、事前の学習 (Train ) が必要です。

③Amazon Bedrock ナレッジベースによるベクトル化

ナレッジベースは、などのデータソースのドキュメントを取り込み、分割・埋め込み・ストアへの書き込みまでを管理する仕組みです。パイプラインを自作せずにのデータ準備ができます。

段階	内容
データソース	S3、、Confluence、SharePoint、Salesforce など
解析	テキストを取り出す。図表や画像を含む文書には高度な解析の機能を選べる
分割	既定 (約300トークン、文の区切りを保つ)、固定長 (と重なりの割合を指定)、階層 (親と子のチャンク)、セマンティック (意味の切れ目で分ける)、分割しない
埋め込み	Amazon Titan Text Embeddings、Cohere Embed などのモデルでベクトルにする
ベクトルストア	Serverless、 PostgreSQL、 Analytics、、他社のストア (Pinecone、MongoDB Atlas、Redis Enterprise Cloud) など
同期	データソースの変更を取り込みジョブで反映する。削除した文書のベクトルも消える

チャンクの大きさ	長所	短所
小さい	検索が正確 (話題が1つにまとまる)	文脈が足りない
大きい	文脈が豊富	関係のない内容が混ざり、検索の精度が下がる
階層	小さいチャンクで探し、大きい親チャンクを返す	返る件数が減ることがある

セマンティックチャンクは、分割にを使うため追加の費用がかかります。Bedrock をデータ処理に組み込む方法は「 (LLM) をデータ処理に組み込む」の章で扱います。

④運用上の注意

注意点	内容
をそろえる	保存時と検索時で同じモデル・同じ次元数にする
モデルを変えたら作り直す	既存のと互換性がなくなるため、全件を埋め込み直す
元データとの同期	文書の更新・削除をベクトルにも反映する。残ると削除済みの内容が回答に混ざる
メタデータでの絞り込み	部門・日付などの属性を一緒に保存し、検索時に絞り込む
アクセス制御と暗号化	ストアをで暗号化し、や DB の権限で読める人を制限する

試験対策

①判断マトリクス

問題文のキーワード	選ぶもの
低遅延・高いの
メモリを抑えて大量のを検索	(+ )
IVF のインデックスを作る前に必要なこと	代表的なデータでの学習 (クラスターの中心を決める)
既存の PostgreSQL の業務データとベクトルを一緒に	PostgreSQL ()
キーワード検索とベクトル検索の組み合わせ
ミリ秒未満のベクトル検索、データを失えない	Amazon MemoryDB
大量のベクトルを低コストで保管
分割・埋め込み・保管のパイプラインを自作したくない	ナレッジベース
文の区切りを保ちつつ一定の長さで分割	既定または固定長の分割
意味のまとまりで分割したい	セマンティックチャンク

②よくある誤答

を、データがまだほとんどない状態で作ること。クラスターが偏り、精度が出ません。
保存時と検索時で別のを使うこと。距離が意味を持たなくなります。
埋め込みモデルを変えたのに、既存のを作り直さないこと。
のために専用の新しいデータベースが必ず必要と考えること。既存の PostgreSQL やで扱えます。