ベクトルデータベース比較：Weaviate、Milvus、Qdrant
TimRAGシステムの成功は、大量の情報を効率的に取得し処理する能力に大きく依存しています。ベクトルデータベースはその中で不可欠な役割を果たし、RAGシステムのコアを構成しています。ベクトルデータベースは、高次元ベクトルデータを保存および管理するために特化されており、テキスト、画像、音声、さらにはビデオをベクトルに変換して保存することができます（この点については後述します）。RAGシステムが最終的に実現できる効果は、これらの基盤となるベクトルデータベースのパフォーマンスに依存しています。
多くのベクトルデータベースとベクトルライブラリの中で、それぞれが独自の特徴を持っており、自分のアプリケーションシナリオに適したものを選ぶには評価が必要です。本稿では、RAGにベクトルデータベースを選択する際に考慮すべき重要な要素について深く掘り下げます。これには、オープンソースの可用性、CRUD（作成、読み取り、更新、削除）サポート、分散アーキテクチャ、レプリカサポート、スケーラビリティ、パフォーマンス、継続的なメンテナンスなどの6つの側面が含まれます。
現在、Weaviate、Milvus、Qdrant、Vespa、Pineconeのようなベクトル専用に設計されたデータベースが業界で非常に注目されています。それに加えて、誕生が早いベクトルライブラリもこの機能を持っています。本文では、FAISS、HNSWLib、ANNOYのようなベクトルライブラリ、およびpgvectorやSupabaseなどのベクトル機能をサポートするSQLデータベースも比較します。
1 ベクトルライブラリ（FAISS、HNSWLib、ANNOY）
ベクトルデータベースとベクトルライブラリの違いは、ベクトルライブラリが主に静的データの保存に使用される点です。これらのライブラリでは、インデックスデータは不変です。これは、ベクトルライブラリがベクトル埋め込みのみを保存し、これらのベクトル埋め込みを生成する関連オブジェクトを保存しないためです。したがって、ベクトルデータベースとは異なり、ベクトルライブラリはCRUD（作成、読み取り、更新、削除）操作をサポートしていません。これは、FAISSやANNOYのようなベクトルライブラリで既存のインデックスに新しいドキュメントを追加するのが難しい可能性があることを意味します。HNSWLibはこの例外であり、CRUD機能を持ち、同時読み書き操作を独自にサポートしています。しかし、それもベクトルライブラリとしての制限を逃れることはできず、デプロイメントエコシステム、インスタンスのレプリケーション能力、およびフォールトトレランスを提供しません。
2 全文検索データベース（ElasticSearch、OpenSearch）
全文検索データベース（例えばElasticSearchやOpenSearch）は、比較的包括的なテキスト検索と高度な分析機能をサポートしています。しかし、ベクトル類似性検索を実行し高次元データを処理する際には、専用のベクトルデータベースに比べて強力ではありません。これらのデータベースは、主にインバーテッドインデックスに依存しており、ベクトルインデックスではないため、セマンティック検索を実現するためには他のツールと組み合わせて使用する必要があります。Qdrantのテスト結果によると、ElasticsearchはWeaviate、Milvus、Qdrantなどのベクトルデータベースと比較してパフォーマンスが劣っています。
3 ベクトルをサポートするSQLデータベース（pgvector、Supabase、StarRocks）
pgvectorのようなSQLデータベースは、ベクトルサポート拡張を通じて、ベクトルデータを既存のデータストレージシステムに統合する方法を提供しますが、専用のベクトルデータベースと比較して、いくつかの明らかな欠点もあります。
最も明らかな欠点は、従来のSQLデータベースのリレーショナルモデルと非構造化ベクトルデータの本質との間に不一致があることです。この不一致は、ベクトル類似性検索を含む操作の効率を低下させ、この種のデータベースは大量のベクトルデータを処理する際のパフォーマンスが理想的ではありません。詳細はANNテストを参照してください。さらに、pgvectorがサポートするベクトル次元の上限（2000次元）は、Weaviateのような専用ベクトルデータベースと比較して低く、後者は最大65535次元のベクトルデータを処理できます。スケーラビリティと効率の面で、専用ベクトルデータベースはより優れています。ベクトルをサポートするSQLデータベース拡張、例えばpgvectorは、ベクトルデータ量が少ない（10万ベクトル未満）で、ベクトルデータがアプリケーションの補完機能としてのみ使用されるシナリオに適しています。逆に、ベクトルデータがアプリケーションのコアである場合や、スケーラビリティに高い要求がある場合、専用ベクトルデータベースがより適した選択となります。
StarRocksについては、SQLフレームワーク上で動作する別のシステムであり、オンライン分析処理（OLAP）およびオンライントランザクション処理（OLTP）シナリオに最適化されていますが、ベクトル類似性検索に特化して最適化されているわけではありません。
4 ベクトルをサポートするNoSQLデータベース（Redis、MongoDB）
NoSQLデータベースに新たに追加されたベクトルサポート機能はまだ初期段階にあり、十分なテスト検証を経ていません。Redisベクトル類似性検索（VSS）を例にとると、この機能は2022年4月に公開され、まだ2年未満です。Redis VSSは多機能データベースとしてサービスを提供できますが、ベクトル類似性検索に最適化された設計ではありません。
5 専用ベクトルデータベース（Pinecone、Milvus、Weaviate、Qdrant、Vald、Chroma、Vespa、Vearch）
専用ベクトルデータベースは、ドット積、コサイン類似度など、さまざまなベクトル演算をネイティブにサポートしています。これらのデータベースは高次元データを処理するために設計されており、大量のクエリ要求に対応し、ベクトル間の類似性検索を迅速に完了することができます。これらの目標を達成するために、通常は近似最近傍（ANN）アルゴリズムに基づいた多様なインデックス戦略を採用しています。これらのアルゴリズムは、効率、ストレージスペースの占有、および検索の正確性の間でトレードオフを必要とします。たとえば、FLATインデックスは、最適化や近似技術を使用しないベクトルインデックスであり、100％のリコール率と精度を実現できますが、他のタイプのベクトルインデックスよりも遅く、効率が低いです。相対的に、IVF_FLATインデックスは、いくつかの精度を犠牲にして、より高速な検索速度を実現します。HNSWインデックスは、精度と検索速度の間で妥協案を提供します。
Pineconeは、プロフェッショナルチームによって維持されるクローズドソースのベクトルデータベースであり、無料版ではスケーラビリティの面で限られた機能を提供しています。Chromaは音声データ専用に設計されたシステムですが、テキストデータの処理に特別な最適化は行われていません。他の主流のベクトルデータベースと比較して、Chromaの総合的なパフォーマンスベンチマークの資料は比較的少ないです。Chromaは0.4バージョンでSQLiteをドキュメントストレージ方式として採用しているため、スケーラビリティと効率の面で、他のベクトルデータ専用に設計されたストレージソリューションに劣る可能性があります。
VearchとValdは、Langchainとの統合において不足しており、開発の使用にとって非常に不利です。Milvusなどの競合他社と比較して、開発者コミュニティの規模が小さく、オープンソースコミュニティのメンテナンスも活発ではありません。
したがって、RAGにとって、Weaviate、Milvus、Qdrant、Vespaは最良の選択肢かもしれません。理論的には、パフォーマンスとスケーラビリティのベンチマークテスト（下記のANNベンチマークを参照）に基づいて最適なシステムを選択する必要があります。しかし、システム設計や機能の特徴も比較する必要があります。以下の表は、これらの側面から視覚的に比較しています。
| データベース | Qdrant | Weaviate | Milvus |
|---|---|---|---|
| オープンソースで自ホスティング可能 | ✅ | ✅ | ✅ |
| オープンソースライセンス | Apache-2.0 | BSD | Apache-2.0 |
| 開発言語 | Rust | Go | Go, C++ |
| Github Stars | 17k | 9.2k | 26.2k |
| 初回リリース日 | 2021 | 2019 | 2019 |
| SDK | Python, JS, Go, Java, .Net, Rust | Python, JS, Java, Go | Python, Java, JS, Go |
| クラウドサービス | ✅ | ✅ | ✅ |
| 内蔵テキスト埋め込み | ✅FastEmbed | ✅ | ❌ |
| ハイブリッド検索 | ❌ | ✅RRF*+RSF* | ✅表内多ベクトルハイブリッド |
| メタ情報フィルタリング | ✅ | ✅ | ✅ |
| BM25サポート | ❌ | ✅ | ✅ |
| テキスト検索 | ✅ | ✅ | ❌ |
| 単一ポイント多ベクトル | ✅ | ✅ | |
| テンソル検索 | ❌ | ❌ | ❌ |
| Langchain統合 | ✅ | ✅ | ✅ |
| Llamaインデックス統合 | ✅ | ✅ | ✅ |
| Geo地理情報検索 | ✅ | ✅ | ❌ |
| マルチテナントサポート | ✅コレクション/メタデータを通じて | ✅ | |
| メタ情報とドキュメントサイズ制限 | 無制限 | ||
| 最大次元 | 無制限 | 65535 | 32768 |
| インデックスタイプ | HNSW | HNSW | ANNOY, FAISS, HNSW, ScANN … |
| ストリーミングインデックス | ❌ | ||
| スパースベクトルサポート | ❌ | ❌ | ❌ |
| 一時インデックスサポート（サーバーを含まない） | ✅ | ❌ | |
| シャード | |||
| 価格 | |||
| Facets（カウント付き集計） | ❌ | ✅ | |
| 内蔵画像埋め込み | ✅ | ||
| 推奨API | ✅ | ||
| パーソナライズ | |||
| ユーザーイベント | |||
| 内蔵LLMをRAGに使用 | ✅Generative Search |
| データベース | Qdrant | Weaviate | Milvus |
|---|---|---|---|
| 主観的な利点 | 1. 1つのコレクションに複数のベクトル（画像、テキストなど）を保存できる 2. リソース消費が非常に少ない |
1. パフォーマンスが比較的良い 2. 内蔵埋め込みをサポート 3. テキスト検索をサポート 4. GraphQL API 5. S3バックアップをサポート |
1. 公式サポートの視覚的操作インターフェース 2. 高い検索精度 3. 豊富なSDK 4. GPUアクセラレーション |
要約すると、Qdrantは非常に小さなオーバーヘッドで、Weaviateはベクトル検索、オブジェクトストレージ、インバーテッドインデックスの組み合わせをサポートし、Milvusは最も強力なパフォーマンスと多くの機能を持っています。
6 ベクトルデータベースの検索方法の比較
| Milvus | Weaviate | Qdrant | |
|---|---|---|---|
| 独自の検索方法 | 多ベクトル検索 | BM25キーワード検索+ハイブリッド検索 | キーワードフィルタリングをベクトル検索に適用 |
6.1 Milvus
Milvusは、コレクション内のベクトルフィールドの数に応じて、2種類の検索をサポートしています：単一ベクトル検索と多ベクトル検索。
単一ベクトル検索は、search()メソッドを使用して、クエリベクトルとコレクション内の既存のベクトルを比較し、最も類似したエンティティのIDとその間の距離を返します。また、結果のベクトル値とメタデータをオプションで返すこともできます。
多ベクトル検索は、2つ以上のベクトルフィールドを持つコレクションに適しており、hybrid_search()メソッドを使用して実行されます。このメソッドは、複数の近似最近傍（ANN）検索リクエストを実行し、結果を再ランキングして最も関連性の高い一致を返します。（最新の2.4.xバージョンでサポートされ、最大10個のベクトル検索が可能です）
多ベクトル検索は、高精度が必要な複雑な状況に非常に適しており、特に1つのエンティティが複数の異なるベクトルで表現できる場合に役立ちます。これは、同じデータ（例えば1つの文）が異なる埋め込みモデルで処理される場合や、多モーダル情報（例えば個人の画像、指紋、声紋）がさまざまなベクトル形式に変換される場合に適しています。テーブル全体の「マルチウェイリコール」を通じて、これらのベクトルに重みを割り当てることで、それらの総合的な効果がリコール能力を大幅に向上させ、検索結果の有効性を高めることができます。
その他の基本的な検索操作：
- 基本検索には、単一ベクトル検索、バッチベクトル検索、パーティション検索、指定された出力フィールドを持つ検索が含まれます。
- フィルタ検索は、スカラーフィールドのフィルタ条件に基づいて検索結果を絞り込みます。
- 範囲検索は、クエリベクトルと特定の距離範囲内のベクトルを見つけます。
- グループ検索は、特定のフィールドに基づいて検索結果をグループ化し、結果の多様性を確保します。
6.2 Weaviate
- ベクトル類似度検索：一連の近似検索方法をカバーし、この種の検索はクエリベクトル表現に最も類似したオブジェクトを探します。
- 画像検索：画像を類似度検索の入力として使用します。
- キーワード検索：BM25Fアルゴリズムを使用して結果をランク付けするキーワード検索。
- ハイブリッド検索：BM25と類似度検索を組み合わせて結果をランク付けします。
- 生成的検索：検索結果をLLMのプロンプトとして使用します。
- 再ランキング：検索された検索結果を再ランキングモジュールを使用して再ランキングします。
- 集計：結果セットからデータを集計します。
- フィルタ：検索に条件フィルタを適用します。
6.3 Qdrant
サポートされている基本的な検索操作：
- 関連スコアによるフィルタリング
- 単一リクエストで複数の検索操作をロード
- 推奨API
- グループ操作
Qdrantがサポートするその他の検索方法：
Qdrantはまずベクトル検索エンジンであり、ベクトル検索ユースケースに影響を与えない場合にのみ全文サポートを実装します。これにはインターフェースとパフォーマンスが含まれます。
Qdrantができること：
- 全文フィルタを使用して検索
- 全文フィルタをベクトル検索に適用する（つまり、特定の単語やフレーズを含むレコードでベクトル検索を実行する）
- プレフィックス検索とセマンティックインスタント検索を行う
Qdrantが将来導入する予定の機能：
- SPLADEや類似モデルで使用されるスパースベクトルのサポート
Qdrantがサポートする予定のない機能：
- BM25または他の非ベクトルベースの検索またはランキング関数
- 組み込みのオントロジーまたは知識グラフ
- クエリアナライザーやその他のNLPツール
- 関連性スコアリング：
- 単純なキーワード検索は通常、単語の頻度に基づいています：単語がドキュメントに出現する場合、そのドキュメントは関連していると見なされます。この方法は、キーワードの出現回数を計算するだけで、すべてのキーワードが同等に重要と見なされるかもしれません。
- BM25は、より複雑なアルゴリズムを採用しており、単語の頻度だけでなく、ドキュメントの長さや単語の逆文書頻度（すなわち、すべてのドキュメントでの希少性）も考慮します。これにより、BM25はより精緻な関連性スコアを提供し、クエリとドキュメントの一致度をよりよく反映します。
- ドキュメントの長さの処理：
- 単純なキーワード検索は、ドキュメントの長さを考慮しないかもしれません。これにより、より長いドキュメント（より多くの単語を含む）が優先される可能性があります。
- BM25は、そのアルゴリズム内部の標準化プロセスを通じてドキュメントの長さを考慮し、このような偏りを避け、長短のドキュメントが関連性スコアリングで公平になるようにします。
- クエリ単語の重要性：
- 単純なキーワード検索では、すべてのキーワードが等しく扱われるかもしれません。
- BM25は、逆文書頻度（IDF）を利用して、各クエリ単語の重要性を調整します。これにより、より少ないドキュメントに出現する単語（よりユニークな単語）がドキュメントの関連性スコアにより大きな影響を与えます。
- パラメータ調整：
- 単純なキーワード検索には、検索結果を最適化するための設定可能なパラメータがほとんどありません。
- BM25は、アルゴリズムの感度を微調整するためのパラメータ（例：k1とb）を提供し、異なるタイプのテキストや検索ニーズに適応させることができます。
単純なキーワード検索と比較して、BM25はドキュメントとクエリ間の関連性を評価するためのより複雑で精緻な方法を提供し、より正確でユーザーの期待に合った検索結果を生成できます。
現在のところ、ベクトルデータベースのセマンティック検索特性と、従来のキーワード検索の正確な特性を両立させる方法があるかどうかが課題です。
7 付録
7.1 ANNベンチマーク
ベンチマークは、検索タイプ（フィルタ検索または通常検索）、設定、インデックスアルゴリズム、データ埋め込み、ハードウェアなど、データベースのパフォーマンスに影響を与えるさまざまな要因によって影響を受けます。ベンチマークのパフォーマンスに加えて、ベクトルライブラリを選択する際には、分散能力、メモリレプリカとキャッシュのサポート、採用されているインデックスアルゴリズム、ベクトル類似性検索の能力（ハイブリッド検索、フィルタリング、およびさまざまな類似性メトリックを含む）、シャーディングメカニズム、クラスター方法、スケーラビリティの可能性、データの一貫性、およびシステムの全体的な可用性など、複数の側面を考慮する必要があります。
ANN-Benchmarks は、近似最近傍アルゴリズムの検索パフォーマンスを評価する主要なベンチマークプラットフォームです。テキスト検索では、ベクトルデータベースの角度メトリックでのパフォーマンスは、ユークリッドメトリックでのパフォーマンスよりも重要です。これは、角度メトリックが文書のセマンティック類似性に対してより敏感であり、ユークリッドメトリックが文書の長さと規模に対してより敏感であるためです。したがって、生成されたコンテキストの検索を強化する際には、異なる次元を超えた角度データセットでのベクトルデータベースのパフォーマンスを評価することに焦点を当てる必要があります。
7.1.1 glove-100-angular
7.1.2 nytimes-256-angular
7.2 ベクトル類似度指標
| 指標 | 説明 | サポートされているデータベース |
|---|---|---|
| コサイン距離 | 2つのベクトル間の角度のコサイン値を測定 | pgvector, Pinecone, Weaviate, Qdrant, Milvus, Vespa |
| ユークリッド距離（L2） | 多次元空間で2つのベクトル間の直線距離を計算 | pgvector, Pinecone, Qdrant, Milvus, Vespa |
| 内積（ドット積） | ベクトルの対応する成分の積の和を計算 | pgvector, Pinecone, Weaviate, Qdrant, Milvus |
| L2平方距離 | 2つのベクトル間のユークリッド距離の平方 | Weaviate |
| ハミング距離 | 各次元でベクトル間の差異数を測定 | Weaviate, Milvus, Vespa |
| マンハッタン距離 | 直角軸に沿って2つのベクトル次元間の距離を測定 | Weaviate |
以下は、各指標の詳細な紹介であり、それらの相対的な利点、欠点、およびそれらが適した使用シナリオを含んでいます。
7.2.1 コサイン距離
コサイン距離は、2つのベクトル間の角度のコサイン値を測定し、正規化または凸集合を処理する際によく使用されます。
- 利点：主にベクトルの方向を考慮し、高次元空間（例えばテキストの比較）に非常に適しています。テキストの比較では、文書の長さがそれほど重要ではありません。
- 欠点：ベクトル次元の一致が必要なシナリオには適していません。例えば、ピクセル密度に基づいて画像の埋め込みを比較する場合です。データが凸集合を形成していない場合、正確な類似性メトリックを提供できない可能性があります。
コサイン距離は、文書分類、セマンティック検索、推薦システム、および高次元データと標準化データを含むその他のタスクに適しています。情報を検索する際には、コサイン距離はクエリコンテンツと文書ベクトル間の類似性を測定するために使用され、長さを無視し、セマンティックな意味に焦点を当てます。
7.2.2 ユークリッド距離 L2
ユークリッド距離は、多次元空間で2つのベクトル間の直線距離を計算し、二乗ノルムとも呼ばれます。
- 利点：直感的で計算が容易であり、ベクトルの大きさと方向の両方に敏感です。
- 欠点：「次元の呪い」により、高次元空間でのパフォーマンスが低下する可能性があります。
画像認識、音声認識、手書き分析などのシナリオに適しています。
7.2.3 内積
内積は、ベクトルの対応する成分の積の和を計算し、n乗ノルムとも呼ばれます。
- 利点：計算速度が速く、ベクトルの大きさと方向を反映します。
- 欠点：ベクトルの方向に敏感であるだけでなく、ベクトルの大きさにも敏感です。
内積の最も古典的な応用は、推薦システムの分野です。推薦システムでは、内積を使用してユーザーベクトルとアイテムベクトル間の類似度を決定し、ユーザーが特定のアイテムに対して持つ興味を予測するのに役立ちます。内積は、推薦システム、協調フィルタリング、行列分解に適しています。
7.2.4 L2平方距離
2つのベクトル間のユークリッド距離の平方。
- 利点：ベクトル要素間の大きな差異を罰することができ、特定の状況で役立つ可能性があります。
- 欠点：平方操作が距離を歪める可能性があり、外れ値に敏感です。
L2平方距離は、特定の次元の差異の問題に特に適しており、例えば画像処理で2つの画像の違いを比較する際に使用されます。
7.2.5 ハミング距離
各次元でベクトル間の差異数を測定します。
- 利点：バイナリまたは分類データの比較に適しています。
- 欠点：連続または数値データには適していません。
適用シナリオも比較的特殊であり、例えばエラー検出と修正（分類データ）や、2つのDNA鎖間の遺伝的距離を測定する際に使用されます。
7.2.6 マンハッタン距離 L1
直角軸に沿って2つのベクトル次元間の距離を測定し、一乗ノルムとも呼ばれます。
- 利点：ユークリッド距離よりも外れ値に対して耐性があります。
- 欠点：幾何学的な意味ではユークリッド距離ほど直感的ではありません。
チェスボード距離の計算や、物流計画における最短経路問題に適しています。
8 参考資料
支付宝
贝宝
微信