Vector Databaseとは？Embeddingを保存し、意味が近いものを高速に探す仕組み

第021回では、文章や画像をEmbeddingというVectorへ変換し、意味の近さを計算できるようにしました。

次の問題は、Vectorが1,000万件あったらどうするかです。

毎回すべてのVectorを一件ずつ比較すると、Dataが増えるほど処理が重くなります。

そこで使われるのが**Vector Database（ベクトルデータベース）**です。

Similarity Searchを中心にしたDatabase

普通のDatabaseは、

• user_id = 123
• price < 100
• created_at が昨日以降

のような正確な条件検索が得意です。

Vector Databaseでは、これに加えて、

このQuery Vectorに最も近いVectorはどれ？

という**Nearest Neighbor Search（近傍検索）**を重要な機能として扱います。

なぜIndexが必要？

すべてのVectorを完全比較する方法は、Dataが増えるほど遅くなります。

そのためVector Searchでは、Graph型などの特殊なIndexやApproximate Nearest Neighbor手法を使い、候補を高速に絞ります。

Approximateは「適当」という意味ではありません。

数学的に完全な一位を必ず探すことと引き換えに、非常に高い速度とScaleを得る設計です。

Metadata Filterも重要

Similarityだけで結果を返すと危険な場合があります。

会社の全DocumentをEmbedding化していても、あるUserが閲覧権限のない資料を取得してはいけません。

そこで、

• User / Tenant ID
• Language
• Document Type
• Date
• Permission
• Product Category

などのMetadata FilterとVector Similarityを組み合わせます。

一件のRecordには何を持つ？

典型的には、

• Vector
• 元Text、またはそのPointer
• Document ID
• Chunk番号
• Metadata
• PermissionやTimestamp

などを保存します。

Queryが来たらQuery Embeddingを作り、近いRecordを取り出します。

普通のDatabaseを置き換えるものではない

Account残高、Transaction、正確なJoinなどにはRelational Databaseが重要です。

Vector Databaseが得意なのはSimilarity Retrievalです。

実際のアプリではSQL DatabaseとVector Searchを一緒に使うことがよくあります。

RAGとの関係

よくある流れは、

1. DocumentをChunkへ分割
2. Embeddingを作る
3. Vector Databaseへ保存
4. User QuestionもEmbedding化
5. 近いChunkを検索
6. そのChunkをLLMへ渡す

です。

これは次の第023回で扱う**Retrieval-Augmented Generation (RAG)**の基本構成です。

今日の一文

Vector DatabaseはEmbeddingを保存し、Query Vectorに近い情報を高速に探すためのDatabaseです。