wantedly/machine-learning-round-table

[2023/07/26]推薦・機械学習勉強会

Opened this issue · 4 comments

Why

推薦・機械学習勉強会は、推薦や機械学習、その周辺技術を通じてサービスを改善することにモチベーションのある人達の集まりです。ニュースやブログから論文まで、気になったものについてお互い共有しましょう!

発信のため、ここは public にしてあります。外部からの参加をご希望の方は樋口(https://twitter.com/zerebom_3) まで DM を送るか、Wantedly Visit の募集(https://www.wantedly.com/projects/391912) よりご連絡ください!

What

Wantedly では隔週水曜日に

  • 推薦の評価指標について議論したい
  • 〇〇っていうライブラリ / フレームワークを導入してみたい
  • 他社の基盤事例をみんなにシェアして自社の基盤開発に活かしたい
  • もっと推薦を良くするためにどんなものが必要か議論したい

といった話をする「推薦・機械学習勉強会」を開催しています。
この ISSUE はその会で話すネタを共有するための場所です。

話したいことがある人はここにコメントしましょう!
会の間に話した内容もここにメモしましょう!

prev: #203

MIPS推定量の論文: Off-Policy Evaluation for Large Action Spaces via Embeddings

  • オンライン環境で稼働中の意思決定システム(ex. 推薦システム) logging policy $\pi_0$ のログを使って、 開発中のtarget policy $\pi$ のオンライン性能を推定する Off-Policy Evaluation(OPE)に関する論文。(先々週の勉強会に参加させていただいた際に、登壇者の斉藤さんが紹介されていたので興味を持って読んでみました!)

image

  • 人気なOPE推定量である IPS推定量は、以下の common support assumption を満たす場合に 真の性能に対して不偏になる:

$$ \pi(a|x) > 0 → \pi_{0}(a|x) > 0, \forall a \in A, x \in X $$

  • ここで、$a$ はaction(ex. 推薦アイテムの選択肢), $x$ は context (ex. ユーザの特徴量)
  • (なるほど...!この仮定は、決定論的な推薦モデルよりも確率論的な推薦モデルの方が遥かに満たしやすい:thinking:)

  • でも大規模行動空間であるほどcommon support assumption が成立しづらくなり、IPS推定量の真の性能に対するBiasとVarianceがどんどん増えていく...!-> これは、logged dataset $D$ に(i.e. $\pi_0$に) サポートされていないactionの情報が含まれなくなる事に起因する。
  • なので本論文では、IPS推定量のaction $a$ を action embedding(i.e. action の特徴量的な認識) $e$ で置き換えた Marginalized IPS(MIPS)推定量を提案している。

image

  • MIPS推定量は、以下の "Common Embedding Support Assumption" を満たす場合に不偏になる。

$$ p(e|x, \pi) > 0 → p(e|x, \pi_{0}) > 0, \forall e \in E, x \in X $$

  • 大規模行動空間において common support assumption は厳しいけど、common embedding support assumption の方が成立させやすいので、MIPS推定量は有効.
  • やっぱり common embedding support assumption も確率論的な推薦モデルの方が遥かに満たしやすいよなぁ...。OPEの観点では決定論的な推薦モデルはご法度というか、かなり扱いづらそう...。:thinking:

  • MIPS推定量が不偏になる条件としてもう一つ "No Direct Effect Assumption" を満たす必要もある: $a \perp r | x, e$
  • ただ論文内では、あえてno direct effect assumptionを破るようにすることで、biasは増えるけどvarianceを減らせる、という戦略を提案していた。

オフライン環境で算出可能なmetricsを使ってオンライン性能を予測しようという論文: Predicting Online Performance of News Recommender Systems Through Richer Evaluation Metrics

  • この論文では、accuracy metricsもbeyond-accuracy metricsも含めてオフライン算出可能なmerticsをたくさん使って、推薦システムのオンライン性能(論文ではCTR と online accuracy という指標を定義していた) を予測する回帰モデルを教師あり学習的に作る、という手法を提案していた。
  • OPE推定量とは別のアプローチ。シンプル。決定論的な推薦モデルでも適用しやすい気はする:thinking:
  • OPE推定量を使うアプローチと組み合わせても良いのでは?? その場合は、低bias高varianceな推定量よりも高bias低varianceな推定量を説明変数として有効そう:thinking:
  • また本論文では、オンライン性能予測モデルを用いて、推薦アルゴリズムのハイパーパラメータを自動調整する手法も提案していた。(論文の例では、複数の推薦結果のブレンドの際の重み付け設定をself-adjustingしていました)

オフライン評価が難しいならオンライン実験のコストを下げまくるのも手なのかな...: Innovating Faster on Personalization Algorithms at Netflix Using Interleaving

  • Netflixの推薦システムでは、Interleaving -> ABテストの2段階のオンライン実験プロセスを採用してるという話。
  • ここでの Interleaving の役割としては「短期間で、多くのモデル候補の中から、ABテストすべき良さそうなモデルを絞り込む」というもの。(オフライン評価と近い役割な気がする...:thinking:)
  • もう大規模行動空間における推薦タスクのオフライン評価がめちゃめちゃ難しいのであれば、潔く諦めて、オンライン実験のコストを下げまくる戦略もあるんだろうか...:thinking:
  • wantedlyさんのpodcastが結構好きで聴いているのですが、Interleavingも採用してるし、recommendation schema(?)なるものでABテストの実装コストをかなり下げられているのでは、という印象です...! そんな組織でもやっぱり上手くオフライン評価したい、という感じなのでしょうか?? 🤔

より良い意思決定の支援をするための"効果検証 虎の巻"

効果測定方法として、A/Bテストができればそれが一番無難ではあるが、必ずしもA/Bテストができるわけではない。そうした状況の別の手段について紹介した記事。

DID(差分の差分法)やCausal Impact, 傾向スコアを用いた手法などが紹介されている

こんな感じの優先度付けで手法が検討されている。

image

(https://note.com/mercari_data/n/n2564f839cfd7 より引用)

A/Bテストで想定外の結果が出たら?検定多重性の影響を定量的に分析する

ABテスト(この場合はABCテストとでもいうのか?)において、すべての群で条件を揃えたときに有意差がでないはずなのに有意差がでてしまった事例の紹介。

原因の仮説まで考えた上で、それをシミュレーションにより検証している。

image

image

そこでここまでの結果をもってA/Bテストシステムに大きな問題はないだろうという結論でステークホルダーと合意を形成しました。

「状況から考えて多分こうだろう」で終わらせず、きちんとシミュレーションなどで確度を上げられるかがポイントなんだと思った。
ただただすごい。。。

論文紹介:ChatGPT で情報抽出タスクは解けるのか?

ChatGPTの情報抽出タスクの性能を検証した論文について紹介されている。検証結果から、SOTAと比べて何ができないのか、どういう形で使うと良いかの示唆が得られている。

LLMを活用した “反直感的”な新規サービス設計

チャット形式のUXどうなの?という話に加えて、ワークフロー単位での置き換えを意識したサービス開発の視点に共感した。

Choosing a Sequential Testing Framework — Comparisons and Discussions

Spotifyのオンラインテストに関する記事。テーマはシーケンシャルテストのフレームワーク

  • シーケンシャルテストのモチベーション
    • オンラインテスト中にp-valueを継続的にモニタリングしたい
      • ユーザ体験が悪化しているときには早く終わらせる判断をしたい
      • 明らかに結果が良いならば早くテストを終わらせたい
    • しかし多重検定問題があるのでどうにかしたい (peeking problem)
  • 主要なシーケンシャルテストフレームワーク
    • Group sequential tests (GST)
    • Always valid test (AVI)

テストフレームワークの基本的な考え方は、偽陽性率を制御するというもの。

  • GST:
    • 予めpeekingするタイミングを決めておいて各peekingでアルファ(=偽陽性率)を消費していくという考え方
    • peekingするときに見る実験データ量の見積もりがずれると精度が悪くなる
    • テストデータがbatchで入ってくる場合に便利
  • AVI
    • 実験途中のデータから実験終了時点での偽陽性率を予測することで偽陽性率を制御する手法
    • テストデータがstreamで入ってくるときにも使える