Annoy vs Voyager：GenAIのための正しいベクトル検索ツールの選択
AI主導のアプリケーションが成長を続ける中、高速でスケーラブルなベクトル検索ツールの必要性が不可欠となっている。ベクトル検索は、推薦システム、画像検索、自然言語処理（NLP）など、高次元データ間の類似性を見つけることが重要な分野で重要な要素です。ベクトル検索に利用可能な数多くのツールの中で、AnnoyとVoyagerは広く使われている2つの選択肢であり、それぞれが明確な利点を提供している。
この記事では、AnnoyとVoyagerを比較し、それぞれの特徴、検索方法、スケーラビリティ、ユースケースに焦点を当て、どちらが自分のニーズに適しているかを判断できるようにします。
ベクターサーチとは？
AnnoyとVoyagerの詳細について説明する前に、ベクトル検索について理解しておく必要がある。簡単に言うと、ベクトル検索、またはベクトル類似性検索は、与えられたクエリベクトルに最も近いベクトル(データポイント)を高次元空間で見つける。これらのベクトルは、多くの場合、機械学習モデルによって生成され、非構造化データ(例えば、文章の意味や画像の特徴)の本質を捉える。 ；
従来のデータベース](https://zilliz.com/blog/relational-databases-vs-vector-databases)のように、完全一致やフィルタリングに基づいて検索するのとは異なり、ベクトル検索は類似性に重点を置く。目標は、距離メトリック(ユークリッド距離や余弦類似度など)に基づいて、互いに「近い」ベクトルを見つけることです。例えば、ベクトルは自然言語処理（NLP）において単語や文章を表すことができ、ベクトル検索は最も意味的に類似した単語や文章を見つけるのに役立つ。推薦システムでは、ベクトル検索はユーザーの好みに最も近いアイテムを特定する。また、ベクトル検索は、retrieval augmented generation (RAG)、大規模言語モデル(LLMs)の出力に余分な文脈情報を与えて補強する技術でも重要な役割を果たす。
ベクトル検索を実行するための多くのソリューションが市販されている：
- AnnoyやVoyagerのようなベクトル検索ライブラリ  ；
- Milvus](https://zilliz.com/what-is-milvus)、Zilliz Cloud(フルマネージドMilvus)のような目的別ベクトルデータベース。
- Chroma](https://zilliz.com/blog/milvus-vs-chroma)やMilvus Liteのような軽量ベクターデータベース。
- 従来のデータベース ベクトル検索アドオン付き。
Annoyとは？概要
Annoy](https://zilliz.com/learn/approximate-nearest-neighbor-oh-yeah-ANNOY) (Approximate Nearest Neighbors Oh Yeah)は、Spotifyによって開発されたオープンソースライブラリで、高次元空間における効率的な近似最近傍(ANN)探索のために設計されている。 Annoyの主な機能は、ベクトル埋め込みに基づいて、与えられたクエリーアイテムに似ているアイテムを素早く見つけることである。Annoyは、「十分に近い」結果を素早く見つけることよりも、完全に一致することが重要でない大規模なデータセットを扱う場合に特に有用である。ユーザーの好みに基づいて、似たようなアイテム（曲、製品、ビデオなど）を提案するレコメンデーションエンジンを構築するためによく使われる。
Annoy のコア機能と強み
- 近似最近傍探索**：Annoyは近似最近傍（ANN）検索を高速に実行することで知られており、完全一致を必要とせずに「十分に近い」結果を提供する。これは、厳密な検索では時間がかかりすぎたり、リソースを大量に消費したりするような巨大なデータセットを扱うアプリケーションで特に有用です。
- ツリーベースのインデックス作成**：Annoyはランダムな射影木を使ってデータにインデックスを付け、データをより管理しやすいサブセットに整理することで検索クエリを高速化する。
- ディスクベースのストレージAnnoyの最も価値ある特徴の一つは、インデックスをディスク上に保存することである。つまり、メモリに収まらないような大きなデータセットでも効率的にインデックスを作成し、検索することができる。Annoyのディスクベースのストレージはまた、異なるプロセス間でインデックスを共有することを可能にし、メモリ使用量の削減に貢献する。
- メモリ効率**：Annoyはメモリを効率的に使用するように最適化されています。メモリ上でインデックスを構築し、ディスク上に保存することができるため、RAMが十分でなくても大きなデータセットを扱うことができる。この機能は、システムのメモリが制約となっている場合に特に有用である。
- 不変インデックス**：一度Annoyでインデックスを作成すると、変更することはできません。データセットが変更された場合、インデックス全体を再構築する必要があります。このため、データが頻繁に変更されない静的なデータセットに適している。
- バッチ・クエリー複数のクエリーを並行して実行することができ、特に高スループットのアプリケーションでは、検索プロセスをさらに最適化するのに役立つ。
- 言語サポートAnnoyは主にPythonで使用されるが、パフォーマンス上の理由からC++で書かれている。
Annoyの強みは、そのシンプルさと、高次元のベクトル検索をスピードと効率で処理する能力にある。しかし、これらの性能向上を達成するために、ある程度の精度を犠牲にしている。
Voyagerとは？概要
VoyagerはSpotifyの最新のベクトル検索ライブラリで、Annoyの後継として設計されました。hnswlib**の上に構築されたVoyagerは、より高速で高精度、より優れたメモリ効率、より広い柔軟性を要求する最新の最近傍探索のユースケースに最適化されています。Voyagerは、より高速で、より高精度で、よりメモリ効率に優れ、より幅広い柔軟性を必要とする最新の最近傍探索ユースケースに最適化されています。
Voyager のコア機能と強み
- スピードと正確さ：Voyagerは、同じ呼び出し速度を維持しながら、Annoyの10倍以上の速度を提供します。また、同レベルのスピードで最大50%以上の精度**を実現し、パフォーマンスを損なうことなく、より正確な結果を提供します。
- メモリ効率：ボイジャーはメモリ効率が高く、E4M3 8ビット浮動小数点表現の採用により、Annoyの最大4倍のメモリ**を使用します。このため、メモリに制約のある環境に最適です。
- マルチスレッドとスケーラビリティ**：Voyagerはマルチスレッドでのインデックス作成とクエリをサポートし、高いスケーラビリティを実現しています。小規模なアプリから大規模なエンタープライズソリューションまで、Voyagerはワークロードを効率的に処理します。
- 言語サポート**：Pythonのみをサポートする多くの最近傍検索ツールとは異なり、VoyagerはPythonとJavaの両方に同一のインターフェイスを提供します。
- フォールト・トレラントでプロダクション・レディ**：Voyagerは、破損検出機能を備えたフォールトトレラントインデックスファイルを備えており、データ破損のリスクなしに大規模なデプロイメントに対応できます。
- Google Cloudとの統合**：VoyagerはGoogle Cloud ServicesのストリームベースI/Oをビルトインでサポートしており、クラウドから直接インデックスをストリームすることができます。
Voyagerは本番使用を念頭に設計されており、速度、精度、メモリ効率を提供すると同時に、強力な言語サポートとクラウドベースのインフラストラクチャとの互換性を提供します。
Annoy と Voyager の主な違い
検索方法
Annoyは近似最近傍探索にランダムプロジェクションツリーを使用し、ある程度の精度を犠牲にしてでもスピードを優先します。この方法は検索データセットが大きく、完璧な結果を必要としない場合に有効です。対照的に、Voyagerはhnswlibに基づいており、これはHNSW（Hierarchical Navigable Small World）アルゴリズムを採用している。この方式はより優れた精度と速度を提供し、特に精度が重要な場合、ほとんどのユースケースでAnnoyを凌駕します。
データ処理
Annoyは非構造化データと高次元ベクトル検索に最適化されている。そのツリーベースのアプローチは大量のデータを効率的に扱うが、構造化または半構造化データに関してはあまり柔軟ではない。一方、Voyagerはより柔軟だ。どちらもベクトルデータを扱うが、Voyagerの設計、特にマルチスレッドとGoogle Cloudとの統合は、複数のデータタイプが関係する、より複雑で大規模なデータ環境に適している。
スケーラビリティとパフォーマンス
どちらのツールもスケーラビリティに優れているが、Voyagerはマルチスレッドでのインデックス作成とクエリをサポートしており、よりスケーラビリティの高いオプションを提供している。Voyagerのフォールトトレラントインデックスファイルとクラウド互換性も、分散システムやクラウド環境でのスケーリングを容易にしている。Annoyは導入がよりシンプルで、大規模なデータセットを効率的に扱うことができるが、エンタープライズレベルのスケーラビリティやクラウドネイティブアーキテクチャにおいては堅牢性に欠ける。
柔軟性とカスタマイズ
Annoyは基本的なカスタマイズが可能だが、近似最近傍探索に主眼を置いているため、異なるデータタイプや探索手法に適応する柔軟性に限界がある。対照的に、Voyagerはカスタマイズを念頭に置いて構築されている。ユーザーは、速度、精度、レイテンシ、コストのバランスをとりながら、特定のニーズに基づいてパフォーマンスを微調整することができる。このためVoyagerは、よりカスタマイズされたソリューションを必要とするアプリケーションにより適しています。
統合とエコシステム
Annoyはスタンドアロン・ライブラリであり、より大きなエコシステムに統合するためのサポートは限られています。Pythonベースのプロジェクトではうまく機能するが、エンタープライズ環境で必要とされる広範な統合機能が欠けている。Voyagerはここで輝きを放ち、Google Cloudのようなクラウドベースのサービスとのシームレスな統合を提供し、JavaとPython**を完全にサポートしている。これにより、より大規模なデータパイプライン、機械学習ワークフロー、企業システムにVoyagerを組み込むことが容易になる。
使いやすさ
Annoyのシンプルさは最大の強みの一つである。特にPython環境で作業している場合、セットアップも使い方も簡単だ。しかし、その範囲は比較的限られている。一方、Voyagerはより多くの機能と柔軟性を提供するが、追加機能とカスタマイズオプションがあるため、学習曲線が若干高くなる。Voyagerは本番環境にも対応しており、PythonとJavaの両方に対応した広範なドキュメントが含まれているため、より複雑なシステムに統合するプロセスを容易にするのに役立つ。
コストの検討
Annoyは完全にオープンソースであり、ライセンス費用は一切かからない。しかし、大規模な環境に導入する場合は、インフラやスケーリングのコストを考慮する必要があります。Voyagerはより新しく先進的であるため、特にGoogle Cloudのようなマネージドサービスをインデックスのホスティングに使用する場合、追加コストが発生する可能性がある。とはいえ、Voyagerのメモリ効率と大規模なデータセットを処理する能力は、特にエンタープライズレベルのアプリケーションでは、時間の経過とともにコスト削減につながる可能性がある。
セキュリティ機能
Annoyにはセキュリティ機能が組み込まれていない。必要であれば、ユーザは暗号化、認証、アクセス制御を別途実装する必要がある。Voyagerは本番環境向けに設計されているため、フォールトトレラントインデックスファイルと破損検出に対するより良いサポートが含まれていますが、暗号化やアクセス制御のようなセキュリティ機能はまだツール自体の外で実装する必要があります。
Annoyを選ぶべき時
Annoyは以下のような場合に最適である：
- 小規模なプロジェクト**で、近似的な最近傍探索で十分な場合。
- 構造化データや半構造化データを扱う必要がない。
- 精度よりもスピードを優先し**、検索結果の精度はそれほど重要でない。
- メモリリソースに制約があるが、大きなデータセットを効率的に扱う必要がある。
- 最小限のセットアップで、軽量で使いやすいツールを好む。
Voyager を選ぶとき
以下のような場合は、Voyagerを選択することをお勧めします：
- 高い精度**が要求され、最近傍検索に正確な結果が必要な場合。
- 構造化、半構造化、非構造化データを扱うアプリケーションで、より柔軟性**が必要な場合。
- 大規模なクラウドベースの環境で作業しており、Google Cloudのようなクラウドサービスとのシームレスな**統合が必要です。
- あなたのプロジェクトは、検索アルゴリズムとデータ処理をカスタマイズするオプションと、スピード、精度、コストのバランスをとる必要があります。
- PythonとJavaの両方を強力にサポートし、堅牢なフォールトトレランス機能を備えたプロダクション対応ソリューションが必要です。
ベクトル検索ライブラリと専用ベクトルデータベースの比較
AnnoyやVoyagerのようなベクトル検索ライブラリも、Milvusのような目的別ベクトルデータベースも、高次元ベクトルデータの類似性検索問題を解決することを目的としていますが、その役割は異なります；
ベクトル検索ライブラリは、効率的な最近傍探索のタスクにのみ焦点を当てています。これらのライブラリは、クエリベクトルに類似したベクトルを見つけるための軽量で高速なソリューションを提供します。これらのライブラリは、小規模なシングルノード環境や、静的または中程度のサイズのデータセットを扱うアプリケーションでよく使用されます。しかし、一般的に、動的データの管理、永続性の提供、分散システム間でのスケーリングなどの機能が欠けている。これらのライブラリを使用する開発者は、通常、データ管理、更新、スケーリングを手動で処理する必要がある。
一方、MilvusやZilliz Cloud（マネージドMilvus）のような目的別ベクトルデータベースは、大規模なベクトルデータ管理のために設計された包括的なシステムです。これらのデータベースは単純なベクトル検索にとどまらず、永続ストレージ、リアルタイム更新、分散アーキテクチャ、高度なクエリ機能などの機能を提供している。これらのデータベースは動的なデータセットをサポートし、データが頻繁に更新されるリアルタイムアプリケーションを容易に扱うことができます。さらに、ベクターデータベースには、ベクター検索と従来のフィルタリングやメタデータクエリを組み合わせるための統合サポートが含まれていることが多く、スケーラビリティ、高可用性、より複雑な検索機能を必要とする本番環境に最適です。
- Zilliz Cloudの最新の新機能と機能強化をご覧ください：Zilliz Cloudアップデート：マイグレーションサービス、Fivetranコネクター、マルチレプリカ、その他
各ベクトル検索ソリューションを選択するタイミング
ベクターサーチ・ライブラリー**を選択する場合：
- 小規模から中規模の比較的静的なデータセットを持っている。
- インデックス作成と検索アルゴリズムを完全にコントロールしたい。
- 既存のシステムに検索を組み込み、インフラを管理できる。
目的別ベクターデータベース**を選択する場合：
- 分散システムで数十億ベクトルまで拡張する必要がある。
- データセットが頻繁に変更され、リアルタイムの更新が必要な場合。
- ストレージ、スケーリング、クエリの最適化を代行してくれるマネージドソリューションを好む。
まとめると、ベクトル検索ライブラリ は、スピードとメモリ効率が優先されるが、運用の複雑さは最小限の、よりシンプルで小規模なユースケースに最適である。これとは対照的に、目的別ベクターデータベース は、動的なデータ処理、スケーラビリティ、使いやすさが要求される大規模なプロダクショングレードのシステム向けに設計されており、多くの場合、複雑なアプリケーションを管理する開発者に大きな運用上のメリットをもたらします。
あらゆるベクトル検索ソリューションの評価と比較
さて、さまざまなベクトル検索ソリューションの違いはわかった。次の疑問は、検索アルゴリズムが正確な結果を確実に、しかも高速に返すにはどうすればいいか？様々なANNアルゴリズムの有効性を、特に規模に応じてどのように評価するか？
これらの質問に答えるには、ベンチマークツールが必要である。そのようなツールは数多くあるが、最も効率的なものとして2つが挙げられる：**ANNベンチマーク](https://zilliz.com/glossary/ann-benchmarks)とVectorDBBenchである；
ANNベンチマーク
ANN Benchmarks](https://zilliz.com/glossary/ann-benchmarks) (Approximate Nearest Neighbor Benchmarks)は、様々な近似最近傍(ANN)アルゴリズムの性能を評価・比較するために設計されたオープンソースプロジェクトです。高次元ベクトル探索などのタスクで異なるアルゴリズムをベンチマークするための標準化されたフレームワークを提供し、開発者や研究者が様々なデータセットで探索速度、精度、メモリ使用量などのメトリクスを測定することを可能にします。ANN-Benchmarksを使うことで、Faiss、Annoy、HNSWlibなどのライブラリにあるようなアルゴリズムの速度と精度のトレードオフを評価することができます。
ANN Benchmarks GitHubリポジトリ： https://github.com/erikbern/ann-benchmarks
ANNベンチマークウェブサイト： https://ann-benchmarks.com/
VectorDBBench: オープンソースのベンチマークツール
VectorDBBenchは、高性能なデータ保存・検索システム、特にベクトルデータベースを必要とするユーザーのために設計されたオープンソースのベンチマークツールです。このツールにより、ユーザは独自のデータセットを用いてMilvusやZilliz Cloud(マネージドMilvus)などの異なるベクトルデータベースシステムの性能をテスト・比較し、ユースケースに最も適したものを決定することができる。VectorDBBenchはPythonで書かれており、MITオープンソースライセンスの下でライセンスされている。
VectorDBBench GitHubリポジトリ**: https://github.com/zilliztech/VectorDBBench
VectorDBBench Leaderboard](https://zilliz.com/vector-database-benchmark-tool?database=ZillizCloud%2CMilvus%2CElasticCloud%2CPgVector%2CPinecone%2CQdrantCloud%2CWeaviateCloud&dataset=medium&filter=none%2Clow%2Chigh&tab=1).** で主流のベクターデータベースのパフォーマンスを簡単に見てみよう；
VectorDB評価のテクニックと洞察：
- ベンチマークベクターデータベースのパフォーマンス：テクニックと洞察](https://zilliz.com/learn/benchmark-vector-database-performance-techniques-and-insights)
- ベクターデータベースを他のデータベースと比較する](https://zilliz.com/comparison)
VectorDB、GenAI、MLに関するその他のリソース
- ジェネレーティブAIリソースハブ｜Zilliz](https://zilliz.com/learn/generative-ai)
- あなたのGenAIアプリのためのトップパフォーマンスAIモデル｜Zilliz](https://zilliz.com/ai-models)
- RAGとは](https://zilliz.com/learn/Retrieval-Augmented-Generation)
- 大規模言語モデル(LLM)を学ぶ](https://zilliz.com/learn/ChatGPT-Vector-Database-Prompt-as-code)
- ベクトルデータベース101](https://zilliz.com/learn/what-is-vector-database)
- 自然言語処理(NLP)](https://zilliz.com/learn/introduction-to-natural-language-processing-tokens-ngrams-bag-of-words-models)
Chloe WilliamsChloe Williams is a technical writer at Zilliz.
読み続けて
Zilliz Cloud Now Available in Azure North Europe: Bringing AI-Powered Vector Search Closer to European Customers
The addition of the Azure North Europe (Ireland) region further expands our global footprint to better serve our European customers.
Why I’m Against Claude Code’s Grep-Only Retrieval? It Just Burns Too Many Tokens
Learn how vector-based code retrieval cuts Claude Code token consumption by 40%. Open-source solution with easy MCP integration. Try claude-context today.
Demystifying the Milvus Sizing Tool
Explore how to use the Sizing Tool to select the optimal configuration for your Milvus deployment.
The Definitive Guide to Choosing a Vector Database
Overwhelmed by all the options? Learn key features to look for & how to evaluate with your own data. Choose with confidence.