バックエンドエンジニアの@nasaです。最近Elasticsearchのversion8から追加された近似最近傍探索(以下ANN)を試してみたのでその話をしようと思います。

Elasticsearch version 8から追加されたknn search API にリクエストを送信して速度検証を行いましたANN自体については取り扱わないので、知りたい人はElasticsearchの公式ドキュメントを参照してください。

ANNをパッと試したときの記録があるので、実際に動かしてみたい人はこちらを参照してみてください！https://zenn.dev/nasa/scraps/fc4ba5d8e700df

検索パフォーマンス計測

この計測はぱっと検索速度の感覚を掴むことが目的だったので手元で雑に動かしたものです。手元のPCでElasticsearchやベンチマーカー以外のプロセスが動いた状態で計測しています。

計測は手元のm1 macで行いました。

• MacBook Pro (13-inch, M1, 2020)
• メモリ 16GB
• CPU 8コア

Elasticsearchについては次のようになっています。

• version: 8.1.0
• JVM version: 17.0.2
• shard数 1
• replicaなし
• 環境: 手元のPCで立ち上げている (Dockerなどは使っていない)

Elasticsearchに100回検索リクエストを送信しレスポンスタイムの平均を取りました。

Elasticsearchに保存しているドキュメント数10万件で、ベクトルは200次元、768次元で試しています。

このとき用いるベクトルはランダムに生成したものを使っています。

検索クエリは次のようになっています。取得数を増やした時にレスポンスに含まれるアイテムのフィールドやsourceが増えレスポンスタイムに影響が出るので何も取得しないようにしています。

{
    "knn": {
        "field": "vector",
        "query_vector": <ランダムに生成したベクトル>,
        "k": <取得するアイテム数>,
        "num_candidates": <探索候補となるベクトル数>
    },
    "fields": [],
    "_source": false
}

200次元

768次元

アイテム数が増えるとどれくらい遅くなるのか感覚がつかめた気がしますね。

特殊なユースケースかもしれませんが、今後Elasticsearch君にはアイテムを1万件取得するリクエストを20万件捌いてもらう予定だったのですが今回の計測でそれが無理そうなことが分かりました。

(Wantedlyのベクトル検索導入については解決したい問題の深堀り含め今後ブログにしようと思います！)

検索速度についてはこれで終わりです〜。

次はElasticsearch以外でベクトル検索を試してみます。ブログにすると思うのでまたお会いしましょう〜。

ちょっとチームのお話。推薦基盤チームでは現在ベクトル検索導入に向けて動いています。他にも大量データと戦ったり、Wantedlyの推薦を高速に改善するための取り組みとかをやっているチームです。

興味があればぜひ話を聞きに来てください！