MLOps 成熟度モデルと Azure Machine Learning での実現イメージ
こんにちは、@keonabut です。Microsoft が過去のお客様プロジェクトで得られた知見をベースに「MLOps 成熟度モデル」を 4 つのレベルで定義しています。本記事ではそれらを紹介するとともに、Azure Machine Learning での実現イメージを記載します。Azure で MLOps を導入したい、高度化したいという方々の第一歩となれば幸いです。
※ なお本記事で利用している素材の作成に、同僚のイトーさん (Zenn,Qiita)、書道家さん (Zenn,Qiita) にめちゃくちゃご協力頂いております。
目次
1. MLOps 成熟度モデル
MLOps 成熟度モデルは機械学習プロジェクトにおける MLOps 導入の指針になることを目指しています。現在の MLOps の Level を把握し、今後の MLOps の改善に必要な技術、プロセス、組織体制を見なすきっかけになります。
Microsoft Docs にて公開されており、こちらから確認できます👇
機械学習運用 (MLOps) の成熟度モデル
2. Azure Machine Learning とは？
本題に入る前に Azure Machine Learning の基本機能に触れておきます。Azure Machine Learning は Azure が提供する機械学習プラットフォームです。Python や R だけなく GUI でのモデル開発の機能、自動機械学習、ハイパーパラメータチューニングなどの効率的に実験を進める機能があります。また、本記事のテーマになる MLOps も強力にサポートしています。Microsoft の GitHub & GitHub Actions と連携することで、スムーズにアプリケーションと機械学習を一緒に管理していくことができます。
Azure Machine Learning は Workspace という単位で利用します。Workspace はプロジェクトやチーム毎に作成して共有します。
各機能の詳細については、下記のドキュメントを参照いただければと思いますが、データを管理する Datastore/Dataset、実験のログやメトリックを管理する Experiment、モデルなどのアーティファクトを管理する Models、モデル学習や推論で用いる Python パッケージや Docker イメージを管理する Environment、推論環境を管理する Endpoint、モデル学習やバッチ推論を自動化する Pipeline など機械学習のライフサイクル管理に必要な機能が揃っています。
3. 成熟度モデルの各レベルの定義
それでは MLOps の成熟度レベルをそれぞれ見ていきます。また Azure Machine Learning を利用した時のイメージ図も掲載しています。
Level 0 : MLOps なし
概要
何もしていない状態です。個人が自由に環境構築、モデル学習、デプロイメントを行っています。野良環境を用いており、機械学習モデルの再現性に問題があります。モデルのデプロイメントやアプリケーションとの連携を考えると、組織で整備されていない環境で生成された機械学習モデルなどの成果物は信頼性に欠けます。
Azure Machine Learning での実装
Azure Machine Learning や Data Science VM (DSVM) などを利用し一連の機械学習のライフサイクル実行できます。しかしながら野良環境のため、ステークホルダーとの成果物の共有が難しかったり、信頼性に欠けます。組織における Azure のポリシーに合っていないため、機械学習プロジェクトが途中で頓挫する懸念もあります。
課題・チャレンジ
-
プラットフォーム
- Python / R と各種機械学習向けライブラリが動く環境と組織での標準化が行われている
- 十分な性能の CPU/GPU/メモリ/ディスク etc を搭載したマシン/クラスターを調達できている
- コードを集約し管理する環境が整備されている
-
コード品質
- テスト可能となるようにコードが記述され、ユニットテストの整備がされている
-
データ
- セキュアで人に依存しない方法で繰り返しデータを取得する仕組みが整備されている
What's next ?
- 機械学習プラットフォームの整備
- チーム・組織で共有の機械学習プラットフォームを利用していること
- テストの自動化
- 少なくともコードに対するテスト項目がルール化されており、テストの実行が自動化できていること
- データ基盤が整備され始めていること
Level 1 : DevOps あり、MLOps なし
概要
従来のソフトウェアにおける DevOps は導入されているものの、MLOps は導入されていない状態です。
モデル学習
個人はそれぞれ自由に作業しており、追跡されていません。モデルファイルなどの成果物は手動で関係者に連携されます。
リリース
手動で実行されます。
統合
アプリケーション部分はテストが実施されるが、モデルの実装やテスト主にデータサイエンティストによって手動で実行されます。
People
サイロ化しています。
Azure Machine Learning での実装
基本的な ELT/ETL 処理は Azure Synapse Analytics などの分析基盤を用います。試行錯誤を繰り返せるように Synapse Pipeline で必要なデータが誰でもすぐに取得できるようにします。ベースとなるデータは Azure Data Lake Storage Gen2 に置かれます。機械学習の学習コード・推論コードは GitHub に保存され、Commit や Pull Request のタイミングなどでテストが実行されます。
Model の後段に 2 つの流れがありますが、上段が バッチ推論、下段が リアルタイム推論 になります
課題・チャレンジ
- 再現性の確保
- 学習を実行した際のコード、ハイパーパラメーター、パッケージのバージョン、データセット等が保存され、実験を再現できる
- 確立したモデル学習やデプロイの手順がパイプラインとしてまとめられ実行可能な状態になっている
- モデルそのものがバージョニングされて保存され、モデルの更新を行う場合に新旧比較が可能な状態になっている
What's next ?
-
モデル学習の再現性確保
- 1度やった実験を再現しようと思えばでき、実験の成果物（学習済みモデル等）が実験と紐づいた形で保管されていること
- パイプラインが構築され、確立した手順は簡単に再実行できること
-
モデルの運用管理
- モデルが管理されており、関連する実験やエンドポイントが紐づくこと
Level 2 : トレーニングの自動化
概要
これまでは手動で各プロセスを実行していましたが、自動化の概念を導入します。このレベルでは、機械学習パイプラインにより、モデル学習が自動化されます。また成果物は収集されて管理されます。正確に成果物を出力し収集することで再現性が高まります。
モデル学習
実験は追跡されています。モデルファイル、ログなどの成果物は収集され、集中的に管理されます。
リリース
手動で実行されます。プロセスはソフトウェアエンジニアのチームによって管理されます。
統合
アプリケーション部分はテストが実施されるが、モデルの実装やテスト主にデータサイエンティストによって手動で実行されます。
People
データエンジニアとデータサインティストは密に連携している。
Azure Machine Learning での実装
Azure Machine Learning には専用の Python SDK や Azure CLI (コマンドライン) ツールがあり、様々な外部環境からアクセスできます。この絵では GitHub Actions から Machine Learning Pipeline を実行しています。
課題・チャレンジ
- デプロイ
- 様々な推論環境へのスムーズなモデル投入
- モデルレベルのテストによる機械学習モデルの品質確認と説明性の付与
What's next ?
- 推論環境に合わせたデプロイパイプラインの実装
- アプリケーションから呼び出すことができる HTTP エンドポイント
- 既存データに対して推論結果を付与するバッチ推論
- モデルの検証・品質確認を行う仕組みの実装
Level 3 : モデル デプロイの自動化
概要
全工程が管理できています。デプロイした機械学習モデルを元データまで追跡することができます。
モデル学習
実験は追跡されています。モデルファイル、ログなどの成果物は収集され、集中的に管理されます。
リリース
自動化されています。CI/CD のパイプラインが整備されて、全てがバージョン管理されています。
統合
半自動化されています。Unit Test や Integration Test が追加されています。しかしながら部分的には手動で実行されます。
People
一部でサイロ化されていますが、多くのステークホルダーが密に連携しています。
Azure Machine Learning での実装
こちらでも GitHub Actions を用いており、モデルのデプロイまで拡張しています。
課題・チャレンジ
- デプロイ
- ユーザ影響を最小限に抑えたモデル更新
- 運用管理
- 監視
- データの変動の検知
- モデル性能劣化の検知
- モデル再学習・再実験の際のプロセスの確立
- 監視
- 自動化
- 機械学習モデルの監視+機械学習のパイプラインの組み合わせによる自動的なモデルの再学習と再展開
What's next ?
- 全工程を連続的に自動化し、各担当者はそれぞれの責務にのみ集中すれば良い状態にする
- 緻密な監視に基づく機械学習モデルの運用
Level 4 : MLOps の再トレーニングの完全自動化
概要
全工程を自動的に管理・監視しています。再学習が容易に行える環境になり、継続的にモデルが改善されていきます。
モデル学習
実験は追跡されています。モデルファイル、ログなどの成果物は収集され、集中的に管理されます。
リリース
自動化されています。CI/CD のパイプラインが整備されて、全てがバージョン管理されています。A/B が追加されています。
統合
半自動化されています。Unit Test や Integration Test が追加されています。手動で実行される部分は必要最小限度に止まっています。
People
全てのステークホルダーが密に連携しています。
Azure Machine Learning での実装
このレベルではモニタリングが強化され、そこから収集されたモデルの精度やシステムのパフォーマンスデータ、またデータドリフト検知によってモデルの再学習が自動で実行できる環境になっています。
※ 再学習やその後のプロセスが全て自動化されるべきとは思いませんが、再学習をするタイミングを定量的にある程度定めておくことと、再学習のプロセスを事前に構築しておくことで、システムの機械学習モデルを常に最新の状態に保持できます。
4. MLOps を支える Azure Machine Learning の特徴的な機能
MLOps に関連する Azure Machine Learning の機能や Microsoft テクノロジーを紹介します。
開発ツール
組織の中で統一された機械学習プラットフォームを利用することで、セキュリティを担保したり、機械学習モデルの再現性を高めることができます。しかしながら、実験環境において決められた開発ツールしか使えないとなると、オープンソースの Python や R を利用した機械学習の実験はやりずらいと思います。
Azure Machine Learning で利用できる開発ツールは非常に自由度が高く、ユーザビリティを極力下げないような工夫がされています。
マネージドの開発ツール
Azure Machine Learning が機能として提供している開発ツールです。
- Jupyter Notebook, Jupyter Lab
- Visual Studio Code
- Azure Machine Learning の Compute Instance に Remote 接続された環境
- R Studio
- Integrated Notebook
- Azure Machine Learning Studio に統合されている nteract ベースのノートブック環境
それ以外の開発ツール
Azure Machine Learning の各機能は Python SDK や Azure CLI (コマンドライン) からアクセスすることが出来ます。これらは Windows, Linux, Mac にインストールすることができるため、PyCharm などの任意の開発ツールをそのまま使うことができます。
Machine Learning Pipeline
Azure Machine Learning で提供しているパイプラインの機能です。主に特徴量エンジニアリングを含むモデル学習、バッチ推論での利用を想定しています。
かなり柔軟性の高い実装が可能になっており、例えば重たいデータの前処理は Azure Synapse Analytics の Spark Pool や Azure Databricks を用いることもできます。
なお、ドラッグ & ドロップでモデル学習から推論まで実装できる Designer は、この Machine Learning Pipeline をベースに用いており、ローコードで「モデル学習」「リアルタイム推論」「バッチ推論」を実装することができます。
また、Microsoft のテクノロジーには Pipeline (パイプライン) の機能が多数あり、やや混乱するかと思います。下記のドキュメントの どの Azure パイプライン テクノロジを使用すべきか で整理されていますので、一読ください。Azure Pipeline のところは、GitHub Actions に置き換えて読んで頂いても大丈夫です。
データドリフト検知
Azure Machine Learning にはデータドリフトを検知する機能が内蔵されています。数値系の変数にはワッサースタイン距離など、カテゴリ変数にはユークリッド距離などを使ったモニタリングができます。また検知されたイベントを用いて Microsoft Teams のチャットやメールでの配信などの連携も可能になっています。
※ 少し古い資料ですが、以前勉強会用にスライドを作りましたので、是非ご覧ください。
GitHub, GitHub Actions
Microsoft の GitHub はコード管理に欠かせません。また GitHub Enterprise はよりセキュアで高機能なプランで、本格的に DevOps, MLOps に取り組まれる場合は導入を検討ください。
GitHub Actions は Azure Pipelines から Fork されて登場したオーケストレーションツールです。例えば、モデル学習を実施後、テスト環境にモデルをデプロイし、QAエンジニアの承認を得てから、本番環境にデプロイするというプロセスを定義することができます。
責任のある AI
Microsoft が最近特に注力している分野です。Microsoft 社内でも MLOps に、責任のある AI を組み込んでいます。本記事では Level 2 の「課題・チャレンジ」に モデルレベルのテストによる機械学習モデルの品質確認と説明性の付与 と機械学習モデルの解釈可能性・説明性に関連することを記載しましたが、機械学習プロジェクトにおいて Sensitive なデータを扱ったり、エンドユーザーへの影響が大きいシステムにおいては、プロジェクト単位で事前に検討することはもちろんのこと、本来であれば組織・企業それぞれでポリシーを定め、継続的に取り組む必要があります。
Microsoft は責任のある AI のための様々なガイドライン、技術を公開しています。Azure Machine Learning と直接的に関わりがあるものとしては、Responsible AI Toolbox というオープンソーステクノロジーがあります。将来的に Azure Machine Learning に統合されます(現在は Private Preview)。
モデルの解釈可能性・説明性だけでなく、モデルの誤差分析 (Error Analysis)、因果推論 (EconML)、反実仮想サンプル生成 (DiCE) などのさまざまな機能が統合されています。ぜひ一度お試しください。
最新情報はこちらの動画を確認するのが手っ取り早いと思います。
最後に...
以前、MLOps はバズワード！ という Twitter の投稿を見ましたが、個人的にはその通りだと思います。機械学習プロジェクトを成功させるために求められる MLOps の考え方や技術を網羅することはできないので、キーワードに惑わされずに目の前の機械学習プロジェクトを紐解いていく必要があります。とはいえ白紙の状態では迷子になってしまうと思いますので、この成熟度モデルが何かしら参考になれば幸いです。
また、Azure Machine Learning を利用した具体的な実装方法は後日記事を作成したいと思いますので、乞うご期待！
参考情報
Discussion