ベクトルデータベースについて: ベクトルデータベース、ベクトル検索ライブラリ、とベクトル検索プラグインの比較

ようこそ、ベクトルデータベース101へ！ 　ChatGPTと他の大規模言語モデル（LLM）の急増が、 ベクトル検索技術の成長を押し進んでいます。 その結果として、 Milvusや Zilliz Cloudのような特殊な ベクトルデータベース、 FAISSのようなライブラリ、および伝統的な データベース内に統合されたベクトル検索プラグインが誕生しました。 　前のシリーズ記事では、 ベクトルデータベースの基本を掘り下げました。さて、この記事では、ベクトルデータベース、 ベクトル検索プラグイン、および ベクトル検索ライブラリを比較しながら、ベクトルデータベースをより深く理解し、ベクトル検索の複雑な領域を探索します。

ベクトル検索とは何か？ 　ベクトル検索は、ベクトル類似検索と呼ばれています。それはつまり、高密度ベクトルデータの大規模な コレクションの中から、 指定されたクエリベクトルに最も類似した、または 意味的に関連した上位k個の結果を取得する技術です。 　類似検索を実行する前に、 私たちはニューラルネットワークを利用して、 テキスト、画像、動画、音声のような非構造化データを高次元数値ベクトル、つまり埋め込みベクトルに変換します。埋め込みベクトルが 生成された後、ベクトル検索エンジンは入力されたクエリベクトルとベクトルストア内のベクトルとの 空間距離を比較します。空間的により近いほど、ベクトルはより類似しています。 　相場には、 以下の通り、複数のベクトル検索技術が存在します:

• PythonのNumPyのような機械学習ライブラリ
• FAISSのようなベクトル検索ライブラリ
• 伝統的なデータベースに組み込まれたベクトル検索プラグイン
• Milvusや Zilliz Cloudのような専門ベクトルデータベース

ベクトルデータベース vs. ベクトル検索ライブラリ 　専門ベクトルデータベースは、類似検索に使用される唯一の スタックではありません。 ベクトルデータベースが登場する前には、 FAISS、ScaNN、HNSWのような多くの ベクトル検索ライブラリが ベクトル検索に使用されていました。 　ベクトル検索ライブラリは、 高性能なプロトタイプのベクトル検索システムを 迅速に構築するのに役立ちます。 例としてオープンソースのFAISSを挙げますと、これは効率的な類似検索と高密度ベクトルクラスタリングのために、Metaによって開発されました。 FAISSはメモリに完全にロードできないほどのサイズを持ったベクトルコレクションさえも処理することが可能です。さらに、FAISSは評価とパラメータ調整のためのツールも供与しています。 C++で書かれたにもかかわらず、FAISSは Python/NumPyインターフェースを提供しています。 　しかしながら、 ベクトル検索ライブラリはあくまでも軽量な近似最近傍探索(ANN)ライブラリであり、 管理型ソリューションではありません。 また、 機能も制限されています。 もしデータセットが小さくて限定的であれば、 これらのライブラリは非構造化データの処理に十分であり、 実際の生産システムにおいても使用可能です。 しかし、データセットのサイズが大きくなり、さらに多くのユーザーが加わると、 スケールの問題がさらに解決できなくなります。さらに、 これらのライブラリはインデックスデータを修正することができず、 データのインポート中にクエリを実行することもできません。 　これに対して、ベクトルデータベースは、非構造化データの保存と取得のために最適なソリューションです。 ベクトルデータベースは、数百万から数十億の ベクトルを保存・クエリしつつ、 同時に リアルタイムで応答を返すことができます。 また、 ユーザーの成長するビジネスニーズに対応するため、高いスケーラビリティを備えています。 　さらに、 Milvusのようなベクトルデータベースは、 構造化/半構造化データの ためによりユーザーフレンドリーな機能を持っています: クラウドネイティブ性、 マルチテナンシー、 スケーラビリティなど。 これらの特徴は、 このチュートリアルを深掘りしていく中でより明確に なっていくでしょう。 　また、 ベクトルデータベースはベクトル検索ライブラリとは全く異なる抽象レイヤーで作動しています。 ベクトルデータベースは 完全なサービスであり、 ANNライブラリは開発中のアプリケーションに統合されるべきコンポーネントの 一つに 過ぎません。 この意味で、 ANNライブラリはベクトルデータベースの上に構築される多くのコンポーネントの一つです。 例えば、Elasticsearchが Apache Luceneの上に構築されているのと同様です。 　この抽象性がなぜ重要であるかを説明するために、 新しい非構造化データ要素をベクトルデータベースに挿入する例を見てみましょう。 Milvusでは、 これは非常に簡単です:

from pymilvus import Collection
collection = Collection('book')
mr = collection.insert(data)

これだけです。 たった3行の コードで完了します。 FAISSや ScaNNのような ライブラリを 使用する場合、 これを実現する簡単な方法はなく、 一定のチェックポイントでインデックスを手動で再作成する必要が あります。 さらに、 ベクトル検索ライブラリは、スケーラビリティとマルチテナンシーの2つの最も重要なベクトルデータベースの 特徴を 欠いています。

