メモ：Using AntiPatterns to avoid MLOps Mistakes

論文
https://arxiv.org/pdf/2107.00079.pdf

概要

金融分野でのMLOpsアンチパターンをまとめた論文。
技術的な課題もあればMLの結果を使っている周辺のコンテキストが十分な知識を有していなかったことが原因となっている。
これらの状況を議論するに当たり共通のボキャブラリーを提供することで、ステークホルダー間の素早いコミュニケーション並びにより素早く問題を解決する。

ここでは9つのアンチパターンについて取り上げる。
f:id:A_Koide0519:20210810224536p:plain

アンチパターン

Data Leakage AntiPattern

データリークはモデルが本来持っていない、あるいはモデル生成時には利用できないデータを利用してしまうこと。
モデル作成時にモデルを過大評価してしまう可能性があり、そのまま本番提供すると想定よりも性能が全然出ないということが起こりする。
システムやデータの複雑さが時間的な依存を隠してしまいがち。

ユーザーの行動履歴をembeddingしたものを使ったりするとこういう問題が発生しそうな感じがする。

Peek-a-Boo AntiPattern

データが実際に取得できるまでタイムラグが有る場合がある。
例えば、月の労働時間は当該月が終わって次の月にならないとわからない情報。
モデラーがこのデータの日付と実際にデータを受け取れる日付の違いを理解しないと想定しないデータをモデルに含めてしまうかも。

Temporal Leakage AntiPattern

トレーニングとテストのデータセット分割の際に、サンプリングの方法を誤ってしまうとリークが発生する。
特に予測問題では、連続性があるデータの分割の仕方を誤るとリークが起こってしまう可能性がある。

Oversampling Leakage AntiPattern.

不均衡データにおいてOverSamplingはよく用いられる手法だが、TrainとTestの前にOverSamplingを実施してしまうとリークが発生する可能性がある。銀行の解約予測を事例にリークが起きていることを説明する。
f:id:A_Koide0519:20210812195057p:plain

この図を見ると(a)の方のOverSamplingしたあとにデータを分割した方は楽観的な性能を示しているが、これはOversamplingのタイミングがTestデータを作る前に行われたことが原因であると考えられる。

Metrics-from-Beyond AntiPattern

データの前処理の段階でTrainデータとTestデータを合わせて正規化などをしてしまうことにより、Testデータの統計的な性質がリークしてしまう可能性がある。

‘Act Now, Reflect Never’ AntiPattern

一度モデルが本番にDeployされると、予測はフィルタリング、更新、反映、定期的な調査も行われないまま現状維持で利用されることがある。
こういったことがコンセプトドリフト、誤った予測結果の提供、敵対的攻撃を引き起こしてしまう。
※コンセプトドリフト：入力データと予測結果の関係が変化した状態. 古いデータに基づいて構築されたモデルが新しいデータと矛盾した状態.
デプロイしたモデルに対してのモニタリングやデバックの仕組みを用意する必要がある。

Tuning-under-the-Carpet AntiPattern

ハイパーパラメータはモデルのパフォーマンスにおいて重要な役割を果たす。実際の例として退会予測のタスクにおいてXGBのハイパラチューニングをした結果としない結果を示す。
f:id:A_Koide0519:20210813165259p:plain
F1スコアが3.5%程度改善していることからも、チューニングは重要であることがわかる。
ハイパーパラメータの最適化に関わる学習パイプラインの部分は、再現性があり容易に適応できるように、明示的かつ丹念に文書化することが必要。

‘PEST’ AntiPattern

新しいML分野の研究が提案される時、主要なコントリビューションは下記に寄って示される。
i)これまで検証されていなかった理論的提案
ii)新しい理論的な提案と経験的な検証の組み合わせ
iii)既存の学習パイプラインを効果的に補強し、パフォーマンスを向上される
経験的検証を行うには、提案手法を過去のアプローチと比較して公正に評価し経験的な性能を評価する必要がある。しかし新たに提案されたML手法の経験的な検証が不十分であったり、欠陥があったり、あるいは期待外れであったりすることはよくある。
こういったケースでは、報告された経験的な利益は経験的優位性の認識 (PEST) antipatternが発生しているということになる。
対策として、まずはシンプルなモデルでBaselineを作ってそこからより高度なモデルの調査をしていく、あるいはSQuADのようなベンチマークのデータセットに対してモデルを検証するパイプラインを構築するといったことが挙げられる。

個人的にこの話で思い出すのはRecSys2019のBestPaperだった下記の論文。
https://arxiv.org/pdf/1907.06902.pdf

Bad Credit Assignment AntiPattern

モデルが改善したときに、MLパイプライン全体のどこに性能向上の要因があったのか特定できない問題が頻繁に起きる。
研究領域においては改善は新しいアーキテクチャによるものであると言われることが多いが、実際には巧妙な問題設定、データの前処理、ハイパラチューニング、既存ロジックを新しいタスクに適用したといったことで性能向上することがほとんど。
こういったことを防ぐために、ablation studyによって新しい学習モデルのどの部分に優位性があったのかを経験的な評価の中に含める必要がある。

Grade-your-own-Exam AntiPattern

ここの章はあまりよくわからなかったが...

モデリングは潜在的な威力を探るために好奇心に駆られた反復作業から始まる。このタイミングでは3rd-partyからのレビューなどは必要ないが、この状況が長く続くと検証を行わず、検証されていない結果を他の方法と比較することができない。
これを避けるために、テストと評価のデータは独立してサンプリングされるべきで、堅牢なパフォーマンス分析のためには、モデル開発が完了するまで隠しておき、最終的な評価にのみ使用する必要がある。
実際には、サイエンティストが最終的なテストセットを入手し、このテストセットに対してテストを繰り返すことで、テストセットでのパフォーマンスを向上させるようにモデルを修正してしまう。
これは暗幕的なデータのリークに繋がり、パフォーマンス評価での過学習が選択バイアスにつながる。
これはHARKing「Hypothesizing After Results are Known」(結果が判明したあとに仮説を作る)と呼ばれている。

Set & Forget AntiPattern

モデルのトレーニングと推論にはSet and Forgetの考えが適用されることが主流となっている。しかし、モデルが予測するターゲットの統計的な特徴が時間とともに変化することが頻繁に発生する(concept drift)。
concept driftの対策方法については下記のサイトに良くまとまっていたので勉強になった。
recruit.gmo.jp

モデルをdailyなどで定期的にTrainingしている場合にはForgettingをしている状態と言って問題ないのだろうか。

‘Communicate with Ambivalence’ AntiPattern

モデル自身の不確実性に関する情報についてほとんど注意が払われていない状態。
校正されていないモデルを本番に投入すると、何かあったときに補償や改善のためのパイプラインを導入することが難しくなるので、Brier Score（またはそれに準ずるもの）で注意深くキャリブレーションされているモデルを投入する必要がある。

rindalog.blogspot.com

‘Data Crisis as a Service’ AntiPattern

データの抽出手順を記録せずに手動で抽出したデータを使ってモデルを開発すると、後々モデルを検証したり展開する際にデータの準備に非常に時間がかかる。
センシティブなデータなどで外部のデータ提供者がサニタイズしたりするとこういったことが起こりやすい。
対応として以下のようなものがあげられる。
・専門的なデータエンジニアリングプラクティスの用意
・パイプライン上移動するデータの追跡
・仲介業者を含むすべてのデータプロダクトの系統の追跡

Rabbit Holes and Taste Distortion: Distribution-Aware Recommendation with Evolving Interests(WWW2021)

論文

論文
http://people.tamu.edu/~zhaoxing623/publications/WWW21-Final-Publication.pdf

概要

既存のレコメンドロジックとしてよくあるユーザーの過去の嗜好を元にしたレコメンドは、ユーザーの嗜好が基本的に固定であることが前提となっている。
この論文では、こういった前提によって起こる味覚の歪み(本来ユーザーが持つ嗜好とレコメンド側で認識しているユーザーの嗜好が異なっていることを言っていると思われる）をまずデータから明らかにする。
その上でユーザーの好みがどのように動的に変化し、その変化を考慮したキャリブレーションメカニズムを設計する必要性を示す。

どういう問題

MovieLensのデータセットからランダムに抽出したあるユーザーに対して、

  • Trainに利用するデータにおけるユーザーの嗜好の分布
  • BPRが予測したユーザーの嗜好の分布
  • xQuAD(Diversityを加味したレコメンドモデル)が予測したユーザーの嗜好の分布
  • Testデータにおける実際のユーザーの嗜好の分布

のそれぞれを可視化する。

f:id:A_Koide0519:20210721212227p:plain

これを見ると、まずTrainとTestでのユーザーの嗜好の分布は全く異なる傾向を持っている。
特にBPRはTrain時の傾向に引っ張られるので予測結果も似たような傾向を持っている。
また、Diversityを加味することでこの問題は緩和しているようにも見えるが、あくまでも多くのユーザーの嗜好をカバーすることが目的となっているので、実際の嗜好に近づいたものを出せているわけではない。

システム的には頻度高く再学習をすることでこの問題に対処することができるかもしれないが、モデルとしてこの問題にアプローチするのが目的。

最終的に求めたいのは、

  • あるユーザーに対するTopKレコメンド
  • あるユーザーに対するTopKレコメンドのアイテムのジャンルの分布

データを実際に見てみる

分布の変化

学習データにおけるジャンル単位の嗜好の分布と、テストデータ、BPRの結果、CaliRec*1という先行研究にてCalibrationを加味した手法それぞれで観測されるジャンル単位の嗜好の分布感のKL-Divergence(以降KL)を取った結果が下記になる。
なおCaliRecの設定はベースのモデルがBPRで、Calibrationを調整するパラメータはCalibrationを強く効かせるように設定している。
この既存手法のほうは、BPRによって計算されたレコメンドにたいして、Trainデータの各ユーザーの視聴履歴から作られるジャンル分布により近づけるようにCalibrationするものになっている。
f:id:A_Koide0519:20210722164258p:plain
結果を見ると、まずTrainデータとTestデータ間のKLの値は非常に大きくなっており、傾向が大きく異なることがわかる。
BPRやCaliRecについてはTrainデータの傾向を強く反映しているのでKLのあたりが非常に小さくなっている。特にTrainデータの傾向に合わせるようにCalibrationされたCaliRecはその傾向が強い。
同様にTestデータに対して同じような比較をするとKLの値はどれも大きくなる。
結局の所、このアプローチでは性能を出すことが難しいと考えられる。

ケーススタディ

実際にランダムに抽出したユーザーの視聴の傾向の変化を見てみる。
このユーザーだとミステリー->サイエンスフィクション->コメディ->ロマンス->戦争->ドラマ->ホラーと嗜好が変化しているのがわかる。
f:id:A_Koide0519:20210722165148p:plain

Taste-Enhanced calibrated Recommendation(TecRec)

先行研究のCaliRecと同様に、BPRなど何らかのロジックで算出されたレコメンド結果(accuracy term)に対してCalibration(calibration term)し、TopK件のレコメンドを返却する。

嗜好分布の学習

過去z分のTrainの嗜好の分布を入力とし、現時点の嗜好の分布を予測する。
f:id:A_Koide0519:20210722172700p:plain
Lossはユーザーに対する時刻t時点で予測した嗜好の分布q_{u,t}と真の嗜好の分布q^_{u,t}のKLを用いる。
f:id:A_Koide0519:20210722174224p:plain
最終的な目的関数は下記となり、これを最小化する重みを求める。
f:id:A_Koide0519:20210722180236p:plain
ここで予測した嗜好の分布q_{u,t}を次のフェーズで利用する。

ランキング

Post-rankingという方法でアイテムの並び替えをする。
f:id:A_Koide0519:20210722180952p:plain

候補のアイテム（ここではすべてを候補とせず、計算コストを削減するためにスコア上位Zのアイテムだけをターゲットにする。この値はこの研究ではジャンル数の30倍で設定している。）に対して、accuracy termでは、何らかのモデルによって算出されたスコアのsumを取り、calibration termでは先述の学習で算出された予測した嗜好の分布q_{u,t}と、現状のレコメンドリストと候補アイテムのジャンルの分布ベクトルをsumしたものとのKLを取る。
この２つの結果を重み付け線形和としてこの値が最大になるアイテムiをリランキングしたレコメンドアイテムとして追加する。重みλは大きくなるほどcalibrationが作用する。

評価

嗜好の変化に追従できているか

比較として下記のデータ、モデルで得られる嗜好の分布、並びに提案手法の嗜好の分布に対する真の嗜好の分布とのKLを取った結果。

  • allTrain：Trainデータのすべてから嗜好の分布を算出したもの
  • lastTrain：Trainデータの最後のtime windowで算出された嗜好の分布
  • BPR：Accuracy-driven recommender
  • SASRec：sequential recommender
  • xQuAD, SPAD：diversity-focused recommender

BPR以下のものについてはレコメンド結果上位10件のアイテムからジャンルの分布を算出して比較する。
f:id:A_Koide0519:20210722184732p:plain

提案したTecRecはKLが他に比べて小さくなっており、Testデータでのユーザーの嗜好の分布により近いレコメンドを出すことができていると言えそう。
ただし、実際にユーザーの好みのものが出せているかはこれではわからないので、レコメンドそのものの性能も確認する。

レコメンドが改善しているか

BPRとSASRecをaccuracy termとして用いたTecRecの性能が良くなっているかをCaliRecと比較して確認する。
指標はRecall@KとNDCG@Kを用いた。
※ここではこの２つのモデルを使っているが、Post-rankingの方法がこのモデルに限らず利用できる
f:id:A_Koide0519:20210722184736p:plain
どちらのモデル並びにどちらの評価指標においても既存の手法を上回る結果が得られている。
評価指標によって最適なλの値微妙に違ったりするが、0.5くらいが良さそうに見える。

ところでこの結果を見ると先行研究の一つのCaliRecの方はλ=0がオフライン上では一番いい結果にみえていてなんのための比較なのか色々とよくわからなくなってしまった。
元論文のほうを確認した感じでは、そもそも性能の議論をしているわけじゃなくて、例えばユーザーが薄く関心を持っているジャンルの情報が、acuuracyベースのモデルだと潰されてしまって強い関心のあるものばかりレコメンドしてしまうので、それを防ぐためにTrainデータ内の視聴履歴から作られる嗜好の分布を加味してレコメンド結果をCalibrationするという感じのようなので比較の意味があまりないような気もする。

なお、SASRecのほうが改善幅が小さいのはSASRecにはすでにシーケンシャルな情報が部分的に入っているからではないかと考察されている。

*1:https://dl.acm.org/doi/pdf/10.1145/3240323.3240372

MLOps理解したい

機械学習

MLOpsという単語を聞かない日はないくらいだけど、世の中にMLOpsのためのツールが溢れているせいかツール使っていればMLOpsしているみたいな気持ちになってしまっている。

結局何ができていればMLOpsができていると言えるのか理解しておきたい。

AIエンジニアのための機械学習システムデザインパターンでは以下のようにMLOpsが定義されている。
www.shoeisha.co.jp

昨今のソフトウェアエンジニアリングではクラウドとWeb技術の発展により、システムの開発と運用を同一のライフサイクル、同一のチームで実施し、高速に開発とフィードバックループ（ユーザからプロダクトの使い心地や意見を得て、改善に繋げるプロセスを繰り返すこと）を回す文化やツール、開発プロセスとしてDevOps（DevelopmentとOperationsを繋げた略語。「デブオプス」と読む）が誕生し、盛んに用いられています。DevOpsでは開発チームと運用チームを統合し、全員がプロダクトのEndtoEndに責任を持ちます。継続的インテグレーション（CI=ContinuousIntegration）や継続的デリバリー（CD=ContinuousDelivery）を維持し、フィードバックループを回すことでプロダクトの修正を行います。特にWebやスマホアプリ業界では、ユーザが直接使うアプリケーションを提供するため、ユーザのアプリケーション内での行動やフィードバック、障害をもとに自社プロダクトの修正、更新をスピーディに実行することが求められます。修正や更新されないアプリケーションは使われなくなると言っても良いくらい、変化の激しいビジネスになっています。こうしたDevOpsで用いられるプラクティスを機械学習に適用したのがMLOps（MachineLearningとOperationsを繋げた略語。「エムエルオプス」と読む）です。

澁井 雄介. AIエンジニアのための機械学習システムデザインパターン

ということでMLOps=DevOps+ML(継続的なトレーニング)と考えて良さそう。

なのでまずはDevOpsの考え方を理解しておきたい。
そこで以下の本を読む。
www.nikkeibp.co.jp

この書籍を読んで自分としてDevOpsは結局どんなものなのかを言葉にすると以下のような感じ。

  • 顧客の要望を達成するための一連の作業(書籍内ではITバリューストリームと呼んでいる)のリードタイムを短くすること、そのために仕事のバッチサイズを小さくすること
  • 改善のカタを作り上げるために、慣習的に日々業務改善を実践すること

上記を達成するための3の原則として

  1. 開発->運用->顧客の流れを高速にすること。そのために仕事の可視化、作業のバッチサイズ、作業間インターバルを削減する。また、作業の品質を高めて下流に不良品を渡さないこと。
  2. 運用->開発への素早いフィードバックフローを構築すること。問題解決のためのフィードバックを最重要視すること。
  3. 実験とリスクテイク(リスク受容)によって得られる成功と失敗から学習・改善ができる組織文化を構築すること

これにMLが入ってきたとしても考え方に大きな違いはないように思う。

  • モデリングを担当するDSがオフラインでの検証を回すためにほか作業に影響されない環境を作ること
  • 作られたモデルをアプライドするエンジニアが、DSに依存せずに機能改善を行えること
  • システムに以上があった際に、エンジニア側からDSに高速にFBができ、DSがも即時に対応できること
  • オフラインからオンラインへの壁を取り除き、高速な実験とFBが受けられる環境を作ること

などなど...

この解釈のもとで昨今のMLOpsを果たすための各種ソフトウェアなどを見ていくと、道具としては多少の違いはあっても必要なものは揃っている状況にあると思う。
ただ、道具を入れただけだと本来DevOpsによって達成されるべきものが完全には果たされない印象もある。

  • DSとエンジニアが互いの状況を把握しておらず、作業間インターバルが多く発生する
  • まともにテストがされていないモデルがデプロイされ、運用負荷が増大するというDSとエンジニアのテストへの意識の違い（ロールバックを素早く行える環境を作ることでカバーすることもできるかもしれないが、いずれにしてもプロダクションに入れるタイミングではテストが徹底されている必要はある）
  • うまく行かなかったことを組織内で共有・改善に繋げられる組織風土

このあたりを意識しながらMLOpsを推進していかないと道具だけ入ってできた気になってしまいそう。

自分が関与しているところでは前提となるDevOpsや取り組みに対する組織的な理解が追いついていない感じもあるので、このあたりを意識できるような働きかけを意識していけると良さそう（難しそうだが）。

GWに読んだ本

読書

意識の低さにより目標を大きく下回り2冊

www.amazon.co.jp
もともと自分が研究領域にしていた分野の関連書籍で当時共同研究していた先生が著者に入っていることもあり購入。
構成としては計算社会科学に関連する分野（ネットワーク分析や自然言語処理など）を各章ごとにまとめている感じなので、過去にあまりやったことがなかったテキスト分析や統計モデリングなどをかいつまんで読ませてもらった。
自分にとってはこの学問のいろいろなアプローチを学べて得るものはそれなりにあったが、入門書として人に薦めるかと言われると誰に薦めていいか悩む内容な気がする。

研究者・学生向けにはちょっと各章の内容が広く薄すぎる感じがして、一方で社会人が読書として読むには学問的すぎる感じがする。
計算社会科学で研究対象としている現象（情報拡散とか意見形成とか）単位で章立てして、各章の中でどういう技術を使ってその現象を説明するかみたいな形の方が大衆受けしそうな感じがした。

いずれにしても自分にとっては価値があったので問題ない。


www.amazon.co.jp

金融関連の仕事をすることがあるので他社事例として読んでみた。

各金融関連の事例について、アリババ、アントの考え方が具体的に書かれていて、かなり参考になる内容だった。
「脱I(IBM)O(オラクル)E(EMC)」という概念の話は面白いし、自分たちで決済のDBをちゃんと研究開発できている、製作者にはCEO自らが勲章を与えているというところは技術の会社として優れているなと思った。
やっぱり事業の要になるシステムは外注してはいけないんだよなぁ...

そのほかにも随所に彼らがプラットフォーマーとしてECや金融事業を運営しようと考えていること、徹底的にテクノロジーで物事の解決を図っていること、ユーザーへの価値の提供が全てであること（そのために短期的なKPIを無視できること）などが書かれていて、会社としての考え方が徹底されているなと感じられた。
※もちろん実際そうかはわからないが

普通に読み物として誰が読んでも得られるものがありそうな内容になはっている。

PFNの講座をやった

勉強

こちらのサイトでPFNが提供しているDeepLearningの基礎講座をいくつかやりました。
quest.signate.jp

数学ガバガバの自分としては数学基礎とディープラーニング入門は紙とペンで実際に解きながら理解を深められたのでいい教材だったと思います。
数Ⅲ+Cあたりから怪しい人にはいい難易度。

ただ内容としては下記の講座の資料の簡易版という感じなので、本当に何もわからない人でなければ下記の講座の内容を普通にこなした方が良さそう。
japan-medical-ai.github.io

KDD2020で気になった論文を読む その2

論文

PinnerSage: Multi-Modal User Embedding Framework for

Recommendations at Pinterest
https://arxiv.org/pdf/2007.03634.pdf
以降文中の画像は論文中からの引用になります。

概要

多様なembeddingsを介してユーザーを表現し、それを活用して高品質なレコメンドを提供するPinterest独自の推薦システムであるPinnerSageの紹介とそのロジックについて。
作り方としては、階層的なクラスタリング手法によってユーザー行動をまとまったクラスタにし、代表的なpin(テキスト付きの画像)を介して効率的かつ解釈性をもってクラスタをまとめあげる。
このロジックにより単体のEmbedding手法よりもA/Bテストで良い結果を得られた。

pinterestのレコメンドシステムと課題

下記のような多様な目的それぞれに対して異なった最適化アルゴリズムが適用される。
(a)TopPageのPinレコメンド。Feed型で無限スクロールされる
(b)3rd partyのe-commerceサイトに飛ばすショッピングのレコメンド
(c)パーソナライズ検索
(d)パーソナライズ広告
(e)パーソナライズpinボードレコメンド
など
数百万ユーザーに対して十億オーダーのアイテムからパーソナライズされたレコメンドを提供するにあたっては「いかに効率的にユーザーの複数のfacetをエンコードするか」になる。
例えば、人の関心は短期的な物もあれば長期に渡る物もあったりするので、そういった興味関心の進化に対応するためには、単一の高次元EmbeddingVectorではなく、Multi-Embeddingなモデルが必要であると考えている。
しかし、このアプローチはまだ適用が少なく、以下の課題に対しては完全には議論されていない。

  • ユーザーに対してどれくらいのEmbeddingが必要か
  • 何億人ものユーザーに対してどう推論を回し、embeddingsを更新するのか
  • パーソナライズレコメンドを生成するためにどのようにembeddingを選択するか
  • 本番環境でMulti-Embeddingsモデルが通用するか

デザイン選択

  • pinのembeddinsは固定

ユーザーとアイテムのembeddingsを同時に学習するアプローチが先行研究としてあるが、この方法はモデルが複雑になり、推論に時間がかかるためリアルタイム推論には不向き。
また、複数のトピックに関する興味があった時に、それを近くにするように学習するのは実は避けたいことで、あくまでもPinの類似性を保持した状態にしたい。

  • embeddingの数に制約を入れない

これにより、ユーザーの理解に制限が入るし、最悪ことなる概念を統合してしまうことで悪いレコメンドになってしまう。
これを、ユーザーの行動を階層的凝集型クラスタリングアルゴリズムを用いることで解決する。

centroidよりも外れ値に強いmedoidsを使う。また、medoidsでは対象のpinが代表になるので、pinのidをキャッシュしていればクロスユーザー、クロスアプリケーションで共有できる。

  • 候補探索時のmedoidsサンプリング

コストを抑えるためと、ユーザーが過剰にアイテムを浴びせられるのを防ぐ。

  • リアルタイム更新のための二本立てのアプローチ

ユーザーの直近のニーズに対応することも大事だし、同時に60-90日のアクティビティに基づいた正確なレコメンドも大事。
これを一つの仕組みで対応するのは難しいので、長期的な情報に基づいた推論はdailyのバッチ推論で対応し、オンライン推論では直近の日にちの情報に対応する。

  • 近似近傍探索

任意のmodoids(pin)をクエリとして与えると、近傍のk個のpinを取得する。

アプローチ

pinのembeddingsの作成ロジックは下記のGNNベースの物を利用している。
[1806.01973] Graph Convolutional Neural Networks for Web-Scale Recommender Systems
ゴールはそれぞれのユーザーに対して複数のembeddingsを推論すること。
先行調査として、ユーザーが次にアクションするピンのembeddingsに対してどのようにユーザーのembeddingsを作ると関連した物を用意できるか検証した。
直近の履歴1件を利用するのに対して、全ての履歴から近傍を選ぶのがもっとも性能がいいが、これは全てのデータを保持するのでシステム的に負荷が高い。一方でこれを3-meansでクラスタリングしたcentroidのembeddingsものから近傍を出すと、性能はやや劣化するもののある程度いいものがだせそうかつ、実システムに適用が可能になりそうだった。
ユーザーのpinするアイテムは複数の興味からなっているので、履歴から複数のembeddingsを生成しレコメンドすることに意味がありそう。
Stepとしては

  • ユーザーの直近90日のアクションを少量のクラスタにする

Ward方を用いて階層的クラスタリングを行う

  • それぞれのクラスタに対して、medoidベースの表現を計算

クラスタ内のpinの中で他のpinとの距離が最小となるpinをmedoidとして選出

  • ユーザーに対して、それぞれのクラスタの重要度を計算

クラスタの重要度をクラスタないのpinのアクションがあった時刻を用いた平均時間遅れでスコアリングする。

システム概要

f:id:A_Koide0519:20210101183801p:plain

ANN検索

Pixieという自社の候補検索のフレームワークがある。
下記の工夫でレイテンシなどのコスト削減。

  • インデックス作成方法の検証
  • 候補となるindexの削減

重複削除、画像が大半をしめるような低品質のpinなど

  • medoidを利用することでcacheする内容をembeddingsではなくpinのidにする
サービング

先述したとおり、長期的な情報に基づいた推論はdailyのバッチ推論で対応し、オンライン推論では直近の日にちの情報に対応する。

  • バッチ推論

過去90日のアクションをもとにdailyで推論を実施。medoidとそれに付随するimportanceをlistとしてKVSに格納。

  • オンライン推論

直近20個のアクションをオンラインの推論で用いる。

実験

実際にクラスタを確認すると、ユーザーの複数の興味をうまく分割できている。
また、レコメンドの結果ももっとも関心のあるであろう上位3トピックに関連するpinをレコメンドできている。
オンラインの実験により、baselineの単体のembeddingモデル(アクションを起こしたpinのembeddingを時間遅れで重み付けした平均)と比較して、アクション全体の数、並びにユーザーごとのアクションの数が増加した。
オフラインでも単一のEmbeddingsを使う手法としてLSTM、GRU、HierTCNなど、multi embeddingsとしてはクラスタリングアルゴリズム、embeddingsの手法、クラスタの重要度を決めるためのパラメータの設定などをいくつか検証している。
少なくとも単一のEmbeddingsを使うロジックよりもmulti embeddingsの手法の方が大きく性能が改善している。

所感

前回のGoogle同様Pinterestも数年にわたって推薦関連の論文を投稿し続けていて、進化がわかるようになっている。
システム周りの工夫がしっかりと書かれているので実運用のイメージが持ちやすかったような気がする。
ランキングの仕方があまり言及されていなかったのでよくわからなかった。関連論文読み直せってことですね。
課題感とかアプローチは納得感があった。
どうでもいいが後半明らかに読み疲れた。。

KDD2020で気になった論文を読む その1

論文

冬休みのノルマとして2本しっかりじゃなくてもいいので読んでおく。

Improving Recommendation Quality in Google Drive

https://storage.googleapis.com/pub-tools-public-publication-data/pdf/8b3a830b943f7b3e16d51963f9e7aadd51b84960.pdf

概要

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.様々な特徴量の有無にばらつきがあり、特定の候補アイテムで特定の特徴量が欠ける

servingのレイテンシ最適化

レコメの結果をまってレンダリングを追えるようにすると全体の表示時間がかかる。
ユーザーの訪問と同時にレコメンドへのリクエストを行い、予測結果を流すようにインフラを変更。
また、ページのレンダリングが終わった後に別途レコメンドの結果を注入できるようにした。
これによって50%tileで18.5%のレイテンシが改善した。
また、CTRも5%程度向上した。

メトリクス

ここでは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