Azure Machine Learning のエンジニア的 に推せる機能と MLOps のためのアーキテクチャ 日本マイクロソフト株式会社 Cloud Solution Architect 伊藤 駿汰

自己紹介  伊藤 駿汰 (Shunta Ito)  所属  Cloud Solution Architect - AI @ 日本マイクロソフト  ソフトウェアエンジニア @ Omamori  趣味  料理  映画/アニメ/ドラマ鑑賞  近況  技術書典で Azure Machine Learning 本書いた、商業でも Azure Machine Learning 本 を出したい @ep_ito

🤔 別にわざわざ Azure 使わ なくても MLOps の仕組 みは実装できるでしょ？ 今更ベンダーの人間が何 喋るの？

🤔 Azure 使ってないしもう AWS/GCP で実装し ちゃってるから聞く意 味なくない？

目次  Azure Machine Learning 概要  推し機能  VSCode 連携  MLflow 連携  CLI v2 / SDK v2  Registry  MLOps アーキテクチャ  LLM と Azure Machine Learning

Azure Machine Learning とは？ https://docs.microsoft.com/ja-jp/azure/machine-learning/overview-what-is-azure-machine-learning 機械学習の各プロセスから MLOps まで幅広くサポートする 『機械学習プラットフォーム』

Azure Machine Learning の全体像 Workspace に各リソースとアセットが紐づく Azure Synapse Analytics Azure Kubernetes Service Azure Arc Power BI Microsoft Purview (他) 計算リソース Datastores (Blob/ADLS2, etc.) Data Jobs Components Environments Models Endpoints サービス連携 依存サービス Workspace Azure Key Vault Azure Container Registry Azure Storage Account Azure Application Insights アセット Pipelines データ保管 Compute instances Compute clusters Kubernetes compute Spark compute

例: ジョブの構成  アセット  Data : データセット  Environment : Python 環境定義  Compute Cluster : 計算リソース  Python コード  ジョブ定義  使用するアセットや Python のスクリプト、 渡す引数などを指定したもの マウント Azure Data Lake Storage Gen2 Job Environments Azure Container Registry Data Models Compute Instance Compute Clusters ビルド&push ジョブ 送信 学習 コード等 ローカル環境

要するに……？ AWS おける SageMaker、Google Cloud における Vertex AI に相当する、Azure における ML プラットフォーム 機械学習周りの色々をサポートするサービス  Notebook 簡単に使える  機械学習ジョブを投げられる  実験記録・モデル記録を取れる  パイプラインを作れる  ML API をデプロイできる  …他にも色々 クラウドベンダークッソ競争してる から似たようなサービスなら大体似 たことできる理解でヨシ！

推し機能① VSCode 連携

モデル開発段階で使用できる計算リソース  Compute Instance  ユーザー個人向けの開発環境を提供する計算リソース  Azure ML 上の互換 Notebook/Jupyter/JupyterLab/Terminal/VSCode  Compute Cluster  ジョブを投げるためのスケーラビリティに優れた計算リソース  ジョブ定義でノード数などの設定に触れるだけ、基本的にタッチしない  Serverless Spark  Spark による分散処理を提供する計算リソース  データの前処理 (特徴量エンジニアリング) が主な用途

VSCode 連携  Compute Instance と VSCode を接続する機能  Web 版とデスクトップ版そ れぞれの VSCode に対応  SSH 設定不要、Compute Instance のデプロイ後ワン クリックで接続

なぜ推すのか？ 1. スクリプトの実装に入ると Jupyter や Azure Machine Learning Notebook はエディタとして機能不足、VSCode 使いたい 2. SSH 周りの設定を省略して Azure Active Directory による認証だ けで VSCode に接続できる、簡単でセキュリティ的にも嬉しい

推し機能② MLflow 連携

MLflow とは  機械学習のライフサイクルを管理する OSS プラットフォーム  実験管理、コードのパッケージ化、モデル管理、モデル登録、パイ プラインの5要素 Tracking 実験の記録とクエリ (コード、データ、 構成設定、結果) コードのパッケージ化 による再現性を 実現する形式 Projects Model Registry 一元的なモデルの ライフサイクル管理 Models フレームワーク非依 存なモデルの統一的 フォーマット Recipes モデルの開発とデプ ロイを支えるパイプラ インの構築

MLflow Tracking による実験管理  Tracking 単位  1回のコード実行≒Run  Run は入れ子にもできる  1個以上の Run を含む実験全体 =Experiment  記録対象  モデルの設定値、ハイパーパラ メーター  RMSE、AUC などの精度指標  画像、モデルファイルなどの任 意のファイル Experiment 売上予測モデル作成 Run 1 モデル: LightGBM パラメーター: n_estimator=50, num_leaves… メトリック: R2=0.823 Run 2 モデル: LightGBM パラメーター: n_estimator=30, num_leaves… メトリック: R2=0.802 Run 3 パラメーターチューニング Child Run 1 パラメーター: n_estimator=50, num_leaves… メトリック: R2=0.823 Child Run 2 パラメーター: n_estimator=40, num_leaves… メトリック: R2=0.802