ベクトルデータベース vs. 伝統的データベース向けのベクトル検索プラグイン 　さて、 ベクトル検索ライブラリとベクトルデータベースとの違いを確認したところで、 ベクトルデータベースとベクトル検索プラグインの違いを見てみましょう。 　従来の関係データベースや検索システム（例えば、ClickHouseやElasticsearch）には、 内蔵のベクトル検索プラグインが含まれるようになってきました。 例えば、 Elasticsearch 8.0では、 含まれたベクトル挿入やANN検索機能が RESTful APIエンドポイントを介して呼び出せるようになっています。 　ベクトル検索プラグインの問題点は一目瞭然です。 これらの ソリューションは、 埋め込み管理とベクトル検索に関して、フルスタックのアプローチを取っていません。 むしろ、 既存のアーキテクチャ上に機能を拡張することを意図しており、 その結果、 限定的で非最適化されている状態になっています。従来のデータベース上に非構造化データアプリケーションを開発することは、 ガソリン車のフレームにリチウム電池と電気モーターを詰め込もうとすることに似ています。あまり良いアイデアとは言えませんね。 　この理由をより具体的に説明するために、 ベクトルデータベースが実装すべき機能（最初のセクションに記載しました）を振り返りましょう。ベクトル検索プラグインには、 可調整性とユーザーフレンドリーな API/SDKという 2つの機能が欠けています。 　　　　　　　　 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 　ElasticsearchのANNエンジンを例に挙げます。他のベクトル検索プラグインも非常に似ているものですのでため、 詳細に深入りすることはありません。 　　　 　Elasticsearchは、 dense_vectorというデータフィールド種類を介してベクトルの保存をサポートし、 knnsearch endpointを介して クエリを実行できます:

PUT index
{
 "mappings": {
   "properties": {
     "image-vector": {
       "type": "dense_vector",
       "dims": 128,
       "index": true,
       "similarity": "l2_norm"
     }
   }
 }
}
 
PUT index/_doc
{
 "image-vector": [0.12, 1.34, ...]
}

GET index/_knn_search
{
 "knn": {
   "field": "image-vector",
   "query_vector": [-0.5, 9.4, ...],
   "k": 10,
   "num_candidates": 100
 }
}

Elasticsearchの ANNプラグインは、 階層的ナビゲーション可能スモールワールド(HNSW)と呼ばれる1つのインデックスアルゴリズムのみをサポートしています（この名前をつけた人は、 マーベルがマルチバースを人気トピックにしたより先にこのアイデアを持っていたようです）。 さらに、 サポートされている距離指標は L2/ユークリッド距離のみです。 これは 出発点としては十分ですが、 Milvusのようなフル機能のベクトルデータベースと比較してみましょう。 　pymilvusを使用すると、 次のように実行できます:

>>> field1 = FieldSchema(name='id', dtype=DataType.INT64, description='int64', is_primary=True)
>>> field2 = FieldSchema(name='embedding', dtype=DataType.FLOAT_VECTOR, description='embedding', dim=128, is_primary=False)
>>> schema = CollectionSchema(fields=[field1, field2], description='hello world collection')
>>> collection = Collection(name='my_collection', data=None, schema=schema)
>>> index_params = {
        'index_type': 'IVF_FLAT',
        'params': {'nlist': 1024},
        "metric_type": 'L2'}
>>> collection.create_index('embedding', index_params)

>>> search_param = {
        'data': vector,
        'anns_field': 'embedding',
        'param': {'metric_type': 'L2', 'params': {'nprobe': 16}},
        'limit': 10,
        'expr': 'id_field > 0'
    }
>>> results = collection.search(**search_param)

ElasticsearchとMilvusの両方が、 インデックス作成、埋め込みベクトル挿入、 および最近傍検索を実行するためのメソッドを提供していますが、 これらの例から明らかなように、 Milvusはより直感的なベクトル検索API（よりユーザーフレンドリーなAPI）と、 幅広いベクトルインデックスおよび距離指標サポート（より高い可調整性）を提供しています。 Milvusは、将来にさらに多くのベクトルインデックスをサポートし、 SQLに似たステートメントを介したクエリの実行をサポートする予定であり、 可調整性と使いやすさの両方を改善します。 　私たちはここで非常に多くの内容を一気に駆け抜けました。このセクションはかなり長くなったため、スキミングした方のために要点をまとめさせていただきます：Milvusは、ベクトル検索プラグインよりも優れています。なぜなら、Milvusはベクトルデータベースとしてゼロから構築されており、より豊富な機能セットと非構造化データに適したアーキテクチャを備えているからです。

さまざまなベクトル検索技術の選び方 　すべてのベクトルデータベースが同じように作られているわけではありません。それぞれが特定のアプリケーションに対応する独自の特性を持っています。ベクトル検索ライブラリやプラグインは、ユーザーフレンドリーで、数百万規模のベクトルを扱う小規模な生産環境に最適です。データサイズが小さく、基本的なベクトル検索機能のみが必要な場合、これらの技術はビジネスにとって十分なものでしょう。 　しかし、数億のベクトルを扱い、リアルタイムの応答が求められるデータ集約型のビジネスの場合は、特化型のベクトルデータベースが最適な選択肢となります。たとえば、Milvusは数十億のベクトルを容易に管理し、非常に高速なクエリ速度と豊富な機能性を提供します。さらに、Zillizのような完全管理型ソリューションは、運用上の難題を取り除き、コアビジネス活動に専念できるようにサポートします。