タイトルの論文を読んでみたので、内容に関する雑なメモです。
論文
著者
Suming J. Chen, Zhen Qin, Zac Wilson, Brian Calaci, Michael Rose, Ryan Evans, Sean Abraham, Donald Metzler, Sandeep Tata, Mike Colagrosso (Google LLC, USA)
背景
Google Drive にはQuick Accessという機能があり、ユーザーはこの機能によって関連するファイルに効率的にアクセスすることができます。 Quick Accessの推薦を改善することは膨大なトラフィックが発生するGoogle Driveにとっては非常に重要なこととなっています。
システムの概略
前提となるQuick Accessの動作は大まかに下記の通りになっているようです。
- ユーザーがGoogle Driveにアクセスした際に、直近2~3週間のユーザーの行動を収集
- 1.で収集したコンテキスト情報から特徴量・アイテム候補・アイテム候補ごとの特徴を取得
- 2.で生成した特徴量を使用してランキングを作成
- 上記の推薦結果をユーザーに提示し、Google Drive内の任意の位置でクリックされた情報がMLパイプラインへ送信
- MLパイプラインは、特徴量・候補とクリック情報から新しいモデルを学習
目的とアプローチ
目的
- Quick Accessの推薦精度の改善
アプローチ
この論文に書かれている取り組みは、大まかに下記の通り。
- アイテム候補の推定改善
- DNNの改善
- モデリングの改善
- feature engineering
- レイテンシの改善
提案手法
実際の改善方法について、かいつまんでメモしていきます。
アイテム候補の推定改善
もともとは過去60日以内に使用されたファイルが推薦の候補としていたようですが、推薦に係るデータ量を削減するために過去40日間のデータに絞ったようです。 直近40日にあまりアクティブでないユーザーのために、候補の数を増加させることも試みたようですが、時間的局所性に反するアイテム候補をカバーしきれないため、過去40日間に使用されたファイルを対象にしても品質には影響がないと判断したようです。
その他、ユーザーに対して他の人が共有したファイルやユーザー自身が言及したファイルなどを候補に加えることで、アイテム候補のRecallを増大させているようです。
DNNの改善
実際の推薦にはDNNを使用しています。その内部についての改善についても確認します。
損失関数
もともとは、損失関数にlogloss、評価関数にAUCLossを使用していたそうです。 ただ、これだと100個の推薦候補があるときセッションに対して1つのpositiveなアイテムと99個のnegativeなアイテムになるという、偏った状態になってしまいます。 そこで、オフライン評価関数と損失関数をAUC-PR(AUC Precision Recall)に変更したそうです。
Latent Cross
YouTubeの推薦で使用されているLatentCrossという手法をここでも採用したようです。 ユーザーの属性と推薦の候補の間の暗黙の特徴の相互作用を生成するようです。
Latent Crossとしては、ユーザーの種別やモバイル/デスクトップ、曜日などが含まれるとし、そうした特徴を通常のニューラルネットの最終層の出力と掛け合わせることで最終的な出力を得るそうです。
ResNet
当初、全結合層を3層重ねたモデルであったのに対して、全結合層をResidual Unitに置き換える改善をしています。 Residual Unitでは一般的に2層の畳み込み層とスキップコネクションで構成されていますが、ここでは単層の全結合層とスキップコネクションでResudual Unitを構成しているようです。
Batch normalization
バッチノーマライゼーションは一般的なNNのテクニックではありますが、ここでは最初の全結合層の後にバッチノーマライゼーション層を挿入しています。 全結合層の前に配置するより、こちらのほうが学習時間が短縮できるそうです。
Deep & Cross Networks
上記で示した内容をDeep & Cross Networkに基づいて構築すると下記のようになる模様。
Cross Features, user context features, other featuresの3つのタワーを最後に結合するような構造になっています。
モデリングの変更
モデルのロスに関して、100個のアイテムのうちいくつをサンプリングして使用するかについても検討されています。 結論としては、100個のアイテム候補のうちすべてをロス計算に使用するのが最も良かったとし、ロス計算をそのように行っているようです。
Quick Accessでは、95％のクリックは推薦された上位3件のファイルに該当しており、学習の段階ではこの位置に関するバイアスに対処したそうです。 これに関しては、ネットワークの途中でドロップアウトを挿入することで、位置バイアスに過度に依存することを回避するようです。
学習データに関しての見直しも行っており、推薦されてから時間が経ってからクリックされたケースや推薦された領域以外の部分でクリックされたケース、ファイルに対するインタラクションが不自然なケースなどを精査しています。
最終的には
- 推薦されてから時間が経ってからクリックされたケースについては5分以上経ってからクリックしたケースを学習セットから除外
- 推薦された領域以外の部分でクリックされたケースについてはデータに含める
- 直接ユーザーが操作したと想定される場合に限り学習データに含める
といったように学習データを整理したそうです。
Feature engineering
推薦品質の主な向上方法として、特徴量エンジニアリングを行っています。 さらに、既存のデータだけでなく新しいデータの作成・ロギングも合わせて実施しているようです。
最終的には下記のような特徴を追加した模様。
- 共同編集者・アップロードの有無
- ファイルの更新時間やスターが付いているかどうか
- レイテンシは増大したが、それ以上に精度が改善したため採用
- モバイル/デスクトップ情報
- オフライン評価では効果は確認できなかったがオンライン評価では効果があった模様
- ユーザー情報
- ユーザー情報、曜日・時間、カレンダー情報
- ユーザー固有の外部情報
- 連絡先・ファイルなど
逆に、うまく行かなかったケースとしては、
- 多くの数値系の特徴量
- 他の特徴から派生するものと考えられるため
- ランキングに関するDrive以外のアクティビティ
- 候補の絞り込みには有用でもランキングには効果がない恐れ
となっています。
レイテンシの改善
その他、UX改善のため、レイテンシの改善を行ったそうですが、機械学習とはあまり関係ないので詳細は省略。 フロントエンドのレンダリングとレコメンドの作成のタイムラインをパラレルにすすめることでシリアルだった実行を高速化したそうです。
評価
改善の結果は下記の通り。
CTR・Accuracy・Recallのすべてで従来（Most Recently Used）よりも良いスコアを出しているとのこと。
その他
議論になっている部分について確認すると、特徴量の数に関する議論はありました。 素朴に特徴量を作り続けると34000個ほどになるそうですが、実際にはある特徴量から派生したものがおおく、新しく変数を追加しても改善が見られない場合も多かったそう。 この辺の見直しをして、最終的には4000個のfloatの特徴を使用するモデルにし、モデルの見通しを良くしたとの話。
あとは、季節性とデータの利用ポリシによって、モデルの再現性には苦労したようです。 夏になるとアクセスの傾向が変わったり、過去のモデルを再現しようにも使用ポリシ上それができないこともあったりなかったり。 そういう苦労もあるんですね。
結論
ユーザーごとに異なるファイルのコーパスを用いた推薦システムのケーススタディを示し、性能改善のための特徴量エンジニアリングのテクニックからパフォーマンス改善のためのインフラ整備までを示した。
決定木では対応が難しい、スパースかつ特徴量エンジニアリングが難しいような場合にもDNNは有効であるとしています。
今後は、ユーザーが最初にファイルを開いたときだけでなく最初のファイルを開いた後も考慮していったり、ユーザーの特徴量が少ないケースについても検討していくようです。
感想
久しぶりに推薦(？)の論文を読んでみた感じです。
肝になっている考え方としては、Latent Crossなのかなと思いました。 機会があればLatent Crossの論文も読んでみようと思いました。
