n週連続推薦システム系読んだシリーズ46週目: Udemyさんのユニット推薦にMABを導入したテックブログを読んだメモ!

これは何??

• 本記事は、n週連続 推薦システム系論文読んだシリーズの46回目です。

  • 前回はこちら: カルーセルUIの特性を考慮して推薦モデルを学習させるために、banditパラメータ更新にカスケードモデルを適用する論文を読んだ!

• Udemyさんのユニット推薦にMAB(multi-armed bandit)アルゴリズムを導入したテックブログを読んだメモです!

  • ブログ自体は二部構成:
    • 前半パート: Building a Multi-Armed Bandit System from the Ground Up: A Recommendations and Ranking Case Study, Part I
    • 後半パート: Building a Multi-Armed Bandit System from the Ground Up: A Recommendations and Ranking Case Study, Part II

• 「まずMAB(multi-armed bandit)ってなんだっけ?」「なぜ推薦でMABが有効なのか?」という話から、実務のランキング問題にMABを適用する際のデータサイエンス的な課題、実際の大規模サービスにおけるMAB導入のエンジニアリング的な課題まで、丁寧に言語化・共有してくださってて非常に読み応えがありありがたかったです...!!

導入

• 探索-活用のバランスをとるアプローチが様々なアプリケーションで成功を収めてるため、MAB(multi-armed bandit)アルゴリズムの人気が高まってる。
  • 特に成功してるアプリケーションの一つが、推薦。
• ゼロからMABシステムを本番システムに導入するのって エンジニアリング・運用・データサイエンス全部の観点から大変。
• 今回のテックブログでその実体験をシェアしてくれてる(ありがてぇ...)。
  • part1: 理論とデータサイエンス的な話
  • part2: ソフトウェアエンジニアリング的な話

MABとは?? なぜ推薦にMABを使うのか??

ざっくりMABの問題設定

• MAB(Multi-Armed Bandit)は、不確実性の元での意思決定問題を解くために使用される explore-exploit(探索-活用)アルゴリズムの一種。
• explore-exploit(探索-活用)アルゴリズムってどんな問題設定を解くためのもの??
  • 例: カジノのスロットマシン (かなりイメージしやすくてわかりやすい例でした!)
    • あなたはカジノに入り、選択可能なスロットマシンがいくつか提示される。
    • 各スロットマシンにはレバー(アーム)があり、それを引く(プレイ)と、各スロットマシンの事前に定められた報酬確率分布からサンプリングされたランダムな報酬(支払い)を受け取る。
      • 各スロットマシンは異なる報酬確率分布を持ち、これらの分布は最初にプレイを始めた時のあなたは知らない。
    • あなたの目標は、これらのスロットマシンをプレイすることで得られる勝ち金(累積報酬)を最大化すること。
    • あなたは賢いギャンブラーなので、使うつもりのある固定金額を持ってカジノに来た。なので、アームを引く回数は限られている。
    • もし各スロットマシンの真の報酬確率分布を知っていれば、長期的に勝ち金を最大化する方法は非常に明確である。
      • シンプルに、報酬期待値が最も高い1つのスロットマシンのアームを継続的にプレイするだけで良いはず。
    • しかし、あなたは最初はこれらの報酬分布について何も知らないため、限られたアームを引く回数の一部を使って探索し、各アームの期待報酬についてもっと学ぶ必要がある。また、これまで得た学びを活用して最も良さそうなアームを引くこととのバランスも取るよう必要もある。
      • 探索だけを行うと、各スロットマシンの報酬分布に対する高い信頼性を得ることができる。しかし、最適なアームを引くことを知る前に、アームを引ける回数が尽きてしまう。
      • 活用だけを行うと、最適でないスロットマシンを継続的にプレイする可能性が高くなり、それはそれでより高い報酬を得る機会を逃し得る。
    • これが古典的な「探索-活用(explore-exploit)のジレンマ」!
    • MABアルゴリズムをはじめとした探索-活用アルゴリズムは、このジレンマを解決するため(i.e. 探索と活用の最適なバランスをとり累積報酬の最大化を助けるため)に設計されてる。

MABの定式化

