Amazon MLA-C01: Monitoraggio del modello e osservabilità — Guida allo studio

By Laurynas Brazys · 3 August 2026 · #amazon #mla-c01 #certification #exam-prep #study-guide

Fa parte della AWS Machine Learning Engineer Associate MLA-C01 — Guida allo studio. Esercitati con risposte verificate nel centro esami Amazon, oppure fai test cronometrati su ExamRoll.io.

Concetti fondamentali: drift, baseline e osservabilità

Il monitoraggio dei modelli è la disciplina operativa che converte la telemetria grezza di runtime in segnali utilizzabili (actionable): data drift, concept drift, regressioni nella qualità del modello e stato di salute dell’infrastruttura. Per data drift si intende quando la distribuzione statistica delle feature di input in produzione diverge dalla distribuzione di baseline osservata durante l’addestramento; per concept drift si intende quando la relazione statistica tra input ed etichette (label) cambia, degradando la mappatura predittiva del modello. Un’osservabilità efficace richiede una baseline del comportamento atteso, una profilazione continua degli input e degli output di produzione, l’estrazione di metriche (sia incentrate sul modello come F1/ROC AUC, sia incentrate sui dati come la distanza KS, PSI, tassi di valori mancanti, cardinalità categorica) e un sistema affidabile di alerting e workflow che chiuda il cerchio verso la validazione o il riaddestramento.

Le baseline sono tipicamente generate da uno snapshot rappresentativo dei dati di addestramento (e validazione) utilizzando statistiche descrittive e file di vincoli (constraint). In AWS SageMaker, l’utility

undefined

o un Processing job possono calcolare le statistiche di baseline e un set iniziale di vincoli (es. min/max, valori categorici consentiti, percentili). L’output è un file di vincoli JSON e un file di statistiche archiviati in S3; questi artefatti diventano la baseline canonica a cui fanno riferimento i job di monitoraggio continui. Il monitoraggio confronta le statistiche per-batch con tali baseline e segnala le violazioni quando le soglie configurate vengono superate. Osservabilità significa anche catturare gli input del modello, gli output del modello, la latenza di inferenza e la metrica di business a valle (se disponibile) e correlare questi segnali per diagnosticare rapidamente (triage) un calo nelle metriche a livello di modello come F1.

Servizi chiave e configurazione

SageMaker Model Monitor fornisce la capacità gestita di pianificare processing job che calcolano e valutano statistiche rispetto alle baseline. Le API principali e gli oggetti di configurazione che utilizzerai includono

undefined

con i parametri

undefined

, dove

undefined

contiene uno

undefined

con una

undefined

in stile cron e un

undefined

che include

undefined

