※ こちらはミツモアAdvent Calendar 2021の7日目の記事です。
こんにちはミツモアで分析リーダーをしている古田（@crazysrot）です。 今回は、ミツモアのマッチングアルゴリズムに機械学習モデルを導入した話を紹介いたします。
ミツモアは「リモートワークが増えてエアコンを綺麗にしたい」「引っ越しで出た不用品を回収してもらいたい」といった生活のあらゆるシーンであなたにぴったりの専門家を無料で探せるサービスですので、ぜひ気軽に使ってみてください！
背景
ミツモアでは、見積もりの自動応募というものを行っています。
自動応募とは、「エアコンを綺麗にしたい依頼者様」と、「エアコンを綺麗にできる事業者様(プロ)」のマッチングをシステムが自動的に見積もりを作成し応募を行うことです。依頼者様はより早く正確な見積もりが届き、プロは応募通知が届き、それぞれの負担を極限まで減らした仕組み
現在は約200のサービスにて自動応募を実施しています。
「システムが自動的に見積もりを作成し応募を行う」アルゴリズムを、依頼数/提供サービス数の増加してきたことから従来での手法では限界があることや、データの増加により機械学習モデルで個別最適化を測ることが可能になってきたこのタイミングでの導入を致しました。 GoogleのRule of Machine Learningの Rule #3: Choose machine learning over a complex heuristic. がまさに今回該当しています。
ロジックベースアルゴリズムについて
※従来の自動応募アルゴリズムのことをロジックベースアルゴリズムと呼ぶことにします
ロジックベースアルゴリズムは、一般化線形回帰をベースに作られたものがあり、それをサービスの特性に合わせて改修されたアルゴリズムが10種類弱ほど存在していました。今まではそれらを次のステップで改善が行われていました
- 仮説だし(依頼者様との距離が遠いと、プロは契約を避けがち 等)
- 仮説をもとにそれっぽいアルゴリズムに変更する
- 過去の依頼を数件ランダムサンプリングして、期待したに対してアルゴリズムを適用し期待通りの応募がつくか確認
- 適用サービスを決めてABテストを実施
それぞれのステップでまぁまぁな負担がかかる上に、あまり勝率も高くなかった(一般的なABテストと同じ程度の勝率)ようでした。
現状では、サンプリングも十分ではなく、仮説を反映する際も真にロジカルにチューニングされた数式に落とし込むことも難しく、実際に触れてみた感想も課題がたくさんある印象を持ちました。
マッチングアルゴリズム改善プロジェクトについて
今回は、MVP（Minimum Viable Product）開発を参考に、まずはパッとモデルを作ってスモールスタートし、効果が見込めることを確認してからモデル適用対象サービスの拡大・アルゴリズムの改善をする方針でした。 分析のPJチームは藤井さん(@yuki_meetsmore_87910)と二人でタッグを組んで毎朝1〜2時間程度Meetingしつつ開発をすすめました。 モデルの報告は石川さん(CEO),柄澤さん(CTO, @fmy)のお二人がメインでした。お二人からもモデル作成のヒントをたくさんもらえ、とても仕事しやすかったです。
PJの目的
それぞれ、次のような世界を達成するために目標を掲げています
目的①GMVを最大化する
弊社の売り上げも増加し、プロの売り上げも増加し、依頼者の満足度も向上を目指しWinWinWinになる
目的②ミツモアで活躍できるプロを増やす
より多くのプロに活躍していただくことで、プラットフォームの成長のための土台を作る。依頼数が増えても対応できるプロが少なければ依頼者にぴったりの見積もりを付けれなくなるためです。
目的③マッチングアルゴリズムのブラックボックスをなくす
プロへ、「もっとこうしたら応募がつきやすくなりますよ！！！」 といったアドバイスを行いたい。のようなビジネス側の要求に応える。 (でも、今よりホワイトにするのは無理です、ごめんなさい。精度とブラックボックスがトレードオフなのは自然の摂理なので、、、) *ブラックボックスの可視化部分はまだ未開発です
現状のチームでこれを+弊社諸々のデータ施策全て解決するのは難しいので、これからも取り組んでいく仲間を募集しています。
今回作成したモデルについての基本的情報
- いわゆる推薦システムの枠組みと捉えています
- 過去依頼とそれについた応募を使用
- 目的変数：X日以内支払率
- 説明変数：プロ、依頼者、依頼内容の大きく三つから編成
- 目的①GMVを最大化する への対応
- 期待GMV = 予測支払率 * 初期見積り
- の値を使用することで表現し、基本的には期待GMVの高いプロ順に応募をつける
モデル適用のイメージ(カメラマン カテゴリーの例)
機械学習モデルの作成
スピーディな開発は行うにせよ、一般的なモデル開発プロセスCRISP-DMになるべく従って進めるようなるべく意識して行いました。今回は、MVP開発の手法を意識した取り組みだったため、テクい話はほとんどありませんでした。そのため、今回は通常の分析の流れに沿ってどのようなことをしたのかを簡単に書きます。
ロジックベースアルゴリズムのリスペクト(Business Understanding & Data Under Standing)
まず、ロジックベースアルゴリズムでは何が重要視されているかを確認しました 成果が出ていそうなものはなるべく取り入れました
経営陣 + カテコンチームへのヒアリング(Business Understanding & Data Under Standing)
※カテコン = カテゴリコンサル = 各サービス(カテゴリ)の依頼者様やプロと常に直接向き合っている弊社の精鋭
私と藤井さんはミツモアにJOINしたばかりのタイミングだったため、ビジネス側の知見はほぼありませんでした。 そのため精鋭たちから、依頼者はどのような応募を選択しがちなのか、プロはどのような応募に対して積極的に取り組むのか、過去にどんなクレームが入ったのか、などなどの知見をスプレッドシートで管理された変数候補リストで収集しました。
現在は2つ目のモデル作成(売上規模の大きい特徴的なサービスに特化したモデル)に取り掛かっていますが、その際にもヒアリングの時間を十分行い、今も継続的に情報を仕入れています。 このヒアリングでは、十分すぎるほどの意見をいただけたのですが、MVP開発だったため、優先度高かつ低コストの要素しかモデルへ反映していません。
説明変数の収集〜特徴量加工(Data Preparation)
弊社ではBigQueryにDWHを構築しており、そこからほとんど取得することができました。
モデル作成(Data Preparation & Modeling)
- 構築環境
- colaboratory → GCP VertexAI
- 最初はどのサービスでエンドポイントを作成するか決まっていなかったため、colab上で簡易EDA+modelingを実施しました。
- 最終的にはVertex AI でエンドポイントを作成することにしたので、GCP Vertex AI Workbench に開発環境を移行しました。
- アルゴリズム
- XGBoostを採用。サービスの特性上、強調フィルタリングやMatrix Factorizationのようなアルゴリズムには向いていなかったため、GBDTを採用しました。
- VertexAIでエンドポイントを立てることにしたので、結果的にこの選択がベストでした
精度検証(Evaluation)
通常の精度指標AUC, MRR等を用いた検証に加えて次の検証を行いました
- 過去依頼に対して機械学習モデルを適用した場合、目的②ミツモアで活躍できるプロを増やす は達成できそうなのか？
- 特定のプロ応募が集まりすぎないか、より多くのプロへ応募を届けれるのか
- SHAPで変数が実際にどのようにモデルで使用されているかの可視化
APIの作成(Deployment)
Deployment周りは詳しくは @yumit414 さんの方で紹介します 今回はVertexAI でエンドポイントの作成をしました。 簡単に作成でき、XGBoostで作成されたお試しモデルを素早くリリースできる環境は今回の取り組みにとてもフィットしていました。
本番環境で推論に使用する一部の説明変数を事前作成(Deployment)
- 説明変数の作成
- 計算コストを減らすために、事前に準備できる一部の説明変数に関してはでBigQueryで作成し、バッチ更新する設定にしました
- node.js上での開発
- こちらも @yumit414 さんの方で紹介します
その後のアップデートで発見した面白いこと
先ほども述べた、現在作成中の2つ目のモデルの中であった発見の1つを紹介します
過去の負例の情報を特徴量として使用
@yuki_meetsmore_87910 さんのアイデアで、面白そうだなと思って投入したら精度が向上しました。正例の傾向と負例の傾向は別のベクトルで表現されたということですね。今考えると確かにハマりそうだと思うのですが、あまり聞かない発想だったのでSHAPを見て上位の方で出力されているのを見たときは興奮しました。
どのサービスからリリースするか検討した話
ミツモアでは、自動応募を導入しているサービスが約200あります。中には、実績依頼数の少ないサービス、季節変動の大きなサービス、実績成約数の少ないサービスなどもあり、作成したモデルが本当に実運用に耐えうるのか不安な点もあります。今回は、モデルは全サービスを用いて学習したものを1つだけ作成したので、適用可/不可サービスの振り分けを行う必要がありました。その振り分け方法は個人的に良い方法だったと思っているので紹介します。
サービス別の学習データ数が少なくなるほどAUCの分散が大きくなる→過学習が疑われるため、その分散が激しくなってくる部分や、AUCの低下などが見られるようになってくる閾値を見定めてました。他にも、正例数や正例率でも比較を実施した上で最終的に決めました。
まとめ
前職は分析ベンダーでクライアントは大企業だったため、分析は失敗のないように念入りにEDAするなど、とてもセンシティブに作っていましたが、今回はスピード重視でダメだったら素早く修正する方針だったため、重要・簡易の2軸で最低限のチェックに留めました。ここはベンチャーと大企業の特徴の違いがよく現れており、どちらもそれぞれメリデメがあるなと感じました。
私はPJ開始時点でまだ入社1ヶ月ちょっとでまだ右も左もわかっていなかったため、入社直後には次のことを実施しました。これをやっていたので、スムーズに機械学習に取り組めて個人的には本当に良かったと思っています。
- 入社してから各部門からくる集計タスクを優先的に消化し、データの知見や肌感をそこで得る
- 社内Wiki & slackを見まくる
- 社内のステークホルダーや、ビジネスに詳しい人が誰なのかを把握する
新たにMVPの方法で機械学習を導入する方の参考にちょっとでもなればと思います。
現在、事業拡大を進めておりエンジニア・デザイナー・PdMを積極採用中です。ぜひWantedlyのリンクからカジュアル面談をしましょう。
