機械学習の操作

  • [アーティクル]

機械学習の操作 (MLOps とも呼ばれる) とは、AI を取り入れたアプリケーションに DevOps の原則を適用することを指します。 組織で機械学習の操作を実装するには、特定のスキル、プロセス、テクノロジが導入されていなければなりません。 目標は、堅牢かつスケーラブルで信頼性が高く、自動化された機械学習ソリューションを提供することです。

この記事では、組織レベルで機械学習の操作をサポートするリソースを計画する方法について説明します。 Azure Machine Learning を使用してエンタープライズで機械学習の操作を導入することに基づいて、ベスト プラクティスとおすすめ候補についてレビューします。

機械学習の操作の概要

最新の機械学習アルゴリズムとフレームワークにより、正確な予測を行えるモデルの開発はますます容易になっています。 機械学習の操作は、エンタープライズでのアプリケーション開発に機械学習を組み込む構造化された方法です。

シナリオ例では、期待以上の正確性の機械学習モデルを構築し、ビジネス スポンサーを感心させることができました。 しかし、いざそのモデルを運用環境にデプロイするとなると、思っていたほど簡単ではない場合があります。 組織が運用環境で機械学習モデルを使用できるようになるには、その前に人、プロセス、テクノロジを整備する必要が生じる可能性があります。

また将来的に、あなたや同僚が、古いモデルより優れた性能を持つ新しいモデルを開発するかもしれません。 運用環境で使用されていた機械学習モデルを置き換えると、組織にとって重要な以下のような懸念事項が生じることがあります。

  • デプロイされていたモデルに依存する事業運営を中断せずに、新しいモデルを実装する必要が生じることがあります。
  • 新しいモデルのデータから異常な予測や偏った予測が行われた場合には、規制上の目的で、そのモデルの予測を説明したり、モデルを再作成したりする必要が生じることがあります。
  • 機械学習のトレーニングやモデルで使用されるデータは、時間の経過と共に変化する可能性があります。 このデータの変化のため、予測の正確性を維持するには、モデルを定期的に再トレーニングする必要が生じることがあります。 データのフィード、モデルのパフォーマンスのモニター、モデルの再トレーニング、失敗した場合のモデルの修正を行う担当者または役割が割り当てられている必要があります。

モデルの予測に REST API を使用するアプリケーションがあるとします。 このような単純なユース ケースでも、運用環境では問題が発生する可能性があります。 機械学習の操作の戦略を実装すると、デプロイに関する懸念に対処し、AI を取り入れたアプリケーションに依存する事業運営をサポートするのに役立ちます。

機械学習の操作のタスクの中には、一般的な DevOps フレームワークにフィットするものもあります。 たとえば、単体テストと統合テストの設定や、バージョン コントロールを使用した変更の追跡などがあります。 以下の方法を含むその他のタスクは、機械学習の操作に特有です。

  • ベースライン モデルに対する継続的な実験と比較。
  • データ ドリフトを検出するための入力データのモニター。
  • モデルの再トレーニングのトリガーと、ディザスター リカバリーに備えたロールバックの設定。
  • トレーニングとスコアリングの両方に対応する、再利用可能なデータ パイプラインの作成。

機械学習の操作のゴールは、開発と運用の間のギャップを解消し、顧客に価値をより迅速に提供することです。 このゴールを達成するには、従来の開発と運用のプロセスを見直す必要があります。

すべての組織の機械学習の操作の要件が同じであるとは限りません。 大規模な多国籍企業の機械学習の操作のアーキテクチャは、小規模なスタートアップ企業が確立するインフラストラクチャと同じではない可能性があります。 通常は、組織は小規模なもので始め、成熟度やモデル カタログ、経験が増えるにつれて拡大していきます。

機械学習の操作用の成熟度モデルは、組織が機械学習の操作に関する成熟度のスケールのどの段階にあるかを確認し、将来の成長に備えて計画するのに役立ちます。

機械学習の操作と DevOps との違い

