[情報検索/推薦 各社合同 論文読み祭 #1] KDD ‘20 "Embedding-based Retrieval in Facebook Search"

Transcript

1. 情報検索/推薦 各社合同 論文読み祭 #1 KDD ‘20 Embedding-based Retrieval in Facebook

   Search 高柳慎一 / @_stakaya

2. - 要約： 何の話？ - Facebookのembeddingを活用した検索基盤 - 見所（私見） - boolean検索にembedding検索を混ぜてる -

   検索精度をあげるためのembeddingの作り方 - 学習データの作り方 - これを実際のシステムとして動かす/載せるか？の方法 - 感想 - 2020年ちょい前まではFacebookでもboolean検索でやってたんだ なぁ… - 山の登り方（bool -> embedding）がとても嬉しい ※以下で”論文”と言った場合には当該紹介論文を指す 要約と見所（私見）

3. 1 INTRODUCTION - 検索エンジンの２層 - Recall layer: retrieval（検索） - 関係ある情報取りこぼさない（TP

   + FNなので） - Precision layer: ranking（ランキング） - 関係ない情報を削る（TP + FPなので） - Embeddingがガツンと効くのはretrieval - 曖昧に持ってこれる（semantic matching） - 例: にっぽん → 日本？ - 主にembedding-based retrieval (EBR)と呼称 - embeddingしてdense vectorさえGETしちゃえばあとは最近傍 （nearest neighbor）探索になる 論文Figure 1より引用

4. - 画像検索系と違って”boolean検索”との整合性を意識しないといけない - Facebook searchではコンテクストも考える必要がある - 同じクエリでも人物、居場所、ソーシャルグラフに依存して意味が変化 - 例：”高柳慎一”と検索したら友人にいる奴から出して欲しい -

   “unified embedding”を提唱しこれに対応 - 検索対象ドキュメント：人物、ページ、グループ（verticalと呼ばれている） 1 INTRODUCTION

5. 1 INTRODUCTION 論文Figure 1より引用

6. - Recallを最適化する問題として定式化 - 評価指標はRecall@K - N個の”狙った”結果集合T - “狙った” = ユーザがクリック、人が判断など

   - Top K個のドキュメントdを出力 - クエリとドキュメントのembeddingのcos類似度の最大化として考える - オフライン評価指標計算には10,000検索セッション単位をランダム抽出して使用 - 1検索セッション=30分程度、らしいぞ（技術書展 11 エムスリーテックブックより） 2 MODEL

7. - 数式 - d±: Posi/Negativeなドキュメント - q: クエリ, D: 距離関数(cos類似度),

   m: マージン - できるだけd±のドキュメントが離れるようにembeddingを学習 - 良い感じのTriplet(q, d+, d-)になるようなEncoderを学習 - mの値の決め方次第でRecall@Kのバラツキが5-10%程度出るらしい（怖い） 2.2 Loss Function

8. 2.3 Unified Embedding Model - 距離関数Dはcos類似度 - Eq, Edはそれぞれクエリとドキュメントの embedding

   - Encoderはクエリとドキュメントそれぞれに用意 - コンテクストも一緒にEncodingしちゃうのがミソ （Unified Embeddingモデルたる所以） 論文Figure 2より引用

9. - 学習データのPosi/Negativeの定義は不明瞭 - Negative - ①: ランダムサンプリング - ②: 表示されたしかしClickされなかった

   - non-click impressions - ②のパフォーマンスが①対比で悪い - 理由（仮説）②はいうて表示はされたわけなんで、 何らかの意味でHighスコアなドキュメントであり、 限りなく白に近い奴らだったのだろう。したがっ て、正負の判断がしにくいHardなケースになって しまったのだろう（ランダムサンプリングが必要な 理由） 2.4 Training Data Mining

10. - Positive - ①ユーザのClick - これはまあ直感的にユーザからのフィードバックであろう - ②Impression自体 - 画面に表示された、それだけでPositive。

    - Retrievalの過程はRanking様への橋渡し。Ranking様に認められた （表示された）ってのはそれだけで価値、という気持ち。 - 意外とRecallの意味でのパフォーマンスに差はなかった - 同じデータサイズで検証 2.4 Training Data Mining

11. 3 FEATURE ENGINEERING Text features - 文字単位のnグラム - 文: …to_be_or_not_to_be…

    - unigram: …, t, o, _, b, e, _, o, r, _, n, o, t, _, t, o, _, b, e, … - 単語単位のnグラム - 文… to be or not to be … - unigram…, to, be, or, not, to, be, … - “文字”単位の方が性能は良かったが、組み合わせて使うとより良い - この手の報告はいまいち信用しき r… - Fucebookでの検索対象（人、グループ、イベントページ）には embedding単体でも有用 - Fuzzy text match: kacis creations -> Kasie’s creations - Optionalization “mini cooper nw” -> “Mini cooper owner/drivers club” - nwを勝手に削る

12. Location features - クエリ：検索者の所在地や使用言語 - ドキュメント：グループの位置など - これは素直に効きそう Social embedding

    features - ソーシャルグラフ入れてみた - 結果は？？？ 3 FEATURE ENGINEERING 論文Table 2より引用

13. 4 SERVING, 4.1 ANN - “近似近傍探索（ANN）ベースの転置インデクス”としてDeploy - 理由１： ベクトルを量子化しちゃうえばストレージコストが安い -

    理由２： 既存システムへの組み込み観点 - Faissを使用して実装 - https://github.com/facebookresearch/faiss - 量子化？？？ - 問題：あるベクトルからの距離が最も短い k番目のベクトルをベクトルの集合から見つけたい - ブルートフォース検索は非現実的 - 量子化するとベクトル空間での検索の効率問題を解決することができる - ~無限~次元のベクトル空間を有限ベクトル集合（コードブック , codebook）に写像し、写像されたさ れたベクトルで元のベクトルを特徴付ける /近似する - 量子化の方法は…（次のスライドへ）

14. - 量子化は二段階で行われる - Rough/Coarse quantization - k-meansみたいなもん、クラスタIDの同定 - IMI[11], IVF[15]が実際には使われる

    - Product Quantization - ベクトルの次元の個性（分布）を活かして量子化。次元を均等に分割するなど、ベクトルを m個 の部分に分割。最終的なコードブックのサイズ = 各部分量子化のコードブックのサイズの積。 各部分量子化はクラスター量子化（ k-means, Faissにある) - ↓色違いごとにk-meansして、その所属するクラスター中心を使うってこと 4.1 ANN 引用: 以下の論文の Figure 1より Victor Lempitsky. 2012. The Inverted Multi-Index. In Proceedings of the 2012 IEEE Conference on Computer Vision and Pattern Recognition (CVPR)

