Kaggleコンペティション解法紹介 H&M Personalized Fashion Recommendations Kazuki Fujikawa

▪ コンペティション概要 ▪ ベースライン手法 ▪ 弊チームのSolution ▪ TopチームSolution Agenda 2

▪ コンペティション概要 ▪ ベースライン手法 ▪ 弊チームのSolution ▪ TopチームSolution Agenda 3

▪ H&Mの購買履歴データを基に、各顧客の翌週購入商品を当てる 推薦タスク ▪ 顧客130万件, 商品1万件, 購買履歴総数300万件の大規模データ ▪ 商品メタ情報, 画像, 購買履歴データが与えられる コンペティション概要: タスク 2020-09-02 2020-09-05 2020-09-15 4 図: Competition Dataより引用

▪ 時間軸と共に売れ筋商品は変化する ▪ 毎週新商品が登場し、商品ID（article_id）は基本大きくなっていく ▪ LB評価週で初めて登場する商品も存在することが想像される ▪ 古い商品も売れ筋は根強く残る コンペティション概要: 売れ筋商品の変化 5 最新週 商品ID （e.g. 108775015）

2020-09-22 2018-09-20 ▪ 最終週の顧客の購買が評価対象 ▪ 1週間単位で遡って訓練データ化 ▪ ※本資料で “CV” と表記してるのは fold=0 に対する評価（holdout） コンペティション概要: データ分割 6 X 2020-09-29 2020-09-15 2020-09-08 2020-09-01 y X y X y y X submission fold=0 fold=1 fold=2

▪ 評価指標: MAP@12 ▪ 130万人の顧客全てに対し、12件の商品IDを記述して提出する ▪ 12件のうち、正解が前の方に含まれていればスコアが高くなる コンペティション概要: 評価指標 TopK precision 正解なら1, 不正解なら0 7 図: Competition Overviewより引用

8 ▪ 12位で金メダルは獲得🥇 ▪ ただし、1・2位とは大きく差を離されての完敗。。。 コンペティション概要: 結果 図: Competition Leaderboardより引用

▪ コンペティション概要 ▪ ベースライン手法 ▪ 弊チームのSolution ▪ TopチームSolution Agenda 9

10 ▪ 3つのルールを組み合わせたベースライン ▪ ① そのユーザの直前週の購入商品をそのまま並べる ▪ CV: 0.0217 ▪ ② ①を、類似商品に置換して並べる ▪ CV: 0.0069 ▪ ③ 最新週の人気Top12件をそのまま並べる ▪ CV: 0.0087 ベースライン by @cdeotte CV: 0.0264, LB: 0.021 2020-09-22 2018-09-20 2020-09-29 2020-09-15 2020-09-08 2020-09-01 X y fold=0

11 ▪ 3つのルールを組み合わせたベースライン ▪ ① そのユーザの直前週の購入商品をそのまま並べる ▪ CV: 0.0217 → 0.0091 ▪ ② ①を、類似商品に置換して並べる ▪ CV: 0.0069 → 0.0043 ▪ ③ 最新週の人気Top12件をそのまま並べる ▪ CV: 0.0087 → 0.0056 （参考: 最新1週を捨てた場合）CV: 0.0264 → 0.0121 2020-09-22 2018-09-20 2020-09-29 2020-09-15 2020-09-08 2020-09-01 X y fold=0

12 ▪ 顧客毎の推薦候補商品を生成 ▪ 各customerの直前週の購入商品 ▪ 最新週の売れ筋Top12 ▪ LightGBMRankerによってランク学習 ベースライン by @radek1 [CV: ???, LB: 0.019] 購入週の商品 （=GT） その顧客の 直前週購入商品 最新週 売れ筋Top12

▪ 各商品に埋め込みベクトルを割当て、候補 x 購買の類似度行列を構築 ▪ 翌週購買有無の推定に役立つように埋め込み空間が訓練される ▪ 類似度最大の購買商品に対する特徴量を基に、翌週購買有無を予測 ▪ コサイン類似度・購入後の経過週数・商品毎の学習可能な1dパラメータ ベースライン by @aerdem: [CV: 0.0254, LB: 0.019] 購買商品埋め込みベクトル (例) 3件 x 5d　 候補商品埋め込みベクトル (例) 6件 x 5d　 コサイン類似度行列 (例) 3件 x 6件　 類似度Top1商品に対する特徴量 (例) 6件 x 3d　 MLP 翌週購買有無ロジット (例) 6件 x 1d　 13 BCELoss + DiceLoss

▪ コンペティション概要 ▪ ベースライン手法 ▪ 弊チームのSolution ▪ TopチームSolution Agenda 14

15 弊チームSolution概要 図: 12th place writeup より引用

16 ▪ 候補グループ毎にモデルを作り、重み付き平均で混ぜる ▪ 重みはOOFに対するGrid-Searchで決定 GBDT [CV: 0.0390, LB: 0.0324] All candidates （約10万件） ① Re-order: その顧客が過去購入した 商品そのもの （中央値: 8件） ③ Last week top1k: 直前週の人気1000件 からRe-orderを除外 （~1000件） ② Other colors: その顧客が過去購入した 商品の色違い （中央値: 8件 * 色種） GBDT GBDT GBDT ① Candidates: ①モデルで推論した 各候補に対する確率値 ② Candidates: ②モデルで推論した 各候補に対する確率値 ③ Candidates: ③モデルで推論した 各候補に対する確率値 Candidates: ①②③の確率値を 重み付け平均

