© DeNA Co., Ltd. 1 N=1 の推薦系コンペの戦い方 関西Kaggler会 村上直輝 (kami) 株式会社ディー・エヌ・エー

© DeNA Co., Ltd. 2 kami @634kami © DeNA Co., Ltd. 自己紹介 https://www.kaggle.com/kami634 Kaggle @kami634 ● メガベンチャーのDS ○ 昨年度入社の新卒２年目 ○ 現在は業務中のKaggle工数50% ● 推薦系コンペが得意だと思いこんでいる ○ Kaggleの推薦系コンペは参加したことない ○ 推薦以外のコンペも参加 ■ 鳥の音声認識 ■ 自然言語処理 ■ 系列データ処理 等…

© DeNA Co., Ltd. 3 最近参加した(Kaggle以外の)推薦系コンペ https://www.guruguru.science/kami https://recsys.eb.dk/ ２連覇が自慢です

© DeNA Co., Ltd. 4 目次 自己紹介 推薦タスク概要編 前処理編 (候補生成・特徴量作成) re-ranking 編 1 2 3 4 おまけ 5

© DeNA Co., Ltd. 5 2. 推薦タスク概要編 推薦タスクへのイメージをざっくり掴む

© DeNA Co., Ltd. 6 1 ざっくり説明 　Userに見せるItemを予測するタスク 推薦(レコメンド)タスクについてざっくり 電卓とCDを推薦したら買ってもらえる？ 具体例 ● ECサイトで 「買ってもらいやすい商品」を予測 ● 動画配信サービスで 「５段階の評価値」を予測 ● 広告配信サービスで 「Clickされやすい広告」を予測

© DeNA Co., Ltd. 7 推薦タスクのよくある提出形式・評価方法 ● 提出形式 ○ User ごとに K 個の Item を確信度の高い順に予測 ● 評価方法 ○ 正解(clickされた,購入された)Item が上位になるよう に予測できていれば高いスコアになるような指標 ○ 例：MAP@K, NDCG@K, AUC 2

© DeNA Co., Ltd. 8 推薦タスクのよくあるデータ形式 ● 基本はテーブルデータ ● 細かいところはコンペ・タスクによって色々！ ○ だが基本形がある ● 1+2種類のテーブルデータ(もしくはそれを加工したもの) が中心 ○ User の Log データ：行動ログ。過去好んだItemや正解ラベルの情報を含む ○ 特徴量 ■ User の Master データ：年齢・性別などのユーザの情報 ■ Item の Master データ：推薦したい商品の情報 3

© DeNA Co., Ltd. 9 具体例：atmaCup #16 in collaboration with RECRUIT ● タスク ○ 閲覧履歴から最終的に予約する宿を当てる(推薦する) ● データ ○ train / test_log.csv ■ セッションごとに出現した宿を記録したログデータ ■ 最後に出現した宿は答えにならない ○ train_label.csv：最終的にどの宿を予約したかのデータ ○ yado.csv：宿の属性情報が記録されたデータ ○ その他：宿の画像のembedding ● 分割方法 ○ Train/Test : 時系列で分割 ○ Public/Private: Test をランダム分割 4 Train Public (25%) Private (75%) 時間 Master User に相当するデータはな いが、log データを元に各ユーザー の情報をある程度学習できる input output (候補を10個予測) https://www.guruguru.science/competitions/22/

© DeNA Co., Ltd. 10 推薦タスクのよくある解法 ● その１：ルールベース ○ 一番お手軽だが創意工夫が必要 ○ コンペによってはこれだけである程度戦えることもある ■ 特に User の情報が少ないケース (コールドスタート) で有効な印象 ● その２：協調フィルタリング系の手法 ○ Matrix Factorization、GNNなど色々手法が存在 ● その３：2 stage 推薦システム (今日のメイントピック) ○ 候補生成 → re-ranking の2段階のパイプライン ■ 推薦コンペの上位解法はこれが多い (もしくはこれを組み合わせるor発展させたもの) ○ 候補生成が不要なパターンもある： e.g.) atmaCup#15, RecSys Challenge 2024 ○ 実装は大変だが計算効率を保ったまま LightGBM などで良い性能を出せる 5

