機械学習の運用 (MLOps) v2

  • [アーティクル]

この記事では、機械学習の運用のための 3 つの Azure アーキテクチャについて説明します。 これらはすべて、エンド ツー エンドの継続的インテグレーション (CI)、継続的デリバリー (CD)、再トレーニングの各パイプラインを備えています。 これらのアーキテクチャは、以下の AI アプリケーションに適しています。

  • 古典的機械学習
  • Computer Vision (CV)
  • 自然言語処理 (NLP)

これらのアーキテクチャは MLOps v2 プロジェクトの成果です。 いくつもの機械学習ソリューションを作成する過程でソリューション アーキテクトが発見したベスト プラクティスを組み込んでいます。 結果として、以下で説明するような、デプロイ可能で、反復可能で、保守のしやすいパターンが得られました。

すべてのアーキテクチャで Azure Machine Learning サービスを使用します。

MLOps v2 のサンプル デプロイ テンプレートを使用した実装については、GitHub の Azure MLOps (v2) ソリューション アクセラレータに関するページを参照してください。

考えられるユース ケース

  • 古典的機械学習: 表形式の構造化データに対する時系列予測、回帰、分類は、このカテゴリの最も一般的なユース ケースです。 次に例をいくつか示します。
    • 二項分類とマルチ ラベル分類
    • 線形、多項式、リッジ、なげなわ、分位点、ベイズ回帰
    • ARIMA、自己回帰 (AR)、SARIMA、VAR、SES、LSTM
  • CV: ここで提示する MLOps フレームワークでは、主にセグメント化と画像分類の CV ユース ケースに焦点を当てています。
  • NLP: この MLOps フレームワークでは、以下のすべてのユース ケースと、一覧に含まれていない他のユース ケースを実装できます。
    • 名前付きエンティティの認識
    • テキスト分類
    • テキスト生成
    • センチメント分析
    • 翻訳
    • 質問応答
    • 概要
    • 文検出
    • 言語検出
    • 品詞のタグ付け

シミュレーション、深層強化学習、その他の形式の AI については、この記事では説明しません。

アーキテクチャ

MLOps v2 アーキテクチャ パターンを構成するのは、MLOps ライフサイクルの以下のフェーズを表す 4 つの主要モジュール要素です。

  • データ資産
  • 管理と設定
  • モデル開発 (内部ループ)
  • モデル デプロイ (外部ループ)

これらの要素、要素間の関係、各要素に通常関連するペルソナは、すべての MLOps v2 シナリオのアーキテクチャに共通です。 シナリオによっては、それぞれの詳細にバリエーションが存在する場合があります。

Machine Learning 向けの MLOps v2 の基本アーキテクチャは、表形式データに対する古典的機械学習のシナリオです。 CV および NLP アーキテクチャは、この基本アーキテクチャをベースに改変を加えたものです。

現在のアーキテクチャ

この記事では、現在 MLOps v2 でカバーしている以下のアーキテクチャについて説明します。

古典的機械学習アーキテクチャ

古典的機械学習アーキテクチャの図。

このアーキテクチャの Visio ファイルをダウンロードします。

