KDD2020で気になった論文を読む その1
冬休みのノルマとして2本しっかりじゃなくてもいいので読んでおく。
Improving Recommendation Quality in Google Drive
概要
google driveでのレコメンドの改善の積み重ねをまとめて論文にしたもの。
DNNの構造、モデリングの技術、データソース追加、UX改善などあらゆる視点でのレコメンド施策が述べられている。
結果として、CTRを34.8%、精度を10.7%改善することができた。
システムの全体像
大きく5つのコンポーネントから成る。
(1)訪問ユーザーのデータ取得
ユーザーが訪問した際、そのユーザーに関する情報を蓄積されたデータソースから取得する。
サービスでのアクティビティ、gmailやカレンダーなど関連サービスでの添付ファイル情報など。
(2)候補生成
1で収集したデータを特徴量に変換し、候補となるアイテム（ファイル）とそれに紐づく特徴量と共にランキングモデルに投げる。
候補は60日以内にアクティビティのあるファイルに限定している。*1
(3)ランキング
MLモデルによる候補のランキングを行う。
このモデルはビジネスロジックで調整がされており、例えばなぜそのファイルが選択されたのかをユーザーに示すなどが例としてあげられる。
＃例えば同じ説明がされるアイテムが1位と3位だったとして、ユーザーへの説明のために3位のアイテムを1位と一緒に並べたりするということだろうか...？
(4)レコメンド結果の提示
ユーザーがDriveの何れかのファイルをクリックしたらセッションが終わり、詳細情報が紐づいたクリックデータがサーバーに送られる。
(5)モデルの学習
モデルは候補、ならびに特徴量、クリックの情報を元に再学習がされる。
改善の内容
候補生成
候補対象の選び方に制限をかけて行った。
まず過去40日で最大500の候補->メトリクスに変化がなく、問題なかった。
さらに直近60日間で100の候補に変更。
その結果、性能を低下させることなくレイテンシを減少させることができた（99%tileで24%）
候補生成のメトリクスにはRecallを用いている。
最初からrecallが結構高く、ここにMLモデルを入れても改善の上限がありそうなので、まずは経験則で別ソースから候補を追加した。具体的には、シェアorコメントによる言及をしたファイルを追加することで+5.3%の改善などがみられた。
DNNモデルの最適化
- 損失関数の変更
当初は損失関数としてlogloss、評価関数としてAUClossを利用していた。
しかし、データの不均衡性（pos : neg = 1 : 99）の問題から、AUC-PRに損失関数、オフライン評価関数ともに変更した。
結果、オフラインのAUC-PRが0.45%向上し、オンライン評価時のAccuracy, CTRがそれぞれ1.0%, 0.6%向上した。
- latent cross
自分の所属組織だけかもしれないがよく参考にされているyoutubeのレコメ論文で触れられている手法。
特徴量間の相互作用を考慮できるらしい。
今回は実際にユーザータイプ、Platform、曜日の情報を利用した結果、オフラインメトリクスはわずかな改善しか見られなかったが、オンラインでは全ての実験グループで改善がみられた。
- ResNet
Residual Unitを組み込み、オンライン指標では精度が0.56%, CTRが0.45%増加と非常に大きな効果があった。
- Batch normalization
導入により収束スピードの向上とテストのパフォーマンスが向上した。
今回は、入力層Batch normalizationレイヤを追加しなかった。理由としては学習の時間が大幅に増加してしまったため。
- Deep & Cross Networks
latent crossでいい結果が出たため、さらなる相互作用の追加を見込んでDeep & Cross Networkを導入した。
同じ意味を持つような特徴量をグループ化する必要があるため、どのように特徴量を分割するかを検討した。
あたらしく特徴量を追加する際にどのグループに追加すればいいかわかるようにすることをルールとして分割を決定しtた。
この仕組みの導入によって、特定セグメントでCTRが+1%程度向上した。
ただしTrainingの時間が2倍程度かかるようになってしまった。
モデリングアプローチ
- 候補サンプリング
ランキングモデルをpoint wise lossからlist wise lossに変更することを検討するにあたり、候補アイテムのネガティブサンプルを減らすと性能が下がるかどうかを確認した。
候補のMaxが100の際の精度と比較し、50にすると-1.3%、25だと-4.2%、10だと-30.9%という結果となった。
もともとたいていのネガティブサンプルには学習においてそれほど意味がないという仮定があったが、これは誤りだった。
- ポジションバイアス
95%のクリックが上位3件から来ていることもあり、ポジションバイアスを考慮してアプローチでの改善を行ったが、特に変化がなかった。
- 学習データの完全性
学習データの完全性を担保するために、クレンジングやフィルタリングを行う。
クリックをポジティグ、ノンクリックをネガティブとして学習している以上、これに関連するノイズデータを除去することでモデルの性能が上がるかどうかを調査するべき。
具体的には以下。
(1)ユーザーが予測をみた後時間が経ってからクリック
1分以上遅れ、5分以上遅れのクリックをフィルタリングしてみた。
結果としてモデルの性能に違いは出ず、学習データを減らすことができた。
(2)Quick AceessのUI外からのクリック
Quick Aceessのみのクリックから作成したデータセットと、全てのDriveからのクリックから作成したデータセットで性能を比較。
結果としてフィルタリングしたデータセットでは精度が0.6%低下したことから、フィルタリングはしないほうがいい。
FeedbackLoopの問題を防げているのではないかとのこと。
(3)ユーザーのファイルがユーザーにとって真の関連性のあるインタラクションを有していない
インタラクションとしてカウントされているイベントを調査。いかに大別される。
a.ユーザーイベント：読んだり編集したりするなどのユーザーが直接トリガーとなるイベント
b.3rd party イベント：sync clientなどの3rd partyがトリガーとなるイベント
bのイベントはnoiseだとしてこのデータをフィルターした結果、CTRが+1.3%となった。
- 特化モデル
特定のユーザーグループ単位の特化モデルを作成した。
別ユーザーへの性能が下がるのは当然だが、驚くべきことに特定ユーザーに対しても既存モデルと変化がなかった。
すでに現状のモデルて、特定グループがそうでないかを分別できていると考えられる。
特徴量の追加
下記を繰り返す
(1)新しいデータの追加
(2)新しい特徴量の作成
(3)追加した特徴量でモデルの学習とチューニング
この改善サイクルの中で、改善があったと思われるのは大体15%くらいの特徴量セットだった。
いくつか事例があるが効果大きかったやつだけ。
a.meta data features
ユーザーがstarをつけたファイル、編集日時、権限があるか。
レイテンシは悪化するが性能はよくなる。
b.Platform feature
web, iOSなど。特にモバイルユーザーに対しての性能が大きく向上。
- 特徴量追加の落とし穴
1.候補の特徴量が何万のものfloatの値をもっており、冗長性をもっている？
例えばヘビーユーザーの行動を捉えるためにdailyのDriveでのセッション数を追加してみたが、既存特徴量に対して新規性がない結果になった。
この結果から、既存特徴量を文書化し、モデルの複雑性を下げる方向にした。
2.下記の問題
a.rankerによって偏ったフィードバックを収集されている
b.様々な特徴量の有無にばらつきがあり、特定の候補アイテムで特定の特徴量が欠ける
メトリクス
ここではMLモデルとベースラインとしてMRU（Most Recently Used）のCTR、Accuracy、Recallを計測している。
18ヶ月の計測で着実に指標が改善しているが、この要因としては実験速度を最適化するためのシステムを構築したことがあげられる。
システム内では自動での実験ごとのラベル付、評価、プロットなどが行われ、容易に実験の比較が可能。
こういった実験のオーバーヘッドを削減することが性能改善に寄与している。
最終的にCTRが34.8%、Accuracyが10.7%改善。
スケールと複雑性の削減
インフラの変更
ItemSuggestというインフラに変更。
これにより特徴量追加の度に実装が必要になり、学習のプロセスが遅くなってしまった。
これについては特徴量変換をするオフラインパイプラインの実装が妥当点となった。
MLモデルについてはTFモデルからTFRankingに変更にすることでlist wise lossに対応、かつ学習時間を50%削減できた。
ハイパラ探索はGrid SearchからVizerに変更。
モデルパイプラインはTFXに変更。これにより異常検知の自動化、モデルの品質検証の自動化、データのサブセット上でのモデルの評価能力向上といった利益があった。
特徴量再構成
元々のモデルは38kの素性を使っていた。
これによって、モデルの性質の改善が難しい状態になっていたし、新しい特徴量が追加された時に性能が上がらなかった時の原因がよく分からなくなっていた。
対策として、特徴量生成をより小さいブロックで生成できるように改修、並びにVizerの利用による特徴量のPruningを行い、最終的に4000まで特徴量を削減できた。
学習workflowの改善
モデルの再現性についてはチャレンジし続けている。
新しいデータやシーズナリティ、データのプラポリ的な制約（一定期間でデータ削除）などで再現は難しい。
対応としては、
1.実験モデルの学習をする際に、プロダクションモデルと同じ特徴量とハイパラで新しいベースラインモデルを常に再学習すること
2.実験者が共通のベースライン上で検証を行うこと
がある。
Deepモデルからの脱却
モデルの解釈性、レイテンシ改善、特徴量エンジニアリングを生かすためにGBDTモデルへの移行を検討したが、これは失敗に終わった。
多量のスパースな特徴量があり、特徴量エンジニアリングをしてもDeepモデルの品質には至らなかった。
また、特徴量ベクトルのサイズが大きく、我々のGBDTの学習環境ではcross feature interactionがうまく学習できなかったと考えている。
ただし、特徴量生成のロジックの理解やBugFixにつながったのは幸運だった。
所感
この手の特定サービスにおけるレコメ品質改善の内容が外に出されるのは非常にありがたい。
G社のプロダクトのレコメ周りはRecSysとKDDで継続的に発表されているし、それぞれ読んでいると改善の変遷がよくわかるようになっている。特に今回は自動化へシフトが目を引いた。
インフラ周りとかはどうにもならない部分もありそうだけど、システムのHigh level Archietectはずっと一貫しているのでこの形は参考にしたい。
今使っているといっているDeepのモデルは推論のlatencyがだいぶ大きくなりそうな感じだけど、そうでもないのだろうか...
*1:過去の研究により、実際に開かれるファイルの75%以上はこの条件に該当することが分かっている。https://static.googleusercontent.com/media/research.google.com/ja//pubs/archive/46184.pdf