© DeNA Co., Ltd. 11 推薦タスクのよくある解法：2 stage 推薦システム ● 1st Stage: 候補生成 ○ 多すぎるアイテムの中から候補を絞ることで、2nd Stage の効率を上げる ○ ルールベース・embeddingと近傍探索を用いる方法などを複数種類組み合わせることが多い ● 2nd Stage: re-ranking ○ 候補アイテムにそれぞれについて LightGBM などで並び替え 6

© DeNA Co., Ltd. 12 推薦タスクのよくある解法：2 stage 推薦システム 7 N=1 の実装上の手順 1. 前処理（候補生成＆特徴量生成） 2. 学習用データ作成 (前処理結果を結合） 3. 学習 (LightGBM, Transformer 等を利用) 候補生成時に 2nd Stage 用の特徴量 を一緒に作ることもある

© DeNA Co., Ltd. 13 N=1 の戦い方 ● 初手 ○ 2 stage のパイプラインを LightGBM 使ってまず一通り組んでみる ■ と言いつつ atmaCup#15 はGNN使いたかったので初手で試した (候補生成が不要なコンペだったし...） ○ 新規ユーザが多い場合(コールドスタート系) の時はルールベースも考えてみる ● その後は以下をやっていく ○ 1st Stage 周りの改善 ○ 2nd Stage 周りの改善 ○ ルールベースとの組み合わせの検討/改善 ○ 協調フィルタリング系の手法との組み合わせの検討/改善 ○ … 8

© DeNA Co., Ltd. 14 3. 前処理編 (候補生成・特徴量作成) 推薦の候補を絞り込む・学習に使う特徴量を作る

© DeNA Co., Ltd. 15 1 ● 推薦タスクのテーブルデータは結構重くなりがち ○ 例：1ユーザに対して500候補作ると、ユーザー数 x 500 行のテーブルを用意する必要がある ● 候補生成や特徴量生成の処理だけでも結構時間がかかることがある ○ 例：RecSys Challenge 2024 の一番効いた特徴量は作るのに数時間かかった 前処理の重要性 候補生成や特徴量は前処理結果を保存して使いまわしたい！！ ※候補生成時に関連する特徴量を一緒に作れることが多いという側面もある ※一方で実験用に作ったデータが使われずにストレージを圧迫することもある（こまめに消す手間がいるかも）

© DeNA Co., Ltd. 16 候補生成の基本 ● さまざまな方法で推薦候補を作成・組み合わせる ○ ユーザにパーソナライズした候補生成の方法 ■ 「ユーザが見たアイテムに似たアイテムを候補にする」 ○ どのユーザにも共通した候補生成の方法 ■ 「人気のアイテムを候補にする」・「最新のアイテムを候補にする」 ● 良い候補生成の方法をどうやって判断する？ ○ 細かい精度は re-ranking でなんとかなる(する)ので recall を高めるのを意識すると良さそう ■ そもそも答えをここで取りこぼすと、あとの re-ranking の意味がない ○ 候補数を増やせば recall は高くなるが、2nd stageでの計算時間も増えるトレードオフがある 2 候補数 少 計算時間 小 候補数 多 recall 良

© DeNA Co., Ltd. 17 特徴量の基本 ● 基本的は3種類ある ○ User の特徴量 ○ Item の特徴量 ○ User×Item の特徴量 ● しかし場合によっては更に種類が増えるケースも ○ 例：Userだけではなくて、Session や Impression ごとの情報も与えられる場合 ■ Session の特徴量、Session × Item の特徴量 ■ Impression の特徴量、Impression × Item の特徴量 ○ 例：Itemのカテゴリの情報も与えられる場合 ■ … 3 User 特徴 Item 特徴 User×Item 特徴 LightGBM等のモデルへ

© DeNA Co., Ltd. 18 具体例を見てみる: 共起・遷移確率系の方法 ● ユーザのログから「共起」や「遷移確率」を考えて候補生成や特徴量に利用できる ○ 共起：Item A と Item B が同時に好まれやすい ○ 遷移確率：Item A を見たら Item C を次に見る確率が高い ● 具体例 ○ ユーザが最後に見た Item に対して、共起(遷移)する確率が高い Item 上位50件を 候補にし、その確率を特徴量にする 4

© DeNA Co., Ltd. 19 具体例を見てみる: Item の類似度を利用した方法 ● Item 間の類似度を計算する方法もある ○ Item の説明文など利用する ■ BERT系のモデルで埋込み cos 類似度を計算 ■ tf-idf を利用 ○ Item の共起関係や遷移の関係をグラフ等にして embedding を教師なし学習で求める ■ item2vec, node2vec や ProNE などで各 Item の embeding を求めて cos 類似度を計算 ● 具体例 ○ ユーザが最後に見た Item に対して、類似度が高い Item 上位50件を候補にし、そ の類似度を特徴量にする 5

© DeNA Co., Ltd. 20 4. re-ranking 編 LightGBM/時間情報の扱い方

© DeNA Co., Ltd. 21 1 2nd Stage: re-ranking の概要 全体の流れをおさらい 1. 前処理等で候補生成・特徴量作成 ← さっきまで話してたところ 2. 学習用データ作成 (前処理結果を結合） ○ 候補生成で正解を拾えなかった場合でも、学習データには含めておくことが多い 3. 学習 (LightGBM, Transformer 等を利用) ← いまここ どんなモデルでやるか？ ● 王道は LightGBM などのGBDT ○ （Transformer などを利用する方法もある。使ったことはない）

© DeNA Co., Ltd. 22 推薦タスクでの LightGBM ● 基本：普通のテーブルデータと変わらない ● 学習方法を変えるのは試すべき ○ 方法１: ２クラス分類等 (ポイントワイズ） ■ objective: binary などにして、普通のテーブルデータと同様に正解を 1, 不正解を 0 とし てクラス分類。その候補１つに対する確率を求める ○ 方法２ : ランキング学習 (ペアワイズ・リストワイズ） ■ objective: labmdarank などにする。Userごとに group 化して学習する ● binaryの方が良い時もあるが、lambdarankの方が性能が良いことが多い印象 ○ objective: rank_xendcg などもあるのでいくつか試してみても良いかも 2

© DeNA Co., Ltd. 23 リークに注意しつつなるべく未来のデータを利用する テストデータが時系列 split されている場合 ● 可能な限り未来のデータを含めて学習したほうが性能が高いことが多い ○ リークしないように full train っぽくやるのが良い 3 Train Private (75%) 時間 Public (25%) Validation Train Private (75%) 時間 Public (25%) 最適なパラメータ・イテレーション数を決定 全データを使って同じパラメータで学習 ※データサイズ合わせるためTrainの前半を捨てるのもありかも

© DeNA Co., Ltd. 24 5. おまけ その他の情報・ちょっとした tips

© DeNA Co., Ltd. 25 1 おまけ：その他の手法について ● 2 stage 以外の手法もある ○ 協調フィルタリング系の手法等 ○ 最近は GNN を使うのが個人的お気に入り ● これらの予測結果を候補生成や特徴量に使っても良い ○ 学習が必要な場合はスタッキングっぽくなる ■ 時間情報がなければ oof を利用するなどリークに注意する ■ 時間情報があれば時系列splitして未来の予測結果を利用するなど注意する

© DeNA Co., Ltd. 26 2 おまけ：大きいデータの取り扱いについて ● マシンリソースは結構必要なことが多い ○ 特にLightGBMで学習する際にメモリは結構必要なイメージ ○ ディスクの利用で節約することは可能だが学習に時間がかかる ● CV,LBが相関するなら小さいデータで高速に実験を回すのを検討しても良い ○ 例：RecSys Challenge 2024 では小さいデータで実験・検証を行っていた ■ 最終提出も全データで学習せずに20%程度のデータで学習していたが性能はあまり変わらず ○ 例：Kaggle のOTTOコンペでも同様のチームがあった模様 ● 前処理のためにpandasではなくBigQueryを使ってみたという人もいる

© DeNA Co., Ltd. 27