• MABは、不確実性の下で意思決定を行うために使用される探索-活用アルゴリズムの一種。
  • これは簡略化された強化学習アルゴリズムとみなせる。
• 標準的なMAB問題の設定は、以下のように定義できる:
  • $k$ 本のアーム（選択肢）のセット $A = {a_1, a_2, \ldots, a_k}$ が与えられた時、目標は、これらのアームをプレイする事で得られる累積報酬を最大化するために、最良のアームを決定すること。
  • アーム $a_i$ が時刻 $t$ にプレイされると、そのアームの報酬確率分布からサンプリングされた報酬 $r_{t}$ が得られる。プレイされていないアームに対しては他の報酬は観測されない。このアーム-報酬ペア $(a_i, r_t)$ を**観測(observation)**と呼んで記録する。
  • 我々は、最適でないアームをあまり頻繁に表示することなく、各アームの真の期待報酬についてより多くを学ぶために、次にどのアームを選択するかを最適に決定する戦略を考案する。戦略は、時刻 $t-1$ までのアーム-報酬ペアの観測履歴を考慮し、時刻 $t$ において次にプレイするアームを選択する。
• MAB戦略には多くの異なるアプローチがあるが、それぞれ利点と欠点がある。
  • ちなみに、Udemy内で構築したアプリケーションでは、主にThompson Sampling戦略を使用してるらしい。

推薦にMABを使うこと

• 推薦ドメインは、MABの完全な応用を含んでいる。
  • 一般的な推薦問題において、私たちの目的はユーザに最適なアイテムを推薦することであり、その「最適」とは何らかのユーザフィードバックに基づいて定義される。
  • (前述のMABの問題設定っぽい...!)
• 従って、推薦問題は以下のようなMAB問題として定式化できる:
  • 推薦するための候補アイテム集合は、プレイ可能なアームの集合 (各アイテムはアーム)。
  • 特定の推薦アイテムをユーザに一定の時間表示することは、「そのアームをプレイする」ことに相当する。
  • 推薦アイテムが表示された時のユーザフィードバック(ex. クリック、いいね、Udemyの場合はコース登録など)は、観測された報酬に対応する。(これはすなわち、選ばれたアームの未知の報酬分布からサンプリングされた報酬)
  • 目標は、探索と活用のバランスを取りながら、ユーザにさまざまなアイテムを動的に推薦することによって、できるだけ早く最高の報酬を得られるアイテムを特定すること。
• また、MABには、推薦アプリケーションに優れた特性が多くある。MABが特に推薦に適してる主な理由は3つ:
  • 理由1: 推薦タスクにはopportunity cost(機会コスト?)があるから
    • (もっとより最適なアイテムをおすすめできたのでは...という機会損失のコスト、という解釈...!)
    • MABは、最適でないアームをプレイすることによるコストがある問題設定で真価を発揮する。なぜなら、 MABはそもそも累積regretを最小化するように設計されてるから。
  • 理由2: 推薦におけるフィードバックループバイアス問題を克服するのに役立つから
    • フィードバックループバイアス問題 = すでに推薦されたアイテムがより多くの露出の機会を持つようになってしまい、結果としてそれらのアイテムに対するフィードバックが増え、さらにそれらのアイテムが推薦されやすくなる、という悪循環。
    • MABにおける探索は本質的にこのサイクルを断ち切る。あまり探索されてないアイテムはMAB的に推薦されやすくなるので、真に最適でない限り、同じアイテムを繰り返し表示することに陥る可能性が低くなる
  • 理由3: MABは、コールドスタートアイテム問題に自然に対処できるから
    • フィードバックループバイアス問題に密接に関連しているのがコールドスタートアイテム問題。
      • フィードバックがほとんどない新しいアイテムは、関連するポジティブなシグナルがほとんどないため、推薦される可能性が低くなる。
    • MABの設計上、報酬期待値の推定に自信を持つまでは新しいアイテムを自然に探索するようになってる。なので、MABは全ての候補アームに公平な機会が与える。
      • 探索フェーズにて成功と見なされた場合はそのアイテムを活用し、失敗と見なされた場合は表示を停止する。

ユニット推薦へのMAB導入に関するデータサイエンス的な話

ランキング問題をMAB問題として解くこと

