Azure 上の AI ワークロード用の MLOps と GenAIOps
AI ワークロード操作は、データのキュレーションとそのデータの消費に重点を置いて行われます。 運用により、ワークロードに優先順位を付ける品質、信頼性、セキュリティ、倫理、およびその他の標準を達成し、維持する効率が確保されます。
ワークロード タスクは、アプリケーション開発、データ処理、AI モデル管理の 3 つの主要な領域に分類できます。 各カテゴリでは、 DevOps、DataOps、MLOps、GenAIOps など、業界で実証済みの運用手法を採用する必要があります。
DevOps アクティビティは、自動化された継続的インテグレーションと継続的デプロイ (CI/CD) パイプラインと監視を通じてアプリケーション開発ライフサイクル管理全体をカバーします。 ただし、AI ワークロードの場合、データ パイプラインはコア コンポーネントの 1 つです。 DevOps の特殊化である DataOps は、データの抽出、変換、読み込み (ETL/ELT) などのプロセスを合理化することでデータ ライフサイクルの管理に重点を置いています。 DataOps の実践者は、通常、データ フローのパフォーマンスとデータ クレンジングの有効性を測定し、パイプラインの異常を監視します。
AI ワークロードは本質的に非決定的です。 多くの AI モデルでは、推論中に同じ問い合わせに対して異なる回答が生成される傾向があります。 これらのワークロードには、AI 出力の予測不能性を管理および適応できるプロセスが必要です。 DataOps は MLOps に拡張され、 モデルのトレーニングとテストのために 機械学習ワークフローを操作できます。 MLOps の特殊なサブセットである GenAIOps は、生成型 AI ソリューションを対象としています。 これには、 モデルの検出や、強化されたデータを使用した事前トレーニング済みモデルの絞り込み などのタスクが含まれます。
多くの場合、運用アクティビティは重複しており、さまざまな手法がさまざまな程度に適用されます。 たとえば、差別的 AI では、DataOps が主要な役割を果たしますが、DevOps アクティビティはあまり目立たないとします。 逆に、生成 AI では、オペレーショナル エクセレンスは DataOps よりも DevOps に大きく依存します。
関係なく、全体的な目標は、開発ライフサイクル全体を通して効率的な運用による機能の提供です。 予想される結果は次のとおりです。
- 一貫性のある結果を持つ反復可能なプロセス。
- 時間の経過に伴うモデルの持続的な精度。
- リスクを最小限に抑える効果的なガバナンス。
- モデルドリフトに適応するための管理プロセスを変更します。
自動化と監視は、これらの目標を達成するための主要な運用戦略 です。
また、AI コンポーネントの標準化されたプロセスを に確立し日常的、計画外、緊急操作に対応し、適切な追跡メカニズムを用意する必要があります。 これらのプロセスがないと、次のリスクが発生します。
- データ処理、モデル ホスティング、グラウンド データ管理、およびその他のタスクで繰り返し発生するエラーと非再現性。
- モデルのトレーニングと絞り込みのために使用される低品質または古いデータ。
- システムに対するエンド ユーザーの信頼度に影響を与え、最悪の場合は法的、コンプライアンス、またはセキュリティの問題につながります。
完全なツール セットを使用して、確立されたプロセスを実装する必要があります。 さまざまな環境で AI/機械学習ワークフローを管理するための特殊なツールを使用できます。
この記事では、運用の設計戦略に焦点を当て、ツールに関する推奨事項を示します。
推奨事項
この記事で提供される推奨事項の概要を次に示します。
| 推奨 | 説明 |
|---|---|
| 効率的なワークロード運用ライフサイクルを設計する。 | AI ワークロードのコンポーネントに基づいて、さまざまな運用ステージがそのライフサイクルに適用されます。 シナリオに関連するベスト プラクティスと、それらを実装するために使用できるツールを理解しておくことが重要です。 時間をかけて、ワークロードのすべてのコンポーネントに関する主要な推奨事項について学習し、実装します。 ▪ DataOps ▪ MLOps ▪ GenAIOps ▪ 監視 |
| すべてを自動化。 | 自動化により、ワークロードのライフサイクルにおける再現性と効率性が確保されます。 DevOps プロセスはこれに対する重要な共同作成者ですが、モデルを効率的に構築、テスト、検証、デプロイするために必要な追加の手順があります。 ▪ Automation |
| 可能な限りデプロイ パイプラインを利用。 | デプロイ パイプラインは、繰り返し可能なインフラストラクチャデプロイを提供したり、コードを継続的に統合したりするのに役立ちます。 また、モデルを運用環境に昇格させる前に、モデルを作成したり検証したりするための優れたツールでもあります。 デプロイ パイプラインを実装すると、信頼性とワークロードの全体的なユーザー エクスペリエンスを向上させることができます。 ▪ パイプラインのデプロイ |
| モデルのドリフトと減衰を防ぎます。 | モデルの減衰とドリフトを防ぐために、新しいモデルの変更を制御された方法で受け入れるのに役立つ構造化されたプロセスを用意する必要があります。 モデルのメンテナンスに関する推奨事項に従うと、準拠を維持し、予期しないユーザー エクスペリエンスを回避し、より最新のサービスを提供できます。 ▪ Model のメンテナンス |
ワークロード操作のライフサイクル
この画像は、データ収集、データのクリーニングによる不整合やエラーの排除、分析可能な形式へのデータの変換など、AI モデルの運用段階を示しています。 これらのステージは、判別モデルと生成モデルのグラウンド データの両方のトレーニングに関連します。 ただし、生成モデルのトレーニングの具体的なユース ケースは、この画像には示されていません。 このユース ケースは、この記事の範囲外です。
MLOps と GenAIOps のステージは似ています。 主な違いは、GenAIOps の場合、トレーニングから適切なモデルの選択、迅速なエンジニアリング、ドメイン固有の知識の組み込み 、微調整または取得拡張生成 (RAG) の実装にフォーカスが移る点です。
デプロイと監視の段階もかなり似ています。
次のセクションでは、一般的な運用方法について説明します。 運用前から運用まで、ライフサイクルのあらゆる段階をカバーします。
DataOps
データは、さまざまな運用データ ソースから集計された後、エラーや不整合を取り除き、欠損値を処理するために前処理されます。 最後に、トレーニングまたはエンリッチメントに適した形式に変換および正規化されます。 設計の側面については、 データのトレーニング および データの に関する記事を参照してください。
複数のソースや複雑なデータ パイプラインから大量のデータ処理することは困難な場合があるため、この段階でのデータ操作プロセスは効率的である必要があります。 このフェーズで高品質のデータが確実に されるようにするには、次の方法が必要です。 このステージを監視して、許容可能な品質バーの進行状況を追跡します。
また、データが運用環境からのものであることを考えると、データが安全であることを確認する必要もあります。 Dev/Test などの低い環境が、セキュリティの問題を防ぐのに役立つ運用環境と同じくらい安全であることを確認します。
Note
初期フェーズで広範なデータ クリーニングに投資することで、品質の低いデータに対処します。 medallion、データ メッシュ、フィーチャ ストアなどの既知の分析パターンを利用して、アップストリーム処理タスクを実行します。 アップストリーム フェーズが無効な場合は、ダウンストリーム フェーズの間に品質を向上させる必要があります。そのため、各ステージでデータ準備が行われるため、ワークロード コストが増加します。
データ処理タスクの詳細については、次の記事を参照してください。
ツール
ワークロードのデータ オーケストレーション ツールを標準化することをお勧めします。 ツールは、アクティビティをグループ化でき、自動化が組み込まれているデータ パイプラインを提供できる必要があります。
Azure Data Factory パイプラインを最初の選択肢にすることができます。 多くのデータ ソースを効率的に接続して処理できます。 ビッグ データとデータ ウェアハウスを組み合わせ、データ レイク、Apache Spark、Azure Synapse SQL をサポートする Azure Synapse Analytics を検討することもできます。 また、ETL 用の Data Factory と統合されます。
トレーニング データを準備するために、 Azure Machine Learning パイプライン には、データの収集や処理などのタスクを自動化できる特殊な機能が用意されています。
Pandas (データ準備用) や Scrapy などのオープンソース テクノロジは、一般的な選択肢です。
MLOps
モデル トレーニングは、適切なアルゴリズムを選択し、前処理された履歴データと観測を提供して、モデルがパターンを学習し、予測を行えるようにするプロセスです。
モデルのトレーニング (特徴エンジニアリング) とハイパーパラメーターの調整は反復的なプロセスであり、コストがかかります。 各イテレーションの間、データ サイエンティストはデータ、コード、およびパラメーターの組み合わせで結果を追跡します。 反復可能なパイプラインを使用して実験を追跡し 適切なレベルの精度が得られるまで手動で最小限の作業を行います。
もう 1 つの運用上の課題は、 特殊化されたコンピューティング リソースのプロビジョニングとスケーリングです 実験が行われます。 また、モデルのパッケージ化と発行効率的にする必要があります。
チームは UI ベースの開発から始めて課題を減らし、自信を持てるようにコードベースのアプローチに移行できます。
ツール
コードのバージョン、環境、パラメーター、実行、結果などの詳細をキャプチャして機械学習の実験を追跡できるツールを使用することをお勧めします。 MLflow は、このようなオープンソース フレームワークの 1 つです。 MLflow 互換の Azure Machine Learning ワークスペースを使用することを検討しデータ サイエンティストがプロジェクトの生産性と再現性を管理できるようにする合理化されたワークフローを提供します。 ソース管理の追跡を使用してコード開発を管理するには、機械学習パイプラインを GitHub などのソース管理と統合するか、ファイル共有を使用します。
ホスティング コンピューティングは、ワークフロー オーケストレーターの選択にも影響を与える可能性があります。 アプリケーションが Azure Kubernetes Service (AKS) でホストされている場合は、Kubeflow の使用を検討してください。
Azure Machine Learning を検討している場合は、Machine Learning に関する Azure Well-Architected Framework の観点から始めて ワークロードの適切に設計されたフレームワークの品質に関する問題に製品がどのように役立つかを理解することをお勧めします。
このプロセスの利点の一部は、個人の時間を最適化することです。 通常、データ サイエンティストは、探索的データ分析 (EDA) と実験をワークステーションから効果的に実行するために、特定のツールと SDK を必要とします。 Azure Machine Learning の事前構築済みオプションが適しているかどうかを評価します。 そうでない場合は、ワークステーションの構成を保存するか、この作業に対して承認された VM イメージを維持します。 開始点として使用できるイメージの 1 つの例として、 Data サイエンス仮想マシン (DSVM)があります。
場合によっては、ポリシーによって VM の使用が禁止される場合があります。 Microsoft Dev Box や Azure Virtual Desktop の追加などの代替手段を探します。 Docker を使用して、事前構築済みのイメージを含むマシンをブートストラップすることも検討できます。
ただし、この段階が成熟し、拡張実験が必要な場合は、マネージド コンピューティング インスタンスに移動し、ワークフローの一部として統合されたオプションを優先します。 Azure Machine Learning コンピューティング インスタンス開発とテストの目的でトレーニングと推論に使用できるかどうかを評価します。 コンピューティング クラスターでは、大規模なデータセットと複雑なモデルを処理できます。
Azure Machine Learning には、SDK を使用したコード ベースのソリューションと、自動化された機械学習やビジュアル デザイナーなどのロー コード オプションの両方が用意されています。 Python SDK には、それぞれ異なる機能を備えたモデルをトレーニングする複数の方法が用意されています。 Machine Learning では、トレーニング プロセスを高速化するために、ONNX ランタイム トレーニングの ORTModule、DeepSpeed、LoRA などの高度な最適化と分散コンピューティング テクノロジもサポートされています。
GenAIOps
この段階の主要なアクティビティは、 既存のモデルの検出と評価から始まり 特定のユース ケースに対して事前トレーニングされたものを特定します。 これは反復的なプロセスです。 適切なモデルが見つかると、ドメイン固有の接地に合わせて調整されるメリットが得られる場合があります。これには反復的な手順も含まれ、特定のレベルのオーケストレーションが必要になります。
モデルの統合とデプロイには、モデルの調整、ベクター インデックス、プロンプト、コード ブロックなど、従来の MLOps 機能を超える特殊なツールとプラクティスが必要です。
ツール
検出タスクに対処するには、さまざまなプロバイダーのモデルを含むモデル カタログを利用します。 Azure AI Studio の モデル カタログ を使用すると、キュレーションされたコレクションの中から評価し、モデルを効率的にデプロイできます。
Azure Machine Learning プロンプト フロー は、オーケストレーション コードの開発に役立ち、プロトタイプ作成、実験、反復、プロンプト エンジニアリングを可能にします。 これらのフローは、Azure Machine Learning マネージド エンドポイントにデプロイできます。 既存の CI/CD パイプライン テクノロジを使用してフローを実行してデプロイできるかどうかを評価します。
展開
この段階では、モデルはホスティングおよび推論プラットフォームまたは AI ワークロードのサービス レイヤーにデプロイされます。 API は、スケーラブルなコンテナーとしてパッケージ化する必要があります。 コンテナー プラットフォームは、マネージド コンピューティングまたはカスタム ホスティング プラットフォームにすることができます。 運用プラクティスでは、安全なデプロイを確保し、ロールバックを有効にする必要があります。
Azure OpenAI Service などのサービスとしてのプラットフォーム (PaaS) とサーバーレス ソリューションから始めて、導入と管理を簡素化します。 エンドポイント アクセスを集計するために、Azure Machine Learning サーバーレス API を使用することを検討してください。 マネージド コンピューティング クラスターは、高度なニーズに対応する実行可能なオプションです。 AKS でのセルフホスティングも別のオプションです。 コンピューティングのサイズを適切に設定し、他のワークロードからの適切な分離を維持してください。 また、サービスとしてのインフラストラクチャ (IaaS) としてモデルを完全にホストするなどのオプションを検討することもできます。 IaaS は柔軟性を提供しますが、運用上の負担を増やすことができます。 これらのオプションについては、 アプリケーション プラットフォームで説明されています。
このステージでは、モデルを運用環境に移行する前に問題をキャッチする最後の機会を示します。 テスト プロセスには、予測を期待どおりに提供するようにモデルが構成されていることを確認するための検証手順を含める必要があります。
このモデルを既存の運用環境に統合する必要があります。この場合、 実行される露出プロセスに従い、サイド バイ サイドデプロイを使用します。 カナリア モデルは、新しいモデルをロールアウトする一般的な方法です。 この方法では、ユーザー ベースが徐々に増加します。 ブルーグリーンデプロイも別の方法です。
ツール
Azure Machine Learning パイプライン azure Pipelines を使用して、推論用のモデルをデプロイできます。 Machine Learning には、ノード のプロビジョニング、OS の更新、自動スケール、監視、分離された仮想ネットワークなど、簡略化された操作のためのいくつかの機能が用意されています。
Machine Learning では、青緑色のデプロイもサポートされています。これにより、1 つのエンドポイントに複数のデプロイを含めることもできます。
Azure Container Apps や Azure アプリ Service などの他のホスティング プラットフォームを使用する場合は、プロビジョニングやスケーリングなどの操作を担当します。 そのような場合は、Azure DevOps、GitHub パイプライン、または CI/CD テクノロジの選択を使用します。
監視
監視は重要な戦略であり、すべての段階で適用されます。 これは継続的なプロセスであり、開発ライフサイクル全体にわたって一貫性と信頼性を維持するために AI ワークロードが厳格にテストされることを保証する品質ゲートへの入力として機能します。 モデルは、運用とデータ サイエンスの両方の観点から監視する必要があります。
受け入れ品質バーへの近接性を測定し、異常をチェックする DataOps 内部ループ監視プロセスを用意することを強くお勧めします。
事前トレーニング済みモデルの場合は、関連性に重点を置いて、データの誤差とパフォーマンスを監視することも重要です。 入力 (プロンプト) と出力 (入力候補) を評価して、関連性が高く正確であることを確認します。 さらに、悪意のあるプロンプトを使用してモデルの動作を操作する試みなど、セキュリティ リスクに注意してください。 双方向のデータを検査し、不適切なコンテンツを除外する完全なコンテント モードレーションがあることを確認します。 これらの考慮事項については、 ResponsibleAI の設計領域で説明します。
デプロイ後、モデルの減衰などの問題に対処するには、監視操作が必要です。 データの変更や外部の変更によってモデルが古くなり、モデルが無関係な結果を生成する可能性があります。 プロアクティブな対策として、継続的な監視に自動化されたプロセスを使用し、精度と関連性を維持するために評価と再トレーニングを行います。 さらに、最適なパフォーマンスと信頼性を確保するために、他のワークロードと同様に、インフラストラクチャとワークロードのメトリックを監視する必要があります。 詳細については、「 モデルの減衰のテストを参照してください。
ツール
Azure Machine Learning データ コレクターなどの推論エンドポイントからメトリックを収集しやすくするツールに投資します。
また、モデルのパフォーマンス、データドリフト、および生成 AI の安全性と品質の監視も必要です。
詳細については、次の記事を参照してください。
自動化
全体的なライフサイクルには多くのロール、頻繁な変更、相互に関連する手順が含まれているため、AI ワークロードは複雑です。 手動プロセスでは、エラーや不整合が発生する可能性があります。 データ処理モデルホスティングの自動化は、 反復性と効率を確保するのに役立ちます。 自動化は必ずしも必須ではありませんが、これらの複雑さを効果的に管理する方法です。 自動化によってリスクを軽減できるユース ケースをいくつか次に示します。
従来のコードデプロイとは異なり、AI/機械学習の非決定的なモデルとソリューションには、反復的な実験とトレーニングが必要です。 複数のチームが共同作業を行う場合、自動化は標準化されたプロセスを適用する方法として、データ サイエンティスト、エンジニア、運用チーム間の一貫性、再現性、および効果的なコラボレーションを維持するのに役立ちます。
モデルのライフサイクルには、主に次の 2 種類のトレーニングが含まれます。
オンライン トレーニングでは、意思決定が最新の情報に基づいて行われるように、モデルに最近のデータが頻繁に (場合によっては毎日) 組み込まれます。 このトレーニングはワークロードに統合されるため、モデルは通常のプロセスの一部として継続的に更新されます。
オフライン トレーニングでは、モデルのトレーニング頻度が低くなり、更新間のギャップが長くなります。 トレーニング プロセスはメイン ワークロードとは別であり、非同期的に実行されます。 新しいモデルの準備ができたら、システムに統合されます。
更新頻度が低い場合は、信頼性が損なわれる可能性があります。 更新プログラムが見逃された場合は、大きな問題なしで延期できます。 この概念は、グラウンド データにも適用されます。 たとえば、RAG を使用する場合は、最近のデータを使用する必要があるか、少し古いデータで十分かを決定する必要があります。 どちらのシナリオでも、最新の情報の必要性と更新頻度の実用的なバランスを取る必要があります。 必要な頻度と信頼性のため、自動化によってオンライン トレーニングを実行する必要があります。 オフライン トレーニングでは、必要な頻度のため、コストメリット分析を実行して自動化を正当化する必要があります。 さらに、オフライン ハードウェアなどのコストの低いリソースを使用して、オフライン トレーニングを実行できます。
従来の DevOps プロセスは、通常、構造的な変更の影響を受ける。 ただし、AI と機械学習では、モデルは運用データに基づいてトレーニングされます。 モデルの減衰は重大なリスクをもたらし、監視されていない場合、時間の経過と同時にパフォーマンスが低下する可能性があります。 モデルの有効性を維持するには、パフォーマンス メトリック、アラート、モデルの再トレーニングの自動収集と分析が必要です。 データとモデルの依存関係の変化を 検出するのに役立つ方法で自動化を使用して いつでも現在の状態を明確に把握できます。
モデルは、2 つの異なるアプローチでトレーニングできます。
- モデルは、完全な運用データを使用して開発環境でトレーニングされ 成果物のみが環境を通じて昇格されます。 この方法では計算コストを削減できますが、低い環境で運用データを処理するためにセキュリティを強化する必要があり、すべての組織では不可能な場合があります。
- モデルは、各環境でトレーニングされます。 コードの昇格は、トレーニング コードが低い環境でレビューおよびテストされますが、コンピューティングのコストが増加するため、安定性に役立つ場合があります。
どちらの方法にも長所と短所があります。 適切なアプローチの選択は、組織の優先順位とワークロードのソフトウェア開発ライフサイクル (SDLC) プラクティスによって異なります。 運用デプロイ前のモデルの徹底的なテストと評価は、方法に関係なく不可欠です
自動化コードでは、データ処理ステージの明確な記録を提供することで監査をサポートするためにデータ系列をする必要があります。 このレコードは、期待を管理するのに役立ち、結果に関する懸念に対処できるように決定がどのように行われたかを示すことができます。
デプロイ パイプライン
AI/機械学習ワークロードでは、モデルの開発には、モデルホスティング プラットフォームへのモデルの の作成、検証、および昇格 が含まれます。 データ処理、特徴エンジニアリング、モデルのトレーニングまたは拡張、運用環境へのデプロイに関連する複雑なワークフローを合理化するデプロイ パイプラインを用意することが重要です。 プロセスを不透明にする AI の非決定的な性質を考えると、リリース パイプライン監視システムで定性テストをする必要があります。
MLOps と GenAIOps では、個別の AI アクティビティとコア テクノロジが必要になる場合がありますが、基になる概念は DevOps の概念と似ています。 既存の DevOps プロセスからベスト プラクティスを適用することをお勧めします。 AI アクティビティをワークロードの既存のパイプラインに統合します。
通常、AI ワークロードには従来のコードデプロイが含まれます。 コードと共にモデルのデプロイを処理することも、独自のライフサイクルで個別に処理することもできます。 前者のアプローチが好ましい。 モデルと推論エンドポイントをワークロードデプロイと共にパッケージ化する準備を行い、AI 運用を主にデータの準備、トレーニング/微調整、データ管理、監視に重点を置きます。
運用前から運用まで、MLOps と GenAIOps のライフサイクル全体をカバーするように次の資産を調整する方法を再評価します。
- コードとしてのインフラストラクチャ (IaC) ツール
- CI/CD パイプライン
- 問題を追跡および特定するための監視スタック
ツール
CI/CD でよく使用される Azure Pipelines と GitHub Actions ワークフローを機械学習モデルに拡張できます。 機械学習インフラストラクチャ、カスタム ワークロード コンポーネント、オーケストレーション コード、モデルのデプロイに役立ちます。 Azure Machine Learning パイプラインを Azure DevOps または GitHub パイプラインと組み合わせます。 詳細については、「 Azure Machine Learning で Azure Pipelines を使用するを参照してください。
ツールの適切な組み合わせの選択には、ユース ケースと機能という 2 つの主な要因が影響します。 たとえば、Azure Machine Learning パイプラインは、データ サイエンティストによって実行されるオーケストレーションに適しています。 これには、再利用、キャッシュなどをサポートする豊富な機能セットがあります。 ツールの選択については、「 Azure パイプライン テクノロジを使用する必要がありますか?」を参照してください。
モデルのメンテナンス
AI/ML のランドスケープは、進行中のイノベーションと競合しています。 新しいモデルが頻繁に出現し、新しいユース ケースが検出され、新しいデータ ソースが使用可能になります。 その結果、モデルの減衰は一般的な課題です。
モデルのパフォーマンスの低下や時間の経過に伴う誤差を防ぐには、継続的な監視、評価、再トレーニングのための自動化されたプロセスを実装する必要があります。 次に例を示します。
モデル カタログを維持する。 新しいモデルを検出し、カタログを更新するプロセスを自動化します。
新しいユース ケースに適応する。 ワークロードの要件に新しいユース ケースが追加されたら、クエリを予測し、それに応じてデータ処理ロジックを調整します。
新しいデータ ソースを組み込む。 新しいデータ ソースがモデルの予測力または関連性を高める可能性がある場合は、データ インジェスト パイプラインを更新して、それらのソースに接続してデータをプルします。
規制要件に対するコンプライアンスを評価。 新しい機能に適応する場合は、組織または外部のコンプライアンス標準の制約内で変更が有効なままであることを確認します。
継続的な改善を追跡するための正式なプロセスを実装し、そのサイクル内のサブプロセスとして自己改善を組み込みます。
継続的な進化
運用を定期的に見直し、改善し、イノベーションを促進します。
MLOps 成熟度モデルは、手動プロセスから完全自動化に進みます。 手動ビルドと監視から始め、包括的なメトリックによって正当化されるように、自動化されたアプリケーション ビルド、トレーニング環境、デプロイを段階的に組み込みます。 詳細については、 MLOps 成熟度モデルを参照してください。
GenAIOps の成熟度レベルは、自動化された最適化手法を使用して、基本的なモデルから構造化されたデプロイに段階的に移行します。 詳細については、「 GenAIOps の成熟度レベルを調整するを参照してください。