ベクトルデータベースは、多数の高次元ベクトルを保存、索引付け、検索するためのシステムであり、典型的には機械学習モデルによって生成された埋め込みを扱い、クエリベクトルを、正確なキーワードやキー検索ではなく、距離に基づいて最も近い保存済みベクトルと照合できるようにする。従来のリレーショナルデータベースやドキュメントデータベースは、構造化フィールドに対する完全一致や範囲クエリを中心に構築されており、「この100万件のアイテムのうち、どれがこれに最も意味的に類似しているか」という、ベクトルデータベースが得意とする問いには適していない。
登場の背景
専用のベクトル検索へのニーズは、Transformer (architecture)と、それに基づく大規模言語モデルの台頭から直接生じた。組織が文書、画像、その他のコンテンツをセマンティック検索や検索拡張生成のために埋め込み始めるにつれ、クエリベクトルを保存済みの全ベクトルと一つずつ比較する単純な類似性検索は、数万件を超えると計算的に非現実的となった。近似最近傍（ANN）アルゴリズム、特に階層的ナビゲーション可能なスモールワールドグラフ（HNSW）や、積量子化と組み合わせた転置インデックスは、数百万から数十億のベクトルを、想起精度の小さな調整可能な損失と引き換えに、ミリ秒単位で検索することを可能にした。
Pinecone、Weaviate、Milvus、Qdrantなどの専用ベクトルデータベースは2020年代初頭に登場し、これらのANNアルゴリズムを、永続性、レプリケーション、メタデータによるフィルタリング、水平スケーリングといったデータベースに期待される運用機能とともにパッケージ化した。同時に、既存のデータベースも、PostgreSQL向けのpgvectorや、Elasticsearch、Redis、MongoDBのベクトルインデックスなど、ベクトル検索をスタンドアロン製品ではなく機能として追加し、「ベクトルデータベース」という明確なカテゴリと、既存インフラに組み込まれる機能としてのベクトル検索との境界線を曖昧にした。
仕組み
典型的なワークフローでは、コーパス内の各アイテムを埋め込みモデルで埋め込み、結果のベクトルを識別子と任意のメタデータとともに保存し、ベクトル集合に対してANNインデックスを構築する。クエリ時には、入力されたテキストや画像を同じモデルで埋め込み、インデックスは選択された距離メトリック（最も一般的にはコサイン類似度、ドット積、ユークリッド距離）に基づいてk個の最近傍ベクトルを返す。多くのシステムはハイブリッド検索をサポートしており、ベクトル類似性を従来のキーワードフィルタリングやメタデータ制約（特定の日付範囲やカテゴリの文書に結果を制限するなど）と組み合わせる。
AIアプリケーションでの役割
ベクトルデータベースは、検索拡張生成の成長に伴い、AIインフラの中核的要素となった。この手法では、ベクトルインデックスから取得された関連パッセージがLLMのコンテキストウィンドウに挿入され、特定の文書に基づいて回答を裏付け、幻覚を軽減する。また、レコメンデーションシステム、画像・音声類似性検索、重複排除パイプライン、異常検知など、「これに似たものを見つける」というクエリが機能するあらゆる場面を支えている。
限界とトレードオフ
ANN検索は、少量の精度を大きな速度向上と引き換えにしており、インデックスの種類とパラメータの選択には、クエリレイテンシ、メモリフットプリント、想起率の間で実際のトレードオフが伴う。埋め込み品質は検索品質を制約する。ベクトルデータベースは、それを供給する埋め込みモデルと同じ程度にしか良くなり得ず、コーパスの索引付けに使用された埋め込みモデルとクエリ時に使用されるモデルとの不一致は、結果を静かに劣化させる。2020年代半ば現在、ベクトルデータベースは、大量の生テキストを直接取り込める長コンテキストLLMからの競争圧力に直面しており、一部のアプリケーションでの検索の必要性を減らすものの完全には排除せず、また、ベクトル検索を別個の運用システムではなく組み込み機能として吸収する汎用データベースからの競争圧力にも直面している。