Amazon Quick を使用した Amazon SageMaker AI エンドポイントの推論メタモニタリング

機械学習（ML）モデルが本番環境にデプロイされた後、継続的に監視されていないと、組織は顧客からの苦情やスポットチェックによってのみ問題に気づくことになり、顧客の信頼を損なう可能性があります。この記事では、Amazon SageMaker AI エンドポイント向けの推論メタモニタリングシステムを紹介します。これは、本番 ML 推論パイプラインの上位に位置するガバナンスレイヤーであり、予測とデータ品質のメトリクスを継続的に追跡し、トレンドを可視化します。

推論モニタリングのギャップ

予測 ML モデルの開発は、多くの場合、リソースを大量に消費するプロセスです。チームは、不正検出、信用スコアリング、需要予測などのユースケースで強力な検証精度を達成するために、トレーニングパイプラインの構築に数ヶ月を費やします。しかし、デプロイされたモデルのパフォーマンスは静かに劣化する可能性があり、チームがそれに気づくのは数週間後になることがよくあります。不正対応担当者は誤検出の急増を目にし、融資担当者は以前ならフラグが立てられたはずの申請が増えていることに気づき、企業のリソースプランナーは需要予測の過大評価により過剰在庫に直面します。

したがって、ML チームには、本番環境でのモデルのパフォーマンスに関する継続的なフィードバックを提供するシステムが必要です。システムは、モデル品質やデータドリフトが検出された場合にすぐにアラートを発し、チームが早期に対処できるようにし、モデルのパフォーマンスを長期間一貫させ、顧客の信頼を維持する必要があります。

ソリューション概要

この推論メタモニタリングソリューションは、AWS マネージドサービス（Amazon SageMaker AI、Amazon Athena、AWS Lambda、Amazon EventBridge、Amazon Quick）とオープンソース ML ツール（SageMaker AI MLflow Apps、Evidently AI）を組み合わせています。

前提条件

AWS アカウントが必要です。リポジトリで提供されている CloudFormation テンプレートを使用して、仮想プライベートクラウド（VPC）、サブネット、SageMaker AI ドメイン、ユーザープロファイル、JupyterLab スペースを作成します。このテンプレートは、Git リポジトリをクローンし、.env を実際の値で更新します。

セットアップ

CloudFormation テンプレートはセットアップ全体を自動化します。既存のドメインを使用する場合は、リポジトリをクローンし、env 値を更新して、ノートブックを順番に実行できます。

アーキテクチャ

このシステムは、統合されたトレーニング、推論、モニタリングパイプラインを実装し、中央の Athena Iceberg テーブル、Amazon Quick、SageMaker AI MLflow Apps によって統一されています。

トレーニングパイプライン（1_training_pipeline.ipynb）

トレーニングパイプラインには、MLflow での実験追跡が含まれています。エンドツーエンドのモデルトレーニングを設定します：Kaggle からクレジットカード不正検出データセットをダウンロードし、データを S3 からトレーニングデータに取り込みます。アーキテクチャは 5 つの Athena Iceberg テーブルを使用して中央データレイクを形成します。training_data テーブルはモデルが適合される 80% のデータを格納し、evaluation_data テーブルはモデルがスコアリングされる凍結された 20% のホールドアウトスライスです。evaluation_data はドリフトモニタリングのベースラインであり、ホールドアウトスライスは登録されたすべてのモデルのメトリクスが測定される基準です。両方のテーブルは、transaction_id の決定論的ハッシュ分割によって同じ予測 CSV から入力され、行の分割がパイプライン実行間で安定していることが保証されます。

モデルデプロイ（2_deployment.ipynb）

デプロイ手順では、カスタムハンドラーを SageMaker AI 推論エンドポイントにデプロイします。推論ハンドラーはすべての推論を Amazon Simple Queue Service（Amazon SQS）に書き込み、それが inference-logger Lambda 関数によって処理されます。この Lambda 関数は、最大 10 個の予測、または 30 秒以内に到着した予測数をバッチ処理し、Athena Iceberg テーブルに書き込みます。

推論モニタリング（3_inference_monitoring.ipynb）

モニタリング手順には、グラウンドトゥルースのシミュレーションとドリフト計算が含まれます。まず、ドリフトした入力特徴量でモデルを呼び出してデータドリフトをシミュレートします。実際の環境では、これは時間の経過とともにドリフトした入力を送信するビジネスアプリケーションに相当します。次に、グラウンドトゥルースをシミュレートします：実際のフィールドをランダムに不正/非不正に反転させ、15% の不正確さを注入してモデルドリフトを誘導します。

次に、inference_responses テーブル内の予測を、ground_truth_updates テーブル内の非同期ラベル確認とマージします。マージ後、システムはデータドリフトとモデルドリフトを計算します。データドリフトの場合、トレーニングデータの凍結スライスを参照分布として使用し、最近の推論入力特徴量をベースラインと比較します。モデルドリフトの場合、評価データの凍結スライスを使用し、最近の推論（グラウンドトゥルースと結合）をベースラインと比較して、ROC-AUC、適合率、再現率、F1 の低下を追跡します。

ドリフト Lambda 関数は、エンドポイントが現在提供しているモデルを解決し、その登録された baseline.json をロードし、2 つの独立したチェックを実行します。各実行の出力は monitoring_responses テーブルに保存され、モデルパッケージ ARN と Iceberg スナップショット ID が含まれ、モデルバージョンごとにトレンドをスライスできます。

各登録モデルは、evaluation_data で獲得したメトリクス、そのデータスライスの Iceberg スナップショット ID、およびそれを生成したコードコミット SHA を記録する凍結された baseline.json アーティファクトを保持します。ドリフト Lambda は実行のたびにこれらのポインタを逆参照するため、モニタリングシステムは常にデプロイされたモデルが由来する正確なバージョンのデータとコードに対して本番環境を比較し、古いまたは間違ったバージョンの参照を回避します。

このメタモニタリングシステムにより、ML チームはモデル品質やデータドリフトが発生したときに即座にアラートを受け取り、モデルのパフォーマンスを一貫して維持し、顧客の信頼を守ることができます。