• 伝統的なMABの問題設定は、ユーザに一度に1つのアームが提示され単一のポジションに対して最良のアームを見つけることが目標。
  • (ex. バナー最適化、サムネイル最適化、ボタンの色の最適化, etc.)
  • (いわゆる、Single-Play MABって呼ばれるやつ...!)
• 一方で、推薦ドメインにはランキング問題もある。
  • ここでの重要な違いは、ランキング問題では考慮すべき複数のポジションがあり、そのため技術的には複数のアームに対して同時に報酬を収集できるということ。
  • (いわゆる、Multi-Plays MABって呼ばれるやつ...!)
• Udemyにおけるランキング推薦の一般的な応用の1つは、推薦ユニットランキングである。
  • 推薦ユニットは、特定グループに属するコース達を集めた横カルーセル。(ex. 「Because you Viewed」「Recommended for You」「Popular for ___」など)
  • (つまり、ページ内での横カルーセル単位のランクづけ、みたいな感じか...!)。
  • これらの推薦ユニットがユーザのホームページに表示される順序は、ユーザーの視点とビジネスの視点の両方から非常に重要。

今回、Udemyでは推薦ユニットランキング問題を以下のように定式化したとのこと。
(この定式化方法は実運用で参考になりそう! 定式化大事だよなぁ...書籍「反実仮想機械学習」でも最初のステップとして「定式化がめちゃめちゃ大事だからスキップするな!」みたいな事が書かれてた気がするし...!)

1. 各推薦ユニットは「アーム」である。
2. 「アームをプレイする」ことは、特定のポジションにおいてユーザに推薦ユニットを固定時間(今回の事例では15分)表示することを意味する。各ユーザは、表示されたユニットに対して提供されたFBに基づいて「報酬(reward)」の「観測(obeservation)」を生成する。(ユニットのimpressionが発生した場合にのみ報酬が観測される。)
3. 「報酬(reward)」は、特定のポジションにおけるさまざまなユニットのパフォーマンスを比較するために使用したい指標。今回の事例では、固定時間内にユニット内のコースに対するユーザのクリックと登録の組み合わせを使用する (=確か後述されてたけど、報酬関数はこの2種類のFBの線形結合だった気がする...!)

このMABの定式化は十分にシンプルそう。しかし、ランキングの複数のポジションにおけるフィードバックの扱いについてはまだ検討すべき点が残ってる。

• 伝統的なMAB設定では、単一のアームのみがプレイされる。
• 複数のアームを同時に引くことができるという利点を活かすために、伝統的なMAB設定を修正する必要がある。(なるほど、解決すべき問題としては複雑性が増しててデメリットだと思っちゃうけど、利点とも見做せるのか...!)

ランキング形式のフィードバックの扱いをいい感じにするために、今回の事例では2つの異なるフレームワークが検討された。

検討されたフレームワーク1: Per-Position Framework

• 各ポジションを独立したMAB問題として扱う。
  • よって、ランキングの各ポジションに対して別々のバンディットインスタンスを使用することになる。
    • この場合の各バンディットの目標は、割り当てられた位置でプレイする最適なアームを見つけること。
    • ex. 位置2専用のバンディットインスタンスは、位置2でユーザにユニットが表示された場合にのみアームを「プレイした」と見なされ、位置2に関する観察のみを収集して学習する。
    • (なるほど。ポジションの数だけバンディットインスタンスを立てて、各バンディットインスタンスはSingle-play MABを解くってことか...!)
• 利点:
  • 各ポジションで最適なユニットを学習する設定なので、後述するslate bandit frameworkよりも、詳細でspecificなランキング最適化を達成できる。
