モデルモニター FAQs

Amazon SageMaker Model Monitor の詳細については、以下FAQsを参照してください。

Q: Model Monitor と SageMaker Clarify は、お客様がモデルの動作をモニタリングするのにどのように役立ちますか？

お客様は、Amazon Model Monitor と SageMaker Clarify を通じて、データ品質、モデル品質、バイアスドリフト、特徴量属性ドリフトの 4 つのディメンションで SageMaker モデルの動作をモニタリングできます。Model Monitor は、本番環境の Amazon SageMaker 機械学習モデルの品質を継続的にモニタリングします。これには、データ品質のドリフトのモニタリングや、精度やなどのモデル品質メトリクスが含まれますRMSE。バイアスモニタリングSageMaker を明確にすることで、データサイエンティストや ML エンジニアはモデルの予測と特徴量属性ドリフトのバイアスをモニタリングできます。

Q: Sagemaker モデルモニターを有効にすると、バックグラウンドでは何が起きますか?

Amazon SageMaker Model Monitor は、モデルのモニタリングを自動化し、モデルを手動でモニタリングしたり、追加のツールを構築したりする必要性を軽減します。プロセスを自動化するために、Model Monitor では、モデルのトレーニングに使用したデータを使ってベースライン統計と制約のセットを作成し、エンドポイントで行われる予測をモニタリングするスケジュールを設定することができます。Model Monitor は、ルールを使用してモデルのドリフトを検出し、ドリフトが発生した場合はアラートが表示されます。次の手順では、モデルモニタリングを有効にするとどうなるかを説明します。

モデルモニタリングを有効にする: リアルタイムエンドポイントでは、デプロイされた ML モデルへの受信リクエストとその結果として得られたモデル予測からのデータをエンドポイントがキャプチャできるようにする必要があります。バッチ変換ジョブでは、バッチ変換の入出力のデータキャプチャを可能にします。
ベースライン処理ジョブ: モデルのトレーニングに使用されたデータセットからベースラインを作成します。ベースラインはメトリクスを計算し、メトリクスの制約を提案します。例えば、モデルのリコールスコアが下がって 0.571 を下回ったり、精度スコアが 1.0 を下回ったりしてはいけません。モデルから得たリアルタイム予測またはバッチ予測はこの制約と比較され、制約値から外れている場合は違反として報告されます。
モニタリングジョブ: T 収集するデータ、収集する頻度、分析方法、作成するレポートを指定するモニタリングスケジュールを作成します。
マージジョブ： これは Amazon SageMaker Ground Truth を利用している場合にのみ適用されます。Model Monitor では、モデルの予測を Ground Truth ラベルと比較し、モデルの品質を測定します。これを機能させるには、エンドポイントでキャプチャされたデータを定期的にラベル付けし、Amazon S3 にアップロードする必要がありますます。

Ground Truth ラベルを作成してアップロードした後、モニタリングジョブを作成するときにそのラベルの場所をパラメータとして含めます。

Model Monitor を使用してリアルタイムエンドポイントの代わりにバッチ変換ジョブをモニタリングする場合、エンドポイントへのリクエストを受信して予測を追跡する代わりに、Model Monitor は推論の入出力をモニタリングします。Model Monitor のスケジュールでは、処理ジョブで使用されるインスタンスの数とタイプを顧客が指定します。これらのリソースは、現在の実行状況に関係なく、スケジュールが削除されるまで確保されています。

Q: データキャプチャとはどういうものですか? なぜ必要なのですか? また、どうすれば有効にできますか?

モデルエンドポイントへの入力とデプロイされたモデルからの推論出力を Amazon S3 に記録するために、データキャプチャという機能を有効にできます。リアルタイムエンドポイントとバッチ変換ジョブで有効にする方法の詳細については、「Capture data from real-time endpoint」と「 Capture data from batch transform job」を参照してください。

Q: データキャプチャを有効にすると、リアルタイムエンドポイントのパフォーマンスに影響しますか?

データキャプチャは本番トラフィックに影響を与えずに非同期的に行われます。データキャプチャを有効にすると、要求ペイロードと応答ペイロードは、追加のメタデータとともに、DataCaptureConfig で指定した Amazon S3 の場所に保存されます。キャプチャしたデータの Amazon S3 への伝播には遅延があることに注意してください。

