ベクトルデータベースの深さ比較：Weaviate、Milvus、Qdrant

人工知能や機械学習の分野では、特にRAG（Retrieval Augmented Generation）システムやセマンティック検索などのアプリケーションを構築する際、膨大な量の非構造化データを効率的に処理・検索することが極めて重要になる。ベクターデータベースは、この課題に対処するための中核技術として登場した。ベクターデータベースは、高次元のベクターデータを格納するための特殊なデータベースであるだけでなく、次世代のAIアプリケーションを推進するための重要なインフラストラクチャでもある。

本記事では、ベクターデータベースの概念、原理、適用シナリオについて解説し、現在主流のオープンソースベクターデータベースWeaviate、Milvus、Qdrantを比較・分析します。ベクターデータベースの包括的かつ詳細なガイドを読者に提供することで、ベクターデータベースの価値を理解し、実際のプロジェクトにおいて十分な情報に基づいた技術的選択を行うことを目的としています。

ベクターデータベースとは？従来のデータベースからベクトル検索へ

ベクトルデータベースの特徴を理解するためには、まずベクトルとは何か、そしてベクトルデータを扱うときに従来のデータベースが圧倒されるのはなぜかを理解する必要がある。

ベクトル：データの数学的表現

簡単に言えば、ベクトルとはデータの特徴や属性を表現するための数学的な道具であり、多次元空間における点と見なすことができる。ベクトルデータベースのコンテキストでは、通常高次元ベクトルつまり、これらのベクトルは、データの複雑さと必要とされる表現の粒度によって、数十次元から数千次元に及ぶ多数の次元を持つことになる。

ベクトル埋め込み：非構造化データの構造化表現

では、この高次元ベクトルはどのようにして生成されるのだろうか？答えは組み込み機能生の非構造化データ（テキスト、画像、音声、ビデオなど）をベクトルに変換する。この変換プロセスはベクトル埋め込み機械学習モデル、単語埋め込み技術、特徴抽出アルゴリズムなどの手法を用いて、データの意味情報や特徴をコンパクトなベクトル空間に圧縮する。

例えば、テキストデータの場合、Word2Vec、GloVe、FastText、または変換モデル（BERT、Sentence-BERTなど）のような技術を使用して、各単語、文、または記事全体をベクトルに変換することができます。ベクトル空間では、意味的に類似しているテキストは、ベクトルが近くなります。

ベクトルデータベースの核となる強み：類似性検索

リレーショナル・データベース（PostgreSQL、MySQLなど）やNoSQLデータベース（MongoDB、Redisなど）といった従来のデータベースは、主に構造化または半構造化データの格納とクエリ用に設計されており、完全一致や事前に定義された条件に基づくデータ検索を得意としている。しかし、データ検索に関しては意味類似性もしかしたら文脈上の意味データの検索は、従来のデータベースを非効率なものにしている。

このギャップを埋めるために登場したのがベクターデータベースである。その核となる強みはベクトル距離や類似度に基づく類似検索・取得を効率的に行う。.つまり、完全なキーワードマッチングを行わなくても、意味的または特徴的な類似性に基づいてデータを見つけることができる。

ベクトル・データベースと従来のデータベースの主な違い

ベクターデータベースの独自性をより明確に理解するために、従来のデータベースとの主な違いを以下にまとめる：

ベクトルデータベースの価値：AIアプリケーションの礎石

ベクターデータベースは、人工知能や機械学習の分野、特に以下の分野でますます重要な役割を果たしている：

• 次世代検索エンジン： ユーザーのクエリの意図を理解し、キーワードのマッチングだけでなく、より関連性の高い、文脈に沿った検索結果を返すために、セマンティック検索を実装する。
• 知的推薦システム： ユーザーの過去の行動やアイテムの特性に基づいてパーソナライズされたレコメンデーションを行い、レコメンデーションの精度とユーザーエクスペリエンスを向上。
• 大規模言語モデリング（LLM）アプリケーション： LLMに長期記憶と効率的な文脈検索機能を提供し、より強力なチャットボット、Q&Aシステム、コンテンツ生成アプリケーションの構築をサポートする。
• マルチモーダルなデータ検索： クロスモーダルな類似性検索を可能にする。例えば、テキスト記述によって関連する画像や動画を検索することができる。

要約すると、ベクトル・データベースはAI時代の非構造化データを処理・検索するための重要なインフラであり、機械に意味論を理解させ、類似性を推論させることで、数多くの革新的なAIアプリケーションを推進する。

ベクターデータベースとRAG：強力な検索機能拡張生成システムの構築

RAG（Retrieval-Augmented Generation）システムは現在、大規模言語モデリングの応用分野で人気のある方向性である。RAGの中核となる考え方は、テキストを生成する前に外部の知識ベースから関連情報を検索し、検索された情報をコンテキストとして使用して、より正確で信頼性の高い回答を生成するように言語モデルを導くことである。

RAGシステムにおけるベクター・データベースの中心的役割

RAGシステムでは、ベクター・データベースが以下の役割を果たす。リポジトリRAGシステムは、膨大な知識文書のベクトル表現を保存し、効率的に検索する役割を担っている。RAGシステムのワークフローは、おおよそ次のようなものである：

1. 知識ベースの構築：
   • 知識文書（テキスト、ウェブページ、PDFなど）のベクトル表現への埋め込み。
   • これらのベクトルと対応する文書のメタデータをベクトルデータベースに格納する。
2. 問い合わせの検索
   • ユーザークエリを受け取り、クエリをベクトル埋め込みしてクエリベクトルを得る。
   • クエリベクトルを用いてベクトルデータベース内で類似度検索を行い、クエリベクトルに最も類似した文書ベクトルを検索する。
   • 検索された文書ベクトルに対応するオリジナル文書または文書断片を取得する。
3. テキスト生成：
   • 検索された文書断片は、ユーザークエリとともにコンテキストとして大規模言語モデル（LLM）に入力される。
   • LLMは文脈情報に基づいて最終的な回答や文章を生成する。

Milvusによる画像の意味検索

なぜベクターデータベースはRAGシステムに最適なのか？

• 効率的な意味検索機能： ベクトル・データベースは、意味的な類似性に基づいて文書を検索することができるため、ユーザーのクエリに関連する文脈情報を知識ベースから見つける必要のあるRAGシステムには完璧にマッチする。
• 膨大な知識ファイルを扱う RAGシステムは通常、大量の知識文書を扱う必要があり、ベクトル・データベースは膨大なベクトル・データを効率的に格納・検索できるため、RAGシステムのスケーラビリティ要件を満たすことができる。
• ユーザーからの問い合わせへの迅速な対応： ベクトル・データベースの類似性検索は非常に高速で、RAGシステムはユーザーからの問い合わせに迅速に対応できる。

ベクトル・データベースの選択：RAGシステムにおける重要な決定事項

適切なベクターデータベースを選択することは、RAGシステムのパフォーマンスと有効性にとって非常に重要です。ベクターデータベースは性能、機能、使いやすさの点でそれぞれ異なります。以下の章では、ベクターデータベースの選択要素について説明し、Weaviate、Milvus、Qdrantの3つの優れたオープンソースベクターデータベースを比較・分析することで、RAGシステムに最適な礎を選択するお手伝いをします。

ベクターデータベースの選択：性能だけでなく、これらの重要な要素に注目する

具体的な製品の比較に入る前に、ベクター・データベースを選択する際の核となる懸念事項を確認しておこう。これらの要素は、構築するRAGシステムやAIアプリケーションのパフォーマンス、スケーラビリティ、安定性、コストに直接影響します。

1.オープンソース対商業化：自主性対使いやすさ

• オープンソースのベクトルデータベース（Milvus、Weaviate、Qdrant、Vespaなど）：
  • アドバンテージだ： 自由なカスタマイズや二次開発を可能にする高い自律性と柔軟性、データ・セキュリティやシステム・アーキテクチャのより良い管理。活発なオープンソースコミュニティに支えられ、迅速な反復と迅速な問題解決が可能。通常、低コストまたは無料で使用できる。
  • チャレンジだ： 配備、運用・保守、トラブルシューティングには、ある程度の技術的スキルが必要である。商業的なサポートは比較的弱く、地域社会への依存や自発的な問題解決が必要となる場合がある。
  • 適用されるシナリオ 高度な自律性とコントロールを必要とし、技術チームに支えられ、コスト削減を望み、コミュニティの共同制作に積極的に参加できるプロジェクト。
