マッチングアプリにおける推薦システム

Slide 1

Slide 1 text

マッチングアプリにおける推薦システム 2023.02.16 橋爪友莉子 1 メディアサービスにおけるデータ・AIの活用事例 #2

Slide 2

Slide 2 text

自己紹介 2 橋爪友莉子 ( ゆっこ ) ● 21年度入社 ( 新卒2年目 ) ● ML Engineer @MDTS-DSC ( メディアのデータ横軸組織 ) ○ タップルの推薦システムの分析と開発 ○ タップルのその他の分析もろもろ ● 興味 ○ 推薦システム、NLP、分散処理、MLOps、面白いって思ったら基本気になるので、たくさん首を突っ込みます ○ ユーザ理解、ユーザがちょっと幸せになること ● 趣味 ○ カメラ、邦ロック、走る Twitter: @runnlp

Slide 3

Slide 3 text

話すこと ● マッチングアプリとデータ活用 ○ プロダクトの説明: タップル ○ マッチングアプリにとって正解は？ ○ (データによって) 解決したい課題例 ● 相互推薦システム ○ item-to-user推薦と相互推薦の違い ○ 相互推薦を構成する2つの要素 ○ 相互推薦の評価、その他のトピック ● タップルでの活用事例 ○ 協調フィルタリングベースの推薦アルゴリズムの一例 ○ システム構成 3

Slide 4

Slide 4 text

話すこと今日のゴール 4 マッチングアプリの ML/DSの人のイメージ沸いたなんか面白そうちょっと話聞いてみたい相互推薦の研究がわかった

Slide 5

Slide 5 text

マッチングアプリとデータ活用 5

Slide 6

Slide 6 text

マッチングアプリ: タップルタップルは共通の趣味や行きたいところから恋の相手を見つけることができるマッチングアプリです。 6 https://tapple.me/

Slide 7

Slide 7 text

マッチングアプリにとって正解は何？ ● 課金して貰えばいい？ ● ユーザ体験が良いと継続してくれる？ ● 使い続けてもらいたい？ ● マッチがたくさんあればいい？ ● 安心安全は絶対に必要だよね？ ● ゴールは、デートして付き合うこと！(さらには結婚とか) 7

Slide 8

Slide 8 text

解決したい課題の例 ● 誰に誰を推薦する？→ユーザ推薦 ● 安心安全に使ってほしい→ 監視フィルタ ● デートプランカードを使ってもらうために推薦したい→ 起動時推薦 ● どの指標を伸ばすとサービスのグロースに繋がる？→ 指標の分析 ● 施策の効果はどう？→ ABテストなどによる検証 8

Slide 9

Slide 9 text

解決したい課題の例 ● 誰に誰を推薦する？→ユーザ推薦 ● 安心安全に使ってほしい→ 監視フィルタ ● デートプランカードを使ってもらうために推薦したい→ 起動時推薦 ● どの指標を伸ばすとサービスのグロースに繋がる？→ 指標の分析 ● 施策の効果はどう？→ ABテストなどによる検証 9 参考資料 ● マッチングサービスの画像審査における機械学習の応用 / Application of machine learning in image examination - Speaker Deck ● AI/ Data Technology Map

Slide 10

Slide 10 text

解決したい課題の例 ● 誰に誰を推薦する？→ユーザ推薦 ● 安心安全に使ってほしい→ 監視フィルタ ● デートプランカードを使ってもらうために推薦したい→ 起動時推薦 ● どの指標を伸ばすとサービスのグロースに繋がる？→ 指標の分析 ● 施策の効果はどう？→ ABテストなどによる検証 10 デートプランカードが導入されたときに設定率を上げるために起動時推薦を実施

Slide 11

Slide 11 text

解決したい課題の例 ● 誰に誰を推薦する？→ユーザ推薦 ● 安心安全に使ってほしい→ 監視フィルタ ● デートプランカードを使ってもらうために推薦したい→ 起動時推薦 ● どの指標を伸ばすとサービスのグロースに繋がる？→ 指標の分析 ● 施策の効果はどう？→ ABテストなどによる検証 11 参考資料 (ちょっと古いけど) マッチングサービスにおけるKPIの話

