機械学習操作 (MLOps) 成熟度モデルでは、運用環境の機械学習環境の構築と運用に役立つ原則とプラクティスが定義されています。 このモデルを使用して、現在の状態を評価し、成熟した MLOps 環境に向けた段階的な進行状況を計画します。
成熟度モデルの概要
MLOps 成熟度モデルでは、MLOps 環境を正常に実行するために必要な開発操作 (DevOps) の原則とプラクティスが明確になります。 組織の MLOps 機能を測定し、現在の実装のギャップを特定するためのフレームワークが提供されます。 このモデルを使用して、成熟した実装の完全な複雑さに事前に直面するのではなく、MLOps 機能を徐々に開発します。
MLOps 成熟度モデルをガイドとして使用して、次のタスクを実行します。
新しい契約の作業範囲を見積もります。
現実的な成功基準を確立します。
契約の終了時に引き渡す成果物を特定します。
ほとんどの成熟度モデルと同様に、MLOps 成熟度モデルは、人と文化、プロセスと構造、オブジェクトとテクノロジを定性的に評価します。 成熟度レベルが上がるにつれて、インシデントやエラーが開発および生産プロセスの改善につながる可能性も高くなります。
MLOps 成熟度モデルには、5 つのレベルの技術的な機能が含まれます。
| レベル |
Description |
概要 |
テクノロジー |
| 0 |
MLOps なし |
- 完全な機械学習モデルのライフ サイクルは管理が困難です。
- チームは異なっており、リリースは困難です。
- ほとんどのシステムは非トランスペアレントであり、デプロイ中とデプロイ後のフィードバックはほとんどありません。
|
- ビルドとデプロイは手動で行います。
- モデルとアプリケーションのテストは手動で行います。
- モデルのパフォーマンス追跡は一元化されていません。
- モデルトレーニングは手動です。
- Teams では、基本的な Azure Machine Learning ワークスペース機能のみが使用されます。
|
| 1 |
DevOps はあるが MLOps はない |
- リリースはレベル 0 よりも難しくはありませんが、新しいモデルごとにデータ チームに依存します。
- 運用環境でのモデルのパフォーマンスに関するフィードバックはまだ限られています。
- 結果をトレースして再現することは困難です。
|
- ビルドは自動化されます。
- アプリケーション コードには自動テストがあります。
- コードはバージョン管理されています。
|
| 2 |
自動トレーニング |
- トレーニング環境は完全に管理され、トレース可能です。
- モデルは再現が容易です。
- リリースは手動ですが、実装は簡単です。
|
- モデルトレーニングは自動化されています。
- モデル トレーニングのパフォーマンス追跡が一元化されています。
- モデル管理が実施されています。
- Machine Learning のスケジュールされたジョブまたはイベントドリブン ジョブは、定期的なトレーニングを処理します。
- 管理対象の機能ストアが採用されています。
- Azure Event Grid のライフ サイクル イベントは、パイプライン オーケストレーション用に生成されます。
- 環境は、Machine Learning 環境定義を使用して管理されます。
|
| 3 |
モデルの自動デプロイ |
- リリースは実装と自動が簡単です。
- デプロイから元のデータへの完全な追跡可能性が存在します。
- トレーニング、テスト、運用など、環境全体が管理されます。
|
- モデル のパフォーマンスの A/B テストは、デプロイ用に統合されています。
- すべてのコードに自動テストがあります。
- モデル トレーニングのパフォーマンス追跡が一元化されています。
- 成果物は、Machine Learning レジストリを使用してワークスペース間で昇格されます。
|
| 4 |
完全自動化されたMLOps運用 |
- 完全なシステムは自動化され、容易に監視される。
- 運用システムは、改善方法に関する情報を提供し、場合によっては新しいモデルで自動的に改善します。
- システムはダウンタイムゼロに近づいている。
|
- モデルのトレーニングとテストは自動化されています。
- デプロイされたモデルは、詳細で一元化されたメトリックを出力します。
- ドリフトまたは回帰シグナルは、Event Grid を使用して自動再トレーニングをトリガーします。
- 特徴の具体化の正常性と鮮度が監視されます。
- モデルの昇格はポリシー ベースであり、Machine Learning レジストリを使用して自動化されます。
|
次の表では、各成熟度レベルの詳細な特性について説明します。
レベル 0: MLOps なし
| People |
モデルの作成 |
モデルリリース |
アプリケーションの統合 |
- データ サイエンティストは、大規模なチームと定期的にコミュニケーションを取ることなく、分離して作業します。
- データ エンジニア (存在する場合) は、大規模なチームと定期的にコミュニケーションを取ることなく、単独で作業します。
- ソフトウェア エンジニアは分離して作業し、他のチーム メンバーからモデルをリモートで受け取ります。
|
- データは手動で収集されます。
- コンピューティングは管理されていない可能性があります。
- 実験は一貫して追跡されません。
- 最終的な結果は、通常、入力と出力を含む単一のモデル ファイルであり、手動で渡されます。
|
- リリース プロセスは手動です。
- スコアリング スクリプトは実験後に手動で作成され、バージョン管理されません。
- 単一のデータ サイエンティストまたはデータ エンジニアがリリースを処理します。
|
- 実装は、データ サイエンティストの専門知識に大きく依存します。
- アプリケーションのリリースは手動で行います。
|
レベル 1: DevOps ですが MLOps なし
| People |
モデルの作成 |
モデルリリース |
アプリケーションの統合 |
- データ サイエンティストは、大規模なチームと定期的にコミュニケーションを取ることなく、分離して作業します。
- データ エンジニア (存在する場合) は、大規模なチームと定期的にコミュニケーションを取ることなく、単独で作業します。
- ソフトウェア エンジニアは分離して作業し、他のチーム メンバーからモデルをリモートで受け取ります。
|
- データ パイプラインは自動的にデータを収集します。
- コンピューティングは、管理される場合と管理されない場合があります。
- 実験は一貫して追跡されません。
- 最終的な結果は、通常、入力と出力を含む単一のモデル ファイルであり、手動で渡されます。
|
- リリース プロセスは手動です。
- スコアリング スクリプトは、実験後に手動で作成されますが、バージョン管理されている可能性があります。
- モデルはソフトウェア エンジニアに渡されます。
|
- モデルの基本的な統合テストが存在します。
- 実装は、データ サイエンティストの専門知識に大きく依存します。
- アプリケーションのリリースは自動化されています。
- アプリケーション コードには単体テストがあります。
|
レベル 2: 自動トレーニング
| People |
モデルの作成 |
モデルリリース |
アプリケーションの統合 |
- データ サイエンティストは、データ エンジニアと直接連携して、実験コードを反復可能なスクリプトとジョブに変換します。
- データ エンジニアは、モデル開発に関してデータ サイエンティストと協力します。
- ソフトウェア エンジニアは分離して作業し、他のチーム メンバーからモデルをリモートで受け取ります。
|
- データ パイプラインは自動的にデータを収集します。
- コンピューティングは管理されます。
- 実験結果が追跡されます。
- トレーニング コードとモデルはどちらもバージョン管理されています。
|
- リリース プロセスは手動です。
- スコアリング スクリプトはバージョン管理され、テストがあります。
- ソフトウェア エンジニアリング チームがリリースを管理します。
|
- モデルの基本的な統合テストが存在します。
- 実装は、データ サイエンティストの専門知識に大きく依存します。
- アプリケーション コードには単体テストがあります。
|
レベル 3: モデルの自動デプロイ
| People |
モデルの作成 |
モデルリリース |
アプリケーションの統合 |
- データ サイエンティストは、データ エンジニアと直接連携して、実験コードを反復可能なスクリプトとジョブに変換します。
- データ エンジニアは、データ サイエンティストやソフトウェア エンジニアと協力して、入力と出力を管理します。
- ソフトウェア エンジニアはデータ エンジニアと協力して、アプリケーション コードへのモデル統合を自動化します。
|
- データ パイプラインは自動的にデータを収集します。
- コンピューティングは管理されます。
- 実験結果が追跡されます。
- トレーニング コードとモデルはどちらもバージョン管理されています。
|
- リリース プロセスは自動です。
- スコアリング スクリプトはバージョン管理され、テストがあります。
- 継続的インテグレーションと継続的デリバリー (CI/CD) パイプラインによってリリースが管理されます。
|
- 各モデル リリースには、単体テストと統合テストが含まれています。
- 実装は、データ サイエンティストの専門知識にあまり依存しなくなります。
- アプリケーション コードには、単体テストと統合テストがあります。
|
レベル 4: 完全な MLOps 自動化操作
| People |
モデルの作成 |
モデルリリース |
アプリケーションの統合 |
- データ サイエンティストは、データ エンジニアと直接連携して、実験コードを反復可能なスクリプトとジョブに変換します。 また、ソフトウェア エンジニアと連携してデータ マーカーを識別します。
- データ エンジニアは、データ サイエンティストやソフトウェア エンジニアと協力して、入力と出力を管理します。
- ソフトウェア エンジニアは、データ エンジニアと協力してモデル統合を自動化し、デプロイ後のメトリック収集を実装します。
|
- データ パイプラインは自動的にデータを収集します。
- 運用環境のメトリックでは、再トレーニングが自動的にトリガーされます。
- コンピューティングは管理されます。
- 実験結果が追跡されます。
- トレーニング コードとモデルはどちらもバージョン管理されています。
|
- リリース プロセスは自動です。
- スコアリング スクリプトはバージョン管理され、テストがあります。
- CI/CD パイプラインはリリースを管理します。
|
- 各モデル リリースには、単体テストと統合テストが含まれています。
- 実装は、データ サイエンティストの専門知識にあまり依存しなくなります。
- アプリケーション コードには、単体テストと統合テストがあります。
|
MLOps と GenAIOps
この記事では、予測、表形式、および従来の機械学習のライフ サイクル機能について説明します。 生成 AI 操作 (GenAIOps) では、MLOps の成熟度レベルを補完する追加の機能が導入されます。これは、それを置き換えるのではなく、 GenAIOps には、プロンプト ライフ サイクル、取得の拡張、出力の安全性、トークン コストのガバナンスが含まれます。 詳細については、 MLOps への投資がある組織の GenAIOps を参照してください。 プロンプトイテレーションのしくみと、この記事で説明する再現可能なトレーニングデプロイループを混同しないでください。
貢献者達
Microsoft では、この記事を保持しています。 次の共同作成者がこの記事を書きました。
-
デリン・チョン |シニア クラウド ソリューション アーキテクト – データと AI
公開されていない LinkedIn プロフィールを見るには、LinkedIn にサインインしてください。
次のステップ