Recommendation Industry Talks #2ルポ
- 日時：四谷タワーLINE社（リアルのみ）
- 場所：2024年4月11日19時〜
- 登壇：
- LINEの人
- クックパッドの人たち
- タイミーの人
【1】スタンプショップの推薦枠に2-stage制を導入した事例紹介
（資料を公開してないっぽいので、発表内容も厚めに）
- 文鳥「ふ」
- ユーザーごとに「このスタンプに類似するスタンプはこれ！」のレコメンドをしてる
- 2ステージ制=最初はベクトル検索で候補を検索して、次にランカーを使って候補をランキングする
今まで
- LINEは規模が大きく、数億ユーザーに対して数千万のスタンプからレコメンドを計算してる
- 日次で計算し、計算結果をどこかしらに格納して配信してる
- 今まではレコメンドしたスタンプのインプレッションを取れなかったが、一昨年？くらいからそれが取れるようになった（=特徴量に使えるようになったし、モデルの評価時にも使えるようになった）
- 今まではMLPミキサー？とかANNをつかってレコメンドしてた（この辺曖昧）
やったこと＆結果
課題：
- 2ステージ制を導入するに至った背景は不明。たぶん、既存のANNでリトリーバルするモデルに、まだ改善の余地があったとかだと思う
やったこと：
- ランカーを設け、2ステージ製にした
- 〇〇では、クリックは重みを1に、CVは重みを2にした（ここもメモ忘れた）
- レコメンドからの流入なのか、通常検索からの流入なのか？は考慮しないモデルにした（意図的にやらなかったわけではなさそう）
- Spotifyが出してるレポートで、「レコメンドするアイテムの種類の多さ」が、CVに影響を与えることがわかっていた。そのため種類の多さも考慮した（多分https://research.atspotify.com/2020/12/algorithmic-effects-on-the-diversity-of-consumption-on-spotify/ ）
結果：
- オフライン検証においても、ABテストにおいても、本番リリース後においてもすごい良くなった
- ABテストは、アクティブな数千万人を対象に2週間やった
- 本番リリースは、リリース後にも継続してモニタリングするために95%のユーザーにしかリリースしなかった。この95%は毎月シャッフルしている。またこのモニタリングは今後も継続する予定。新しいモデルを作った際、5%：5%：90%にリリースするか？とかは未定。
課題：
- PVとかCV（スタンプの購入）は生のログからいちいち集計しなきゃいけなくて面倒くさかった
やったこと：
- 専用のログテーブルを設けた（トラッキング時から別テーブルにしたのか、既存の生ログテーブルをフィルタ・集約したテーブルを作ったのかは不明）
結果：
- 色々楽だった。オススメだそう
課題：
- Sparkの計算スピードが遅かった
やったこと：
- シャッフル時に遅くなることを特定した
- シャッフルを減らすべく、ブロードキャストジョインにした
結果：
- 早くなった
感想
やはりLINEは規模がデカいから、レコメンドで改善したときのビジネスインパクトもデカい。
そのため5%のユーザーにリリースしないのはすごく大きな意思決定に思う。それで生じる（もしくは損なう）金額より、得られる情報のほうが価値があるという判断なのかと思うが、LINEスタンプの5%ってとんでもないのでは？とも思ったりした。
Spotifyが出した多様性のレポートなどはQ&Aにチラッと話していたが、僕にはめちゃくちゃ貴重な情報だったので助かった。
また多様性に関して「多様性を考えなくて良いなら、極論ただのランキングで十分」ということを言っていて、なるほどと思った。
【2】クックパッドが取り組むレシピレコメンドの面白さと難しさ
発表内容は↓の通り。
Sequential recommendの手法として、スライドでは〈BERT4Rec〉〈SASRec〉〈CORE〉があったが、口頭では〈Transformers4Rec〉なんかも言ってた。
感想
クックパッドは料理を作っていただくことを目的としているが、料理を作るというイベントはECのように明確にイベントを定義しづらいのがネックだそう。似た概念に〈つくれぽ〉機能があるが、これはいちいちレポートを書かなきゃいけない。その手間を惜しまずに投稿してくれるのはコアなユーザーだけ。
個人的な意見だが、〈つくれぽ〉よりもっと手軽に投稿できる何かがあると、分析にも使いやすいのかなとは思った。「このレシピを作るのに何分かかった？」を投稿するやつとか。システム改修が走るからちょっと面倒かもしれないが。
レコメンドするプロダクトの性質を考え、類似した他社製品を参考にするのは流石だと思った。たしかAWSのML Enablement Workshop でも似たようなことをやるセクションがあるし、車輪の再発明をしないためのデファクト的な進め方なのかなと思った。
【3】タイミーにおけるH3を活用したレコメンドの改善事例
発表内容は↓の通り
1回でも働いたことのある人へのレコメンドが今回の発表内容。
感想
質問にて、「H3なんか使わずに、単純に勤務場所の特徴量を入れたら良かったのでは？」と質問されていたが、「既に入れてる。しかし説明変数として現住所が強すぎる」そう。
今回のレコメンドはワーカー目線の評価指標のみで、企業側にメリットになるような指標が無いそう。その課題感は発表者も持ってるそう。この視点は僕にはなかったので、ステークホルダーのメリットの総量を上げるという視点は持ちたいと思った。
N=1とかで見てるわけではないが、カテゴライズ化した全カテゴリのワーカーにおいて数値は良くなったらしい。「N=1で見ると、今回のレコメンドが悪く影響してるユーザーもいるかもしれない」という指摘はなるほどと思った。
全体感想
オンライン勉強会は色々参加していたが、オフライン勉強会はめちゃくちゃ久しぶりだった。機械学習は専門ではないが全然楽しめた。
どの会社もABテスト環境が整ってたり、LINE社、タイミー社はオフラインテストのデータセットもあるようでめちゃくちゃ羨ましかった。この辺は少しずつやるしか無いのかなと思った。
タイミー社は、「オフラインテストだと新モデルは効果なさそうだけど、今後の知見のためにも本番リリースしようぜ」というノリで本番リリースしてみたら、予想に反してスコアが良かったらしい。この企業文化というかチーム文化は本当に羨ましい。
また参加したい。
Discussion