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

「情報検索/推薦 各社合同 論文読み祭 #1」での発表資料です。

元論文
Embedding-based Retrieval in Facebook Search

Transcript

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

   View Slide

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

   View Slide

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より引用
   

   View Slide

4. - 画像検索系と違って”boolean検索”との整合性を意識しないといけない
   - Facebook searchではコンテクストも考える必要がある
   - 同じクエリでも人物、居場所、ソーシャルグラフに依存して意味が変化
   - 例：”高柳慎一”と検索したら友人にいる奴から出して欲しい
   - “unified embedding”を提唱しこれに対応
   - 検索対象ドキュメント：人物、ページ、グループ（verticalと呼ばれている）
   1 INTRODUCTION
   

   View Slide

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

   View Slide

6. - Recallを最適化する問題として定式化
   - 評価指標はRecall@K
   - N個の”狙った”結果集合T
   - “狙った” = ユーザがクリック、人が判断など
   - Top K個のドキュメントdを出力
   - クエリとドキュメントのembeddingのcos類似度の最大化として考える
   - オフライン評価指標計算には10,000検索セッション単位をランダム抽出して使用
   - 1検索セッション=30分程度、らしいぞ（技術書展 11 エムスリーテックブックより）
   2 MODEL
   

   View Slide

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

   View Slide

8. 2.3 Unified Embedding Model
   - 距離関数Dはcos類似度
   - Eq, Edはそれぞれクエリとドキュメントの embedding
   - Encoderはクエリとドキュメントそれぞれに用意
   - コンテクストも一緒にEncodingしちゃうのがミソ
   （Unified Embeddingモデルたる所以）
   論文Figure 2より引用
   

   View Slide

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

   View Slide

10. - Positive
    - ①ユーザのClick
    - これはまあ直感的にユーザからのフィードバックであろう
    - ②Impression自体
    - 画面に表示された、それだけでPositive。
    - Retrievalの過程はRanking様への橋渡し。Ranking様に認められた
    （表示された）ってのはそれだけで価値、という気持ち。
    - 意外とRecallの意味でのパフォーマンスに差はなかった
    - 同じデータサイズで検証
    2.4 Training Data Mining
    

    View Slide

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を勝手に削る
    

    View Slide

12. Location features
    - クエリ：検索者の所在地や使用言語
    - ドキュメント：グループの位置など
    - これは素直に効きそう
    Social embedding features
    - ソーシャルグラフ入れてみた
    - 結果は？？？
    3 FEATURE ENGINEERING
    論文Table 2より引用
    

    View Slide

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

    View Slide

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)
    

    View Slide

15. パフォーマンス
    Optimized Product Qunatization = OPQ
    ※1-Recall@10 は 1個だけの正解に対するRecall@10の意味だと思う
    4.1 ANN
    論文Figure 3, Table 3より引用
    

    View Slide

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
    

    View Slide

17. 学び、その教え。
    - pq_bytes を d/4 (byte) にせよ（経験談）
    - Product Quantizationは、d次元ベクトルをxバイトコードに圧縮
    - xが大きいほど精度は高いが、メモリ使用量は多くなる
    - 次元数/4 byteくらいがちょうどええ
    - nprobe, num_cluster, pq_bytesを”オンライン”でチューニングしよう
    - 比較検証のために、複数のセットでオンラインテストをしてよりよく挙動
    を理解する
    4.1 ANN
    

    View Slide

18. 4.2 System Implementation
    - Facebookの検索エンジンはbool検索ベース
    - 既存のエンジンにNN（近傍）操作 “nn ：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個のクラスターが同定され
    る
    - ペイロードは一致したドキュメントの半径制限を確認するために使用される
    

    View Slide

19. 4.2 System Implementation
    - NN操作のradiusクエリモードとtop-Kクエリモードを比較し、radiusモードがシステ
    ムパフォーマンスと結果の品質のバランスをより良くできる
    - 理由は、半径モードは制限付きNN検索であり、topKは全インデックスをス
    キャンする必要があるため
    - Model serving
    - クエリ/ドキュメントembeddingは同時に学習されるが、独立にServing
    - クエリ:
    - オンラインのリアルタイム推論
    - ドキュメント:
    - Apache Sparkでオフラインバッチ推論
    - Forward Indexにメタデータととにもembeddingを格納
    - 「Document -> そのDocument関連のデータ」なインデックス、
    転置インデックスの逆（元通り？）
    - 量子化して転置インデックスを作成
    

    View Slide

20. 4.3 Query Index Selection
    - 効率よくインデクシングし、クエリの効率と結果の品質を向上するため…
    - 容量食うやつとか無駄なコンテンツの蓄積は避ける
    - ユーザが以前検索したものや簡単にわかるものなどに対してはEBRを除外
    - または検索の意図がembeddingの学習時とは明らかに違うもの
    - 検索速度を上げるため以下のような有用なもののみインデックスに登録
    - 月次アクティブユーザー（休眠ユーザはインデクシングしない）
    - 最近のイベント
    - 人気のあるページ・グループ
    

    View Slide

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

    View Slide

22. 6.1.1 Hard Negative Mining(HNM)
    - 限りなくPositiveに近い判別が困難なもののみを学習に使う
    - 画像系でと有名
    - 著者らのモチベーション
    - 同姓同名でのランキングがうまくいかない
    - ↓
    - ランダムサンプリングした負例で学習していたのならあたりまえ
    - ↓
    - より”判別困難”な例で鍛え上げる必要がある
    6 ADVANCED TOPICS, 6.1 Hard Mining
    

    View Slide

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に近いやつを引くのはなかなか難しい
    

    View Slide

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
    

    View Slide

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
    

    View Slide

26. - ２つの方針、２つのモデル
    - ランダムnegativeで学習させたモデル
    - 大きめなKに対してRecallが良い
    - retrievalの空間の”抜漏れ/見逃し”を減らす（FN減）のでRecallが良い
    - non Click Impressionをnegativeとして学習させたモデル
    - 小さめのKに対してPrecisionが良い
    - うっかりretrievalがなくなる（FP減）のでPrecisionが良い
    - これらをEmsembleしたいっ！！！
    6.2 Embedding Ensemble
    

    View Slide

27. Weighted Concatenation
    - S: モデルごとにαで加重した類似度スコア
    - Eq, Ed: 複数のモデルのembeddingを並べた
    concatされたembedding（ベクトル）
    - モデル何個にするか？何をPositiveにするか？あ
    たりのチューニングが難しそう
    - この組み合わせが良かった
    - impressionをnegativeとしたモデル
    - offline hard negativeで学習させたモデル
    6.2 Embedding Ensemble
    D
    D
    

    View Slide

28. Cascade Model
    - “縦”にモデルを積む（Sequential）
    - First Stageの出力がSecond Stageの入力に
    - Weighted Concatenationの方が良い
    - ”Documentの埋め込みを使用して結果を事前にフィルタリングす
    る”というテクニックを使ってやっとWork
    - ※unified embedding model対比
    6.2 Embedding Ensemble
    

    View Slide

29. 7 CONCLUSIONS
    - 研究の２つの方向性
    - deep
    - BERTとかで特定の問題を解く方向
    - universal
    - 事前学習しておいたモデルを用いて、いろんなタスクに使えるモデ
    ルを作る方向に持っていく
    

    View Slide

30. END
    

    View Slide