Slide 12

Slide 12 text

解決したい課題の例 ● 誰に誰を推薦する？→ユーザ推薦 ● 安心安全に使ってほしい→ 監視フィルタ ● デートプランカードを使ってもらうために推薦したい→ 起動時推薦 ● どの指標を伸ばすとサービスのグロースに繋がる？→ 指標の分析 ● 施策の効果はどう？→ ABテストなどによる検証 12 正しく効果を測るための工夫もろもろ例えば、マッチングの推薦のABテストでは、いいかもする人とありがとうする人の両側に人がいるので、単純な分割ではだめ (STUVAの問題)

Slide 13

Slide 13 text

解決したい課題の例 ● 誰に誰を推薦する？→ユーザ推薦 ● 安心安全に使ってほしい→ 監視フィルタ ● デートプランカードを使ってもらうために推薦したい→ 起動時推薦 ● どの指標を伸ばすとサービスのグロースに繋がる？→ 指標の分析 ● 施策の効果はどう？→ ABテストなどによる検証 13 マッチ成立の流れいいかも→ありがとう (=マッチ) → メッセージができるようになる https://tapple.me/ 累計会員数1700万人が利用しているので全員見るのは難しい　　　　　↓ それぞれに合ったお相手を推薦したい今日話すこと

Slide 14

Slide 14 text

相互推薦システム 14

Slide 15

Slide 15 text

マッチングアプリにおけるユーザ推薦とは男性には女性を、女性には男性を推薦する (※アプリによっては同性同士のマッチもある) 15 ユーザにマッチしそうなユーザを互いに推薦する =相互推薦双方のユーザがマッチングの推薦に満足する必要がある

Slide 16

Slide 16 text

相互推薦が必要となるサービス ● マッチングアプリ (Online Dating) ● 仕事探し ● オンライン学習 ● SNS 16

Slide 17

Slide 17 text

item-to-user推薦と相互推薦の違い相互推薦 ● ユーザuにユーザvを推薦する ● ユーザu,vがどちらも推薦を受け入れた場合に他のユーザにユーザu,vを推薦できなくなる ● アプリケーションによっては、推薦がうまくいくと、ユーザはそのシステムを使用する必要がなくなり、離脱してしまう ● ユーザu,vが互いに満足しないと、推薦成功とはならない 17 ACM SIGIR 2020 Tutorial - Reciprocal Recommendation: matching users w… item-to-user推薦 ● ユーザuに対して、アイテムiを推薦する ● 複数のユーザにアイテムを推薦することができる ● 良い推薦できたからといって、ユーザがシステムから離脱するわけではない ● 推薦成功は推薦を受けユーザの満足によって決まる

Slide 18

Slide 18 text

item-to-user推薦の場合相互推薦を構成する2つの要素 18 18 ユーザu→ アイテムi の Preference Score 行動履歴や属性データなどユーザに関するデータそれぞれのアイテムに対する Preference Score を推論するそれぞれのアイテムに対するPreference Scoreがわかればソートして、候補生成なりリランキングなりに使えるコンテンツベースや協調フィルタリングなどのアルゴリズムによって推薦リスト作成

Slide 19

Slide 19 text

item-to-user推薦の場合相互推薦を構成する2つの要素 19 19 ユーザu→ アイテムi の Preference Score 行動履歴や属性データなどユーザに関するデータそれぞれのアイテムに対する Preference Score を推論するそれぞれのアイテムに対するPreference Scoreがわかればソートして、候補生成なりリランキングなりに使えるコンテンツベースや協調フィルタリングなどのアルゴリズムによって推薦リスト作成ここで... 相互推薦の場合単方向のScoreだけでは両ユーザを満足させる推薦が実現できない

Slide 20

Slide 20 text