候補: 約3万件 ● 顧客に拠らず、直近5週 でアクティブな3万件 ● GBDTより多量の候補を 少ない時間で推論可能 17 NNモデル改善 [CV: 0.0348~352, LB: 0.0298~0.0303] ①メタ情報埋め込みベクトルの導入（+α） （CV:0.0254→0.0298） ⑤EfficientNet PCA, deepwalk, w2vの導入 （CV:0.0345→0.0352） EfficientNet + PCA ②Likelihood dropout （CV:0.0298→0.0306） ● 商品ID毎の1Dパラメータ(Likelihood) は過学習しやすい ○ 初期値ゼロ、顧客に寄らない商品 の出現頻度が学習される ○ 訓練⇔検証・テストで頻度分布は 異なり、過学習に繋がりやすい ○ 検証・テストで初めて出現する 商品はゼロのままで、異常データ になり得る ● 学習時にランダムに0を入力する ことで性能改善 ④Top2~5 features （CV:0.0327→0.0345） ● 購買商品に対する特徴量を追加 ○ その顧客の最終購入週の 何週前の購入か ○ 何週購入したか ○ 通算何点購入したか ● 類似度Top1 → Top2~5 を算出 ③1e-2*DiceLoss （CV:0.0306→0.0327） ● BCELoss, DiceLossの スケールの違いを吸収

18 ▪ NNモデルの予測値を入力にGBDTでスタッキング NNモデルスタッキング [CV: 0.0374, LB: 0.0313] GBDT 翌週購買有無ロジット (例) 6件 x 1d　

19 ▪ 各モデルの出力候補を重み付けランク平均 ▪ 重みはOptunaで最適化 GBDT+NNのアンサンブル [CV: 0.0405, LB: 0.0339] 商品ID スコア aaaa 1/1 * 1 = 1.0 bbbb 1/2 * 1 = 0.5 cccc 1/3 * 1 = 0.33 dddd 1/4 * 1 = 0.25 商品ID スコア bbbb 1/1 * 0.5 = 0.5 dddd 1/2 * 0.5 = 0.25 eeee 1/3 * 0.5 = 0.17 aaaa 1/4 * 0.5 = 0.13 商品ID スコア aaaa 1.0 + 0.13 = 1.13 bbbb 0.5 + 0.5 = 1.0 dddd 0.25 + 0.25 = 0.5 cccc 0.33 + 0 = 0.33 eeee 0 + 0.17 = 0.17 モデルA: weight=1.0 モデルB: weight=0.5 アンサンブル後

▪ コンペティション概要 ▪ ベースライン手法 ▪ 弊チームのSolution ▪ TopチームSolution Agenda 20

21 ▪ Topチームの大半はRetrieval & Rankingのフレームワークを使用 ▪ ②の特徴量エンジニアリングの貢献は限定的で、①の候補作りが鍵 （by 1st place） TopチームSolution: 概要 All candidates （約10万件） ① xxxx ③ zzzz: ② yyyy: GBDT Candidates : ① Retrieval: 顧客毎に候補を絞り込み ② Ranking: ①で出力された候補を並び替え 引用: https://www.kaggle.com/competitions/h-and-m-persona lized-fashion-recommendations/discussion/324486

22 ▪ Retrieval ▪ 各顧客に対する候補Top100の正例濃度を高めることに集中 ▪ 最新週: 39142件 / 213728件（Recall: 18.3%） ▪ Ranking ▪ retrieval戦略から得られる特徴量が中心 ▪ 特徴量エンジニアリングよりも、候補戦略が鍵だった 1st place (senkin13 & 30CrMnSiA) [Public: 0.0372, Private: 0.0379] 引用: https://www.kaggle.com/competitions/h-and-m-personalized-fashion-recommendations/discussion/324070 Reorder, Other colors, Last week top1kと同等?

23 ▪ Retrieval ▪ 単純な戦略で600件の候補を選択後、GBDTで130件に絞り込み ▪ 600件: 最近の売れ筋・ユーザが過去購入したセクション下での売れ筋商品 ▪ ItemCFなど候補戦略を工夫しても改善に繋がらなかった ▪ Ranking ▪ より複雑な特徴量（以下）を使ってTop12をGBDTで推論 ▪ single: 0.0355, @paweljankiewicz候補追加: 0.0362, ensemble: 0.0368 2nd place (@wht1996) [Public: 0.0368, Private: 0.0374] 引用: https://www.kaggle.com/competitions/h-and-m-personalized-fashion-recommendations/discussion/324197

24 ▪ Retrieval ▪ 商品の人気度合いを以下の属性でグループ化してソートする ▪ postal code & age でグループ化してソートするのが有効だった 2nd place (@paweljankiewicz) [Public: 0.0368, Private: 0.0374] 引用: https://www.kaggle.com/competitions/h-and-m-personalized-fashion-recommendations/discussion/324197

25 ▪ レコメンドタスクにおいて、Retrieve → Ranking のアプローチが 非常に有効だった ▪ 弊チームはRetrieveでのrecall向上が不十分だった ▪ 特にItemCF系は取り入れられていない ▪ NNも Retrieve → Ranking に載せる検討を進めるべきだった ▪ 候補を並び替える問題をNNで解くことは考えてなかった ▪ 46th: Embedding based Retrieve (LB: 0.021) → Transformer Ranking (LB: 0.028) の二段階化することで精度改善していたらしい ▪ NNで候補出し→GBDTでランキングをちゃんと考えるべきだった ▪ 初期に話題が挙がっていたが、OOF作る部分で問題が生じて他のタスクを 優先してしまった。。 まとめ