古典的機械学習アーキテクチャのワークフロー

  1. データ資産

    この要素は、組織のデータ資産と、データ サイエンス プロジェクトにおけるデータの潜在的なソースとターゲットを示しています。 データ エンジニアは、MLOps v2 ライフサイクルのこの要素の主な所有者です。 この図の Azure データ プラットフォームは、網羅的でも規範的でもありません。 顧客のユース ケースに基づいて推奨されるベスト プラクティスを表すデータ ソースとデータ ターゲットは、緑色のチェック マークで示されます。

  2. 管理と設定

    この要素は、MLOps v2 のアクセラレータのデプロイの最初のステップです。 プロジェクトに関連付けられたリソースとロールの作成と管理に関連するすべてのタスクで構成されています。 これには次のタスクが含まれる可能性があり、その他のタスクが含まれる場合もあります。

    1. プロジェクト ソース コード リポジトリの作成
    2. Bicep または Terraform を使用した Machine Learning ワークスペースの作成
    3. モデルの開発とデプロイに使用されるデータセットとコンピューティング リソースの作成または変更
    4. プロジェクト チーム ユーザー、各ユーザーのロール、他のリソースへのアクセス制御の定義
    5. CI/CD パイプラインの作成
    6. モデルとインフラストラクチャのメトリックを収集し、通知するためのモニターの作成

    このフェーズに関連する主要なペルソナはインフラストラクチャ チームですが、データ エンジニア、機械学習エンジニア、データ サイエンティストも関連する可能性があります。

  3. モデル開発 (内部ループ)

    内部ループ要素は、セキュリティで保護された専用の Machine Learning ワークスペース内で作用する、反復的なデータ サイエンス ワークフローで構成されます。 一般的なワークフローを図に示します。 データ インジェスト、探索的データ分析、実験、モデルの開発と評価から、運用向けの候補モデルの登録に向かって進みます。 このモジュール要素は、MLOps v2 アクセラレータで実装されているように、データ サイエンス チームがモデルの開発に使用するプロセスに依存せず、そのプロセスに適応可能です。

    このフェーズに関連するペルソナには、データ サイエンティストと機械学習エンジニアが含まれます。

  4. Machine Learning レジストリ

    運用環境へのデプロイの候補となるモデルをデータ サイエンス チームが開発したら、Machine Learning ワークスペース レジストリにそのモデルを登録できます。 モデル登録によって自動的に、または人間参加型のゲート承認によってトリガーされる CI パイプラインにより、モデルと、その他のモデル依存関係がモデル デプロイ フェーズに昇格します。

    このステージに関連するペルソナは通常、機械学習エンジニアです。

  5. モデル デプロイ (外部ループ)

    モデル デプロイまたは外部ループ フェーズを構成するのは、運用前のステージングとテスト、運用環境へのデプロイ、そして、モデル、データ、インフラストラクチャの監視です。 CD パイプラインは、運用、監視、そして潜在的な再トレーニングを通じて、組織とユース ケースにとって適切な基準が満たされているかに関して、モデルと関連資産の昇格を管理します。

    このフェーズに関連するペルソナは、主に機械学習エンジニアです。

  6. ステージングとテスト

    ステージングとテストのフェーズは、顧客のプラクティスによって異なる場合がありますが、通常は、運用データに対するモデル候補の再トレーニングとテスト、エンドポイント パフォーマンスのためのテスト デプロイ、データ品質チェック、単体テスト、モデルとデータの偏りに関しての責任ある AI チェックなどのオペレーションが含まれます。 このフェーズは、セキュリティで保護された 1 つ以上の専用の Machine Learning ワークスペースで行われます。

  7. 運用環境へのデプロイ

    ステージングとテストのフェーズを通過したモデルは、人間参加型のゲート承認を使用して運用に昇格させることができます。 モデル デプロイのオプションには、バッチ シナリオの場合はマネージド バッチ エンドポイントが含まれ、オンラインのほぼリアルタイムのシナリオの場合は、マネージド オンライン エンドポイントか、Azure Arc を使用した Kubernetes デプロイのいずれかが含まれます。運用は通常、セキュリティで保護された 1 つ以上の専用の Machine Learning ワークスペースで行われます。

  8. 監視

    ステージング、テスト、運用の各ステージでの監視により、モデル、データ、インフラストラクチャのパフォーマンスの変化に関するメトリックを収集し、対応することができます。 モデルとデータの監視には、モデルやデータ ドリフトのチェック、新しいデータに対するモデルのパフォーマンス、責任ある AI の問題などが含まれる場合があります。 インフラストラクチャの監視では、低速なエンドポイント応答、コンピューティング容量の不足、またはネットワークの問題を監視できます。

  9. データとモデルの監視: イベントとアクション

    自動化されたトリガーと通知では、メトリックのしきい値やスケジュールなど、モデルとデータの懸念事項に関する基準に基づいて、実行する適切なアクションを実装できます。 たとえば、新しい運用データに対するモデルの自動再トレーニングや、運用前の評価を目的としたステージングとテストへのループバックを定期的にスケジュールできます。 モデル開発フェーズへのループバックが必要な、モデルまたはデータの問題をトリガーにすることもできます。このフェーズでは、データ サイエンティストが調査を行い、必要であれば新しいモデルを開発することができます。

  10. インフラストラクチャの監視: イベントとアクション

    エンドポイント応答のラグや、デプロイのためのコンピューティングの不足など、インフラストラクチャの懸案事項に関する基準に基づいて、自動化されたトリガーと通知で実行する適切なアクションを実装できます。 これらは、セットアップと管理のフェーズへのループバックのトリガーとなります。このフェーズでは、コンピューティングとネットワークのリソースをインフラストラクチャ チームが調査し、必要に応じて再構成できます。