• 市販のベクターデータベース（例えば、Pineconeなどのクラウドプロバイダーによるホスト型ベクターデータベース）：
  • アドバンテージだ： 通常、完全なマネージド・サービスとテクニカル・サポートを提供し、導入とO&Mの複雑さを簡素化し、開始と利用が簡単です。パフォーマンスと安定性は商業的に証明されており、サービス品質も保証されています。
  • チャレンジだ： コストが高く、長期的に多額の費用が発生する可能性がある。ベンダーロックインの可能性、カスタマイズの制限、二次開発のリスク。
  • 適用されるシナリオ 使いやすさと安定性を求めているプロジェクト、早く始めたいプロジェクト、O&Mの負担を減らしたいプロジェクト、予算に余裕があるプロジェクト、ベンダーのロックインリスクに敏感でないプロジェクト。

2.CRUDのサポート：動的データと静的データ

• CRUD（作成、読み取り、更新、削除）のサポート：
  • 重要だ： RAGシステムや多くのダイナミック・データ・アプリケーションには欠かせない。データを頻繁に更新、削除、修正する必要がある場合は、完全なCRUD操作をサポートするベクターデータベースを選択することが重要です。
  • インパクトがある： CRUD操作をサポートするデータベースは、動的に変化するデータの管理を容易にし、ナレッジベースをリアルタイムかつ正確に保ちます。
• 静的データシナリオ：
  • 需要だ： 構築済みのナレッジベースのようにデータが静的で、データの更新頻度が非常に低い場合は、読み取り専用のベクター・ライブラリや、完全なCRUDをサポートしないデータベースも適しているかもしれない。
  • 選択する： この場合、軽量なベクトルライブラリや、データ更新機能が弱く高性能な検索に特化したベクトルデータベースなどが考えられる。

3.分散アーキテクチャとスケーラビリティ：膨大なデータと高い並行性への対応

• 分散アーキテクチャ：
  • 必要性： RAGシステムや多くのAIアプリケーションは、通常、大量のデータと高度な同時リクエストを処理する必要がある。分散アーキテクチャは、このような課題に対応するための鍵となる。
  • アドバンテージだ： 分散ベクターデータベースは、複数のサーバーに分散したデータを格納し、並列クエリをサポートすることで、データ処理能力とクエリ性能を向上させることができる。
• スケーラビリティ：
  • 水平展開： 優れたベクターデータベースは、データ量とリクエストの増加に対応するためにノードを追加することで、簡単に水平方向に拡張できるはずだ。
  • 伸縮性のあるストレッチ： コストとパフォーマンスを最適化するために、実際の負荷に基づいてリソースを動的に調整するエラスティックなスケーリングをサポートすることが望ましい。

4.データレプリケーションと高可用性：データセキュリティとサービスの安定性を保証する

• データコピー：
  • 役割 データコピーの仕組みは、データの安全性とシステムの高い可用性を確保するための重要な手段である。
  • 実現： データの同一コピーを複数のサーバーに保存することで、一部のノードに障害が発生しても、システムはデータを失うことなく正常に稼働し続ける。
• 高可用性：
  • 重要だ： 高可用性は、高いサービス安定性を必要とするRAGシステムやオンライン・アプリケーションにとって極めて重要である。
  • セーフガード： データコピー、自動故障転送、モニタリングとアラームなどのメカニズムが連動し、システムの継続的で安定した運用を保証する。

5.パフォーマンス：検索速度と精度

• 待ち時間：
  • 指標： クエリーレイテンシー、すなわちクエリーを開始してから結果を得るまでの時間。
  • 影響を及ぼす要因： インデックス作成アルゴリズム、ハードウェアリソース、データサイズ、クエリの複雑さなど。
  • 需要だ： リアルタイム性が要求されるアプリケーションでは、検索速度の速いベクトルデータベースを選択する必要がある。
• リコール、プレシジョン：
  • 指標： RecallとPrecisionは、類似検索結果の精度を測定する。
  • 計量： 通常、検索速度と精度はトレードオフの関係にあり、アプリケーションのシナリオに応じて適切なバランスを選択する必要がある。例えば、RAGシステムの場合、可能な限り多くの関連文書が検索されるようにするため、リコールの方が重要かもしれない。

6.継続的なメンテナンスと地域社会の支援：長期的な安定運営の保証

• 継続的なメンテナンス：
  • 重要だ： ベクター・データベース技術は急速に進化しており、継続的なメンテナンスとアップデートが重要です。
  • 気になる点 データベースがアクティブな開発チームによって継続的に保守・更新され、タイムリーにバグを修正し、最新の技術動向に対応しているかどうか。
• 地域社会の支援：
  • 価値がある： 活発なコミュニティは、豊富なドキュメント、チュートリアル、サンプルコード、質問への回答を提供し、学習と使用の障壁を下げる。
  • 評価だ： コミュニティ・サポートは、GitHubリポジトリでの活動、コミュニティ・フォーラムでの話題、ユーザー数などのメトリクスを見ることで評価できる。

7.コストに関する考察：オープンソースと商業化、セルフビルドとホスティング。

• オープンソースと商業化のコスト比較：
  • オープンソース： データベース・ソフトウェア自体は無料だが、ハードウェア・コスト、O&Mコスト、人件費などを考慮しなければならない。
  • 商業化： ソフトウェアのライセンス料やクラウドサービスの利用料がかかるが、O&Mコストの削減や技術サポートの充実が期待できる。
• セルフビルドとホスティングのコスト比較：
  • セルフビルド： ハードウェアの調達、配備、運用・保守、監視などに責任を持つ必要があり、初期投資と長期的な運用・保守コストがかさむ。
  • ホスティング： クラウドプロバイダーが提供するホスト型ベクターデータベースサービスを利用すれば、基盤となるインフラを気にする必要がなく、従量課金制で、より柔軟なコスト構造を持つが、長期的に利用すると割高になる可能性がある。

合成：

ベクトルデータベースの選択においては、上記の7つの重要な要素を考慮し、特定のアプリケーションシナリオ、ニーズ、予算に基づいてトレードオフと選択を行う必要があります。絶対的に最適なデータベースは存在せず、特定のシナリオに最も適したデータベースが存在するだけです。

異なるタイプのベクトルデータベースソリューションの比較：技術選択のパノラマ

市場には数多くのベクターデータベースソリューションがありますが、その種類と特徴を理解することで、選択肢を絞り込み、より早く最適なソリューションを見つけることができます。ベクトルデータベースソリューションを以下の5つのカテゴリーに大別します：

1.ベクトルライブラリ（FAISS、HNSWLib、ANNOY）：軽量インデックス、静的データ高速化ツール

FAISS (Facebook AI Similarity Search)、HNSWLib (Hierarchical Navigable Small World Graphs Library)、ANNOY (Approximate Nearest Neighbors Oh)などのベクター・ライブラリ。Yeah)などのベクター・ライブラリがある。ベクトルインデックスの構築と類似検索のためのソフトウェアライブラリ.これらは通常、スタンドアロンのデータベース・サービスとしてではなく、アプリケーションに組み込まれたライブラリとして実行される。

ゆうせい::

• 高性能： 超高速検索に最適化されたベクトルインデックスと類似検索アルゴリズムに焦点を当てる。
• 軽量だ： リソースのフットプリントが小さく、導入が簡単で、既存のアプリケーションへの統合も容易です。
• 成熟し、安定している： 長期にわたる開発と幅広い応用を経て、この技術は成熟し、信頼性が高く、コミュニティからの支持も厚い。

制限::