(

undefined

(percorsi di input S3 e

undefined

) e

undefined

. Gli artefatti di baseline sono referenziati tramite

undefined

. Per la derivazione automatica della baseline, si utilizza la chiamata

undefined

(SageMaker Python SDK), che esegue un

undefined

che scrive vincoli e statistiche su S3.

L’osservabilità e l’alerting sono implementati utilizzando le metriche e gli allarmi di CloudWatch e EventBridge per i workflow event-driven. Model Monitor pubblica i risultati dell’esecuzione che possono essere convertiti in metriche CloudWatch; per creare un allarme si utilizza l’API

undefined

con

undefined

. Collega gli allarmi ad azioni automatizzate specificando

undefined

che puntano a un topic SNS o a un target EventBridge. Le regole di EventBridge possono filtrare per la sorgente “aws.sagemaker” e utilizzare un pattern che corrisponde a fallimenti nell’esecuzione della pianificazione di monitoraggio di Model Monitor o a violazioni dei vincoli, per poi instradare verso una Lambda o direttamente a

undefined

per una SageMaker Pipeline.

Per il deployment controllato e le approvazioni manuali, il SageMaker Model Registry supporta gli oggetti

undefined

. Quando si chiama

undefined

è possibile impostare

undefined

su “PendingManualApproval”, e successivamente un utente autorizzato chiama

undefined

con

undefined

impostato su “Approved”. Le pipeline o i job di CI/CD che effettuano il deploy del modello promuoveranno solo le versioni del model package con

undefined

== “Approved”. Utilizza le policy IAM per controllare chi può chiamare

undefined

Uno stack di monitoraggio completo utilizza tipicamente la seguente combinazione di servizi:

Amazon SageMaker Model Monitor
Amazon SageMaker Pipelines and Model Registry
Amazon S3 (per baseline, ground truth e cattura delle inferenze)
Amazon CloudWatch (metriche, log,

undefined

)

Amazon EventBridge (regole di evento e routing)
AWS Lambda o Step Functions (target di automazione)
Amazon SNS (notifiche di allarme)
AWS Glue / Athena / QuickSight per esplorazione e visualizzazione ad-hoc

Pattern di progettazione e compromessi

Un pattern comune e robusto consiste nel separare il rilevamento a breve termine dalla remediation a lungo termine. Utilizzare una pianificazione di monitoraggio ad alta frequenza (ad esempio, oraria o giornaliera con CreateMonitoringSchedule e ScheduleExpression) per calcolare statistiche per ogni batch e rilevare rapidamente il drift. Inviare i risultati di ogni esecuzione a parametri personalizzati di CloudWatch utilizzando PutMetricData e creare allarmi CloudWatch Alarms con soglie conservative per azioni automatizzate a bassa confidenza (es. inviare notifiche) e soglie più rigorose per azioni automatizzate ad alta confidenza (es. avviare una pipeline di riaddestramento). Le regole di EventBridge collegano il rilevamento alla remediation mappando un evento di violazione di Model Monitor o una modifica dello stato di un CloudWatch Alarm a una funzione Lambda che si autentica e chiama StartPipelineExecution per una SageMaker Pipeline o invoca un processo di riaddestramento tramite CreateTrainingJob.

Quando si decide se riaddestrare automaticamente o richiedere un’approvazione manuale, bisogna valutare il rischio aziendale e la conformità. Il riaddestramento automatico è adatto per modelli a basso rischio con passaggi di validazione automatizzata affidabili nella pipeline (validazione dei dati, valutazione del modello su dati di holdout, test di rollback). Per modelli regolamentati o ad alto impatto, utilizzare il pattern di approvazione manuale di Model Registry: caricare un ModelPackage candidato con ModelApprovalStatus “PendingManualApproval”, avviare un flusso di revisione umana (es. un ticket in una dashboard MLOps o una Lambda di approvazione che aggiorna il ModelPackage tramite UpdateModelPackage) e solo allora consentire il deployment sugli endpoint di produzione.

La frequenza di monitoraggio e la dimensione dei dati di inferenza acquisiti introducono compromessi tra costo e sensibilità. Finestre di batch più piccole aumentano la sensibilità al rumore transitorio e incrementano i costi di elaborazione, mentre finestre più grandi riducono i costi ma possono ritardare il rilevamento di un drift rapido. Allo stesso modo, l’acquisizione di payload di inferenza completi può essere costosa e sollevare problemi di data governance; considerare il campionamento o la memorizzazione solo di feature aggregate e output del modello, a meno che non siano necessarie riesecuzioni complete per l’analisi delle cause profonde (root cause analysis).

Per i trigger di riaddestramento, preferire un’automazione guidata dagli eventi (event-driven) che codifichi la logica di business nella pipeline: l’attivazione di un CloudWatch Alarm innesca una regola di EventBridge che passa un payload minimo (URI S3 per i dati acquisiti e i file di differenze dei vincoli) a StartPipelineExecution con PipelineParameters come “TrainingDataS3Uri”, “BaselineConstraintsS3Uri” e “RetrainTriggerReason”. Questo mantiene il trigger deterministico e verificabile (auditable).

Errori comuni e criteri decisionali

Un errore frequente è considerare la deriva statistica come qualcosa che richieda necessariamente un’azione. Non tutte le derive influenzano le prestazioni del modello. È necessario correlare le variazioni nella distribuzione delle feature con le metriche di qualità del modello (F1, precision-recall, calibrazione) prima di avviare un costoso riaddestramento. Un altro errore è non proteggere i dati di inferenza acquisiti; si consiglia di scegliere la crittografia at-rest (S3 SSE-KMS), le policy dei bucket S3 e gli endpoint VPC per mantenere isolati i dati di produzione. Quando si configurano i job di monitoraggio, assicurarsi che l’IAM RoleArn abbia accesso con il minimo privilegio: lettura dei prefissi S3 di cattura dell’inferenza, scrittura sul prefisso S3 di output del monitoraggio e autorizzazione a creare log di CloudWatch se si emettono log.

Nel selezionare la cadenza di riaddestramento e la complessità della pipeline, basare le decisioni sui rapporti segnale/rumore osservati. Se Model Monitor mostra frequenti violazioni transitorie, implementare uno smoothing o richiedere più esecuzioni consecutive in violazione prima di attivare le pipeline. Per i flussi di lavoro con approvazione manuale, imporre l’uso di UpdateModelPackage(ModelApprovalStatus="Approved") tramite un set di permessi IAM ristretto e registrare l’identità dell’approvatore nei metadati di esecuzione della pipeline per scopi di conformità.

Problema Pratico: Scenario d’Uso

Azienda: FinSecure Analytics; sfida: un modello XGBoost di rilevamento frodi in produzione mostra picchi intermittenti di falsi positivi e un calo costante del punteggio F1 nel corso dei mesi; i dati provengono da log di transazioni su S3 e da un mirror on-premise di profili cliente su MySQL; il modello deve essere sottoposto ad audit e riaddestrato con approvazioni umane.

Monitoraggio automatizzato e baseline: eseguire DefaultModelMonitor.suggest_baseline su uno snapshot rappresentativo dei dati di addestramento per produrre statistiche e vincoli di baseline archiviati in S3 (prefisso S3 della baseline). Creare un CreateMonitoringSchedule con una MonitoringScheduleConfig che specifichi una ScheduleExpression per esecuzioni orarie, un RoleArn con permessi di lettura/scrittura su S3, una MonitoringAppSpecification.ImageUri che punti al container di Model Monitor, una MonitoringResources.ClusterConfig con InstanceType ml.m5.large e InstanceCount 1, MonitoringInputs che puntino ai prefissi S3 di cattura dell’inferenza e una MonitoringOutputConfig.S3OutputPath per catturare gli output delle esecuzioni.
Allarmi e triage: pubblicare i conteggi delle violazioni per ogni esecuzione su CloudWatch usando PutMetricData sotto un Namespace personalizzato e creare un PutMetricAlarm con un AlarmName che imposti una soglia su NumberOfViolations > X per tre periodi consecutivi. Configurare AlarmActions verso un topic SNS e una regola EventBridge che filtri per source "aws.sagemaker" e detail-type "SageMaker Model Monitor" per includere i metadati della violazione.
Pipeline di correzione con approvazione manuale: implementare una SageMaker Pipeline che esegua l’ingestion dei dati (un job Glue per centralizzare i dati da S3 e dal mirror MySQL in un dataset di addestramento), l’ingegneria delle feature automatizzata, l’addestramento tramite CreateTrainingJob usando il container XGBoost, uno step di valutazione che produca report sul punteggio F1 e sul bias, e la registrazione nel Model Registry tramite CreateModelPackage con ModelApprovalStatus="PendingManualApproval". La pipeline scrive le metriche di valutazione su CloudWatch e nei metadati del ModelPackage.
Intervento umano (human-in-the-loop) e applicazione delle policy: usare una regola EventBridge attivata dall’allarme di CloudWatch per notificare il team di data science tramite SNS; l’approvatore esamina gli artefatti di valutazione accessibili in S3/QuickSight e poi chiama UpdateModelPackage con ModelApprovalStatus="Approved". Lo step di CICD/deployment controlla il ModelApprovalStatus prima di invocare CreateModel (o l’aggiornamento dell’endpoint SageMaker). Per il riaddestramento automatico, nei casi in cui le metriche scendono al di sotto di soglie automatizzate e il business accetta il riaddestramento automatico, collegare una funzione Lambda come target alla regola di EventBridge che chiama StartPipelineExecution con i PipelineParameters TrainingDataS3Uri e RetrainTriggerReason, abilitando un percorso completamente automatizzato, protetto da soglie più restrittive.

Motivazione AWS: SageMaker Model Monitor centralizza il rilevamento della deriva e il confronto con la baseline con un lavoro operativo minimo; CloudWatch ed EventBridge forniscono un sistema robusto di allarmi e di instradamento verso SNS/Lambda; SageMaker Pipelines automatizza il riaddestramento e la validazione del modello; ModelApprovalStatus del Model Registry impone un gate di approvazione manuale per i deployment in produzione, e S3/Glue/Athena forniscono un’aggregazione centralizzata e sicura dei dati per l’addestramento e la visualizzazione. Insieme, questi servizi consentono di avere baseline riproducibili, approvazioni verificabili e un riaddestramento automatizzato configurabile, con una netta separazione tra il rilevamento e la correzione.

← MLOps e gestione del ciclo di vita del modello · Tutti i domini · Sicurezza →

Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →