Netflix の事例から RecSysOps を学ぶ
Netflix は RecSys のトップランナーの1社であり，そこで行われているオペレーションに以前から興味があり気になっていた．そこで，2022年のテックブログで紹介された RecSysOps に関する取り組みからノウハウを学ぼうと思い，記事の内容を取り上げながら，所感を書いていく．
Large-Scale と書かれていますが，Netflix のような規模でなくても試せることは多いと感じる．
RecSysOps とは？それに必要な要素とは？
RecSysOps (= Recommender Systems Operations) という言葉はこのブログが初かなと思う．もちろんこういった言葉で表現されていないけど，各社推薦システムの運用を通して何かしらのプラクティスを持っているはず．
RecSysOps が何を指すかは，動画で以下のように述べられている．
RecSysOps: Lessons we learned while operating a large RecSys
多くのリクエストに応えたり，安定的に稼働させ続ける（可用性）推薦システムを運用する上で得られたプラクティスを RecSysOps として紹介してくれている．
この取り組みを行うことで，以下の点で役立ったと書かれている．
- Reduce our firefighting time
- Focus on innovations
- Build trust with our stakeholders
RecSysOps には4つの主要な取り組みがあり，
- Issue Detection
- Issue Prediction
- Issue Diagnosis
- Issue Resolution
これらを通して，Netflix のような大規模な推薦システムを健全に運用できているとのこと．
こういった取り組みは自分達が本来集中したいこと，また検証したいことだったりクリエイティブな活動に時間を割けるようにする上でも大事な取り組みだなと感じる．機械学習システムは本番環境に導入されてからが 本番 なので，最初は上手くいってても，時間が経過するにつれて綻びというか予期せぬこと・開発時には想像していなかった事象は平気で起きるので，これらを検知したり予測して，適切に対処していく活動は尊いなと感じる．
モニタリングして，検知できる状態にするまではよく行われるが，じゃあ検知した後にそれらが分析できる状態になっているか，Runbook のような形でオペレーション手順にまで落とし込めているか，これらができている会社はまだまだ多くない印象．
では，それぞれ4つのトピックを見て行く．
Issue Detection
RecSysOps における最初のフェーズで，「Issue Detection = 問題の検出」が最も重要な要素だと語られている．理由としては，これが後続ステップのトリガーとなるため，これが行われないと後続ステップは意味がない．
この取り組みとしては，3ステップ紹介されている．
ステップ1: 関連する分野から既知の全てのベストプラクティスを取り入れる
最初のステップとして，
The very first step is to incorporate all the known best practices from related disciplines.
「関連する分野から既知の全てのベストプラクティスを取り入れる」ということで，推薦システムの場合だと，ソフトウェアエンジニアリングと機械学習が含まれるため，DevOps と MLOps の両方のプラクティスを取り入れることが示されている．ここでも ML Test Score をチェックリストとして活用できるよと紹介されている．
本番環境で発生する問題は無数にある & 未知なる問題もあるため全てに対応することは難しいと感じるが，問題に気づくための取り組み・検出範囲を拡げるための教訓は先人の知恵から学ぶことができるので，こういったものをリサーチするのも必要だと感じる．
ステップ2: システムを自分たちの視点からエンドツーエンドで監視する
2番目のステップとして，
The second step is to monitor the system end-to-end from your perspective.
「システムを自分たちの視点からエンドツーエンドで監視する」ということで，大規模な推薦システムの場合，多くのチームが開発や運用に関わってくる．ML チームの視点から見ると，
- アップストリームチーム
- データを提供するチーム
- ダウンストリームチーム
- モデルを使用するチーム
がある．データチームや自分たちのモデルを使いたい別チームが社内に居るかもしれない．それぞれのチームが独自にモニタリングなどの監視をしているかもしれないが，そのチームの取り組みだけに頼らずに自分たちの視点からも必要な情報（入力と出力など）をモニタリングするのが良いと紹介されている．
この教訓は，ML Test Score の「Monitor 1: Dependency changes result in notification」でも似たようなことが述べられている．例えば，データチームや開発チームと連携して，スキーマ変更や保存されるデータが変わる場合は連携するようにオペレーションを整えるべきだったりが挙げられる．
データチームはデータ全体を見ているので，ML だけが使う一部のデータをどこまで感知しているかはわからないので，ML で使用するデータに関しては ML 側できちんと把握して必要なことは自分たちで率先して動くことが大事だと感じる．
他チームに任せるのではなく，オーナーシップを持って自分たちの範疇で取り組めることに関しては積極的に行っていく姿勢は素晴らしい！
ステップ3: ステークホルダーの懸念を理解する
3番目のステップとして，
The third step for getting a comprehensive coverage is to understand your stakeholders’ concerns.
「ステークホルダーの懸念を理解する」ということで，推薦システムの文脈では，主要な視点として，メンバー（ユーザー）とアイテムがある．この取り組みは問題の検出要素のカバー範囲を拡げるのに良いと書かれている．
メンバー（ユーザー）視点
提供している推薦モデルによって高く評価されていないアイテムを選択している場合，何かしらの潜在的な問題があるかもしれない．また，これは将来の優れたインスピレーションの源になるとも書かれている．
アイテム視点
Netflix の場合，アイテムに責任を持つチームはアイテムのコールドスタートと潜在的な本番バイアスに関する懸念を持っている．彼らの懸念に関してサポートするために，メトリクスの定義・モニタリングツールの提供だけでなく，問題がアイテムごとに発生しているかどうかについてのインサイトの提供などもしている．これらを通して，アイテムに関連する主要な問題に積極的に対処し，ステークホルダーとの信頼関係を構築していると書かれている．
Netflix のようなアイテムに責任を持つチームやカスタマーサクセス・サポートチームのようにユーザーのことを常に考えているステークホルダーの懸念や悩みをヒアリングしたり，サポートすることは自分たちが気づいていない新しい視点を提供してくれるので，とても参考になると日々の業務でも感じる．こういったチームからの要望などを元にモニタリングすべき項目を追加したり参考にしたりしているので，ホットラインを築いて協力していくことで問題に気づくことはあると思う．
Issue Prediction
2つ目のトピックは，「Issue Prediction = 問題の予測」で，問題が本番環境で起こる前に予測して修正することを紹介している．
Netflix では，アイテムのコールドスタート問題が重要なテーマになっている．この問題を過去のデータを使用して，ローンチ当日の本番モデルの行動統計を予測できるモデルを構築して予測しているとのことで，これによりアイテムのコールドスタートに関連する潜在的な問題を一週間以上前に検出し，問題を修正する時間を確保できているとのこと．
この取り組みは正直かなり難易度が高いと感じた．アイテムに関する事前の情報やメタデータを駆使しながら，類似アイテムとの関連性を見つけて予測するのが良いのかな？正直これに関するアイデアは現時点だとあまりない😅
Issue Diagnosis
3つ目のトピックは，「Issue Diagnosis = 問題の原因特定」で，3つステップに分けて取り組みを紹介している．
問題を分離して再現する
まず最初のステップとして，
the next phase is to find its root cause.
「問題を分離して再現すること」ということで，問題を再現するには事前に適切なログ設定を行う必要があると書かれている．これは何かしら問題がある場合に，単純にコードを再実行しても問題が再現できない状況があるということ．そのため，問題を理解するための再現に必要なログを出力しておくのが大事．ただし，コストを削減するためにトラフィックの一部に対してログの記録を行っているとのこと．この場合には，適切なスライスでカバレッジを満たせるサンプリング方法を設計する必要がある．
Netflix レベルになると，全部をロギングしておくとコストが尋常じゃないぐらい増えるので，こういった観点も必要になるんだなと感じた．ロギングは完全に同意で，問題の再現だけでなくモデル改善・分析観点でも必須である．
問題がMLモデルの入力またはモデル自体と関連しているかどうかを理解する
2つ目のステップとして，
The next step after reproducing the issue is to figure out if the issue is related to inputs of the ML model or the model itself.
「問題がMLモデルの入力またはモデル自体と関連しているかどうかを理解すること」ということで，入力データに関連しているかどうかは，入力が正確で有効であることを検証する必要があるので，非常に難しい問題とのこと．
これ難しい．データ全体でスケーリングしたりする処理を入れているとそのモデルも持っておかないとだし，ある特徴量を生成するのに別の特徴量を使っている場合は，その追跡やリネージュ関係を理解する必要があるので，より複雑な問題になりそう．そういったこともあり，データのバリデーションは大事な取り組みの1つになってくる．
MLモデルとその学習データの内部を詳しく調べて問題の根本原因を見つける
3つ目のステップとして，
the next step is to dig deep inside the ML model and its training data to find the root cause of the issue.
「MLモデルとその学習データの内部を詳しく調べて問題の根本原因を見つける」ということで，ここでは例えば，モデルを解釈するために SHAP / LIME などの可視化ツールを使ったり，決定気のノードやニューラルネットワークのレイヤーを可視化する方法などを述べている．
Issue Resolution
最後のトピックは，「Issue Resolution = 問題の解決」で，解決には短期的で緊急度が高いものから，長期的に取り組む必要があるものが考えられる．ML モデルは高度に最適化されているので，気軽に手動で変更することはできないし，しても適切な推薦を提供できない可能性が生じるということ．
ここでは，事前に緊急に解決すべきかどうかの選択肢やトレードオフを用意しておくというのが紹介されている．
- 検出または予測コンポーネントのチェックが定期的に自動実行されているか
- 人間の判断が必要な場合に，その人が必要な情報をすぐに手に入れるようになっているか
- Hotfix が必要な時に，デプロイを数クリックで簡単に適用することができるか
後半2つは非常に刺さる．例えば，データを集めるだけでなくすぐに使える状態に整理されているか，対応時のレポートラインやステークホルダーとの調整が事前にされているか，優先度の応じて対応できるようにオペレーションが確立されているかなど色々とありそうで，こういったことを事前に準備しておけると，いざその問題に直面した時に自分たちが楽になるし，変に焦る必要もなくなるので，動きやすいし信頼感もあるだろうな感じる．
RecSysOps という推薦システムに焦点を当てているが，これは別に推薦システム特有のものではなく，他の機械学習システムにおける MLOps として，適用できる話だと感じた．泥臭いオペレーションや関連するチームとの信頼関係を通して，日々の運用やサービスが安定稼働しているのを感じる．Issue Detection の3つのステップに全てが詰まってる．
機械学習の場合は，データ・コード・モデルの三大要素があるので，問題を検知していく上でこれらの「Versioning・Reproducibility・Monitoring」への取り組みはより必要だと改めて感じた．
参考
- RecSysOps: Best Practices for Operating a Large-Scale Recommender System