• 静的なデータが主流だ： 主に静的データの保存に使用され、インデックス構築後のデータ更新は容易ではない。HNSWLibを除き、ほとんどのベクトルライブラリはCRUD操作をサポートしておらず、データの更新や削除が困難である。
• 機能が制限されている： 通常、基本的なベクトルインデックスと類似検索機能のみを提供し、分散、データコピー、権利管理、監視操作、メンテナンス、およびその他の高度なデータベース機能の欠如。
• 高いO&Mコスト： 独自の展開エコシステムを構築し、データの複製やフォールトトレランスを処理する必要があり、洗練されたO&Mツールや管理インターフェイスがない。

適用シナリオ::

• 静的データセットに対する類似性検索： 例えば、オフラインで構築された知識ベース、商品ベース、顔ベースなど、データの更新頻度が低いシナリオ。
• 非常に高いパフォーマンスが要求されるが、データの更新頻度が低いシナリオ： 例えば、検索エンジンのオフラインインデックス構築や、大規模なレコメンダーシステムのオフライン特徴インデックス作成などがある。
• 他のデータベース用のベクトルインデックス加速コンポーネントとして： 例えば、ベクター・ライブラリーをRedisやMySQLなどのデータベースと併用することで、類似検索が高速化する。

代表的な製品：

• FAISS（Facebook AI類似検索）： Facebook AI Researchによって開発され、学界や産業界で広く利用されている。IVF、PQ、HNSWなど様々な効率的なインデックス作成アルゴリズムを提供し、特に大規模データセットの扱いに優れている。
• HNSWLib (Hierarchical Navigable Small World Graphs Library)： HNSW (Hierarchical Navigable Small World) アルゴリズムをベースとし、その高いパフォーマンスと効率性で知られています。 HNSWLibは、他のベクトルライブラリと比較して、より柔軟で、CRUD操作と並行読み書きをサポートしています。
• ANNOY (Approximate Nearest Neighbors Oh Yeah)： Spotifyによって開発され、高速な近似最近傍探索に焦点を当てている。クリーンで効率的な設計で知られ、遅延の影響を受けやすいアプリケーションシナリオに適しています。

2.全文検索データベース（ElasticSearch、OpenSearch）：ベクトル検索を補完するもの。

ElasticSearchやOpenSearchのような全文検索データベースは、主に次のような目的で使用されるように設計されています。全文検索とキーワード検索これらは転置インデックス技術に基づいており、テキスト検索や高度な分析に威力を発揮する。近年、ベクトル検索機能も追加され始めているが、ベクトル検索は彼らの中核的な強みではない。

ゆうせい::

• 強力な全文検索機能 複雑なテキストクエリ、単語の分割、同義語、スペルチェック、関連性のソート（例 BM25)などの機能がある。
• リッチな分析： データ分析およびビジネス洞察のための集計、統計、レポーティング、データ可視化を提供します。
• 成熟した生態系： 大規模なユーザーベースと確立されたエコシステムがあり、周辺ツールやプラグインが豊富で、統合しやすく使いやすい。

制限::

• ベクトル検索の性能は弱い： 専用のベクトルデータベースと比較すると、ベクトル類似検索の性能は低く、特に高次元データや大規模データセットでは、クエリの待ち時間が長く、精度が不十分な場合がある。
• 資源の消費が多い： 全文検索や分析などの機能をサポートするためには、リソースの消費量が多く、導入や運用・保守のコストがかかる。
• セマンティック検索が苦手： 主にキーワードマッチと転置インデックスに依存しており、意味理解が限られているため、複雑な意味検索のニーズに応えることが難しい。

適用シナリオ::

• キーワード検索が主な用途で、ベクトル検索がそれを補う： 例えば、eコマースサイトの商品検索やニュースサイトの記事検索では、主にキーワード検索が使われており、ベクトル検索は検索の意味的関連性を高めるための補助機能として使われている。
• 全文検索とベクトル検索の組み合わせを必要とするハイブリッド検索シナリオ： 例えば、キーワード検索とセマンティック検索の両方をサポートするインテリジェントなカスタマーサービスシステムは、ユーザーの多様なクエリニーズに対応する。
• ログ分析、アラームの監視など、強力な分析機能を必要とするシナリオ： ログ分析、モニタリング、アラート、セキュリティ監査などに、全文検索データベースの強力な分析機能をご利用ください。

代表製品::

• ElasticSearch： Luceneに基づいて構築され、最も人気のあるオープンソースの全文検索エンジンの一つであり、広く検索、ログ解析、データ可視化などの分野で使用されています。
• オープンサーチ ElasticSearchとKibanaをベースとしたAWSからの分岐で、ElasticSearchとの互換性を維持し、ElasticSearchに新機能と改良を加える。

結論 ElasticSearchとOpenSearchはベクトル検索機能を提供しているが、そのパフォーマンスと機能は専用のベクトルデータベースにはまだ及ばない。ベクトル検索に重点を置くRAGシステムやAIアプリケーションには、専用のベクトルデータベースの方が適している。全文検索データベースは、ベクトル検索の代替というよりは、補完として適している。

3.ベクター対応SQLデータベース（pgvector、Supabase、StarRocks）：従来のデータベースをベクターで拡張し、軽量なアプリケーションに対応。

PostgreSQLのようなSQLデータベースは、拡張機能（pgvectorなど）によってベクトルデータ型と類似検索機能をサポートしています。これにより、ユーザは新しいデータベースシステムを導入することなく、既存のリレーショナルデータベースにベクトルデータを格納し、照会することができます。

ゆうせい::

• 簡単な統合： 既存のSQLデータベースとのシームレスな統合は、技術スタックの複雑さを軽減し、学習と移行のコストを削減します。
• 成熟し、安定している： SQLデータベース技術は成熟し安定しており、強力なデータ管理とトランザクション処理能力を持ち、データの一貫性と信頼性が保証されている。
• 学習コストが低い： SQLに慣れている開発者にとっては、学習コストは低く、ベクトル検索機能をすぐに使い始めることができる。

制限::

• ベクトル検索の性能には限界がある： リレーショナルデータベースはベクトル検索のために設計されたアーキテクチャではないため、特に大規模で高次元のベクトルデータを扱う場合、クエリのレイテンシが高く、専用のベクトルデータベースほどうまく動作しない。
• スケーラビリティには限界がある： リレーショナル・データベースはスケーラビリティが比較的弱いため、膨大なベクトル・データや並行性の高いクエリに対応することが難しく、水平方向のスケーラビリティにも限界がある。
• ベクトル次元の制限： 例えば、pgvectorがサポートするベクトル次元の上限は2000次元であり、これは専用のベクトルデータベースよりも低く、高次元のベクトルデータのニーズを満たすことができない可能性がある。

適用シナリオ::

• ベクトルデータ量が少ないアプリケーション（10万レベル以下）： 例えば、小規模なレコメンダー・システム、単純な画像検索、個人知識ベースなどは、ベクトル・データ量が少なく、要求性能も低い。
• 補助機能としてのベクトルデータの応用： 例えば、eコマースサイトの商品データベースに商品ベクトルフィールドを追加し、商品の推薦や類似商品の検索を行う場合、ベクトル検索はデータベースの補助的な機能に過ぎない。
• すでに成熟したSQLデータベースを持ち、ベクトル検索機能を迅速に追加したいアプリケーション： PostgreSQLのようなSQLデータベースを既に使用していて、ベクトル検索機能を素早く導入したいプロジェクトでは、pgvectorのような拡張機能の使用を検討してください。

代表製品::

• pgvector： Crunchy Dataによって開発されたPostgreSQLの拡張で、ベクトルデータ型（vector）とインデックス（IVF、HNSW）、ベクトル類似度検索機能を提供する。
• スーパーベース PostgreSQLをベースとしたオープンソースのPaaSプラットフォームで、pgvectorが統合されており、ベクトル検索をサポートするアプリケーションを素早く構築することができます。
• スターロックス OLAP指向のMPPデータベースで、ベクトル検索機能も追加されているが、ベクトル検索は中核的なニッチ機能ではなく、主にOLAP分析シナリオで使用される。

結論 pgvectorのようなベクトルをサポートするSQLデータベースは、ベクトルデータの量が少なく、性能要件が高くなく、ベクトルデータがアプリケーションの補完的な機能としてのみ使用されるような軽量なアプリケーションシナリオに適しています。ベクターデータがアプリケーションの中核である場合、またはスケーラビリティに対する要求が高い場合は、専用のベクターデータベースを選択する方が良いでしょう。