相互推薦の場合相互推薦を構成する2つの要素 20 20 ユーザu→ ユーザv の Preference Score 行動履歴や属性データなどユーザに関するデータ Preference Score を推論する 20 20 ユーザu→ ユーザv の Preference Score ユーザv→ ユーザu の Preference Score

Slide 21

Slide 21 text

相互推薦を構成する2つの要素 21 21 ユーザu→ ユーザv の Preference Score 行動履歴や属性データなどユーザに関するデータ Preference Score を推論する 21 21 ユーザu→ ユーザv の Preference Score ユーザv→ ユーザu の Preference Score 相互推薦の場合 ① ①ユーザそれぞれ単方向の Preference Scoreを推論する

Slide 22

Slide 22 text

相互推薦を構成する2つの要素 22 22 ユーザu→ ユーザv の Preference Score 行動履歴や属性データなどユーザに関するデータ Preference Score を推論する 22 22 ユーザu→ ユーザv の Preference Score ユーザv→ ユーザu の Preference Score 相互推薦の場合 ① 　ここで... 　2つのスコアがあるので　何かしらの方法で統合して　推薦を作る必要がある ①ユーザそれぞれ単方向の Preference Scoreを推論する

Slide 23

Slide 23 text

相互推薦を構成する2つの要素 23 23 ユーザu→ ユーザv の Preference Score 行動履歴や属性データなどユーザに関するデータ Preference Score を推論する 23 23 ユーザu→ ユーザv の Preference Score ユーザv→ ユーザu の Preference Score 相互推薦の場合 ① ①ユーザそれぞれ単方向の Preference Scoreを推論する相互推薦の場合集約関数ユーザu, ユーザv の Reciprocal Preference Score 相互推薦の場合集約関数ユーザu, ユーザv の Reciprocal Preference Score

Slide 24

Slide 24 text

相互推薦を構成する2つの要素 24 24 ユーザu→ ユーザv の Preference Score 行動履歴や属性データなどユーザに関するデータ Preference Score を推論する 24 24 ユーザu→ ユーザv の Preference Score ユーザv→ ユーザu の Preference Score 相互推薦の場合 ① ①ユーザそれぞれ単方向の Preference Scoreを推論する相互推薦の場合集約関数ユーザu, ユーザv の Reciprocal Preference Score 相互推薦の場合集約関数ユーザu, ユーザv の Reciprocal Preference Score 集約関数 ② ② 2つのScoreを統合して双方向のScoreを算出する (手法はScore統合だけではない)

Slide 25

Slide 25 text

相互推薦を構成する要素① それぞれのPreference Scoreの推論 25 25 ユーザu→ ユーザv の Preference Score 行動履歴や属性データなどユーザに関するデータ Preference Score を推論する 25 25 ユーザu→ ユーザv の Preference Score ユーザv→ ユーザu の Preference Score ① ①ユーザそれぞれ単方向の Preference Scoreを推論する集約関数ユーザu, ユーザv の Reciprocal Preference Score 集約関数ユーザu, ユーザv の Reciprocal Preference Score 集約関数 ②

Slide 26

Slide 26 text

相互推薦を構成する要素① それぞれのPreference Scoreの推論手法 ● RECON: A reciprocal recommender for online dating ● Reciprocal recommendation system for online dating (RCF) ● Latent Factor Models and Aggregation Operators for Collaborative Filtering in Reciprocal Recommender Systems (LFRR) ● Hybrid Reciprocal Recommender Systems: Integrating Item-to-User Principles in Reciprocal Recommendation 26 コンテンツベース協調フィルタリング Hybrid

Slide 27

Slide 27 text

相互推薦を構成する要素① それぞれのPreference Scoreの推論 RECON: A reciprocal recommender for online dating [Pizzato 2010] ● 相互推薦のために、単方向のPreference Scoreを計算して、最終的に集約してReciprocal Preference Scoreを出すという構造を最初に導入した論文 ( 現在の相互推薦もだいたいこの構造 ) ● Preference Scoreの算出方法は、コンテンツベース ○ ユーザのプロフィール情報を利用：属性情報とフリーテキスト ○ ユーザの過去にいいかもデータ(厳密にはメッセ依頼用の短いメッセによるコンタクトしたかどうかデータ)を利用して、ユーザが好む属性を見つけて、それに近い属性のユーザを出す ● 集約関数は、調和平均 27 コンテンツベース

