Step-by-step MLOps v1.2

▼ 更新情報
・Azure Machine Learning 新機能サポート
　・Managed Feature Store
　・Registry etc...
・パイプラインジョブのデバッグ
・環境分離と計算リソース共有
・LLMOps

▼ Prompt flowの動画
https://www.youtube.com/watch?v=DaIYrlMOj7I

▼こちらのMLOps資料のv1.2版となります。
https://speakerdeck.com/shisyu_gaku/step-by-step-mlops-and-microsoft-products
全く MLOps が無い状態から徐々にステップアップする場合に具体的にどんなアーキテクチャで Azure Machine Learning やその他サービスのどの機能を使用して実装を進めていくか整理した資料を大幅に更新しました。

Transcript

1. Step-by-step MLOps v1.2 Shunta Ito (CSA) Kohei Ogawa (CSA) Keita Onabuta (FTA)
2. 目次  MLOps 概要  Step by Step MLOps  Lv0 No MLOps  Lv1 DevOps no MLOps  Lv2 Automated Training  Lv3 Automated Model Deployment  Lv4 Full MLOps Automated Retraining  Azure Machine Learning における MLOps  各 Lv 別アーキテクチャと Azure サービス詳細  技術詳細  機械学習におけるコード品質  機械学習モデルのテスト  MLflow  Feature Store  デバッグ  環境分離と計算リソース共有  LLMOps
3. MLOps 概要
4. MLOps とは Validate Model Deploy Model Package Model Monitor Model Train Model モデル再学習 開発と学習 ビジネス課題を解 決する パッケージ化 モデルをどこで も使用可能にす る 挙動の検証 応答性の観点と規 制遵守の観点から デプロイ 予測値の生成にモ デルを使用する モニタリング 挙動とビジネス価 値を監視する 陳腐化したモデル をいつ置換/廃止 するか決める 機械学習ライフサイクルを管理する手法・概念、あるいは ML における DevOps
5. 機械学習システム D. Sculley et. al. ,“Hidden Technical Debt in Machine Learning Systems,” Google, NIPS2015. Figure 1: Only a small fraction of real-world ML systems is composed of the ML code, as shown by the small green box in the middle. The required surrounding infrastructure is vast and complex. ML Code Configuration Data Collection Data Verification Feature Extraction Machine Resource Management Analysis Tools Process Management Tools Serving Infrastructure Monitoring
6. 機械学習プロジェクトにおける課題 データの増大、世の中の変化に伴うデータの変化、 要件の変化によるモデル精度の劣化 データサイエンティスト 機械学習およびその周辺の膨大な要素技術と、一部 エンジニア/データサイエンティストへの負荷集中 アセットの属人化、サイロ化による管理・監査の問題と、 チームおよびプロジェクトのスケーラビリティが困難になる問題 モデルに対する信頼性欠如によるプロジェクトの PoC 倒れ
7. 課題に対する技術的アプローチ 自動化/ 可観測性 • コード駆動のアセット生成とデプ ロイ • 再現性と検証可能性を持ったパイ プライン • アセット間の依存関係が明示され、 集中管理された管理体制 検証 • SWE で培われた品質管理のベスト プラクティス適用 • オフラインでのモデル品質検証、 バイアスの最小化と説明性の確保 • メトリックに基づく検証 再現性/監査可能性 • 制御されたロールアウト機能 • 予測性能と期待性能のライブ比較 • ドリフトの監視とモデル改善に使用 できるフィードバック
8. MLOps を実現するための要素 People • チームで共同で開発を進め、他 人が引き継ぐことを前提とした 品質確保を継続的に行う体制構 築と文化醸成 • 無駄なくスキルをビジネス価値 へと転換するために必要な体 制・技術への金銭的/人的投資 Process • 学習やデプロイプロセス等、機 械学習の一連のプロセスに含ま れる定型的処理の自動化 • アセットの集中管理と共有によ る作業効率の向上 • 再現性確保 Platform • アセットを集中管理し共有する ためのハブ • 運用中のパイプライン、インフ ラ、製品を監視し、期待通りの 動作をしていないことを検知す ることが可能な仕組み • 必要に応じて可及的速やかかつ 安全に本番への機能投入を可能 とするシステム
9. ML プロジェクトのループ構造  Inner Loop  モデルの探索と仮説検証  人間によるインタラクティブ な試行  Middle Loop  本番投入可能なモデルの探索  再実行可能なパイプライン  Outer Loop  モデルの継続的監視と メンテナンス モニタリング 自動学習 本番デプロイ 推論 学習パイプ ライン パラメーター チューニング モデルQA 学習 評価 モデル選定 ➢ 「MLOps」は各要素およびループの間をつなぎ、円滑化を目指す
10. 成熟度モデル 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 • システムを完全自動化し、監視を容易化 • 運用システムは、改善方法に関する情報 を提供。場合によっては、新しいモデル で自動的に改善 • ゼロ ダウンタイム システムに近づく • モデル学習とテストを自動化 • デプロイされたモデルからの詳細で一元 化されたメトリック • 機械学習モデルの経時的な劣化を前提と した監視体制を整備する • 手動で実行する必要が無い部分について 自動化を進め、「最大効率で機械学習モ デルを運用できる体制」を目指す
11. Step by Step MLOps
12. Level 0 – No MLOps  インタラクティブかつ実験的に有益なモデルを探す  環境構築、データの取得、デプロイ、テストは手動 データソース データ準備 良いモデルの発見 アルゴリズム選定 手動デプロイ 標準化されていない ML 環境 ML エンジニア データサイエン ティスト 外部ソースからの データの読み込み
13. 課題・チャレンジ 再現性 • 個々にデータサイエンティストが独自にカスタマイズした機械学習ツールやコー ド、Python/Rパッケージを使い学習モデルのジョブを作成しており、組織全体 に共有されず学習モデルのジョブを再現することは非常に困難 品質とセキュリティ • テストが設定されていない • テストポリシーが組織横断的に設計されていない • 機械学習基盤および成果物が管理されておらず、セキュリティ上の懸念がある スケーラビリティ • 大規模なジョブを実行するのに十分なパワーの計算リソースがない • 高価な計算リソースが属人的に管理・使用されて組織内で共有されていないため、 コスト増につながる • 機械学習用のデータソースが整備されておらず、学習データの取得に手作業が必 要
14. Lv0 → Lv1  機械学習プラットフォームの整備 ➢ チーム・組織で共有の機械学習プラットフォームを利用していること  コードを集約するリポジトリホスティング環境の整備  テストの自動化 ➢ 少なくともコードに対するテスト項目がルール化されており、テストの実行が自動化できて いること  データ基盤が整備され始めていること
15. Level 1 – DevOps no MLOps  データパイプラインとマネージドな ML 環境が整備される  テストが整備され始める データパイプライン データカタログ データ準備 良いモデルの発見 アルゴリズム選定 手動デプロイ マネージドな ML 環境 コードレベルの テスト ML エンジニア データサイエンティスト データ エンジニア Capture ✓ コード コードリポジトリ
16. 課題・チャレンジ 再現性 • 機械学習の実験記録が共有可能な形で取られておらず、実験およびジョブの再現 が困難 • 機械学習のライフサイクルを構成するアセットが組織間で共有されていない • 学習モデルワークフローの中に複雑なジョブの依存関係があり、開発者に属人的 となっている
17. Lv1 → Lv2  モデル学習の再現性確保 ➢ 1度やった実験を再現しようと思えばでき、実験の成果物（学習済みモデル等）が 実験と紐づいた形で保管されていること ➢ パイプラインが構築され、確立した手順は簡単に再実行できること ➢ 特徴量が管理・保存され再利用できること  モデルの運用管理 ➢ モデルが管理されており、関連する実験やエンドポイントが紐づくこと
18. Level 2 – Automated Training  コード、データ、特徴量、モデルがバージョン管理され、実験が記録される  モデルの再作成が自動化される データ 準備 アルゴリズム 選定 良いモデル の発見 Capture ✓ データセット ✓ 環境 ✓ コード (スナップショット) ✓ ログ/メトリック ✓ 生成物 履歴の取得と保存 モデル登録 機械学習パイプライン データパイプライン データカタログ ML エンジニア データサイエン ティスト データ エンジニア MLOps エンジニア 特徴量ストア
19. 課題・チャレンジ デプロイ • モデルの用途によって推論環境の実装方法が毎回異なり、デプロイ手順が散在し ている • デプロイ手順が属人化しており共有されておらず、再実行が難しい 品質とセキュリティ • 学習されたモデルの挙動と性能が求める要件を満たしているか検証する手順 (QA) が標準化されていない • 機械学習モデルのテスト工程が全く自動化されていない • ステークホルダーにモデルの解釈可能性、説明可能性、公平性等のモデルの信頼 性について説明をする必要がある
20. Lv2 → Lv3  推論環境に合わせたデプロイパイプラインの実装 ➢ データを受け取って機械学習モデルによる推論結果を返すコンテナをビルドし Kubernetes 等のコンテナを動かす基盤上にデプロイする一連の作業を実行するパイプラインを構築※ ➢ データソースからデータを取得し、機械学習モデルによる推論結果を得てデータを格納する バッチ処理を実行するパイプラインを構築する※  モデルの検証・品質確認を行う仕組みの実装 ➢ テストデータ（ゴールドデータ）による精度検証の自動化 ➢ 説明性、公平性の確認  本番運用を想定した環境構築 ➢ 開発環境と本番環境の分離 ※代表的な機械学習モデルのデプロイパイプライン、実際にはユースケースに応じた構築が必要
21. Level 3 – Automated Model Deployment  モデルのパッケージ化、品質確認、デプロイが半自動的に行われ、 本番環境にモデルが展開される パッケージ化 品質確認 リリース Environments コード 説明 データセット イベント & 通知 DevOps 統合 (CI/CD) Model Registry MLOps エンジニア QAエンジニア
22. 機械学習を取り巻く現実 学習に用いるデータ は日々増大していく データの性質は日々変 化していく 使用状況やビジネス要 件の変化に伴って要望 が生じる 機動的なモデル改善と継続的なモデル作成 (再学習) が必要
23. 課題・チャレンジ 監視 • 推論環境およびモデルの推論性能の監視が十分でない • データの監視が十分でない • 再トレーニングの基準となる KPI およびその閾値の設定ができていない 品質とセキュリティ • デプロイ後モデルが適切なタイミングでアップグレードされていない • 新しいモデルを本番の推論環境にデプロイする場合に、ユーザーへの影響を最小 化できていない スケーラビリティ • システム全体に自動化可能にも関わらず手動実行が必要な部分が多数存在する
24. Lv3 → Lv4  機械学習モデルの性能劣化や劣化につながる要因を検知するための 監視体制を整備する ➢ 機械学習モデルの性能を評価できる指標の洗い出し ➢ 指標の算出に必要なログの収集とニアリアルタイムな指標算出の仕組み構築 ➢ データセットの変動を検知する仕組みの構築  自動化の仕組みを実装する ➢ 学習からデプロイまでの各工程を間断なく処理する仕組みの実装※1 ➢ ブルー・グリーンデプロイと新モデルの挙動を自動的に監視対象に含める仕組みの構築 ➢ 異常検知時の通知や定型的作業の自動実行 ➢ 再学習・再展開を実行する指標の閾値設定とトリガーの実装※2 ※1 運用方針に応じて、QA やデプロイ時等、人間による承認を間に挟むことは許容される ※2 新しいモデルが閾値を超えられない or より劣化した場合にロールバックする基準も同時に定める必要がある
25. Level 4 – Full MLOps Automated Retraining データパイプライン 学習パイプライン デプロイ パイプライン データ準備 良いモデル の発見 アルゴリズム 選定 データセット /特徴量 モデル テスト・検証 ML エンジニア データサイエン ティスト データ エンジニア QAエンジニア MLOps エンジニア 検証 ML API ログ データ変動 再学習トリガー アプリ Kubernetes インフラ エンジニア ソフトウェア エンジニア ログ モニタリング ML エンジニア データサイエン ティスト QAエンジニア MLOps エンジニア
26. Azure Machine Learning での MLOps 実装 • アーキテクチャ • 利用する Azure サービスの機能詳細
27. Azure Machine Learning とは？ https://docs.microsoft.com/ja-jp/azure/machine-learning/overview-what-is-azure-machine-learning 機械学習の各プロセスから MLOps まで幅広くサポートする 『機械学習プラットフォーム』
28. 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
29. 学習におけるアセット間の関係 Datastore Environment Data Model Command Job Pipeline Job Job Component Compute Compute Instance AmlCompute (Compute Cluster) Kubernetes Compute
30. 推論におけるアセット間の関係 Datastore Environment Data Model Batch Deployment Managed Online Endpoint Kubernetes Online Endpoint Batch Endpoint Endpoint Managed Online Deployment Kubernetes Online Deployment Online Endpoint Compute Compute Instance AmlCompute (Compute Cluster) Kubernetes Compute 1…n 1…n 1…n
31. Azure Machine Learning の基本的な使い方 31 • GPU 搭載のサーバー を調達 • 電源確保＆ネット ワークに接続 • Python 環境と Jupyter をセットアッ プ • GPU のドライバ/ライ ブラリをインストー ル • データを吸出して CSVやParquet等の ファイル形式で貰う • データの前処理 • アルゴリズムの試行 とパラメーター探索 • Dockerfile を書いて モデルを収めたコン テナを作成 • Flask / fastAPI など で HTTP エンドポイ ントをセット • Kubernetes 等に コンテナをデプロイ • 計算リソースを アタッチ • Azure ML Compute Instance/Cluster を 展開 • Environment を 読み込む • Compute Instance を そのまま使う • Datastores として データソースをア タッチして、Dataset を作成 • Auto ML でモデルを 自動作成 • 大規模計算リソース で効率的に探索 • 実験/モデルを記録 • 保存したモデルにメ タデータを付与する • エントリスクリプト の作成 • アタッチした推論用 のリソースにデプロ イ 計算リソースの用意 環境構築 データの吸出し 前処理/モデルの作成 推論コンテナの作成 デプロイ 従来 Azure Machine Learning
32. Level 0 – No MLOps Train Mount/ Download Azure Data Lake Storage Gen2 Compute Instance Model Deploy manually Managed Endpoint (Online/Batch) Local Conda YAML PIP requirements etc container Azure Machine Learning Components DSVM
33. 利用サービス サービス 機能 目的 Azure Data Lake Storage Gen2 • データの保存 Azure Machine Learning Compute Instance • 機械学習の実行 • 開発 Managed Online Endpoint • モデルの API 化
34. Data Science Virtual Machine  一通り機械学習を実行するた めに必要なソフトウェアがプ リセットされた VM  JupyterLab + JupyterHub が デフォルトで稼働 https://docs.microsoft.com/ja-jp/azure/machine-learning/data-science-virtual-machine/overview
35. Level 1 – DevOps No MLOps Train Mount/ Download Azure Data Lake Storage Gen2 Compute Instance Model Deploy manually Managed Endpoint (Online/Batch) Local Conda YAML PIP requirements etc container Code Checkout GitHub Test Code Test Data Check Data Prep Data Azure Machine Learning Components
36. 利用サービス サービス 機能 目的 Azure Synapse Analytics Synapse Pipelines • ETL Azure Data Lake Storage Gen2 • データの保存 GitHub リポジトリ • コードの集約 GitHub Actions • テストの実行 • コンテナのビルド • デプロイ Azure Machine Learning Compute Instance • 機械学習の実行 • 開発 Datatsore • データソースへの接続 Data • データセットの定義 Managed Online Endpoint • モデルの API 化
37. GitHub  Git によるソースコード管理  多種多様なサービスとの強力 な連携機能  Github Actions によるワーク フロー構築
38. GitHub Actions  イベント駆動でジョブを実行する GitHub のワークフローツール https://docs.github.com/ja/actions
39. Azure Repos  Azure DevOps に含まれる ソースコード管理機能  Git※もしくは TFVC  容量無制限  AAD ベースの権限管理 https://azure.microsoft.com/ja-jp/services/devops/repos/ ※ Azure Machine Learning は Git と連携可能 (TFVC は未対応）
40. Azure Pipelines  Azure DevOps に含まれる パイプラインツール  Azure と緊密に連携した処 理に強み
41. Workspaces  Azure Machine Learning 使用時に作 成したあらゆるアセット・成果物を集 約した一元的な作業スペースを提供  Workspace は複数人で共有すること ができ、RBAC によって Workspace 上で可能な操作を制限することができ る
42. Data and Data Stores  Datastores は Azure のストレージ サービスに対する接続情報を保持する ために使用される  Data は Datastores を使用して接続さ れたデータソース内に保存されたデー タを参照する  Data と Datastores により、機械学習 ジョブとデータが疎結合になる 認証情報 username: admin password: p@s5w0rd! ストレージ接続情報 リソースID: /subscriptions/902f23… Datastores pandas/spark データフレーム Data ファイル
43. Azure ML CLI v2  yaml 形式で記述した静的な定義 ファイル + az ml コマンドを使 用した Azure ML の CLI  Azure Resource Manager への API コールによってジョブ実行、 パイプライン定義、デプロイな どを実行する https://docs.microsoft.com/ja-jp/azure/machine-learning/concept-v2#azure-machine-learning-cli-v2
44. マネージドリソース  Azure Machine Learning 配下のマネージドなコンピュー ティングリソース • Compute Instances • 単一の VM • 様々なマシンスペック (GPU 搭載含む) から自由に選んで作成可能 • Notebook (Azure ML Studio) の他、JupyterLab、VSCode 等を使用したアド ホックな分析を行うための計算リソース • Compute Clusters • オートスケールするクラスター • 様々なマシンスペック (GPU 搭載含む) から自由に選んで作成可能 • 1台の VM ではこなしきれない大規模な処理をこなすための計算リソース
45. 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 Azure Data Lake Storage Gen2 Managed Feature Store Shareable Other AML Workspace Get Historical Feature
46. 利用サービス サービス 機能 目的 Azure Synapse Analytics Synapse Pipelines • ETL Azure Data Lake Storage Gen2 • データの保存 Github リポジトリ • コードの集約 GitHub Actions • テストの実行 • コンテナのビルド • デプロイ • パイプラインのキック Azure Machine Learning Compute Instance • モデル開発と分析 Compute Clusters • ジョブ・パイプラインの実行 Environments • 実行環境の保存 Datatsore • データソースへの接続 Data • データセットの定義 Managed Feature Store • 特徴量の保存と提供 Jobs • 実験の記録 Models • モデルの保存 Pipelines • パイプラインの構築 Azure Container Instances • コンテナのホスト
47. マネージドリソース  Azure Machine Learning 配下のマネージドな コンピューティングリソース • Compute Instances • 単一の VM • 様々なマシンスペック (GPU 搭載含む) から自由に選んで作成可能 • Notebook (Azure ML Studio) の他、JupyterLab、VSCode 等を使用したアド ホックな分析を行うための計算リソース • Compute Clusters • オートスケールするクラスター • 様々なマシンスペック (GPU 搭載含む) から自由に選んで作成可能 • 1台の VM ではこなしきれない大規模な処理をこなすための計算リソース
48.  Computes はジョブを実行するための コンピューティングリソースを表す  AzureML 組み込みの計算リソースの 他、連携のための設定を行った任意の Kubernetes 環境、DSVM などの Azure VM を指定することができる Computes Computes インタラク ティブ ジョブ実行 デプロイ (Batch) Compute Instance ✓ ✓ Compute Cluster ✓ (デバッグ) ✓ ✓ Serverless Spark ✓ ✓ Kubernetes ✓ ✓ Virtual Machine (DSVM) ✓ (DSVM の Jupyter) ✓
49.  Azure Machine Learning Environments は機械学習を実行す る環境のカプセル化を提供する  Environment では学習や推論スクリ プト周辺の Python パッケージ、環 境変数、ソフトウェアの設定、ラン タイム（Python、Spark や Docker 等）を指定する Environments Environment 1 種類: conda environment.yml Environment 2 種類: conda environment.yml Environment 3 種類: Dockerfile コンテナ (必要に応じて自動 でビルドされる) Computes, Endpoint
50.  Experiment は複数の Job をグループ 化し、メトリックを横断的に可視化す る  Job は1回の実験についてのパラメー ター、メトリック、生成物、ログ等を 保存し、実験の再現性確保を支援する  Job は実験記録の枠組みであると同時 に、学習の実行そのものとして計算リ ソースや実行環境の定義などを内包す る Jobs and Experiments Experiment 売上予測モデル作成 Job 1 モデル: LightGBM パラメーター: n_estimator=50, num_leaves… メトリック: R2=0.823 Job 2 モデル: LightGBM パラメーター: n_estimator=30, num_leaves… メトリック: R2=0.802 Job 3 パラメーターチューニング Child Job 1 パラメーター: n_estimator=50, num_leaves… メトリック: R2=0.823 Child Job 2 パラメーター: n_estimator=40, num_leaves… メトリック: R2=0.802
51.  Model は学習が完了したモデルの状態 を保存したファイルを含むオブジェク トである  Model Registry は Model をバージョ ニングして保管し、 Model を使用し たエンドポイントや Model を生成し た Run と関連付けして管理する  MLflow Models との高い互換性 Models and Model Registry Model A ver.1 ver.2 Model B ver.1 ver.2 ver.3 Model Registry 任意のモデ ルに関連し たファイル Model
52.  1つの Pipeline は完成した機械学習 タスクのワークフローを表し、機械 学習の各サブタスクはパイプライン を構成する Component として内包 される  Pipeline は REST エンドポイントを パラメーターを備え、パラメーター を受け取ることで動作をカスタマイ ズすることができる  Job の1種としても取り扱われる Pipelines データ 準備 アルゴリズム 選定 良いモデル の発見 データ 準備 モデル 学習 推論と 結果の保存 データ 準備 モデル 学習 推論と 結果の保存
53. Managed Feature Store (preview)  組織内で作成された特徴量を再利用可 能にする  特徴量を作るための一連の変換処理を パイプラインとして定義し、特徴量エ ンジニアリングの運用を自動化する  学習と推論の双方で同じ特徴量パイプ ラインを利用することでオフライン・ オンラインの一貫性を確保し、Skew を回避する データソース Serving API 特徴量カタログ Spec Pipeline Feature set (特徴量セット) Managed Feature Store モニタリング
54. Designer GUI で機械学習のタスクを定義し、パイプラインを作成する機能
55. Auto ML 特徴量エンジニアリング、アルゴリズムとハイパーパラメーターの 選択を自動化し、データに対して最適なモデルを探索する機能 https://docs.microsoft.com/ja-jp/azure/machine-learning/concept-automated-ml ユーザーによる 入力 特徴量化 & 特徴量 エンジニアリング アルゴリズム 選択 ハイパーパラメー ター チューニング モデル リーダーボード Dataset 設定・制約 76% 34% 82% 41% 88% 72% 81% 54% 73% 88% 90% 91% 95% 68% 56% 89% 89% 79% 順位 モデル スコア 1 95% 2 76% 3 53% …
56. 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 Data/Managed Feature Store
57. 利用サービス サービス 機能 目的 Azure Synapse Analytics Synapse Pipelines • ETL Azure Data Lake Storage Gen2 • データの保存 Github リポジトリ • コードの集約 GitHub Actions • テストの実行 • パイプラインのキック Azure Machine Learning Compute Instance • モデル開発と分析 Compute Clusters • ジョブ・パイプラインの実行 Datatsore • データソースへの接続 Data • データセットの定義 Managed Feature Store • 特徴量の保存と提供 Jobs • 実験の記録 Models • モデルの保存 Pipelines • パイプラインの構築 • 学習パイプライン • デプロイパイプライン • 推論パイプライン Managed Online Endpoint • モデルの API 化 Registry • Workspace 間のアセット共有
58.  Pipeline を構成する Component、 Model、Environment をWorkspace をまたいで共有する仕組み  組織横断的にアセットを発見・再利用 する用途に加え、ステージの異なる Workspace 間でアセットを転送する 用途としても使用可能 Registry • Compute 作成 • ジョブ実行 • Endpoint 作成 Workspace チーム A Workspace チームB Workspace チームC アセット作成: Model Component Environment Data Registry
59.  説明変数を受け取りモデルによる推論 結果を返す API をデプロイする仕組み  1つの Endpoint はDeployment を複数 個持つことができる  各 Deployment へのリクエスト配分を 自由に設定できる Online Endpoint Deployment Model Model Endpoint Deployment ユーザー
60. ブルーグリーンデプロイメント AzureMLのエンドポイントは、複数のデプロイを含めることができる。 メリット・できること • 各デプロイに任意の割合のトラフィックを与えて負荷分散可能 • モデルを切り替える際の安全なロールアウトの実現が可能 • 別のデプロイにミラーリングして、ライブクライアントに影響を 与えずに、応用待機時間やエラー状態などをテスト可能(プレビュー) ミラーリングの場合 Blue:100%、Green:10%(ミラーリング) デプロイ先によってトラフィックを分離可能 トラフィックの割合を設定可能 詳細な方法：オンライン エンドポイントの安全なロールアウト - Azure Machine Learning | Microsoft Docs
61.  Compute Cluster を使用した並列バッ チ推論の仕組み  推論対象のファイル群を複数ノードで 分担して読み込み推論結果を付与する  内実は Job、バッチ推論をトリガーす るための専用 Endpoint が作られる Batch Endpoint Datastore Data Compute Cluster Model predictions.csv
62. モデルデプロイ  並列処理によって大規模なバッチ推論が実行可能 パイプラインコンポーネントデプロイ (preview)  複雑な学習・推論のプロセスを複数のステップからなるワークフローで構成し、 Batch Endpoint の API から実行可能 Batch Endpoint 2種類のデプロイ方法 バッチ エンドポイントとは - Azure Machine Learning | Microsoft Learn
63. Datastore Data Compute Cluster Model predictions.csv Batch Endpoint – モデルデプロイ  Compute Cluster を使用した 並列バッチ推論の仕組み  推論対象のファイル群を複数 ノードで分担して読み込み推 論結果を付与する  内実は Job、バッチ推論をト リガーするための専用 Endpoint が作られる
64. Datastore Data Compute Cluster Pipeline predictions.csv Batch Endpoint – パイプラインコンポーネントデプロイ (preview)  パイプラインやコンポーネン トを Batch Endpoint の API で利用する仕組み  モデル学習時に利用した前処 理のコンポーネントを再利用 した推論パイプラインの作成 とデプロイも可能  内実は Pipeline Job、バッチ 推論をトリガーするための専 用 Endpoint が作られる
65. Level 4 – Full MLOps Automated Retraining Mount/Download Azure Synapse Pipeline Azure Data Lake Storage Gen2 Job Environments Azure Machine Learning Python SDK/CLI Azure Container Registry Data Prep Data Models Monitoring Azure Machine Learning Python SDK/CLI 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 Azure Monitor Azure Insights Azure Machine Learning Components container Gated approval Retraining Trigger Deploy to Prod Deploy to Prod Model Test ResponsibleAI Safe Rollout Azure Machine Learning Python SDK/CLI Compute Instance Compute Clusters build&push Training (pipeline) Deployment (pipeline) Data Science team Infra team Alert Dashboard build&push job submit experiment log/metric auto scale log/metric auto scale log/metric Register model deploy automatically deploy automatically Event Grid (Model Trigger) (Code Trigger) Event Grid model register data drift Prod Stage Dev Stage Model Monitoring Data/Managed Feature Store
66. 利用サービス サービス 機能 目的 Azure Synapse Analytics Synapse Pipelines • ETL Azure Data Lake Storage Gen2 • データの保存 GitHub リポジトリ • コードの集約 GitHub Actions • テストの実行 • パイプラインのキック Azure Machine Learning Compute Instance • モデル開発と分析 Compute Clusters • ジョブ・パイプラインの実行 Datatsore • データソースへの接続 Data • データセットの定義 Managed Feature Store • 特徴量の保存と提供 Jobs • 実験の記録 Models • モデルの保存 Pipelines • パイプラインの構築 • 学習パイプライン • デプロイパイプライン • 推論パイプライン Managed Endpoint • モデルの API 化 Model Monitoring • モデルの監視 • データドリフト監視 Registry • Workspace 間のアセット共有 Azure Monitor • 監視 Application Insights • 監視
67.  オンラインエンドポイントのモデルを 簡単に監視することが可能  データドリフト、予測ドリフト、デー タ品質、特徴量属性ドリフトといった 表形式データに対応するビルトインの シグナルを提供  包括的な UI (Azure ML Studio) での 監視メトリックの表示と監視 Model monitoring (preview)
68. Model monitoring の仕組み Azure ML Model monitoring 入力データ 予測値データ オンライン エンドポイント アプリ 学習データ (ベースデータ) Azure ML Studio Azure Monitor モデル学習 1. モデル学習 2. デプロイ 3. 入出力データ収集 4. 監視構成 5. 表示と分析 デプロイ
69. Azure Monitor ログの収集、分析とその後の対応をカバーするサービス Metrics Logs Application Containers VM Monitoring Solutions Insights Dashboards Views Power BI Workbooks Visualize Metrics Explorer Log Analytics Analyze Alerts Autoscale Respond Event Hubs Ingest & Export APIs Logic Apps Integrate Azure Monitor Custom Sources Application Operating System Azure Resources Azure Subscription Azure Tenant
70. Azure Event Grid イベントを検知し、イベントハンドラーに送信するサービス  Azure Machine Learning からは以下イベントをサポート  Microsoft.MachineLearningServices.RunCompleted  Microsoft.MachineLearningServices.ModelRegistered  Microsoft.MachineLearningServices.ModelDeployed  Microsoft.MachineLearningServices.DatasetDriftDetected  Microsoft.MachineLearningServices.RunStatusChanged  通知送信、WebHooks による API キック、Functions や Logic Apps によるコード実行等に繋げることで自動化 ML ワークフロー内でイベントをトリガーする (プレビュー) - Azure Machine Learning | Microsoft Docs
71. 技術詳細 MLOps を構成する要素技術の詳細
72. Lv.1 DevOps No MLOps
73. 機械学習におけるコード品質 継続的なメンテナンスと多人数開発を可能とするコード品質を確保する ための技法
74. コード品質を保つ意義  今、一緒に開発を行っている同僚が効率的かつ継続的にコードに手 を入れられるようになる  将来、コードを書いた当人以外が苦労なくコードに手を入れ、メン テナンスやリファクタリングを継続することができる  上記の結果としてビジネス上の価値を効率的に生み出すことができ る
75. コード品質を担保する仕組み  Linter と formatter  型ヒント  テスト
76. Linter と Formatter Linter  ルールに則ったコードの記述ができ ているか静的に解析するツール  実行時にエラーにならないが、バグ の温床やコード品質を下げる原因と なるような記述を特定することがで きる Formatter  コードのスタイルを確認・自動修正 するツール  改行やインデントなどを自動的に修 正し、コードの見た目を整える https://black.readthedocs.io/en/stable/index.html
77. 機械学習における Linter と Formatter  不必要な import や未使用の変数など、実験を繰り返す中で混入し たコードの見通しを悪化させる要素を取り除くことができる  コードの形式をある程度の範囲で自動的に揃えることができる ➢複数人でコラボレーションする際の摩擦低減につながる  特に初期段階においては導入コストが低く効果が大きい
78. 型ヒント Python は型を明示的に記述しな くても動作するが、任意で型ヒン トを付与することができる  可読性が向上する  型ヒント付与により IDE の支援 が強力に  型の静的解析を行うことで不正 な値が渡されることを防ぐ ◼ 必須ではないため徐々に導入することが可能
79. 機械学習における型ヒント  受け取るデータ形式を明示・制約することで意図しないエラーを防 ぐ  Int 型と Float 型の取り違えによるミス (除算で起こりがち)  渡す型のミスによるエラーや NaN 、 Inf の発生  機械学習では各コンポーネントやモデルが独自の型や形式を要求す ることが多く、開発者当人以外のエンジニアがコードを触る際の可 読性向上は効果が大きい  tensor か pandas の DataFrame か Spark の DataFrame か ndarray か list か、あるいはラ イブラリが備える独自型か  入力として複数の tensor を要求するモデルへの渡し方  パイプラインのコンポーネントとして実装する場合の入出力インターフェースの明示
80. テスト  プログラムが正しく動作するか 検証するためのテストコード ✓コード変更時の影響範囲調査と修正が 高速化 ✓「動くコード」に継続的に手を入れる ことが可能になり、リファクタリング を通じて品質向上につながる ✓デプロイ頻度の向上とリードタイムの 低減
81. 引用元 : https://speakerdeck.com/twada/quality-and-speed-2020-autumn-edition?slide=7
82. テストのトレードオフ  テストを書くことによる短期的な時間損失は存在する ➢チーム規模が小さく十分なリソースを確保できない（と感じる）初 期段階や、成果を急かされている状況ではテストは省略されがち  しかし中長期で見れば、テストコードを書く時間より多くの時間を 失う  コード変更時の影響範囲調査に時間を要し、修正時の動作も見落としが発生しがちになり品 質が低下する  「現在動くコード」をリファクタリングすることが困難になり、品質が低下し続ける ➢ 爆弾処理のようなコード修正をこなすことになるか、最悪本番障害が発生し長期化する
83. 機械学習におけるコードレベルのテスト  前処理部分はテスト可能かつ境界値テストで問題を事前検知しやす くテストを書くメリットが大きい  学習部分のコードは出力がモデルであることが多く、厳密な一致を 確認することは意味が薄い ➢ 単にモデルが生成されていることのみを確認し、モデルそのものの性質は後述のモデルに対 するテストで代替する  モデルに NaN や Inf などが含まれていないか程度はこのタイミングで確認することも可能
84. 機械学習におけるテストの考慮事項  テストを書く対象となるコード  テストを書く意義が薄いコードも存在  使い捨てのコンポーネントにテストは必要か？（使い捨てでも状況によって必要なこともある）  ライブラリの薄いラッパーや、ライブラリ側のテストで検証済みのことを再検証するような場合  テストの粒度  実装するテストの粒度を費用対効果に基づいて決定する  状況に合わないテスト戦略はむしろリソースを無駄に消費する E2E 結合 単体 • ユーザー環境に 近い • 実行速度が遅い • 高コスト • 局所的(問題箇所 を絞りやすい) • 実行速度が速い • 低コスト ➢ 例1: プロトタイピング (jupyter notebook) と本番投入 用コード (python スクリプト) でテストの有無を分ける ➢ 例2: 使い回すコンポーネント向けのユニットテストを 優先し、E2Eテストはテストデータを用いたドライラン で代替して実装しない
85. Lv.2 Automated Training
86. MLflow 実験管理やモデル管理を実現する OSS
87. MLflow とは  機械学習のライフサイクルを管理する OSS プラットフォーム  実験管理、コードのパッケージ化、モデル管理、モデル登録、パイ プラインの5要素 Tracking 実験の記録とクエリ (コード、データ、 構成設定、結果) コードのパッケージ化 による再現性を 実現する形式 Projects Model Registry 一元的なモデルの ライフサイクル管理 Models フレームワーク非依 存なモデルの統一的 フォーマット Recipes モデルの開発とデプ ロイを支えるパイプラ インの構築
88. 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
89. 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
91. MLflow Models  フレームワーク、モデルの保存形式、読み込み・書き込み、モデル の入出力を抽象化するコンポーネント ➢学習に使用したフレームワークや実装に依らず、 MLflow の API を 使用してモデルを統一的に取り扱うことができる ➢ノーコードでモデルデプロイを実現  Docker コンテナビルド  SageMaker or AML へのデプロイ  ローカルデプロイ Models 入出力形式等 のメタデータ 実行環境 モデル
92. MLflow Model ノーコードデプロイの条件  フレームワークの種類を特定していること  mlflow の各フレームワークに対応するサブモジュール内にある log_model 関数 (ex. mlflow.pytorch.log_model) を使用することで フレームワークを特定する  使用しているフレームワークがビルトイン (右記) でない場合は Python Function を使用し、 メンバー関数として predict を持つ クラスのインスタンスを登録する  入出力形状を特定していること  mlflow.models.signature.infer_signature に入出力サンプルを与え て得られる signature を渡すことで決定する
93. MLflow Model Registry モデル本体、モデルの入出力の情報、フレームワーク の種類等、MLflow Models で定義した情報を保持 モデルは実験と紐づけられた上でバージョンごと に分離して管理
94. チームで使用する MLflow 環境の管理 MLflow Tracking Server の ホスト環境管理 コンテナ 仮想マシン アプリホスト PaaS AWS Elastic Beanstalk Azure App Services Google App Engine RDB の管理 コンテナ 仮想マシン DBaaS Amazon RDS Azure SQL Database GCP Cloud SQL ストレージ の管理 NAS Hadoop クラスター ブロックストレージ Amazon S3 Azure Blob Storage GCP Cloud Storage ユーザー制御 (認証) nginx Apache
95. MLflow-as-a-Service  Tracking Server の構築・運用が面倒  組織的に MLflow を活用する場合にはセキュリティの確保が必要  使いたいときに使うことができる可用性確保（サーバーの冗長構成）  認証機構の組み込み ➢マネージドな MLflow Tracking Server Azure Databricks Azure Machine Learning 機密性 : Azure AD ベースの RBAC 完全性 : ストレージ組み込みのログ、 バージョニング、バックアップ等 可用性 : ADB SLA 99.95 % AML SLA 99.9 % オートスケール Spark クラスター + Jupyter 互換ノートブック環境 + マネージド MLflow MLOps をトータルサポートする 機能・リソースの複合サービス MLflow 互換エンドポイントと MLflow Models を前提とした 機能統合
96. Azure Databricks + MLflow  Azure Databricks の一部としての MLflow  外部から MLflow Tracking Server として利用可能 Azure Infrastructure ML Lifecycle Management integrations ML Runtime Optimized Databricks runtime engine Databricks I/O Delta Lake TensorFlow PyTorch Scikit-Learn MLflow Serverless Optimized Apache Spark Azure Active Directory Azure Virtual Machine Scale Sets Azure Data Lake Storage Azure Databricks Metrics Artifacts Models
97. 実験 Logging API Tracking URI Model API Azure Machine Learning + MLflow  MLflow Tracking Server 互換 ➢MLflow を使用して Azure ML に実験やモデルを記録 Metrics Artifacts Azure Machine Learning MLflow Tracking Server 互換エンドポイント Azure Machine Learning Environments Azure Machine Learning Experiments Azure Machine Learning Models Models Azure Machine Learning Endpoints Metrics Artifacts Models Azure Synapse Analytics API Power BI 実験管理・記録 デプロイ
98. Azure Machine Learning + MLflow のメリット MLflow for Training MLflow による学習時の ログ記録と Model Registry へのモデル保存 MLflow for Inference MLflow フォーマットで 保存されたモデルによる 追加コード不要なスコア リング • 実験を記録するためのプラットフォー ム固有の API およびツールを覚える必 要がない • 固有ライブラリを一切使用することな く学習コードを記述し、MLプラット フォーム間のポータビリティを保つ • チーム共有の MLflow Tracking Server を構築・運用する必要がなくなる
99. AzureML as MLflow Tracking Server https://www.mlflow.org/docs/latest/tracking.html#mlflow-tracking-servers 1. AzureML の Python SDK を 使用して Workspace と接続 2. MLflow Tracking Server 互換 のトラッキング URI を発行 3. MLflow に set する Azure Machine Learning Azure Active Directory による ID 管理と制御 ws = ml_client.workspaces.get() url = ws.mlflow_tracking_uri mlflow.set_tracking_uri(url)
100. 深化する Azure Machine Learning と MLflow の関係 SDK v1  ログ記録ツールの選択肢の1つ  MLflow Models 形式による API ノーコードデプロイサポート ➢機械学習のコードから Azure ML 依 存的なコードの大半を排除できる SDK v2  唯一のログ記録の手段  MLflow Models 形式による API/ バッチ推論ノーコードデプロイサ ポート  MLflow Projects によるジョブ定義 と実行 (preview) ➢ログ記録で MLflow が必須 ➢より進んだ MLflow Models 統合 https://docs.microsoft.com/ja-jp/azure/machine-learning/v1/how-to-use-mlflow https://docs.microsoft.com/ja-jp/azure/machine-learning/how-to-use-mlflow-cli-runs?tabs=mlflow
101. Feature Store 特徴量を格納・共有し、異なる性能要件を持つワークロードに対して共 通のインターフェースで特徴量を供給するコンポーネント
102. 特徴量 (Feature) booking datetime customer_id driver_id Trip_completed 10001 2021-03-17 19:31 1010 5010 True 10002 2021-03-18 19:31 1010 5010 False 10003 2021-03-19 19:31 1010 5010 True 10004 2021-03-20 19:31 1010 5010 False datetime driver_id conv_rate acc_rate avg_daily_trips 2021-03-17 19:31 5010 0.229297 0.685843 861 2021-03-17 20:31 5010 0.781655 0.861280 769 2021-03-17 21:31 5010 0.150333 0.525581 778 2021-03-17 22:31 5010 0.951701 0.228883 570 conv_rate acc_rate avg_daily_trips Trip_completed 0.229297 0.685843 861 True 0.781655 0.861280 769 False 0.150333 0.525581 778 True 0.951701 0.228883 570 False ML Model 入力 出力 特徴量エンジニアリング • カテゴリ変数の変換(label encoding etc…) • 欠損値の変換(平均値、予測値、代表値etc..) • 新たな特徴量の作成 ⇒特徴量の管理がしたい(できる) ⇒ Feature Storeの出番
103. Feature Store の概念  データサイエンティストが作成した特徴量を保存・共有する  要件が異なる学習と推論の両方において一貫したインターフェースを提供する オフラインストア オンラインストア ストリーミング Feature Store ML API バッチ推論 学習 特徴量エンジニアリング
104. 特徴量がスクリプト上に埋もれて、再利用や活用できるように整理、保存されないため、ト ラッキングやコンプライアンス基準を満たすことが難しい 特徴量エンジニアリングの作業は、重複しており、Data Scientist の時間とCompute リソー スを消費する 特徴量を本番環境に反映させるのは難しい オフライントレーニングとオンライン推論では、通常、異なるサービングパイプラインが必 要であり、一貫した特徴量の提供ができずしばしばモデル性能の劣化を招く (Skew) 特徴量やデータの質は刻々と変化しており、人の手が介入する必要がある Feature Store が必要とされる背景
105. Skew 「偏り」「歪み」、特にデータ/特徴量において学習時と推論時の要件の違いか ら生じる様々な課題を指す (Training-serving Skew)  Feature Skew  学習時と推論時で、与えられる特徴量の値が異なる  学習時と推論時に異なる処理を記述していたり、データベースに変更が加えられた場合などに発生  Distribution Skew  学習時と推論時で与えられる特徴量の分布が大きく異なる  学習データ作成時に行ったサンプリングやデータを取り巻く情勢の変化によって発生  Scoring/Serving Skew  推論結果の影響を受けているデータから再学習用の学習データを得るときに発生する偏り https://research.google/pubs/pub47967/
106. 共通 特徴レジストリ ＆ 管理 特徴量 モニタリング 再利用性 統一性(重複の防止) 汎用性 特徴量の取り込み & 計算 (バッチ & ストリーミング ソース) 共通プロバイダー • バッチプロバイダー： 高スループット(学習) • オンラインプロバイダー：低レイテンシー (推論) 利用時・方法における特徴量の一貫性 監視性 Feature Store の構成
107. Feature Store 導入時の活用の流れ Feature Store Data Engineer / Data Scientist / ML Engineer Independent Production Jobs DE / DS / MLE 推論 監視 新しい特徴量の 定義/イテレーション Feature Storeから 学習用にデータを 読み込み Feature Storeから テスト用にデータを 読み込み 推論に必要な特徴量の 算出 特徴量、推論結果 ジョブの実行結果の ログを保管 特徴量や関連する問 題の追跡 (タイムラインと頻度) 特徴量ドリフトと 品質問題の監視 特徴量 エンジニアリング トレーニング/テスト モデル&評価
108. Azure Machine Learning Managed Feature Store (preview)  Spark ベースの特徴量エン ジニアリングパイプライン  特徴量の共有とバージョン 管理  特徴量を提供する仕組み  学習とバッチ推論のためのバッチプ ロバイダー  オンライン推論向けのオンラインプ ロバイダーは 2023/06/12 現在未提 供 https://learn.microsoft.com/ja-jp/azure/machine-learning/concept-what-is-managed-feature-store?view=azureml-api-2 データソース Serving API 特徴量カタログ Spec Pipeline Feature set (特徴量セット) Managed Feature Store モニタリング
109. Feathr on Azureの全体像例
110. Feathr component Cloud Integrations Offline store – Object Store Azure Blob Storage Azure ADLS Gen2 AWS S3 Offline store – SQL Azure SQL DB Azure Synapse Dedicated SQL Pools (formerly SQL DW) Azure SQL in VM Snowflake Online store Azure Cache for Redis Feature Registry Azure Purview Compute Engine Azure Synapse Spark Pools Databricks Machine Learning Platform Azure Machine Learning Jupyter Notebook File Format CSV Parquet ORC Avro Delta Lake Feathr on Azure Integration with Cloud Services
111. Lv.3 Automated Model Deployment
112. 機械学習モデルのテスト 本番環境へのモデル投入を恐れず進めるための技術
113. 機械学習におけるテストの考慮事項 ◆機械学習モデルの「テスト」は難しい  通常テストで用いられる同値クラスの代表値を用いたテスト手法が使用できない  そもそも「境界」が自明ではなく、それゆえに機械学習を使っているという事情も  わずかな入力の差分が結果に大きな変化を与えることがある  一般に入力の全パターンに対して網羅的にテスト結果を得ることは難しい ◆テストを踏まえて修正することも難しい  問題のあるパターンを発見した場合に、その問題だけをピンポイントで修正することは困難  多くの場合モデルのアルゴリズムに手を加えるかデータセットに手を加えることになり、修 正の結果はやってみなければ分からない ➢機械学習モデルに求められる要件とテストの実装・実行コストのバ ランスを踏まえてテストを実装する
114. 開発段階 (オフライン) で実施できるテスト  ゴールドスタンダードを使用した性能検証 ➢ モデルの精度や FN/FP の傾向を測定する  メタモルフィックテスティング ➢ モデルの推論結果間にあるべき関係が満たされているか確認する  網羅検証 ➢ 特定の範囲の入力について、取り得る値の範囲が想定内か確認する
115. 本番環境 (オンライン) で実施できるテスト  入力データ分布と学習データ分布の差分 (ドリフト) 比較 ➢ 特に教師あり学習モデルにおいて、入力されるデータが学習時に使用したデータと異なると性能劣化が 発生しやすいことを前提とする、間接的な性能「劣化」度合いのモニタリング  KPI を評価指標としたモデルの性能モニタリング ➢ 推論結果の影響が大きい KPI によってモデルの性能劣化度合いを間接的に測定する ➢ 閾値を定めれば自動的かつ効率的なモデル再学習実施のトリガーとして使用できる  シャドウ A/B テスト ➢ 実際にユーザーに影響を与えず新旧モデルの性能を比較する  KPI を評価指標とする A/B テスト ➢ モデルが与えるビジネスインパクトを測定・比較する
116. ゴールドスタンダードを使用した性能検証 正解ラベル付きのテスト用データセット (ゴールドスタンダード) を 用いて機械学習モデルの性能を検証する 入力データセット 𝒙 出力 𝒚′ 正解 𝒚 クラス分類 • 正解率 • 適合率 • 再現率 • 特異度 … 回帰 • MAE • RMSE • R2 • AIC … 事前に用意するもの
117. ゴールドスタンダードを使用した性能検証 ✓モデルの予測性能を定量的に評価できる ✓実装がシンプルかつ容易 (ライブラリで補助関数が実装されている 場合が大半) ◆正解ラベルを付与するためにコストがかかる場合がある ◆学習データとゴールドスタンダード間の分布差異に注意が必要  学習用データセットから切り出してゴールドスタンダードを構築する場合、両者で分布のず れがあると適正な評価が難しい  学習用データセットとテスト用データセットの取得タイミングに時間的なずれが生じる場合 は、「分布の差異」(データドリフト)そのものが重要な指標となり得る
118. メタモルフィックテスティング 複数の入力・推論ペア間で満たされるべき関係を見出し、推論結果 が実際に関係を満たしているか確認する 佐藤直人, 小川秀人, 來間啓伸, 明神智之, 2021, “AIソフトウェアのテスト-答のない答え合わせ [4つの手法] ”, リックテレコム, p93-123. ソース入力 𝒙 フォローアップ入力 𝒙′ ソース出力 𝒚 ソースフォローアップ出力 𝒚′ 関係 関係 ？ 事前に用意するもの
119. メタモルフィックテスティング ✓ソースとフォローアップの関係に基づいてテストデータを追加生成 できる ✓推論結果の関係に注目しているため、推論結果に明確な正解ラベル を定義できない場合でも使用できる ◆ソースとフォローアップ双方についてその出力間で期待される関係 は満たされているが、出力そのものが両方とも間違っている可能性 は否定されない ➢可能であればゴールドスタンダードデータセットによる精度検証と 併用する 佐藤直人, 小川秀人, 來間啓伸, 明神智之, 2021, “AIソフトウェアのテスト-答のない答え合わせ [4つの手法] ”, リックテレコム, p93-123.
120. 網羅検証 ある特定の入力範囲についての推論結果が収まるべき範囲を定め、 実際に網羅的な入力を加えて推論結果が収まるべき範囲内に収まる か確認する ある範囲内の 入力データセット 𝒙 出力 𝒚′ 出力 𝒚′が満たすべき条件 (範囲) 事前に用意するもの 反例の有無
121. 網羅検証  手法によって厳密性と実装の難しさが変わる 佐藤直人, 小川秀人, 來間啓伸, 明神智之, 2021, “AIソフトウェアのテスト-答のない答え合わせ [4つの手法] ”, リックテレコム, p201-252. 手法 厳密さ 実装難易度 性質 一定範囲のデータをデータセットから 抽出してモデルに入力して探索する 低い 簡単 正解ラベルが不要であるため、本番環 境からデータを取得するなどサンプリ ングが容易 範囲を網羅するデータセットを生成し てモデルに入力して探索する やや高い 簡単 入力パターンが爆発的に増大し、計算 コストが高くなり得る モデルを論理式に変換し SMT ソル バーによって与えれた条件 (論理式) に対する反例が存在しないか探索する 高い 難しい 条件非適合範囲探索に繋げることで、 システムとしてサポートする範囲をモ デルごとに探索することが可能
122. 網羅検証 ✓特定範囲の入力に対しモデルが出力する推論結果の範囲を限定する ことで、システムのカバー範囲や異なるモデルを使用する境界設定 に繋げることができる ✓正解ラベルが不要 ◆厳密性を求められる場合、実装が難しい ◆計算コストが重くなりやすい  SMT ソルバーを使う場合もデータを実際にモデルに入力する場合も計算コストが高い 佐藤直人, 小川秀人, 來間啓伸, 明神智之, 2021, “AIソフトウェアのテスト-答のない答え合わせ [4つの手法] ”, リックテレコム, p93-123.
123. 入力データ分布と学習データ分布の差分比較 入力されてくるデータと学習時に使用したデータの分布差分 (ドリフ ト) を計測しモデルの劣化度合いを間接的に測定する 𝐷 𝑋𝑡𝑟𝑎𝑖𝑛 , 𝑋𝑖𝑛𝑝𝑢𝑡
124. 入力データ分布と学習データ分布の差分比較 ✓適切な(擬)距離を定義することで、ラベル付けのコストをかけるこ となく幅広いモデルについて性能劣化を検出できる ✓(ニア)リアルタイムに性能劣化を検証できる ◆モデルの性能を直接的に測定しているわけではないためドリフトと モデル性能劣化は必ずしも一致しない  性能劣化につながらないドリフトをトリガーとしてモデル学習を実行してしまい、余計なコ ストがかかる (偽陽性)  本質的な性能劣化を検知できず、モデルの性能劣化を見逃してしまう (偽陰性) ➢ 後述の KPI モニタリングと併用することで確度を上げる
125. KPI を評価指標としたモデルの性能モニタリング 推論結果の影響が大きい KPI によってモデルの間接的な性能をリア ルタイムに測定する 既存推論API 入力 出力 ユーザー 分割 KPI 閾値を決め、新モ デルの学習パイプ ラインのトリガー などに繋げる
126. KPI を評価指標としたモデルの性能モニタリング ✓モデルが持つビジネス価値の相対的な変化を計測できる ✓正解ラベルの付与が不要 ✓(ニア)リアルタイムに性能を検証できる ◆KPI の設定は難しい  ある程度運用経験がないと設定することが難しい (鶏卵問題、スモールスタートでメトリッ クを徐々に増やし適切なメトリックを取捨選択することが現実的な解決策) ◆モデル性能以外の因子が KPI に与える影響を考慮する必要がある ◆間接的な性能測定であり必ずしもモデル性能を反映しないことに注 意する必要がある ➢ 初期段階もしくは定期的にモデルの直接評価を行い、KPI との相関を確認する
127. 既存推論API シャドウ A/B テスト 実際に本番で稼働しているモデルに対する入力を複製して新しいモ デルにも与え、両モデルの推論結果のズレを比較・検証する、可能 であれば正解率なども比較する 入力 出力 比較 • 正解ラベルを用意して精度を比 較する • 推論結果のズレを比較する (分 布を比較する) … 新推論API 複製 出力 ユーザー
128. シャドウ A/B テスト ✓モデルそのものが実際の環境において使用できるか、本番環境およ びユーザーに影響を与えず検証することができる ✓新モデルを含む API が実際に動作可能かを検証する目的でも使用で きる(≒E2E テスト) ◆ビジネス上の価値を直接的に計測することは困難 ◆性能差を定量的に検証する場合、正解ラベルを簡単に付与できる場 合以外ではコストが継続的にかかる  簡単に正解ラベルを付与できる場合の例  厳密な解法があるが UX 観点で機械学習モデルで高速な近似を与えたい場合  前捌きとして機械学習モデルを使用しており、最終的には別の手段で正解となる値を生成する場合
129. Azure ML マネージドオンラインエンドポイント トラフィックのミラーリング  トラフィックの一部を複製 し、新しくデプロイしたモ デルに送信する機能  応答は返却せず、メトリッ クとログの収集のみ行う https://docs.microsoft.com/ja-jp/azure/machine-learning/how-to-safely-rollout-managed-endpoints#test-the-deployment-with-mirrored-traffic-preview
130. KPI を評価指標とする A/B テスト 機械学習モデルに対する入力を一定比率で分割して新旧モデルそれ ぞれに入力して応答させ、モデルごとに算出した KPI を比較する 既存推論API 入力 出力 新推論API 出力 ユーザー 分割 比較 既存モデルの KPI 新モデルの KPI
131. KPI を評価指標とする A/B テスト ✓新モデルの既存モデルに対するビジネス上の価値の差を直接的に計 測できる ✓新モデルに問題が発覚した場合の切り戻しが容易 ◆システムの構築に手間がかかる ◆本番環境に精度の保証がない新モデルを投入することが許容されな い場合があり得る ➢ バンディットアルゴリズムにより動的な「活用」群比率変更でリスクマネジメントを試みる ➢ 開発環境上でのテストやシャドウ A/B テストを踏まえてモデルの QA を十分に行う ◼ 究極的にはユーザーに新しいモデルを試験してもらうことは絶対に避けられない(≒どこかの タイミングで新モデルに切り替えることは不可避)点をステークホルダーに理解させる
132. Azure ML マネージドオンラインエンドポイント Blue-green デプロイメント  トラフィックを分割し、指 定した割合で別のモデルへ 転送する機能  モデル事にメトリックとロ グを記録  スキーマが一致していれば 異なる種類の計算リソース を混在させることが可能 https://docs.microsoft.com/ja-jp/azure/machine-learning/how-to-safely-rollout-managed-endpoints#test-the-new-deployment-with-a-small-percentage- of-live-traffic
133. モデルデプロイ方式 本番環境におけるモデルの使い方
134. 機械学習モデルのデプロイ方式  Web API (オンラインサービング)  HTTP や gRPC などでアクセスできる、入力を受けて推論結果を返却する API としてデプロ イする方式  バッチ処理 (バッチサービング)  まとまったデータに対し一括で推論結果を付与するパイプラインに組み込む方式  パイプラインに直接モデルを組み込む場合と Web API と組み合わせる場合がある  直接組み込み  アプリケーション内部に何らかの読み出し可能なバイナリ形式で機械学習モデルを組み込み、 アプリケーション内で推論を行う方式  モデルを実装するフレームワークネイティブの保存形式か ONNX
135. ONNX エコシステム ONNX オープンソースの機械学習モデル保 フォーマット scikit-learn や LightGBM、PyTorch など多様なフレームワークに対応 枝刈りや量子化、構造の効率化により モデルの軽量化と推論の高速化が可能 ONNX Runtime ONNX 形式のモデルを使用して推論 を行うためのフレームワーク 多言語に対応し、インフラの違いを吸 収して効率的な推論を提供する https://onnx.ai/ https://onnxruntime.ai/
136. Other
137. デバッグ パイプラインのデバッグ
138. AzureMLの推論環境の選択肢 オンライン バッチ 推論 低レイテンシー(< 90秒)/ リアルタイム 高スループット ローカルエンドポイント (開発/テスト) ローカルマシン上で開発/テストを行うための Docker デプロイメント マネージドオンライン エンドポイント フルマネージドなMLデプロイメント K8s オンラインエンドポイント セルフマネージドなK8sクラスターへの デプロイメント パイプライン エンドポイント (v1) 各パイプラインを任意の処理グラフ(=1ジョブ)にした 大量のデータの推論方法 エンドポイントインターフェースを利用した 大量のデータの推論方法 バッチエンドポイント
139. パイプラインジョブのデバッグの基本と観点 1. ジョブ実行結果に基づくデバッグ 2. ジョブステータスに基づくデバッグ 3. ジョブ実行中に行うデバッグ Appendix: • トラブルシューティング例 • ML パイプラインのトラブルシューティング – Azure Machine Learning | Microsoft Learn • Azure ML以外のMicrosoft製品との組み合わせによるデバッグの補助 • Outlook(電子メール通知) • スタジオでジョブを監視および分析する - Azure Machine Learning | Microsoft Learn • Application Insight(ログ) • パイプラインのログ ファイルを監視して収集する - Azure Machine Learning | Microsoft Learn
140. ジョブ実行結果に基づくデバッグの種類 ジョブ失敗の原因を解決する方法と、ジョブ成功時に要件に適したパイプラインにチューニングする方法を示す。 ジョブ実行 Python code エラーデバッグ 実行環境エラーデバッグ クラスターエラーデバッグ ジョブ失敗 ジョブ完了 パフォーマンスデバッグ パラメータデバッグ ▶ 「ジョブ」の「出力とログ」のファイルを確認 Next Action ▶ 「環境」の「ビルドログ」のファイルやステータスを確認 ▶ 「コンピューティング」のクラスターノードの状態を確認 ▶ ジョブパイプラインの画面で「プロファイリング の表示」を行い、ガントチャートで確認 ▶ パイプラインの比較(成功vs失敗)により、パイプラ インパラメータ、出力、実効設定などの比較確認を 詳細は次ページを参照
141. ジョブステータスに基づくデバッグ Status 状況 デバッグの確認箇所とNext Action Not started ジョブがクライアントから送信されて他のジョ ブとの実行タイムスケジュールを確認中。 バックエンドに問題がない場合、基本的にはすぐPreparingへ遷移す るため問題なることはほぼない。あまりにも時間がかかるようであ れば、ネットワークの接続を確認し、「最新の情報に更新」を押し て画面をリフレッシュしてみる。 Preparing 環境イメージのBuild中。 使用している環境のビルドログを確認してみる。ビルドに失敗して いる可能性がある。使用しているコンピューティングのRAMやスト レージも足りているか要チェック。 Queue コンピューティングリソースの割り当て中。 使用しているコンピューティングの状態を確認してみる。ノードの 空きリソースがなく準備中になっている可能性が高い。 Running ジョブが指定されたコンピューティングリソー ス上で実行中。主にランタイムの準備 ・環境イメージのpull ・Dockerの開始、データの準備 (マウント/Download) ・ユーザスクリプトの実行 ソースコードを確認するために、実行中のジョブの「出力とログ」 に書かれているメッセージを確認する。実行結果がFailedになった 場合もまずは実行ジョブのログを確認するのがミソ。 Completed ジョブの実行がエラーなく実行された状態 正しく実行されたため、必要であればパフォーマンスデバッグを行 う。 ジョブ実行に異様に時間がかかっている際にジョブステータスを見ることで原因と解決策の見通しを立てることができる。
142. ジョブ実行中に行うデバッグ 実行中のジョブコンテナに 直接接続 Compute Clusters & Attached Compute container vscode Jupyter Lab TensorBoard • デバッガーをジョブに直接アタッチ可能 • job settingsでsleepコマンドを用いてデ バッグのためにジョブを無制限に維持する ことも可能 • ジョブ実行時 or エンドポイントに対してコードのデバッグとモニタリングが可能
143. 環境分離と計算リソース共有 Azure Machine Learning Registry による環境分離と Kubernetes Compute による計算リソース共有
144.  Pipeline を構成する Component、 Model、Environment をWorkspace をまたいで共有する仕組み  組織横断的にアセットを発見・再利用 する用途に加え、ステージの異なる Workspace 間でアセットを転送する 用途としても使用可能 Registry • Compute 作成 • ジョブ実行 • Endpoint 作成 Workspace チーム A Workspace チームB Workspace チームC アセット作成: Model Component Environment Data Registry
145. 本番環境と開発環境 組織規模の拡大やセキュリティ等の理由により開発チームと運用 チームそれぞれに Workspace が割り当てられる状況 ➢開発チームから運用チームへ Model、Environment、Component を共有するための Registry (開発チーム: R/W 運用チーム: Read) モデル開発チーム モデル運用チーム Azure Machine Learning Registries
146. Azure PaaS Services Azure Storage Azure Key Vault Azure Container Registry 運用側 WS にのみ閉域化が要求される場合の構成 Internet Virtual Network Azure Machine Learning Workspace インターネット 接続不可 PrivateEndpointSubnet /27 Private Endpiont Azure Machine Learning Workspace Azure PaaS Services Azure Storage Azure Key Vault Azure Container Registry Azure Machine Learning Registries
147. 機械学習の民主化 専任チームや IT 部門以外の各部門や各チーム単位で機械学習を行う ニーズが生じ、個別に Workspace が割り当てられる状況 ➢共有が必要な組織単位ごとの Registry (R/W) + 組織横断の Registry (管理部門: R/W その他: Read) 部門A チーム1 部門A チーム2 部門A チーム3 部門A Registry 部門B チーム1 部門B チーム2 部門B Registry 部門横断 Registry 管理部門
148. Kubernetes Compute Azure Kubernetes Service (AKS) もしくは外部の任意の Kubernetes クラスター を Azure Machine Learning の計算リソースとしてアタッチする仕組み ジョブの実行、Web API デプロイなどの実行環境として利用可能 https://learn.microsoft.com/en-us/azure/machine-learning/how-to-attach-kubernetes-anywhere?view=azureml-api-2
149. 計算リソースの共有 予算が同一の Workspace ごとに Kubernetes Compute を経由して クラスターをアタッチ、共有リソースとして運用 部門A チーム1 部門A チーム2 部門A チーム3 部門A 共有 AKS 部門B チーム1 部門B チーム2 部門B 共有 AKS 管理部門 管理 管理
150. 外部計算リソースの活用 オンプレミス、Azure 以外の他社クラウドの Kubernetes クラスター をアタッチして共有、既存の設備・契約を活用 部門A チーム1 部門A チーム2 部門A チーム3 部門B チーム1 部門B チーム2 管理部門 管理 外部 Kubernetes
151. LLMOps LLM を使用したアプリケーション開発と運用
152. LLMOps の整理 LLMOps MLOps DevOps 開発対象 • LLM • プロンプト • LLM を組み込んだソフ トウェア • 機械学習モデル • 機械学習モデルを組み 込んだソフトウェア • ソフトウェア オフライン評価 • コードを対象とするテ スト • システムを対象とする テスト • モデル + プロンプトの 推論性能テスト • コードを対象とするテ スト • システムを対象とする テスト • モデルの推論性能テス ト • コードを対象とするテ スト • システムを対象とする テスト オンライン評価 • A/B テスト • A/B テスト • データドリフト • A/B テスト 管理対象 • コード • 実験記録 • モデル • プロンプト • コード • 実験記録 • モデル • コード • ビルド産物
153. LLM ワークフロー LLM の入出力と外部 API/データソースへのアクセスをハンドリング し組み合わせるためのワークフロー 入出力のいずれかもしくは両方が自然言語となる パーツ 役割 LLM • 意図の分類 • 意図に基づく処理内容の生成 • 外部 API/データソースから提供されたデータを基にした応答生成 ワークフローツール • LLM に対する入力と出力のハンドリング • LLM が出力する意図の分類結果ごとの処理を実行する仕組みの提供 外部 API/データソース • データの提供 • LLM が不得意とする処理を担うエンジンの提供
154. ユーザーの質問 LLM Workflow データのクエリ Cognitive Search プロンプトに結果を追加 テキスト生成 Large Language Model 結果の送信 例: LLM をインターフェースとした検索システムのワークフロー
155. LLM ワークフローの実装  ChatGPT Plugins  外部データソース/API へのアクセスを提供するマネージドな仕組み  LangChain/Semantic Kernel/guidance  OSS の LLM アプリケーション作成フレームワーク  LLM ワークフロー実装を補助 (実行計画 or ReAct)  LLM を取り扱う上で典型的な実装を抽象化  Azure Machine Learning Prompt flow  LLM ワークフローを実装するマネージドサービス
156. LLM におけるモデル改善の手法 prompt-tuning  ユーザー入力の前に挿入する、タス クを指示するテキスト (prompt) を 変更する  指示文の調整によって性能改善を試みる  適切なタスクの回答例を数件～数十件付 加することで性能改善を試みる (few- shot learning) fine-tuning  対象タスクのラベル付きデータセッ トを用意し事前学習済みの LLM を 再学習してタスクに特化させる ➢ それぞれ単体でも、双方組み合わせることも可能 ➢ ある時点での「LLM」はモデルとプロンプトの2つのアセットから成立しているため、再現性 確保のためにモデルとプロンプト双方を組み合わせたアセット管理が必要
157. LLM のオフライン評価 LLM の場合もその他 ML におけるオフライン評価と原則同様 ➢ ゴールドスタンダードを用いた精度検証などが有効 ただしタスクごとにオフライン評価の難易度が異なる  インテント分類など、結果が一意に定まる場合は比較的容易に評価可能  要約、翻訳などの、正解に幅はあるもののある程度正解が定まるタスク指向的な自然文を生 成する場合はやや評価が難しい  BLEU、ROUGE などの機械的に計算可能な評価指標である程度は可能  評価指標は人手評価との相関性が薄い場合は人手評価が必要  雑談生成などの正解を一意に定めることができない非タスク指向的な自然文を生成する場合 は定量評価が極めて難しい
158. LLM のオンライン評価 LLM においてデータドリフトによる性能劣化検知は難しいかもしれ ない  自然言語入力に対して、タスク性能と関係を持つ分布の定め方は自明ではない  単純な語彙、 bi-gram や tri-gram 等の出現頻度、文長といった統計量がタスク性能とどこまで関係するかは不明  広い範囲の自然言語に対応できるように事前学習されているため、ドリフトとタスク性能の間に必ずしも相関が 発生するとは限らない  単語の意味のブレや言語の特性を表現する統計量の研究成果が有望？ ➢ 候補メトリックと別の性能評価手法 (代替指標など) の関連を分析し、実用的なメトリックを 見出す必要がある、データサイエンスが重要 KPI を代替指標とした性能モニタリングや A/B テストは恐らく有効  オフラインテストでは困難な、LLM ワークフロー全体の E2E な評価が可能  feature toggle のような UI 改善の分野で発達した仕組みを応用できる可能性がある
159. 自然言語入力におけるデータドリフト 2つのテキストコーパスについて特性を数値化し比較する手法と、そ の手法によって得られた数値が性能劣化と関連することを示すこと が必要 実用的なメトリックは未確立、LLM 実運用に至った組織やアカデ ミックからの報告に期待  著者の識別やテキストコーパスの分類に使用でき得る一定性指標  Computational Constancy Measures of Texts—Yule’s K and Rényi’s Entropy (Tanaka-Ishii & Aihara, CL 2015)  LLM の事前学習に用いるコーパス内に含まれる単語の時系列意味変化を捉えるメトリックと、 メトリックと LLM 性能の関連性分析  Semantic Shift Stability: Efficient Way to Detect Performance Degradation of Word Embeddings and Pre- trained Language Models (Ishihara et al., AACL-IJCNLP 2022)
160. LLM による LLMOps を試みる上での注意点  LLM を使ったシステムの開発運用、特に性能評価や改善を LLM に よって実行する手法が出現  高精度なコード生成能力を背景に、API とプログラムで可能な処理を自動実行できる状況に なった  ReAct の実装により LLM によって LLM システムの評価と改善 (prompt-tuning) が可能に なった ◆適切に評価・改善できているか、オフライン・オンラインテストや Human-in-the-loop によって継続的に検証するか必要がある  LLM による評価と人の評価は必ずしも一致しない、LLM による「改善」が人にとっての 「改善」であるかは要検証  責任ある AI の原則のうち特に「アカウンタビリティ」を守るために重要 https://www.microsoft.com/ja-jp/ai/responsible-ai?activetab=pivot1%3aprimaryr6
161. LLM 開発における新たな「アセット」  プロンプト  モデルとセットでシステムの性能を決定する要素  モデルに対して従属的  モデル  自前のモデルを使用する場合は通常の MLOps 同様  API を利用する場合は API のバージョンが相当  ワークフロー  アプリ実装として扱うか、別のアセットとして扱うかは実装手段次第
162.  選択した フレームワーク と API を使 用して さまざまな 言語モデル と デー タソース を使用する AI ワークフロー を作成  1つのプラットフォームで 生成 AI ワークフロー の 構築、調整、評価を 迅速に反復  事前構築済の指標で AI ワークフロー の品質を評価 Prompt flow (preview)
163. Prompt flow
164. ◼ 本書に記載した情報は、本書各項目に関する発行日現在の Microsoft の見解を表明するものです。Microsoftは絶えず変化する市場に対応しなければならないため、ここに記載した情報に対していかなる責務を負うものではなく、 提示された情報の信憑性については保証できません。 ◼ 本書は情報提供のみを目的としています。 Microsoft は、明示的または暗示的を問わず、本書にいかなる保証も与えるものではありません。 ◼ すべての当該著作権法を遵守することはお客様の責務です。Microsoftの書面による明確な許可なく、本書の如何なる部分についても、転載や検索システムへの格納または挿入を行うことは、どのような形式または手段（電子的、 機械的、複写、レコーディング、その他）、および目的であっても禁じられています。 これらは著作権保護された権利を制限するものではありません。 ◼ Microsoftは、本書の内容を保護する特許、特許出願書、商標、著作権、またはその他の知的財産権を保有する場合があります。Microsoftから書面によるライセンス契約が明確に供給される場合を除いて、本書の提供はこれら の特許、商標、著作権、またはその他の知的財産へのライセンスを与えるものではありません。 © 2023 Microsoft Corporation. All rights reserved. Microsoft, Windows, その他本文中に登場した各製品名は、Microsoft Corporation の米国およびその他の国における登録商標または商標です。 その他、記載されている会社名および製品名は、一般に各社の商標です。