ml-mlops

ML MLOps

概要

実験の追跡、再現性、オーケストレーション、レジストリ、CI/CD、モデルデプロイのガバナンス、モニタリング、ドリフトへの対応、再トレーニングなど、機械学習の運用にはこのスキルを使用します。MLOps は、ノートブックやスクリプトを、責任の所在とロールバック方法が明確な、監査可能で再現性のあるシステムへと変えます。

MLOps の不変条件

本番環境の ML ワークフローでは、次の問いに答えられる必要があります。

• このモデルの生成に使われたデータ、コード、設定、環境、ハードウェアは何ですか？
• プロモーションを正当化した指標、データスライス、テストは何ですか？
• モデルのアーティファクトはどこに保存されていて、どのようにロールバックできますか？
• 入力データとサービング機能を検証するものは何ですか？
• 品質、ドリフト、レイテンシー、コスト、安全性、公平性を監視するものは何ですか？
• インシデント、再トレーニング、承認、廃止の責任者は誰ですか？

いずれかの答えが欠けている場合は、インフラを追加する前にライフサイクルを改善してください。

実験の追跡

パラメーター、指標、アーティファクト、データセットのバージョン、コードのリビジョン、環境、乱数シード、実行メモ、タグを追跡します。オープンなモデルレジストリのワークフローでは MLflow が優れたデフォルトの選択肢です。Weights & Biases は充実した実験ダッシュボードとスイープに強く、Neptune、Comet、ClearML も同様のコラボレーションやアーティファクト管理のニーズに対応します。ダッシュボードの見た目だけでなく、ガバナンス、ホスティング、統合機能、チームのワークフローに基づいて選択してください。

実験と実行には一貫性のある名前を付けます。最終指標と学習曲線の両方を記録します。混同行列、キャリブレーションプロット、特徴量の重要度、検証データに対する予測、代表的なエラーを保存します。トラッキングバックエンドがそのデータ分類の取り扱いについて承認されていない限り、シークレット、生の PII、または独自の事例を記録しないでください。

モデルレジストリとバージョニング

レジストリのエントリーには、アーティファクト URI、モデルのシグネチャまたはスキーマ、入出力の例、前処理／トークナイザーの参照情報、依存関係の環境、トレーニングデータセットの識別子、評価レポート、承認状態、担当者、変更履歴、想定用途を含める必要があります。

標準化されたモデルレジストリのメタデータスキーマ（JSON）

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "title": "ModelRegistryMetadata",
  "type": "object",
  "properties": {
    "model_name": { "type": "string" },
    "version": { "type": "string" },
    "artifact_uri": { "type": "string", "format": "uri" },
    "framework": {
      "type": "object",
      "properties": {
        "name": { "type": "string" },
        "version": { "type": "string" }
      },
      "required": ["name", "version"]
    },
    "signature": {
      "type": "object",
      "properties": {
        "inputs": {
          "type": "array",
          "items": {
            "type": "object",
            "properties": {
              "name": { "type": "string" },
              "type": { "type": "string" },
              "shape": { "type": "array", "items": { "type": "integer" } }
            },
            "required": ["name", "type"]
          }
        },
        "outputs": {
          "type": "array",
          "items": {
            "type": "object",
            "properties": {
              "name": { "type": "string" },
              "type": { "type": "string" },
              "shape": { "type": "array", "items": { "type": "integer" } }
            },
            "required": ["name", "type"]
          }
        }
      },
      "required": ["inputs", "outputs"]
    },
    "provenance": {
      "type": "object",
      "properties": {
        "git_commit": { "type": "string" },
        "dataset_snapshot_uri": { "type": "string" },
        "environment_lockfile_uri": { "type": "string" }
      },
      "required": ["git_commit", "dataset_snapshot_uri"]
    }
  },
  "required": ["model_name", "version", "artifact_uri", "framework", "signature", "provenance"]
}

ステージの移行は、自動化された品質ゲートと、リスクに応じた人間の承認によって管理する必要があります。candidate、staging、production、archived などのセマンティックなモデルラベルは、その意味が確実に適用される場合に限り使用します。DVC、レイクハウスのテーブルバージョン、オブジェクトストレージのマニフェスト、特徴量ストアのマテリアライズ時刻などのツールでデータセットをバージョン管理します。モデルのバージョンだけでは不十分です。データと特徴量コードもモデルの一部です。