4.ベクトル対応NoSQLデータベース（Redis、MongoDB）：可能性と課題の両方を持つ、新たな試み。

RedisやMongoDBのようなNoSQLデータベースも、Redis Vector Similarity Search（VSS）やMongoDB Atlas Vector Searchのようなベクトルサポートを追加する試みを始めており、NoSQLデータベースがベクトルデータも扱えるようになっている。

ゆうせい::

• NoSQLデータベースの本質的な利点： 例えば、高性能なキャッシュ、低レイテンシー、高スループットのRedisや、柔軟なドキュメントモデル、スケーラビリティの容易さ、豊富なドキュメント操作機能のMongoDBなどだ。
• 技術的な新規性： これは、成熟したNoSQLデータベースにベクトル検索機能を組み込んだデータベース技術の発展トレンドを象徴するものであり、一定の革新性と発展性を持っている。

制限::

• 機能はまだ成熟していない： ベクターをサポートする機能はまだ初期段階にあり、機能や性能は改良され検証されるべきであり、エコシステムは比較的未成熟である。
• 貧弱な生態系： 関連するツール、ライブラリ、エコシステムが相対的に少なく、使用や維持にコストがかかり、コミュニティからの支援も相対的に弱い。
• 考慮すべきパフォーマンス Redis VSSは優れた性能を謳っているが、実際の結果はより多くのシナリオで検証する必要があり、高次元データや大規模データセットでは専用のベクトル・データベースほどの性能は発揮できないかもしれない。

適用シナリオ::

• 高性能が要求され、ベクターデータが少量のシナリオ： 例えば、Redisベースのリアルタイム・レコメンダー・システムやオンライン広告検索などでは、低レイテンシーで高スループットのベクトル検索が必要となる。
• 新しい技術を試したいと思っていて、多少のリスクは覚悟しているシナリオ： テクノロジーを試される方は、NoSQLデータベースのベクトルサポート機能を使って、その可能性を探ってみてください。
• すでにNoSQLデータベースを使用しているが、ベクトル検索機能を追加したい： すでにRedisやMongoDBを使用していて、その上にベクトル検索機能を素早く導入したいプロジェクトでは、ベクトル拡張モジュールの使用を検討しよう。

代表製品::

• Redis Vector Similarity Search (VSS)： Redis用のモジュールで、ベクトルインデックス（HNSW）と類似検索機能を提供し、リアルタイムに要求されるシナリオのための高性能と低レイテンシに重点を置いている。
• MongoDBアトラスベクトル検索： MongoDBのクラウドサービスであるAtlasの新機能は、ベクトル検索をMongoDBのドキュメントデータベースに統合し、より包括的なデータ処理機能を提供するように設計されている。

結論 NoSQLデータベースに新たに追加されたベクトルサポート機能は、まだ開発の初期段階にあり、その成熟度と安定性をさらに検証する必要があります。ある程度の可能性はあるものの、機能面や性能面では、専用のベクターデータベースに比べ、成熟度もパワーもまだ劣る可能性がある。その選択は慎重に評価し、その限界を十分に考慮する必要がある。

5.専用ベクターデータベース（Pinecone、Milvus、Weaviate、Qdrant、Vespa、Vald、Chroma、Vearch）：ベクター用に構築されており、RAGシステムやAIアプリケーションの第一候補。

Pinecone、Milvus、Weaviate、Qdrant、Vespa、Vald、Chroma、Vearchなどの専用ベクターデータベースは、ゼロから設計されており、次のような点に焦点を当てている。ベクトルデータの保存、索引付け、検索ベクトルデータは、高次元のベクトルデータを扱うのに適している。RAGシステム、セマンティック検索、レコメンダーシステムなどのAIアプリケーションを構築するのに適したソリューションである。

ゆうせい::

• 優れたベクトル検索性能： ベクトル類似検索のために深く最適化されており、高速検索と高精度を実現し、大規模な高次元ベクトルデータを効率的に扱うことができる。
• 強力なスケーラビリティ： 通常、分散アーキテクチャを採用し、水平方向の拡張が容易で、大規模なアプリケーションのニーズを満たすために、膨大なデータと高い並行性のクエリに対処することができます。
• 豊富な機能性： 通常、完璧なベクトルデータ管理、インデックス構築、クエリ最適化、モニタリング、運用保守機能、さらに豊富な類似検索アルゴリズムと距離メトリックを提供する。
• 柔軟なインデックスオプション： 複数のベクトルインデキシングアルゴリズム（IVF、HNSW、PQ、ツリーインデックスなど）をサポートし、さまざまなアプリケーションシナリオやデータ特性に応じて最適なインデックス戦略を選択できます。
• 成熟したエコシステム（一部の製品）： 製品の中には、活発なコミュニティと確立されたエコシステムがあり、使いやすく統合しやすい豊富なドキュメント、ツール、統合ソリューションを提供しているものもある。

制限::

• 高い学習費： 従来のデータベースに比べ、専用のベクトルデータベースは学習曲線が急で、ベクトルインデックスや類似検索などに関する概念を理解する必要があるかもしれない。
• 技術の選択は複雑だ： さまざまな機能や特徴を持つ製品が数多くあり、その選択には、製品ごとの長所と短所を比較する慎重な評価が必要だ。
• 製品の一部商品化： 専用のベクターデータベースのなかには、商用製品（Pineconeなど）もあるが、使用するには高価で、ベンダーロックインの危険性もある。

適用シナリオ::

• ベクトル検索を中心としたアプリケーション： 例えば、RAGシステム、セマンティック検索、画像検索、音声検索、ビデオ検索、レコメンダーシステム、バイオインフォマティクス分析など、ベクトル検索はアプリケーションの中核機能である。
• 大量の高次元ベクトルデータを扱う必要のあるアプリケーション： 例えば、大規模なナレッジグラフ、膨大な商品ライブラリー、ユーザー行動データ分析などでは、大規模な高次元ベクトルデータの処理が必要となる。
• 検索性能と精度が高度に要求されるアプリケーション： 例えば、財務リスク管理、セキュリティ監視、正確な推薦には、検索スピードと正確性が厳しく要求される。
• 柔軟なスケーラビリティと高可用性を必要とするアプリケーション： 例えば、大規模なオンラインサービスやクラウドプラットフォームでは、サービスの安定性と信頼性を保証するために、水平スケーリングと高可用性をサポートする必要がある。

代表製品::

• 松ぼっくり： 専門家チームによって管理され、使いやすく拡張性の高いベクトル検索サービスを提供する、商用利用可能なクラウドベースのベクトルデータベース。使いやすさとパフォーマンスの高さで知られ、クラウドベースのベクターデータベースを代表する存在。ただし、オープンソースの性質上、カスタマイズには限界があり、無料版では機能が制限されている。
• ミルバス オープンソースの分散型ベクトルデータベースは、Zilliz社が主導し、強力なパフォーマンス、豊富な機能、アクティブなコミュニティは、オープンソースのベクトルデータベースのベンチマークです。様々なインデックスタイプ、距離メトリックとクエリ方法をサポートし、様々なアプリケーションのシナリオに対処するために柔軟であることができます。
• ウィービエイト ドイツのSeMI Technologies社が開発したオープンソースのグラフベクターデータベースは、ベクトル検索とグラフデータベース技術を組み合わせ、独自のデータモデリングとクエリ機能を提供する。GraphQLクエリ言語をサポートし、複雑なデータクエリと分析を容易にします。
• Qdrantです： オープンソースのベクトルデータベース , ロシアのチームによって開発された , Rust言語で書かれた , パフォーマンスと使いやすさに焦点を当てた , 軽量アーキテクチャ , 低リソース消費 .その高いパフォーマンス、低レイテンシとデプロイの容易さで人気があります。
• ベスパ ヤフーとオープンソースの検索エンジンとベクトルデータベースによって開発された、強力な、優れたパフォーマンス、しかし、アーキテクチャは、より複雑で、急な学習曲線です。パフォーマンスと機能のための非常に高い要件を持つシナリオに適しています。
• ヴァルド 日本のチームによって開発されたオープンソースの分散ベクトルデータベース。高精度・低遅延を重視しており、精度が非常に要求されるシーンに適している。ただし、Langchainとの連携に不備があり、コミュニティ規模も小さい。
• ヴェーチェ 中国のチームによって開発されたオープンソースの分散ベクトルデータベースで、高性能で可用性の高いベクトル検索サービスを提供します。使いやすさと拡張性に重点を置いており、ベクトル検索アプリケーションを素早く構築する必要があるプロジェクトに適している。Langchainとの統合に不備があり、コミュニティも小さい。
• クロマ： Chromaはオープンソースの組み込みベクターデータベースで、ドキュメントストアとしてSQLiteを使用し、軽量で使いやすさに重点を置いている。ローカル開発、プロトタイピング、小規模なアプリケーションに適しており、スケーラビリティと効率性は比較的限られています。Chromaはオーディオデータに特化して設計されていますが、テキストデータの処理には最適化されておらず、包括的なパフォーマンスベンチマーク情報はほとんどありません。