Amazon S3 に保存されたデータキャプチャファイルを一覧表示して、キャプチャされたデータを表示することもできます。Amazon S3 のパス形式は次のとおりです。s3:///{endpoint-name}/{variant-name}/yyyy/mm/dd/hh/filename.jsonlAmazon S3 データキャプチャは Model Monitor スケジュールと同じリージョンにある必要があります。また、ベースラインデータセットの列名は小文字で、区切り文字はアンダースコア (_) のみにする必要があります。

Q: モデルモニタリングに Ground Truth が必要なのはなぜですか?

Ground Truth ラベルは、Model Monitor の以下の特徴量に必要です。

モデル品質モニタリングでは、モデルの予測を Ground Truth ラベルと比較し、モデルの品質を測定します。
モデルバイアスモニタリングは、予測にバイアスがないかをモニタリングします。デプロイされた ML モデルにバイアスが生じる可能性の 1 つは、トレーニングに使用されるデータが予測の生成に使用されるデータと異なる場合です。これは、トレーニングに使用されるデータが時間の経過とともに変化し (住宅ローン金利の変動など)、更新されたデータでモデルを再トレーニングしない限りモデル予測の精度が下がる場合に特に顕著になります。例えば、モデルトレーニングに使用された住宅ローン金利が実際の最新の住宅ローン金利と異なる場合、住宅価格を予測するためのモデルの出力にバイアスが生じる可能性があります。

Q: Ground Truth をラベリングに利用している場合、モデルの品質をモニタリングするために実行できる手順を教えてください。

モデル品質モニタリングでは、モデルの予測を Ground Truth ラベルと比較し、モデルの品質を測定します。これを機能させるには、エンドポイントでキャプチャされたデータを定期的にラベル付けし、Amazon S3 にアップロードする必要がありますます。モデルバイアスモニタリングの実行には、キャプチャの他に、Ground Truth データも必要です。実際のユースケースでは、Ground Truth データを定期的に収集し、指定された Amazon S3 の場所にアップロードする必要があります。Ground Truth ラベルとキャプチャされた予測データを照合するには、データセット内の各レコードに一意の識別子が必要です。Ground Truth データの各レコードの構造については、「Ingest Ground Truth Labels and Merge Them With Predictions」を参照してください。

次のコード例は、表形式データセットの人工的な Ground Truth データを生成するために使用できます。


import random

def ground_truth_with_id(inference_id):
    random.seed(inference_id)  # to get consistent results
    rand = random.random()
    # format required by the merge container
    return {
        "groundTruthData": {
            "data": "1" if rand < 0.7 else "0",  # randomly generate positive labels 70% of the time
            "encoding": "CSV",
        },
        "eventMetadata": {
            "eventId": str(inference_id),
        },
        "eventVersion": "0",
    }


def upload_ground_truth(upload_time):
    records = [ground_truth_with_id(i) for i in range(test_dataset_size)]
    fake_records = [json.dumps(r) for r in records]
    data_to_upload = "\n".join(fake_records)
    target_s3_uri = f"{ground_truth_upload_path}/{upload_time:%Y/%m/%d/%H/%M%S}.jsonl"
    print(f"Uploading {len(fake_records)} records to", target_s3_uri)
    S3Uploader.upload_string_as_file_body(data_to_upload, target_s3_uri)
# Generate data for the last hour
upload_ground_truth(datetime.utcnow() - timedelta(hours=1))
# Generate data once a hour
def generate_fake_ground_truth(terminate_event):
    upload_ground_truth(datetime.utcnow())
    for _ in range(0, 60):
        time.sleep(60)
        if terminate_event.is_set():
            break


ground_truth_thread = WorkerThread(do_run=generate_fake_ground_truth)
ground_truth_thread.start()

次のコード例は、モデルエンドポイントに送信する人工的なトラフィックを生成する方法を示しています。上記で呼び出す際に使用した inferenceId 属性に注目してください。これが存在する場合は、Ground Truth データとの結合に使用されます (存在しない場合、eventId が使用されます)。


import threading