MLflow による実験記録 1. Experiment 名を決める 2. Run を開始する 3. 記録を取る  パラメーターを記録する  メトリックを記録する  ファイルを記録する 4. Run を終了する 5. モデルを登録する

MLflow による実験記録 対応ライブラリなら autolog でパラメーター もメトリックもモデルも全自動で記録

MLflow Tracking Server  実験のログやモデルを保存するための API サーバー  Backend Store  ローカルファイルか RDB (MySQL, PostgreSQL, SQLite, SQL Server)  Artifact Store  SFTP, NFS, HDFS などでアクセス可能なストレージかクラウド上のブ ロックストレージ  MLflow の Client と REST API で通信  各種実験ログは Backend Store に保存される (1a, 1b)  モデルやその他のファイル群 (log_artifact で保存される全て のファイル) は Artifact Store に保存され、 URI が Backend Store に保存される (2a, 2b, 2c) https://www.mlflow.org/docs/latest/tracking.html#mlflow-tracking-servers

Azure Machine Learning as MLflow Tracking Server https://www.mlflow.org/docs/latest/tracking.html#mlflow-tracking-servers Azure Machine Learning Azure Active Directory による ID 管理と制御

MLflow Models  フレームワーク、モデルの保存形式、読み込み・書き込み、モデル の入出力を抽象化するコンポーネント ➢学習に使用したフレームワークや実装に依らず、 MLflow の API を 使用してモデルを統一的に取り扱うことができる ➢ノーコードでモデルデプロイを実現 Models 入出力形式等 のメタデータ 実行環境 モデル

 説明変数を受け取りモデルによる推論 結果を返す API をデプロイする仕組み  1つの Endpoint はDeployment を複数 個持つことができる  各 Deployment へのリクエスト配分を 自由に設定できる Online Endpoint Deployment Model Model Endpoint Deployment ユーザー

 Compute Cluster を使用した並列バッ チ推論の仕組み  推論対象のファイル群を複数ノードで 分担して読み込み推論結果を付与する  内実は Job、バッチ推論をトリガーす るための専用 Endpoint が作られる Batch Endpoint Datastore Data Compute Cluster Model predictions.csv

ほぼ計算リソース指定 のみ、とても楽

なぜ推すのか？ 1. MLflow Models のモデル抽象化機能が非常に優秀、モデルの可搬 性を高め、デプロイの大幅簡略化が可能 2. Azure Machine Learning から離れる場合でもほぼコードの変更な しに動作可能な状態を保つことができる ※ MLflow Tracking Server の用意が必要 3. 機械学習のコードの奥深くにベンダー固有の不安定 (関数仕様が ころころ変わるの意) な SDK を入れて汚染したくない ➢ 現在の Azure Machine Learning では実験記録を取りたければ MLflow を使う以外の選択肢 がなくなった

推し機能③ Azure Machine Learning CLI v2

アセット操作＆ジョブ定義を行う手段 AzureML SDK v2  Python のコード AzureML CLI v2  コマンド + yaml ファイル

補足: v2 って？  2022/05 末に登場した Azure Machine Learning の新 API  混み入っていたアセットの概念が整理され、強化された  v2 API から CLI でできることが大幅に拡充された  v1 ではアセット操作・ジョブ実行は SDK の仕事で CLI はリソースレベルの管理 (権限管理 とか計算リソース割り当てとか) のみ  v2 からは SDK と CLI 双方で AzureML のアセット操作・ジョブ実行も可能に  SDK で破壊的変更  ログ記録機能廃止＆ MLflow への一本化  独自路線だった API 構成を廃止、他の Azure SDK と実装パターンを統一

なぜ推すのか？ 1. yaml 形式でジョブやアセットを静的に定義することができるよう になり、git で管理しやすい上に見通しが良くなった 2. az コマンド + yaml ファイルでほとんどのアセット操作やジョブ 実行が可能になったことで、Github Actions のようなワークフ ローツールと組み合わせやすくなった ➢ 自動化の仕組みを実装しやすくなった

推し機能④ Registry

 Pipeline を構成する Component、 Model、Environment をWorkspace をまたいで共有する仕組み  組織横断的にアセットを発見・再利用 する用途に加え、ステージの異なる Workspace 間でアセットを転送する 用途としても使用可能 Registry • Compute 作成 • ジョブ実行 • Endpoint 作成 Workspace チーム A Workspace チームB Workspace チームC アセット作成: Model Component Environment Data Registry