結論 RAGシステムやほとんどのAIアプリケーションには、専用のベクトル・データベースが最適です。パフォーマンス、機能性、スケーラビリティの点で優れており、これらのアプリケーションのニーズをよりよく満たすことができる。数ある専用ベクトルデータベースの中でも、Weaviate、Milvus、Qdrant、Vespaは現在最も人気があり、広く利用されています。

Weaviate、Milvus、Qdrantの3つの優れたオープンソースのベクトルデータベースをより視覚的に比較するために、以下の表にまとめました：

概要

• Qdrantです： 軽量アーキテクチャ , 低リソースオーバーヘッド , 優れたパフォーマンス , デプロイと使用が容易 , Rust言語開発 , パフォーマンスと効率に焦点 .
• ウィービエイト 包括的な機能、ベクトル検索、オブジェクトストレージ、転置インデックスの統合、GraphQLクエリのサポート、データモデリング機能、Go言語開発、活発なコミュニティ。
• ミルバス 強力なパフォーマンス、豊富な機能性、活発なコミュニティ、様々なインデックスタイプとクエリメソッドのサポート、様々な複雑なシナリオに柔軟に対応可能、GoとC++言語の開発、生態学的な完成度。

お客様のニーズ、技術スタックの好み、チームの能力に最も適したベクターデータベースを選択することができます。

ベクターデータベースの検索方法を解説：ベクター検索のさまざまなポジションを解き明かす

ベクトルデータベースの中核機能は類似性検索であり、さまざまなベクトルデータベースが、さまざまなアプリケーションのニーズに応えるために、さまざまな検索方法を提供している。これらの検索方法を理解することで、ベクトルデータベースをより効果的に活用し、より強力なAIアプリケーションを構築することができます。

6.ベクトルデータベースにおける検索方法の比較

ここでは、Milvus、Weaviate、Qdrantの3つのデータベースの主な検索方法に焦点を当てる：

6.1 Milvus：さまざまなシナリオに対応する柔軟で多様な検索戦略

Milvusは豊富で柔軟な検索ストラテジーを提供し、様々なデータ構造やクエリー要件に応じて適切な検索方法を選択することができます。

• 単一ベクトル検索： を使った最も基本的な検索方法である。 search() このメソッドは、クエリ・ベクトルとコレクション内の既存のベクトルを比較し、最も類似したエンティティ ID とその距離を返します。返される結果のベクトル値とメタデータを選択できます。単純な類似検索シナリオに最適です。例えば、ある商品と最も類似した商品を見つける、ある画像と最も類似した画像を見つけるなど。
• マルチベクトル検索： 複数のベクトル・フィールドを含むコレクションでは hybrid_search() メソッドを使用します。Milvusの最新バージョン2.4.xでは、最大10ベクトルまでの検索をサポートしています。マルチベクトル検索は、例えば、高い精度が要求される複雑なシナリオに特に適しています：
  • 同じデータを異なる埋め込みモデルを使って処理する： 例えば、BERT、Sentence-BERT、GPT-3などの異なるモデルを使用して、同じ文を異なるベクトル表現で生成することができる。マルチベクトル検索は、検索の精度を向上させるために、これらの異なるモデルのベクトル表現を融合することができる。
  • マルチモーダルデータフュージョン： 例えば、個人の画像、指紋、声紋などの複数のモーダル情報は、包括的な検索のために異なるベクトル形式に変換される。マルチベクトル検索は、これらの異なるモダリティのベクトル情報を融合し、より包括的な類似性検索を実現することができる。
  • リコール率を高める： 異なるベクトルに重みを割り当て、「マルチプル・リコール」戦略で複数のベクトルの情報を利用することで、検索結果のリコール能力と有効性を大幅に向上させ、関連する結果の見逃しを防ぐことができる。
• 基本的な検索操作： 一方向性検索と多方向性検索に加えて、Milvusは以下のような基本的な検索操作を豊富に提供している：
  • 一括ベクトル検索： 複数のクエリベクトルを一度に送信することで、検索効率が向上し、クエリのバッチ処理を必要とするシナリオに適している。
  • パーティション検索： 指定されたパーティションで検索し、検索範囲を絞り込み、検索速度を向上させます。大容量のデータシナリオに適しており、パーティションごとにデータを保存し、クエリの効率を向上させることができます。
  • 検索する出力フィールドを指定します： 指定されたフィールドのみを返し、データ転送量を減らし、検索効率を向上させ、フィールド情報の一部のみが必要なシナリオに適しています。
• フィルター検索： 検索結果を絞り込むためにスカラーフィールドに基づいて条件をフィルタリングすること、例えば、商品価格、ユーザー年齢、商品カテゴリーなどの条件に基づいてフィルタリングすること、さらに検索の精度を向上させるために類似性検索に基づいて結果をフィルタリングすること。
• 範囲検索： クエリーベクトルとの距離が特定の範囲内にあるベクトルを検索する。例えば、対象製品との類似度が0.8以上の製品を検索する。これは、類似度の範囲を限定する必要があるシナリオに適している。
• グループ化された検索： 特定のフィールドに基づいて検索結果をグループ化することで、結果の多様性を確保し、結果の過度な集中を避けることができる。これは、結果の多様性を必要とするシナリオ、例えば、異なるカテゴリの商品を推薦したいレコメンダーシステムなどに適している。

6.2 Weaviate：複数の検索技術を組み込んだ強力なハイブリッド検索機能

Weaviateは強力なハイブリッド検索機能を提供し、ベクトル類似検索、キーワード検索、生成検索、その他の検索手法を柔軟に組み合わせることで、複雑なクエリ要件に対応し、より包括的な検索ソリューションを提供します。

• ベクトル類似度検索： クエリベクトルに最も類似したオブジェクトを見つけるための複数の近接検索メソッドを提供することが、Weaviateの中核となる検索機能です。
• 画像検索 類似検索の入力として画像の使用をサポートし、画像検索シナリオに適した画像検索機能を実現。
• キーワード検索 結果はBM25Fアルゴリズムを使ってランク付けされ、従来のキーワード検索シナリオの効率的なキーワード検索をサポートする。
• ハイブリッド検索： BM25キーワード検索とベクトル類似度検索を組み合わせて、意味的関連性とキーワードのマッチングを考慮した結果の融合ランキングを行うことは、キーワードと意味情報の両方を考慮する必要があるハイブリッド検索シナリオに適している。
• ジェネレーティブ・サーチ： 検索結果をLLMのヒントとして利用し、よりユーザーの意図にマッチした回答を生成することで、検索とジェネレーティブAI技術を組み合わせ、よりスマートな検索体験を提供する。
• 再ランクイン： 検索結果の品質は、再ランク付けモジュール（Re-rank）を使用して、検索された検索結果を再ランク付けし、その精度と関連性を向上させることにより、さらに最適化される。
• 集計： 結果収集からデータを集計し、統計分析を実行し、データ分析機能を提供し、データマイニングと分析でユーザーを支援する。
• フィルター メタデータフィールドなどに基づく条件付きフィルタリングを検索に適用し、検索精度を向上させ、複雑なフィルタリング条件をサポートします。

