Innovative Recommendation Applications Using Two Tower Embeddings at Uber
概要
- Uberの推薦システムにおけるTwo-Towerモデルの話
- Two-TowerモデルはUser-Itemのインタラクションの特徴量を持たず、User EmbeddingとItem Embeddingの関係からCVがあるかなどを学習するのでメモリ効率がいいことが知られている。
- Uberのような数百万店舗の中から注文者との関係性の高い上位数店舗を数百msecで検索するのは容易ではない。そこでTwo-Towerモデルを使うと店舗のベクトルを事前に計算しておいてUserのベクトルだけリアルタイムに作成して、ANNによって店舗ベクトルから上位数件を撮るだけで良くなる。
- 元々はDeepMFモデルを都市ごとに作成していて、スケールしなかった。数千のDeepFMモデルを一つのモデルで置き換えられた。
- DeepMFだとメタ情報を特徴量に追加できず、IDだけで学習していた
- 訓練方法の戦略などについても語られている
- Uber EatsではRecall@100を主要なメトリクスとしているため、正確に訓練時に指標を測るためには、ネガティブサンプルを多くサンプリングする必要がある
- あまり大きくしすぎると、訓練コストが高くなるので、”in-batch negatives”を使うことが多いが、これはバッチ内のネガティブサンプルを賢くとってくる必要がある
- (うまくハードネガティブを取ってくるっていう話かな？)
- Spatial Indexing：ある程度レストランと注文者との距離が近いものを取ってくる
- LogQ Correction for In-batch Negatives：in-batch Negativeでは、ミニバッチ内のpostive itemを同じbatch内の他のクエリのnegative itemとして再利用する。しかし、これだと他のクエリでもpositive itemとなる場合もあるため、人気アイテムに偏りやすくなってしまう。そこでLogQ correctionを使ってバイアスを補正したり、(多分登場回数に応じた)itemの重みを考慮してサンプリングすることで、この問題を解決した。recall@500が89% → 93%になった模様
- モデリング
- 注文者のIDを過去の行動の系列に置き換えることで、モデルサイズを縮小し、コールドスタート問題を緩和させた。(eater_id -> [ordered_store_1, ordered_store_2, ordered_store_3, …])
- (当たり前だが)store_idのEmbedding Layerは共通化した
- その他
- eater_id、store_idは特徴としてとても重要だが、モデルサイズが課題になってくる
- 訓練が数日かかってしまう
- 今後はEatsだけでなく、他のチームでもTwo Towerモデルを使えるように横展開できるプラットフォームを作る。
- そうすることで、さまざまなEmbeddingを作成することができ、それを入力特徴とした新たなプロダクトも作りやすくしていく。(地理Embeddingとか？)