なぜ推すのか？ 1. かつて Workspace をまたぐアセットの共有が困難の極みだった がこれを解決した 2. アセット共有が可能になったことで Workspace の割り当て単位 の自由度が上がり、組織の規模や段階、利用形態に合わせたアー キテクチャ構成が可能になった

本番環境と開発環境 組織規模の拡大やセキュリティ等の理由により開発チームと運用 チームそれぞれに別個の Workspace が割り当てられる状況 ➢開発チームから運用チームへ Model、Environment、Component を共有するための Registry (開発チーム: R/W 運用チーム: Read) モデル開発チーム モデル運用チーム Azure Machine Learning Registries

機械学習の民主化 専任チームや IT 部門以外の各部門や各チーム単位で機械学習を行う ニーズが生じ、個別に Workspace が割り当てられる状況 ➢共有が必要な組織単位ごとの Registry (R/W) + 組織横断の Registry (管理部門: R/W その他: Read) 部門A チーム1 部門A チーム2 部門A チーム3 部門A Registry 部門B チーム1 部門B チーム2 部門B Registry 部門横断 Registry 管理部門

MLOps 実装

ML プロジェクトのループ構造  Inner Loop  モデルの探索と仮説検証  人間によるインタラクティブ な試行  Middle Loop  本番投入可能なモデルの探索  再実行可能なパイプライン  Outer Loop  モデルの継続的監視と メンテナンス モニタリング 自動学習 本番デプロイ 推論 学習パイプ ライン パラメーター チューニング モデルQA 学習 評価 モデル選定 ➢ 「MLOps」は各要素およびループの間をつなぎ、円滑化を目指す

成熟度モデル https://docs.microsoft.com/ja-JP/azure/architecture/example-scenario/mlops/mlops-maturity-model https://techcommunity.microsoft.com/t5/ai-machine-learning-blog/mlops-maturity-model-with-azure-machine-learning/ba-p/3520625 Level 概要 技術 文化 Level 0 No MLOps • 機械学習モデルのライフサイクル全体を 管理することは困難 • チームは別々で、リリースは困難 • ほとんどのシステムは "ブラック ボックス " として存在し、デプロイ時およびデプロ イ後のフィードバックはほとんどなし • 手動によるビルドとデプロイ • モデルおよびアプリケーションの手動に よるテスト • モデルのパフォーマンスの一元的追跡な しモデル学習は手動 • まず動くものを作り上げ、スモールス タートでプロジェクトを推進する Level 1 DevOps no MLOps • Level 0 よりもリリースの苦労は少ないが、 新しいモデルごとにデータ チームに依存 • 運用段階でのモデルのパフォーマンスに 関するフィードバックは依然として限ら れる • 結果の追跡および再現が困難 • 自動ビルド • アプリケーション コードの自動テスト • チーム内でのコード共有とレビューを行 う • パイプラインなどの自動化技術を活用し て、低摩擦に継続的に本番投入する • テストなどによりコード品質に配慮する Level 2 Automated Training • トレーニング環境は完全に管理され、追 跡可能 • モデルの再現が容易 • リリースは手動であるが、摩擦は少ない • 自動化されたモデルの学習 • モデル学習のパフォーマンスを一元的に 追跡 • モデル管理 • 機械学習固有の性質に配慮した自動化を 行う • 機械学習実験の再現性確保に注意を払う Level 3 Automated Model Deployment • リリースは低摩擦で自動 • デプロイから元のデータまで完全に追跡 可能 • 環境全体 (学習 > テスト > 運用) を管理 • デプロイするモデルのパフォーマンスに 関する A/B テストを統合 • すべてのコードのテストを自動化 • モデルの学習性能を一元化 • 機械学習モデルの品質に配慮する • 投入先ソフトウェア開発チームと連携し た継続的モデルデプロイとその自動化を 推進する Level 4 Full MLOps Automated Retraining • システムを完全自動化し、監視を容易化 • 運用システムは、改善方法に関する情報 を提供。場合によっては、新しいモデル で自動的に改善 • ゼロ ダウンタイム システムに近づく • モデル学習とテストを自動化 • デプロイされたモデルからの詳細で一元 化されたメトリック • 機械学習モデルの経時的な劣化を前提と した監視体制を整備する • 手動で実行する必要が無い部分について 自動化を進め、「最大効率で機械学習モ デルを運用できる体制」を目指す

Step by Step MLOps 6/12 に v1.2 を公開しました

