Closed nogawanogawa closed 1 year ago
nogawanogawa
commented
1 year ago Airbnbではゲストが宿泊先などの商品を見つける主な手段は検索になっている。 ゲストからの場所や日時などのクエリが与えられると、Airbnbではランキングモデルによって商品をランキングし、ビジネス指標を最適化させようとする。
Airbnbでは、EC等と同様に最終的なコンバージョンを重視している。 ゲストは多くの選択肢を身長に検討し、最終的な予約リクエストをするまでに何十もの検索を繰り返し何週間も費やすこともある。 双方向マーケットプレイスのため、ホストから拒否されたりキャンセルされたりする可能性があり、ゲストはその度に検索をやり直すのは非常に体験が悪い。
そのため、長い検索ジャーニーを通じてゲストをガイドしつつ、ゲストとホストの両方のバランスをとることが求められる特徴的な問題がある。
nogawanogawa
commented
1 year ago ゲストの検索をガイドしつつ、ホストとのバランスを考慮して双方にとって良い検索体験を実現する
nogawanogawa
commented
1 year ago 従来のランキングでは、最終的にキャンセルされなかった予約を正例として扱っていた。
ポジティブなラベルを他の全ての検索インプレッションよりも上位にランク付けすることである。ゲストができるだけ早く理想的なリスティングを見つけることができるように、検索ジャーニー全体にわたる全てのゲストの検索に対してこれを行っている。
過去のランキングには以下のような問題点があった。
その他、過去の予約者のみから学習したランキングモデルをすべてのゲストに提供しているため、選択バイアスにもさらされている
nogawanogawa
commented
1 year ago Journey Rankerの入力はリスティングに関する特徴FLとコンテキスト（ゲストとクエリ）に関する特徴FCになっている。 それぞれをMLPを通してリスティング・コンテキストのembeddingを生成する。
これらが３つのモジュールを通して最終的なscoreが計算されている。
base moduleの責務は「最終的なポジティブなマイルストーン（例：キャンセルなし予約）に対して最適化された検索結果ごとの単一スコア」である。
問題点で上げた通り、キャンセルなしの予約とそれ以外で分けてしまうと、多くの情報が失われてしまう。 そこで、問題設計を「ゲストがポジティブな検索マイルストーンに到達することを支援すること」に再定義している。
6つのポジティブなゲストの検索マイルストーンを、確率の連鎖法則を使用するゲストの行動としてモデル化する。
これらそれぞれに対してLossを定義し、連鎖させるモデルを構築している。
Twiddler Moduleの責務は、ネガティブなマイルストーンごとに検索結果ごとのスコアを生成することである。
これらについてスコアを計算し、合計値をLossとして扱う。
base moduleと違って、こちらは連鎖させていない。 （あんまりわかってない）
上記２つのモジュールの出力を線形結合して求められるのがCombination Moduleとなっている。
解釈容易性のため、Combination Moduleから上流のモジュールへのバックワードはしていない。
nogawanogawa
commented
1 year ago オンラインでも良くなった
論文URL
https://arxiv.org/abs/2305.18431
著者
Chun How Tan, Austin Chan, Malay Haldar, Jie Tang, Xin Liu, Mustafa Abdool, Huiji Gao, Liwei He, Sanjeev Katariya
会議
KDD '23
目的
ゲストの検索をガイドしつつ、ホストとのバランスを考慮して双方にとって良い検索体験を実現する
アプローチ
Base Module
Twiddler Module
Combination Module
ひとことメモ
目的変数の置き方とかは参考になるかも？