PostgreSQL / pgvector を使った、数百万件規模のベクトルデータ高速検索チューニング
はじめに
こんにちは、NKKTech Global です。
RAG（検索拡張生成）の実装において、多くのエンジニアが最初に選ぶのが PostgreSQL の pgvector 拡張です。しかし、データ量が「数万件」から「数百万件」にスケールした瞬間、検索クエリのレイテンシが数秒単位に跳ね上がるという壁にぶつかります。
本記事では、大規模なベクトルデータを運用する際に不可欠な、インデックス選定とシステムパラメータの最適化について解説します。
1. インデックスの選択：IVFFlat vs HNSW
数百万件規模では、シーケンシャルスキャン（全件検索）は不可能です。必ず近似最近傍探索（ANN）インデックスを使用します。
IVFFlat (Inverted File Flat)
- 特徴: クラスタリングベース。インデックス作成が速い。
-
欠点: データが増えると検索精度（Recall）を維持するために
probesを増やす必要があり、検索が遅くなる。 - 適したケース: データ更新が非常に頻繁で、検索精度に少し余裕がある場合。
HNSW (Hierarchical Navigable Small World) ※推奨
- 特徴: グラフベース。検索速度と精度のバランスが圧倒的に優れている。
- 欠点: インデックス作成に時間がかかり、メモリ（RAM）を多く消費する。
- 結論: 数百万件規模なら、迷わず HNSW を選択してください。
2. HNSWインデックス作成時のチューニング
HNSWのパフォーマンスは、インデックス作成時のパラメータで決まります。
CREATE INDEX ON items USING hnsw (embedding vector_cosine_ops)
WITH (m = 16, ef_construction = 64);
パラメータの役割と影響
m (デフォルト 16):
各ノードの最大接続数です。
影響: 値を増やすとグラフの密度が上がり、検索精度が向上します。一方で、インデックス作成時のメモリ消費量と、ストレージ上のインデックスサイズが増大します。
ef_construction (デフォルト 64):
インデックス構築時の探索範囲を決定します。
影響: 値を増やすとインデックスの質（検索精度）が向上しますが、インデックス作成時間が大幅に伸びます。
大規模環境での推奨値
データセットの特性によりますが、数百万件規模では以下の数値を基準に調整を開始することをお勧めします。
3. 検索時のパフォーマンス・チューニング：ef_search
インデックス構築後、検索クエリの実行時にリアルタイムで調整可能なパラメータが ef_search です。
ef_search の調整
ef_search は検索時の探索範囲を制御し、**「精度と速度のトレードオフ」**を決定します。
-- 検索セッション内で動的に設定
SET hnsw.ef_search = 100;
###
-- ベクトル検索実行
SELECT * FROM items
ORDER BY embedding <=> '[...]'
LIMIT 10;
- 値を大きくする: より多くのパスを探索するため精度は上がりますが、計算量が増え、レスポンスが遅くなります。
- 値を小さくする: 探索範囲が狭まり、高速化されますが精度は低下します。
実務では、まず ef_search = 40 程度から測定を開始し、目標とする精度（リコール率）をクリアできる最小の数値を特定するのがベストプラクティスです。
まとめ：効率的なスケーリングのために
数百万件規模のベクトル検索基盤を構築するポイントをまとめます。
- HNSWインデックスを必ず使用する。
-
mとef_constructionを調整してインデックスの「密度」を最適化する。 - 実行時に
ef_searchを調整し、アプリケーションが求める「速度」と「精度」の境界線を見極める。
NKKTech Globalでは、こうしたデータベースの内部チューニングから、LLMを活用したエンタープライズ向けAIシステムの構築まで、幅広くサポートしております。
お問い合わせ先
AIソリューションの構築や、大規模データのパフォーマンス改善でお悩みの方は、下記よりお気軽にご連絡ください。
- Webサイト: https://nkktech.com/
- メール: contact@nkk.com.vn
- LinkedIn: NKKTech Global Official
著者：NKKTech Global 技術チーム
私たちは、グローバルな知見と確かな技術力で企業のDXを加速させる技術パートナーです。