この記事は （1人で）基礎から学ぶ推薦システム Advent Calendar 2022の8日目の記事です。
昨日まで「とりあえずやってみよう！」というテンションでの準備体操は終わったので、今日は一歩下がって推薦システム開発の大まかな全体像を一巡りしていこうと思います。
開発をひとめぐり
ざっくり開発の流れを書くとこんな感じかな？と思ってます。
図は個人的にウォーターフォールっぽく考えたほうが考えやすいなと思ってるだけです。 きっと人それぞれ考えはあると思うので、順番とか依存関係はうまいこと調整してもらえれば。
以降で、一個ずつ見ていきます。
問題設定
これは推薦に限らずですが、最初にきちんと問題設定をするところから始まります。
推薦と一口に言っても人によって想像するものはバラバラだったりします。 ユーザーによって推薦の方法が異なる場合もありますし、推薦に使用するアルゴリズム自体も変わることもあります。
なんの指標を改善したいのか、その場合ターゲットセグメントはどこなのか、UIはどうするのか、などを決める必要がありそうですね。
単一, 一定数のコンテンツの推薦
メールによるアイテムのおすすめや、広告枠などでアイテムが表示されるような状況が該当します。 この場合はアイテム数はたかだか数件〜数十件になると思われ、何を表示するのかが重要になるかもしれません。
ランキング
ニュースやSNSなどのフィード画面ではコンテンツが1列にならんでいることがあります。 あくまでランキングなので、理論上すべてのコンテンツが表示されることになりますが、実際にユーザーが見るのは上位から数件〜数十件といったところかもしれません。 さらに、多くの場合下位のコンテンツを表示するにはスクロールが必要になり、ランキングには存在するが表示すらされない点にも注意しないといけません。 この場合は、どんな順番でアイテムがおすすめされているかが重要になるかもしれません。
アルゴリズム・システム設計・実装
よくあるアーキテクチャ
推薦システムではTwo Stage Recommendationのアーキテクチャが使用されることが多いかと思います。
細かい形は違えど、さまざまな企業でこのTwo Stage Recommendationのアーキテクチャが採用されおり、主流のアーキテクチャといって良いでしょう。
Two Stage Recommendationだと、
- candidate generation
- dataのロード
- 前処理
- train、モデル作成
- predict
- 結果の出力・保存
- reranking
- dataのロード
- 前処理
- train、モデル作成
- predict
- 結果の出力・保存
のような構成を記述していくことになるかと思います。
オンラインで稼働させるときには評価は学習も評価もしている時間はおそらく無いと思います。 なので、モデルは事前に学習したものを用意しておいて、下記のように推論だけを2段階行うような構成になるかと思います。
- candidate generation・rerankingで使用するモデルの学習(オフライン)
- candidate generation(オンライン)
- 前処理済みのtest data、モデルのロード
- predict
- 結果の出力・保存
- reranking(オンライン)
- 前処理済みのtest data、モデルのロード
- predict
- 結果の出力・保存
パイプライン・モデルの設計
candidate generation・rerankingに実際にどんなモデルを使用するかは、頑張って考えるしかありません。
なんとなくですが、candidate generationはTwo-TowerモデルでEmbeddingを作成してオンラインで近似近傍探索を使用するのが、最近のトレンドな気はします。
オフライン評価
イメージした推薦システムができたとしましょう。 「このままリリース！」とするのはちょっと待ったほうが良いかもしれません。
もしオンラインにリリースして、実装した推薦が思ったような性能を実は達成できないと、ユーザーは離れてしまうかもしれません。 そこで、リリース前に事前に期待した性能が出そうかどうかについて評価を行うことがあります。
もちろん、完全に新しいシステムだったりなどオフラインでの評価が難しいケースもありますが、「既存のアルゴリズムと比べて優れていそうか？」などの観点はオフラインで確認できる範囲ではオフラインである程度確認できるので、オフラインで確認したほうがトータルのコストは小さく収まったりします。
精度
真っ先に思い浮かぶのは精度の観点だと思います。 精度と言ってもいろいろあるので、いくつか見ていきたいと思います。
このあたりは次の記事でもう少し突っ込んだ記事を書く予定なので、サラッと行きます。
回帰精度
ユーザーによる評価値が得られる場合には、RMSEなどの誤差を評価するのが有効かもしれません。 例としては、商品に対してn段階評価をつけてもらったケースなどのデータが得られる場合には、RMSEの指標を使用して評価を行うことで、「ユーザーがつけた評価にどれだけ近い評価を推定できるか」について確認することができます。
ざっと挙げるだけで下記のようなものがあります。
- MAE(Mean Absolute Error)
- MSE(Mean Squared Error)
- RMSE(Root Mean Squared Error)
- NMAE(Normalized Mean Absolute Error)
- NMSE(Normalized Mean Squared Error)
分類精度
positiveな反応をするアイテムをどれだけ効率よくおすすめできたかの観点で評価することもあります。 特にTwo Stage Recommendationの1段目では、正確な評価値を推定するより、「本当だったらユーザーに見せればいい反応をしたアイテムをcandidateに効率よく含められたか」がポイントになります。 この問題は、アイテムがユーザーにとってpositive/negativeの2値分類するタスクと同様に考えられるので、Recall やPrecisionを使用して評価を行うことができます。
代表的なところだと下記のような指標があります。
- precision
- recall
- F score
- AUC
並びの良さ
Two Stage Recommendationの1段目とは異なり、2段目ではアイテムの順位のほうが関心があります。 特に、ランキングシステムなどではユーザーがpositiveな反応をするアイテムをどれだけ上位に配置できるかという並び順の良さが重要になってきます。 こうしたときにはnDCGなどで並び自体の評価を行ったりします。
代表的なところだと下記のような指標が使用されます。
- MRR(平均逆順位)
- MAP(平均適合率)
- nDCG
その他観点
「精度が良いからOK!」とは言い切れず、推薦システムでは下記のような観点も考慮していたりします。
- ユーザー視点での観点
- 多様性
- Serendipity
- カバー率
- プライバシー
- アイテム提供者側の視点
- 公平性
精度が高いだけでなく、ユーザー・アイテムの両面から考えて良い推薦になっているかを考えるケースが最近は増えてきました。
オンラインテスト
オフライン評価で問題なさそうだったらオンラインテストで実際に確認することが多いと思います。
テスト手法
一口にオンラインテストといっても、手法はいくつかあります。
- A/Bテスト
- 定番
- ユーザーテスト
- まだプロダクションに乗せられないときなど
- interleaving
- ランキング形式での推薦など
- Switch Backing
- ネットワーク効果の影響を軽減したいときなど
推薦の方法によって、望ましいオンラインテストの手法も変わったりするので、オンラインテストごとに選定していきます。
テスト設計
オンラインテストをすると言っても、様々なことを決める必要があります。
- テスト期間
- 対象ユーザー数
- ユーザー分割単位
- 評価指標
- Goal metrics
- Guardrail metrics
- Debugging metrics
などを決めていったりします。 （参考: メルカリにおけるA/Bテスト標準化への取り組み｜Mercari Analytics Blog｜note）
参考文献
以上、"超ざっくり推薦システムの開発ツアー"でした。 正直なところ、やってみないとわからないこともたくさんありますが、最後に「書籍で勉強するならこの辺かな？」というのを挙げて終わります。
その他、こちらの記事も参考になりますのでご参照ください。
