DevOpsの状態に関する最も憤慨した研究では、著者は、エリート/高性能組織のソフトウェア開発と提供の有効性を捉える4つの主要な指標、つまり展開頻度、変更のリードタイム、平均復元時間、および変更失敗率を強調しました。これらのメトリックは、MLベースのソフトウェア配信を測定および改善するのに役立つことがわかっています。次の表では、各メトリックの定義を示し、MLOps に接続します。
| Metric | DevOps | MLOps |
|---|---|---|
| 展開頻度 | 組織はどのくらいの頻度でコードを運用環境にデプロイしたり、エンド ユーザーにリリースしたりしていますか? | ML モデルのデプロイ頻度は、 1)モデルの再トレーニング要件(頻度の低いものからオンライントレーニングまで)。モデルの再トレーニングには 2 つの側面が重要です 1.1) モデル減衰メトリック。 1.2) 新しいデータの可用性。 2) デプロイ プロセスの自動化のレベル (手動デプロイ と 完全に自動化された CI/CD パイプラインの間)。 |
| 変更のリードタイム | コミットされたコードから本番環境で正常に実行されるコードに移行するのにどのくらい時間がかかりますか? | 変更の ML モデルのリードタイムは以下に依存します 1)デプロイ/サービング用のMLモデルを完成させるためのデータサイエンスの探索フェーズの期間。 2) ML モデルのトレーニング期間。 3) 展開プロセス中の手動ステップの数と期間。 |
| 平均復元時間 (MTTR) | サービス インシデントまたはユーザーに影響を与える欠陥 (計画外の停止やサービスの障害など) が発生した場合、サービスの復元に通常どのくらいの時間がかかりますか? | ML モデルの MTTR は、手動で実行されるモデルのデバッグの数と期間、およびモデルのデプロイ手順によって異なります。ML モデルを再トレーニングする必要がある場合、MTTR は ML モデルのトレーニング |
| 変更失敗率 | 運用環境への変更またはユーザーにリリースされた変更のうち、サービスが低下し (サービスの障害やサービスの停止など)、その後修復が必要 (修正プログラム、ロールバック、修正、修正プログラムが必要など) に何パーセントがもたらされますか。 | ML モデル変更の失敗率は、現在のモデルを展開する前にデータを使用して ML モデルをテストすることによって減少する可能性があります。以下についても考慮する必要があります 1) ML モデルのトレーニングとサービング用のデータセットが一致すること。 2) ML モデルをデプロイする前に、モデルを使用して予測を行い、予測の精度を検証すること。 3) モデルを展開する前に、モデルを使用して業務ロジックをテストすること。 4) ML モデルのデプロイプロセスを自動化すること。 |
ML の開発と配信プロセスの有効性を向上させるには、上記の 4 つの主要な指標を測定する必要があります。このような効果を実現するための実用的な方法は、最初に CI/CD パイプラインを実装し、データ、ML モデル、ソフトウェア コード パイプラインのテスト駆動開発を採用することです。