この成熟度モデルの目的は、機械学習運用 (MLOps) の原則とプラクティスを明確にすることです。 この成熟度モデルでは、運用レベルの機械学習アプリケーション環境の作成と運用の継続的な改善を示します。 これは、機械学習の運用環境およびそれに関連するプロセスの成熟度を測定するために必要な段階的要件を確立するためのメトリックとして使用できます。
成熟度モデル
MLOps 成熟度モデルは、MLOps 環境を正常に実行するために必要な Development Operations (DevOps) の原則とプラクティスを明確にするのに役立ちます。 これは、既存の組織がこのような環境を実装しようとしたときに生じるギャップを特定することを目的としています。 また、これは、完全に成熟した環境の要件でユーザーを困惑させるのではなく、MLOps 機能を段階的に拡張する方法でもあります。 これを、次の目的のガイドとして使用してください。
新しい契約の作業範囲を見積もる。
現実的な成功基準を確立する。
契約終了時に引き渡す成果物を特定する。
ほとんどの成熟度モデルと同様、MLOps 成熟度モデルは、人材または文化、プロセスまたは構造、オブジェクトまたはテクノロジを定性的に評価します。 成熟度レベルが上がるに従って、インシデントまたはエラーが開発および運用プロセスの品質向上につながる可能性も高くなります。
MLOps 成熟度モデルは、次の 5 つのレベルの技術的機能に分けられます。
| Level |
説明 |
ハイライト |
テクノロジ |
| 0 |
MLOps なし |
- 機械学習モデルのライフサイクル全体を管理することは困難
- チームは別々で、リリースは困難
- ほとんどのシステムは "ブラック ボックス" として存在し、デプロイ時およびデプロイ後のフィードバックはほとんどなし
|
- 手動によるビルドとデプロイ
- モデルおよびアプリケーションの手動によるテスト
- モデルのパフォーマンスの一元的追跡なし
- モデル トレーニングは手動
|
| 1 |
DevOps はあるが、MLOps はなし |
- "MLOps なし" よりもリリースの苦労は少ないが、新しいモデルごとにデータ チームに依存
- 運用段階でのモデルのパフォーマンスに関するフィードバックは依然として限られる
- 結果の追跡および再現が困難
|
|
| 2 |
トレーニングの自動化 |
- トレーニング環境は完全に管理され、追跡可能
- モデルの再現が容易
- リリースは手動であるが、摩擦は少ない
|
- 自動化されたモデルのトレーニング
- モデル トレーニングのパフォーマンスを一元的に追跡
- モデル管理
|
| 3 |
モデル デプロイの自動化 |
- リリースは低摩擦で自動
- デプロイから元のデータまで完全に追跡可能
- 環境全体 (トレーニング > テスト > 運用) を管理
|
- デプロイのためのモデルのパフォーマンスに関する A および B テストを統合
- すべてのコードのテストを自動化
- モデル トレーニングのパフォーマンスを一元的に追跡
|
| 4 |
MLOps 運用の完全自動化 |
- システムを完全自動化し、監視を容易化
- 運用システムは、改善方法に関する情報を提供。場合によっては、新しいモデルで自動的に改善
- ゼロ ダウンタイム システムに近づく
|
- モデル トレーニングとテストを自動化
- デプロイされたモデルからの詳細で一元化されたメトリック
|
次の表は、そのレベルのプロセス成熟度の詳細な特性を示しています。 モデルは常に進化しています。
Level 0:MLOps なし
| ユーザー |
モデルの作成 |
モデルのリリース |
アプリケーションの統合 |
- データ サイエンティスト: サイロ化、より大きなチームとの定期的なコミュニケーションがない
- データ エンジニア ( "存在する場合"): サイロ化、より大きなチームとの定期的なコミュニケーションがない
- ソフトウェア エンジニア: サイロ化、他のチーム メンバーからリモートでモデルを受信
|
- データ収集は手動
- コンピューティングは管理されない可能性あり
- 実験は予測追跡されない
- 最終結果は、入力と出力を単一のモデル ファイルにまとめられる可能性があり、手動で手渡される
|
- 手動プロセス
- スコアリング スクリプトは、実験後に手動で作成される可能性あり、バージョン管理なし
- リリースは、データ サイエンティストまたはデータ エンジニアのみによって処理される
|
- 実装をデータ サイエンティストの専門知識に大きく依存
- 毎回手動によるリリース
|
Level 1: DevOps あり、MLOps なし
| ユーザー |
モデルの作成 |
モデルのリリース |
アプリケーションの統合 |
- データ サイエンティスト: サイロ化、より大きなチームとの定期的なコミュニケーションがない
- データ エンジニア (存在する場合): サイロ化、より大きなチームとの定期的なコミュニケーションがない
- ソフトウェア エンジニア: サイロ化、他のチーム メンバーからリモートでモデルを受信
|
- データは、データ パイプラインによって自動収集
- コンピューティングは管理される場合もあれば、管理されない場合もある
- 実験は予測追跡されない
- 最終結果は、入力と出力を単一のモデル ファイルにまとめられる可能性があり、手動で手渡される
|
- 手動プロセス
- スコアリング スクリプトは、実験後に手動で作成される可能性あり、バージョン管理の可能性あり
- ソフトウェア エンジニアへは手渡し
|
- モデルの基本的な統合テストあり
- モデルの実装をデータ サイエンティストの専門知識に大きく依存
- リリースを自動化
- アプリケーション コードのユニット テストあり
|
Level 2: トレーニングの自動化
| ユーザー |
モデルの作成 |
モデルのリリース |
アプリケーションの統合 |
- データ サイエンティスト: データ エンジニアと緊密に連携して、実験コードを反復可能なスクリプトまたはジョブに変換
- データ エンジニア: データ サイエンティストと連携
- ソフトウェア エンジニア: サイロ化、他のチーム メンバーからリモートでモデルを受信
|
- データは、データ パイプラインによって自動収集
- コンピューティングを管理
- 実験結果を追跡
- トレーニング コードと生成されたモデルの両方のバージョンを管理
|
- 手動によるリリース
- スコアリング スクリプトをテストと共にバージョン管理
- リリースをソフトウェア エンジニアリング チームで管理
|
- モデルの基本的な統合テストあり
- モデルの実装をデータ サイエンティストの専門知識に大きく依存
- アプリケーション コードのユニット テストあり
|
Level 3: モデル デプロイの自動化
| ユーザー |
モデルの作成 |
モデルのリリース |
アプリケーションの統合 |
- データ サイエンティスト: データ エンジニアと緊密に連携して、実験コードを反復可能なスクリプトまたはジョブに変換
- データ エンジニア: データ サイエンティストおよびソフトウェア エンジニアと連携して入力および出力を管理
- ソフトウェア エンジニア: データ エンジニアと連携して、アプリケーション コードへのモデルの統合を自動化
|
- データは、データ パイプラインによって自動収集
- コンピューティングを管理
- 実験結果を追跡
- トレーニング コードと生成されたモデルの両方のバージョンを管理
|
- 自動リリース
- スコアリング スクリプトをテストと共にバージョン管理
- リリースを継続的デリバリー (CI/CD) パイプラインで管理
|
- モデル リリースごとのユニットおよび統合テスト
- モデルの実装について、データ サイエンティストの専門知識への依存度を低減
- アプリケーション コードのユニットおよび統合テストあり
|
Level 4: MLOps の再トレーニングの完全自動化
| ユーザー |
モデルの作成 |
モデルのリリース |
アプリケーションの統合 |
- データ サイエンティスト: データ エンジニアと緊密に連携して、実験コードを反復可能なスクリプトまたはジョブに変換。 ソフトウェア エンジニアと連携して、データ エンジニアのためのマーカーを特定
- データ エンジニア: データ サイエンティストおよびソフトウェア エンジニアと連携して入力および出力を管理
- ソフトウェア エンジニア: データ エンジニアと連携して、アプリケーション コードへのモデルの統合を自動化。 デプロイ後のメトリック収集を実装
|
- データは、データ パイプラインによって自動収集
- 運用メトリックに基づいて再トレーニングを自動トリガー
- コンピューティングを管理
- 実験結果を追跡
- トレーニング コードと生成されたモデルの両方のバージョンを管理
|
- 自動リリース
- スコアリング スクリプトをテストと共にバージョン管理
- 継続的インテグレーションおよび継続的デリバリー (CI/CD) パイプラインで管理
|
- モデル リリースごとのユニットおよび統合テスト
- モデルの実装について、データ サイエンティストの専門知識への依存度を低減
- アプリケーション コードのユニットおよび統合テストあり
|
次のステップ