マッチング理論に基づく推薦とそれを支えるMLOps開発

1. マッチング理論に基づく推薦 とそれを支えるMLOps開発 Matsuzuki Daisuke Tomita Yoji
2. 松月 大輔(まつづき だいすけ) 入社：2020年新卒 職種：MLエンジニア 所属：メディア事業部/技術本部 /MDTS/DSC 専門領域：Computer Vision 趣味：スポーツ全般，麻雀，F1観戦 冨田 燿志(とみた ようじ) 入社：2020年新卒 職種：リサーチサイエンティスト 所属：AI事業本部/AI Lab/Econ SI 専門領域：マーケットデザイン, マッチン グ理論, ゲーム理論 趣味：サッカー観戦, 漫画・小説
3. マッチング理論に基づく推薦
4. タップルにおけるレコメンド • タップルでマッチングするまで ◦ おすすめされたユーザーのプロフィールを確認 ◦ いいかも（右フリック）かイマイチ（左フリック）か選択 ◦ 送ったいいかもにありがとうをされるか、 相手から届いたいいかもにありがとうをするとマッチング ◦ マッチングが成立するとメッセージ交換が可能に • 適切におすすめ（レコメンド）することが重要
5. 相互推薦システム（RRS） • 相互推薦システム（Reciprocal Recommender Systems; RRS） ◦ ユーザーに他のユーザーをレコメンドするシステム ◦ 例：求人・就職サービス（求職者/企業）、マッチングアプリ（男性/女性）、など • 通常のRRSの流れ ◦ 行動履歴から男性ユーザーから女性ユーザーへの興味スコアと、 女性ユーザーから男性ユーザーへの興味スコアを、 それぞれ通常の推薦の手法（行列分解など）によって算出 ◦ 集約関数で相互興味スコアを計算 ▪ 平均、幾何平均、調和平均など ◦ 相互興味スコア順に推薦
6. RRSの課題 • 被推薦機会の集中・不平等 ◦ 一部の人気ユーザーは、多くの人から興味スコアが高くなる。 → 集約された相互興味スコアも人気ユーザーは高くなりやすい。 → 一部のユーザーは何度も数多く推薦されて推薦機会が集中し、 　 他のユーザーは推薦される機会の少なくなる不平等な状況に陥りやすい。
7. RRSとマッチング理論 • RRSに重要な2つの観点 ◦ 相互の興味の一致 ▪ ユーザーAがユーザーBに強く興味を持っていても、 ユーザーBがユーザーAに興味がないなら推薦効果はない。 ◦ マッチングキャパシティ ▪ 人気ユーザーAを何度も推薦してユーザー Aが数多くのいいかもを集めても、 ユーザーAが実際にメッセージやり取りや会うことのできる人数は時間的・物理的に限られる。 • マッチング理論 ◦ 人と人、あるいは人とモノの適切な割り当てを、 それぞれの好みと制約（キャパシティ）から決める仕組みを探る経済学・CSの一分野。 • マッチング理論を活用したRRSにより、推薦機会の集中の緩和が期待できる。
8. マッチング理論に基づく推薦 • MTRS（Matching Theory-based Recommeder Systems） ◦ 男性ユーザーから女性ユーザー、女性ユーザーから男性ユーザへの興味スコアを、 通常の推薦の手法（行列分解など）により算出するのは同様。 ◦ 興味スコアと制約をもとに、マッチング理論のアルゴリズムにより 適切なマッチングを計算し、その結果に基づいて推薦を行う。 ◦ マッチングアルゴリズムはさまざま ▪ Gale-Shapley (1962), Choo-Siow (2006), など • プロジェクト ◦ Chen-Hsieh-Lin (2021) を参考に、 Choo-Siow (2006)に基づくRRS の導入を目指している。
9. MLOpsについて
10. タップルのレコメンドシステムにおけるMLOps - Feature - batch学習 - FeatureStore - Ranker - モデルの学習 - 推論APIの提供 - Candidate Generator Development Developer DSC AILab tapple Intern
11. VertexAI - 2021年5月にリリース - Pipeline - workflowを定義 - FeatureStore - 特徴量ストア - WorkBench(Notebook) - Notebookで簡単にPipelineの設計が可能 VertexAIに関してはサイバーエージェントcam所属の原和希氏による紹介資料が分かり やすい https://speakerdeck.com/cyberagentdevelopers/vertexaidegou-zhu-sitamlopsji-p an-falsequ-rizu-mi
12. 構築したシステムの例
13. Vertex Pipelines - Kubeflow Pipelinesをフルマネージドで実行可能 - GCP製品と親和性が高い - BigQureyやCloudStorageとのやり取りが多い - Artifactなど中間生成物も全てGCPで完結できる - Custom JobsはPipeline実行時にインスタンスが立ち上 がる - 運用コストの削減 - 開発者はComponentの繋げ方を定義するPipelineを設 計する - 専門性の横断が可能 - 責任範囲の曖昧さを解消することが重要 BQから学習データを ロードする モデルを学習する
14. 構築したPipelineの例 - データセットの準備 - FeatureStore - CloudStorage - BigQuery - モデルの学習 - metricsの設定 - モデル精度のモニタリング - ModelRegistry - モデルの保存庫 - モデルのデプロイ - リリースするモデルの書き換え
15. チュートリアルの設計 - 様々な所属のdeveloperが開発 - 他所属の方や、インターン生など - プロジェクトに入る人が最初に実行するチュートリアルを設計 - Pipelineの設計からデプロイまで - 依存サービスが多くなる - Sparkを使用したい - DataProcを使用 - GCSの扱い方 - Pipelineに関するデータ - 中間生成物 Pipelineの設計のプロセスと、運用ルールをチュートリアルで学ぶ
16. VertexPipelines導入に関して • 簡単に機械学習ワークフローを 設計可能 • レビュワーの負担が小さい • 共通の処理がある場合の汎用 化も容易 • GCP製品との親和性が高い メリット • 依存システムが多くなる場合の コード管理 ◦ DataProc(spark) ◦ カスタムエンドポイントの 設計 • testが難しい • componentエラー時の対応 課題