学習
高速ベクトル探索

迷惑とは何か？

Jan 06, 20251 分で読めます

Annoyは、高次元ベクトル空間における高速な近似最近傍探索のために設計された、軽量でオープンソースのライブラリです。

シリーズ全体を読む

今日の組織は、パーソナライズされた顧客体験を提供しようと試みており、多くの場合、製品やコンテンツを提案するために推薦エンジンに依存している。ストリーミング・プラットフォームやeコマース・サイトで一般的に使用されているこれらのエンジンは、最近傍探索(NNS)やベクトル類似性探索のような技術を活用して、大規模なデータセットを処理し、ユーザーの好みに合わせた正確な結果を提供する。

NNSは、ユークリッド距離 (L2)、余弦類似度、またはドット積のようなメトリックを使用して、多次元空間内のクエリに最も近いデータポイントを識別します。NNSの特殊な形態であるベクトル類似探索は、高次元空間におけるベクトル埋め込み間の距離を比較し、それらの関連性を効率的に計算する。膨大なデータセットを扱う場合、近似最近傍探索([ANNS])(https://zilliz.com/glossary/anns)は精度を犠牲にすることなく探索を高速化し、Annoyのようなアルゴリズムはそのシンプルさ、スピード、スケーラビリティで知られている。この記事では、Annoyとその機能、使用例について説明する。

Annoyとは？

Annoy (Approximate Nearest Neighbors Oh Yeah) は、高次元データセットの類似データ点を見つけるという課題に取り組むために設計されたオープンソースライブラリです。近似最近傍探索アルゴリズムを用いて、クエリと類似するデータ点を高速かつコスト効率よく見つける方法を提供します。

Spotifyは、ユーザーにパーソナライズされたおすすめ音楽をリアルタイムで提供するためにAnnoyを開発した。 Spotifyは、曲の埋め込みの膨大なデータセットを扱うことができ、過剰なメモリを消費することなく、高速で近似的な結果を提供できるツールを必要としていた。ユーザーの事前の検索や好みに基づいて、Annoyは音楽の類似検索を素早く実行し、ユーザーが好きそうな新しい曲、アーティスト、プレイリストを提案することができる。大規模な推薦システム、画像類似タスクなどで広く利用されている。

Annoyの紹介ビデオ：

Annoyの仕組み

Annoyの核心は、ツリーベースのインデックスにある。Annoyはベクトル空間を複数のランダムな射影木に分割してインデックスを作成する。各ツリーはデータセットをランダムな超平面に沿って再帰的に分割することで構築され、結果としてバイナリ構造になる。これらの木は多様なデータビューを提供し、集合的に検索時の効率的な近似を可能にする。

Annoyはクエリを実行する際、検索空間を絞り込むために複数のツリーを並行して走査する。すべてのツリーからの結果は、クエリーベクトルに最も近い近傍を近似するために結合される。このアプローチは、速度のために正確さを犠牲にしているため、正確さが効率と引き換えになるリアルタイムアプリケーションに最適である。

Annoyの主な特徴はメモリ効率である。メモリマップされたファイルを活用することで、システムのメモリよりはるかに大きなデータセットを扱い、必要なものだけをRAMにロードすることができる。さらに、ツリーの数（n_trees）や探索するノードの数（search_k）といったパラメータを調整できるため、ユーザーは精度と速度のバランスを取ることができる。

Annoyは近似的な性質を持っているため、厳密な結果を必要とするタスクには適していないが、スケーラビリティ、シンプルさ、ディスクベースの機能により、軽量で高性能なベクトル検索アプリケーションには万能な選択肢となる。特に推薦システム、クラスタリング、リアルタイムの類似性クエリに効果的である。

Annoyの仕組みと実装方法については、以下のブログを参照：

近似最近傍Oh Yeah (Annoy) - Zilliz Learn](https://zilliz.com/learn/approximate-nearest-neighbor-oh-yeah-ANNOY)

Annoy の主な機能

Annoy (Approximate Nearest Neighbors Oh Yeah) は、高次元ベクトル空間における近似類似探索を高速に行うための、軽量で効率的なライブラリです。以下はAnnoyが開発者に選ばれている主な特徴です：

高速な近似類似検索

Annoyは複数のランダムな射影木を使ってベクトル空間を分割し、速度を最適化する。クエリ中にツリーをトラバースすることで、データの小さなサブセットを検索し、最近傍探索に必要な時間を大幅に短縮します。このため、推薦システムや検索エンジンなど、迅速な応答が重要なアプリケーションに最適である。

スピードと精度のバランスをカスタマイズ可能

Annoyは、開発者が特定の要件に合わせてパフォーマンスを調整することができます：

ツリー数 (n_trees)**：ツリーの数を増やすと検索精度が向上するが、クエリ中に必要なストレージと計算量が増える。
Search Effort (search_k)：このパラメータは、システムがクエリ中に評価する候補点の数を決定します。値が高いほど精度が向上しますが、その代償としてクエリー時間が長くなります。

ディスクベースのインデックス作成

Annoyの際立った特徴の一つは、ディスクベースインデックスのサポートである。インデックスをファイルとして保存し、メモリマップすることで、インデックス全体をメモリにロードすることなく、大規模なデータセットをクエリできる。クエリ中にインデックスの関連部分のみがロードされるため、数百万のベクトルを持つデータセットに対する効率的な操作が可能になる。

効率的なメモリ使用

Annoyはメモリ効率を最大化するように設計されています。ディスクにインデックスを保存し、必要に応じてロードする機能により、RAMが制約となる大規模アプリケーションに適しています。

複数ツリーによる堅牢性

Annoyは、ベクトル空間の多様な分割ビューを提供するために、複数の独立したツリーを構築します。各ツリーはランダムな超平面に沿ってデータを分割し、より広いカバレッジを確保し、検索中に関連する近傍を見逃す可能性を低減する。この機能により、Annoyは近似的な設定でも高い再現率を達成できる。

Annoyの課題と限界

Annoyは近似最近傍探索に大きな利点を提供する一方で、特定のユースケースへの適合性に影響を与える可能性のあるいくつかの制限がある：

1.精度とスピードのトレードオフ:1.

Annoyの主な焦点は速度であり、これは近似検索によって達成される。これは多くのアプリケーションにとって効率的であるが、時には関連性の低い結果を返すこともある。検索工数（search_k）を増やすことで精度を向上させることができるが、その代償として検索時間が遅くなる。このトレードオフは、アプリケーションの優先順位に基づいて慎重にチューニングする必要がある。

**2.高精度のための長いビルド時間

Annoyは高精度を達成するために複数のツリー(n_trees)を構築し、インデックス構築時間を増加させる。全てのツリーはクエリ中に走査されるため、ツリーの数が多くなるとクエリ処理時間も長くなる。このため、Annoyは高精度と低レイテンシの両方を要求するアプリケーションでは効率が悪くなる。

3.動的なデータセットには適さない。

Annoyは頻繁な更新を必要とする動的なデータセットには向いていない。更新の度にインデックス全体の再構築と保存が必要となり、時間とリソースを消費する。この制限により、Annoyは静的なデータセットや更新頻度の低いデータセットに適している。

**4.低次元データにおける最適なパフォーマンスとは言えない。

Annoyのツリーベースのアプローチは、ランダムな投影がデータを分割する高次元ベクトル空間に最適化されている。しかし、低次元のデータセットでは、HNSWlibのようなグラフベースの手法に性能が劣る可能性がある。

**5.GPUアクセラレーションの欠如

AnnoyはGPUアクセラレーションをサポートしておらず、CPUベースの計算のみに依存しています。大規模なデータセットを高速に検索する必要があるユースケースでは、これがボトルネックになる可能性がある。GPUやTPU環境に最適化されたFaissやScaNNのような選択肢は、このような状況でより良いパフォーマンスを提供する。

Annoy と他のベクトル検索ライブラリとの比較

Annoy 以外に広く使われているベクトル探索ライブラリには、HNSWlib、Faiss、ScaNN があります。各ライブラリは近似最近傍探索を実現するために、それぞれ異なる手法を採用しています：

Annoy**はツリーベースのアプローチで、複数のランダムな射影ツリーを作成し、高速で近似的な検索を行います。
HNSWlib**](https://zilliz.com/learn/learn-hnswlib-graph-based-library-for-fast-anns)はグラフベースで、HNSW(Hierarchical Navigable Small World)グラフを利用して高精度で効率的な検索を行います。
Faiss](https://zilliz.com/learn/faiss)は、Meta社によって開発され、特にGPU環境での大規模な類似検索に最適化されています。
Googleによって開発されたScaNNは、TPUとGPUプラットフォームの両方におけるスケーラビリティとハードウェアアクセラレーションに焦点を当てている。

| ----------- | --------------------------------- | ----------------------------- | ------------------------------- | ------------------------------- | | ライブラリ | スピード | メモリー使用量 | 精度 | ディスクベース機能 | | 高速（ツリー数に依存）｜低（メモリ・マッピング）｜中（おおよそ、調整可能）｜はい：メモリ・マッピングをサポートします。 |

| Faiss｜非常に高速（GPU用に最適化）｜中・高（チューニング可能）｜高（複数インデックスの量子化）｜あり：ディスクベースのオプションに制限あり｜なし｜あり：ディスクベースのオプションに制限あり | ScaNN｜非常に高速（アクセラレータに最適化）｜高（インメモリ）｜高（再順位付けあり）｜なし｜｜｜。

Annoyはオフラインのインデックス作成とメモリマッピングが特徴で、大規模な電子商取引のカタログや音楽ライブラリのようなメモリ制限を超えるデータセットに適しています。高い精度とパフォーマンス**を求めるのであれば、FaissやScaNNのようなライブラリが理想的です。HNSWlib は、メモリ使用量が制約にならない場合、ほぼ正確な検索に最適です。ScaNNは、TPUやGPUなどのアクセラレータに最適化された環境で最もよく機能し、要求の厳しいアプリケーションにスケーラビリティを提供します。

ベクトル検索ライブラリとベクトルデータベースの使い分け

ベクトルベースのデータの採用が増えるにつれて、開発者はベクトル検索ライブラリとベクトルデータベースのどちらを使うかを決めることが多い。どちらも高次元空間で最近傍を見つけるという目的は果たしますが、異なるニーズやユースケースに対応します。

Annoy、Faiss、HNSWlib、ScaNNなどのベクトル検索ライブラリは、近似最近傍(ANN)検索用に設計された軽量ツールです。これらのライブラリは、シンプルさとスピードが優先される研究、プロトタイピング、小規模なアプリケーションによく使用されます。これらのライブラリは効率的なインメモリ操作を提供するため、1台のマシンのメモリ内に収まるデータセットに最適です。さらに、FaissやScaNNのようなライブラリはGPUまたはTPUアクセラレーションを提供し、計算集約的なタスクのための高性能検索を可能にします。

しかし、ベクトル検索ライブラリには限界がある。分散処理のサポートが組み込まれていないため、大規模なデータセットや、フォールトトレランスやレプリケーションを必要とするアプリケーションには適していない。さらに、データセットの動的更新はサポートされていないことが多く、データが変更されるとインデックスの完全な再構築が必要になる。

対照的に、Milvusのようなベクトルデータベースは、大規模なベクトルデータを管理・検索することを目的として構築されている。分散インデックス、リアルタイムインジェスト、ベクトル類似度とメタデータフィルタリングを組み合わせたハイブリッド検索のサポート、密と疎ベクトル検索と全文検索を組み込んだハイブリッド検索などの堅牢な機能を提供し、実運用環境向けに設計されている。これらのデータベースはスケーラブルで、複数のノードで数十億のベクトルを扱うことができ、最新のデータパイプラインとシームレスに統合することができる。

ベクターデータベースは強力ですが、欠点がないわけではありません。分散ベクターデータベースをセットアップするには、軽量ライブラリに比べてより多くの計算リソースとインフラが必要です。しかし、フォールトトレランス、ロールベースアクセスコントロール(RBAC)、レプリケーションなどの運用上の利点があるため、レコメンデーションシステム、セマンティック検索エンジン、異常検知などの大規模なアプリケーションには欠かせない。

結論として、ベクトル検索ライブラリは、実験や研究、または永続的なストレージや動的な更新を必要としない小規模なデータセットに最適な選択肢である。一方、ベクターデータベースは、大規模なデータ、頻繁な更新、スケーラビリティ、ハイブリッド検索、フォールトトレランスなどの運用要件を備えたプロダクショングレードのアプリケーションに優れている。

要約

Annoyは軽量なオープンソースライブラリで、高次元ベクトル空間における高速な近似最近傍探索のために設計されている。主な特徴として、大規模なデータセットを扱うためのディスクベースのインデックス、速度と精度のバランスをとるための調整可能なパラメータ、効率的なメモリ使用などがある。Annoyはインデックスを事前に計算できる静的なデータセットに最適であり、推薦システム、コンテンツ検索、リアルタイムの類似検索などのアプリケーションに理想的である。しかし、頻繁な更新や分散処理を必要とする動的で大規模なエンタープライズグレードのアプリケーションには、Milvusのような専用に構築されたベクトルデータベースの方が適しているかもしれない。

article.updateAt

Fendy Feng
Fendy Feng is the Technical Marketing Writer at Zilliz. She has extensive experience developing and enhancing the impact of open-source projects in various global markets by producing high-quality, tailored content. Before joining Zilliz, Fendy worked as a Content Strategist at PingCAP, a fast-growing E-Series startup renowned for its open-source distributed SQL database.
ShriVarsheni R

無料で始めて、簡単にスケール

あなたのGenAIアプリケーションのために構築されたフルマネージドのベクトルデータベースを試してみてください。

Zilliz Cloudを無料で試す

この記事を共有

読み続けて

筏か否か？クラウドネイティブデータベースにおけるデータ一貫性のベストソリューション

PaxosやRaftのようなコンセンサスに基づくアルゴリズムが、なぜ銀の弾丸ではないのかを説明し、コンセンサスに基づくレプリケーションの解決策を提案する。

ベクターデータベースにおける高度なクエリー技術

ベクトルデータベースは、ANN、マルチベクトル、範囲検索などの高度なクエリ技術によってAIアプリケーションを強化し、データ検索の速度と精度を向上させる。

Zillizでレキシカル検索とセマンティック検索を使いこなす

レキシカルサーチとセマンティックサーチの仕組み、応用、メリット、そしてZillizでの実行方法を学びます。