class WorkerThread(threading.Thread):
    def __init__(self, do_run, *args, **kwargs):
        super(WorkerThread, self).__init__(*args, **kwargs)
        self.__do_run = do_run
        self.__terminate_event = threading.Event()

    def terminate(self):
        self.__terminate_event.set()

    def run(self):
        while not self.__terminate_event.is_set():
            self.__do_run(self.__terminate_event)
def invoke_endpoint(terminate_event):
    with open(test_dataset, "r") as f:
        i = 0
        for row in f:
            payload = row.rstrip("\n")
            response = sagemaker_runtime_client.invoke_endpoint(
                EndpointName=endpoint_name,
                ContentType="text/csv",
                Body=payload,
                InferenceId=str(i),  # unique ID per row
            )
            i += 1
            response["Body"].read()
            time.sleep(1)
            if terminate_event.is_set():
                break


# Keep invoking the endpoint with test data
invoke_endpoint_thread = WorkerThread(do_run=invoke_endpoint)
invoke_endpoint_thread.start()

Ground Truth データは、キャプチャされたデータと同じパス形式の Amazon S3 バケットにアップロードする必要があります。これは、次の形式です。s3://<bucket>/<prefix>/yyyy/mm/dd/hh

注記

このパスの日付は、Ground Truth ラベルが収集される日付です。推論が生成された日付と一致している必要はありません。

Q: 顧客はどのようにモニタリングスケジュールをカスタマイズできますか?

組み込みのモニタリングメカニズムを使用するだけでなく、前処理スクリプトと後処理スクリプトを使用したり、独自のコンテナを使用または構築したりして、独自のカスタムモニタリングスケジュールと手順を作成できます。前処理スクリプトと後処理スクリプトは、データとモデル品質ジョブでのみ機能することに注意してください。

Amazon SageMaker は、モデルエンドポイントによって観測されたデータをモニタリングおよび評価するための機能を提供します。そのためには、リアルタイムトラフィックを比較するベースラインを作成する必要があります。ベースラインの準備ができたら、継続的に評価してベースラインと比較するスケジュールを設定します。スケジュールを作成するときに、前処理と後処理のスクリプトを用意できます。

次の例は、前処理スクリプトと後処理スクリプトでモニタリングスケジュールをカスタマイズする方法を示しています。


import boto3, osfrom sagemaker import get_execution_role, Sessionfrom sagemaker.model_monitor import CronExpressionGenerator, DefaultModelMonitor
# Upload pre and postprocessor scripts
session = Session()
bucket = boto3.Session().resource("s3").Bucket(session.default_bucket())
prefix = "demo-sagemaker-model-monitor"
pre_processor_script = bucket.Object(os.path.join(prefix, "preprocessor.py")).upload_file("preprocessor.py")
post_processor_script = bucket.Object(os.path.join(prefix, "postprocessor.py")).upload_file("postprocessor.py")
# Get execution role
role = get_execution_role() # can be an empty string
# Instance type
instance_type = "instance-type"
# instance_type = "ml.m5.xlarge" # Example
# Create a monitoring schedule with pre and post-processing
my_default_monitor = DefaultModelMonitor(
    role=role,
    instance_count=1,
    instance_type=instance_type,
    volume_size_in_gb=20,
    max_runtime_in_seconds=3600,
)

s3_report_path = "s3://{}/{}".format(bucket, "reports")
monitor_schedule_name = "monitor-schedule-name"
endpoint_name = "endpoint-name"
my_default_monitor.create_monitoring_schedule(
    post_analytics_processor_script=post_processor_script,
    record_preprocessor_script=pre_processor_script,
    monitor_schedule_name=monitor_schedule_name,
    # use endpoint_input for real-time endpoint
    endpoint_input=endpoint_name,
    # or use batch_transform_input for batch transform jobs
# batch_transform_input=batch_transform_name,
    output_s3_uri=s3_report_path,
    statistics=my_default_monitor.baseline_statistics(),
    constraints=my_default_monitor.suggested_constraints(),
    schedule_cron_expression=CronExpressionGenerator.hourly(),
    enable_cloudwatch_metrics=True,
)

Q: 前処理スクリプトを利用できるシナリオやユースケースにはどのようなものがありますか?

モデルモニターへの入力を変換する必要がある場合は、前処理スクリプトを使用します。例えば、次のシナリオ例を考えてみます。