• 欠点: いくつかの実践的な課題(practical challenges)あり
  • 欠点1: ポジション間の相互依存関係を考慮できない。
    • (上で同じようなユニットをおすすめしてたらそれを避ける、みたいな多様性の観点も含まれそう)
    • ランキングの長さが大きくなるにつれて、この相互依存関係はますます複雑になり得る。
  • 欠点2: 同時に複数の異なるバンディットインスタンスを維持(i.e. 運用)する必要がある。
    • 特にUdemyさんのシステムでは相互に依存するストリーミングアプリケーションとして構築されてる?ので、1つのバンディットインスタンスの障害は、他のバンディットインスタンスに問題を引き起こす可能性がある。
  • 欠点3: 単一バンディットインスタンスあたりが使用できる報酬フィードバックの量が減少する。
    • 観測される報酬FBは、異なるバンディットインスタンス間で簡単に共有できない。
    • ex. 位置2専用バンディットインスタンスの視点での「ユニットAの報酬」の定義は、「位置2でユニットAが表示された場合に発生するクリックとsubscription」である。よって、位置3でユニットAが表示された場合に観測されたFBは、位置2専用バンディットインスタンスでは使用できない。
    • これにより、バンディットが学習する時間とランキングが収束する時間が増加し得る。
    • (各position専用のバンディットインスタンス達が、個別で頑張って学習する必要があるって話か〜...)

検討されたフレームワーク2: Slate Bandit Framework

• 各ポジションを同時にテストする単一のMAB問題として扱う。
• 複数のアームを同時にテストするような、単一のバンディットインスタンスを使用する。
  • このフレームワークでは、「アームをプレイする」とは、上位 k 位置のいずれかにユニットを表示することと定義される。
• 注意点: この場合のkの値の選択は重要!
  • なぜなら、上位 k 位置のいずれかに表示されたアームに対するFBはすべて同等に扱われるから。
    • ex. 最初の位置でのクリックや登録は、バンディットインスタンス視点では、k番目の位置でのクリックや登録と同等に扱われる。
    • 一般的にkは、ユースケース次第のハイパーパラメータ。使用ケースやページレイアウトによって異なる。
  • なおUdemyさんの特定の(今回の?)ユースケースでは $k=3$ が選択されたとのこと。
    • 設定理由: ユーザのログインしたホームページは通常、画面が最大化されるとウィンドウ内に3つの完全なユニットを表示するから。これらの位置にあるユニットに対するFBは、一般的にほぼ等価と見做せるという考え。
• 欠点:
  • 解決しようとする問題の粒度が低下する。
    • このフレームワークでは、バンディットはもはや各位置における正確な最適ユニットを見つけようとはしない。「ページトップに表示するのに最適なユニットは何か？」という、より具体性の低い問題を解決しようとする。
    • (位置1に表示するのに最も良さげなユニットたちを上位k個選ぶ、的な問題になるってこかな...!)
    • ↑の目標の粒度の低下がもたらすのは...
      • 1: 上位 k 位置内のランキングは最適化されない。
      • 2: 上位 k 位置外のランキングは誘導されたものであり、直接学習されない。
• 利点:
  • 実装と運用がより簡単。
    • 単一のバンディットインスタンスを維持すれば良い。
  • 単一バンディットインスタンスが使用できる報酬フィードバックの量が増える -> バンディットインスタンスの学習・収束を速められる。

なお、上記のPer-Position Frameworkの実践的な課題を考慮して、Udemyさんの事例ではSlate Bandit Frameworkが採用されたとのこと。
そしてその後の既存の非バンディットユニットランキングアルゴリズムとのA/Bテストで、強い収益とエンゲージメントの向上を観察できた、とのこと。(いいね...!)

MAB活用におけるデータサイエンス的な課題

課題1: 収束(convergence)の達成と測定

• MABシステムを運用する際の一般的なDS的課題の1つは、収束を達成すること。
  • 特にstationary bandit setting(定常バンディット設定?)では、我々はバンディットシステムが最適なアームに収束すること(i.e. 探索を減らし、活用を増やしていくこと)を期待している
  • ここで「stationary bandit setting(定常バンディット設定?)」 = 各アームの真の報酬分布が時間とともに大きく変化しないと仮定するバンディット設定。
