Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Airbnbの機械学習導入から学ぶ

 Airbnbの機械学習導入から学ぶ

KDD2020で紹介されたAirbnbの論文がとても参考になったので、過去の事例も紹介しつつ勉強会用にまとめています。

ご意見・コメントがある方はTwitter: @pacocat までよろしくお願いいたします。

Jun Ernesto Okumura

August 27, 2020
Tweet

More Decks by Jun Ernesto Okumura

Other Decks in Technology

Transcript

  1. Outline Airbnbの推薦アルゴリズムと、その後の改良のプロセスについて紹介します Real-time Personalization using Embeddings for Search Ranking at

    Airbnb Grbovic & Cheng 2018 (KDD 2018) Applying Deep Learning To Airbnb Search Haldar et al. 2019 (KDD 2019) Improving Deep Learning For Airbnb Search Haldar et al. 2020 (KDD 2020) 1 2 3
  2. Photo by Etienne Boulanger on Unsplash Real-time Personalization using Embeddings

    for Search Ranking at Airbnb Grbovic & Cheng 2018 (KDD 2018) 1
  3. Overview 概要 • 検索スコアのアルゴリズムにEmbedding特徴を導入し、 Cold Startにも対応できるよう拡張した • 結果、類似宿モジュールのCTR+21%(予約数+4.8%)、全体のNDCUも改善 Airbnbのサービス特徴 •

    「宿泊場所を貸し出すホスト」と「宿泊を希望するゲスト」をマッチングする Two-sided market(ゲストの希望だけでなく、ホストが受け入れるかも大切) • ECやストリーミングといったサービスと比較して予約頻度が高くない ◦ ゲストの旅行目的での利用はせいぜい年に 1,2回程度(最大でも365回しか使えない) ◦ 受け入れ側可能なゲスト数・日数も限られている • 検索はマーケット(ドメイン; 地域)を横断しない ◦ パリに行きたい人はアメリカや日本を検索することなく、パリという地域内でのみ検索を行う
  4. サービス利用の流れ User A • ゲストが希望条件で検索→候補をクリックして検討→予約→ホストが承認 候補となる宿のクリック ※ Session 30min以上行動がなかった 場合は別Sessionとして扱う

    Session 予約(booking) ※ 意図的に訪れたページのみを考慮するため、学習時は30sec以上滞在したクリックに限っている ※ 学習時は2つ以上のクリックがあるセッションのみを利用 ⇒その後、ホストが承認、  もしくはリジェクトを行う
  5. Negative Sampling Approach • Targetの勾配を求めるには に比例した計算が必要になり非現実的 • そこでNegative Sampleのアプローチを用いる ◦

    Positive pairsとNegative pairsをサンプリングし、以下のように最適化 Positive sample クリックされた とコンテキスト ( 周辺のクリック)のペア Negative sample 全セッションからランダムにサンプル
  6. Booking Listing as Global Context • 周辺のクリック(local context)だけでなく、最終的に予約される宿かどうかの情報 (global context)も埋め込みたい

    ◦ 予約された宿とのsimilarityの項を追加することで実現 ◦ Local contextはセッション中をスライドする点に注意 Local Context(Skip Gram Model) Global Context … … …
  7. Adapting Training for Congregated Search • Airbnbはサービス特性上、検索される地域の制約がある ◦ パリを条件に設定している人はアメリカや日本の宿を求めていない ◦

    Negative Sampleをランダムにすると意味のない地域の情報が混ざる • 新たに同一地域からランダムにNegative pairsを抽出して利用 Local Context(Skip Gram Model) Global Context 同一地域内の Negative Sample
  8. 学習とCold Startへの対応 • 8億のセッション※を利用して学習 • Embeddingの次元数はd=32次元 • 推論時のCold Start対応 ◦

    新着の宿はクリック情報を持たないため、以下の情報で代替する ▪ 新着宿から10mile以内、同一タイプ(Private Roomなど)、 同一料金帯($20-25など)でEmbeddingが計算できる宿を3つ抽出して平均化 ※ 宿の数は450万に及ぶ(論文投稿時点)
  9. 話題② User Type、Listing TypeのEmbeddings • 短期的にセッション中の推薦を改善するだけでなく、長期的にユーザーの好みを反 映した推薦を実現したいが、サービス特性上の困難がある ◦ 予約を含むセッションはクリックセッションよりも桁で少ない ◦

    ゲストの予約情報が少ない(多くのユーザーは過去に 1度の予約情報しかない) ◦ ホストの予約情報が少ない( 5-10件しか予約されていない宿も多い) ◦ 次の予約まで時間が空くためユーザー属性も変化する ゲスト・ホストを個別に扱うのではなく、属性ごとにグルーピングする
  10. Listing type buckets • 地域はUS • 2名まで宿泊可能 • ベッド1つ •

    ベッドルーム1つ • バスルーム1つ • 平均料金$60.8 • ゲストあたり平均料金$29.3 • レビュー数5つ(全て星5) • 新規ゲストの受け入れ率100% US_lt1_pn3_pg3_r3_5s4_c2_b1_bd2_bt2_nu3 mapping
  11. User type buckets • SF在住 • MacBookからアクセス • 言語は英語を設定 •

    プロフィールと写真は設定済み • 83.4%のホストが星5で評価 • 過去に3度の予約 • 過去予約の平均料金が$52.52 • ゲストあたりの平均料金は$31.85 • 8.24件のレビュー • 76.1%を星5で評価 SF_lg1_dt1_f p1_pp1_nb1_ppn2_ppg3_c2_nr3_l5s3_g5s3 ※ 過去に予約していなくても、上位5項目(赤枠)の情報は使えるので、Cold Start文脈でも嬉しい mapping
  12. User type, Listing typeの学習 • ユーザーの予約履歴から (user_type, listing_type)のタプルを抽出※ • Skip

    Gram Modelを用いてEmbeddingを学習 ◦ ホストによるリジェクトがある場合は明示的な Negative Sampleとして扱う ※同一ユーザーでもuser_typeは変化しうる点に注意
  13. Type Embeddingの学習詳細 • 基本的にはlisting embeddingと同様 • 学習には予約セッションのみを使い、5倍にoversampleを行った • Embeddingの次元はd=32、windowはm=5に固定 ◦

    dを増やせば表現力は上がるが、メモリの使用量とトレードオフがある • 学習システム ◦ パイプラインはAirflowで構築 ◦ MapReduce(300 mapper & single reducer) ◦ Dailyでフルスクラッチ学習 ※ ※ 追加データに対してinclementalに学習するよりもオフライン評価が良かった
  14. オフライン評価 • 予約した宿を、それ以前にどれだけ上位にランクできていたかで評価 ◦ ランキング(縦軸)は低いほどよい 予約宿のランキング 予約前のクリック Search Ranking: 既存システム

    (クリック履歴を使っているため次第にrankが上がる) d32 reg: skip gram modelを使ったEmbedding d32 book: global contextを追加したEmbedding d32 book+neg: 同一地域のNegative pairを使ったEmbedding d32 book+reg が最も予約宿を上位にランクできた
  15. EmbeddingのSearch Ranking Modelへの導入 • ある検索で i 番目に表示された宿の特徴量 , ラベル※ を考える

    • 過去30日の予約セッションを集めて学習データを構築 Description 1 予約が成立 0.25 ホストに連絡が行われたが予約はされなかった -0.4 ホストからリジェクトが行われた 0.01 クリックが発生 0 クリックが発生しなかった ※ ラベルは検索から1週間後の状態にもとづいて割り当てる
  16. 特徴量 • Listing features ◦ 一泊あたりの料金、宿泊タイプ、部屋数、リジェクト率、 … • Query features

    ◦ ゲスト数、宿泊日数、リード時間、 … • User features ◦ 過去の平均予約料金、ユーザー評価、 … • Cross-features ◦ 検索地と宿泊地の距離、ゲスト数と受入可能ゲスト数の差、宿の料金と過去の予約料金と の差、リジェクト率、セッション内で対象宿がクリックされていた割合、 … • Embedding features(後述) ◦ 6種類のlisting feature + user_type & listing_type feature
  17. Embedding Features • ユーザーの過去2週間の行動履歴から、以下の宿のEmbeddingを抽出 ◦ (clicked listing ids) : クリックした宿

    ◦ (long clicked listing ids) : 60sec以上閲覧した宿 ◦ (skipped listing ids) : クリックされずにスキップした宿 ◦ (wishlisted listing ids) : ウィッシュリストに入れた宿 ◦ (inquired listing ids) : ホストに問い合わせしたが予約しなかった宿 ◦ (booked listing ids) : 予約した宿 • 抽出されたEmbeddingを地域ごとに平均化 • スコアリング対象の宿に対してcosine similarityの最大値を特徴とする
  18. Photo by Etienne Boulanger on Unsplash Applying Deep Learning To

    Airbnb Search Haldar et al. 2019 (KDD 2019) 2
  19. Overview 概要 • Search Rankingモデルの変遷を振り返った論文 • 多くの失敗事例や得られた知見をまとめられている 背景 • GBDTの活用(前論文)によって予約率は大きく向上した

    • 一方で、その後は目覚ましい改善はなかった ◦ 様々な試行錯誤にも関わらず、アーキテクチャは複雑になる一方だった • 最終的に、単純なDeepモデルに立ち返ることで改善を達成 • 過去モデルの歴史を俯瞰しながら失敗したこと・学習したことをまとめている
  20. “Don’t be a hero”※ by Andrej Karpathy • 複雑なモデルアーキテクチャーではなく簡単なものからスタートすべき •

    Airbnbのランキングモデルは様々な独自の改良を加えた結果、複雑で制御ができな いものになってしまった。最終的には単純なDeepモデルに落ち着いた。 ※ A Recipe for Training Neural Networks (Karpathy 2019) http://karpathy.github.io/2019/04/25/recipe/ I’ve seen a lot of people who are eager to get crazy and creative in stacking up the lego blocks of the neural net toolbox in various exotic architectures that make sense to them. Resist this temptation strongly in the early stages of your project.
  21. モデルの変遷1: Simple NN→LambdaRank NN • LambdaRank※1の導入よってNDCGを直接最適化できるようになった ◦ Pairwise: {booked-listing, not-booked

    listing}ペアに対して順番を学習(Rank学習) ◦ ペアを入れ替えることで、損失が大きくなるものは大きな勾配を与える ※2 ※1: From RankNet to LambdaRank to LambdaMART: An Overview https://www.microsoft.com/en-us/research/publication/from-ranknet-to-lambdarank-to-lambdamart-an-overview/ ※2: 例えば、9位と10位を間違えるよりも1位と2位を間違える方が問題なので勾配が大きくなる • 32ユニットの中間層を1つだけもつ単純なNN(w/ ReLU activation) • 宿に対して予約するかしないかの 2値予測を行っていた • 入力は前論文に使われていたものとほぼ同じ SImple NN LambdaRank NN
  22. モデルの変遷2: GBDT/FM NN ※ Deep & Cross Network for Ad

    Click Predictions https://dl.acm.org/doi/10.1145/3124749.3124754 • GBDTとFM(Factorization Machine)の出力をNNの入力として使うモデル • FMはクエリと宿を32次元のベクトルに埋め込むことで、宿の予約確率を出力する • Deep & Cross Network※に触発されて、GBDT/FM/NNの各強みを活用しようとした GBDT/FM NN
  23. モデルの変遷3: Deep NN • モデルの複雑化に伴い、技術的な負債が無視できないようになってきた • そこで、過去のモデルを全て廃止し、 2層の隠れ層を持ったDeepモデルに置き換えた ◦ 195次元の入力→第1中間層(127

    unit w/ ReLU)→第2中間層(83 unit w/ReLU) • 特徴は最小限のエンジニアリングで決めている ◦ 料金、アメニティ、過去の予約数、 … ◦ ダイナミックプライシングで使われているモデルの出力 ※ ◦ 前論文で紹介した(過去に閲覧した宿に関する) Embedding特徴 ※ Customized Regression Model for Airbnb Dynamic Pricing https://www.kdd.org/kdd2018/accepted-papers/view/customized-regression-model-for-airbnb-dynamic-pricing Deep NN
  24. 上手くいかなかった手法1: Listing ID • NLPやYouTubeの推薦※などの成功事例からlisting idを特徴に使えると考えた • 一方で、実際にlisting idを入れてみると過学習に陥った ◦

    単語や動画とは異なり、 1つのアイテム(宿)に大量の予約を受け入れることはできないし、ユーザー が入れられる予約にも上限があるサービス特性 idを入れるとTrain NDCGが早々に1になる
  25. 上手くいかなかった手法2: Multi-task Learning • 予約数が限られているのであれば、より数の大きいクリックを活用できないかと考えた • 予約予測とページ閲覧時間予測のマルチタスク学習に着手 ※1 ◦ しかし、閲覧時間は明らかに改善したにも関わらず、予約数は増えなかった

    ※2 ◦ 調べると、本来の目的とは異なったページの閲覧が増えているだけだった ※3 ※1: 予約数とクリック数のスケールが桁で異なるため、予約予測の精度を維持するために   予約のLossに大きな重みを付けたり、さらにlong_viewのLabelをlogで変換している ※2: Airbnbでは閲覧時間と予約に相関があるにも関わらず ※3: 高級/希少な宿、説明が長い宿、説明が面白い宿、など予約目的とは異なる宿の閲覧 予約までのクリック数分布 1つの予約までに数十〜数百の宿が閲覧されている
  26. 特徴量エンジニアリング1: Feature Normalization • NNを使えば自動的に特徴量が選択・加工される期待があったが甘かった • 初期にはGBDTの特徴量をそのままNNに与えたが、精度が極端に悪くなった ◦ GBDTは特徴の順序が重要だが、 NNではスケールに影響を受けるため前処理が必要

    • 正規化※ ◦ 正規分布のような特徴の分布に対しては標準化 ◦ べき乗分布に対しては logを取る ※ 当たり前のことを書いていると思われるが、この論文では全体的にこのレベルの「しくじり」も含めて正直に書かれている
  27. 特徴量エンジニアリング2: Feature distribution • 特徴の分布がなめらかになっているかをしっかり確認した • Spotting bugs ◦ 複数のバグを見つけた

    ▪ 通貨レートの変換がおかしくなっている地域がある ▪ 28日以上の宿泊に対して dialy料金ではなくmonthly料金が設定されている • Facilitating generalization ◦ 入力の特異な変化に対してどれだけ影響を受けるか確かめた ▪ 特徴(例えば料金)を 2x, 3x, 4x, ..のように変化させ、NDCGの変化を観測 ▪ 結果、出力は安定しており、特異な入力に対しても影響を受けにくいことが分かった
  28. 特徴量エンジニアリング4: Feature Completeness • 分布を見ることで、足りていない特徴にも気づくことができる ◦ 宿のクオリティを表すことを期待して、空いている宿泊日数を入れていた ※ ◦ しかし、宿によって予約可能な最低日数は異なり、カレンダー依存でもある(分布が特異)

    ◦ ここで足りていなかったのは平均滞在日数。実際平均滞在日数で正規化することで、 なめらかな分布を得ることができた。 ※ 人気の宿は早々と予約されあまり空きがないといった仮説
  29. High cardinality categorical features • Listing idは失敗したが、カーディナリティの高い地理情報は上手く活用できた ◦ 都市内の地域を表す特徴を頑張って手作りしていたが、 DNNに表現学習を任せた

    ◦ S2 cell※を使うことでEmbeddingを獲得した ▪ 例えば、San FransiscoのEmbarcaderoは539058204に位置しており、 {“San Francisco”, 539058204} -> 71829521と表現できる(このカテゴリを入力に使った) ※ 階層的に地球上の位置を表現するコード(以下の説明が詳しい) https://s2geometry.io/devguide/s2cell_hierarchy.html
  30. System Engineering • Protobufs and Datasets ◦ GDBTモデルではcsvで訓練データを入力しており、 DNNでもパイプラインを使いまわしていた ◦

    しかし、GPUが25%しか使えず、feed_dictを通じたcsvのパースがボトルネックと判明 ◦ そこで、パイプラインを作り直し、 Protobufとtf.data.Dataset※を使った ▪ 学習が17倍早くなり、GPU利用率も90%に達するようになった • Refactoring static features ◦ 宿の特徴(場所やベッド数)は基本変化せず、毎回全て読み込むのはボトルネックになる ◦ そのため、準静的な特徴は事前に listing idでインデックスされたベクトルとして固めておいた ▪ GPUメモリに乗せることで、 CPUからのロードを必要とせずに効率化することができた ※ https://www.tensorflow.org/guide/data ※ その他、Javaのライブラリを開発してLatencyを改善した話などあるがここでは割愛
  31. Hyperparameters • GBDTからNNの移行に従って、ハイパーパラメータの調整も未知の領域だった • FOMO(fear-of-missing-out;取り残されることへの恐怖)から、多くの事例をサーベイして試行錯 誤したが、最終的に以下に落ち着いた ◦ 正則化はDropoutではなくData Augumentationを活用 ▪

    Dropoutは流石に効くだろうと思っていたがそうでもなかった ▪ (hand-madeな)ランダムな摂動を加えた Data Augumentationを利用 ▪ オフラインのNDCGを1%改善したが、オンラインでは有意差が出ていない ◦ 初期化 ▪ 重みを全部ゼロにするしくじりなどを経て、最終的に Xavier初期化に落ち着いた ◦ LazyAdamOptimizerを活用 ▪ 大きなEmbedding計算の収束が早かった ◦ Batch sizeは200を利用
  32. 特徴量選択 • GBDTではFeature Importanceを見ることで特徴量の重要度を判断していたが、 NNではどのように特徴量を抜き差しするか試行錯誤を行った ◦ Ablation Test: ある特徴を落としてパフォーマンスへの影響度を計測 ▪

    大きくパフォーマンスが変化しなかった ▪ 宿を表現する特徴は相互に関連しており、特徴を 1つ落としても、他の特徴の組み合わせで再 現できてしまうような状況があったのでは ※1 ◦ Permutation Test: ある特徴をシャッフルしてパフォーマンスへの影響を計測 ▪ 直感的でない結果が得られた • 例えば予約数を予測するのに一番影響があったのは宿の部屋数だった • 特徴が全て独立という仮定を置いてしまっているので判断に注意する必要がある ※2 ▪ 一方で「役に立たない特徴」をあぶり出すのには使えた • シャッフルしても影響ない特徴は落してもいい ※1:「テセウスの船のパラドックス(Ship of Theseus paradox)」と表現されている ※2: 実際は、部屋数は値段やゲスト人数やアメニティと相関していると考えられる
  33. Photo by Etienne Boulanger on Unsplash Improving Deep Learning For

    Airbnb Search Haldar et al. 2020 (KDD 2020) 3
  34. 「ユーザーが先、モデルが後」 • DNNモデルに移行後、様々な事例を参考にしながらアーキテクチャの改善を行ったが、パフォー マンスがなかなか上がらなかった ◦ 例えば、クエリと宿の関係をより関連付けて学習するため、 Wide & Deepモデル※1や Attentionベースのモデル※2を試したが、目立った変化は起きなかった

    ※1: Wide & Deep Learning for Recommender Systems https://dl.acm.org/doi/10.1145/2988450.2988454 ※2: Attention Is All You Need https://papers.nips.cc/paper/7181-attention-is-all-you-need Download paper → Implement → A/B test というループを辞め、 “User lead, model follows”の基本に立ち返ることにした
  35. 1. Enforcing Cheaper Is Better • 最初に試したのは、料金特徴を DNNから明示的に分離する手法 ◦ 最終層を以下のようにモデル化して、高い料金に対してペナルティのような効果が働くようにしている

    (w, bはtrainableな重みで、最終的に w=0.33, b=-0.9となった;左図) 料金を特徴から除外 料金に対して単調に応答する関数(学習結果は左図) 平均料金は-5.7%となったが予約数は-1.5%となりビジネス毀損が発生 • 料金が他の特徴と強く結びついていたため underfitした可能性? • 実際、Train/TestのNDCGも減少していた
  36. 2. Generalized Monotonicity • 次に考えたのは、入力に対して単調に変化する構造の導入 ◦ より強い”Cheaper is better”の学習を期待 ①

    priceに対して単調な入力 ② wightを2乗して中間層への入力が単調になるよう調整  ③ 活性化関数にtanhを使い、単調性を維持 ④ 他の中間層でもweightは2乗することで単調な応答で制約 予約数が-1.6%となり再び失敗
  37. 3. Soft Monotonicity • これまでは料金に対して単調に出力が変わるようアーキテクチャを制御してきたが、 入力にヒントだけを与えて、後は DNNの表現力を最大限活かしてあげればいいのでは? • {予約あり, 予約なし}

    のペアだけでなく、{料金が安い,料金が高い} という情報を追加 ◦ 予約があった宿は上位に、料金が安い宿は上位に、というランク学習になる ◦ パラメータαで両者の学習の程度を制御 平均料金は-3.3%となったが、予約数は-0.67%となり引き続きネガティブな結果に
  38. 試行錯誤を経た状況整理 • ここまでの結果から「表示する料金は確かに下げられているのに、それがユーザーにとってメリッ トとなっていない」という状況が分かってきた • 料金に対して検索スコアを plot※すると元のDNNは”cheaper is better”を理解している ⇒

    ではなぜそれでもなおユーザーの予約料金の分布は偏っていたのか? ⇒ 問題は表示している宿が高いことではなく、 検索条件(地域)に対して適切な料金の提案がで きていないことではないのか? ※ Individual Conditional Expectation (ICE) plots(以下論文も参照) Peeking Inside the Black Box: Visualizing Statistical Learning With Plots of Individual Conditional Expectation (Goldstein et al 2015) https://doi.org/10.1080/10618600.2014.907095
  39. 料金差分のDrill Down • 検索に対して適切な料金提案ができているか確かめるため、地域ごとに料金差を確認 ◦ New YorkやSan Franciscoといった人気地域では料金差はほぼ観測されなかった ◦ 一方で、Tail

    Cityで分散が大きかった ⇒原因(の1つ)はTail Cityに対して適切な料金の宿を出せなかったこと 人気の地域は料金の提案と予約料金の差が小さい Tail Cityでの料金乖離が顕著
  40. 4. Two Tower Architecture • 検索クエリと結果の関連を正しく学習するため Two Tower Architectureを提案 ◦

    Pairwiseで学習をするのは同様 ◦ ユーザー・クエリに関する DNN出力との距離に対して Lossを定義している 平均料金は-2.3%に、予約数は+0.6%の改善! • パラメータ数も小さくなり、 Latencyが33%減少する副次的効果も
  41. Two Tower Architectureの評価 • ICE curveは、安い宿に高スコアを与えるだけでなく、特徴的な料金に山をもつ分布に ◦ “Cheaper is better”

    から “Right price for the trip” へ • 様々なクエリ毎に中央の DNNによる100次元の出力の t-SNE plotを作成※ ◦ 料金や地域でクラスタができているわけではなく、宿泊人数(例えば家族旅行か、単独旅行 か)、都市、宿泊日数などの検索文脈によってクラスタが形成されている ※ ラベルは都市名/ゲスト数/宿泊日数、 色は料金(緑ほど安く、青ほど高い) 検索に応じた特徴的な料金帯の山
  42. 話題2: Cold Start問題の改善 • 新着宿は、どのようなユーザーが宿泊してきたかという統計情報がない ◦ 「十分データのある宿」と「新着宿」を比べると、 NDCGで-6%という大きな開き ◦ ゲストのエンゲージメントに関する特徴

    ※1を抜くとNDCGは-4.5%の落ち込み ⇒ 新しく登録された宿が土俵に立つのは難しい • Explore-ExploitそしてのCold Start問題 ◦ ゲストは蓄積データを最大限活用( Exploit)することで適切な宿を知りたい ◦ プラットフォームとしては、新着宿を露出させることでデータを溜め( Explore)、長期的なユー ザー価値につなげていきたい ◦ コストを払ってでも新着宿をブーストしていきたいが許容度もバラバラなはず ※2 ※1: 受け入れてきたゲストに関する情報や宿泊数などの統計 ※2: 例えば、宿が多い人気都市では的外れな新着宿のブーストも気にならないかもしれないが、宿の少ない地域では事情は異なる
  43. ユーザーエンゲージメントの予測 • 新着宿が他の宿と異なるのはエンゲージメント特徴の有無 ⇒新着宿に対して事前にエンゲージメント特徴の影響が予測できれば良い • エンゲージメント特徴の予測手順 ◦ 1億オーダーの検索結果に対して、 Top100の宿から1件ずつランダムサンプル ⇒

    十分閲覧されている宿のデータセットができる ◦ サンプルした宿に対してランク と割引ランク を定義する ◦ エンゲージメント特徴を抜いて、これらの特徴を予測モデルで補完 ▪ このモデルによるランクを とする ◦ によってモデルを評価(0に近いほど良い)
  44. 予測モデルと結果 • 以下の2モデルを比較した 1. ベースライン: ハンドメイドなデフォルト値(既存で運用していた値) 2. 周辺の宿の平均値: 地理的に近く、タイプが同一の宿の特徴平均 ▪

    ゲスト人数が2人の新着宿の場合、近くにあるゲスト人数 2人の宿の平均を使う • オフライン評価: ベースラインに対してエンゲージメント予測の 2乗誤差が42%減少 • オンライン評価: 新着宿の予約が+14%に改善!(全体でも+0.38%の改善)
  45. Related Work • ユーザー がクエリ を発行し、 番目に表示された宿 を予約するかどうかは 以下のモデルで表すことができる ※1

    ※ Click Models for Web Search (Chuklin et al. 2015) https://doi.org/10.2200/S00654ED1V01Y201507ICR043 : のもと表示された宿 が予約したい宿である確率 (本来求めたいもの) : のもと 番目に表示された宿がクリックされる確率 (モバイル端末でアクセスしていたらあまり深くまで探索されないなどユー ザーとクエリに依存した応答をする)
  46. Related Work • Positional biasの影響を除くには、propensity model を 構築して、訓練データをこの逆数で重み付けすれば良い ※1 ◦

    一般的には、counterfactuals を集めるために検索結果に介入(ランダム化など) する必要があるが、今回はそのような介入を行わず実際の検索結果だけを使う ※2 • この論文ではPropensity modelを頑張って作るのではなく、positionをDNNの入力として直接導 入するアプローチを提案 ※1 Unbiased Learning-to-Rank with Biased Feedback (Joachims et al. 2017) https://dl.acm.org/doi/10.1145/3018661.3018699 ※2 予約できる日数がカレンダーやホスト依存であったりと、同じクエリでも同じ宿は様々な位置に表示されている
  47. Position As Control Variable • Two Tower Modelを以下のようにpositional biasのフレームで解釈する •

    ここで、表示位置 への依存を表現 • が と独立であればpositional biasへの影響はノイズとみなせる • 実際にランク付けする際には と置くことでバイアスの入らない評価ができる Relevance prediction Positional bias ※ 今回は十分なデータがあるため、これらのノイズは無視できると仮定する
  48. Position Dropout • Position biasは正しく学習できるようになるが、今度は relevance predictionが位置に依存するよ うになり学習が毀損される可能性がある ◦ 実際、position

    featureを入れることでNDCGが1.3%減少 • そこで、確率的に position featureを0にする dropoutを導入 ◦ Dropout rateは、NDCGとのトレードオフを考え0.15に設定 dropoutを入れないとNDCGの精度が落ちる Dropoutを入れすぎるとpositional biasが考慮できなくなる
  49. 結果 • positon biasを学習するとオンライン評価で +0.7%の予約数改善があった • 3つのアプローチを全て導入することで、最終的に +1.1%の予約数改善を実現した But the

    highlight of our journey is the realization that to push the boundaries of our DNNs, the inspiration was not going to come from some external source. For that we had to follow the lead of our users.
  50. まとめ(所感) • Airbnbの検索モデルの変遷をKDD2018-2020をもとに紹介 ※1 • 継続的にビジネス価値を生み続けているが、そこには多くの失敗もあった ◦ 紹介論文はプロセスや失敗を丁寧に説明している点で学びがあるものだった • 一貫していたのはモデルを不必要に複雑化させない

    ※2、ユーザー理解の重要性 の2点 ◦ 特に後者は、文献の手法をそのまま導入するサイクルではなく、サービス利用者をちゃんと理解しな がらstep by stepで進めるという点でとても重要 ※3 ※1: dynamic pricingの導入(KDD2018)や多様性の導入(KDD2020)など他にも面白い文献は多かったが今回は3本に絞った ※2: とは言え他のAirbnb論文で提案されている手法は結構複雑だったりするが、    あくまで「腹落ちしてない状態でやみくもに外部知見を取りれるのはやめましょう」という意味で理解 ※3: 自分が関わるサービスでもこうした姿勢を意識していきたい