ベクターデータベースの研究開発における新たな潮流
2019年にMilvusで初めて導入されたベクトルデータベースは、大規模言語モデル(LLMs)の出現や生成AI(GenAI)アプリケーションの台頭とともに急速に台頭してきた。この分野に深く携わるエンジニアとして、私は近似最近傍探索（ANNS）アルゴリズムの基本的な実装から、現代のAIフレームワークに不可欠な洗練されたデータベースシステムまで、ニッチな実装から広範な展開まで、その進化を目の当たりにしてきた。
AIが成熟し続ける中、ベクトル・データベースの未来はどこに向かうのだろうか？私の考えでは、このテクノロジーの発展は、ユーザーの要求の変化に後押しされた製品の進化と密接に結びついている。こうした変化を理解することは、技術開発の軌跡と目標を方向づける上で極めて重要である。
この記事では、技術的な観点と実用的な観点の両方から、コスト効率とビジネス要件に焦点を当てて、ベクター・データベースの発展と予想される将来について論じる。
ホット・データ・ストレージとコールド・データ・ストレージの分離
ベクターデータベースを広く採用する上で、コストは長い間大きな懸念事項であった。これらのコストは主に2つの分野に起因する：
データ・ストレージ：*** 従来、ベクトル・データベースは低レイテンシーを実現するため、すべてのデータをメモリ上またはローカル・ディスク上にキャッシュしていた。しかし、アプリケーションが数十億単位のデータ量を頻繁に扱うAIの時代には、このアプローチでは数十から数百テラバイトに及ぶ膨大なストレージ・リソースを消費する可能性がある。
データ計算:**分散データベースシステムでは、拡張データセット管理を強化するために、データを多数の小さなセグメントに分割する必要がある。各セグメントは独立に処理されてデータを取得し、それをまとめて解析して最終的なTop-Kの結果をまとめる。この分割方法は、クエリ実行の複雑さを著しく増大させる。例えば、合計数十億のデータを10GBのチャンクに分割すると、約10,000のセグメントとなり、計算量は10,000倍になる。
主流のLLMの応答時間](https://assets.zilliz.com/The_response_time_of_mainstream_LL_Ms_b5670d924f.png)
主流LLMの応答時間。画像出典： https://artificialanalysis.ai/models
しかし、RAG（Retrieval-Augmented Generation）アプリケーション構築の波の中で、ベクトル・データベースの待ち時間は、ToCプラットフォーム上の個人ユーザーや単一テナントにとっては問題にならなくなっています。ベクターデータベースの操作に関連する遅延は数ミリ秒から数百ミリ秒であり、大規模な言語モデルの典型的な1秒以上の遅延に比べればごくわずかである。さらに、クラウドオブジェクトストレージのコストは、ローカルのディスクやメモリよりも大幅に低いため、ストレージと計算効率を最適化する革新的なソリューションが求められています。
ストレージコストを最小化するために、データは最も経済的なクラウドオブジェクトストレージに保存され、クエリのためにオンデマンドで取得されるべきである。
計算クエリの範囲を事前に絞り込むことで、大規模なデータ処理の必要性を減らし、運用効率を高める。
Zillizでは、Zilliz Cloud(フルマネージド型Milvus)に、レイテンシを許容レベルに保ちながらコスト削減を可能にする改良を加えています。
パフォーマンスと費用対効果を向上させるハードウェア革新の採用
ハードウェアは技術的進歩のバックボーンとして機能し、ベクトル・データベースのパフォーマンスと費用対効果を向上させます。
GPUテクノロジーの進化
激しい計算要求で知られるベクトル・データベースは、GPUの進歩により大幅な性能向上を遂げました。GPUは法外に高価であるという認識は覆されつつあります。強化されたアルゴリズムはベクトル検索タスクに適しており、低レイテンシで費用対効果の高い演算が可能です。
我々のテストによると、GPUベースのCAGRAインデックスを使用した場合、Milvusベクトルデータベースは、CPUベースのHNSWインデックスを使用した場合よりも数倍から数十倍高いパフォーマンスレベルを達成する一方、コストは2倍から3倍にしかならない。この結果は、GPUがデータ処理のための実行可能で経済的に効率的なオプションとなり、従来のCPUセットアップよりも大きな性能上の利点を提供することを示している。
VectorDBBenchによるテスト結果](https://assets.zilliz.com/Testing_results_by_Vector_DB_Bench_c6b6b04fc1.png)
VectorDBBench
によるテスト結果です。
CPU: m6id.2xlarge T4: g4dn.2xlarge A10G: g5.2xlarge Top 100 Recall：98%
クラウドコンピューティングにおけるARMベースCPUの出現
AWSのGravitonやGCPのAmpereのようなARMベースのCPUの採用は、よりエネルギー効率が高く、コスト効率の高いコンピューティングソリューションへのシフトを示すだけでなく、従来のx86アーキテクチャに対する自信に満ちた挑戦でもあります。これらのプロセッサーは、同等またはそれ以上のパフォーマンスを提供しながら、より低いコストを実現し、お客様のコンピューティング・ニーズに対する賢明な決断をお約束します。
AWSのGraviton3の評価は、x86プロセッサと比較して、その優れた性能とコスト効率を実証しています。特筆すべきは、Graviton3のわずか1年後である2023年のGraviton4のリリースに見られるように、これらのCPUの迅速な反復は、コンピューティングパワーの30％向上とメモリ帯域幅の70％向上を強調しています。
ストレージ技術の進歩
データストレージにディスクを利用することで、ベクトルデータベースは、ほとんどのベクトル検索アプリケーションに十分なミリ秒レベルのレイテンシを維持しながら、その容量を大幅に拡張することができる。さらに、ディスク・ストレージに関連するコストはメモリよりも大幅に低いままであるため、データ集約的なオペレーションにとって魅力的な選択肢となっている。
全体として、これらのハードウェアの開発は、ベクトルデータベースの能力を促進し、ベクトルデータベースが進化しても、強力で経済的に実行可能であることを保証します。
高度な機械学習モデルとの連携
ベクトル埋め込み](https://zilliz.com/glossary/vector-embeddings)を生成する機械学習モデルもまた、大きな変革を遂げつつある。これらの進歩は、ベクトルのサイズと次元を小さくすることで、大規模データセットのストレージ要件を最小化し、計算効率を高めることを目的としている。
ベクトルの次元数を減らす従来の方法は、データ検索の精度を低下させることが多かった。しかし、最近の技術革新は、実行可能な代替手段を提供している。例えば、OpenAIのext-embedding-3-largeモデルでは、設定可能なパラメータによって出力ベクトルの次元を調整することができる。この柔軟性により、下流タスクの有効性への影響を最小限に抑えながら、ベクトルサイズを大幅に縮小することができる。さらに、Cohere は最近その技術をアップグレードし、float、int8、binary などの複数のデータタイプを一度に出力するベクターをサポートし、運用の汎用性を高めました。
これらの進歩は、ベクターデータベースがこれらの新しいテクノロジーに積極的に取り組み、取り入れる必要性を浮き彫りにしています。ディープラーニングとデータ管理というダイナミックで変化し続ける分野で競争力を維持するためには、そうすることが極めて重要です。
ベクター検索の精度を優先する
ベクトル検索の精度は、特に本番環境と最先端のRAGアプリケーションの両方でベクトルデータベースの統合が拡大するにつれて、ますます重要になり、要求が厳しくなっている。ベクトル・データベースが進化するにつれ、検索の品質と精度を向上させるために、革新的な技術が採用されるようになりました。その中でも、ColBERT検索モデルと高度なハイブリッドベクトル検索技術は、情報損失を軽減し、ドメインに特化した検索を洗練させる上で極めて重要である。
ColBERT のような高度な検索モデルの出現
ColBERT 検索モデルは、従来のデュアル・タワー・モデルのかさばるアーキテクチャに典型的に関連する情報ロスを効率的に処理することで有名である。ColBERTは、トークン・ベクトル・ベースのレイト・インタラクション・アプローチを使用し、完全に接続されたセットアップの非効率性を回避している。より最近の反復であるColBERTv2は、ベクトル検索を統合することでこのプロセスをさらに最適化し、相互作用速度を大幅に加速している。
クエリqと文書dが与えられた場合のColBERTの一般的なアーキテクチャ.png](https://assets.zilliz.com/The_general_architecture_of_Col_BERT_given_a_query_q_and_a_document_d_6116056e20.png)
クエリqと文書dが与えられた場合のColBERTの一般的なアーキテクチャ
。
画像ソースhttps://arxiv.org/pdf/2004.12832.pdf
ハイブリッド検索：スパースと密なベクトル技術の橋渡し
従来の密ベクトルは、BERT のような言語モデルから派生することが多く、意味的なニュアンスを捉えることに優れ ていますが、新しい語彙や訓練データにない特殊な用語に対応できないことがあります。モデルを微調整することで、このような制限を緩和することができますが、リアルタイムで展開することは依然としてコストがかかり、困難です。逆に、BM25のような従来のキーワードマッチングアルゴリズムから得られるスパースベクトルは、このような領域外の問題に効果的に取り組むことができる。
SPLADEやBGEのM3-EmbeddingのようなEmerging sparse embeddingモデルは、厳密な用語マッチングの精度と密な検索手法の包括的な性質を融合している。これらのモデルは、キーワード・マッチングの有効性を維持しながら、より豊富な意味情報を組み込んだスパース・ベクトルを生成し、全体的な検索品質を向上させる。
キーワードとベクトル検索手法を活用したハイブリッド検索システムへのシフトは、業界では長年の慣行となっている。スパースベクトル技術の最新の進歩により、これらをベクトルデータベースに統合し、ハイブリッド検索をサポートすることは、ますますベストプラクティスと考えられている。特に、Milvusベクトルデータベースは、最近のアップデートでこのアプローチを採用している。
BGEのM3-Embeddingを例にとると、エンベッディングモデルの3つの一般的な検索機能である、高密度検索、マルチベクトル検索、スパース検索を同時に実行することができる。下の表は、異なる種類のベクトル検索を行った場合の検索品質を示している。スパース検索と高密度検索のハイブリッド検索の検索品質は、高密度検索とスパース検索のみに依存した検索品質よりもはるかに高い。
NarrativeQAでの評価(NDCG@10)](https://assets.zilliz.com/Evaluation_on_Narrative_QA_n_DCG_10_cd07dc22db.png)
NarrativeQA(nDCG@10)の評価
https://arxiv.org/abs/2402.03216
注：検索品質は、しばしばNDCG（正規化割引累積利得）を使って評価されます。これは、ユーザーに有用なアイテムリストを提供するランキングシステムの有効性を評価するものです。NDCGのKの値、例えば5、10、または25は、評価されたトップランク項目の数を示し、したがって、異なるレベルにおける検索システムの精度についての洞察を提供する。例えば、NDCG@10は上位5項目のランキングを評価する。
オフラインユースのためのベクターデータベースの最適化
ベクトルデータベースの現在の焦点は、主にRAG(Retrieval-Augmented Generation)や画像類似検索のようなオンラインアプリケーションに当てられているが、オフラインのユースケースにおけるその可能性は膨大であるが、まだ十分に活用されていない。
オンライン・アプリケーションは通常、高頻度かつ厳しいレイテンシ要件で少量のデータを扱い、コスト重視のパフォーマンス最小の環境であっても、しばしば数秒以内の応答を必要とする。逆に、オフラインアプリケーションは、データ重複排除や特徴マイニングのような大規模なデータ処理タスクを実行することが多く、タスクの実行時間は数分から数時間に及ぶこともある。
ここでは、オフラインで使用されるベクトルデータベースに関するいくつかの課題とその対処法を紹介する：
計算効率:**各クエリに対して低レイテンシを優先するオンラインユースケースとは異なり、オフラインタスクでは大量のデータバッチに対して高い計算効率が要求されます。低レイテンシーの実現は、検索や推薦システムのオフラインコンポーネントにおいて特に重要である。例えば、GPUインデクシングによって計算密度を向上させることで、これらのシナリオにおける大規模なデータクエリの処理を大幅に改善することができます。
膨大なデータ検索データ・マイニング・アプリケーションでは、ベクトル検索が特定の状況を認識するモデルを支援します。このようなタスクでは、大量のデータを検索する必要があることが多く、特に大規模なTop-K検索では、帯域幅とアルゴリズム効率の問題が生じます。このような大規模検索を管理する効率的なソリューションを開発することは、堅牢なオフラインベクターデータベースアプリケーションをサポートする上で非常に重要です。
これらの課題に取り組むことで、ベクトルデータベースはより幅広いアプリケーションをサポートできるようになり、オンライン環境以外にもその有用性を広げることができます。
多様な産業におけるベクトルデータベースのフィーチャーセットの拡張
ベクターデータベースの採用がさまざまな分野で拡大するにつれ、多様なアプリケーションに対応するため、業界固有の要件に対応した特殊な機能の開発が必要となります。ベクトルデータベースは汎用性が高いため、各分野が直面する固有の課題に合わせてパフォーマンスと機能を最適化するカスタマイズ機能が求められます。このような機能強化は、さまざまな分野特有の要件に対応し、ベクターデータベースの全体的な機能性と生産環境での汎用性を向上させます。ベクターデータベースがこのような要求を満たすためにどのように進化しているのか、いくつかの例をご紹介します：
バイオ医薬品アプリケーション:**医薬品の分子式を検索するためにバイナリーベクターを使用することは、バイオ医薬品業界では一般的になりつつあります。バイナリーベクターは、複雑な化学構造の効率的な検索とマッチングを可能にし、迅速な創薬と開発プロセスを促進します。
金融セクターのニーズ:**最も近いベクターの一致を求める多くの産業とは異なり、金融セクターではしばしば最も外れたベクターを特定する必要があります。この機能は、異常や潜在的な不正を検出するために極めて重要であり、標準からの最大の逸脱が最も高い関心を集めています。
範囲検索機能：**範囲検索は、関連する結果の正確な数が予測できないユースケースに対応するため、ユーザーが類似度のしきい値を定義することを可能にします。システムはこの閾値を超えるすべての結果を返し、検索されたデータの高い関連性と精度を保証します。
GroupbyとAggregation機能:** 映画や長い記事のような広範な非構造化データの場合、ベクトルデータベースはフレームやテキストセクションでセグメント化されたベクトルを生成し、処理する必要があります。このセグメンテーションには、結果が特定のユーザー基準を効果的に満たすことを保証する、堅牢なGroupbyおよび集計機能が必要です。
マルチモーダルモデルのサポート:** マルチモーダルモデルへの移行は、様々な分布のベクトルを導入し、従来の検索アルゴリズムに課題をもたらします。ベクターデータベースは、これらの多様なデータタイプに対応し、異なるモダリティ間での効果的な検索を保証するように進化しています。
このような業界特有の適応は、ベクトルデータベースのダイナミックな性質を浮き彫りにしています。ベクトルデータベースは、各分野における最新のアプリケーションの複雑で多様な要求を満たすために進化しています。
まとめ
この1年、ベクトルデータベースは急速な進化を遂げ、そのユースケースと本質的な機能が大きく成熟したことを反映している。AI主導の時代へと進むにつれ、これらの開発は加速し、データの保存、検索、管理におけるイノベーションの新たな波が到来する。
この概要では、ベクターデータベースの革新的なトレンドと新たな機能を明らかにし、この分野のさらなるイノベーションを促すような洞察を提供することを目的としています。このようなエキサイティングな変化を乗り越えながら、ベクターデータベースの強化に向けた集団的な旅は、私たちの技術的展望を再構築し、より洗練された効率的なデータ駆動型ソリューションを可能にすることを約束します。
ベクターデータベースの有望な未来を熱意と協力の精神で受け入れ、共に探求と革新を続けましょう。
読み続けて
Milvus 2.6.x Now Generally Available on Zilliz Cloud, Making Vector Search Faster, Smarter, and More Cost-Efficient for Production AI
Milvus 2.6.x is now GA on Zilliz Cloud, delivering faster vector search, smarter hybrid queries, and lower costs for production RAG and AI applications.
The Great AI Agent Protocol Race: Function Calling vs. MCP vs. A2A
Compare Function Calling, MCP, and A2A protocols for AI agents. Learn which standard best fits your development needs and future-proof your applications.
Vector Databases vs. Time Series Databases
Use a vector database for similarity search and semantic relationships; use a time series database for tracking value changes over time.