Slide 28

Slide 28 text

相互推薦を構成する要素① それぞれのPreference Scoreの推論 CF Reciprocal recommendation system for online dating (RCF) [Xia 2015] ● Preference Scoreの推論をメモリベースの協調フィルタリングベースの手法 ● コンテンツベースの手法(RECON)よりも精度高い ● ただ大規模データでは、計算・時間的なコストがかかる ● 集約関数は、調和平均 Latent Factor Models and Aggregation Operators for Collaborative Filtering in Reciprocal Recommender Systems (LFRR) [Neve 2019] ● Preference Scoreの推論に行列分解を用いる手法 ● RCFと性能は同等だが、推論の計算時間がRCFよりはるかに優れている ● 集約関数は、いくつか試している 28 協調フィルタリング

Slide 29

Slide 29 text

相互推薦を構成する要素① それぞれのPreference Scoreの推論 HRRS Hybrid Reciprocal Recommender Systems: Integrating Item-to-User Principles in Reciprocal Recommendation [Neve 2020] ● item-to-userのScoreとReciprocal Scoreをそれぞれ計算して集約する手法 ● 集約関数は、加重平均 ● オフライン評価で、コンテンツベース・協調フィルタリングベースよりも優 29 Hybrid

Slide 30

Slide 30 text

相互推薦を構成する要素② 集約関数 30 30 ユーザu→ ユーザv の Preference Score 行動履歴や属性データなどユーザに関するデータ Preference Score を推論する 30 30 ユーザu→ ユーザv の Preference Score ユーザv→ ユーザu の Preference Score ① 集約関数ユーザu, ユーザv の Reciprocal Preference Score 集約関数ユーザu, ユーザv の Reciprocal Preference Score 集約関数 ② ② 2つのScoreを統合して双方向のScoreを算出する

Slide 31

Slide 31 text

相互推薦を構成する要素② 集約関数双方性は相互推薦の最も複雑なところ。一般的なアプローチは相互のPreference Scoreを集計計算すること。(他にもある) 手法 ● aggregation of preferences a. 相加平均 (Arithmetic mean) b. 相乗平均 (Geometric mean) c. 調和平均 (Harmonic Mean) ■ RCFなどLFRR以前はこれ d. 交差非平均 (cross-ratio uninorm) 31 a b c d ACM SIGIR 2020 Tutorial - Reciprocal Recommendation: matching users w… ←[Neve 2019]での比較

Slide 32

Slide 32 text

相互推薦を構成する要素② 集約関数双方性は相互推薦の最も複雑なところ。一般的なアプローチは相互のPreference Scoreを集計計算すること。(他にもある) 手法と文献例 ● matrix multiplication ○ It's a Match! Reciprocal Recommender System for Graduating Students and Jobs [Javobsen 2019] ● weighted mean ○ Providing explanations for recommendations in reciprocal environments [Kleinerman 2018] ● recommendation rankings ○ scoreではなくて、推薦リストの順位を統合する手法 32 ACM SIGIR 2020 Tutorial - Reciprocal Recommendation: matching users w…

Slide 33

Slide 33 text

● 単方向の評価 ○ ①推薦が受け入れられるか? ○ ②ユーザのポジ反応が受け入れられるか？ ● 双方性を考慮した評価 ○ ③マッチしたかどうか？指標 ● Precision at N ● Success rate at N ● Failure rate at N ● F1 ● DCG at N 　　に　　を推薦する場合相互推薦の評価 33 　　 ① ② 　　 ③

Slide 34

Slide 34 text