6.3 Qdrant: ベクトル検索に重点を置き、全文フィルタリングを考慮、軽量で効率的

Qdrantは、フルテキストフィルタリングと高性能ベクトル検索サービスをバランスよく提供することに重点を置き、その軽量、高性能、使いやすさで知られています。

Qdrantがサポートする基本的な検索操作::

• スコアによるフィルタリング： ベクトル類似度スコアに基づくフィルタリングは、類似度の高い結果のみを返し、検索結果の質を向上させる。
• 一つのリクエストで複数の検索操作をロードする（マルチ検索リクエスト）： 複数の検索リクエストを一度に送信すると、検索効率が向上し、クエリのバッチ処理が必要なシナリオに適しています。
• APIを推奨する： 推薦システムを構築するための特別な推薦APIを提供し、推薦システムの開発プロセスを簡素化する。
• グループ化の操作： 検索結果のグループ化は、結果の多様性を必要とするシナリオにおいて、結果の多様性を向上させる。

Qdrantがサポートするその他の検索方法::

Qdrantのコアとなる位置づけはベクトル検索エンジンであり、ベクトル検索のパフォーマンスに影響を与えることなく、基本的な全文フィルタリングのニーズを満たすために、限定的な全文検索サポートを提供しています。

• 全文フィルタリングによる検索： ベクトルデータは、例えば特定のキーワードを含むベクトルデータを検索するために、フルテキストフィルターを使用してフィルタリングすることができ、シンプルなフルテキスト検索機能を実現します。
• ベクトル検索による全文フィルタ： 全文フィルタリングとベクトル検索を組み合わせ、より正確な検索を実現するために、特定のキーワードでレコード内のベクトル検索を実行し、検索の精度を向上させる。
• プレフィックス検索とセマンティック・インスタント検索： プレフィックス検索とセマンティック・インスタント検索をサポートし、よりユーザーフレンドリーなエクスペリエンス、あいまい検索、リアルタイム検索を提供。

Qdrantの今後の予定機能::

• スパース・ベクターに対応： 例えば、SPLADEや同様のモデルで使用されるスパースベクトルは、スパースデータを扱う能力を高め、ベクトル検索の効率と精度を向上させる。

Qdrantがサポートしない機能::

• BM25または他の非ベクトルベースの検索またはランキング関数（非ベクトルベースの検索）： Qdrantはベクトル検索を中核とし、従来のキーワードベースの検索方法をサポートするつもりはなく、シンプルで効率的なアーキテクチャを維持している。
• 内蔵オントロジーまたはナレッジグラフ、クエリーアナライザー、その他の自然言語処理ツール（内蔵オントロジーまたはナレッジグラフ）： Qdrantはベクトル検索の基礎となるインフラに焦点を当て、上位レイヤーのアプリケーションやNLP機能を排除し、コア機能に集中し、パフォーマンスを最適化します。

BM25と単純なキーワード検索の違いとは？関連性スコアリングを詳しく見る

キーワード検索の分野では、BM25（ベストマッチング25）アルゴリズムは、単純なキーワードマッチングよりも高度で効果的な関連性スコアリング方法です。両者の違いを理解することで、特にキーワード検索や混合検索が必要なシナリオにおいて、適切な検索戦略をより適切に選択することができる。

1.関連性スコアリングメカニズム：

• シンプルなキーワード検索： スコアリングは通常、用語頻度（TF - Term Frequency）に基づいて行われる。つまり、あるキーワードが文書に登場する回数が多ければ多いほど、その文書の関連性は高くなる。この方法はシンプルでわかりやすいが、文書の長さやキーワードの重要性を無視する傾向があるため、長い文書のスコアリングが過剰になったり、よく使われる単語や無効化された単語が結果に干渉したりする可能性がある。
• BM25（ベストマッチング25）： 単語頻度（TF）、逆文書頻度（IDF - Inverse Document Frequency）、文書の長さを考慮したより複雑なアルゴリズムを使って文書の関連性をスコア化することで、BM25はクエリに対する文書の関連性をより正確に測定し、単純なキーワード検索の限界に効果的に対処することができる。

2.ドキュメントの長さ処理

• シンプルなキーワード検索： 文書の長さが考慮されていない可能性があり、その結果、長い文書はキーワードを含む確率が高いため、関連性が高いとみなされる可能性が高くなり、結果的に長い文書バイアスが生じる。
• BM25： 文書の長さを正規化する係数を導入することで、長い文書と短い文書の間の関連性スコアリングの公平性を確保し、長さの優位性のために長い文書のスコアが高くなりすぎるのを避けるために、長い文書の偏りの問題が解決される。

3.クエリ用語の重要性

• シンプルなキーワード検索： すべてのキーワードを等しく重要なものとして扱うことが一般的であり、文書コレクションにおけるキーワードの希少性を無視し、一般的な単語や非活性化された単語が結果に干渉する原因となる。
• BM25： キーワードの重要度は、逆文書頻度（IDF）を用いて測定される。IDF値が高いキーワード（すなわち、文書コレクションの中で希少なキーワード）ほど、文書関連性スコアに大きく寄与し、キーワードの重要度を効果的に区別し、検索結果の質を向上させる。

4.パラメータの調整可能性：

• シンプルなキーワード検索： 通常、パラメータが少ないため、微調整が難しく、柔軟性に欠ける。
• BM25： 調整可能なパラメータ（k1やbなど）は、ユーザーが特定のアプリケーションシナリオやデータ特性に応じてアルゴリズムを微調整し、検索結果を最適化し、検索の柔軟性とカスタマイズ性を向上させるために提供される。

概要

単純なキーワード検索と比較して、BM25アルゴリズムは、関連性スコアリング、文書長処理、クエリ語の重要度測定、パラメータ調整可能性の点で優れており、より正確でユーザが期待する検索結果を提供することができる。したがって、BM25アルゴリズムは、検索品質に対する要求が高いシナリオ、特にキーワード検索やハイブリッド検索が必要とされるシナリオにおいて、より優れた選択肢であり、検索結果を改善するための重要な技術である。

7.性能ベンチマークとメトリクスの詳細：ベクトルデータベースの長所と短所の定量的評価

ベクトルデータベースを選択する上で、性能は重要な検討事項である。ベクトルデータベースの性能を評価する手段として、ベンチマークは有効である。ただし、ベンチマーク結果は様々な要因に影響されるため、ベンチマーク結果を参照する際には、具体的なアプリケーションシナリオや要件と組み合わせて総合的に分析する必要があることに留意する必要がある。

7.付録

7.1 ANNベンチマーク：権威ある性能評価プラットフォーム

ANNベンチマーク Approximate Nearest Neighbors Benchmarks (ANN-Benchmarks)は、近似最近傍アルゴリズムのための権威ある性能評価プラットフォームであり、Erik Bernhardssonによって作成・管理されている。様々な近似最近傍探索アルゴリズムとベクトルデータベースの性能を評価するための統一されたベンチマークフレームワークとデータセットを提供します。ANN-Benchmarksはベクトルデータベースの性能評価のための重要なリファレンスを提供し、異なるベクトルデータベース間の性能の違いを理解するための重要なツールです。

ベンチマークの影響要因

• 検索タイプ フィルタリングされた検索と通常の検索では、検索の種類によってパフォーマンスに与える影響が異なります。
• コンフィギュレーション設定： インデックス・タイプ、インデックス・パラメーター、キャッシュ設定などのデータベース構成パラメーターは、パフォーマンスに大きく影響します。
• インデックス作成アルゴリズム： 異なるインデックス作成アルゴリズム（IVF、HNSW、PQなど）は異なる性能特性を持ち、異なるデータ分布やクエリシナリオに適している。
• データの埋め込み： データの埋め込みの質と次元は、ベクトルデータベースの性能と精度に影響する。
• ハードウェア環境： CPU、メモリ、ディスク、ネットワーク、その他のハードウェアリソースは、データベースのパフォーマンスに直接影響します。

ベンチマークに加えて、モデルを選択する際に注目すべき主な要素：

