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

松月 大輔(まつづき だいすけ) 入社：2020年新卒 職種：MLエンジニア 所属：メディア事業部/技術本部 /MDTS/DSC 専門領域：Computer Vision 趣味：スポーツ全般，麻雀，F1観戦 冨田 燿志(とみた ようじ) 入社：2020年新卒 職種：リサーチサイエンティスト 所属：AI事業本部/AI Lab/Econ SI 専門領域：マーケットデザイン, マッチン グ理論, ゲーム理論 趣味：サッカー観戦, 漫画・小説

マッチング理論に基づく推薦

タップルにおけるレコメンド ● タップルでマッチングするまで ○ おすすめされたユーザーのプロフィールを確認 ○ いいかも（右フリック）かイマイチ（左フリック）か選択 ○ 送ったいいかもにありがとうをされるか、 相手から届いたいいかもにありがとうをするとマッチング ○ マッチングが成立するとメッセージ交換が可能に ● 適切におすすめ（レコメンド）することが重要

相互推薦システム（RRS） ● 相互推薦システム（Reciprocal Recommender Systems; RRS） ○ ユーザーに他のユーザーをレコメンドするシステム ○ 例：求人・就職サービス（求職者/企業）、マッチングアプリ（男性/女性）、など ● 通常のRRSの流れ ○ 行動履歴から男性ユーザーから女性ユーザーへの興味スコアと、 女性ユーザーから男性ユーザーへの興味スコアを、 それぞれ通常の推薦の手法（行列分解など）によって算出 ○ 集約関数で相互興味スコアを計算 ■ 平均、幾何平均、調和平均など ○ 相互興味スコア順に推薦

RRSの課題 ● 被推薦機会の集中・不平等 ○ 一部の人気ユーザーは、多くの人から興味スコアが高くなる。 → 集約された相互興味スコアも人気ユーザーは高くなりやすい。 → 一部のユーザーは何度も数多く推薦されて推薦機会が集中し、 　 他のユーザーは推薦される機会の少なくなる不平等な状況に陥りやすい。

RRSとマッチング理論 ● RRSに重要な2つの観点 ○ 相互の興味の一致 ■ ユーザーAがユーザーBに強く興味を持っていても、 ユーザーBがユーザーAに興味がないなら推薦効果はない。 ○ マッチングキャパシティ ■ 人気ユーザーAを何度も推薦してユーザー Aが数多くのいいかもを集めても、 ユーザーAが実際にメッセージやり取りや会うことのできる人数は時間的・物理的に限られる。 ● マッチング理論 ○ 人と人、あるいは人とモノの適切な割り当てを、 それぞれの好みと制約（キャパシティ）から決める仕組みを探る経済学・CSの一分野。 ● マッチング理論を活用したRRSにより、推薦機会の集中の緩和が期待できる。

マッチング理論に基づく推薦 ● MTRS（Matching Theory-based Recommeder Systems） ○ 男性ユーザーから女性ユーザー、女性ユーザーから男性ユーザへの興味スコアを、 通常の推薦の手法（行列分解など）により算出するのは同様。 ○ 興味スコアと制約をもとに、マッチング理論のアルゴリズムにより 適切なマッチングを計算し、その結果に基づいて推薦を行う。 ○ マッチングアルゴリズムはさまざま ■ Gale-Shapley (1962), Choo-Siow (2006), など ● プロジェクト ○ Chen-Hsieh-Lin (2021) を参考に、 Choo-Siow (2006)に基づくRRS の導入を目指している。

MLOpsについて

タップルのレコメンドシステムにおけるMLOps - Feature - batch学習 - FeatureStore - Ranker - モデルの学習 - 推論APIの提供 - Candidate Generator Development Developer DSC AILab tapple Intern

VertexAI - 2021年5月にリリース - Pipeline - workflowを定義 - FeatureStore - 特徴量ストア - WorkBench(Notebook) - Notebookで簡単にPipelineの設計が可能 VertexAIに関してはサイバーエージェントcam所属の原和希氏による紹介資料が分かり やすい https://speakerdeck.com/cyberagentdevelopers/vertexaidegou-zhu-sitamlopsji-p an-falsequ-rizu-mi

構築したシステムの例

Vertex Pipelines - Kubeflow Pipelinesをフルマネージドで実行可能 - GCP製品と親和性が高い - BigQureyやCloudStorageとのやり取りが多い - Artifactなど中間生成物も全てGCPで完結できる - Custom JobsはPipeline実行時にインスタンスが立ち上 がる - 運用コストの削減 - 開発者はComponentの繋げ方を定義するPipelineを設 計する - 専門性の横断が可能 - 責任範囲の曖昧さを解消することが重要 BQから学習データを ロードする モデルを学習する

構築したPipelineの例 - データセットの準備 - FeatureStore - CloudStorage - BigQuery - モデルの学習 - metricsの設定 - モデル精度のモニタリング - ModelRegistry - モデルの保存庫 - モデルのデプロイ - リリースするモデルの書き換え

チュートリアルの設計 - 様々な所属のdeveloperが開発 - 他所属の方や、インターン生など - プロジェクトに入る人が最初に実行するチュートリアルを設計 - Pipelineの設計からデプロイまで - 依存サービスが多くなる - Sparkを使用したい - DataProcを使用 - GCSの扱い方 - Pipelineに関するデータ - 中間生成物 Pipelineの設計のプロセスと、運用ルールをチュートリアルで学ぶ

VertexPipelines導入に関して ● 簡単に機械学習ワークフローを 設計可能 ● レビュワーの負担が小さい ● 共通の処理がある場合の汎用 化も容易 ● GCP製品との親和性が高い メリット ● 依存システムが多くなる場合の コード管理 ○ DataProc(spark) ○ カスタムエンドポイントの 設計 ● testが難しい ● componentエラー時の対応 課題