データ変換用の前処理スクリプト。

モデルの出力が配列 [1.0, 2.1] だと仮定します。Model Monitor コンテナは、などの表形式またはフラット化されたJSON構造でのみ機能します{“prediction0”: 1.0, “prediction1” : 2.1}。次の例のような前処理スクリプトを使用して、配列を正しいJSON構造に変換できます。
```
def preprocess_handler(inference_record):
    input_data = inference_record.endpoint_input.data
    output_data = inference_record.endpoint_output.data.rstrip("\n")
    data = output_data + "," + input_data
    return { str(i).zfill(20) : d for i, d in enumerate(data.split(",")) }
```
Model Monitor のメトリクス計算で特定のレコードを除外します。

モデルにオプションの特徴量があり、そのオプションの特徴量に欠測値があることを示すために -1 を使用すると仮定します。データ品質モニターを使用している場合は、モニターのメトリクス計算に含まれないように、入力値の配列から -1 を削除したほうがよい場合があります。次のようなスクリプトを使用して、これらの値を削除できます。
```
def preprocess_handler(inference_record):
    input_data = inference_record.endpoint_input.data
    return {i : None if x == -1 else x for i, x in enumerate(input_data.split(","))}
```
カスタムサンプリング戦略の適用。

前処理スクリプトにカスタムサンプリング戦略を適用することもできます。そのためには、Model Monitor のファーストパーティのビルド済みコンテナを設定して、指定したサンプリングレートに従って一部のレコードを無視するようにします。次の例では、ハンドラーはハンドラー呼び出しの 10% のレコードを返し、それ以外の場合は空のリストを返すことで、レコードの 10% をサンプリングします。
```
import random

def preprocess_handler(inference_record):
    # we set up a sampling rate of 0.1
    if random.random() > 0.1:
        # return an empty list
        return []
    input_data = inference_record.endpoint_input.data
    return {i : None if x == -1 else x for i, x in enumerate(input_data.split(","))}
```
カスタムログ記録を使用します。

スクリプトから必要な情報はすべて Amazon に記録できます CloudWatch。これは、エラーが発生した場合に前処理スクリプトをデバッグするときに役立ちます。次の例は、 preprocess_handlerインターフェイスを使用してにログ記録する方法を示しています CloudWatch。
```
def preprocess_handler(inference_record, logger):
    logger.info(f"I'm a processing record: {inference_record}")
    logger.debug(f"I'm debugging a processing record: {inference_record}")
    logger.warning(f"I'm processing record with missing value: {inference_record}")
    logger.error(f"I'm a processing record with bad value: {inference_record}")
    return inference_record
```

注記

前処理スクリプトをバッチ変換データに対して実行する場合、入力タイプは必ずしも CapturedData オブジェクトではありません。CSV データの場合、型は文字列です。JSON データの場合、タイプは Python ディクショナリです。

Q: 後処理スクリプトはいつ利用できますか?

モニタリングが正常に実行された後は、後処理スクリプトを拡張機能として利用できます。以下は簡単な例ですが、モニタリングが正常に実行された後に実行する必要のあるビジネス機能を実行または呼び出すことができます。


def postprocess_handler(): 
    print("Hello from the post-processing script!")

Q: モデルモニタリング用に独自のコンテナを持ち込むことを検討すべきタイミングはいつですか?

SageMaker は、表形式データセットのエンドポイントまたはバッチ変換ジョブからキャプチャされたデータを分析するための構築済みのコンテナを提供します。ただし、独自のコンテナを作成する必要がある場合もあります。次のシナリオを考えてみてください。

組織内で作成、管理されているコンテナのみを使用するという規制要件やコンプライアンス要件がある。
いくつかのサードパーティーライブラリを含める場合は、ローカルディレクトリにrequirements.txtファイルを配置し、SageMaker 推定器の source_dirパラメータを使用して参照できます。これにより、実行時にライブラリをインストールできます。ただし、トレーニングジョブの実行中にインストール時間を短縮するライブラリや依存関係が多数ある場合は、を活用できますBYOC。
使用している環境ではインターネット接続 (またはサイロ) が強制されないため、パッケージのダウンロードが妨げられる。
NLP や CV のユースケースなど、表形式以外のデータ形式のデータをモニタリングする場合。
Model Monitor がサポートしていないモニタリングメトリクスが必要な場合。

