Slide 1

Slide 1 text

© commmune Inc. All rights reserved 使い回しやすい 2-stage recommender systemの デザインパターンを考えて実装した話 2024/01/20 #16 atmaCup 表彰式&振り返り会 Kokoro Higuchi

Slide 2

Slide 2 text

© commmune Inc. All rights reserved 自己紹介 樋口 心 Commmune - Data Scientist お仕事 ● 機械学習システムの開発(推薦システム...etc) ● プロダクト KPIの分析 ● (入社して2週間🐣) SNS ● X (旧 Twitter):@zerebom_3 Kokoro Higuchi X アイコン

Slide 3

Slide 3 text

© commmune Inc. All rights reserved 会社紹介 コミュニティ作りに 特化したプロダクト commmune(コミューン) 営業・CSのアクションを 最速で効率化するプロダクト SuccessHub(サクセスハブ) あらゆる組織とひとが融け合う未来をつくる VISION

Slide 4

Slide 4 text

本日お伝えたいしたいこと 1 2-stage recommender systemは 様々なドメイン(atma-16含む)で使える 実装デザインパターンを知って、 自作パイプラインを作っておくと便利

Slide 5

Slide 5 text

本日お伝えたいしたいこと 2 パイプラインに必要な候補・特徴量クラスを ナイーブに実装すると多機能かつ長大になる クラスと責任を分解するとGood

Slide 6

Slide 6 text

© commmune Inc. All rights reserved 作ってきた2-stage recommender systemのドメインと所感 自分が過去に作ってきたドメイン ● ビジネスSNSのマッチング@Wantedly ● 洋服のEC @H&Mコンペ 🥈 ● 総合EC @ottoコンペ 🥈 ● 旅行サイト @atma-16 27位 ● コミュニティプラットフォーム @commmune 所感 ● どのドメインでも2st-recysなら、体感80/100点以上の精度は出せる ● ドメインによらず、割と実装構成は似せることができる ● → 使い回せる自作ライブラリを作ると便利そう!

Slide 7

Slide 7 text

2st-recsysの一般化と要件と実装

Slide 8

Slide 8 text

© commmune Inc. All rights reserved 2st-recsysの入力データ形式 行: 複数の候補生成ロジックの和集合 列: キーとなるID列 + 候補集合の順位,スコア + ユーザー/アイテム/ユーザ*アイテムに紐付く特徴量

Slide 9

Slide 9 text

© commmune Inc. All rights reserved 2st-recsysのCandidateとFeatureの要件? Candidate ● 複数のロジックを使用する ● 各ロジックの和集合をとる Feature ● 複数のロジックを使用する ● 候補集合の和集合に left joinで紐付ける つまり... ● 基底クラスを継承し、For文でJoinすればOK? (Template Methodパターン)

Slide 10

Slide 10 text

© commmune Inc. All rights reserved 隠れていた2st-recsysのCandidateとFeatureの要件 共通 ● 重い処理は一度だけ実行し、保存したい。二度目は読み出したい ● データの取得先や方法を柔軟に変えたい(BQ, インメモリ, csv…) ● 柔軟にデータの保存先を変えたい(Train/ valid / test…, Fold,....) ● 各ロジックごとに検証したい(欠損値はないか、len() != 0...) Candidate ● 複数のTOP KでRecallやなどMetricを評価したい Feature ● ロジックは同じだけど、 join先のkey_colsを可変にしたい (ex. item2itemの推薦) ● 実験を経て、使うカラムを柔軟に決めたい

Slide 11

Slide 11 text

© commmune Inc. All rights reserved 巨大Candidate Classの完成😭 ナイーブに盛り込むと、多機能で取り回しづらいクラスになる ● 持っている機能 ○ 入力データのダウンロード ○ 候補集合の生成 ○ 候補集合の保存 ○ 候補集合の評価 ○ 候補集合の検証 ● 巨大クラスの弊害 ○ 引数の順番ミスによるエラー発生 ○ 可読性低下 ○ ドメインごとに一部だけ変えることが難しい

Slide 12

Slide 12 text

© commmune Inc. All rights reserved 解決策: 責務ごとにクラスを作り、委託する(Strategy パターン) 責務ごとにクラスを分けるメリット ● 必要なところだけ独立で呼び出せる ○ クラスを通さずアドホックに作った候補集合を評価 ○ 入力データのダウンロード機構を特徴量にも流用 ● 必要なところだけ作り替えられる ○ DataLoaderだけcsv → BQに ● → 様々なドメインで使い回しやすくなる👌

Slide 13

Slide 13 text

© commmune Inc. All rights reserved Class図 Before / After

Slide 14

Slide 14 text

© commmune Inc. All rights reserved 作ってどうだったか? これらを踏まえ、コンペ中にscortaという自作ライブラリを作りました: https://github.com/zerebom/scorta Good ● 複雑化したコンペ終盤でもエラーなく、速度を落とさず実験できた ● 業務でもatmaでもscortaのコードをほぼ流用して、すぐに2-stage recsysを実装できた Bad ● 短期コンペで作り始めたので、序盤は精度改善できなかった ○ 有休期間だったからこそ作れたかも ● ライブラリに熱中すると精度改善が疎かになる🙃