15. パフォーマンス Optimized Product Qunatization = OPQ ※1-Recall@10 は 1個だけの正解に対するRecall@10の意味だと思う 4.1

    ANN 論文Figure 3, Table 3より引用

16. 学び、その教え。 - “スキャンしたドキュメント数”を見ながらRecallをチューニングせよ - 同じnum_clusterとnprobeで、Rough Quantizationアルゴリズム間(IMI, IVF)の比較すると、 クラスターが極端に不均衡になるものもあり、クエリ中にスキャンされるドキュメントの数が大き く異なりえる -

    指標として”スキャンするドキュメントの数”も見よう - モデルが大幅に改善された場合、 ANNパラメーターを再調整する必要がある - ANNのパフォーマンスはモデルの特性に依存しているのでがんばろう - とりあえずOPQアルゴリズムを使え - 常に他のアルゴリズムよりも優れたパフォーマンスを発揮 - OPQは埋め込みを回転するため、num_cluster と nprobe を再調整する必要がある - PQのアイディアに回転を加えて最適化するってアイディア（チラ見レベル） - Tiezheng Ge, Kaiming He, Qifa Ke, and Jian Sun. 2013. Optimized Product Quantization for Approximate Nearest Neighbor Search. In The IEEE Conference on Computer Vision and Pattern Recognition (CVPR) 4.1 ANN

17. 学び、その教え。 - pq_bytes を d/4 (byte) にせよ（経験談） - Product Quantizationは、d次元ベクトルをxバイトコードに圧縮

    - xが大きいほど精度は高いが、メモリ使用量は多くなる - 次元数/4 byteくらいがちょうどええ - nprobe, num_cluster, pq_bytesを”オンライン”でチューニングしよう - 比較検証のために、複数のセットでオンラインテストをしてよりよく挙動 を理解する 4.1 ANN

18. 4.2 System Implementation - Facebookの検索エンジンはbool検索ベース - 既存のエンジンにNN（近傍）操作 “nn <key>：radius <radius>”

    をサポートするよう 拡張（すでにそういう検索エンジンUnicornがある） - Curtiss, Michael, et al. "Unicorn: A system for searching the social graph." Proceedings of the VLDB Endowment 6.11 (2013): 1150-1161 - インデックス作成 - ドキュメントは量子化され以下の２部分に分けられる - クラスター（所属） - ペイロード（量子化された残差ベクトル） - クエリフェーズ - nnクエリ操作がor操作して書き直され、最も近いnprobe個のクラスターが同定され る - ペイロードは一致したドキュメントの半径制限を確認するために使用される

19. 4.2 System Implementation - NN操作のradiusクエリモードとtop-Kクエリモードを比較し、radiusモードがシステ ムパフォーマンスと結果の品質のバランスをより良くできる - 理由は、半径モードは制限付きNN検索であり、topKは全インデックスをス キャンする必要があるため -

    Model serving - クエリ/ドキュメントembeddingは同時に学習されるが、独立にServing - クエリ: - オンラインのリアルタイム推論 - ドキュメント: - Apache Sparkでオフラインバッチ推論 - Forward Indexにメタデータととにもembeddingを格納 - 「Document -> そのDocument関連のデータ」なインデックス、 転置インデックスの逆（元通り？） - 量子化して転置インデックスを作成