Machine Learning CV アーキテクチャ

Computer Vision アーキテクチャの図。

このアーキテクチャの Visio ファイルをダウンロードします。

CV アーキテクチャのワークフロー

Machine Learning CV アーキテクチャは古典的機械学習アーキテクチャに基づいていますが、教師あり CV シナリオに特有の変更が加えられています。

  1. データ資産

    この要素は、組織のデータ資産と、データ サイエンス プロジェクトにおけるデータの潜在的なソースとターゲットを示しています。 データ エンジニアは、MLOps v2 ライフサイクルのこの要素の主な所有者です。 この図の Azure データ プラットフォームは、網羅的でも規範的でもありません。 CV シナリオの画像は、さまざまなデータ ソースに由来する可能性があります。 Machine Learning を使用して CV モデルを開発およびデプロイする場合の効率を高めるために、画像の Azure データ ソースとしては Azure Blob Storage と Azure Data Lake Storage を推奨しています。

  2. 管理と設定

    この要素は、MLOps v2 のアクセラレータのデプロイの最初のステップです。 プロジェクトに関連付けられたリソースとロールの作成と管理に関連するすべてのタスクで構成されています。 CV シナリオでは、MLOps v2 環境の管理とセットアップは古典的機械学習の場合とほぼ同じですが、Machine Learning または別のツールのラベル付け機能を使用して、画像のラベル付けと注釈プロジェクトを作成するという追加の手順があります。

  3. モデル開発 (内部ループ)

    内部ループ要素は、セキュリティで保護された専用の Machine Learning ワークスペース内で実行される、反復的なデータ サイエンス ワークフローで構成されます。 このワークフローと古典的機械学習シナリオの主な違いは、画像のラベル付けと注釈がこの開発ループの重要な要素であるという点です。

  4. Machine Learning レジストリ

    運用環境へのデプロイの候補となるモデルをデータ サイエンス チームが開発したら、Machine Learning ワークスペース レジストリにそのモデルを登録できます。 モデル登録によって自動的に、または人間参加型のゲート承認によってトリガーされる CI パイプラインにより、モデルと、その他のモデル依存関係がモデル デプロイ フェーズに昇格します。

  5. モデル デプロイ (外部ループ)

    モデル デプロイまたは外部ループ フェーズを構成するのは、運用前のステージングとテスト、運用環境へのデプロイ、そして、モデル、データ、インフラストラクチャの監視です。 CD パイプラインは、運用、監視、そして潜在的な再トレーニングを通じて、組織とユース ケースにとって適切な基準が満たされているかに関して、モデルと関連資産の昇格を管理します。

  6. ステージングとテスト

    ステージングとテストのフェーズは、顧客のプラクティスによって異なる場合がありますが、通常は、エンドポイント パフォーマンスのためのテスト デプロイ、データ品質チェック、単体テスト、モデルとデータの偏りに関しての責任ある AI チェックなどのオペレーションが含まれます。 CV シナリオでは、リソースと時間の制約のため、運用データに対するモデル候補の再トレーニングは省略することができます。 代わりに、データ サイエンス チームはモデル開発に運用データを使用できます。開発ループから登録される候補モデルは、運用のために評価されるモデルです。 このフェーズは、セキュリティで保護された 1 つ以上の専用の Machine Learning ワークスペースで行われます。

  7. 運用環境へのデプロイ

    ステージングとテストのフェーズを通過したモデルは、人間参加型のゲート承認によって運用に昇格させることができます。 モデル デプロイのオプションには、バッチ シナリオの場合はマネージド バッチ エンドポイントが含まれ、オンラインのほぼリアルタイムのシナリオの場合は、マネージド オンライン エンドポイントか、Azure Arc を使用した Kubernetes デプロイのいずれかが含まれます。運用は通常、セキュリティで保護された 1 つ以上の専用の Machine Learning ワークスペースで行われます。

  8. 監視

    ステージング、テスト、運用の各ステージでの監視により、モデル、データ、インフラストラクチャのパフォーマンスの変化に関するメトリックを収集し、対応することができます。 モデルとデータの監視には、新しい画像に対するモデルのパフォーマンスのチェックを含めることができます。 インフラストラクチャの監視では、低速なエンドポイント応答、コンピューティング容量の不足、またはネットワークの問題を監視できます。

  9. データとモデルの監視: イベントとアクション

    NLP 向けの MLOps で、古典的機械学習との重要な違いは、データとモデルの監視、およびイベントとアクションのフェーズです。 CV シナリオでは通常、新しい画像に対してモデルのパフォーマンスの低下が検出されても、自動再トレーニングは行われません。 この場合、モデルのパフォーマンスが低い新しい画像は、人間参加型のプロセスによって確認し、注釈を付ける必要があります。また多くの場合、モデル開発ループに戻り、新しい画像を使用してモデルを更新することが次のアクションとなります。

  10. インフラストラクチャの監視: イベントとアクション

    エンドポイント応答のラグや、デプロイのためのコンピューティングの不足など、インフラストラクチャの懸案事項に関する基準に基づいて、自動化されたトリガーと通知で実行する適切なアクションを実装できます。 これは、セットアップと管理のフェーズへのループバックのトリガーとなります。このフェーズでは、環境、コンピューティング、ネットワークのリソースをインフラストラクチャ チームが調査し、必要に応じて再構成できます。

