ベクトル検索の実用化における6つの重要な課題

アプリケーション、製品、またはビジネスでベクトル検索を使用することを決定しました。埋め込みとベクトル検索によって、どのように、またなぜ問題を解決できるのか、または新しい機能を実現できるのかを調査しました。近似最近傍アルゴリズムとベクトル データベースという、注目の新興分野に足を踏み入れました。

ベクトル検索アプリケーションを製品化するとすぐに、非常に困難で、予期しない問題に遭遇することになります。このブログでは、皆さんの将来、直面する問題、そしてまだ知らないが尋ねる必要がある質問についての知識を皆さんに提供しようとしています。

1. ベクトル検索≠ベクトルデータベース

ベクトル検索とそれに関連するすべての巧妙なアルゴリズムは、ベクトルを活用しようとするあらゆるシステムの中心的なインテリジェンスです。しかし、それを最大限に有効活用し、実稼働に対応できるようにするための関連インフラストラクチャはすべて膨大であり、非常に過小評価されがちです。

できるだけ強く言うと、製品版のベクトル データベースは、「ベクトル」の問題よりも「データベース」の問題をはるかに多く解決します。ベクトル検索自体は決して「簡単な」問題ではありません (以下で多くの難しいサブ問題を取り上げます) が、ベクトル データベースが解決する必要がある従来のデータベースの問題の山は、確かに「難しい部分」のままです。

データベースは、原子性やトランザクション、一貫性、パフォーマンスやクエリの最適化、耐久性、バックアップ、アクセス制御、マルチテナント、スケーリングやシャーディングなど、非常に現実的でよく研究された多くの問題を解決します。ベクター データベースは、あらゆる製品、ビジネス、企業に対して、これらすべての側面での回答を必要とします。

自家製の「ベクトル検索インフラ」には十分注意してください。最先端のベクトル検索ライブラリをダウンロードして、興味深いプロトタイプに向けて近似最近傍法を開始するのはそれほど難しくありません。ただし、この道を進み続けると、誤って独自のデータベースを再発明することになります。これはおそらく意識的に行うべき選択です。

2. ベクトルの増分インデックス

最新の ANN ベクトル検索アルゴリズムの性質上、ベクトル インデックスを段階的に更新することは非常に困難です。これはよく知られている「難しい問題」です。ここでの問題は、これらのインデックスが高速検索のために慎重に編成されており、新しいベクトルで段階的に更新しようとすると、高速検索の特性が急速に低下することです。そのため、ベクトルが追加されても高速検索を維持するには、これらのインデックスを定期的に最初から再構築する必要があります。

新しいベクトルを継続的にストリーミングし、ベクトルがインデックスにすばやく表示され、クエリが高速のままである必要があるアプリケーションでは、「増分インデックス」の問題に対する本格的なサポートが必要になります。これは、データベースについて理解する上で非常に重要な領域であり、多くの難しい質問をするのに適した場所です。

データベースがこの問題を解決するために採用する可能性のあるアプローチは多数あります。これらのアプローチを適切に調査するには、このサイズのブログ投稿を何件も書く必要があります。データベースのアプローチの技術的な詳細の一部を理解することは重要です。アプリケーションで予期しないトレードオフや結果が生じる可能性があるためです。たとえば、データベースが一定の頻度で完全な再インデックスを実行することを選択した場合、CPU 負荷が高くなり、クエリの待ち時間に定期的に影響する可能性があります。

アプリケーションが増分インデックス作成を必要としていること、およびサービス提供に使用しているシステムの機能について理解する必要があります。

3. ベクトルとメタデータの両方のデータ遅延

すべてのアプリケーションは、データ遅延の必要性と許容範囲を理解する必要があります。ベクターベースのインデックスは、少なくとも他のデータベース標準と比較すると、インデックス作成コストが比較的高くなります。コストとデータ遅延の間には大きなトレードオフがあります。

ベクトルを「作成」してから、インデックスで検索できるようになるまでにどのくらいの時間がかかりますか? すぐに必要な場合、ベクトルのレイテンシはこれらのシステムの主要な設計ポイントになります。

同じことがシステムのメタデータにも当てはまります。一般的なルールとして、メタデータの変更はかなり一般的です (たとえば、ユーザーがオンラインかどうかの変更)。そのため、メタデータ フィルター クエリがメタデータの更新に迅速に反応することが非常に重要になります。上記の例で言えば、ベクター検索で最近オフラインになったユーザーに対するクエリが返されても役に立ちません。

ベクトルをシステムに継続的にストリーミングしたり、それらのベクトルのメタデータを継続的に更新したりする必要がある場合は、たとえば翌日に使用するために毎晩完全なインデックスを再構築することがユースケースで許容される場合とは異なる、基盤となるデータベース アーキテクチャが必要になります。