相互推薦の評価 (indeedの事例) ● item-to-user推薦と相互推薦(特に仕事探し)の推薦だと色々違う ○ プラットフォームで閉じなくて、実際に面接などをしてどうだったかが大切 ○ 結果が出るまでに時間がかかりやすい (すぐに結果が出ない) ○ 商品購入くらいなら小さな負担だけど、仕事の決定は大きな賭け ○ クリックだけで推薦の良さを測ることができるとは限らない ● 定量的な評価に合わせて、定性的な評価も必要 ○ Eye Tracking ○ Diary Studies ○ Usability Studies RecSys2022 HR workshopのkeynoteより https://www.youtube.com/watch?v=XsH2OYNY1sY 34

Slide 35

Slide 35 text

相互推薦のTOPIC① Popularity Bias, fairness 人気ユーザに推薦が集中すると、 ● 人気ユーザの負担増加 (全部確認しないといけないので...) ● 人気ユーザを推薦されたユーザは、マッチする可能性が低くなる ● 人気じゃないユーザはなかなか推薦されずに、マッチの機会が減るユーザそれぞれにマッチできるキャパシティがあるので、推薦される回数を分散させたい ( → 公平性については、こちらのブログを皆が幸せになるマッチングプラットフォームを目指して。「マッチング理論に基づく相互推薦システム」 | CyberAgent Developers Blog ) 35

Slide 36

Slide 36 text

相互推薦のTOPIC② Explainability Explainability (推薦理由の提示など)は推薦分野ではよく研究されている&有効性が示されているが、相互推薦の文脈ではあまり研究がない Providing Explanations for Recommendations in Reciprocal Environments [Kleinerman 2018] ● 推薦するときに、双方向にとっての推薦理由の説明(利益)を添える ● 説明の手法: 推薦理由となるユーザの属性k個を出す (これは先行研究で有効性が示されている) ● 単方向の説明と双方向の説明で比較 ○ 推薦を受け入れるコストが高いプラットフォームでは、双方の説明をした方が良い ○ 推薦を受け入れるコストが低いプラットフォームでは、一方的な説明の方が良い 36

Slide 37

Slide 37 text

相互推薦のTOPIC③ image ImRec: Learning Reciprocal Preferences Using Images [Neve 2020] ● Siamese networkで単方向スコア算出 + 集約 ● RECON(テキストデータ) vs ImRec(画像)だと、画像の方が良い ● コールドスタートにおいて、LFRR(協調フィルタリングよりも優) ● 計算コストはかなりかかる Photos Are All You Need for Reciprocal Recommendation in Online Dating [Neve 2021] ● Siamese network + LSTM ● likeした画像とdislikeした画像データを利用 ● オフライン評価でLFRR(協調フィルタリングベースの手法より優) ● 計算コストはかなりかかる 37

Slide 38

Slide 38 text

タップルでの活用事例 38 ユーザ推薦の一例を説明します

Slide 39

Slide 39 text

協調フィルタリングベースのユーザ推薦例: ある男性ユーザに女性ユーザを推薦する場合　 39 ユーザ推薦の一例を説明します男性から女性の興味スコア算出女性から男性の興味スコア算出集約関数双方向の好みを考慮したスコア ↓ 推薦

Slide 40

Slide 40 text

① 双方向の好みのを考慮してお相手を出したい 40 例: ある男性ユーザに女性ユーザを推薦する場合　男性から女性の興味スコア算出女性から男性の興味スコア算出集約関数双方向の好みを考慮したスコア ↓ 推薦男性から女性の好み

Slide 41

Slide 41 text

① 双方向の好みのを考慮してお相手を出したい 41 例: ある男性ユーザに女性ユーザを推薦する場合　男性から女性の興味スコア算出女性から男性の興味スコア算出集約関数双方向の好みを考慮したスコア ↓ 推薦男性から女性の好み女性から男性の好み

Slide 42

Slide 42 text

① 双方向の好みのを考慮してお相手を出したい 42 例: ある男性ユーザに女性ユーザを推薦する場合　男性から女性の興味スコア算出女性から男性の興味スコア算出集約関数双方向の好みを考慮したスコア ↓ 推薦男性から女性の好みそれぞれの興味スコアを算出して最終的に集約する女性から男性の好み