パイプラインのオーケストレーション

運用環境に応じてオーケストレーションを選択します。

プラットフォーム	最適な用途
Kubeflow Pipelines	Kubernetes ネイティブの ML ワークフロー、移植可能なコンポーネント、複雑な DAG
SageMaker Pipelines	AWS ネイティブのトレーニング、処理、モデルレジストリ、エンドポイント、Feature Store、Clarify、Model Monitor
Vertex AI Pipelines	GCP ネイティブのトレーニング、エンドポイント、Feature Store、Model Monitoring、AutoML との統合
Azure ML Pipelines	Azure ワークスペース、マネージドコンピューティング、レジストリ、マネージドエンドポイント、Responsible ML
Databricks Workflows	レイクハウス中心の特徴量エンジニアリング、MLflow レジストリ、Spark、Delta、ノートブック／ジョブ
Airflow/Prefect/Dagster	幅広いエコシステム統合を備えた、汎用的なデータ／ML オーケストレーション

パイプラインはモジュール化します。データ検証、特徴量生成、トレーニング、評価、登録、デプロイ、モニタリングの設定は、入力と出力が明示された個別のステップにする必要があります。安全な場合は、ステップを冪等にし、キャッシュを活用します。CI での Azure ML コードアセットの登録、ADF から Azure ML へのバージョン伝播、ポインターブロブ、または ADF WebActivity パスの実行時検証には、ml-azureml-adf-automation を読み込みます。

ML の CI/CD

CI では、コードのリンティング、前処理のユニットテスト、スキーマテスト、小規模データによる決定論的なトレーニングのスモークテスト、モデル読み込みテスト、シリアライズテスト、推論コントラクトテスト、セキュリティスキャンなど、時間のかからないチェックを実行する必要があります。CD では、評価ゲートを通過したアーティファクトのみをデプロイします。

本番環境向け GitHub Actions MLOps ワークフロー（.github/workflows/mlops.yml）

name: MLOps CI/CD Workflow

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  lint-and-test:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
    - name: Set up Python
      uses: actions/setup-python@v4
      with:
        python-version: '3.10'
        cache: 'pip'
    - name: Install dependencies
      run: |
        python -m pip install --upgrade pip
        pip install ruff pytest pytest-cov -r requirements.txt
    - name: Lint with Ruff
      run: ruff check src/
    - name: Run unit tests
      run: pytest tests/unit/ --cov=src --cov-report=xml
      
  model-smoke-test:
    needs: lint-and-test
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
    - name: Set up Python
      uses: actions/setup-python@v4
      with:
        python-version: '3.10'
    - name: Run small-scale training smoke test
      run: |
        pip install -r requirements.txt
        python src/train.py --config configs/smoke_test.yaml
    - name: Verify model serialization & load contract
      run: python src/verify_contract.py --model_path outputs/model.pt

  promote-and-deploy:
    needs: model-smoke-test
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
    - name: Deploy model to Staging endpoint
      env:
        AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
        AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
      run: |
        pip install awscli
        # Trigger staging endpoint update
        python scripts/deploy.py --stage staging

モデルのサービングには、ブルー／グリーン、カナリア、シャドウ、または A/B デプロイを使用します。最初は少量のトラフィックをカナリアとして流し、ガードレールを監視してから拡大します。シャドウモードはリスクのない比較に役立ちますが、判断に基づいて実際にアクションを実行しない限り、ユーザーへの影響に関する指標は測定できません。常にロールバックを簡単に行えるようにし、テストしておきます。

データ検証

トレーニングとサービングの前にデータを検証します。Great Expectations、TFDV、Deequ を使用して、スキーマや分布に関する期待値を適用できます。

Great Expectations 検証スイートのセットアップ

import great_expectations as ge
from great_expectations.core.expectation_suite import ExpectationSuite

