糞糞糞ネット弁慶

読んだ論文についてメモを書きます.趣味の話は http://repose.hatenablog.com

Applying Deep Learning To Airbnb Search (preprint) 読んだ

[1810.09591] Applying Deep Learning To Airbnb Search

Airbnb における Search に Deep Learning を導入した話.「機械学習のシステムが既にあってそこにニューラルネットワークを導入したい人」に向けて書かれている.
論文調ではないのでまとめも箇条書き.

モデルの概要

  • 既存の GBDT -> 4層 (中間層は32個,ReLU で活性化) の NN (17年4月) -> Lambdarank NN (17年6月) -> GDBT/FM NN (18年3月) -> Deep NN (18年6月) と段階的に本番環境に導入してきた
    • 最初の NN は損失関数を二乗誤差にしていた
    • Lambdarank NN : 損失関数を Lambdarank のそれにして学習した
    • GBDT/FM NN : 既存の NN に対して以下の特徴量を追加したもの (なぜならそれらのモデルの出力は NN によるものと異なっていたため)
      • GBDT feature : それぞれの木においてどこの leaf に落ちたかを categorical feature として得る
      • FM feature : 32 次元に落とした Factorization Machine の出力を連続値として得る
    • Deep NN : 4層 (195-127-83-1) の DNN.feature engineering はほとんど行っていない.

失敗した試み

代表的なものをふたつ.

  • 物件 ID (Listing ID)
    • Listing ID を embedding して使ったところ overfitting してばかりで精度が下がった
      • 同じ Listing ID が重複して booking log として登場しないため
  • long view (多分ある listing を長い時間閲覧していること) と Booking probability をひとつのネットワークで同時に学習させる multi-task learning (最終層を 2 つにする)
    • long view と booking にある程度の相関があったため
    • また,long view には Listing ID が複数登場するため先程失敗した embedding も効くのではないか
    • しかし実際には long view のみを改善し booking には変化が無かった
      • long view が発生するのは高価な物件,説明文が長い物件,珍しかったり面白い物件といったような booking に直接関係しない要素が原因だったため

Feature engineering

  • 特徴量の値を [-1, 1] に変換する
  • モデルの sanity check として特徴量の値を 2,3,4 倍 としていった時に NDCG が変化しないかを見るといいらしい
  • 位置情報は少し工夫する
    • 物件の緯度軽度は検索時に表示されている地図の中央の緯度経度を基準に変換するだけでは値が中央によりすぎるので,その上で log を取る
      • 相対的な位置情報に変換することで特定の位置情報ではない特徴量が得られる
  • 分布が連続にならない特徴量も組み合わせることで連続になる
    • ひとつの例として,ある時点からの未来における予約率が特徴量として効きそう(人気の物件ほど速く予約が埋まる)が分布が連続ではないので困った
    • 物件ごとに最低日数が設定されており,これが原因で分布がおかしくなっていた
    • 物件ごとの平均利用日数と組み合わせることで分布が連続になった
  • より大域的な位置情報をどう扱うか
    • level 12 の S2 cell で位置情報を取得する
    • その上でクエリと組み合わせて Hash にする
      • 例えば "San Francisco" というクエリに対して Embarcadero のある物件の S2 cell が 539058204 だった場合 `{"San Francisco", 539058204}` を Hash 化して 71829521 という値を得る.これを categorical feature として用いる
      • ここの Hash についてはこれ以上の記述はなし

System engineering

  • パイプラインは Java で構成されている
  • GBDT 時代に CSV を受け渡していたパイプラインを使いまわしていたら学習時間のほとんどを CSV ファイルの変換に使っていることがわかったので Protobuf を使うよう再構築したところ学習も高速化されたので学習に用いるデータを一週間から一月に増やすことができた
  • モデルの学習は Tensorflow で行うがスコアリングは Java で独自に構築した NN ライブラリで行う