AnnoyはApproximate Nearest Neighbors Oh Yeahの略で、Spotifyのエンジニアだったエリック・バーンハードソンが2013年に公開したオープンソースの近似最近傍探索ライブラリです。音楽レコメンドにおけるユーザ・楽曲埋め込みの近傍探索を高速化するために開発され、今もPython、Java、Ruby、Goなど多言語のバインディングを伴って広く使われています。本稿ではAnnoyのアルゴリズム、典型的な使い方、現代のベクトルDBとの位置づけを順に整理します。
この記事の目次
- ランダム射影木が支える検索アルゴリズム
- ファイルベースの設計と運用
- 現代のベクトルDBとの位置づけ
- Annoyを今使うべき場面
- まとめ
ランダム射影木が支える検索アルゴリズム
Annoyの核となるのは、ランダムなハイパープレーンで空間を二分する木を多数構築し、それぞれの木で近傍候補を集める「ランダム射影木フォレスト」と呼ばれるアルゴリズムです。クエリ時には各木を辿って葉ノードのリーフ集合を抽出し、すべての木の候補を統合してから正確な距離を計算してトップKを返す、という二段構えで動きます。
距離関数はユークリッド、コサイン、マンハッタン、ハミング、ドット積など複数から選べ、次元数は数百〜数千でも実用的に扱えます。木の本数を増やすほどリコールが上がりますが、構築時間とメモリ使用量も比例して増えるため、ワークロードに応じてバランスを取るのが基本の使い方です。
ファイルベースの設計と運用
Annoyの特徴は、構築済みインデックスをsaveでファイルに書き出し、別プロセスからload時にmmapで共有メモリ的に読み込める点です。本番では一度学習・構築したインデックスファイルを複数のサーバプロセスに配布し、ワーカープロセスごとにメモリを増やさずに近傍探索を提供する、という運用が定番でした。
SpotifyではユーザIDや楽曲IDを整数で扱い、Annoyに対応させたインデックスを構築することで、「あなたが好きな楽曲に似た楽曲」「あなたに似たユーザ」の計算を分散ジョブとオフラインで行い、結果を別ストレージへ保存してオンラインに反映する、という流れを長く運用してきました。FaissがGPU活用を強みとするのに対し、AnnoyはCPUのみで枯れた挙動を期待できる安心感が魅力です。
現代のベクトルDBとの位置づけ
Annoyは10年以上の運用実績があり、その間にHNSW、NSG、ScaNN、CAGRAといったより高性能なグラフ系・量子化系のANNアルゴリズムが登場しました。リコールとレイテンシの両面ではHNSWの方が優れる場面が多いものの、Annoyは「インデックスのファイルサイズが小さく、mmapで扱いやすい」という独自の長所が残り、サーバレス環境やエッジ環境でのオフライン推論に強みを発揮します。
FaissがMeta、ScaNNがGoogle、CAGRAがNVIDIAから出てきたのに対し、AnnoyはSpotify発という出自そのものが「現実のレコメンドシステムでの実戦投入」を示しています。新規プロジェクトの第一選択肢ではなくなりつつあるものの、教科書的なANN教材や、軽量ライブラリとしての価値は失われていません。
Annoyを今使うべき場面
Annoyが今でも有効な場面は、たとえば「インデックスが数百MB程度に収まり、オフラインバッチで構築して読み取り専用で配るだけ」のような用途や、Lambdaや組み込み環境のように、追加の永続化サーバを立てたくないケースです。PyPIからpip install annoyで導入でき、依存関係が極端に少ない点もリスクの少なさにつながります。
一方、オンラインでドキュメントが追加・削除され、フィルタ付き検索やマルチテナンシーが必要な現代のRAG用途では、QdrantやWeaviate、Milvusのようなフル機能のベクトルDBに譲ります。「読み取り中心・低運用負荷・小〜中規模」のANNを必要とするタスクで、Annoyは今も第一線で使える堅実なライブラリです。
まとめ
AnnoyはSpotifyのレコメンドから生まれた老舗のANNライブラリで、ランダム射影木とmmap前提の運用が独自の強みを支えます。最新のベクトルDBが台頭した今でも、軽量さと安定性を求めるシナリオで現役の選択肢として価値を保ち続けています。
※本記事はIT用語辞典の手書きドラフトです。公開前に最新情報・出典を確認のうえ加筆修正してください。
コメント