• 分散された能力： 分散デプロイメントをサポートし、膨大なデータと高い並行性に対応するために水平方向に拡張できるかどうか。
• データのコピーとキャッシュ： データの安全性を確保し、システムのパフォーマンスを向上させるために、データコピーとキャッシュ機構をサポートするかどうか。
• インデックス作成アルゴリズム： どのようなインデックス作成アルゴリズムが使用されているか、アルゴリズムのパフォーマンス特性と適用シナリオ、複数のインデックス作成アルゴリズムがサポートされているかどうか。
• ベクトル類似検索機能： 複雑なクエリのニーズを満たすために、ハイブリッド検索、フィルタリング、複数の類似性メトリクス、その他の高度な検索機能をサポートするかどうか。
• セグメンテーションのメカニズム： データスライスをサポートするかどうか、データスライスと管理をどのように実行するか、データ管理とクエリの効率を向上させる。
• クラスター方式： クラスタの構築方法、クラスタのスケーラビリティと安定性、システムの高可用性とスケーラビリティの保証。
• スケーラビリティの可能性： システムの拡張性の上限、将来のビジネス成長のニーズに応えられるかどうか、システムの拡張能力を予測する。
• データの一貫性： 特に分散環境において、データの一貫性と信頼性をどのように保証するか。
• システム全体の可用性： システムの安定性と信頼性、7x24時間の安定稼働を確保し、事業継続の要件を満たすことができるかどうか。

角度メトリクスとユークリッドメトリクスの比較：テキスト検索の主要メトリクス

テキスト検索の分野では、ベクトル・データベースが使われている。角度距離 でのパフォーマンスは、通常ユークリッド距離 の方が重要である。これは、角度メトリクスがテキスト文書の意味的類似性に敏感であるのに対し、ユークリッドメトリクスは文書の長さとサイズに重点を置いているためである。

• 角度測定（余弦距離など）： ベクトルの方向に注目し、ベクトルの長さに敏感でなく、テキストの意味的類似性を測定するのに適しており、テキスト検索、文書分類、および他のシナリオに適しています。
• ユークリッドメトリック（ユークリッド距離など）： また、ベクトルの大きさと方向を考慮し、ベクトルの長さに敏感で、ベクトルの絶対距離の測定に適しており、画像認識や音声認識などのシーンに適している。

したがって、RAGシステムを選択する際には、異なる次元のベクトルデータベースに焦点を当てるべきである。角度データセット例えば、glove-100-angularとnytimes-256-angularデータセットでのパフォーマンス。

パフォーマンス分析（グローブ100角データセット）：

• クエリー/秒（QPS）： Milvusはリコールが0.95より低い場合に最も高いスループットを示し、これはMilvusが一定のリコールを保証しながら、より高いクエリ同時実行数をより高いパフォーマンスで処理できることを意味する。リコールが0.95を超えると、データベース間のスループット差は縮まり、リコールが高い場合には性能差は目立たなくなる。
• インデックス構築時間： Vespaのインデックス構築時間が最も長く、WeaviateとMilvusの構築時間はほぼ同じであるが、Milvusの方がわずかに長い。インデックス構築時間はデータベースの起動速度とデータ更新効率に直接影響し、構築時間が短いほどデータベースの起動とデータ更新は速くなる。
• インデックスのサイズ： Weaviateのインデックスが最も小さく、Milvusのインデックスが最も大きい。インデックスサイズはストレージコストとメモリ使用量に影響し、インデックスが小さいほどストレージコストとメモリ使用量は少なくなる。Milvusのインデックスは大きいが、120万個の100次元ベクトルを含むデータセットでは、インデックスサイズは1.5GB以下であり、まだ許容範囲である。

7.1.2 nytimes-256-angularデータセットの性能

パフォーマンス分析（nytimes-256-angularデータセット）：

このデータセットでのパフォーマンスは、グローブ100-angularデータセットと似ており、全体的な傾向は一貫している。

• インデックス作成時間： Weaviateのインデックス構築時間は最も長く、MilvusとQdrantは比較的短く、構築時間の順序はglove-100-angularデータセットと一致している。
• インデックスのサイズ： Weaviateのインデックスが最も小さく、Milvusのインデックスが最も大きいが、わずか440MB（29万個の256次元ベクトルを含むデータセット）であり、インデックスサイズの順序はglove-100-angularデータセットと一致している。

概要

ANNベンチマークは、様々なベクトルデータベースの性能特性を理解するのに役立つ貴重な性能参照データを提供する。 Milvusはスループットに優れ、高度な同時クエリシナリオに適しており、Weaviateはインデックスサイズに優位性があり、ストレージスペースを節約できる。 Vespaは構築時間が比較的長く、インデックス構築効率を考慮する必要がある。

実際にモデルを選択する際には、特定のアプリケーションシナリオ、データ特性、パフォーマンス要件を組み合わせて総合的に評価する必要があり、ベンチマークテストの結果だけに頼ることはできない。

7.2 ベクトル類似度メトリクス：検索結果を改善するための正しいメトリクスの選択

ベクトル類似度メトリクスは、2つのベクトル間の類似度を測定するために使用され、異なる類似度メトリクスは、異なるデータタイプやアプリケーションシナリオに適しています。適切な類似度メトリクスの選択は、ベクトル検索の精度と効果に直接影響します。異なるベクトル・データベースは異なる類似度メトリクスをサポートしているため、実際のニーズに応じて適切なデータベースと類似度メトリクスを選択する必要があります。

7.2.1 コサイン距離：テキスト類似度計算の第一選択

コサイン距離は、2つのベクトル間の角度の余弦を計算することにより、ベクトルの類似性を測定します。コサイン値が1に近いほどベクトルは似ており、-1に近いほどベクトルは似ていない。コサイン値が0の場合、ベクトルは直交しており、関連していないことを示す。

• バンテージ::
  • ベクトルの方向に注目し、ベクトルの長さは無視する： コサイン距離はベクトルの方向に注目し、ベクトルの長さには敏感ではない。このため、テキストデータの処理に適している。なぜなら、テキストの類似度計算では、ドキュメントの長さは重要な要素ではないことが多く、ドキュメントの主題や意味方向が重要だからである。
  • 高次元のスパースデータに対応： 高次元の疎なデータのシナリオでは、余弦距離は依然として良好な性能を維持することができ、テキストやユーザー行動のような高次元の疎なデータの類似度計算に適している。
• 欠点::
  • ベクトル長情報には影響されない： シナリオによっては、ベクトルの長さ情報も重要な場合がある。例えば、推薦システムでは、ユーザーの活動レベル（ベクトルの長さ）が重要な特徴となる場合がある。コサイン距離はこの情報を無視し、情報の損失につながる可能性がある。
  • 非凸データセットには適用できない． データ分布が凸集合でない場合、余弦距離は正確な類似性尺度を提供しない可能性があり、データ分布に基づいて適切な類似性メトリックを選択する必要がある。
• 適用シナリオ::
  • テキストの類似度計算： 例えば、2つの記事、2つの文章、2つの段落の意味的類似度を計算することは、テキストの類似度を計算するための一般的な指標である。
  • ドキュメントの分類： 文書は、文書ベクトルの類似性に基づいて異なるカテゴリに分類される。
  • 推奨システム レコメンデーションはユーザーの行動やアイテムの特徴に基づいて行われ、ユーザーベクトルとアイテムベクトルの類似度がパーソナライズされたレコメンデーションのために計算される。
  • 高次元のスパースデータシナリオ： 例えば、ユーザー行動データや商品特徴データのような高次元スパースデータの類似度計算。

7.2.2 ユークリッド距離（L2）：直感的で理解しやすいが、高次元空間では性能に限界がある。

ユークリッド距離はL2ノルムとしても知られ、多次元空間内の2つのベクトル間の直線距離を計算する。距離が小さいほどベクトルは似ており、距離が大きいほどベクトルは似ていない。

• バンテージ::
  • 直感的で理解しやすい： ユークリッド距離の概念はシンプルかつ直感的で、理解しやすく使いやすい。
  • ベクトルの大きさと方向の両方を考える： ユークリッド距離はベクトルの大きさと方向の両方を考慮するため、ベクトルの違いをより完全に把握することができ、ベクトルの大きさと方向の両方を考慮する必要があるシナリオに適している。
