Qdrant を用いた検索改善施策の紹介 / Search Engineering Tech Talk 2024 Summer

Qdrant を用いた検索改善施策の紹介  Search Engineering Tech Talk 2024 Summer, 2024.10.10   
    株式会社ビズリーチ（Visional グループ）  リクルーティングプロダクト本部プラットフォーム開発部  検索基盤グループ  渡會恭平  1

渡會　恭平（わたらい　きょうへい）  2017.02 株式会社ビズリーチ入社  • AIグループに所属し、自然言語処理やレコメンド技術を用いたAI機能開発に従事  • 2024.08 から検索基盤グループに異動し、機械学習を用いた検索・
ランキングの改善に従事    自己紹介  2

• ビズリーチの求職者検索エンジンの紹介  • ベクトルランキング  • ベクトルランキングの仕組み・構成  ◦ Qdrant  ◦ モデル・ベクトル生成 
• まとめ  アジェンダ  3

ビズリーチが提供する検索システムの1つに、採用企業様/ヘッドハンター様向けの求職者検索エンジンがある。  求職者検索システム  4

検索クエリを作成し、検索エンジンから求職者一覧を取得する。  企業もしくは採用企業が求職者を検索する  求職者DB  “AIエンジニア”を  採用したい！  “AIエンジニア”の候補者になります。どうぞ！  AIエンジニア  AIエンジニア  AIエンジニア 
…  AIエンジニア  採用担当者 5

検索側の希望としては「AIエンジニア」で検索した時、「機械学習エンジニア」「データサイエンティスト」も表示させて欲しい。しかし、これらの単語が検索エンジン側で関連付けられてない場合、ユーザー側でキーワードを用意する必要があるため、負担になる課題がある。  求職者検索の課題  いろんなキーワードを用意するのは大変だなぁ。。。  検索キーワード一覧   AIエンジニア 
機械学習エンジニア   データサイエンティスト   …  採用担当者  6

「辞書」を用いて検索エンジン側で関連するキーワードを紐づける方法がある。しかし、課題がある。  1. 新しいキーワードが増えるたびに、辞書の更新が必要になる。  2. 辞書を更新するたびに、関連するキーワードに対するスコアの調整も必要になる。  長期的に見ると管理・運用が重い。  検索エンジンで対応を考える  求職者DB  7 対応するキーワードの管理・運
用が重いなぁ。。。  [辞書]  AIエンジニア => 機械学習エンジニア   営業 => セールス  … 

ユーザーとシステムが抱える問題を解決するためにベクトル導入を考える。  • 検索クエリと求職者をベクトル表現で扱うことで、検索クエリに意味的に類似する求職者を見つけることができるようになる。  • 例えば、求職者検索エンジンにベクトルを導入した場合、AIエンジニアで検索したときに、AIに関連する職種（データサイエンティストや機械学習エンジニア）も検索できることが期待できる。       
ベクトルの導入を考える  8

ベクトルを用いた検索アプローチとして「ベクトル検索」「リランキング」がある  • ベクトル検索：クエリのベクトルに類似する求職者を取得する。  • リランキング：候補者検索の結果をクエリと求職者のベクトルの類似計算を基づいて並び替える。  ベクトルを用いた検索システムを検討する  ベクトル検索  リランキング  ベクトルによる類似計算  並び替え
9

• リランキングは、候補者検索の結果を元に並び替えを行うため、候補者検索の精度の影響を受ける。  ◦ そのため、候補者検索の結果がユーザーにマッチしてない場合、リランキングしても期待する効果が得られない可能性がある。  リランキング導入の課題  並び替え  リランキングは  候補者検索の結果に依存する  
10

• 導入するためのインフラ構築＆システム変更のコストが高い  • モデルやベクトルの生成・運用の仕組みの検討に時間がかかる  • 検索結果が大きく変わるので、ユーザー体験への影響が大きい  ベクトル検索導入の課題  ベクトルによる類似計算  システム変更だけではなくユーザー体験も影響があるため、コスト＆時間がかかる
  11

• システム変更やユーザー体験への影響範囲を小さくしつつ、ベクトル検索の構築や運用を進めたい  ◦ そこで、ベクトル検索技術をベースとした検索のスコアを調整する「ベクトルランキング」と呼ぶ検索改善施策を紹介  ◦ ※ ベクトルランキングはベクトル検索と区別するための独自用語です  ベクトルを用いた改善施策の再検討  ベクトルランキングによるスコアブースト 
12

• まとめ    アジェンダ  ✔ 13