機械学習の操作は、いくつかの主要な領域で DevOps とは異なります。 機械学習の操作には、次の特性があります。

  • 開発と運用に先立って探索を行う。
  • データ サイエンスのライフサイクルに適応性のある作業方法が求められる。
  • データの品質による制限や可用性による制限が進行する。
  • DevOps より大きな運用作業が必要になる。
  • 作業チームには、スペシャリストとドメイン エキスパートが必要になる。

概要については、機械学習の操作の 7 つの原則をレビューしてください。

開発と運用に先立って探索を行う

データ サイエンスのプロジェクトは、アプリケーション開発やデータ エンジニアリングのプロジェクトとは異なります。 データ サイエンスのプロジェクトの中には、運用環境にたどり着かないものもありますが、多くの場合、従来のデプロイよりも多くのステップが必要になります。 最初の分析を行った際に、使用可能なデータセットではビジネスの成果を達成できないことが明らかになることがあります。 詳しく説明すると、データ サイエンスのプロジェクトでは通常、探索フェーズが最初のステップとなります。

探索フェーズのゴールは、問題を定義して絞り込むことです。 このフェーズでは、データ サイエンティストが探索的データの解析を実行します。 統計と視覚化を使用して問題の仮説を裏付けたり、あるいはこれが誤っていることを立証したりします。 利害関係者は、プロジェクトがこのフェーズを超えられない可能性がある、という認識を持つ必要があります。 同時に、このフェーズを可能な限りシームレスにし、迅速な転換を実現することが重要です。 解決する問題にセキュリティ上の要素が含まれている場合を除き、プロセスや手順で探索フェーズを制限することは避けてください。 データ サイエンティストがお気に入りのツールやデータを操作できるようにする必要があります。 この探索作業には、実際のデータが必要です。

利害関係者が、データ サイエンスのプロジェクトが実現可能であり、実際にビジネス価値を提供できるという確証を得られた時に、このプロジェクトを実験と開発のステージに移行できます。 このステージでは、開発手法がますます重要になります。 このステージで行われるすべての実験のメトリックを記録することをお勧めします。 また、モデルを比較したり、異なるバージョンのコードに切り替えたりできるように、ソース管理を導入することも重要です。

開発活動には、反復可能な実験パイプラインへの、探索コードのリファクタリング、テスト、自動化が含まれます。 組織は、モデルを提供するアプリケーションやパイプラインを作成する必要があります。 コードを、モジュール型のコンポーネントやライブラリにリファクタリングすることで、再利用性とテストが向上し、パフォーマンスの最適化が可能になります。

最後に、モデルを提供するアプリケーションやバッチ推論パイプラインが、ステージング環境や運用環境にデプロイされます。 機械学習モデル デプロイでは、標準的なアプリケーションの場合と同様にインフラストラクチャの信頼性とパフォーマンスをモニターするだけでなく、データの品質、データ プロファイル、モデルを、劣化やドリフトを考慮して継続的にモニターする必要があります。 機械学習モデルの場合、変化する環境に即したものであり続けるためには、時間の経過と共に再トレーニングを行う必要もあります。

Diagram of the machine learning DevOps stages explore, experiment and develop, and operate.

適応性のある作業方法が求められるデータ サイエンスのライフサイクル

データの性質と品質は最初は不確実であるため、データ サイエンスのプロジェクトに一般的な DevOps プロセスを適用しても、ビジネス上のゴールを達成できない場合があります。 機械学習のプロセスを通して、探索と実験は繰り返し行われる、必要な活動です。 Microsoft のチームでは、データ サイエンス固有の活動の性質を反映するプロジェクト ライフサイクルと作業プロセスを使用しています。 Team Data Science Process と Data Science Lifecycle Process は、参照実装の例です。

データの品質による制限や可用性による制限が進行する

