Milvusベクトルデータベースによるスケーラブルで高速な類似性検索
カバー画像
はじめに
この記事では、ベクターデータベースとスケールでの類似検索に関連するいくつかの興味深い側面を取り上げます。急速に進化する今日の世界では、新しいテクノロジー、新しいビジネス、新しいデータソースが登場し、その結果、これらのデータを保存、管理、活用して洞察を得るための新しい方法を使い続ける必要があります。構造化された表形式のデータは、何十年もの間、リレーショナル・データベースに保存され、ビジネス・インテリジェンスは、そのようなデータから洞察を分析し、抽出することで繁栄してきました。しかし、現在のデータ状況を考慮すると、「データの80~90%以上は、テキスト、ビデオ、オーディオ、ウェブ・サーバー・ログ、ソーシャルメディアなどの非構造化情報」である。組織は、従来のクエリベースの手法では不十分であったり、不可能であったりする可能性があるため、機械学習やディープラーニングの力を活用し、このようなデータから洞察を引き出そうとしている。このようなデータから価値ある洞察を引き出すには、未開拓の巨大な可能性があり、我々はまだ始まったばかりだ!
「世界のデータのほとんどは非構造化データであるため、それを分析し行動する能力は大きなチャンスとなる。- マイキー・シュルマン、ML責任者、Kensho
非構造化データは、その名の通り、行と列の表のような暗黙の構造を持っていない(そのため、表形式データまたは構造化データと呼ばれる)。構造化データとは異なり、非構造化データの内容をリレーショナル・データベースに格納する簡単な方法はありません。非構造化データを洞察に活用するには、主に3つの課題がある:
- ストレージ:ストレージ:通常のリレーショナル・データベースは、構造化データを保持するのに適している。そのようなデータを保存するためにNoSQLデータベースを使用することは可能だが、AIアプリケーションをスケールアップするために適切な表現を抽出するためにそのようなデータを処理することは、さらなるオーバーヘッドとなる。
- 表現:コンピュータは人間のようにテキストや画像を理解することはできない。コンピュータが理解できるのは数値だけであり、構造化されていないデータを何らかの有用な数値表現(通常はベクトルや埋め込み)に変換する必要がある。
- クエリ:構造化されていないデータは、構造化データのSQLのように、明確な条件文に基づいて直接クエリを実行することはできない。単純な例として、お気に入りの靴の写真から、似たような靴を検索しようとした場合を想像してみてほしい!生のピクセル値を検索に使うことはできないし、靴の形、サイズ、スタイル、色などの構造化された特徴を表現することもできない。これを何百万足もの靴に対して行わなければならないことを想像してみてほしい!
したがって、コンピュータが非構造化データを理解し、処理し、表現するためには、通常、エンベッディングと呼ばれる密なベクトルに変換します。
図1
画像のような視覚データには畳み込みニューラルネットワーク(CNN)、テキストデータにはTransformerなど、特にディープラーニングを活用した様々な方法論が存在する。Zillizには 、様々な埋め込み技術を網羅した素晴らしい記事がある!
さて、これらの埋め込みベクトルを保存するだけでは十分ではありません。似たようなベクトルを検索できるようにする必要があります。なぜそう思うのか?実世界のアプリケーションの大半は、AIベースのソリューションのためのベクトル類似性検索によって動いている。これには、Googleのビジュアル(画像)検索、NetflixやAmazonのレコメンデーションシステム、Googleのテキスト検索エンジン、マルチモーダル検索、データ重複排除など、多くのものが含まれる!
大規模なベクターの保存、管理、クエリーは単純な作業ではない。そのためには専用のツールが必要であり、ベクターデータベースはそのための最も効果的なツールです!この記事では、以下の点について説明します:
はじめよう
ベクトルとベクトル類似検索
先に、画像やテキストのような非構造化データをベクトルとして表現する必要性を説明しました。我々は通常、AIモデル、より具体的にはディープラーニング・モデルを活用して、非構造化データを機械が読み込める数値ベクトルに変換する。通常、これらのベクトルは基本的に浮動小数点数のリストであり、基礎となるアイテム(画像、テキストなど)を集合的に表します。
ベクトルを理解する
自然言語処理(NLP)の分野を考慮すると、Word2Vec、GloVe、FastTextなど、単語を数値ベクトルとして表現するのに役立つ多くの単語埋め込みモデルがあります。時間の経過とともに、BERTのようなTransformerモデルが台頭し、文脈に応じた埋め込みベクトルや、文全体や段落のより良い表現を学習できるようになりました。
同様にコンピュータビジョンの分野では、画像や動画などの視覚データから表現を学習するのに役立つ畳み込みニューラルネットワーク(CNN)のようなモデルがある。トランスフォーマーの台頭により、通常のCNNよりも優れた性能を発揮するビジョン・トランスフォーマーもあります。
図2
このようなベクトルの利点は、写真をアップロードして視覚的に類似した画像を含む検索結果を得るような、視覚検索のような実世界の問題解決に活用できることだ。Googleの検索エンジンでは、次の例にあるように、この機能が非常によく使われている。
図3
このようなアプリケーションは、データ・ベクトルとベクトル類似性検索によって実現される。X-Y直交座標空間上の2点を考える。2点間の距離は次の式で表される単純なユークリッド距離として計算できる。
図4
ここで、各データ点がD次元を持つベクトルであるとすると、ユークリッド距離、あるいはハミング距離や余弦距離のような他の距離メトリックスを使用して、2つのデータ点が互いにどのくらい近いかを調べることができます。これは、近さまたは類似性の概念を構築するのに役立ちます。これは、それらのベクトルを使用して参照アイテムを与えられた類似アイテムを見つけるための定量化可能なメトリックとして使用することができます。
ベクトル類似検索の理解
ベクトル類似性検索は、しばしば最近傍(NN)検索として知られ、基本的には、参照アイテム(類似アイテムを見つけたい)と既存アイテムのコレクション(通常はデータベース内)の間のペアワイズ類似性(または距離)を計算し、トップ「k」最も類似したアイテムであるトップ「k」最近傍を返すプロセスです。この類似度を計算する重要な要素は、ユークリッド距離、内積、余弦距離、ハミング距離などの類似度メトリックである。距離が小さいほど、ベクトルはより類似しています。
厳密最近傍(NN)探索の課題はスケーラビリティです。N個の距離(N個のアイテムが存在すると仮定)を毎回計算し、類似アイテムを取得する必要があります。これは、特にデータをどこかに保存してインデックスを作らないと(ベクトルデータベースのように!)、非常に時間がかかります。計算を高速化するために、私たちは通常、近似最近傍探索を利用します。これはしばしばANN探索と呼ばれ、最終的にベクトルをインデックスに格納します。このインデックスは、参照するクエリ項目に対して「近似的に」類似した近傍ベクトルを素早く検索できるように、これらのベクトルをインテリジェントな方法で格納するのに役立ちます。典型的なANNインデックス作成手法には以下のものがある:
- ベクトルの変換:ベクトル変換:ベクトルに次元削減(例えばPCA、t-SNE)、回転などの変換を加える。
- ベクトル符号化:Locality Sensitive Hashing (LSH)、量子化、ツリーなどのデータ構造に基づくテクニックを適用することで、類似アイテムの高速検索に役立ちます。
- 非網羅的検索法:これは主に網羅的検索を防ぐために使用され、近傍グラフや転置インデックスなどの手法が含まれる。
このことから、ベクトル類似検索アプリケーションを構築するためには、効率的な保存、インデックス付け、クエリ(検索)を大規模に行うことができるデータベースが必要であることがわかります。ベクターデータベースの登場です!
ベクトルデータベースとは?
ベクトルがどのように非構造化データを表現し、ベクトル検索がどのように機能するかを理解した今、ベクトルデータベースを構築するために2つの概念を組み合わせることができます。
ベクトル・データベースは、ディープラーニング・モデルを使って非構造化データ(画像、テキストなど)から生成された埋め込みベクトルを横断的に保存、インデックス付け、クエリするためのスケーラブルなデータ・プラットフォームである。
類似性検索のために膨大な数のベクトルを扱うことは(インデックスを使ったとしても)、超高コストとなる可能性がある。にもかかわらず、最良かつ最先端のベクトル・データベースは、数百万から数十億のターゲット・ベクトルの挿入、インデックス付け、検索を可能にし、さらにインデクシング・アルゴリズムと類似性メトリックを任意に指定できるはずだ。
ベクターデータベースは、企業で使用される堅牢なデータベース管理システムとして、主に以下の主要要件を満たす必要があります:
- スケーラブルであること:ベクトルデータベースは、何十億もの埋め込みベクトルに対してインデックスを作成し、近似最近傍探索を実行できる必要があります。
- 信頼性:ベクターデータベースは、データを損失することなく、運用への影響を最小限に抑えて内部障害を処理できること、すなわちフォールトトレラントであること。
- 高速性:クエリと書き込みの速度は、ベクターデータベースにとって重要である。SnapchatやInstagramのように、1秒間に何百、何千もの新しい画像がアップロードされるプラットフォームでは、スピードは非常に重要な要素になります。
ベクターデータベースはデータのベクターを保存するだけではありません。効率的なデータ構造を使ってベクトルにインデックスを付け、高速な検索を可能にし、CRUD(作成、読み込み、更新、削除)操作をサポートする役割も担っている。ベクターデータベースは、通常スカラーフィールドであるメタデータフィールドに基づくフィルタリングである属性フィルタリングもサポートするのが理想的です。簡単な例としては、特定のブランドの画像ベクトルに基づいて、似たような靴を検索するようなものです。ここで、ブランドはフィルタリングを行う属性となります。
図5
上の図は、これから説明するベクトルデータベースMilvusがどのように属性フィルタリングを使っているかを示している。Milvusでは、フィルタリングの仕組みにビットマスクの概念を導入し、特定の属性フィルタを満たすことに基づいて、ビットマスクが1の類似ベクトルを保持するようにしている。これについての詳細はこちら。
Milvus - 世界で最も先進的なベクトルデータベース
Milvusは、大規模ベクトルデータと機械学習オペレーション(MLOps)の合理化のために特別に構築されたオープンソースのベクトルデータベース管理プラットフォームです。
図6
Zillizは、次世代データファブリックの開発を加速するために、世界で最も先進的なベクトルデータベースMilvusを構築している組織です。Milvusは現在、LF AI & DataFoundationの卒業プロジェクトであり、膨大な非構造化データセットのストレージと検索の管理に焦点を当てている。このプラットフォームの効率性と信頼性により、AIモデルとMLOpsを大規模に展開するプロセスが簡素化される。Milvusは、創薬、コンピュータビジョン、レコメンデーションシステム、チャットボットなど、幅広い用途に利用されている。
Milvusの主な特徴
Milvusには、以下のような便利な機能が満載されています:
- 兆のベクトルデータセットにおける驚異的な検索速度:兆個のベクトルデータセットにおけるベクトル検索と検索の平均待ち時間はミリ秒単位で測定されています。
- 簡素化された非構造化データ管理:Milvusは、データサイエンスワークフローのために設計された豊富なAPIを備えています。
- 信頼性の高い常時稼働のベクトルデータベース:Milvusに組み込まれたレプリケーションとフェイルオーバー/フェイルバック機能により、データとアプリケーションは常にビジネスの継続性を維持することができます。
- 高い拡張性と伸縮性:コンポーネントレベルのスケーラビリティにより、オンデマンドでのスケールアップとスケールダウンが可能です。
- ハイブリッド検索:Milvusはベクトル以外にも、ブール、文字列、整数、浮動小数点数などのデータ型をサポートしています。Milvusはスカラーフィルタリングと強力なベクトル類似性検索を組み合わせています(先ほどの靴の類似性の例に見られるように)。
- 統一されたラムダ構造:Milvusはデータストレージのストリーム処理とバッチ処理を組み合わせることで、適時性と効率性のバランスを取っている。
- タイムトラベル:Milvusはすべてのデータの挿入と削除の操作に対してタイムラインを維持します。検索でタイムスタンプを指定し、指定した時点のデータビューを取得することができます。
- コミュニティでサポートされ、業界で認められています:1,000人以上の企業ユーザー、GitHub上の10.5K以上のスター、そして活発なオープンソースコミュニティにより、Milvusを使用するのはあなただけではありません。Milvus は、LF AI & Data Foundationの卒業プロジェクトとして、組織的なサポートを受けています。
ベクトルデータ管理と検索への既存のアプローチ
ベクトル類似性検索によってAIシステムを構築する一般的な方法は、近似最近傍探索(ANNS)のようなアルゴリズムと、以下のようなオープンソースライブラリを組み合わせることである:
- Facebook AI類似性検索(FAISS):このフレームワークは、密なベクトルの効率的な類似性検索とクラスタリングを可能にする。RAMに収まらないようなものまで、あらゆるサイズのベクトル集合を検索するアルゴリズムが含まれている。逆マルチインデックスや積量子化などのインデックス機能をサポートしている。
- SpotifyのAnnoy (Approximate Nearest Neighbors Oh Yeah):このフレームワークは、ランダムな投影を使用し、密なベクトルに対してスケールでANNSを可能にするためにツリーを構築する。
- GoogleのScaNN(Scalable Nearest Neighbors):このフレームワークは、効率的なベクトル類似探索を大規模に実行する。最大内積探索(MIPS)のための探索空間の刈り込みと量子化を含む実装で構成される。
これらのライブラリはそれぞれそれなりに有用ですが、いくつかの制限があるため、これらのアルゴリズムとライブラリの組み合わせは、milvusのような本格的なベクトルデータ管理システムと同等ではありません。ここでは、これらの限界のいくつかを説明する。
既存のアプローチの限界
前節で説明したように、ベクターデータを管理するために使用されている既存のアプローチには、以下のような限界があります:
- 柔軟性:柔軟性:既存のシステムは通常、すべてのデータをメインメモリに保存するため、複数のマシンで分散モードで実行することは容易ではなく、巨大なデータセットを扱うには適していません。
- 動的なデータ処理:既存のシステムに入力されたデータは静的であると想定されることが多いため、動的データの処理が複雑になり、リアルタイムに近い検索が不可能になる。
- 高度なクエリー処理:ほとんどのツールは、高度なクエリ処理(属性フィルタリング、ハイブリッド検索、マルチベクタークエリなど)をサポートしていない。これは、高度なフィルタリングをサポートする実世界の類似検索エンジンを構築するために不可欠である。
- ヘテロジニアス・コンピューティングの最適化:CPUとGPU(FAISSを除く)の両方における異種システムアーキテクチャの最適化を提供するプラットフォームはほとんどなく、効率の低下を招きます。
Milvusはこれらの制限をすべて克服しようとしており、次のセクションで詳しく説明します。
Milvusの優位性 -Knowhereの理解
Milvusは、非効率的なベクトルデータ管理と類似検索アルゴリズムの上に構築された既存システムの限界に取り組み、以下の方法で見事に解決しようとしている:
- 様々なアプリケーションインターフェース(Python、Java、Go、C++、RESTful APIのSDKを含む)をサポートすることで、柔軟性を高めています。
- 複数のベクトルインデックスタイプ(量子化ベースのインデックスやグラフベースのインデックスなど)と高度なクエリ処理をサポートします。
- Milvusは、ログ構造化マージツリー(LSMツリー)を使用して動的なベクトルデータを処理し、データの挿入と削除を効率的に行い、検索をリアルタイムに実行します。
- Milvusはまた、最新のCPUやGPUのヘテロジニアスなコンピューティングアーキテクチャのための最適化も提供しており、開発者は特定のシナリオ、データセット、アプリケーション環境に合わせてシステムを調整することができます。
Milvusのベクトル実行エンジンであるKnowhereは、システムの上位層にあるサービスや、システムの下位層にあるFaiss、Hnswlib、Annoyなどのベクトル類似検索ライブラリにアクセスするための操作インターフェースである。さらに、Knowhereはヘテロジニアス・コンピューティングも担当している。Knowhereは、インデックス構築や検索要求をどのハードウェア(CPUやGPUなど)で実行するかを制御する。これがKnowhereの名前の由来である。将来のリリースでは、DPUやTPUを含むより多くの種類のハードウェアがサポートされる予定です。
図7
Milvusの計算には主にベクトル演算とスカラー演算が含まれる。KnowhereはMilvusのベクトル演算のみを扱います。上図はMilvusにおけるKnowhereアーキテクチャを示している。一番下の層はシステム・ハードウェアです。サードパーティのインデックス・ライブラリはハードウェアの上にあります。そして、KnowhereはCGOを介して最上部のインデックス・ノードやクエリ・ノードと相互作用します。KnowhereはFaissの機能をさらに拡張するだけでなく、性能を最適化し、BitsetViewのサポート、より多くの類似性メトリクスのサポート、AVX512命令セットのサポート、SIMD命令の自動選択、その他の性能最適化など、いくつかの利点があります。詳細はこちらをご覧ください。
Milvusアーキテクチャ
以下の図は、Milvusプラットフォームの全体的なアーキテクチャを示しています。Milvusはデータフローと制御フローを分離し、スケーラビリティとディザスタリカバリの点で独立した4つのレイヤーに分かれています。
図8
- アクセス層アクセスレイヤーはステートレスプロキシ群で構成され、システムのフロントレイヤーとして、またユーザーへのエンドポイントとして機能する。
- コーディネータ・サービス:コーディネータ・サービスは、クラスタ・トポロジーのノード管理、負荷分散、タイムスタンプ生成、データ宣言、データ管理を担当する。
- ワーカーノード:ワーカーノード(実行ノード)は、コーディネータサービスによって発行された命令とプロキシによって開始されたデータ操作言語(DML)コマンドを実行します。MilvusのワーカーノードはHadoopのデータノードやHBaseのリージョンサーバに似ている。
- ストレージ:Milvusの要であり、データの永続化を担う。ストレージレイヤーは、メタストア、ログブローカー、オブジェクトストレージで構成される。
アーキテクチャの詳細はこちらをご覧ください!
Milvusでビジュアル画像検索を行う - ユースケースの青写真
Milvusのようなオープンソースのベクトルデータベースは、どのようなビジネスでも最小限のステップで独自のビジュアル画像検索システムを構築することを可能にします。開発者は、事前に訓練されたAIモデルを使用して、独自の画像データセットをベクトルに変換し、Milvusを活用して画像から類似商品を検索することができます。このようなシステムを設計・構築する方法の青写真を以下に見てみよう。
図9
このワークフローでは、towheeのようなオープンソースのフレームワークを使用して、ResNet-50のような事前に学習されたモデルを活用し、画像からベクトルを抽出し、これらのベクトルをMilvusに簡単に保存してインデックス化し、さらにMySQLデータベースに画像IDと実際の画像のマッピングを保存することができます。データがインデックス化されれば、Milvusを使用して、新しい画像を簡単にアップロードし、大規模な画像検索を実行することができます。次の図はビジュアル画像検索のサンプルである。
図10
MilvusのおかげでGitHubにオープンソース化された詳細なチュートリアルをチェックしよう。
まとめ
この記事でかなりの範囲をカバーした。オープンソースのベクトル・データベースであるMilvusを使って、非構造化データの表現、ベクトルの活用、ベクトル類似性検索を大規模に行うという課題から始めた。Milvusがどのように構造化されているか、Milvusを動かしている主要なコンポーネントの詳細と、Milvusを使ったビジュアル画像検索という現実世界の問題を解決する方法の青写真について議論した。Milvusを試してみて、現実世界の問題をMilvusで解決してみよう!
この記事が気に入りましたか?この記事を気に入っていただけましたか?
著者について
Dipanjan (DJ) Sarkarは、データサイエンスリード、Google Developer Expert - Machine Learning、著者、コンサルタント、AIアドバイザー。コネクト: http://bit.ly/djs_linkedin
- はじめに
- ベクトルとベクトル類似検索
- ベクトルデータベースとは?
- Milvus - 世界で最も先進的なベクトルデータベース
- Milvusでビジュアル画像検索を行う - ユースケースの青写真
- まとめ
- 著者について
On This Page
Try Managed Milvus for Free
Zilliz Cloud is hassle-free, powered by Milvus and 10x faster.
Get StartedLike the article? Spread the word