• ベクトル検索技術を使った検索結果の並び順を制御するアプローチ  ◦ 候補者検索の前に、ベクトルランキングからブースト対象者を取得する。  ◦ 候補者検索時に、クエリ＋ブースト対象者で候補者の検索を行い、ブースト対象者に一致した候補者のスコアをブーストして、最終的な検索結果を出力する。  • ※ ベクトルランキングはベクトル検索と区別するための独自用語です 
ベクトルランキングとは？  ベクトルランキングによるスコアブースト  14

• 既存の検索システムに大きな変更を加えることなく機能を提供できる  ◦ クエリの修正だけで実現可能（インデックス修正なしで対応できる）  ◦ 当時（2022年9月）、検索システムの改修をしつつも検索品質の改善を進めたかった    • モデルやベクトルの生成・運用をAI専門のチームで対応することができる  ◦
以前は、検索チームとAI機能を開発するチームが分かれていた  ◦ 組織間を跨いでモデル・ベクトルを扱うアーキテクチャ設計や運用の仕組みの構築が不要    • 既存の検索結果の並び順だけに影響を与えるので、ユーザー体験への影響を小さくできる  ◦ ベクトル検索は全アイテムに対して影響があるが、ベクトルランキングは一部の検索結果が対象となるため影響範囲が小さい  ◦ ベクトル検索への移行は、ユーザー体験が大きく変わりすぎるのでプロダクトとしてすぐに受け入れられなかった  ベクトルランキング導入のメリット  15

  検索経由でのインタラクションが5~10%向上しました！  ベクトルランキングの導入効果  すごいなベクトルランキング！  16

ベクトルランキングの構成  ベクトルランキングを作る  17

ベクトルランキングの構成  ベクトルランキングを作る  今回は、VectorDB (Qdrant) とモデル・ベクトル生成についてお話しします！  18

• まとめ    アジェンダ  ✔ ✔ 19

• ベクトルランキングの構成要素の「Vector DB」と「モデル・ベクトル生成」に焦点を当てます。  ベクトルランキングを作る  20

• Vector DB を選ぶ上で以下2つの要件が必須  ◦ ブースト対象者を取得する上で、対象者を絞り込む「pre-ﬁlter」と「ベクトル検索」が備わっている  ◦ 求職者の検索の前に処理するため、可能な限り「検索スループットが小さい」こと    •
上記2点を踏まえた上で調査したところ、以下のエンジンが候補して挙がった  ◦ Elasticsearch (Lucene)  ◦ OpenSearch (nmslib)  ◦ Qdrant  ◦ Vespa  ◦ Vertex AI    • 余談ですが、Faiss や Annoy などの近傍探索ライブラリも検討しましたが、pre-ﬁlter 機能が備わってなかったので候補から外しました。（2022年9月の仕様検討時点）  Vector DB を選ぶ  21

• パフォーマンス検証（2022年9月頃に実施したため、現在の状況は異なります。）  ◦ 1000万件ぐらいのドキュメントに対して検索スループットを調査    • 検証結果  ◦ Qdrant >
Vespa >> Elasticsearch > Vertex AI > OpenSearch    • 検証結果より、最も検索スループットが良かった「Qdrant」を採用することに決定!!  Vector DB を選ぶ（２）  22

What is Qdrant? - Qdrant より  Qdrant is a vector
similarity search engine that provides a production-ready service with a convenient API to store search, and manage points (i.e. vectors) with an additional payload.    Qdrant でできること  • ベクトルおよびペイロードを用いた検索  • クラウドまたはオンプレミスで利用可能  • Quantization や Indexing などの機能も備わっている  Qdrant  Qdrant is a vector similarity search engine that provides a production-ready service with a convenient API to store search, and manage points (i.e. vectors) with an additional payload. 23

What is Qdrant? - Qdrant より  Qdrant の構成  24 引用：https://qdrant.tech/documentation/overview/#high-level-overview-of-qdrants-architecture 

Collections  • 検索できる Point の名前付きセット  • 同じ Collection 内の各 Point のベクトルは、同じ次元を持ち、単一のメトリックで比較する   • NamedVector オブジェクトを用いると、単一のポイントに複数のベクトルを持つことができ、各ベクトルには独自の次元とメトリック要件を設定できる  

What is Qdrant? - Qdrant より  Qdrant の構成  26 引用：https://qdrant.tech/documentation/overview/#high-level-overview-of-qdrants-architecture
Distance Metric • ベクトル間の類似性を測定するために使用され、コレクションを作成するときに同時に選択する • メトリックの選択は、ベクトル生成の方法によって異なる Distance Metric  • ベクトル間の類似性を測定するために使用され、コレクション作成時に選択する  • メトリックの選択は、ベクトル生成の方法によって異なる   