4. メタデータフィルタリング

私は、この点を強く主張します。ほとんどすべての状況において、基礎となるベクトル検索インフラストラクチャをメタデータ フィルタリング (またはハイブリッド検索) によって拡張できれば、製品エクスペリエンスが向上すると思います。

10 マイル以内に位置し、低価格から中価格帯 (メタデータ フィルター) の、好みに合う可能性のあるレストラン (ベクトル検索) をすべて表示します。

このクエリの 2 番目の部分は、従来の SQL のようなWHERE句と、最初の部分のベクトル検索結果が交差する部分です。これらの大規模で比較的静的、比較的モノリシックなベクトル インデックスの性質上、ベクトル + メタデータの結合検索を効率的に行うことは非常に困難です。これは、ベクトル データベースがユーザーに代わって解決する必要がある、よく知られている「困難な問題」の 1 つです。

データベースがこの問題を解決するために採用する技術的なアプローチは数多くあります。まずフィルターを適用し、次にベクター検索を行う「事前フィルター」が可能です。このアプローチでは、事前に構築されたベクター インデックスを効果的に活用できないという欠点があります。ベクター検索をフルに実行した後で、結果を「事後フィルター」できます。これは、フィルターの選択性が非常に高い場合を除き、非常にうまく機能します。フィルターの選択性が非常に高い場合は、指定した基準を満たさないベクターを見つけるのに膨大な時間を費やし、後で除外することになります。Rockset の場合のように、メタデータ フィルタリング ステージとベクター検索ステージを統合して、両方の長所を維持する「シングル ステージ」フィルタリングを実行できる場合もあります。

メタデータ フィルタリングがアプリケーションにとって重要であると考えられる場合 (そして、私は上記でそれがほぼ常に重要であると仮定しました)、メタデータ フィルタリングのトレードオフと機能性を非常に慎重に検討する必要があります。

5. メタデータクエリ言語

私の考えが正しく、メタデータ フィルタリングが構築中のアプリケーションにとって重要である場合、おめでとうございます。また別の問題が発生します。このメタデータに対してフィルターを指定する方法が必要です。これがクエリ言語です。

データベースの観点から、そしてこれは Rockset のブログなので、私が何を言いたいのかはおそらく予想できるでしょう。SQL は、この種のステートメントを表現する業界標準の方法です。ベクター言語の「メタデータ フィルター」は、従来のデータベースの「 WHERE句」に過ぎません。異なるシステム間での移植が比較的簡単であるという利点もあります。

さらに、これらのフィルターはクエリであり、クエリは最適化できます。クエリ オプティマイザーの洗練度は、クエリのパフォーマンスに大きな影響を与える可能性があります。たとえば、洗練されたオプティマイザーは、最も選択性の高いメタデータ フィルターを最初に適用しようとします。これにより、フィルタリングの後の段階で必要な作業が最小限に抑えられ、パフォーマンスが大幅に向上します。

ベクトル検索とメタデータ フィルターを使用して重要なアプリケーションを作成する予定の場合は、使用、作成、保守するクエリ言語を人間工学と実装の両方で理解し、使いこなすことが重要です。

6. ベクターライフサイクル管理

さて、ここまで来ました。必要なデータベースの基礎をすべて備え、ユースケースに適した増分インデックス戦略を備え、メタデータ フィルタリングのニーズに関する適切なストーリーを備え、許容できるレイテンシでインデックスを最新の状態に維持するベクター データベースができました。すばらしいです。

ML チーム (または OpenAI) が埋め込みモデルの新しいバージョンを発表しました。古いベクトルで満たされた巨大なデータベースがあり、これを更新する必要があります。次は何をしますか? この大規模なバッチ ML ジョブをどこで実行しますか? 中間結果をどのように保存しますか? 新しいバージョンへの切り替えをどのように行いますか? 実稼働ワークロードに影響を与えずにこれをどのように実行する予定ですか?

難しい質問をする

ベクトル検索は急速に発展している分野であり、多くのユーザーがアプリケーションを本番環境に導入し始めています。この記事の目的は、皆さんがまだ質問すべきことを知らないかもしれない重要な難しい質問のいくつかを皆さんに知ってもらうことです。そして、それらの質問に早く答えることで、皆さんは大きな利益を得るでしょう。

この投稿では、Rockset がこれらの問題すべてをどのように解決してきたか、また現在どのように取り組んでいるか、また、これらの問題に対する当社のソリューションの一部が画期的で、最先端の他のほとんどの試みよりも優れている理由については触れませんでした。これを説明するには、このサイズのブログ投稿を多数作成する必要がありますが、まさにそれが私たちが行うことです。続きをお楽しみに。