機械学習チームが機械学習を取り入れたアプリケーションを効果的に開発するためには、関係するすべての作業環境で運用データにアクセスできることが望まれます。 コンプライアンス要件や技術的な制約により運用データにアクセスできない場合は、ユーザーの生産性を向上させるため、Azure Machine Learning の Azure ロールベースのアクセス制御 (Azure RBAC)、Just-in-Time アクセス、またはデータ移動パイプラインを実装して、運用データのレプリカを作成することを検討してください。

機械学習には、より大きな運用作業が必要

従来のソフトウェアとは異なり、機械学習ソリューションはデータ品質に依存するため、そのパフォーマンスは絶えずリスクにさらされています。 運用環境で定性的なソリューションを維持するためには、データとモデルの品質を両方とも継続的にモニターして再評価することが重要です。 運用モデルでは、タイムリーな再トレーニング、再デプロイ、チューニングが必要になることが予想されます。 これらのタスクは、日々のセキュリティ、インフラストラクチャのモニター、コンプライアンスの要件に加えて、特別な専門知識を必要とします。

機械学習チームには、スペシャリストとドメイン エキスパートが必要

データ サイエンスのプロジェクトは通常の IT プロジェクトと役割が重複していますが、機械学習の作業が成功するかどうかは、必要不可欠な機械学習テクノロジのスペシャリストとその分野の専門家がいることに大きく依存します。 テクノロジのスペシャリストは、エンドツーエンドの機械学習の実験を行う適切なバックグラウンドを持っています。 ドメイン エキスパートは、データを分析して合成したり、データを使用するために適格化したりして、スペシャリストをサポートできます。

データ サイエンスのプロジェクトに特有の一般的な技術的役割としては、ドメイン エキスパート、データ エンジニア、データ サイエンティスト、AI エンジニア、モデル検証担当者、機械学習エンジニアがあります。 一般的なデータ サイエンス チームの役割とタスクの詳細については、Team Data Science Process に関するページを参照してください。

機械学習の操作の 7 つの原則

組織に機械学習の操作を導入する予定の場合は、基礎として以下の基本原則を適用することを検討してください。

  • コード、データ、実験の出力にバージョン コントロールを使用する。 従来のソフトウェア開発とは異なり、データは機械学習モデルの品質に直接影響します。 実験や推論の結果を再現できるよう、実験コード ベースのバージョン管理に加えて、データセットのバージョン管理を行う必要があります。 モデルのような実験の出力をバージョン管理すると、その再構築に必要な作業量と評価コストを節約できます。

  • 複数の環境を使用する。 開発とテストを運用作業から分離するため、少なくとも 2 つの環境にインフラストラクチャをレプリケートします。 ユーザーに対するアクセスの制御は、環境ごとに異なる場合があります。

  • インフラストラクチャと構成をコードとして管理する。 作業環境でインフラストラクチャ コンポーネントを作成および更新する場合は、コードとしてのインフラストラクチャを使用して、環境内で不整合が発展しないようにする必要があります。 複数の環境で実験のバージョンを簡単に再実行したり再利用したりできるように、機械学習の実験のジョブの仕様をコードとして管理します。

  • 機械学習の実験を追跡したり管理したりする。 機械学習の実験に関する主要業績評価指標やその他の成果物を追跡します。 ジョブのパフォーマンスの履歴を残しておくと、実験の成功を定量的に解析し、チームのコラボレーションと機敏性を向上させることができます。

  • コードのテストを行い、データの整合性を検証し、モデルの品質を確認する。データ準備の正しさ、特徴抽出関数、データ整合性、モデルのパフォーマンスについて実験コード ベースをテストします。

  • 機械学習の継続的インテグレーションとデリバリー。 継続的インテグレーション (CI) を使用して、チームでのテスト実行を自動化します。 継続的トレーニング パイプラインの一部にモデル トレーニングを含めます。 リリースの一部に A/B テストを含め、定性的なモデルだけが運用環境で使用されるようにします。

  • サービス、モデル、データをモニターする。 機械学習の操作の環境でモデルを提供する際は、サービスをモニターし、インフラストラクチャのアップタイム、コンプライアンス、モデルの品質を確認することが重要です。 モニターを設定して、データとモデルのドリフトを特定し、再トレーニングが必要かどうかを把握します。 自動再トレーニングのトリガーを設定することを検討してください。