• MABアルゴリズムの収束速度を左右する要因たち(Convergence Factors)
  • 要因1: アームの数
    • アームの数が増えるほどバンディットの為のより多くの探索が必要になり、収束時間を長くする。
  • 要因2: 各アームの真の期待報酬の差の大きさ
    • 2つのアームの真の期待報酬が非常に近い場合、どちらのアームがより良いかをバンディットが区別するのが難しくなる。
    • これは、バンディットが何を表示するかの選択が行ったり来たりする原因となり、収束時間を長くする。
  • 要因3: バンディットインスタンスが受け取るユーザフィードバックの量
    • より多くのユーザトラフィックは、一定期間内に生成されるより多くの報酬を意味する。これはバンディットインスタンスがより迅速に学習・収束することを可能にする。
  • 要因4: バンディット戦略の選択
    • 一部のバンディット戦略(ex. ε-greedy)には固定された探索確率があり、ランキングが安定する量を制限する。
    • バンディットが収束する程度(およびそれにかかる時間)は、使用される戦略に大きく依存し得る。
• 収束を定義し、測定する方法について。
  • Udemyさんの事例では独自のmetricを設計して監視してたとのこと。
    • 具体的には、バンディットインスタンスが出力する連続したランキングを見て、一定のタイムウィンドウ内で上位k位置におけるアーム集合の変更の平均割合を追跡するような、「rate of change(変化率)」metricを開発した、とのこと。
    • バンディットインスタンスの収束が成功するなら、変化率は徐々にゼロに向かって減少するはず（ほとんどのバンディット戦略では常にある程度の探索が継続されることも考慮）。
• 収束を測定するためのグラフを用意することは、バンディットシステムが期待通りに機能してる事を確認するために重要。
  • 例(下図): 横軸=タイムウィンドウ、縦軸=rate of change metricの折れ線グラフ。
    • ウィンドウサイズ=60, ステップサイズ=60, 各更新は毎分発生する。このグラフは1日の各時間における連続したランキングでのアームセットの変更の平均率を示している。
• Udemyさんでは一般的に、バンディットシステムによる成功したA/Bテストの結果が、成功した迅速な収束と高い相関関係があることを見てきたらしい。
  • よって、改善を検討してるアプリケーションについてバンディットが適しているか否かを判断する際には、収束に影響を与え得る全ての要因(上記のConvergence Factors)を考慮しよう!

課題2: 方策のオフライン評価

• オフライン評価
  • A/Bテストでオンライン評価するバンディット戦略を決定し、iterationと改善に必要な時間を短縮するのに役立つ。
• しかし、MABは本質的にオンラインでinteractiveなアルゴリズムなので、オフライン評価が非常に難しい。
  • 以前に収集されたhistoricalデータを使用することはしばしば不十分である。なぜなら、過去に選択されたアームが、今回評価したいバンディット戦略が選択するアームと異なる場合があるから!
• 提案されてる対処法: replay method(リプレイ法)
  • まず最初に、短いランダムデータ収集フェーズを実行する。
    • これにより、バイアスのないhistoricalなアーム-報酬ペアのストリーミングデータセットが生成される。
  • 次に、評価したいバンディット戦略で、historicalなアーム-報酬ペアのストリーミングを順次進み、その時点でバンディットが選択したいと思っていたアームと一致するアーム-報酬ペアのみを保持する。
  • 最後に、上記の一致したペアのみを使って得られた累積報酬を、バンディット戦略のオフライン評価のための指標として使用する。

MAB活用におけるソフトウェアエンジニアリング的な話

システムアーキテクチャの全体像

• 上図は、Udemyさんの推薦ユニットランキングのためのMABシステムの高レベルアーキテクチャ。
  • ニアリアルタイムに動作する。
  • 赤い点線の矢印が示すように、ユーザフィードバックが継続的にしようされて推薦を改善するような、closed loopなシステム。
    • (「継続的学習(continuous learning)」による継続的改善ってやつか〜...!)

以下はMAB推薦システムにおける各コンポーネントの連携の流れ:

• 流れ1: ユーザがUdemyとinteractする。
  • ループは、ユーザがUdemyのウェブサイトまたはモバイルアプリと対話する際に始まる。
  • リクエストされたページが読み込まれる際、現在の最良の推薦がRedisから読み込まれ、ユーザに提供される。
    • (あ、バッチ推論かな?って思ったら、後述された内容を見るにストリーミング・非同期推論って感じだった!)