def create_ingestion_validation_suite(suite_name: str = "ingestion_suite") -> ExpectationSuite:
    context = ge.get_context()
    suite = context.create_expectation_suite(suite_name, overwrite_existing=True)
    
    # Assert column names exist
    suite.add_expectation({
        "expectation_type": "expect_table_columns_to_match_ordered_list",
        "kwargs": {
            "column_list": ["user_id", "timestamp", "feature_a", "feature_b", "label"]
        }
    })
    
    # Assert feature_a ranges
    suite.add_expectation({
        "expectation_type": "expect_column_values_to_be_between",
        "kwargs": {
            "column": "feature_a",
            "min_value": 0.0,
            "max_value": 100.0
        }
    })
    
    # Assert label is never null
    suite.add_expectation({
        "expectation_type": "expect_column_values_to_not_be_null",
        "kwargs": {
            "column": "label"
        }
    })
    
    context.save_expectation_suite(suite)
    return suite

タイムトラベル結合によって未来情報の漏洩を防ぎ、オンライン特徴量の鮮度を監視していることを確認します。

監視とドリフト

次の 4 つのレイヤーで監視します。

1. システム：可用性、レイテンシー、スループット、エラー、GPU／CPU／メモリ使用率、キューの長さ、コスト。
2. データ：スキーマ、NULL 値、範囲、カテゴリのカーディナリティ、埋め込みのノルム、テキストの長さ、画像の寸法、特徴量分布のドリフト。
3. 予測：スコア分布、信頼度、キャリブレーション、クラス分布、しきい値の結果、拒否／安全性ラベル。
4. 結果：遅延ラベル、ビジネス指標、公平性のスライス、人手レビュー率、インシデント。

本番環境の監視アラートしきい値リファレンス

指標カテゴリ	対象指標	推奨アラートしきい値	診断アクション
システム	p99 レイテンシー	5 分間連続で > 200ms	サービングコンテナのスレッドプール、GPU／CPU のボトルネック、ネットワークストレージを調査する
システム	エラー率	任意の 1 分間のウィンドウで > 1.0%	生入力の検証での OOM やスキーマ違反がないか、サービングバックエンドのログを確認する
データ	特徴量ドリフト（PSI）	Population Stability Index > 0.25	調査を開始し、ソースデータのスキーマ変更や上流フィルターの変更を確認する
予測	スコアドリフト（KS）	Kolmogorov-Smirnov Test の p 値 < 0.01	ラベル／概念ドリフトの可能性についてアラートを出し、予測分布をベースラインと比較する
結果	キャリブレーションのドリフト	Brier Score がベースライン比で > 15% 悪化	概念ドリフトを確認し、ログ収集と手動ラベリングキューへの追加を指示する

ドリフトは調査のきっかけであり、再トレーニングによって結果が改善することの自動的な証明ではありません。

ガバナンス、セキュリティ、コンプライアンス

想定される用途、対象外の用途、トレーニングデータの制約、モデルの限界、既知のリスク、評価スライスを文書化します。データ、アーティファクト、レジストリ、エンドポイントには最小権限のアクセス制御を適用します。コンテナと依存関係をスキャンします。マネージドシークレットストアでシークレットを保護します。転送中と保存時のアーティファクトおよびデータを暗号化します。機密性の高いシステムでは、データアクセス、承認、デプロイ、インシデントの監査ログを保持します。

コスト管理

リソースにプロジェクトと所有者のタグを付け、自動スケーリングを使用し、エンドポイントのサイズを適正化し、アイドル状態のノートブックやクラスターをシャットダウンします。チェックポイントを使用できる場合に限り、スポット／プリエンプティブルインスタンスでのトレーニングを優先し、バッチ推論をオフピークにスケジュールします。レイテンシーが許容される場合は、サーバーレス推論や CPU 推論を評価します。トレーニング実行あたりのコスト、予測 1,000 件あたりのコスト、採用されたモデル改善あたりのコストを追跡します。

参考資料

• MLflow ドキュメント：https://mlflow.org/docs/latest/index.html
• Weights & Biases ドキュメント：https://docs.wandb.ai/
• Kubeflow Pipelines ドキュメント：https://www.kubeflow.org/docs/components/pipelines/
• AWS SageMaker MLOps ドキュメント：https://docs.aws.amazon.com/sagemaker/
• Vertex AI MLOps ドキュメント：https://cloud.google.com/vertex-ai/docs
• Azure Machine Learning ドキュメント：https://learn.microsoft.com/azure/machine-learning/