Points  • Qdrant が操作する中心的な Entity  • ベクトル、 ID および Payload で構成される  ◦ Point 構成  ▪ ID：一意の識別子  ▪ Vector：データの高次元表現  ▪ Payload：Json オブジェクト 

What is Qdrant? - Qdrant より  Qdrant の構成  引用：https://qdrant.tech/documentation/overview/#high-level-overview-of-qdrants-architecture  28
Storage  • 2 つの Storage オプションを持つ。  • in-memory storage：すべてのベクトルを RAM に保存し、disk アクセスは永続性のために利用する仕組み   • memmap storage ：ディスク上のファイルに関連付けられた仮想アドレス空間を作成する仕組み  

• A Complete Guide to Filtering in Vector Search -
Qdrant より  ◦ Filterable Vector Index を採用して、近傍探索（HNSW）＆フィルタリングでの検索が可能。  ◦ フィルタでノード間のリンクが切れても追加のリンクを構築するので、最適解への探索が打ち切られることがない。    Qdrant の検索  引用：https://qdrant.tech/articles/vector-search-ﬁltering/  29

本番稼働に向けて以下のような課題がありました。  • 検索結果に対する取得したブースト対象者のカバレッジが低い  • Payload + Vector の検索が遅い  • Payload
の条件が多いクエリの検索が遅い  これらに対する解決策とその効果について紹介します。  Qdrant 本番稼働に向けての課題  30

課題  • 検索結果に対する取得したブースト対象者のカバレッジが低い  ◦ 検索結果にブースト対象者が現れないことが頻発した。  解決策  • パフォーマンスと精度のトレードオフを見つつ、近傍探索およびHNSWのパラメータを修正  • 修正パラメータ 
◦ エッジの数  ◦ indexing と search の時に保持する近傍ノードの数  結果  • 検索結果に対するカバレッジ平均が約5倍向上した。  • 検索結果に出現するブースト対象の候補者が増えた。  Qdrant 本番稼働に向けての対応（１）  31

課題  • Payload + Vector の検索が遅い  解決策  • Storage オプションを設定する。 
◦ in-memory storage に payload を配置し、memmap storage にベクトルを配値  ◦ メモリ使用率とパフォーマンス（レイテンシ）のトレードオフを調査  結果  • 平均 100 ~ 200 ミリ秒のレイテンシーが、平均 50 ~ 60ミリ秒になった。  • 両方とも in-memory storage に配置すれば良さそうに見えるが。。。  ◦ ベクトルはメモリ使用量が大きいため、そのまま in-memory stroage で扱う場合コストがかかる。  ◦ また、複数のベクトルを対象に実験を行うことを想定すると、さらにメモリが必要になるためコストの都合上 in-memory での運用は厳しい  Qdrant 本番稼働に向けての対応（２）  32

課題  • Payload の条件が多いクエリの検索が遅い  解決策  • 条件の密度が多い Payload の属性値に対して、payload_indexing および
full_text_indexing を設定  結果  • Payload 検索のレイテンシーが、10 ~ 20ミリ秒ほど改善された  Qdrant 本番稼働に向けての対応（３）  33

施策とその効果まとめ  • 近傍探索およびHNSWのパラメータを修正により精度を改善  • Storage オプションの設定でメモリコスト削減およびレイテンシーの改善  • Payload に対して Indexing
を設定して、レイテンシーをさらに改善    これらの改善策を導入して、ベクトルランキングを本番稼働させることができました。  最後に、ベクトルランキングで利用する「モデル・ベクトル生成」について紹介します。    Qdrant 本番稼働！  34

• まとめ    アジェンダ  ✔ ✔ ✔ 35

ベクトルランキングで使うモデルとベクトル生成について紹介します。  • モデルの構成  • モデルの学習＆推論  • モデルの改善施策  モデル・ベクトル生成  36

モデル構成の要求  • オンラインでの推論処理（ベクトル変換）をして、クエリと候補者を類似計算をできるようにしたい。  ◦ クエリは、リアルタイムで変化するためオンラインでのベクトル変換処理が求められる  ◦ 一方、候補者に対するベクトル変換処理はクエリよりも更新頻度が落ち着いているため、オフラインでの運用が可能    上記の要求から、クエリと候補者のベクトルのインタラクションを学習しつつも、それぞれ独立してモデルが利用できる
構成を考える。  モデルの構成を考える  37