• 流れ2: イベントの生成とKafka(=イベント貯めるやつ!)へのpublish。
  • UI要素が読み込まれて操作されると、イベントが生成され（フロントエンドとバックエンドの両方のシステムから）、Eventing Systemに送信される。
  • これらのイベントにはトラッキングIDがあり、それによりファネルイベントにまとめることができる。
    • これにより、UI要素が表示されたか、クリックされたか、またはコース登録や講義の視聴（=報酬）などの興味深い下流イベントにつながったかを知ることができる。
    • (なるほどなぁ...トラッキングIDでアームプレイログと報酬ログを紐づけてるのか。timestampで頑張って紐づけるんじゃないんだ...!)
  • 生成されたイベントは、下流システムによって消費されるためにKafkaトピックにpublishされる。
• 流れ3: ストリーミングアプリケーションがイベントから観測(observation)を生成
  • (イベントを結合して報酬観測値を作るストリーミングパイプライン的なやつ...!)
  • Kafkaイベントから観測(i.e. 報酬)を作成するために特化した2つのSpark Structured Streamingアプリケーションで構成される。
    • 1つ目: Funnel Join App
      • impressionイベントと下流イベント(クリック、登録、講義の視聴など)を組み合わせた結合イベント(i.e. ファネルイベント)を作成する。
      • このファネルイベントは「推薦を表示することは、一定の時間内に報酬につながったか？」という観測を生成するために使用される。
      • このファネルイベントもKafkaトピックにpublishされる。
    • 2つ目: Observation App
      • Kafkaトピックからファネルイベントをsubscribeし、セッション化ロジック(?)を適用して最終的な観測(i.e. アーム-報酬ペア)を生成する。
      • 生成した観測も別のKafkaトピックにpublishされる。
  • (これって2つのfiliterを持つ一個のストリーミングうパイプラインにまとめちゃってもいいのかも...?)
• 流れ4: バンディットモデルアプリケーションが観測を使用して推薦結果を更新、Redisに書き込む。
  • (バンディットインスタンスの学習と推論を非同期に行うストリーミングパイプライン的なやつ...!)
  • Kafkaからマイクロバッチ(=高頻度で小さい件数をまとめて処理すること?)で観測(i.e. アーム-報酬ペア)を取得し、各アームの報酬分布を更新し、Redis上の推薦結果を更新する。
    • ここで「マイクロバッチ(micro batch)」 = 小さい件数を高頻度でまとめて処理すること? バッチとストリーミングの中間的なイメージ...!
  • また、このストリーミングアプリは全ての中間状態をDBにログとして記録するので、後でオフライン分析に使用できる。
    • (なるほど、このログを使って前述の「rate of change metric」を測定するのか...!)

以下は追加のコンポーネントの話:

• 候補生成ワークフロー
  • バンディットインスタンスが推薦ユースケースに対して、どの候補(i.e. アーム)を考慮すべきかを知らせるために使用される。
  • 本ワークフローは、いくつかの設定テーブルを参照して、表示可能なUI要素(i.e. コースや、コース集合の横カルーセル)を取得する。
  • 本ワークフローは、アーム候補集合を更新するために毎晩定期実行されてる。かつ、必要に応じてadhocに更新もできるような十分に堅牢なものとして設計されてる、とのこと。
    • (必要に応じてon-demandでも更新できるよ、って話か...!)
• Monitoring, Alerting, Supervision(監督?)
  • 上述のMAB推薦システムが24時間健康な状態を維持するために、各Kafkaトピックに書き込まれたレコード数や、Redisの書き込み・読み取りレイテンシーなどの重要metricsのリアルタイムダッシュボードを構築・運用してる。
  • さらに、ストリーミングアプリケーションの状態を5分ごとにチェックし、失敗した場合や不良状態の場合には再起動するようにスケジュールされたsupervisorジョブもある。

MAB導入におけるエンジニアリング的な課題

• 課題1: リアルタイムシステムを開発することの学習コスト
  • バッチシステムからリアルタイムシステムに移行すると、考えることが一桁難しくなる。(ニアリアルタイム、ストリーミングシステムって感じかな...!)