Azure Machine Learning からのベスト プラクティス

Azure Machine Learning には、機械学習モデルのトレーニングとデプロイを行うワークフローのライフサイクルの管理に役立つ、資産管理、オーケストレーション、オートメーション サービスが用意されています。 Azure Machine Learning でサポートされる人、プロセス、テクノロジの各リソース領域に機械学習の操作を適用するためのベスト プラクティスとおすすめ候補についてレビューします。

ユーザー

  • 組織内のスペシャリストと専門家の知識を最大限に利用できるよう、作業はプロジェクト チーム単位で行います。 Azure Machine Learning ワークスペースをプロジェクトごとに設定し、ユース ケースの分離要件に準拠するようにします。

  • 一連の責任とタスクを役割として定義し、機械学習の操作のプロジェクト チームのメンバーが複数の役割に割り当てられてその役割を果たすことができるようにします。 Azure のカスタム役割を使用して、各役割が実行できる一連の Azure Machine Learning の Azure RBAC 操作を詳細に定義します。

  • プロジェクトのライフサイクルとアジャイル方式の標準化を行います。 Team Data Science Process には、ライフサイクル実装の参照情報が記載されています。

  • バランスの取れたチームは、探索から開発、運用まで、すべての機械学習の操作のステージを実行することができます。

Process

  • コード テンプレートを標準化することでコードの再利用を可能にし、新しいプロジェクトに対する準備を整える時間またはプロジェクトに新しいチーム メンバーが参加した時にかかる時間を短縮します。 新しいテンプレートの基礎として、Azure Machine Learning パイプライン、ジョブの投入スクリプト、CI/CD パイプラインを使用します。

  • バージョン コントロールを使用します。 Git のフォルダーから送信されたジョブでは、再現性のために Azure Machine Learning のジョブでリポジトリのメタデータが自動的に追跡されます。

  • 実験の入力と出力のバージョン管理を使用して、再現性を高めます。 バージョン管理のためには、Azure Machine Learning データセット、モデル管理、環境管理機能が役立ちます。

  • 比較、計画、コラボレーションのために、実験の実行の実行履歴を構築します。 メトリックを収集するには、Mlflow のような実験追跡フレームワークを使用します。

  • 実験コード ベース全体の CI により、チームの作業品質を継続的に測定してコントロールします。

  • モデルが収束しない場合は、プロセスの早い段階でトレーニングを終了させます。 ジョブの実行をモニターするには、実験追跡フレームワークと Azure Machine Learning の実行履歴を使用します。

  • 実験とモデルの管理戦略を定義します。 現在のベースライン モデルを参照するのに champion のような名前を使用することを検討してください。 challenger モデルは、運用環境にあるchampion モデルを上回る可能性がある候補モデルです。 Azure Machine Learning のタグを適用して、実験とモデルをマークします。 売上予測などのシナリオでは、モデルの予測が正確かどうかを判断するのに数か月かかることがあります。

  • モデル トレーニングをビルドに含めることで、CI を継続的トレーニングに昇格させます。 たとえば、pull request のたびに、全データセットに対するモデル トレーニングを開始するなどです。

  • データ サンプルで自動ビルドを実行することで、機械学習パイプラインの品質に対するフィードバックを取得するまでの時間を短縮します。 Azure Machine Learning パイプライン パラメーターを使用して、入力データセットをパラメーター化します。

  • 機械学習モデルの継続的デプロイ (CD) を使用して、Azure 環境でリアルタイム スコアリング サービスのデプロイとテストを自動化します。

  • 規制のある業界では、機械学習モデルを運用環境で使用する前に、モデルの検証ステップを完了することが必要になる場合があります。 検証ステップを自動化することで、デリバリーまでの時間を短縮することができます。 手動でのレビューや検証ステップが依然としてボトルネックとなっている場合は、自動化されたモデルの検証パイプラインを認定できないかどうかを検討します。 Azure Machine Learning のリソース タグを使用して、資産のコンプライアンスやレビューの候補、またはデプロイのトリガーを示します。

  • 統合テストを行わずに、運用環境で再トレーニングを行ってから運用モデルを直接置き換えることはしないようにしてください。 モデルのパフォーマンスと機能の要件が良好に思えても、その他の潜在的な問題がある中で、再トレーニングされたモデルの環境占有領域が大きくなり、サーバー環境が破壊される場合があります。

  • 運用データへのアクセスが運用環境でのみ可能な場合は、AZURE RBAC とカスタム役割を使用して、限られた人数の機械学習担当者に読み取りアクセス権を付与します。 役割によっては、関連するデータの探索のためにデータを読み取る必要が生じる場合があるからです。 または、コピーしたデータを非運用環境で使用できるようにします。

  • ベースラインの機械学習パイプラインの再トレーニングと実験作業を区別するために、Azure Machine Learning 実験の名前付け規則とタグについて合意しておきます。

