はじめに
検索基盤グループで機械学習エンジニアをしている渡會です。
2024年10月10日に検索技術勉強会が主催する「Search Engineering Tech Talk 2024 Summer」が開催され、株式会社ビズリーチは会場スポンサーをさせていただきました。
この勉強会は、「検索」/「検索システム」に関わる技術や知識を共有する場で、UI・UXやランキング、検索エンジンなど、検索に関わるトピックを扱っています。
今回、筆者を含むビズリーチプロダクトの検索基盤グループのメンバーがイベントに参加したので、そのレポートをお届けします。
検索基盤グループは、事業成長優先で着手できていなかった「ビズリーチ」の検索システムの負債解消や検索品質の向上に取り組むため、2022年に組成された組織で、現在メンバーは10名ほどです。「ビズリーチ」をご利用いただいている企業様、ヘッドハンター様が利用する検索機能の改善に注力してます。
イベントの様子
2024年7月にオープンしたばかりの渋谷アクシュビルでの開催で、約50名の参加者が集まりました。 イベントでは、Qdrant、Elasticsearch、Vespaの活用事例の発表と、参加者の懇談会がありました。
発表内容について簡単に紹介します。
Qdrant を用いた検索改善施策の紹介
発表者：株式会社ビズリーチ 渡會
検索改善施策「ベクトルランキング」の紹介と、その仕組みを構築するための検索エンジンとAIモデルについて発表しました。ベクトルランキングは検索スコアをブースティングするアプローチで、導入コストが小さく、ユーザーのインタラクション改善への効果が期待できます。発表では、このベクトルランキングの構築方法と、検索エンジン Qdrant と Two-Tower Model の改善施策についてお話ししました。
pixivの全文検索基盤とElasticsearchによるリプレイス
発表者：ピクシブ株式会社 後藤様
pixiv の検索基盤のリプレイスの取り組みについてお話しいただきました。pixiv の検索の特徴を紹介していただいたのち、検索DBの変遷と課題、そして Elasticsearch 移行に向けた取り組みについて紹介していただきました。この取り組みに対する成果の話で、システム面の改善だけではなく、検索に関連する新機能や機能改善の話が複数部署で上がったという話が印象に残りました。
Vespaを利用したテクいベクトル検索
発表者：LINEヤフー株式会社 鈴木様
LT枠での発表で、Vespa でベクトル検索を行う際のテクニックについてお話しいただきました。従来の検索では見えてなかったベクトル検索の課題があり、その課題に対するアプローチと Vespa での実装方法について紹介されてました。発表の中でも、1つのドキュメントに複数ベクトルを紐づけるアプローチや、ベクトルの格納容量を節約するアプローチの話は筆者も直面した課題であり、対応方法や実現方法は学びになりました。
懇談会の様子
発表後に懇談会がありました！
懇談会では「検索」に関わる方々が集まり、検索技術に関する情報交換や議論が展開されていました。また、「お久しぶりです！」や「存じております〜」など、検索技術のコミュニティが密であることが伺える会話も聞こえてきました。
おまけ：「Qdrant を用いた検索改善施策の紹介」の質問に対する回答まとめ
筆者の発表についてたくさんの質問をいただいたので、その回答をまとめました。 発表後の質疑応答に加え、懇談会でいただいた質問の回答もまとめたので、ご参考にしていただければ幸いです。
Q1. リランキングモデルにしなかった理由として、もともと上位のものしか並び替えることができないと話していたが、ベクトルランキングはほかの下位の候補者を上位に持ってくることができるのか？
ベクトルランキングは下位の候補者を上位に持ってくることが可能です。ベクトルランキングの対象となった候補者は「元のスコア + 補正」がかかるため、ランキングの上位に表示されやすくなります。
補足ですが、リランキングを採用しなかった理由としては、以下の2点が挙げられます。
- 検索システムの改修が行われていたため、リランキング時に使われる候補者一覧が変わる可能性が高く、AIモデル開発の仕様変更が多発するリスクがあった。
- 当時、アプリケーションとモデルを扱うチームが分かれており、組織を跨ぐ開発・運用の仕組みを整えるためのリソースを割くことが難しかった。
これらの課題から、変更が少なく、導入コストが低いベクトルランキングを採用しました。
Q2. ベクトルモデルを使っているが、どういったモデルであるとうれしいか？
ユーザーのインタラクションを促すようなモデルであると嬉しいです。検索のシステム面では、レイテンシーが低いことが求められるため、モデルの推論時間が短いことも重要です。
Q3. Qdrant はクラウドまたはオンプレミスのどちらに建てているのか？また、なぜそれを採用したのか？
Qdrant はオンプレミスで運用してます。2022年当時、Qdrant Cloud で提供されていた Dashboard が簡素なもので、運用や監視に必要な機能が十分ではありませんでした。そのため、自分たちで監視の仕組みも構築した方が良いという判断をしました。
Q4. インタラクションが改善した理由として、「ランキング精度が上がったからなのか？」それとも「一連の検索セッションの作業効率が上がったからなのか？」どちらだと思いますか？
ランキングの精度改善の影響が大きいと考えます。より細かく言えば、1ページ目に表示される候補者がユーザーのインタラクションを促すような結果になっていることが影響していると考えます。
Q5. データ（ベクトル）の更新頻度について可能な範囲で知りたいです。
ユーザーに関連するデータの鮮度を保つため、データおよびベクトルの更新頻度は日次で行っています。特に、レジュメや行動履歴のデータは日々更新されているため、それに合わせて対応しています。合わせてモデルの更新も日次で行っています。
Q6. ブーストの計算式とスコアリングの仕組みについて詳しく知りたいです。
ブーストの計算式ですが、Elasticsearch の検索スコアに対してベクトルランキングが推薦した候補者が一致した場合「ESの検索スコア × ブースト値」を計算します。一致しなかった場合、ESの検索スコアのみを採用します。
Q7. Two-Tower model について、各 Tower ごとに異なる特徴を使っていますか？
候補者とクエリの Tower で特徴数は異なる構成になります。同じモデルを使う案も検討しましたが、候補者とクエリの特徴を揃える必要があり、それぞれ持つ有効な特徴が使えないため採用を見送りました。 Facebook の論文や Taobao の論文 でも Two-Tower model 採用の実績があることから、ベクトルランキングも Two-Tower 構成にしました。
Q8. ベクトルランキングから得られた検索結果のスコアを使わないのか？
以下2つの理由により、ベクトルランキングから得られる類似スコアは使ってません。
- 検索のタイミングによってスコアが変わるため、完全な再現性が担保できない
- 検索スコアを制御する責務を検索チームに持たせたいため。（類似スコアによる検索スコアの制御をモデルに任せると、AIチーム側でもスコア制御の責務を持つことになるため、ここは役割を分けたかった。）
まとめ
今回の検索技術勉強会の登壇では、ベクトル検索技術をベースとした検索改善施策のベクトルランキングについて紹介させていただきました。発表を通じて、取り組みに対する関心や質問を多くいただき、自分にとって学びや気づきがありとても良い刺激を受けました。懇談会で参加者の方と話をするなかで、検索エンジンだけではなく検索改善で用いるAI技術についても今後の発展の鍵であり、その施策に対する評価も今後重要になってくると感じました。
これらの鍵となる技術を活用して、今後も「ビズリーチ」の検索品質の向上に取り組んでいきたいと思います。
「「「検索チームは本気だ！！！」」」
（↑元ネタはコチラ）
