昨日 6日目:How We Built: An Early-Stage Recommender System 紹介したレコメンドシステムに取り入れた機械学習モデルのお話.どんなモデルを選択したのか,またその理由などに焦点を当てた記事.

Why did we need a model?

2020年3月頃にAWS Personalizeを使ってた際には,階層型LSTMのモデルを採用していたけど,このサービスを利用するのに2つ欠点があった.

  1. 予測のランキングのみが提供されてスコアがなかった.また「For Your Usual」を選択しないと常に同じ「For Your Usual」がレコメンドされて陳腐化してしまう
  2. ランキングとフィルターを使ったレコメンドリストの生成に着目していたが,これを実現するにはより大きな予測リストが必要だった

Outsourcing the model denies the team that opportunity for growth and learning.

チームが成長していくためには自分達で試行錯誤しながらモデルを改善していくことは知見も貯まるし,良いというのは同意するところ.よりコンテンツを正確にかつパーソナライズしていくためにもこれは必要なことだと感じる.専任のMLエンジニアが居なかったり,時間が十分に割けない状況とかであればマネージドサービスによるモデルで一定の成果が出ればOKというパターンはあるけど,成果が出ることがわかれば,より自分達で違うモデルを作って比較したりと改善したくなるので,その場合は成長するためにも自分達で管理していくのは良さげだな.

Considerations for Designing a Model

Making it Uniquely Peloton

ユーザーのニーズ(嗜好性や能力)とコンテンツの多様性を上手くマッチする形でレコメンドしていく必要があるのはやはり大変で,汎用モデルだと対応するのが難しかったりしそうだな.

Batch Compute, Cache, and Retrieve

オフラインのバッチレコメンデーションで実現している.オンライン推論するとなると,予測のレイテンシーだったり,候補選択だったりランキング部分が難易度高いし,非同期的にならざるおえないかなと思うので,ユーザーがアクセスした瞬間提供できるのはオフラインのメリットかな.

Untitled

Platform Maturity

行動ベースのデータを利用したくても,データソースがバラバラだったり,データ基盤が十分に整っていないとできないので,ここが制限されるのは勿体無いので機械学習やっていく以前にこの辺は最低限整えていないとあかんなという印象.機械学習はデータが全てと言ってもいいと思っているので,きちんと使いやすい形で整備するのが第一だな.

Speed of Development vs. Model Performance

自前のモデルを構築していく場合には,現実的なスピード感で開発していく必要があるのでそう言ったことも考えたり,乗り換えるにはベースラインとしてのモデル(今回の場合はAWS Personalizeによる階層型LSTM)と比較して同等以上というのは最低ライン.

Communicating with Product

機械学習の価値を社内の人に理解して貰うのは大事で,組織を教育していくのは必要だなと感じる.ここではPdMが素早くキャッチアップして上手くコミュニケーションを図っていったみたいだけど,この辺は機械学習の価値を理解してそれを正しく周りに伝えられる人は必要だなと思った.

個人的には,PdMはMLを活用した施策以外にも考えることが山ほどあると思うので,MLの良し悪しは知っていて欲しいと思うもののフラットな目線で居て欲しいなという気持ちがある.(MLを活用すること前提でそれをメインに考えるPdM(最近巷で言われているML PdMというのかな?)であれば話は違うかなと思うけど…)