• 欠点::
  • 高次元空間の性能は「次元の破局」によって低下する： 高次元空間では、すべての点間のユークリッド距離が等しくなる傾向があるため、微分が減少し、類似検索の精度に影響を与え、高次元データシナリオでのパフォーマンスが制限される。
  • 外れ値に敏感： ユークリッド距離は外れ値の影響を受けやすく、距離計算結果に大きく影響し、ロバスト性が低い。
• 適用シナリオ::
  • 画像認識： 例えば、顔認識、物体認識など、画像特徴ベクトルのユークリッド距離に基づく類似性比較。
  • 音声認識： 例えば音声特徴マッチングは、音声特徴ベクトルのユークリッド距離に基づいて類似度比較を行う。
  • 筆跡鑑定： 例えば、手書き文字認識、手書き文字特徴ベクトルのユークリッド距離に基づく類似性比較。
  • 低次元データのシナリオ： 低次元データのシナリオでは、ユークリッド距離は依然として低次元データの類似性検索に有効な類似性メトリックである。

7.2.3 ドット積：効率的な計算、推薦システムに適している

内積は点積としても知られ、2つのベクトルの対応する成分の積の和を計算する。内積が大きいほどベクトルは似ており、内積が小さいほどベクトルは似ていない。

• バンテージ::
  • 計算は速い： 内積は非常に高速で、特にベクトル次元が高い場合、性能上の利点はより明白であり、大規模データや高い並行性のシナリオに適している。
  • ベクトルの大きさと方向の両方を反映する： 内積はベクトルの大きさと方向の両方を考慮し、ベクトルの全体的な類似性を反映するため、ベクトルの大きさと方向を考慮する必要があるシナリオに適している。
• 欠点::
  • ベクターのスケールに敏感： 内積の値はベクトルのスケールに影響され、ベクトルのスケールに大きな差がある場合、内積の類似性尺度はベクトルのスケールに敏感に反応して歪む可能性がある。
  • データの正規化が必要な場合もある： ベクトルのスケールの違いの影響を排除するために、内積の類似度測定の精度を保証するために、ベクトルを単位長さに正規化するなど、データを正規化する必要がある場合が多い。
• 適用シナリオ::
  • 推奨システム 例えば、パーソナライズされたレコメンデーションのためのユーザーベクトルとアイテムベクトル間の類似性を計算するために、内積はレコメンデーションシステムでよく使われる類似性メトリックである。
  • 協調フィルタリング： レコメンデーションは、ユーザーやアイテム間の類似度を計算するために内積を使用し、類似度に基づいて行われる。
  • 行列分解： また、内積はベクトル間の類似度を測定し、行列分解アルゴリズムの実装に役立ちます。
  • 高性能コンピューティングを必要とするシナリオ： 例えば、大規模なオンライン推薦システム、リアルタイム検索システム、その他のベクトル類似度の高速計算を必要とするシナリオなどである。

7.2.4 L2乗ユークリッド距離：違いを増幅、特定のシーンに有効

L2 平方距離はユークリッド距離の2乗で、ユークリッド距離の2乗値として計算される。

• バンテージ::
  • ペナルティ・ベクトルの要素間の差が大きい： 二乗演算はベクトル要素間の差異を拡大し、距離値を差異に対してより敏感にする。場合によっては、この特性は類似点を区別し、相違点を強調する上でより有益かもしれません。
  • 平方根の計算を避けることで、計算効率が向上する： 計算のシナリオによっては、平方根の計算を避けることで、効率を向上させ、計算プロセスを簡略化することができる。
• 欠点::
  • 二乗操作は距離を歪める可能性がある： 二乗演算は距離のスケールを変更するため、ユークリッド距離よりも直感的でない解釈的な距離の意味になる可能性がある。
  • 外れ値の影響を受けやすい： 二乗演算はさらに外れ値の影響を増幅し、L2二乗距離を外れ値の影響を受けやすくし、ロバスト性を低下させる。
• 適用シナリオ::
  • 画像処理： 例えば、2つの画像をピクセルレベルで比較する場合、L2乗距離はピクセルの違いを拡大し、画像のニュアンスをより効果的に比較する。
  • 異常検知： 外れ値の影響を増幅することで、異常データの検出が容易になり、外れ値に敏感な異常検出シナリオに適している。
  • 違いを増幅する必要がある具体的なシナリオ： L2平方距離は、差別化を強調する必要がある特定のシナリオでは、ユークリッド距離よりも効果的かもしれない。

7.2.5 ハミング距離：2値データの排他的メトリック

ハミング距離は、2つの等しい長さの2値ベクトルの対応する位置で異なる値の数を測定し、2値ベクトル間の差の程度を測定するために使用されます。

• バンテージ::
  • バイナリまたはカテゴリーデータの場合： ハミング距離は、特にバイナリまたはカテゴリデータの違いを測定するために使用され、バイナリベクトルの類似度計算に適しています。
  • 計算は速い： ハミング距離の計算は非常にシンプルかつ効率的で、2値ベクトルの対応する位置を比較し、異なる値の数を数えるだけでよい。
• 欠点::
  • 連続数値データには適用されない： ハミング距離は2値またはカテゴリーデータにしか使えず、連続した数値データを扱うことができないため、適用範囲が限られる。
• 適用シナリオ::
  • エラー検出と訂正： 例えば、通信符号化では、ハミング距離は誤り検出と訂正のために符号語間の差を測定するために使用され、符号化理論における重要な概念である。
  • DNA配列の比較： DNA配列は2進表現に変換され、バイオインフォマティクス解析のためにハミング距離を用いて配列比較が行われた。
  • サブタイプのデータ類似度計算： サブタイプ化されたデータの類似度計算、例えばユーザーラベルや商品属性などのカテゴリー化されたデータの類似度計算に適している。

7.2.6 マンハッタン距離 (L1): よりロバストな距離指標、外れ値に強い

マンハッタン距離は、L1ノルムや街区距離としても知られ、2つのベクトル間の差の絶対値の総和としてすべての次元で計算される。

• バンテージ::
  • ユークリッド距離よりも外れ値に強い： マンハッタン距離はユークリッド距離よりも外れ値の影響を受けにくく、二乗差ではなく差の絶対値のみを計算するため、外れ値の干渉に強くロバストである。
  • 計算は比較的速い： マンハッタン距離はユークリッド距離よりわずかに速く、距離を素早く計算する必要があるシナリオに適している。
• 欠点::
  • 幾何学的有意性はユークリッド距離よりも直感的でない： マンハッタン距離の幾何学的意義は、ユークリッド距離よりも直感的でなく、理解しにくく、幾何学的に解釈しにくい。
• 適用シナリオ::
  • ボードの距離計算： 例えば、チェス盤上の2マス間の距離を計算するには、マンハッタン距離が一般的に使われる。
  • 都市近隣の距離計算： 例えば、対角線方向の距離を無視して都市内の2地点間の距離を計算する場合、マンハッタン距離は街区距離とも呼ばれる。
  • 物流計画における最短経路問題： マンハッタン距離は、物流計画における経路の長さを評価し、最短経路アルゴリズムの実装を支援するために使用することができる。
  • 外れ値の影響を受けにくいシナリオ： 外れ値の影響を軽減する必要があるシナリオでは、ユークリッド距離よりもマンハッタン距離の方が適用可能でロバストである。

8.参考文献

1. https://github.com/milvus-io/milvus
2. ベクター・データベースでアルを動かす：ベンチマーク - パート1 - データ - ブログ - F-Tech Japan
3. 基礎 - Qdrant
4. Milvusのドキュメント
5. ホーム｜Weaviate - ベクターデータベース
6. Qdrant ドキュメンテーション - Qdrant
7. ベクターデータベースの使用例 - Qdrant
8. ベクターデータベース：概要、使用例、ベクターDBトップ5
9. ANNベンチマーク
10. ベクトル探索における距離メトリクス - Weaviate
11. BM25 - 百度百科事典