• 課題2: リアルタイムシステムの稼働の維持とサポートの取り組み
  • バッチアプリケーションとストリーミングアプリケーションの主な違いの一つは、ストリーミングアプリケーションは24時間安定して稼働しなければならず、時間の経過とともに蓄積される微妙なバグに対してより脆弱であり、アプリケーションがクラッシュする原因となること。
    • これは、昼夜を問わず、休日であってもいつでも呼び出せる専任のオンコールサポートが必要であるため、困難。
    • もちろん、さまざまなmetricsを監視する広範なダッシュボードを通じてアプリケーションの健康状態を把握し、適切なアラートとオンコールスケジュールを持つことは、そのようなプロダクトを立ち上げるための基本条件。
    • しかし、サポートエンジニアを疲弊させることなくプロダクトを成功させるためには、アプリケーションが必然的にダウンするという前提で設計し、再起動を優雅に処理(理想的には自動化)することが重要!

今後の発展の方向性

報酬の強化

• (報酬関数の定義の見直し、拡張みたいな話...!)
• ブログ執筆時点のUdemyさんのMABシステムの報酬関数は、クリックと登録の加重和を使用してる。
  • この報酬定義は、Udemy内で望まれるオンラインA/Bテストの指標と一般的に良い相関関係があることがわかっているとのこと。(この知見が得られてるの流石だな〜...!)
• しかし、MABの能力を更に向上させるために、報酬関数にいくつかの修正を加えることを検討してるとのこと。
  • subscription以外の新しいイベントタイプを報酬に含めること。
    • ex. ウィッシュリストへの追加、レビューの投稿、講義の視聴など。
    • より頻繁に発生するかつユーザの意図を示すシグナルを含めることで、MABの収束速度を向上できる可能性がある。
  • 長期的な報酬を考慮すること。
    • (継続率などの遅行指標の予測値を報酬関数に含める、みたいなイメージかな...!)
    • 1つの方法として、短期的なシグナルからLTV(lifetime Value)のような長期的なシグナルを予測して、それを報酬関数に含めることが紹介されてた。

Contextual Banditへの拡張

• MABシステムをcontexual banditシステムに拡張すること。
  • contextual banditシステムでは、全てのアーム-報酬ペアはcontextベクトルと結び付けられる。
    • contextベクトルには、ユーザ固有の特徴量、表示先ページの特徴量、アイテム固有の特徴量などが含まれ得る。
  • contextベクトルを含めることにより、MABの意思決定プロセスをパーソナライズすることができる。
    • ユニットランキングの例では、全てのユーザに対して単一の動的に更新されるグローバルランキングを持つのではなく、各ユーザに対して動的に更新されるパーソナライズされたランキングを持つことになる。
• システム視点では、contextual banditシステムに拡張するために2つの追加コンポーネントが必要になりそう。
  • 1つ目: 推論とオンライン学習の両方を処理できるリアルタイムモデルサービス。
    • (FTI Pipelines Architecture的には、推論とオンライン学習はコンポーネントを分けるべきなのかなぁ〜まあでも連結されてても全然いいかな!)
  • 2つ目: context(特徴量)をモデル推論時に提供できるリアルタイム特徴量サービス
    • (FTI Pipelines Architecture的には、feature pipeline & feature storeね...!)
  • 注意: contexual MABシステムは既存のMABシステムと比べて非常に挑戦的な設定である!
    • なぜなら、以前は予測がマイクロバッチで更新されRedisを介して提供されていたのに対し、この場合はページが読み込まれる際にパーソナライズされた予測をリアルタイムで(i.e. 50 ms未満のレイテンシで)計算する必要があるため。
      • (全ユーザ分のランキングをバッチ推論で作るとRedisがパンパンになってしまうから、ユーザごとにページ読み込み時にリアルタイム推論する方が効率的だよね、ってことかな...!)
    • また、典型的な推論専用のリアルタイムモデルサービスとは異なり、推論のSLAに悪影響を与えることなくオンライン学習も処理できる必要がある。
      • (やっぱりここは自分だったら、運用しやすさから推論と学習はコンポーネントを分けるかも...!あと必ずしもリアルタイムな学習じゃなくてマイクロバッチ学習でも良いのではという話もある)
• バンディットは成功が実証された強力なツールだが、特にスケーラブルでニアリアルタイムの方法で、プロダクション環境で成功裏に実装することは特に困難。