テクノロジ

  • 現在 Azure Machine Learning スタジオの UI や CLI でジョブを送信している場合、SDK 経由でジョブを送信する代わりに CLI または Azure DevOps Machine Learning タスクを使用することで、自動化パイプラインのステップを設定できます。 このプロセスでは自動化パイプラインから直接同じジョブの送信を再利用するため、コードのフットプリントを減らすことができます。

  • イベントベースのプログラミングを使用します。 たとえば、新しいモデルを登録した後に Azure Functions を使用してオフライン モデルのテスト パイプラインをトリガーするなどです。 または、重要なパイプラインの実行に失敗したときに、指定されたメールアドレスの別名に通知を送信するなどです。 Azure Machine Learning により、イベントが Azure Event Grid に作成されます。 複数の役割が、イベントの通知にサブスクライブできます。

  • Azure DevOps を使用して自動化を行う場合は、Machine Learning の Azure DevOps タスクを使用して、機械学習モデルをパイプライン トリガーとして使用します。

  • 機械学習アプリケーションの Python パッケージを開発する場合は、それらを Azure DevOps リポジトリで成果物としてホストし、フィードとして公開することができます。 この方法を使用して、パッケージをビルドするための DevOps ワークフローを Azure Machine Learning ワークスペースに統合することができます。

  • 上流または下流のアプリケーション コンポーネントと機械学習パイプラインのシステム統合をテストするために、ステージング環境の使用を検討します。

  • デバッグを強化し、デプロイまでの時間を短縮するために、推論エンドポイントの単体テストと統合テストを作成します。

  • 再トレーニングをトリガーするには、データセット モニターとイベント ドリブン ワークフローを使用します。 データ ドリフト イベントにサブスクライブし、再トレーニング用の機械学習パイプラインのトリガーを自動化します。

組織の機械学習の操作向けの AI Factory

あるデータ サイエンス チームが、複数の機械学習のユース ケースを内部で管理できると判断したとします。 機械学習の操作を採用すると、組織がソリューションの品質、信頼性、保守性を向上させることができるプロジェクト チームを立ち上げるのに役立ちます。 バランスの取れたチーム、サポートされたプロセス、テクノロジの自動化によって、機械学習の操作を採用するチームは新しいユース ケースをスケーリングし、その開発に集中することができるようになります。

組織内のユース ケースの数が増えると、このユース ケースをサポートするための管理負担も直線的に、あるいはそれ以上に大きくなります。 組織の課題となるのは、市場投入までの時間を短縮し、ユース ケースの実行可能性の迅速な評価をサポートし、再現性を実装し、利用可能なリソースとスキル セットをプロジェクトの範囲で最も有効に活用する方法です。 多くの組織にとって、AI Factory の開発がソリューションになります。