Machine Learning NLP アーキテクチャ

NLP アーキテクチャの図。

このアーキテクチャの Visio ファイルをダウンロードします。

NLP アーキテクチャのワークフロー

Machine Learning NLP アーキテクチャは古典的機械学習アーキテクチャに基づいていますが、NLP シナリオに特有の変更がいくつか加えられています。

  1. データ資産

    この要素は、組織のデータ資産と、データ サイエンス プロジェクトにおけるデータの潜在的なソースとターゲットを示しています。 データ エンジニアは、MLOps v2 ライフサイクルのこの要素の主な所有者です。 この図の Azure データ プラットフォームは、網羅的でも規範的でもありません。 顧客のユース ケースに基づいて推奨されるベスト プラクティスを表すデータ ソースとデータ ターゲットは、緑色のチェック マークで示されます。

  2. 管理と設定

    この要素は、MLOps v2 のアクセラレータのデプロイの最初のステップです。 プロジェクトに関連付けられたリソースとロールの作成と管理に関連するすべてのタスクで構成されています。 NLP シナリオでは、MLOps v2 環境の管理とセットアップは古典的機械学習の場合とほぼ同じですが、Machine Learning または別のツールのラベル付け機能を使用して、画像のラベル付けと注釈プロジェクトを作成するという追加の手順があります。

  3. モデル開発 (内部ループ)

    内部ループ要素は、セキュリティで保護された専用の Machine Learning ワークスペース内で実行される、反復的なデータ サイエンス ワークフローで構成されます。 一般的な NLP モデル開発ループは、古典的機械学習シナリオと大きく異なる場合があります。それは、このシナリオでは、文についてはアノテーターが、テキスト データについてはトークン化、正規化、および埋め込みが一般的な開発ステップであるという点においてです。

  4. Machine Learning レジストリ

    運用環境へのデプロイの候補となるモデルをデータ サイエンス チームが開発したら、Machine Learning ワークスペース レジストリにそのモデルを登録できます。 モデル登録によって自動的に、または人間参加型のゲート承認によってトリガーされる CI パイプラインにより、モデルと、その他のモデル依存関係がモデル デプロイ フェーズに昇格します。

  5. モデル デプロイ (外部ループ)

    モデル デプロイまたは外部ループ フェーズを構成するのは、運用前のステージングとテスト、運用環境へのデプロイ、そして、モデル、データ、インフラストラクチャの監視です。 CD パイプラインは、運用、監視、そして潜在的な再トレーニングを通じて、組織とユース ケースにとっての基準が満たされているかに関して、モデルと関連資産の昇格を管理します。

  6. ステージングとテスト

    ステージングとテストのフェーズは、顧客のプラクティスによって異なる場合がありますが、通常は、運用データに対するモデル候補の再トレーニングとテスト、エンドポイント パフォーマンスのためのテスト デプロイ、データ品質チェック、単体テスト、モデルとデータの偏りに関しての責任ある AI チェックなどのオペレーションが含まれます。 このフェーズは、セキュリティで保護された 1 つ以上の専用の Machine Learning ワークスペースで行われます。

  7. 運用環境へのデプロイ

    ステージングとテストのフェーズを通過したモデルは、人間参加型のゲート承認によって運用に昇格させることができます。 モデル デプロイのオプションには、バッチ シナリオの場合はマネージド バッチ エンドポイントが含まれ、オンラインのほぼリアルタイムのシナリオの場合は、マネージド オンライン エンドポイントか、Azure Arc を使用した Kubernetes デプロイのいずれかが含まれます。運用は通常、セキュリティで保護された 1 つ以上の専用の Machine Learning ワークスペースで行われます。

  8. 監視

    ステージング、テスト、運用の各ステージでの監視により、モデル、データ、インフラストラクチャのパフォーマンスの変化を収集し、対応することができます。 モデルとデータの監視には、モデルやデータ ドリフトのチェック、新しいテキスト データに対するモデルのパフォーマンス、責任ある AI の問題などが含まれる場合があります。 インフラストラクチャの監視では、低速なエンドポイント応答、コンピューティング容量の不足、ネットワークなどの問題を監視できます。

  9. データとモデルの監視: イベントとアクション

    CV アーキテクチャと同様に、NLP 向けの MLOps で、古典的機械学習との重要な違いは、データとモデルの監視、およびイベントとアクションのフェーズです。 NLP シナリオでは通常、新しいテキストに対してモデルのパフォーマンスの低下が検出されても、自動再トレーニングは行われません。 この場合、モデルのパフォーマンスが低い新しいテキスト データは、人間参加型のプロセスによって確認し、注釈を付ける必要があります。 多くの場合、モデル開発ループに戻り、新しいテキスト データを使用してモデルを更新することが次のアクションとなります。

  10. インフラストラクチャの監視: イベントとアクション

    エンドポイント応答のラグや、デプロイのためのコンピューティングの不足など、インフラストラクチャの懸案事項に関する基準に基づいて、自動化されたトリガーと通知で実行する適切なアクションを実装できます。 これらは、セットアップと管理のフェーズへのループバックのトリガーとなります。このフェーズでは、コンピューティングとネットワークのリソースをインフラストラクチャ チームが調査し、必要に応じて再構成できます。