Slide 43

Slide 43 text

② 好みのお相手を出せば良い？？？ 43 例: ある男性ユーザに女性ユーザを推薦する場合　男性から女性の興味スコア算出女性から男性の興味スコア算出集約関数双方向の好みを考慮したスコア ↓ 推薦公平性の考慮 ● 人気のユーザに偏ってしまうことを避けたい ● 双方のスコアを集約する際に、ユーザキャパシティを考慮する ● AI Labと共同研究中 ● https://www.cyberagent.co.jp/news/detail/id=27897 アクティブさの考慮 ● 好みのユーザだからといって、アクティブではないユーザが推薦されても、いいかもを見て「ありがとう/ごめんなさい」をしてもらえないと意味ない ● アクティブ度合いによるフィルタ ( 推薦候補の鮮度 ) 地域の考慮 ● 好みのユーザだとしても北海道と沖縄では会えない ● 近くの相手を推薦するようにする

Slide 44

Slide 44 text

② 好みのお相手を出せば良い？？？ 44 例: ある男性ユーザに女性ユーザを推薦する場合　男性から女性の興味スコア算出女性から男性の興味スコア算出集約関数双方向の好みを考慮したスコア ↓ 推薦公平性の考慮 ● 人気のユーザに偏ってしまうことを避けたい ● 双方のスコアを集約する際に、ユーザキャパシティを考慮する ● AI Labと共同研究中 ● https://www.cyberagent.co.jp/news/detail/id=27897 アクティブさの考慮 ● 好みのユーザだからといって、アクティブではないユーザが推薦されても、いいかもを見て「ありがとう/ごめんなさい」をしてもらえないと意味ない ● アクティブ度合いによるフィルタ ( 推薦候補の鮮度 ) 地域の考慮 ● 好みのユーザだとしても北海道と沖縄では会えない ● 近くの相手を推薦するようにする

Slide 45

Slide 45 text

② 好みのお相手を出せば良い？？？ 45 例: ある男性ユーザに女性ユーザを推薦する場合　男性から女性の興味スコア算出女性から男性の興味スコア算出集約関数双方向の好みを考慮したスコア ↓ 推薦公平性の考慮 ● 人気のユーザに偏ってしまうことを避けたい ● 双方のスコアを集約する際に、ユーザキャパシティを考慮する ● AI Labと共同研究中 ● https://www.cyberagent.co.jp/news/detail/id=27897 アクティブさの考慮 ● 好みのユーザだからといって、アクティブではないユーザが推薦されても、いいかもを見て「ありがとう/ごめんなさい」をしてもらえないと意味ない ● アクティブ度合いによるフィルタ ( 推薦候補の鮮度 ) 地域の考慮 ● 好みのユーザだとしても北海道と沖縄では会えない ● 近くの相手を推薦するようにする

Slide 46

Slide 46 text

③ 大規模データの学習のための分散処理 46 例: ある男性ユーザに女性ユーザを推薦する場合　男性から女性の興味スコア算出女性から男性の興味スコア算出集約関数双方向の好みを考慮したスコア ↓ 推薦推薦アルゴリズムの選定 ● 大規模な行動ログデータを扱うことになる → 分散処理によって計算コストや実行時間を抑えられるモデルを採用 ( 推薦システムにおいて線形モデルがまだまだ有用な話 | CyberAgent Developers Blog ) 分散処理のためにDataprocの利用 ● 実装はPySparkのALS ● SparkのためのクラスタはDataprocで用意以前はオンプレ環境でSparkクラスタを管理していたが管理の手間を減らすことができた

Slide 47

Slide 47 text

ユーザ推薦で実現したいことは？ユーザ推薦の施策ではそれぞれで実現したいことが異なるので、 ABテストごとに検証項目に合わせて、OECとガードレール指標を設定する e.g. ● たくさんマッチしてほしい ○ → マッチ系の指標 (マッチ平均、マッチ成功率など) ● 多くの人がマッチできるようにしたい ○ → 多様性の指標 (推薦対象者のユニーク数など) ● メッセージに繋がるマッチをしてほしい ○ → メッセージ系の指標 47

