BigQueryで参加するレコメンドコンペ / bq-recommend-competition-kaggle-meetup-tokyo-2023

Slide 1

Slide 1 text

Slide 2

Slide 2 text

自己紹介島越直人よくトリゴエと間違えられますがシマコシです ● 経歴 ○ 京都大学機械理工学専攻卒業 ○ 2019/04 ~ 2023/04 DeNA Data Scientist ■ (2020/04 ~ 2022/03) GO株式会社に出向 ○ 2023/04 ~ LayerX 機械学習エンジニア ML Team Tech Lead ● Kaggle ○ Kaggle Competitions Grandmaster ○ 色々なドメインのデータに触れるのが好きなので色々やってます @nt_4o54 @shimacos

Slide 3

Slide 3 text

レコメンドコンペ

Slide 4

Slide 4 text

© 2023 LayerX Inc. 4 Kaggleで行われたレコメンドコンペ ● OTTO – Multi-Objective Recommender System ○ Session-based Recommendation ○ クリックやカート追加、購入などのsession毎の時系列からその後に何のitemに対してどんなアクションを取るかを予測 ● H&M Personalized Fashion Recommendations ○ Batch Recommendation ○ 7日後までにどの商品を購入するかを予測

Slide 5

Slide 5 text

Slide 6

Slide 6 text

© 2023 LayerX Inc. 6 一般的な処理方法 Pandas ● 言わずと知れたテーブルデータ処理ライブラリ ● 遅い ● (使い慣れてる) Polars ● Rust製のテーブルデータ処理ライブラリ ● 高速 ● CPU上で動く cuDF ● Nvidia製のテーブルデータ処理ライブラリ ● 高速 ● GPUがないと使えない ● GPUのメモリに載る量しか扱えない BigQuery ● GCP上で動くDWH ● SQLさえ書けば、勝手に分散して最適化してくれるため高速 ● 1TB scanあたり500円くらいお金がかかる

Slide 7

Slide 7 text

© 2023 LayerX Inc. 7 一般的な処理方法 Pandas ● 言わずと知れたテーブルデータ処理ライブラリ ● 遅い ● (使い慣れてる) Polars ● Rust製のテーブルデータ処理ライブラリ ● 高速 ● CPU上で動く cuDF ● Nvidia製のテーブルデータ処理ライブラリ ● 高速 ● GPUがないと使えない ● GPUのメモリに載る量しか扱えない BigQuery ● GCP上で動くDWH ● SQLさえ書けば、勝手に分散して最適化してくれるため高速 ● 1TB scanあたり500円くらいお金がかかる今日はこの部分を紹介

Slide 8

Slide 8 text

© 2023 LayerX Inc. 8 BigQueryのメリット・デメリットメリット ● 最終的なデータセットを手元に落として訓練・予測するまではlocalにリソースが必要ない。 ● あまりゴリゴリ最適化せずとも雑にSQLを書いて高速に動作する ● クエリjobを並列に投げておけば、お手軽に並列で特徴量などを作れる。 ● WINDOW関数が便利で、直近N時間とか直近N分のようなRolling特徴が作りやすいデメリット ● 課金が発生する。 ● 細かいcandidatesのRecall Tuningなどinteractiveに結果を確認したい場合面倒。 ● 特徴量が増えてくるとダウンロード速度がボトルネックになってくる。 ● item2vecなどpython経由で候補を作成する場合に一度localを経由するので面倒。

Slide 9

Slide 9 text

OTTO – Multi-Objective Recommender System の場合

Slide 10

Slide 10 text

© 2023 LayerX Inc. 10 問題設定 ● Sessionの途中まで与えられて、その後にクリックする商品、カートに入れる商品、注文する商品を当てる ● データサイズ ○ train: 2億行 (!) (4week分) ○ test: 700万行 (1week分) ○ sessionとaid (item_id)、時間、action_typeが記録されている ● 2億行のデータの取り回しに苦労する

Slide 11

Slide 11 text

© 2023 LayerX Inc. 11 学習方針 ● test期間は1week分なのでtrainの最後1weekで学習させる ● 最後1weekのsessionをrandomにtruncateして自分でラベルを作成 ● 特徴量などは訓練全体とtruncateした前半部分を用いる ● test期間を予測する時は、trainとtest部分を使って再度特徴量を作り直す特徴量・候補作成期間 (Train時) Train期間特徴量・候補作成期間 (Test時)

Slide 12

Slide 12 text

Slide 13

Slide 13 text

© 2023 LayerX Inc. 13 BigQueryが活きる例 ● 例えば、同じsessionに対して直近前後1時間にアクションされたaidが共起しているとして共起行列を作りたいとなった場合どうしますか？ ● polarsの場合 ○ 「えーまず、同じsessionでdfをjoinして、timestampの差分が1時間以内のものにして。。。」 → joinで死ぬ (chunkでやれという話はあります)

Slide 14

Slide 14 text

Slide 15

Slide 15 text

今日は時間がないのでTIPSだけ紹介します！細かい部分は公開Notebookを見てみてください！

Slide 16

Slide 16 text

Slide 17

Slide 17 text

© 2023 LayerX Inc. 17 TIPS 1: Jinja2 Templateを活用する ● 例2) 特徴量のaggregationと命名がpandasなどと比べて面倒解) for文を使うことで feature = df.groupby(cols).agg([‘mean’, ‘std’]) feature.columns = [‘-’.join(cols) for cols in feature.columns] を擬似的に再現できる

Slide 18

Slide 18 text

© 2023 LayerX Inc. 18 TIPS 2: shuffleした時の再現性はFARM_FINGERPRINTを使う ● 例) Negative Sampling時に全体からランダムに負例を持ってきたいが、　　　　RAND()を使うと再現性がなくなる ● 解) ユニークなkeyにseedをくっつけ、　　　　FARM_FINGERPRINGで乱数を発生させた上で並び替える ※ ちなみにただのROW_NUMBERだけだと本質的にRandomに並び替えられずbiasがかかる。 (shimacosはこれで数日溶けた)

Slide 19

Slide 19 text

© 2023 LayerX Inc. 19 TIPS 3: localに持ってくる時はBQ storage APIを使う ● 例) TableをBQで作ったのはいいもののlocalに持ってくるのが遅い ● 解) storage APIを使ってdownloadする。少し課金が走るが14292091 x 31くらいなら15secでdownloadできる。 ※ storage APIを使う場合、ORDER BYをクエリに含めていてもsortされずに返ってくることがあるので注意

Slide 20

Slide 20 text

© 2023 LayerX Inc. 20 TIPS 4: 予測時はCluster化して少しずつ予測を行う。 ● 例) TestデータはNegative Samplingできないので、データセットがデカくなる ● 解) sessionでCluster化してN session単位で予測する。 Cluster化することで毎回全スキャン走らないので課金を減らせる。前もってsampleしたidのリストを作っておく