Q: NLPと CV モデルがあります。データドリフトをモニタリングする方法を教えてください。

Amazon SageMakerのビルド済みコンテナは表形式のデータセットをサポートしています。モデルNLPと CV モデルをモニタリングする場合は、Model Monitor が提供する拡張ポイントを活用して独自のコンテナを持ち込むことができます。要件に関する詳細については、「Bring your own containers」を参照してください。以下にその他の例を示します。

コンピュータービジョンのユースケースで Model Monitor を使用する方法の詳細な説明については、「Amazon SageMaker Model Monitor と Debugger を使って不正な予測を検知して分析する」を参照してください。
Model Monitor をNLPユースケースに活用できるシナリオについては、「カスタム Amazon SageMaker Model Monitor を使用してNLPデータドリフトを検出する」を参照してください。

Q: Model Monitor が有効になっていたモデルエンドポイントを削除したいのですが、モニタリングスケジュールがまだ有効なので削除できません。どうしたらよいですか?

Model Monitor が有効になっているでホスト SageMaker されている推論エンドポイントを削除する場合は、まずモデルモニタリングスケジュールを削除する必要があります ( DeleteMonitoringScheduleCLIまたはを使用API）。その後、エンドポイントを削除します。

Q: SageMaker Model Monitor は入力のメトリクスと統計を計算しますか？

Model Monitor は、入力ではなく出力のメトリクスと統計を計算できます。

Q: SageMaker Model Monitor はマルチモデルエンドポイントをサポートしていますか？

Model Monitor は現在、単一モデルをホストするエンドポイントのみをサポートしており、マルチモデルエンドポイントのモニタリングはサポートしていません。

Q: SageMaker Model Monitor は推論パイプライン内の個々のコンテナに関するモニタリングデータを提供しますか？

Model Monitor は、推論パイプラインのモニタリングをサポートしていますが、データのキャプチャと分析は、パイプライン内の個々のコンテナではなく、パイプライン全体に対して行われます。

Q: データキャプチャを設定したときに、推論リクエストに影響が出ないようにするにはどうしたらよいですか?

推論リクエストへの影響を防ぐため、ディスク使用率のレベルが高くなると、データキャプチャはリクエストのキャプチャを停止します。データキャプチャがリクエストのキャプチャを続行できるように、ディスク使用率を 75% 未満に抑えることをお勧めします。

Q: Amazon S3 データキャプチャは別のにあるか AWS region は、モニタリングスケジュールが設定されたリージョンよりも多いですか？

いいえ、Amazon S3 データキャプチャはモニタリングスケジュールと同じリージョンにある必要があります。

Q: ベースラインとはどういうものですか? また、ベースラインを作成する方法を教えてください。カスタムベースラインは作成できますか?

ベースラインは、モデルからのリアルタイム予測またはバッチ予測を比較するための基準として使用されます。統計とメトリクスを、それらに関する制約とともに計算します。モニタリング時には、これらすべてを組み合わせて使用し、違反を特定します。

Amazon SageMaker Model Monitor のデフォルトソリューションを使用するには、Amazon SageMaker Python SDKを活用できます。具体的には、 ModelMonitor または ModelQualityMonitor クラスの suggest_baseline メソッドを使用して、ベースラインのメトリクスと制約を計算する処理ジョブをトリガーします。

ベースラインジョブの結果として statistics.json と constraints.json の 2 つのファイルが生成されます。統計のスキーマと制約のスキーマにはそれぞれのファイルのスキーマが含まれます。生成された制約を確認し、変更してからモニタリングに使用することができます。ドメインとビジネス上の問題を理解したうえで、制約を強化することも、制約を緩和して違反の数や性質を制御することもできます。

Q: ベースラインデータセットを作成するためのガイドラインとはどのようなものですか?

どのようなモニタリングの場合でも、メトリクスと制約の計算に使用するベースラインデータセットを用意することが第一の要件です。通常、これはモデルが使用するトレーニングデータセットですが、場合によっては他の参照データセットを使用することもできます。

ベースラインデータセットの列名は Spark と互換性があります。Spark、、JSONおよび parquet との互換性を最大限に高めるにはCSV、小文字のみを使用し、区切り文字_としてのみを使用することをお勧めします。“ ” などの特殊文字を含むと問題を引き起こす可能性があります。

Q: StartTimeOffset パラメータと EndTimeOffset パラメータとはどういうものですか? また、どのような場合に使用されますか?

モデル品質などのジョブのモニタリングに Amazon SageMaker Ground Truth が必要な場合は、モニタリングジョブが Ground Truth が利用可能なデータのみを使用するようにする必要があります。の start_time_offsetおよび end_time_offsetパラメータEndpointInputを使用して、モニタリングジョブが使用するデータを選択できます。モニタリングジョブは、start_time_offset と end_time_offset で定義された時間枠内のデータを使用します。これらのパラメータは、ISO8601 期間形式で指定する必要があります。次に例をいくつか示します。

予測が行われてから 3 日後に Ground Truth の結果が届いた場合は、start_time_offset="-P3D" と end_time_offset="-P1D" (3 日と 1 日) を設定します。
Ground Truth の結果が予測から 6 時間後に到着し、1 時間ごとのスケジュールがある場合は、start_time_offset="-PT6H" と end_time_offset="-PT1H" (6 時間と 1 時間) を設定します。

Q: 「オンデマンド」のモニタリングジョブを実行できますか?

はい。 SageMaker 処理ジョブを実行することで、「オンデマンド」モニタリングジョブを実行できます。バッチ変換MonitorBatchTransformStepの場合、パイプラインには、オンデマンドでモニタリングジョブを実行する SageMaker パイプラインを作成するために使用できるがあります。 SageMaker サンプルリポジトリには、データ品質とモデル品質のモニタリングジョブをオンデマンドで実行するためのコードサンプルがあります。

Q: Model Monitor の設定方法を教えてください。

Model Monitor は次の方法で設定できます。

Amazon SageMaker Python SDK – Model Monitor モジュールには、ベースラインの提案、モニタリングスケジュールの作成などを支援するクラスと関数が含まれています。Model SageMaker Monitor の設定に Python を利用する詳細なノートブックについては、Amazon Model Monitor ノートブックの例を参照してください。 SageMaker SDK
パイプライン – パイプラインは、QualityCheck ステップおよびを通じて Model Monitor ClarifyCheckStep と統合されますAPIs。これらのステップを含み、 SageMaker パイプラインが実行されるたびにオンデマンドでモニタリングジョブを実行するために使用できるパイプラインを作成できます。
Amazon SageMaker Studio Classic – デプロイされたモデルエンドポイントのリストからエンドポイントを選択することで、モデルバイアスと説明可能性スケジュールとともに、データまたはモデル品質モニタリングスケジュールを UI から直接作成できます。UI の関連タブを選択することで、他のタイプのモニタリングのスケジュールを作成できます。
SageMaker Model Dashboard – エンドポイントにデプロイされたモデルを選択することで、エンドポイントのモニタリングを有効にできます。コンソールの次のスクリーンショットでは SageMaker 、モデルダッシュボードの「モデル」セクションからという名前のモデルが選択されgroup1ています。このページでは、モニタリングスケジュールの作成や、既存のモニタリングスケジュールやアラートの編集、有効化、無効化ができます。アラートとモデルモニタースケジュールの表示方法の手順については、「View Model Monitor schedules and alerts」を参照してください。

モニタリングスケジュールを作成するオプションが表示されている [モデルダッシュボード] のスクリーンショット。

Q: Model Monitor と SageMaker Model Dashboard の統合方法

SageMaker Model Dashboard は、予想される動作からの逸脱に関する自動アラートとトラブルシューティングを提供して、モデルを検査し、時間の経過とともにモデルのパフォーマンスに影響を与える要因を分析することで、すべてのモデルを一元的にモニタリングできます。

ブラウザで JavaScript が無効になっているか、使用できません。

AWS ドキュメントを使用するには、JavaScript を有効にする必要があります。手順については、使用するブラウザのヘルプページを参照してください。

ドキュメントの表記規則

AWS CloudFormation リアルタイムエンドポイントのカスタムリソース

モデルのバイアスを評価、説明、検出する