• ベクトルランキングでは、Two Tower Model を採用  ◦ 検索クエリを扱う Query Tower と候補者データを扱う
Candidate Tower を構築  ◦ Query / Candidate Tower それぞれに関連する特徴を入れてベクトルを生成し、過去ログのインタラクションを正解ラベルとして、Query Tower と Candidate Tower のモデルを共同で学習する  • マルチモーダルやコールドスタート問題にも対応できる    Two Tower Model  38

• Query Tower のモデルと Candidate Tower のモデルからベクトルを生成し、検索の過去ログのインタラクションを元にそれぞれのモデルを学習する。  • ベクトルランキングでは
Contrastive Learning を採用している。  ◦ 類似するものは近くに、異なるものは遠くにマッピングされるように学習する。  モデル：学習  引用：https://www.mdpi.com/2073-8994/11/9/1066  39 類似度スコア（インタラクション）をもとに loss を算出。

• 推論時には各 Tower から生成されたベクトルをベクトル空間にマッピングする。  • マッピングされたベクトルは、近傍探索でクエリのベクトルに近似する候補者を取得する  モデル：推論・変換  40

学習したモデルは、オンライン・オフラインでそれぞれ利用する  • Query Tower  ◦ Query Tower のモデルは、オンラインで API で提供 
◦ Query データをリアルタイムでベクトルに変換する  • Candidate Tower  ◦ Candidate Tower のモデルは、オフラインで Batch として利用  ◦ Qdrant の Collection に挿入するベクトル生成で、大規模なデータをまとめて処理する    プロダクションでの利用  41

以下の施策を実施  • モデル構造の見直しとパラメータチューニング  • Positive / Negative Sampling  • Implicit
Feature の導入（行動履歴の特徴）  • などなど。。。    今回は、Implicit Feature 導入による精度改善について紹介します。  モデル改善の施策  42

• レコメンド技術（行列分解）のアルゴリズムを用いて、企業または採用企業と候補者のインタラクションの行列を因数分解し、それぞれのベクトルを作成する。（得られたベクトルを implicit feature 呼ぶ。）  • イメージとしては、履歴が類似するユーザー・アイテムがほぼ同じ方向となるベクトルを計算する    Implicit
Feature の導入  43

行列分解で得られたベクトルを各 Tower への入力の特徴として扱う。  • 導入した結果、ランキング指標を用いたオフライン評価で 5 ~ 10 %の精度が向上した。  Implicit
Feature の導入（２）  44

おまけ：さらに詳しく知りたい方は。。。  https://engineering.visional.inc/blog/582/nlp2024/  https://engineering.visional.inc/blog/615/implemen t-interleaving-for-search-evaluation/  45

• まとめ    アジェンダ  ✔ ✔ ✔ ✔ ✔ 46

• ベクトルランキング施策とその構成について紹介  ◦ ベクトルランキングはベクトル検索技術を用いて検索時のスコアをブーストする仕組み  ◦ クエリの修正で実現できるので、導入コストが小さく、改善効果も期待できる    • Qdrantの本番稼働に向けた施策の紹介  ◦
Qdrant の採用経緯とその特徴・構造について紹介  ◦ メモリ・精度・レイテンシーに関わる Qdrant のチューニング方法を紹介    • モデル・ベクトル生成の紹介  ◦ Two Tower Model を用いたベクトル生成の仕組みを採用  ◦ レコメンド技術を用いて行動履歴から特徴を作成し、モデルの精度を改善  まとめ  47

Appendix  48

Qdrant  https://qdrant.tech/    What is Qdrant?  https://qdrant.tech/documentation/overview/    A Complete
Guide to Filtering in Vector Search  https://qdrant.tech/articles/vector-search-ﬁltering/  Appendix：参考文献  49

Embedding-based Retrieval in Facebook Search  https://arxiv.org/pdf/2006.11632    Embedding-based Product Retrieval
TaoBao Search  https://arxiv.org/pdf/2106.09297    Lecture Notes on Neural Information Retrieval  https://arxiv.org/pdf/2207.13443    Appendix：参考文献（２）  50

Eﬃcient and robust approximate nearest neighbor search using Hierarchical Navigable
Small World graphs  https://arxiv.org/pdf/1603.09320    Deep Metric Learning: A Survey  https://www.mdpi.com/2073-8994/11/9/1066    Innovative Recommendation Applications Using Two Tower Embedding at Uber  https://www.uber.com/en-JP/blog/innovative-recommendation-applications-using-two-tower-embeddings/    Appendix：参考文献（３）  51

Qdrant を用いた検索改善施策の紹介 / Search Engineering Tech ...

Qdrant を用いた検索改善施策の紹介 / Search Engineering Tech Talk 2024 Summer

More Decks by Visional Engineering ＆ Design

Other Decks in Technology

Featured

Transcript