マッチングアプリとデータサイエンスでより良い出会いを / Better Encounters with Dating App and Data Science

2023年6月9日開催 Women in Data Science Tokyo @ IBM
KEYNOTE資料
Speaker: 橋爪 友莉子 氏
機械学習エンジニア

株式会社サイバーエージェント
メディア統括本部
Data Science Center

https://widstokyoibm2023.splashthat.com/

Transcript

1. マッチングアプリとデータサイエンスで より良い出会いを CyberAgent, Hashizume Yuriko
2. 本セッションの N 投稿について
 N 投稿：　　全てOK
 
 OK: テキストによる文字のみの投稿
 
 OK: スクリーンショットの画像/動画を含んだ投稿
 
 ハッシュタグ: #WiD 2023 #WiD okyoIBM

3. 3 自己紹介 橋爪 友莉子 ( ゆっこ ) • 21年度入社 ( 新卒3年目 ) • ML Engineer @サイバーエージェントメディア事業部DSC ( メディアのデータ横軸組織 ) ◦ タップルの推薦システムの分析と開発 ◦ タップルのその他の分析もろもろ • 興味 ◦ 推薦システム、NLP、分散処理、MLOps、面白いって思ったら基本気になるので、た さん首を突っ込みます ◦ ユーザ理解、ユーザがちょっと幸せになること • 趣味 ◦ カメラ、邦ロック、走る Twitter: @runnlp
4. 4 話すこと ✗ マッチングアプリとデータサイエンス ✗ サイバーエージェントにお るメディア事業部とデータ活用 ✗ マッチングアプリにとって正解は？ ✗ データによって解決したい課題例 ✗ 相互推薦システムと活用事例 ✗ item-to-user推薦と相互推薦の違い ✗ 相互推薦を構成する2つの要素と2つのトピック ✗ 協調フィルタリングベースの推薦アルゴリズムの一例 ✗ データの力で誰かをちょっと幸せにするために ✗ 3年目の機械学習エンジニアのこれまでとこれから ✗ 技術に張りながらもユーザ理解によって顧客体験を変えるための取り組み
5. 5 話すこと ✗ 今日のゴール ML/DSの若手の働き方 が知れた マッチングアプリの データ活用について わかった 推薦について 少し理解が深まった
6. マッチングアプリと データサイエンス 1
7. サイバーエージェント 7 ✗ 広告事業、メディア事業、ゲーム事業
8. メディア事業部 8 ✗ 動画, ブログ, 公営競技, 音楽エンタメ, ECなど 約20事業の toCサービス
9. メディア事業部 9 ✗ ビジョン 21世紀を代表する toCサービス を創る
10. メディア事業部 Data Science Center 10 ✗ メディア事業部のサービス向 のデータ横軸組織 ✗ サービスメンバーとともにデータ活用 ✗ 基盤システムを提供 データ 戦略立案 データ エンジニア リング データ分析 機械学習 データ サイエンス データ基盤 システム 提供 ↑私はここの所属で マッチングアプリ「タップル」に対して データ活用で事業貢献するお仕事をしている
11. メディア事業部 Data Science Center 11 ✗ メディア事業部のサービス向 のデータ横軸組織 ✗ サービスメンバーとともにデータ活用 ✗ 基盤システムを提供 データ 戦略立案 データ エンジニア リング データ分析 機械学習 データ サイエンス データ基盤 システム 提供 ↑私はここの所属で マッチングアプリ「タップル」に対して データ活用で事業貢献するお仕事をしている
12. マッチングアプリ 「タップル」 12 共通の趣味や行きたいところから恋の相手を見つ ることができるマッチングアプリです。
13. マッチングアプリにとって正解は何？ 13 ✗ 課金して貰えばいい？ ✗ ユーザ体験が良いと継続してくれる？ ✗ 使い続けてもらいたい？ ✗ マッチがたくさんあればいい？ ✗ 安心安全は絶対に必要だよね？ ✗ ゴールは、デートして付き合うこと！
14. 解決したい課題の例 14 ✗ 誰に誰を推薦する？ -> ユーザ推薦 ✗ 安心安全に使ってほしい -> 監視フィルタ ✗ 新機能を使ってほしい -> WISH推薦 ✗ 事業指標に影響を与えやすいデータ活用って？ -> データ戦略立案 ✗ 正し 施策の評価をしたい -> ABテストなど
15. 解決したい課題の例 15 ✗ 誰に誰を推薦する？ -> ユーザ推薦 ✗ 安心安全に使ってほしい -> 監視フィルタ ✗ 新機能を使ってほしい -> WISH推薦 ✗ 事業指標に影響を与えやすいデータ活用って？ -> データ戦略立案 ✗ 正し 施策の評価をしたい -> ABテストなど 参考資料 • マッチングサービスの画像審査にお る機械学習の応用 / Application of machine learning in image examination - Speaker Deck • AI/ Data Technology Map
16. 解決したい課題の例 16 ✗ 誰に誰を推薦する？ -> ユーザ推薦 ✗ 安心安全に使ってほしい -> 監視フィルタ ✗ 新機能を使ってほしい -> WISH推薦 ✗ 事業指標に影響を与えやすいデータ活用って？ -> データ戦略立案 ✗ 正し 施策の評価をしたい -> ABテストなど デートプランカードが導入されたときに設定率を上げるために 起動時推薦を実施
17. 解決したい課題の例 17 ✗ 誰に誰を推薦する？ -> ユーザ推薦 ✗ 安心安全に使ってほしい -> 監視フィルタ ✗ 新機能を使ってほしい -> WISH推薦 ✗ 事業指標に影響を与えやすいデータ活用って？ -> データ戦略立案 ✗ 正し 施策の評価をしたい -> ABテストなど 事業指標と施策の関連性を探る
18. 解決したい課題の例 18 ✗ 誰に誰を推薦する？ -> ユーザ推薦 ✗ 安心安全に使ってほしい -> 監視フィルタ ✗ 新機能を使ってほしい -> WISH推薦 ✗ 事業指標に影響を与えやすいデータ活用って？ -> データ戦略立案 ✗ 正し 施策の評価をしたい -> ABテストなど 事業指標と施策の関連性を探る 正しく効果を測るための工夫もろもろ 例えば、マッチングの推薦のABテストでは、いいかもする人とありがとうする 人の両側に人がいるので、単純な分割ではだめ (STUVAの問題)
19. 解決したい課題の例 19 ✗ 誰に誰を推薦する？ -> ユーザ推薦 ✗ 安心安全に使ってほしい -> 監視フィルタ ✗ 写真の撮り方がもったいない... -> モテ写真 ✗ 新機能を使ってほしい -> WISH推薦 ✗ 事業指標に影響を与えやすいデータ活用って？ -> データ戦略立案 ✗ 正し 施策の評価をしたい -> ABテストなど マッチ成立の流れ いいかも→ありがとう (=マッチ) → メッセージができるようになる https://tapple.me/ 累計会員数1700万人が利用 しているので 全員見るのは難しい 　　　　　↓ それぞれに合ったお相手を 推薦したい 今日話すこと
20. 相互推薦システムと 活用事例 2
21. マッチングアプリにおけるユーザ推薦とは 21 男性には女性を、女性には男性を推薦する (※アプリによっては同性同士のマッチもある) ユーザにマッチしそうなユーザを 互いに推薦する =相互推薦 双方のユーザがマッチングの推薦に 満足する必要がある
22. 相互推薦が必要となるサービス 22 ✗ マッチングアプリ (Online Dating) ✗ 仕事探し ✗ オンライン学習 ✗ SNS
23. item-to-user推薦と相互推薦の違い 23 item-to-user推薦 ✗ ユーザuに対して、アイテムiを推薦する ✗ 複数のユーザにアイテムを推薦するこ とができる ✗ 良い推薦できたからといって、ユーザ がシステムから離脱するわ ではない ✗ 推薦成功は推薦を受 ユーザの満足に よって決まる 相互推薦 ✗ ユーザuにユーザvを推薦する ✗ ユーザu,vがどちらも推薦を受 入れた場合に 他のユーザにユーザu,vを推薦できな なる ✗ アプリケーションによっては、推薦がうま い と、ユーザはそのシステムを使用する必 要がな なり、離脱してしまう ✗ ユーザu,vが互いに満足しないと、推薦成功と はならない
24. item-to-user推薦の場合 相互推薦を構成する2つの要素 24 24 ユーザu→ アイテムi の Preference Score 行動履歴や属性データなど ユーザに関するデータ それぞれの アイテムに 対する Preference Score を 推論する それぞれのアイテムに対するPreference Scoreがわかれば ソートして、候補生成なりリランキングなりに使える コンテンツベースや協調フィルタリングなどの アルゴリズムによって 推薦リスト作成
25. item-to-user推薦の場合 相互推薦を構成する2つの要素 25 25 ユーザu→ アイテムi の Preference Score 行動履歴や属性データなど ユーザに関するデータ それぞれの アイテムに 対する Preference Score を 推論する それぞれのアイテムに対するPreference Scoreがわかれば ソートして、候補生成なりリランキングなりに使える コンテンツベースや協調フィルタリングなどの アルゴリズムによって 推薦リスト作成 ここで... 相互推薦の場合 単方向のScoreだ では 両ユーザを満足させる推薦が 実現できない
26. 相互推薦を構成する2つの要素 26 26 ユーザu→ ユーザv の Preference Score 行動履歴や属性データなど ユーザに関するデータ Preference Score を 推論する 26 26 ユーザu→ ユーザv の Preference Score ユーザv→ ユーザu の Preference Score 相互推薦の場合
27. 相互推薦を構成する2つの要素 27 27 ユーザu→ ユーザv の Preference Score 行動履歴や属性データなど ユーザに関するデータ Preference Score を 推論する 27 27 ユーザu→ ユーザv の Preference Score ユーザv→ ユーザu の Preference Score 相互推薦の場合 ① ①ユーザそれぞれ単方向の Preference Scoreを推論する
28. 相互推薦を構成する2つの要素 28 28 ユーザu→ ユーザv の Preference Score 行動履歴や属性データなど ユーザに関するデータ Preference Score を 推論する 28 28 ユーザu→ ユーザv の Preference Score ユーザv→ ユーザu の Preference Score 相互推薦の場合 ① ①ユーザそれぞれ単方向の Preference Scoreを推論する 　ここで... 　2つのスコアがあるので 　何かしらの方法で統合して 　推薦を作る必要がある
29. 相互推薦を構成する2つの要素 29 29 ユーザu→ ユーザv の Preference Score 行動履歴や属性データなど ユーザに関するデータ Preference Score を 推論する 29 29 ユーザu→ ユーザv の Preference Score ユーザv→ ユーザu の Preference Score 相互推薦の場合 ① ①ユーザそれぞれ単方向の Preference Scoreを推論する 集約関数 集約関数 ユーザu, ユーザv の Reciprocal Preference Score 集約 関数
30. 相互推薦を構成する2つの要素 30 30 ユーザu→ ユーザv の Preference Score 行動履歴や属性データなど ユーザに関するデータ Preference Score を 推論する 30 30 ユーザu→ ユーザv の Preference Score ユーザv→ ユーザu の Preference Score 相互推薦の場合 ① ①ユーザそれぞれ単方向の Preference Scoreを推論する 集約関数 集約関数 集約 関数 ② 2つのScoreを統合して 双方向のScoreを算出する (手法はScore統合だけではない) ユーザu, ユーザv の Reciprocal Preference Score 集約 関数 ②
31. ✗ 単方向の評価 ①推薦が受 入れられるか? ②ユーザのポジ反応が受 入れられるか？ ✗ 双方性を考慮した評価 ③マッチしたかどうか？ 指標 ✗ Precision at N, Success rate at N, Failure rate at N, F1, DCG at N 　　に　　 を推薦する場合 相互推薦の評価 31 　 　 ① ② 　 　 ③
32. 相互推薦の評価 (indeedの事例) ✗ item-to-user推薦と相互推薦(特に仕事探し)の推薦だと色々違う ✗ プラットフォームで閉じな て、実際に面接などをしてどうだったかが大切 ✗ 結果が出るまでに時間がかかりやすい (す に結果が出ない) ✗ 商品購入 らいなら小さな負担だ ど、仕事の決定は大きな賭 ✗ クリックだ で推薦の良さを測ることができるとは限らない ✗ 定量的な評価に合わせて、定性的な評価も必要 ✗ Eye Tracking ✗ Diary Studies ✗ Usability Studies RecSys2022 HR workshopのkeynoteより https://www.youtube.com/watch?v=XsH2OYNY1sY 32
33. TOPIC① 人気ユーザに偏らないようにしたい 人気ユーザに推薦が集中すると、 ✗ 人気ユーザの負担増加 (全部確認しないとい ないので...) ✗ 人気ユーザを推薦されたユーザは、マッチする可能性が低 なる ✗ 人気じゃないユーザはなかなか推薦されずに、マッチの機会が減る 「ユーザそれぞれにマッチできるキャパシティがあるので、 　推薦される回数を分散させたい」 ( → 公平な推薦については、こちらのブログを 皆が幸せになるマッチングプラットフォーム を目指して。「マッチング理論に基づ 相互推薦システム」 | CyberAgent Developers Blog ) 33
34. TOPIC② 説明をつけるとどうなる？ Explainability (推薦理由の提示など)は推薦分野ではよ 研究されている&有効 性が示されているが、 相互推薦の文脈ではあまり研究がない Providing Explanations for Recommendations in Reciprocal Environments [Kleinerman 2018] ✗ 推薦するときに、双方向にとっての推薦理由の説明(利益)を添える ✗ 説明の手法: 推薦理由となるユーザの属性k個を出す (これは先行研究で有効性が示されている) ✗ 単方向の説明と双方向の説明で比較 ✗ 推薦を受 入れるコストが高いプラットフォームでは、双方の説明をした方が良い ✗ 推薦を受 入れるコストが低いプラットフォームでは、一方的な説明の方が良い 34
35. 協調フィルタリングベースのユーザ推薦 例: ある男性ユーザに女性ユーザを推薦する場合　 35 ユーザ推薦の一例を説明します 男性から女性の 興味スコア算出 女性から男性の 興味スコア算出 集約 関数 双方向の好みを 考慮したスコア ↓ 推薦
36. 例: ある男性ユーザに女性ユーザを推薦する場合　 36 男性から女性の 興味スコア算出 女性から男性の 興味スコア算出 集約 関数 双方向の好みを 考慮したスコア ↓ 推薦 ① 双方向の好みのを考慮してお相手を出したい 男性から女性の好み
37. 例: ある男性ユーザに女性ユーザを推薦する場合　 37 男性から女性の 興味スコア算出 女性から男性の 興味スコア算出 集約 関数 双方向の好みを 考慮したスコア ↓ 推薦 ① 双方向の好みのを考慮してお相手を出したい 男性から女性の好み 女性から男性の好み
38. 例: ある男性ユーザに女性ユーザを推薦する場合　 38 男性から女性の 興味スコア算出 女性から男性の 興味スコア算出 集約 関数 双方向の好みを 考慮したスコア ↓ 推薦 ① 双方向の好みのを考慮してお相手を出したい 男性から女性の好み 女性から男性の好み それぞれの興味スコアを算出して 最終的に集約する
39. 双方向の好みを 考慮したスコア ↓ 推薦 ② 好みのお相手を出せば良い？？？ 39 例: ある男性ユーザに女性ユーザを推薦する場合　 男性から女性の 興味スコア算出 女性から男性の 興味スコア算出 集約関数 公平性の考慮 • 人気のユーザに偏ってしまうことを避けたい • 双方のスコアを集約する際に、ユーザキャパシティを考慮する • AI Labと共同研究中 • https://www.cyberagent.co.jp/news/detail/id=27897 アクティブさの考慮 • 好みのユーザだからといって、アクティブではないユーザが推薦されても、いいかもを見て 「ありがとう/ごめんなさい」をしてもらえないと意味ない • アクティブ度合いによるフィルタ ( 推薦候補の鮮度 ) 地域の考慮 • 好みのユーザだとしても北海道と沖縄では会えない • 近くの相手を推薦するようにする
40. 双方向の好みを 考慮したスコア ↓ 推薦 ② 好みのお相手を出せば良い？？？ 40 例: ある男性ユーザに女性ユーザを推薦する場合　 男性から女性の 興味スコア算出 女性から男性の 興味スコア算出 集約関数 公平性の考慮 • 人気のユーザに偏ってしまうことを避けたい • 双方のスコアを集約する際に、ユーザキャパシティを考慮する • AI Labと共同研究中 • https://www.cyberagent.co.jp/news/detail/id=27897 アクティブさの考慮 • 好みのユーザだからといって、アクティブではないユーザが推薦されても、いいかもを見て 「ありがとう/ごめんなさい」をしてもらえないと意味ない • アクティブ度合いによるフィルタ ( 推薦候補の鮮度 ) 地域の考慮 • 好みのユーザだとしても北海道と沖縄では会えない • 近くの相手を推薦するようにする
41. 双方向の好みを 考慮したスコア ↓ 推薦 ② 好みのお相手を出せば良い？？？ 41 例: ある男性ユーザに女性ユーザを推薦する場合　 男性から女性の 興味スコア算出 女性から男性の 興味スコア算出 集約関数 公平性の考慮 • 人気のユーザに偏ってしまうことを避けたい • 双方のスコアを集約する際に、ユーザキャパシティを考慮する • AI Labと共同研究中 • https://www.cyberagent.co.jp/news/detail/id=27897 アクティブさの考慮 • 好みのユーザだからといって、アクティブではないユーザが推薦されても、いいかもを見て 「ありがとう/ごめんなさい」をしてもらえないと意味ない • アクティブ度合いによるフィルタ ( 推薦候補の鮮度 ) 地域の考慮 • 好みのユーザだとしても北海道と沖縄では会えない • 近くの相手を推薦するようにする
42. 双方向の好みを 考慮したスコア ↓ 推薦 ② 好みのお相手を出せば良い？？？ 42 例: ある男性ユーザに女性ユーザを推薦する場合　 男性から女性の 興味スコア算出 女性から男性の 興味スコア算出 集約関数 公平性の考慮 • 人気のユーザに偏ってしまうことを避けたい • 双方のスコアを集約する際に、ユーザキャパシティを考慮する • AI Labと共同研究中 • https://www.cyberagent.co.jp/news/detail/id=27897 アクティブさの考慮 • 好みのユーザだからといって、アクティブではないユーザが推薦されても、いいかもを見て 「ありがとう/ごめんなさい」をしてもらえないと意味ない • アクティブ度合いによるフィルタ ( 推薦候補の鮮度 ) 地域の考慮 • 好みのユーザだとしても北海道と沖縄では会えない • 近くの相手を推薦するようにする
43. ③ 大規模データの学習のための分散処理 例: ある男性ユーザに女性ユーザを推薦する場合　 43 男性から女性の 興味スコア算出 女性から男性の 興味スコア算出 集約 関数 双方向の好みを 考慮したスコア ↓ 推薦 推薦アルゴリズムの選定 • 大規模な行動ログデータを扱うことになる → 分散処理によって計算コストや実行時間を抑えられるモデルを採用 ( 推薦システムにおいて線形モデルがまだまだ有用な話 | CyberAgent Developers Blog ) 分散処理のためにDataprocの利用 • 実装はPySparkのALS • SparkのためのクラスタはDataprocで用意 以前はオンプレ環境でSparkクラスタを管理していたが 管理の手間を減らすことができた
44. ユーザ推薦で実現したいことは？ ユーザ推薦の施策ではそれぞれで実現したいことが異なるので、 ABテストごとに検証項目に合わせて、OECとガードレール指標を設定する e.g. ✗ た さんマッチしてほしい ✗ → マッチ系の指標 (マッチ平均、マッチ成功率など) ✗ 多 の人がマッチできるようにしたい ✗ → 多様性の指標 (推薦対象者のユニーク数など) ✗ メッセージに繋がるマッチをしてほしい ✗ → メッセージ系の指標 44
45. データの力で 誰かをちょっと幸せにするために 3
46. 3年目機械学習エンジニアのこれまでとこれから 46 高校時代は 数学と人が好きだったので 数学の教師になりたかった テクノロジー使って 教育にアプローチするの 面白そうって思い始めて
47. 3年目機械学習エンジニアのこれまでとこれから 47 大学・大学院 ✗ 学部：情報系 ✗ 研究：自然言語処理 ✗ 大学院：CS専攻 ✗ インターン：NLPなど 高校時代は 数学と人が好きだったので 数学の教師になりたかった 学科の仲間とのチーム開発 で作ったものを使ってもら う楽しさを知る 文生成の研究をしていた
48. 3年目機械学習エンジニアのこれまでとこれから 48 大学・大学院 ✗ 学部：情報系 ✗ 研究：自然言語処理 ✗ 大学院：CS専攻 ✗ インターン：NLPなど エンジニアを志す toCサービスに携わりたい 高校時代は 数学と人が好きだったので 数学の教師になりたかった 学科の仲間とのチーム開発 で作ったものを使ってもら う楽しさを知る 文生成の研究をしていた
49. 3年目機械学習エンジニアのこれまでとこれから 49 大学・大学院 ✗ 学部：情報系 ✗ 研究：自然言語処理 ✗ 大学院：CS専攻 ✗ インターン：NLPなど 1年目 ✗ 全体研修：チーム開発 ✗ ジョブロ → 2サービス関わる ✗ そのまま → タップルの分析 → ABEMAで検索改善 エンジニアを志す toCサービスに携わりたい 高校時代は 数学と人が好きだったので 数学の教師になりたかった 学科の仲間とのチーム開発 で作ったものを使ってもら う楽しさを知る 文生成の研究をしていた NLP多め
50. 3年目機械学習エンジニアのこれまでとこれから 50 大学・大学院 ✗ 学部：情報系 ✗ 研究：自然言語処理 ✗ 大学院：CS専攻 ✗ インターン：NLPなど 1年目 ✗ 全体研修：チーム開発 ✗ ジョブロ → 2サービス関わる ✗ そのまま → タップルの分析 → ABEMAで検索改善 エンジニアを志す toCサービスに携わりたい 高校時代は 数学と人が好きだったので 数学の教師になりたかった 学科の仲間とのチーム開発 で作ったものを使ってもら う楽しさを知る 文生成の研究をしていた NLP多め ✗ 課題発見からユーザに届 るところまで ✗ 2サービスに関わる ✗ 部署の外部向 の冊子の編集 ✗ 社内勉強会 推薦の読み会、分析共有会など
51. 3年目機械学習エンジニアのこれまでとこれから 51 大学・大学院 ✗ 学部：情報系 ✗ 研究：自然言語処理 ✗ 大学院：CS専攻 ✗ インターン：NLPなど 1年目 ✗ 全体研修：チーム開発 ✗ ジョブロ → 2サービス関わる ✗ そのまま → タップルの分析 → ABEMAで検索改善 一連の流れをたくさん経験 課題発見、提案、分析、開発、検証など エンジニアを志す toCサービスに携わりたい 高校時代は 数学と人が好きだったので 数学の教師になりたかった 学科の仲間とのチーム開発 で作ったものを使ってもら う楽しさを知る 文生成の研究をしていた NLP多め
52. 3年目機械学習エンジニアのこれまでとこれから 52 2年目 ✗ 推薦システムへ ✗ マッチング推薦の分 析、開発 ✗ 学生トレーナー ✗ 国際学会参加 大学・大学院 ✗ 学部：情報系 ✗ 研究：自然言語処理 ✗ 大学院：CS専攻 ✗ インターン：NLPなど 1年目 ✗ 全体研修：チーム開発 ✗ ジョブロ → 2サービス関わる ✗ そのまま → タップルの分析 → ABEMAで検索改善 一連の流れをたくさん経験 課題発見、提案、分析、開発、検証など エンジニアを志す toCサービスに携わりたい 高校時代は 数学と人が好きだったので 数学の教師になりたかった 学科の仲間とのチーム開発 で作ったものを使ってもら う楽しさを知る 文生成の研究をしていた RecSys2023 就業型で1ヶ月一緒に 推薦システムを始める NLP多め ✗ 推薦システム アルゴリズム、MLOps、分散処理... ✗ ちょっとずつ教える立場へ ✗ 教えることで学ぶことも多い ✗ 共同研究や社内ゼミに参加 ✗ ブログや登壇するように
53. 3年目機械学習エンジニアのこれまでとこれから 53 2年目 ✗ 推薦システムへ ✗ マッチング推薦の分 析、開発 ✗ 学生トレーナー ✗ 国際学会参加 大学・大学院 ✗ 学部：情報系 ✗ 研究：自然言語処理 ✗ 大学院：CS専攻 ✗ インターン：NLPなど 1年目 ✗ 全体研修：チーム開発 ✗ ジョブロ → 2サービス関わる ✗ そのまま → タップルの分析 → ABEMAで検索改善 一連の流れをたくさん経験 課題発見、提案、分析、開発、検証など エンジニアを志す toCサービスに携わりたい 高校時代は 数学と人が好きだったので 数学の教師になりたかった 学科の仲間とのチーム開発 で作ったものを使ってもら う楽しさを知る 文生成の研究をしていた RecSys2023 就業型で1ヶ月一緒に 推薦システムを始める NLP多め ✗ 推薦システム アルゴリズム、MLOps、分散処理... ✗ ちょっとずつ教える立場へ ✗ 教えることで学ぶことも多い ✗ 共同研究や社内ゼミに参加 ✗ ブログや登壇するように ・強みを作る ・精度と早さを高める
54. 3年目機械学習エンジニアのこれまでとこれから 54 2年目 ✗ 推薦システムへ ✗ マッチング推薦の分 析、開発 ✗ 学生トレーナー ✗ 国際学会参加 大学・大学院 ✗ 学部：情報系 ✗ 研究：自然言語処理 ✗ 大学院：CS専攻 ✗ インターン：NLPなど 1年目 ✗ 全体研修：チーム開発 ✗ ジョブロ → 2サービス関わる ✗ そのまま → タップルの分析 → ABEMAで検索改善 3年目~ ✗ 推薦システム深める ✗ 新卒トレーナー ✗ 新卒DS研修推進 ✗ 定量 x 定性 一連の流れをたくさん経験 課題発見、提案、分析、開発、検証など ・強みを作る ・精度と早さを高める エンジニアを志す toCサービスに携わりたい 高校時代は 数学と人が好きだったので 数学の教師になりたかった 学科の仲間とのチーム開発 で作ったものを使ってもら う楽しさを知る 文生成の研究をしていた RecSys2023 就業型で1ヶ月一緒に NLP以外の強みを！推薦へ NLP多め 他のメンバーと協力 チームでより大きい事業成果へ 講義+議論+実践で業務に活きる研 修作り 技術もPJ推進も学びあり より深いユーザ理解のために
55. 3年目機械学習エンジニアのこれまでとこれから 55 2年目 ✗ 推薦システムへ ✗ マッチング推薦の分 析、開発 ✗ 学生トレーナー ✗ 国際学会参加 大学・大学院 ✗ 学部：情報系 ✗ 研究：自然言語処理 ✗ 大学院：CS専攻 ✗ インターン：NLPなど 1年目 ✗ 全体研修：チーム開発 ✗ ジョブロ → 2サービス関わる ✗ そのまま → タップルの分析 → ABEMAで検索改善 3年目~ ✗ 推薦システム深める ✗ 新卒トレーナー ✗ 新卒DS研修推進 ✗ 定量 x 定性 一連の流れをたくさん経験 課題発見、提案、分析、開発、検証など ・強みを作る ・精度と早さを高める ・個人の力は継続強化 ・「チーム」を意識 エンジニアを志す toCサービスに携わりたい 高校時代は 数学と人が好きだったので 数学の教師になりたかった 学科の仲間とのチーム開発 で作ったものを使ってもら う楽しさを知る 文生成の研究をしていた RecSys2023 就業型で1ヶ月一緒に NLP以外の強みを！推薦へ NLP多め 他のメンバーと協力 チームでより大きい事業成果へ 講義+議論+実践で業務に活きる研 修作り 技術もPJ推進も学びあり より深いユーザ理解のために
56. 56 まとめ ✗ マッチングアプリとデータサイエンス ✗ サイバーエージェントにお るメディア事業部とデータ活用 ✗ マッチングアプリにとって正解は？ ✗ データによって解決したい課題例 ( ユーザ推薦、安心安全(監視)、デートプラン推薦、指標分析、施策評価など ) ✗ 相互推薦システムと活用事例 ✗ item-to-user推薦と相互推薦の違い ( 互いに満足してないといけない, 推薦うまくいくと離脱、離脱すると推薦できない ) ✗ 相互推薦を構成する2つの要素と2つのトピック ( 単方向のPreference推定 + 集約によって双方向のPreference Score算出 ) ✗ 協調フィルタリングベースの推薦アルゴリズムの一例 ✗ データの力で誰かをちょっと幸せにするために ✗ 3年目の機械学習エンジニアのこれまでとこれから ( いろいろ経験->強み作る->チームで成果を最大化 ) ✗ 技術に張りながらもユーザ理解によって顧客体験を変えたい ( まだまだ3年目ですが突き進んでます )
57. Thanks! 57