この記事は every Tech Blog Advent Calendar 2023 の 20 日目です。
こんにちは。 開発本部のデータ&AIチームでデータサイエンティストをしている古濵です。
今回は、最近私が取り組んでいるDELISH KITCHENのレコメンドの立ち上げとこれからに向けてのお話をしようと思います。
はじめに
DELISH KITCHENでは、プロの管理栄養士が作成したレシピコンテンツを提供しています。 DELISH KITCHENをローンチした初期はコンテンツ数が多くなかったこともあり、サーバー側の簡易な集計ロジックをもとにユーザーにレシピを提供していました。
しかし、ローンチから8年経過した現在、レシピ数は5万レシピを超え、現状のロジックに任せるだけではユーザー自らが好みのレシピを見つけることも難しくなってきました。
そのような背景から、ユーザーの嗜好に寄り添ったアプリのパーソナライズが課題となってきています。 データ&AIチームとして、パーソナライズに向けたロジック（ルールベース、機械学習等）の開発を推進すべく動き始めています。
レコメンドはじめました
アプリのパーソナライズ手段の一つとして、レシピのレコメンド開発に着手しています。
既存のレコメンドの仕組みがなかったわけではないのですが、数年間ロジックの更新がされておらず、また過去にどのような経緯で企画及び開発されていたのか不明瞭な状態となっていました。 レコメンド開発における社内のノウハウも多くはなく、ほとんど0→1フェーズの立ち上げに近い状態で始まりました。
既存のアプリケーションにレコメンドのような新たな仕組みを導入する際、まずは理想の状態を整理することが重要だと考えています。 特に整理が必要だったのは、ロジックをDELISH KITCHENのサーバーから分離するという点です。
理想としては、データ&AIチームが継続的にロジックの改善に集中でき、サーバーエンジニアがロジック改善に伴う修正を対応せずとも運用できる状態を目指しています。 それに加えて、A/Bテストの設定や機械学習に伴う学習と推論の実装などもやや密結合となっており、コードの管理や開発体験面でも分離の必要性を感じています。
そこで、レコメンドの立ち上げにおいて、以下のようなことを意識して取り組みました。
PDCAの結果をドキュメントとして残し、社内のノウハウをためる
レコメンドの立ち上げから継続的に改善される状態を目指している現状において、仕組みづくりが重要だと考えています。 その手段としてドキュメント化は必須だと考えており、社内のノウハウをためるという意味でも大事なことだと思います。
立ち上げ始めの今から、どのような仕組みを入れるかの企画を立て、レコメンドのためのアルゴリズムを実装し、A/Bテストで評価、分析をするPDCAを回しています。 この結果をドキュメントとして誰でも見れる形でまとめ、過去どんな改善に取り組んだかのノウハウを残し、いつでも振り返りができる状態にしています。
開発スピードを優先し、事例を作る
企画からレコメンド開発、A/Bテストの評価と事後分析を全て一人のデータサイエンティストが担うにはAgility観点で懸念があります。 レコメンド開発は将来的に企画職、そして会社を巻き込んで取り組んでいく必要があると考えており、そのためにはまず事例作りから始めようと考えました。
まず、データ&AIチームでDELISH KITCHEN内のどの部分にパーソナライズを導入できそうか議論し、工数や導入のしやすさなどを見積もりました。 そこから、既存の仕組みを再利用でき、かつルールベースの簡単なロジックから始められる枠でレコメンド開発を進めました。
レコメンドの開発では、ph1はルールベースによるレコメンド、ph2は行列分解など機械学習によるレコメンドといったように、段階的に改善と効果検証を進め、仮説ベースに試行錯誤を繰り返しています。
ポジティブな結果を出す
前節とも重複する部分はありますが、パーソナライズのような仕組みを普及させていくためにも、初速で結果を出すことは大事だと考えています。
以下の画像はレコメンドのA/Bテストの結果です。 旧ロジック（control）と新ロジック（test）で評価指標を比較し、新ロジックでポジティブな結果を出すことができました。 もちろん、すべてのA/Bテストでポジティブな結果を出せたわけではありませんが、レコメンド開発を推進する走り出しとしては良い結果になったかなと思います。
これからに向けて
レシピレコメンドはあくまで一つの事例であり、今後もパーソナライズの仕組みをDELISH KITCHENに導入していく予定です。
そこで、「理想の状態を整理する」節でも述べた部分と関連して、導入を進めていく上で以下のような整理をしています。
ロジック開発に関して
As-Is
ロジック開発は弊社のデータ基盤であるDatabricksを用いて実装できます。 DatabricksにはMLに必要なモデル、特徴量、実験の管理などが MLflow や Feature Store の機能を用いて実現可能です。
対して、ロジックを開発する上でのコードの管理やオフライン評価の検証などが、各データサイエンティスト依存となっており、体系的な整理がされていません。
To-Be
今後は、我々が実現したいML基盤の実現に向けたコーディングルールを決め、共通のオフライン評価基盤を作るなどの改善を進めていきます。
効果検証に関して
As-Is
弊社にはA/Bテスト基盤があり、アプリ内に新しく導入したレコメンドなどの仕組みの効果検証が可能になっています。 旧ロジック（control）と新ロジック（test）として評価指標を比較し、新ロジックの介入効果を計測することで、新ロジックの性能を評価できます。
対して、ロジックの実装とA/Bテスト基盤としての実装が一部癒着しており、人力の設定が必要となっています。 そのため、効果検証自体は可能ですが、ロジック開発に工数がかかったり、実装者のヒューマンエラーが発生するリスクを孕んでいます。
To-Be
今後は、A/Bテストの設定の自動化やロジックの実装とA/Bテストの機能の分離することで、効果検証の効率化を図っていきます。
サービングに関して
As-Is
Databricks内でバッチ推論し、推論結果をデータストアであるRedis（ElastiCache for Redis）にデプロイすることでサーバー側と連携できます。 サーバー側はクライアント側のリクエストに対して、Redisを読み込んでレシピを返すことができます。
対して、サービング方式がRedisを用いたバッチ推論であるため、ロジックの変更でデータ形式が変化した場合には、サーバー側の改修が必要となってしまいます。 また、リアルタイム推論を実現したいビジネス要件が出た場合に対応できません。
To-Be
今後は、サーバー側との連携をRedisを介してのデータの受け渡しだけではなく、リクエストに対して推論結果を返すようなML APIを加えていきたいと考えています。 これにより、新たなロジックの追加や改修もAPIレベルで行えるため、サーバーとロジックを繋ぐ柔軟性と開発効率の向上を期待しています。 また、リアルタイム推論の要件にも対応可能となり、より多くのビジネス要件に対応できるようになると考えています。
その開発を進めるMLエンジニアのポジションを、社内のデータサイエンティストとデータエンジニア共同で開発予定です。
まとめ
本ブログでは、DELISH KITCHENにおけるのレシピレコメンドの立ち上げとこれからに向けての取り組みを紹介しました。 ご紹介したとおり、理想を実現するための課題は多くありますが、データ&AIチームとしてパーソナライズの仕組みをDELISH KITCHENに導入していくことで、ユーザーの嗜好に寄り添ったアプリを目指していきたいと考えています。
社内でもAI/MLプロダクトや生成AIの活用の兆しが出てきているなと感じており、既存のアプリのさらなる成長を目指し、挑戦的な取り組みへのスタートが切りだせてるのではないかと思います。
データ&AIチームでは一緒に働く仲間を募集しています！ 動画メディアでAI/MLプロダクトの推進にご興味のある方はぜひ、以下のURLからご応募ください。