Level 2 – Automated Training Mount/Download Azure Synapse Pipeline Azure Data Lake Storage Gen2 Job Environments Azure Container Registry Data Models Managed (Online/Batch) Endpoint Code Checkout Managed (Online/Batch) Endpoint GitHub Model Training Code Test, Data Check Model Training Model Evaluation Responsible AI container Compute Instance Compute Clusters build&push build&push job submit experiment log/metric Register model deploy manually deploy manually Data Prep Training (pipeline) Azure Machine Learning Python SDK/CLI Azure Machine Learning Components CLI v2 によりワークフロー実装が簡易に Github と連携した CI/CD/CT が可能に CLI v2 によるジョブ実装の簡素化 MLflow との連携で実験記録やモデル記 録の記述も比較的簡素化 VSCode 利用でスクリプト開発を効率化 モダンなコーディング体験

Level 3 – Automated Model Deplyment Mount/Download Azure Synapse Pipeline Azure Data Lake Storage Gen2 Job Environments Azure Container Registry Data Prep Data Models Managed (Online/Batch) Endpoint Code Checkout Managed (Online/Batch) Endpoint GitHub Model Training Code Test, Data Check Model Training Model Evaluation Responsible AI Deploy to Stage Deploy to Stage Model Test Responsible AI container Gated approval Deploy to Prod Deploy to Prod Model Test ResponsibleAI Safe Rollout Compute Instance Compute Clusters build&push Training (pipeline) Deployment (pipeline) build&push job submit experiment log/metric Register model deploy automatically deploy automatically Event Grid (Model Trigger) (Code Trigger) model register Azure Machine Learning Python SDK/CLI Azure Machine Learning Python SDK/CLI Azure Machine Learning Components Azure Machine Learning Python SDK/CLI Prod Stage Dev Stage MLflow Model 形式を前提 とすることで、API デプロ イが簡素化 Registry により開発環境と 本番環境の分離が可能に

LLMOps と Azure Machine Learning LLM を使用したアプリケーション開発と運用

LLM ワークフロー LLM を用いて外部の API/データソースへのアクセスを必要とする処 理を組み込んだシステムを構成する場合、LLM の出力に基づいて外 部 API/データソースへのアクセスをハンドリングするワークフロー が必要 パーツ 役割 LLM • 意図の分類 • 意図に基づく処理内容の生成 • 外部 API/データソースから提供されたデータを基にした応答生成 ワークフローツール • LLM に対する入力と出力のハンドリング • LLM が出力する意図の分類結果ごとの処理を実行する仕組みの提供 外部 API/データソース • データの提供 • LLM が不得意とする処理を担うエンジンの提供

ユーザーの質問 LLM Workflow データのクエリ Cognitive Search プロンプトに結果を追加 テキスト生成 Large Language Model 結果の送信 例: LLM をインターフェースとした検索システムのワークフロー

LLM ワークフローの実装  ChatGPT Plugins  外部データソース/API へのアクセスを提供するマネージドな仕組み  LangChain/Semantic Kernel/Guidance  OSS の LLM アプリケーション作成フレームワーク  LLM ワークフロー実装を補助 (実行計画方式 or ReAct)  LLM を取り扱う上で典型的な実装を抽象化  Azure Machine Learning Prompt flow  LLM ワークフローを実装するマネージドサービス

 選択した フレームワーク と API を使 用して さまざまな 言語モデル と デー タソース を使用する AI ワークフロー を作成  1つのプラットフォームで 生成 AI ワークフロー の 構築、調整、評価を 迅速に反復  事前構築済の指標で AI ワークフロー の品質を評価 Prompt flow (private preview)

◼ 本書に記載した情報は、本書各項目に関する発行日現在の Microsoft の見解を表明するものです。Microsoftは絶えず変化する市場に対応しなければならないため、ここに記載した情報に対していかなる責務を負うものではなく、提示された情報の信憑性につ いては保証できません。 ◼ 本書は情報提供のみを目的としています。 Microsoft は、明示的または暗示的を問わず、本書にいかなる保証も与えるものではありません。 ◼ すべての当該著作権法を遵守することはお客様の責務です。Microsoftの書面による明確な許可なく、本書の如何なる部分についても、転載や検索システムへの格納または挿入を行うことは、どのような形式または手段（電子的、機械的、複写、レコーディング、 その他）、および目的であっても禁じられています。 これらは著作権保護された権利を制限するものではありません。 ◼ Microsoftは、本書の内容を保護する特許、特許出願書、商標、著作権、またはその他の知的財産権を保有する場合があります。Microsoftから書面によるライセンス契約が明確に供給される場合を除いて、本書の提供はこれらの特許、商標、著作権、または その他の知的財産へのライセンスを与えるものではありません。 © 2021 Microsoft Corporation. All rights reserved. Microsoft, Windows, その他本文中に登場した各製品名は、Microsoft Corporation の米国およびその他の国における登録商標または商標です。 その他、記載されている会社名および製品名は、一般に各社の商標です。