ベクトルデータベース

概要

ベクトルデータベースは、埋め込みによって作られた高次元ベクトルを大量に格納し、「このベクトルに最も近いものはどれか」という近傍検索を高速に実行するために設計されたデータベースです。通常のデータベースが「id = 42 の行」「価格が1000円未満の商品」のような条件一致で探すのに対し、ベクトルデータベースは「意味が近い順に上位10件」という距離の近さで探します。

登場する場面の代表が RAG（検索拡張生成）です。社内文書を埋め込みベクトルとして格納しておき、ユーザーの質問が来たら意味の近い文書を取り出して LLM に渡す — この「取り出す」部分の基盤がベクトルデータベースです。ほかにも類似画像検索、レコメンド、重複コンテンツ検出など、「似ているものを探す」機能の裏側で広く使われています。

専用製品（Pinecone、Milvus、Qdrant、Weaviate など）のほか、PostgreSQL の拡張 pgvector のように既存のデータベースにベクトル検索機能を足す形態もあり、どちらを選ぶかが設計の定番論点になっています。

なぜ生まれたか

近傍検索そのものは単純で、クエリベクトルと全データの距離を1件ずつ計算して並べ替えれば正確な答えが出ます。しかしこの全件走査は、データ件数×次元数に比例する計算です。1536次元のベクトルが1000万件あれば、1回の検索で百数十億回の掛け算が必要になり、リクエストのたびに実行するにはあまりに遅い。しかも従来のデータベースのインデックスはここで役に立ちません。B木は「値の大小順」に並べられる1次元的なデータを前提としており、高次元空間の「近さ」には並び順という概念そのものが存在しないからです。

この壁を破ったのが近似最近傍探索（ANN: Approximate Nearest Neighbor）です。「厳密な最近傍を諦め、ほぼ確実に近い候補を桁違いに速く見つける」という割り切りで、全件走査では数秒かかる検索をミリ秒台に短縮します。意味検索の用途では「上位10件のうち1件が11位と入れ替わる」程度の誤差は実用上ほぼ問題にならないため、この近似は極めて割に合う取引でした。2010年代後半にHNSWなどの高性能アルゴリズムが確立し、LLMブームでRAG需要が爆発したことで、ANNインデックスを中核に据えた専用データベースが一気に普及したのです。

詳細

ANNインデックスの仕組み — HNSWを例に

現在最も広く使われるANNアルゴリズムがHNSW（Hierarchical Navigable Small World）です。全ベクトルを「近いもの同士を辺でつなぐグラフ」にしておき、検索時はグラフの辺をたどって「今いる点より近い点」へ貪欲に移動していきます。さらにこのグラフを多層にし、上層ほど点をまばらに（長距離の辺だけを）配置するのがミソです。検索は上層から始まり、高速道路で目的地の近くまで一気に移動してから、下層の一般道で細かく詰める — この階層構造により、数千万件からでも数十〜数百回の距離計算だけで近傍にたどり着けます。

HNSW以外にも、空間をクラスタに分割して有望なクラスタだけを調べるIVF、ベクトルを圧縮してメモリを節約する量子化（PQ）などの手法があり、実製品ではこれらを組み合わせます。共通するのは再現率（正しい近傍をどれだけ拾えるか）と速度・メモリのトレードオフで、インデックスのパラメータ調整はこの釣り合いを取る作業です。

従来のデータベースとの違いと共通点

RDBMS のインデックスが「完全一致・範囲・並び順」を高速化する装置だとすれば、ANNインデックスは「距離の近さ」を高速化する装置であり、答えが近似になる点が本質的に異なります。一方で、データベースとしての要求は共通です。実務の検索は「意味が近く、かつカテゴリが契約書で、作成日が今年」のようにメタデータの絞り込みを伴うため、ベクトル検索と属性フィルタを効率よく組み合わせられるか（フィルタしてから探すか、探してからフィルタするか）は製品の重要な差別化点です。また大量データではシャーディングやレプリケーションによるスケーリングも必要になり、このあたりの設計は NoSQL データベースの系譜に連なります。

専用DB か、既存DBの拡張か

選択肢は大きく2つあります。Pinecone・Milvus・Qdrant のような専用ベクトルデータベースは、ANN検索に最適化された性能・スケール・運用機能を備えますが、システムに新しいコンポーネントが1つ増え、既存データとの同期（商品情報はRDBMSに、ベクトルは専用DBに、両者をどう一致させ続けるか）という古典的な悩みを抱え込みます。

対して pgvector（PostgreSQL拡張）や、Elasticsearch・Redis・主要 NoSQL のベクトル検索機能のような既存DBの拡張は、使い慣れた SQL とトランザクションの世界にベクトル列を1つ足すだけで済み、データの同期問題が消えます。数百万件規模までなら pgvector で十分実用的、というのが現在の相場観です。迷ったら「まず既存DBの拡張で始め、規模や性能要件が専用DBを正当化するまで移行しない」のが堅実な進め方で、これはマイクロサービスを最初から選ばない判断と同型のトレードオフです。

RAGの検索基盤として

ベクトルデータベースの位置づけが最もよく分かるのが RAG のパイプラインです。事前に文書を分割・埋め込みして格納しておき、質問のたびに近傍検索で関連文書を取り出して LLM のプロンプトに添えます。

この構成での典型的な落とし穴は、検索品質の問題をすべてベクトルデータベースのせいにしてしまうことです。実際には、チャンク分割の粒度、埋め込みモデルの適合度、キーワード検索と併用するハイブリッド検索や再ランキングの有無が精度を大きく左右します。ベクトルデータベースはあくまで「近いベクトルを速く返す」係であり、「何を近いとみなすか」は埋め込み側の責任 — この分担を押さえておくと、RAGの改善ポイントを正しく切り分けられます。