データサイエンティストと共にプロダクトの継続的な成長を支える推薦基盤チーム | Wantedly Engineer Blog
Wantedly Visitの検索基盤チームの一條です。普段はData EngineerやMLOpsに取り組んでいます。Wantedlyではユーザーと企業のマッチングをより良いものにするために募...
https://www.wantedly.com/companies/wantedly/post_articles/310799
Photo by Mick Haupt on Unsplash
バックエンドエンジニアの@nasaです。最近Elasticsearchのversion8から追加された近似最近傍探索(以下ANN)を試してみたのでその話をしようと思います。
Elasticsearch version 8から追加されたknn search API にリクエストを送信して速度検証を行いましたANN自体については取り扱わないので、知りたい人はElasticsearchの公式ドキュメントを参照してください。
ANNをパッと試したときの記録があるので、実際に動かしてみたい人はこちらを参照してみてください!https://zenn.dev/nasa/scraps/fc4ba5d8e700df
この計測はぱっと検索速度の感覚を掴むことが目的だったので手元で雑に動かしたものです。手元のPCでElasticsearchやベンチマーカー以外のプロセスが動いた状態で計測しています。
計測は手元のm1 macで行いました。
Elasticsearchについては次のようになっています。
Elasticsearchに100回検索リクエストを送信しレスポンスタイムの平均を取りました。
Elasticsearchに保存しているドキュメント数10万件で、ベクトルは200次元、768次元で試しています。
このとき用いるベクトルはランダムに生成したものを使っています。
検索クエリは次のようになっています。取得数を増やした時にレスポンスに含まれるアイテムのフィールドやsourceが増えレスポンスタイムに影響が出るので何も取得しないようにしています。
{
"knn": {
"field": "vector",
"query_vector": <ランダムに生成したベクトル>,
"k": <取得するアイテム数>,
"num_candidates": <探索候補となるベクトル数>
},
"fields": [],
"_source": false
}
アイテム数が増えるとどれくらい遅くなるのか感覚がつかめた気がしますね。
特殊なユースケースかもしれませんが、今後Elasticsearch君にはアイテムを1万件取得するリクエストを20万件捌いてもらう予定だったのですが今回の計測でそれが無理そうなことが分かりました。
(Wantedlyのベクトル検索導入については解決したい問題の深堀り含め今後ブログにしようと思います!)
検索速度についてはこれで終わりです〜。
次はElasticsearch以外でベクトル検索を試してみます。ブログにすると思うのでまたお会いしましょう〜。
ちょっとチームのお話。推薦基盤チームでは現在ベクトル検索導入に向けて動いています。他にも大量データと戦ったり、Wantedlyの推薦を高速に改善するための取り組みとかをやっているチームです。
興味があればぜひ話を聞きに来てください!