はじめに
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
