【読書】Introducing MLOps
O'Reilly Mediaから出版されている、「Introducing MLOps: How to Scale Machine Learning in the Enterprise」の読書メモ。
ちなみにkindle本として買ったものをiPadで読んでいたのですが、アプリ中から選択箇所の翻訳機能を利用できて便利でした。
読み終わった感想としては、MLOpsサイクルにおけるデータサイエンティストやドメイン専門家（原文だとsubject matter expert）が関係や、データやモデルのガバナンスの重要性など原理原則的な話が多く、ツールやデザインパターンなどといった技術的な内容は控えめだった。
ここでは備忘録も兼ねて各章の内容を簡単にメモとして残す。
MLOps What and Why
1. Why Now and Challenges
サービス上で機械学習を活用するのが難しい理由は、データの性質やビジネス要件が時間と共に変化するからである。また、データサイエンティスト以外に、データエンジニアやドメイン専門家では背景知識や技術スタックに違いがあることなどが挙げられる。
機械学習を導入する際に伴いリスクとしては、モデルにアクセスできなくなるリスク、悪い予測を返すことによるリスク、保守スキルが失われるリスクなど様々なものが考えられる。実際には、発生の頻度と発生時の影響の二つを主に考慮して対策を考える必要がある。
Responsible AIの文脈では、Intentionality（モデルが意図した通りに動作していることの保証）とAccountability（モデルがどのようなデータでどのように学習されたか、などのプロセスに関する情報を把握すること）が重要である。
MLOpsはリスク管理だけでなく、スケーラビリティのためにも重要である。たくさんのモデルを運用する上では、各モデルやデータのバージョニングを行い、モデルの性能が悪化していないかをシステマティックに管理することが重要となる。
このようにMLOpsはデータサイエンティストのみではなく、組織レベルで取り組むべき内容である。これは各スタッフだけでなく、CxOクラスの人間も責任を持つ必要があるということを意味する。
2. People of MLOps
MLOpsに各ロールのスタッフがどのように関わるかを考える。
- ドメイン専門家：ビジネスKPIを明確化し、MLモデルの振る舞いとの整合性に責任を負う
- データサイエンティスト：ビジネス専門家と協力しながら、MLモデルを構築する。またモデルのパッケージングやテスト、予測性能の監視方法などを設計する
- データエンジニア：MLモデルを駆動するデータパイプラインを整備、管理する。
- ソフトウェアエンジニア：MLモデルをソフトウェアに組み込み、バージョニングや自動テストを管理する
- DevOps：サービス全体のCI/CDやセキュリティ、可用性の管理を行い、MLOpsを大枠のDevOpsに統合する
- モデルリスクマネージャー：プロダクション環境で稼働するMLモデルのリスクを認識し、レポーティングなどを管理する
- 機械学習アーキテクト：MLモデル運用のパイプラインやインフラを設計、開発、監視する。
これらの各スタッフが協力することは、機械学習による利益を得るだけでなく、ビジネスをリスクから保護するためにも重要となる。
3. Key MLOps Features
MLOpsを構成する要素として、以下の5つに触れている。
- モデル開発：
- Productionalizeとデプロイ
- モニタリング
- 反復
- ガバナンス
モデル開発の段階では、ビジネス目標を定め、データの内容を確認するところから始める。データの各要素が推論時に利用できるか、どれくらいの頻度で更新されるかを意識した上でモデルを開発することが必要となる。そして学習・評価、再現性を管理する。またResponsible AIの観点からは、各変数が予測にどのように影響しているのかなどを検証することも重要となる。
MLモデルの影響が小さい場合には、デプロイに伴うコストは比較的小さい。一方でMLモデルの振る舞いがミッションクリティカルな場合には、デプロイされるコードや付随するドキュメント、モデルの説明性、アプリケーション全体との統合テストなど、入念なCI/CDが必要となる。
モニタリングでは、スタッフのロールごとに異なる点が注目される。DevOpsチームとしてはモデルがジョブを十分に処理できているか、マシンリソースは逼迫していないかが気になる。データサイエンティストはモデルの精度の変化が気になる。これに対してはなんとか運用時の予測に対する正解ラベルを収集・検証する他に、データのドリフトを検知するアプローチも存在する。一方でビジネス観点からは、モデルの予測がサービスの価値に貢献しているか、運用コストを上回る利益が得られているかが関心の的になる。
MLOpsライフサイクルの上では、継続的にモデルを開発していくことになる。ここでは新しいモデルと運用されているモデルをA/Bテストやシャドーテストによって比較することが必要となる。
ガバナンスの観点からは、MLOpsライフサイクルが経済的、法的、倫理的に問題ないかを検討する必要がある。MLOpsにおけるガバナンスは、データに対するものととプロセスに対するものに大別される。データガバナンスでは、そのデータがどこからどのような要件で得られたのか、プライバシーに抵触していないかなどが焦点となる。プロセスガバナンスでは、モデルが適切な検証を経てデプロイされているか、MLOpsサイクルに対する外部監査などがレビューの実施が重要となる。
MLOps: How
4. Development Models
MLモデルの開発にあたっては、学習・検証データの収集、評価指標の設計、アルゴリズムの選定などが必要となる。アルゴリズムは精度だけでなく、速度やサイズなどの業務要件や、説明性の必要性など多くの観点から選ぶ必要がある。評価時には単純なホールドアウトセットに対する評価の他に、クロスバリデーションも有用となる。
MLOpsサイクルとしては、モデルのバージョンと再現性の管理も重要である。モデルを構築した際の仮定や、ランダムネス、実装、実験環境などを保持しておくことで、問題が発生した時の原因追及が容易になる。
5. Preparing for Production
プロダクションへの準備にあたっては、実行環境やモデルのリスク管理、品質保証などが必要になる。事前に構築したモデルが、TensorFlow ServingやKubernetesなどといった一般的な環境で載せられる場合もあれば、なんらかの制約（推論速度やメモリなど）を受けた環境へデプロイしなければならない場合も考えられる。どちらにしても、できるだけプロダクションに近い環境でモデルの検証作業を行うことが重要となる。
MLモデルの運用に付随するリスクを評価する際には、モデルの予測が悪化した際にどのような影響があるか、悪意のあるユーザーが学習データやモデルのロジックにアクセスできないか、経済的、法的、安全面など懸念はないか、などが注目点としてあげられる。これらのリスクの要因としては、学習や評価時のバグ、敵対的攻撃、データ内のバイアスなどがあげられる。特に、サービスの環境変化が速かったり、システム内におけるモデルの処理が複雑な場合には、こうしたリスクが増大しやすい。
こうしたモデルのリスクを抑えるためには、モデルの再現性の確保と監査性（auditability）が重要となる。モデルがauditableであるとは、モデルのドキュメントや学習時・評価時のメタデータ、ログやモニタリングなど関連する情報が整理され、いつでも確認できることを指す。
MLOpsサイクルでは、モデルを開発する段階から、こうしたプロダクション上の制約や運用時のリスクを念頭におくことが重要である。
6. Deploying to Production
プロダクションへデプロイする際には、CI/CDパイプラインの設計、モデルアーティファクトの生成やスケーリングのためのコンテナ化などを検討することになる。手続きとしては以下のが一例となる
- モデル構築：モデルアーティファクトの生成、基本テスト、公平性や説明性のレポート生成
- テスト環境へのデプロイ：モデルの性能や推論速度などの検証テスト
- プロダクション環境へのデプロイ：カナリアリリース、全体へのデプロイ
ここでのモデルアーティファクトとは、モデルや前処理のコード、ハイパーパラメータなどの設定、実行時の核依存関係のバージョンやドキュメントを指す。これらは後から確認できるように、ストレージに格納しておく。
モデルをプロダクション環境へデプロイする際には、環境全体を変更するのではなく、ブルー・グリーンデプロイやカナリアリリースによって、デプロイの影響を評価しながら移行することが有用となる。またデプロイ後の監視としては、大まかにリソースの使用状況や各サービスのヘルスチェック、MLメトリックのモニタリングがあげられる。
コンテナを利用することで、MLモデルに用いたライブラリの依存関係や実行環境を効果的に管理・運用することができる。一方でたくさんのモデルを並列して開発、デプロイする際には、自動化とガバナンスのコストが増大しやすいということに注意する必要がある。NetflixはSpinnakerという大規模なパイプライン管理のツールを開発して運用している。
デプロイはMLOpsサイクルの中での重要なプロセスである。従来のCI/CDに関するベストプラクティスの多くはMLOpsサイクルにおいても役立つと考えられる。
7. Monitoring and Feedback Loop
MLモデルをデプロイした後には、モデルの予測性能の劣化やデータの変化を検知し、フィードバックループにつなげる必要がある。
MLOpsにおけるモニタリングは、リソースに関するものとパフォーマンスに関するものが考えられるが、本章で特に取り上げるのは後者である。モデルのパフォーマンスモニタリングは、再学習のトリガーとなる。どの程度の頻度でモデルを再学習すべきかは、データの安定性やコスト、許容される予測性能など多くの要素から検討する必要がある。
モデルの予測性能の劣化はを検知する方法としては、運用時の予測結果に対して正解ラベルを用意し評価する方法と、入力データのドリフトを検知する方法の二つが挙げられる。前者は素直で評価しやすいが、正解ラベルの用意が困難なケースも存在する。後者は比較的どんなシチュエーションでも利用できる方法である。
データのドリフトはサンプル選択バイアスが存在する場合や、データの生成過程が非定常な場合に発生しやすい。ドリフトを検知する方法としては、Kolmogorov-Smirnov検定やChi-squared検定などといったシンプルな手法の他に、ドメイン分類器を利用する方法も考えられる。
MLOpsサイクルでは、プロダクション環境のでのMLモデルの振る舞いを踏まえて、モデル開発へとフィードバックを行う必要がある。これを行うためのインフラストラクチャは主に3つの要素から構成される。
- ロギングシステム
- モデル評価ストア
- モデルのオンライン比較
MLシステムにおけるログが含む情報としては、対象モデルの内容を含むメタデータ、モデルの入出力、モデルの予測結果を受けた上でのシステムの処理などが挙げられる。運用環境でのこれらの情報を踏まえて、データサイエンティストは新しいデータでモデルを再学習するか、新しい特徴量を検討するか、新しいアルゴリズムを採用するかなどを検討する。
モデル評価ストアの大きなタスクは二つある。一つは各モデルの学習時の特徴量やアルゴリズム、学習データ、評価指標などといった情報を保持しておくことである。もう一つは異なるバージョンのモデルを比較することである。これらの情報を踏まえて、デプロイの候補となるモデルを検討することになる。
オンライン評価は実環境でのモデルの振る舞いを評価するために不可欠である。比較方法としては主にchampion/challenger（シャドーテストやダークローンチとも呼ばれる）とA/Bテストの二つが一般的である。これらは候補となるモデルの予測がユーザーに影響を与えるかどうかという違いがあり、必要に応じて使い分けることになる。
8. Model Governance
機械学習やAIにフォーカスした規則は現状定まっていないが、一方で既存の規則でMLOpsのガバナンスに影響を与えるものは存在する。例えば金融市場や製薬業は業界に応じた規則が存在する。またプライバシーに関する規則は、MLOpsに限らず幅広い領域をカバーする規則である。
Responsible AIとはデータや機械学習に携わるスタッフが意識するべき責任性であり、データ、バイアス、包括性、スケーラブルなマネジメント、ガバナンスが重要な要素となる。
- データ：どのように収集したか、どのようなバイアスが考えられるか、適切に管理されているか
- バイアス：学習データや運用時にバイアスは発生していないか、システムのUIなどによるバイアスはあるか
- 包括性（inclusiveness）：MLOpsサイクル全体が人の手で適切に管理されており、透明性が担保されていること
- スケーラブルなマネジメント：開発のスケールが拡大しても、モニタリングやフィードバックサイクルが機能しているか
- ガバナンス：プロセスやルールを明確にする、教育によって組織を強化する、など
MLOpsのガバナンスに対するテンプレートとしては、分析のユースケース定義から始まり、責任の所在の明確化や教育、モニタリングなどの８ステップが検討できる。MLOpsサイクルを開始する際には、最初にガバナンスを定義し、これを拠り所としてプロセスを推進するのが重要となる。
MLOps: Real-World Examples
9. MLOps in Practice: Consumer Credit Risk Management
ここでの具体例は、MLによって申請者のローン返済能力を予測するというユースケースである。実際にローンが返済されたかどうか（予測結果へのフィードバック）はすぐにはわからないことに注意する必要がある。
モデルとしては、XGBoostなどを検討でき、モデルの説明性はShapley valueなどで評価することができる。注意するべき点として、基本的にモデルの予測結果は応募をリジェクトするために使われるため、審査を通過する応募はモデルが扱う中で比較的少なくなるというバイアスが存在が考えられる。
プロダクションに際しては、本書で触れたように、学習データやモデルに対する仮説、モニタリング方法をドキュメントとして整備しておく必要がある。またモニタリング内容として、モデルの予測性能だけでなく、データドリフトが発生していないかもチェックするのが良い。モニタリングの頻度によって、どの程度フィードバックループを自動化できるかも決まる。
10. MLOps in Practice: Marketing Recommendation Engines
ここではレコメンドエンジンにおけるMLOpsの適用を考える。レコメンドではメールを送信するようなプッシュ型のチャネルと、オンライン検索時などに表示するプル型のチャネルが存在する。データとしては、ユーザーの年齢や性別、過去の検索履歴などの他に、これらを加工して直近の購買数や直前のアクションなどを特徴量として扱うことも考えられる。
実験計画では、例えばレコメンド期間後の２週間の収益などがKPIとして考えられる。この時、A/Bテストにおける二つのグループの抽出には注意を払う必要がある。また実験時には、最初に限られたサイズのグループで実験を行い、効果が確かめられたら実験の規模を大きくするというアプローチも考えられる。
レコメンドの利用シーンによっては、モデルを含む推論処理全体の速度が重要な場合もある。こうした場合では利用できるモデルやパイプラインに制限が発生する可能性がある。一方で、1日1回予測を行い、その結果をキャッシュしておくようなケースでは、推論速度などの制約は緩くなる場合もある。
レコメンドに対する購買結果などのアクションを記録しておけると、モデルの予測精度をモニタリングできるようになるため、フィードバックループの高速化に有用となる。このような直接的な指標が得られる場合には、モニタリングとしてのデータドリフトの検知を行わなくてもいいかもしれない。
11. MLOps in Practice: Consumption Forecast
ここでは電力消費の予測をユースケースとした場合について紹介する。需要家と供給側は電力ネットワークで繋がっており、できるだけ電力ロスを少なく各需要家に届けることが目標となる。
予測対象としては、風力や太陽発電量から、各需要家の電力需要など様々なものが考えられる。これらは予測結果に対してどのようなアクションが取れるかを念頭において検討する必要がある。また予測期間も、数日先など短期的なものから、数日〜数年先（中期）、数十年先（長期）など様々なタイムスケールが考えられる。MLでは特に短期〜中期の予測が対象と考えられる。例えば中期先の電力消費予測の場合には、カレンダーの日や週などの周期的要素や気温、風速などの気象学的の利用が検討できる。
モデルとしては、Generalized additive modelやARIMA、LSTMなどが考えられる。モニタリングとしてはモデルの予測精度とともに、入力データのドリフトも重要になり得る。モデルの予測精度が劣化した時のために、フォールバックや再学習も準備する必要がある。
9章から11章で見たように、問題定義からMLモデルを構築、プロダクションへ導入する過程は産業やユースケースによって多岐にわたる。一方でMLOpsの原則は様々な組織でのML導入を後押しするものと言える。
感想とか
個人的にはもう少し技術的に具体的な内容を期待していた（推論APIからCI/CDのサンプルアプリケーションとか）。オライリーからはこの「Introducing MLOps」以外にもいくつかMLアプリケーションやMLOpsに関連する書籍が販売されている。
これらはAmazonなどではどれも高い評価を得ている。一方でMLOpsに関するナレッジはまだ需要に対して供給が追いついていないため、やや過大評価されているものもありそうだと思った。次はGCPやAWSなどのサンプルアプリケーションで実際に動くものを触ってみようと思う。
Discussion