AI Factory とは、反復可能なビジネス プロセスと標準化された成果物のシステムで、大量の機械学習ユース ケースの開発とデプロイを支援します。 AI Factory は、チームの立ち上げ、推奨されるプラクティス、機械学習の操作の戦略、アーキテクチャ パターン、ビジネス要件に合わせた再利用可能なテンプレートを最適化します。

AI Factory の成功は、組織が数十のユース ケースから数千ものユース ケースへと効率的に拡張するのに役立つ、反復可能なプロセスと再利用可能な資産に依存しています。

次の図は、AI Factory の主要な要素をまとめたものです。

Diagram of the key elements of an AI factory.

反復可能なアーキテクチャ パターンの標準化

反復可能性は AI Factory の主要な特徴です。 データ サイエンス チームは、組織の機械学習のほとんどのユース ケースに対応できる少数の反復可能なアーキテクチャ パターンを開発することで、プロジェクトの開発を促進し、プロジェクト間の一貫性を向上させることができます。 これらのパターンを導入すれば、ほとんどのプロジェクトでこれらのパターンを使用し、次のベネフィットを得ることができます。

  • 設計フェーズの高速化
  • プロジェクト間でツールを再利用する際の IT およびセキュリティ チームからの承認の迅速化
  • コード テンプレートやプロジェクト テンプレートとして再利用可能なインフラストラクチャによる開発の高速化

アーキテクチャのパターンには、以下のようなトピックが含まれますが、これに限定されるものではありません。

  • プロジェクトの各ステージで推奨されるサービス
  • データの接続性とガバナンス
  • 業界、ビジネス、データ分類の要件に合わせた機械学習の操作の戦略
  • 実験管理の Champion および Challenger モデル

チーム間でのコラボレーションと共有の促進

コード リポジトリやユーティリティを共有することで、機械学習ソリューションの開発を加速させることができます。 コード リポジトリは、プロジェクトの開発中にモジュール形式の方法で開発でき、他のプロジェクト内でも使用できるように汎用性を持たせることができます。 これは、すべてのデータ サイエンス チームがアクセスできる中央リポジトリで利用できるようにすることができます。

知的財産の共有と再利用

コードを最大限に再利用可能にするには、プロジェクトの開始時に、次の知的財産をレビューする必要があります。

  • 組織内での再利用を目的として設計された内部コード。 例として、パッケージやモジュールがあります。
  • 他の機械学習プロジェクトで作成された、または Azure エコシステムで利用可能なデータセット。
  • 類似したアーキテクチャとビジネス上の問題を持つ既存のデータ サイエンス プロジェクト。
  • プロジェクトを加速させることができる GitHub やオープンソースのリポジトリ。

プロジェクトの振り返りに、プロジェクトの要素を共有し、より広範に再利用するために一般化することができるかどうかを検討する実施項目を含める必要があります。 組織が共有して再利用できる資産のリストは、時間とともに拡大していきます。

共有と検出に役立てるため、多くの組織がコード スニペットや機械学習の成果物を整理するための共有リポジトリを導入しています。 データセット、モデル、環境、パイプラインなどの Azure Machine Learning の成果物は、コードとして定義することができるので、プロジェクトやワークスペース間で効率的に共有することができます。

プロジェクト テンプレート

既存のソリューションの移行のプロセスを加速し、コードの再利用を最大化するために、多くの組織は新しいプロジェクトを開始するためのプロジェクト テンプレートを標準化しています。 Azure Machine Learning との併用が推奨されるプロジェクト テンプレートの例としては Azure Machine Learning の例、The Data Science Lifecycle Process、Team Data Science Process などがあります。

中央データ管理

探索または運用時の使用のためにデータにアクセスするプロセスには、時間がかかることがあります。 多くの組織では、データの作成者とデータ コンシューマーを結びつけ、機械学習の実験のためのデータへのアクセスを容易にするために、データ管理を一元化しています。

ユーティリティの共有

