こんにちは。インフラエンジニアの永井(shanagi)です。
今回は、昨年から取り組んでいる機械学習の分野で、自分の作ったモデルをサービスに本番リリースする機会があったので、PoCで終わりがちな機械学習をプロダクト導入にこぎつけるためにどのようなプロセスを歩んだのかとそこで得た自分なりの知見を中心にご紹介できればと思います。
機械学習のプロダクト導入に向けては歩むステップが非常に多く、個々の詳細な内容について細かく書くと非常にボリューミーな内容になってしまうので、詳細は割愛し機会があればまたどこかでご紹介出来ればと思います。
内容は、ざっくり下記2つに絞りました。
- どんな機能をリリースしたのか?
- 導入までの全体アプローチ
ちなみに、なぜインフラ畑の自分が機械学習をやっているのかについては、昨年末に下記ブログにまとめたのでもし興味がある方がいれば読んでみてもらえればと思います。
どんな機能をリリースしたのか?
まずは今回どのような機能をリリースしたのかを紹介します。 ママリはママ達の悩みや疑問を解決するQAプラットフォームなので、毎日ユーザであるママさん達から多くの質問投稿があります。
ママリ内のカテゴリとしては、「妊娠・出産」「育児・グッズ」「お金・保険」などがあり、質問文の内容に合わせて投稿時にユーザに選択してもらっています。 今回は、この質問投稿時のカテゴリ選択において、質問本文の内容から適切なカテゴリを類推してユーザに推薦する「カテゴリ類推」エンジンをリリースしました。
↓質問の本文からカテゴリを類推している様子です！カテゴリを考え中の時にカテゴリ類推のAPIが呼ばれています。
詳しくは、この後の章で触れるのですがこのリリースによって、下記の指標にプラスの影響を出すことが出来ました。
- 回答率の向上
- 質問投稿時のCVRの向上
機械学習の導入は、導入時はマイナス影響なしの状態で入れてそこからモデルアップデートを通して数値を上げていくものという期待値調整をするので、初期モデルである程度プラスの成果が出たのは運がよかった面もあるな思っています。
導入までの全体アプローチ
前提として昨年からコネヒトでは、機械学習を活用したプロダクトの改善を組織として推し進めていくという取り組みを行っています。組織から機械学習導入を期待されているというのは、説明コストが大幅に下がること(PoCまでのハードルが下がる)を意味しており今回のカテゴリ類推導入に向けても大きな後ろ盾になりました。
全体のステップ
今回カテゴリ類推を本番リリースするにあたり大まかに下記のステップをたどりました。
①仮説作りのためのデータ分析 ↓ ②仮説を裏付けるためのデータ分析 ↓ ③モデル作成 ↓ ④オフライン検証と品質チェック ↓ ⑤デモ作成(AWSとAndroidアプリ) ↓ ⑥A/Bテスト(PoC)と効果測定 ↓ ⑦本リリース
それぞれどんなことをしたのかとそこで得た知見ベースで振り返っていこうと思います。
進める上で気をつけた点として、ある程度の精度はオフライン検証で出来るが、実際のユーザの行動は出してみないとわからない部分が大きいのでできるだけ早くA/Bテストまで持っていくことを意識しました。
①仮説作りのためのデータ分析
機械学習導入を期待されているといっても闇雲に機械学習を入れればいいというわけではもちろんありません。 サービスが抱える課題を解くためのツールとして機械学習が適切であればそれを使います。
その課題を可視化して理解し、仮説(機械学習で解決すべき課題)に落とし込むのにはデータ分析が必要です。 解くべき課題に関しては、主にサービスのKPIやそれを細分化したものの達成を設定することが多いと思います。今回のカテゴリ類推においても、当時のサービスKPIの一つになっていた回答率を分析することからはじめました。
データ分析を進める上での工夫として、属人化しがちなデータ分析の知見を気軽に共有するために、GitHubのissueでデータ分析のログを残すようにしています。 仮説を裏付ける際や簡単なモデルの試作品を作る際に使うjupyter notebookのソースも同じリポジトリで管理するようにしており、後からでも過去のプロジェクトを気軽に参照出来るようにしています。
可視化したデータは下記のようなダッシュボードにまとめておくことで、以後のA/Bテスト時の結果計測にも使えるような形にしておきました。
②仮説を裏付けるためのデータ分析
①のデータ分析の結果、質問に対して適切なカテゴリが選択されると回答がつく確率が上がりそうなことがわかりました。 このカテゴリ選択を適切にすることで回答率を上げられそうという仮説を裏付けるためのデータ分析に入ります。 同時に、どのようにして投稿のカテゴリを適切に設定するかを検討しました。その中で、今回採用する機械学習を使った質問投稿時の「カテゴリ類推」を導入すれば、ユーザが入力する投稿内容を元に適切なカテゴリを設定出来てUXも上がりそうという仮説が最終的に出来上がりました。
この仮説を裏付けるために更にカテゴリと回答に絞った分析を行い下記のような事実が浮かび上がってきました。(一部抜粋)
これらは質問文の内容から適切なカテゴリが入ることで回答を増やしてくれそうという仮説の裏付けになりました。
- 特定のカテゴリに偏りがある（質問内容とは関係なくカテゴリを選択している質問が多くある）
- ユーザは好きだったり興味のあるカテゴリを回遊しながら回答してくれていることが多そう
③モデル作成
続いて、ローカルのjupyter notebookで「カテゴリ類推」のモデル作成を行いました。 ざっくりメモですが、どんなことをやったか羅列しておきます。
- 学習データの作成
- 過去の膨大な質問データを使えるので加工等は不要
- 1ヶ月分のデータを取ってpandasで分布みたりしてデータ件数を揃える
- 質問文を機械学習で使える形に前処理する
- 小文字化とテキストから不要な文字を削除や置換
- neologdnを使った正規化とUnicode正規化
- MeCabを使ったトークナイズ(どの品詞を使うと一番精度高いか色々と試したり)
- 学習データとテストデータの分割
- scikit-learnのtrain_test_splitを使う
- 最初層化抽出してなくて、層化抽出することで大きく精度が伸びたのはなつかしい
- 特徴抽出
- 文字列をベクトルに変換する手法
- Bag of WordsとTF-IDFを試す
- 最終的に、TF-IDF(min_df,max_dfでストップワード兼ねる)を使った
- アルゴリズム選定
- scikit-learnを使っていたので、SVM,ロジスティック回帰,ランダムフォレストを試す
- GridSearchしながら同じ条件でどのアルゴリズム一番精度が出るかを繰り返した
- 恥ずかしながら当時はニューラルネットワークはまだ手をつけてなかったので試してない(今後検討)
手元である程度の精度が出るモデルが出来たのでオフライン検証と品質チェックに進みます。
④オフライン検証と品質チェック
オフライン検証として、学習データに含まれないN日分のデータからの正答率を出して指標としました。
オフライン検証の結果、ある程度精度の出る(ユーザに違和感なく提供出来そうな)モデルが出来ました。 ただ、機械的に正答率が高くても、ユーザにとって不快な推薦をしてしまうとサービス価値の毀損につながります。ママリはコミュニティサービスなので、せっかく質問しようとしたユーザにカテゴリの推薦で不快な思いをさせてしまっては機会損失につながります。
ここの部分の不安を解消するために、CSチームと連携して、オフライン検証の結果間違ったデータに関して品質チェックを行ってもらいました。 結果、ユーザに致命的に不快感を与えるような予測はないという裏付けをもらってから次のステップに進みました。
⑤デモ作成(AWSとAndroidアプリ)
ディレクターや社内で説明するのに動いているものを見せるのが一番説得力が増すと考えて、Androidエンジニアに協力してもらいデモ用のAPIを叩くデモアプリを作ってもらいました。 今回このデモの果たしてくれた役割は大きく、やはり動くものをサクッと作るのは大事だなと思いました。
⑥A/Bテスト(PoC)と効果測定
デモやデータ分析と品質チェックの結果をディレクターに説明して、A/BテストへのGoサインを無事こぎつけました。
A/Bテストを行う上では、当たり前ですがトラッキングするためのダッシュボードを事前に作っておくことが重要でした。 今回は①で作ったダッシュボード+mixpanelでアプリver毎のイベントをトラッキングすることで効果測定を行いました。 結果指標として掲げていた項目で明らかな優位が見られました！
- 回答率の向上
- 質問投稿時のCVRの向上
裏話でもないですが、ユーザに直接届くものを作ってリリースする機会はこれまであまりなかったので、結果を毎時ドキドキ見ていたのを思い出します。 興奮してこんなツイートもしてました。
初めて自分の作った機械学習のモデルがローンチされて、ユーザの反応が毎時気になってどきどき。インフラでいう負荷対策した時のキャンペーンスタート時みたいな感覚で、これがサービス開発かという実感を得ている。
— shnagai (@shnagai) 2020年2月27日
⑦本リリース
効果測定の結果、明らかな優位が見られたので簡単なレポートをまとめ関係者に共有し本リリースが決まりました。 ここでのレポーティングは事前にデータ分析する時に効果測定時のレポートを意識しながら可視化したのが役立ちサクッと作りました。
その後、A/Bテスト時は実現までのスピードを重視し手動作成したモデルを使っていたので、前処理とモデル作成のバッチ処理を作成し自動化しました。バッチはAWS上でECS+Fargateベースで動かしています。
最後にどんなアーキテクチャで動いているのかを載せておきます。
今回は技術的な内容には踏み込まずにデータ分析から機械学習のプロダクト導入に至るまでの道筋についてご紹介しました。 コネヒトでは、これからも今回の事例のようにテクノロジーの力でプロダクトを伸ばしていってくれる仲間を絶賛募集しています。ご興味ある方は是非一度お話だけでもさせてもらえるとうれしいです。
