実務でレコメンドをやっているのでKaggle H&Mコンペに参加しました
最近Kaggleで開催されていた、H&M主催のファッション推薦コンペに参加しました。自分はファッションEC企業でレコメンドシステムの構築に関わっており、このコンペはまさに自分が扱っている技術・ドメインの問題です。腕試しと技術研鑽のため、参加することにしました。
結果は25位という、なんとも言えない悔しい結果になってしまいましたが (gold が欲しかった)、色々学びがあったので記録を残しておきます。1
自分の解法は以下の discussion に上げています。
なお一口に業務のレコメンドと言っても、バッチで1日一回だけ計算をすれば良いのか、オンラインでリアルタイムに推論するのか、組織のMLインフラが整っているのか等によって使う技術や考慮事項は変わってくるはずです。ここで書くことはそのようなレコメンドという広い領域の一部を経験した者からの主観的な感想です。
コンペの概要
詳細はコンペのページを見てください。
データセット
H&Mから以下のようなデータが提供されました
- 2年分の購買トランザクション
- ユーザーのメタデータ
- アイテムのメタデータ
これをもとに、ユーザーの将来7日間の購買予測をするコンペです。アイテムの情報として、カテゴリや価格のデータだけでなく、画像や商品説明文もあるのが特徴でした。アイテムのユニーク数は約10万、ユーザーのユニーク数は約100万で、比較的規模の大きいデータセットになっていました。
基本的には（画像や説明文を除けば）テーブルデータのタスクなのですが、与えられたデータに正例・負例のラベルがついているわけではありません。あくまでユーザーがいつ何を買ったかというデータがあるだけで、負例は存在しません。いわゆる implicit feedback の問題です。実務ではあるあるの設定なので、経験者はアドバンテージがあったと思います。
実務のデータと比較して
データの形式としては比較的実務に近いと思います。一つ大きな違いはユーザーの行動履歴が購買しかないことでした。通常ECサイトを運営していれば、購買以外にも様々な行動のログが落ちているはずで、以下のような情報が有用なはずです。
- ユーザーのアイテム閲覧行動（購買行動よりはるかに数が多い）
- セッションにおけるアイテム閲覧系列
- e.t.c.
行動情報が限られているのは
- H&Mには実店舗もあるので、実店舗を中心に使うユーザーとECサイト中心に行動するユーザーとの扱いが公平になる
- そもそも閲覧ログのデータ量は購買より桁で多いので、コンペで使うには大きすぎる
という事情があるのだと想像しています。
解法
2-stage レコメンド
人気 discussion で紹介されていたこともあり、2-stage レコメンドを採用する人が多かったと思います。2-stage レコメンドは、まず粗い方法でアイテムコーパスから少数の関連アイテムを抽出し (1st stage, candidate generation)、その後高精度なモデルで結果を並び替える (2nd stage, reranking) 手法を指します。最初から高精度な 2nd stage モデルでスコアをつけられれば良いのですが、ユーザー・アイテムの数がある程度多くなると、計算量的に厳しくなります。そのような場合によく取られる手法だと思います。自分も同じ方針でモデリングしました。
なお、2-stage レコメンドは多くのテック企業で事例があります。パッと思いつくだけでも
などがあります。実応用もされているレコメンドの strategy を学ぶという意味で良いコンペだったと思います。
上位の解法
コンペ終了後上位の解法に目を通しましたが、どれも大枠では似通っていました。
- 1st stage: 質の高い複数の candidate generation をする
- 2nd stage: GBDTで reranking
パッと見る限り、2nd stage に使う特徴量はどのチームも似たような感じでした。ただ 3rd place solution ではBPRで作った user2item similarity が有効だったと報告されており、特徴量の作り込みが大事なことには変わりないようです。
スコアに大きな差を生むのは 1st stage の質だったように感じました。ここで色々な可能性を探索して recall が上がるように調整できたかどうかが重要でした。多くの解法に共通しているのは
- 再購入: ユーザーの過去購入と同じアイテム、もしくは同じ product code の商品（色違いなど）を推薦する
- アイテムベース協調フィルタリング
- 人気アイテム
です。再購入の重要度が高いのは面白く、ベーシックなアイテムが安価に購入できるH&Mならではの特徴なのかもしれません。
ここでの解法をそのまま実務に応用できるかは組織のインフラによるわけですが、個人的には candidate generation の質の重要性を改めて確認できたという意味で勉強になりました。
ニューラルネットワークの有効性
またニューラルネットワークを使った解法が少なかったことも面白かったです。上位解法では、「NN試したけど微妙だった」というコメントがいくつかありました。例えば 1st place solution には
I tried FM for recall and MLP,transformer for rank,didn’t work.Luckily I gave up soon to focus on GBDT.
とあり、また 2nd place solution には
Deep learning models - I tried several recbole models but they weren’t so good.
とありました。2 ちなみに自分は時間がなかったこともあり、そもそもNNを深くは検討しませんでした。
一方、産業界ではレコメンドでもNNにシフトしていく動きが多いように思います。例えば最近出ていた Netflix の論文 では、彼らがなぜNN系の技術を選択するようになったかが説明されています。エコシステムが充実しておりエンジニアリング観点のメリットが大きい、様々なソースからの heterogeneous な特徴量を使うことによる性能向上が大きいという内容です。NNの方が分散学習させやすかったり、ベクトル近傍探索で candidate generation ができたりするので、規模が大きくなるほどメリットも増すように思います。
まとめ
機械学習コンペに初めて参加しましたが、公開ノートブックや discussion によって高速で学べることは素晴らしかったです。明確に順位がつくので自分のスキルを客観視することができました。特に、上位解法を見ると、あの部分をもう少し深掘りしていれば…という悔しい気持ちになります。
一方コンペはあくまでコンペなので、切り分けは当然必要です。特に、実務のレコメンドでは真に改善したいオンラインのメトリクスと、オフラインで試行錯誤して最適化するメトリクスがきちんと相関するかが大きな課題になります。3 そのためオフラインでの改善だけでなく、高速にABテストを回してオンラインでの仮説検証をすることも重要なように思います。
Kaggle 初参加で取り組んだ期間も実質一ヶ月だったので、そこそこ健闘したと思いたい。
RecBole はレコメンドアルゴリズムのライブラリの一つ。NN系が多い。
例えば Netflix の報告でも、オフラインとオンラインのメトリクスの乖離が課題に挙げられています。