Slide 48

Slide 48 text

協調フィルタリングベースのユーザ推薦のシステム構成 ● オンプレの推論サーバー + Vertex AI Pipelines (+ Dataproc)を利用 48 オンライン処理オフライン処理去年半分移行したので若干いびつな構成だけど最適な状態を探りつつ運用中

Slide 49

Slide 49 text

協調フィルタリングベースのユーザ推薦のシステム構成 49 モデルの事前学習 (GCP) ● vertex AI pipelinesでバッチ処理のパイプラインを作成 ● 分散処理はDataproc ● バッチ処理だけ、去年オンプレから移行オフライン処理 ● オンプレの推論サーバー + Vertex AI Pipelines (+ Dataproc)を利用

Slide 50

Slide 50 text

協調フィルタリングベースのユーザ推薦のシステム構成 ● オンプレの推論サーバー + Vertex AI Pipelines (+ Dataproc)を利用 50 Vertex AI Pipelines ● Kubeﬂow Pipelinesをフルマネージドで実行可能 ● 実装や実行などがシンプルなので、インターン生もキャッチアップしやすい → 1ヶ月インターンのインターンで分析、実装、ABテストをできる ● 実験管理で、Vertex AI Experiments利用できる ( → 過去資料: マッチング理論に基づく推薦とそれを支えるMLOps開発 ) オフライン処理

Slide 51

Slide 51 text

協調フィルタリングベースのユーザ推薦のシステム構成 ● オンプレの推論サーバー + Vertex AI Pipelines (+ Dataproc)を利用 51 Dataproc ● Sparkなどのクラスタを実行するためのフルマネージドサービス ● MFの学習で分散処理をするためにSparkを利用 ● 以前はオンプレのクラスタを運用してたが、移行で、クラスタ管理しなくて良くなったオフライン処理

Slide 52

Slide 52 text

協調フィルタリングベースのユーザ推薦のシステム構成 ● オンプレの推論サーバー + Vertex AI Pipelines (+ Dataproc)を利用 52 フィルタ + 候補生成 + ランキング ● DSCの持つオンプレのk8s上の推薦基盤システムを利用 ● 事前学習モデルを利用して、推論 ● 事前の行動履歴がないユーザは、直近の行動ログを利用してベクトル生成 ● 長く使われているシステム→ 現在モデルストアをアップデート中󰝋 オンライン処理

Slide 53

Slide 53 text

研究とサービス改善タップル事例 53 ① https://www.cyberagent.co.jp/news/detail/id=27897 ② https://developers.cyberagent.co.jp/blog/archives/39706/ ③ https://www.cyberagent.co.jp/news/detail/id=28322

Slide 54

Slide 54 text

まとめ 54 ● マッチングアプリとデータ活用 ○ マッチングアプリにとって正解は？ ( デートして付き合ってもらうこと ) ○ (データによって) 解決したい課題例 ( ユーザ推薦、安心安全(監視)、デートプラン推薦、指標分析、施策評価など ) ● 相互推薦システム ○ item-to-user推薦と相互推薦の違い ( 互いに満足してないといけない, 推薦うまくいくと離脱、離脱すると推薦できない ) ○ 相互推薦を構成する2つの要素 ( 単方向のPreference推定 + 集約によって双方向のPreference Score算出 ) ○ 相互推薦の評価、その他のトピック ( popularity bias, fairness, Explainability, image ) ● タップルでの活用事例 ○ 協調フィルタリングベースの推薦アルゴリズムの一例 ( バッチ処理で単方向スコアをMFで学習+オンラインで推論 ) ○ システム構成 ( Vertex AIやDataprocなどを利用 )

Slide 55

Slide 55 text

\ ありがとうございました！/ 私もまだまだ推薦システムの勉強中なので、精進します✊ なにかございましたらこのあとの座談会やDMなどでお気軽にお願いします〜 55