20. 4.3 Query Index Selection - 効率よくインデクシングし、クエリの効率と結果の品質を向上するため… - 容量食うやつとか無駄なコンテンツの蓄積は避ける - ユーザが以前検索したものや簡単にわかるものなどに対してはEBRを除外

    - または検索の意図がembeddingの学習時とは明らかに違うもの - 検索速度を上げるため以下のような有用なもののみインデックスに登録 - 月次アクティブユーザー（休眠ユーザはインデクシングしない） - 最近のイベント - 人気のあるページ・グループ

21. 5 LATER-STAGE OPTIMIZATION - Retrieval -> Ranking層へと出力が伝搬 - なんでRanking層はRetrievalの結果に対して最適化されて欲しいが …

    - embeddingに対する最適化はシステム的に対応していない（それはそう） 解決策 - Embedding as ranking特徴量 - embeddingを特徴量として（並べ替えの1Keyとして）下流へと持っていく。持っていき方として は、アダマール積（どうやるの？）、元の埋め込み（どうやるの？）と cos類似度を使用。cos類似 度が一番良かった - 学習データフィードバックループ - EBRのPrecisionが低いという問題を解決するため、人間による手動の結果補正過程を追加し て、そのマーキングされたデータを使用してモデルを再トレーニングし、モデルの精度を向上さ せる

22. 6.1.1 Hard Negative Mining(HNM) - 限りなくPositiveに近い判別が困難なもののみを学習に使う - 画像系でと有名 - 著者らのモチベーション

    - 同姓同名でのランキングがうまくいかない - ↓ - ランダムサンプリングした負例で学習していたのならあたりまえ - ↓ - より”判別困難”な例で鍛え上げる必要がある 6 ADVANCED TOPICS, 6.1 Hard Mining

23. 6.1 Hard Mining Online Hard Negative Mining - バッチサイズnでミニバッチしつつ、その時の”他のドキュメントのPositive”の中で最もcos 類似度が高いものをNegativeとして扱う（類似度の閾値は不明瞭）

    - 最も効果的だったのは ”2 negatives per 1 positive”なので”常に2個選ぶ”とかなのかも - メリット - めっちゃRecallあがった - It consistently improved embedding model quality significantly across all verticals: +8.38% recall for people search; +7% recall for groups search, and +5.33% recall for events search - デメリット - ランダムサンプリングしてる中で ”たまたま”Positiveに近いやつを引くのはなかなか難しい

24. Offline Hard Negative Mining - 方法 - ①クエリごとにK個の検索結果を出す - ②検索結果からある

    ”hard selection strategy”に基づいてhard negativeを算出 - ③新しく生成されたTripletsで再学習 - Hard Selection Strategy - 101-500番目くらいにランキングされたもの（そこそこ Positive）を使用 - 逆に上のランクすぎても微妙 - ランダムNegativeとHard Negativeを混ぜる - 1: 単にEasy / Hard trainingを混ぜる（easy:hard = 100:1が良かった） - 2: Hardで学習させたものを Easyに転移学習させる（逆は微妙だったらしい） - 計算時間がめちゃかかるんで、ANN（近似近傍検索）必須 - semi-hard negativeと呼称してこれを学習データに用いる - Positiveから適当に計算するんだろうな（多分） 6.1 Hard Mining

25. 6.1.2 Hard Positive Mining(HPM) - Click or Impression意外のPositiveになる例を持ってきて精度上げたい - failed

    search sessionに対するPositive事例になりそうなものを行動ログから頑張って 引っ張ってくる - failed search session = 0件hit - これで定義したHard Positiveを使うと Clickに基づいた結果の 4% のデータサイズで同 程度の精度が出る（強い） 6.1 Hard Mining

26. - ２つの方針、２つのモデル - ランダムnegativeで学習させたモデル - 大きめなKに対してRecallが良い - retrievalの空間の”抜漏れ/見逃し”を減らす（FN減）のでRecallが良い - non

    Click Impressionをnegativeとして学習させたモデル - 小さめのKに対してPrecisionが良い - うっかりretrievalがなくなる（FP減）のでPrecisionが良い - これらをEmsembleしたいっ！！！ 6.2 Embedding Ensemble

27. Weighted Concatenation - S: モデルごとにαで加重した類似度スコア - Eq, Ed: 複数のモデルのembeddingを並べた concatされたembedding（ベクトル）

    - モデル何個にするか？何をPositiveにするか？あ たりのチューニングが難しそう - この組み合わせが良かった - impressionをnegativeとしたモデル - offline hard negativeで学習させたモデル 6.2 Embedding Ensemble D D

28. Cascade Model - “縦”にモデルを積む（Sequential） - First Stageの出力がSecond Stageの入力に - Weighted

    Concatenationの方が良い - ”Documentの埋め込みを使用して結果を事前にフィルタリングす る”というテクニックを使ってやっとWork - ※unified embedding model対比 6.2 Embedding Ensemble

29. 7 CONCLUSIONS - 研究の２つの方向性 - deep - BERTとかで特定の問題を解く方向 - universal

    - 事前学習しておいたモデルを用いて、いろんなタスクに使えるモデ ルを作る方向に持っていく

30. END