コンポーネント

  • Machine Learning: 大規模な機械学習モデルをトレーニング、スコアリング、デプロイ、および管理するためのクラウド サービス。
  • Azure Pipelines: このビルドおよびテスト システムは Azure DevOps に基づいており、ビルドおよびリリース パイプラインに使用されます。 Azure Pipelines ではこれらのパイプラインをタスクと呼ばれる論理的ステップに分割します。
  • GitHub: バージョン管理、コラボレーション、CI/CD ワークフローのためのコード ホスティング プラットフォーム。
  • Azure Arc: Azure Resource Manager を使用して Azure リソースとオンプレミス リソースを管理するためのプラットフォーム。 リソースには、仮想マシン、Kubernetes クラスター、およびデータベースを含めることができます。
  • Kubernetes: コンテナー化されたアプリケーションのデプロイ、スケーリング、管理を自動化するためのオープンソース システム。
  • Azure Data Lake: Hadoop と互換性のあるファイルシステム。 これには、階層型名前空間が統合されており、Blob Storage の大規模なスケールと経済性を備えています。
  • Azure Synapse Analytics: データ統合、エンタープライズ データ ウェアハウス、ビッグ データ分析を 1 つにまとめた無制限の分析サービスです。
  • Azure Event Hubs。 クライアント アプリケーションによって生成されたデータ ストリームを取り込むサービス。 そして、受信したイベントのシーケンスを保持したまま、ストリーミング データを取り込み、保存します。 コンシューマーはハブ エンドポイントに接続して、処理するメッセージを取得できます。 ここでは、Data Lake Storage との統合を利用しています。

共同作成者

この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。

プリンシパルの作成者:

  • Scott Donohoo | シニア クラウド ソリューション アーキテクト
  • Moritz Steller | シニア クラウド ソリューション アーキテクト

パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。

次のステップ