組織は、エンタープライズ規模で使用できる集中ダッシュボードを使用して、ログとモニターの情報を統合できます。 ダッシュボードには、エラー ログ、サービスの可用性とテレメトリ、モデルのパフォーマンス モニターが含まれる場合があります。

Azure Machine Learning や、Azure Storage などの関連サービスについては、Azure Monitor メトリックを使用してダッシュボードをビルドします。 ダッシュボードは、実験の進捗状況、コンピューティング インフラストラクチャの正常性、GPU クォータの使用状況を追跡するのに役立ちます。

スペシャリストからなる機械学習のエンジニアリング チーム

多くの組織では、機械学習エンジニアの役割を実装しています。 機械学習エンジニアは、堅牢な機械学習パイプラインの作成と実行、ワークフローのドリフトのモニターと再トレーニング、ダッシュボードのモニターを専門としています。 エンジニアは、機械学習ソリューションを開発から運用まで一貫して遂行する責任を担います。 エンジニアは、Data Engineering、アーキテクト、セキュリティ、操作の担当者と密接に連携し、必要なコントロールがすべて行われていることを確認します。

データ サイエンスが深い専門知識を必要とするのに対し、機械学習エンジニアリングはより技術的な側面が強い分野です。 この違いがあるため、機械学習エンジニアは柔軟に対応でき、様々なプロジェクトに取り組んだり様々なビジネス部署と協働したりできます。 大規模なデータ サイエンスの運用では、様々なユース ケースやビジネス領域での自動化ワークフローの反復可能性と再利用を促進するスペシャリストからなる機械学習のエンジニアリング チームがいることで、そのベネフィットを受けることができます。

イネーブルメントとドキュメント化

新規および既存のチームやユーザーに対して、AI Factory のプロセスに関する明確なガイダンスを提供することが重要です。 ガイダンスにより一貫性が確保され、機械学習エンジニアリング チームがプロジェクトを遂行する際に必要な作業量が軽減されます。 組織内の様々な役割に特化したコンテンツを設計するよう検討してください。

誰もが異なる学習方法を持っているため、以下の種類のガイダンスを組み合わせることで、AI Factory フレームワークの導入を加速させることができます。

  • すべての成果物へのリンクが掲載されている中央ハブ。 たとえば、このハブには、Microsoft Teams や Microsoft SharePoint のサイト上のチャネルなどが該当します。
  • 役割ごとに設計されたトレーニングおよびイネーブルメント プラン。
  • そのアプローチに関する大まかな概要のプレゼンテーションと補足のビデオ。
  • 詳細なドキュメントまたはプレイブック。
  • 操作方法に関するビデオ。
  • 準備完了評価。

Azure での機械学習の操作のビデオ シリーズ

Azure での機械学習の操作に関するビデオ シリーズでは、初期開発から運用まで、ご自分の機械学習ソリューションで機械学習の操作を確立する方法について説明しています。

倫理

倫理は、AI ソリューションの設計において、重要な役割を果たします。 倫理原則が実装されていない場合、トレーニングされたモデルは、トレーニングに使用されたデータに存在するのと同じ偏りを示す可能性があります。 その結果、プロジェクトが停止する可能性があります。 さらに重要なのは、組織の評判を危険にさらす可能性があることです。

組織が支持する主要な倫理原則がプロジェクト全体で確実に実施されるようにするためには、組織はこれらの原則のリストと、テスト フェーズで技術的な分析観点からそれらを検証する方法を提供する必要があります。 Azure Machine Learning の機械学習フィーチャーを使って、信頼できる機械学習とは何かを把握し、それを機械学習の操作に組み込む方法を把握しましょう。

次の手順

次の記事で Azure Machine Learning 環境を整理および設定する方法の詳細について学ぶか、または Azure での機械学習の操作に関する実践的なビデオ シリーズを見ます。

Azure Machine Learning 環境の整理とセットアップ

次の記事で、Azure Machine Learning を使用して組織レベルで予算、クォータ、コストを管理する方法の詳細を学びます。

Azure Machine Learning で機械学習の予算、コスト、クォータを管理する