Perché il monitoraggio è parte del ciclo ML

Un modello messo in produzione non è statico: il mondo che genera i dati cambia, e con esso le distribuzioni in ingresso. L’esame distingue due fenomeni. Il data drift (covariate shift) è la deriva della distribuzione delle feature in input rispetto al dataset di training. Il model quality drift è invece il degrado delle prestazioni predittive reali del modello. Concetto chiave da ricordare: un endpoint può avere input apparentemente stabili e comunque perdere accuratezza, e misurare la qualità richiede sempre le etichette reali (ground truth). Per questo Data Quality e Model Quality si monitorano con meccanismi diversi.

SageMaker Model Monitor e baselining

Amazon SageMaker Model Monitor offre quattro tipi di monitoring: Data Quality, Model Quality, Model Bias Drift e Feature Attribution Drift. Funziona con processing job schedulati (tipicamente orari o giornalieri) che confrontano i dati live con una baseline.

Il baselining è il primo passo: si esegue un baseline job (suggest baseline) su un dataset di riferimento, di norma quello di training, per generare statistics.json (statistiche delle feature) e constraints.json (vincoli attesi). I job di monitoring successivi confrontano i dati catturati con questa baseline ed emettono un report di violazioni quando i valori escono dai vincoli.

Il Model Quality monitoring richiede le etichette reali: si caricano i ground truth label su S3, Model Monitor li unisce (merge job) alle predizioni catturate e calcola le metriche appropriate al tipo di problema — RMSE per la regressione, accuracy/F1/precision/recall per la classificazione (con F1 e recall preferibili su classi sbilanciate). Poiché le label arrivano con ritardo, il model quality drift si osserva sempre con latenza rispetto al data quality drift.

Data capture sull’endpoint

La data capture è il prerequisito di quasi tutti i monitor su endpoint real-time. Si abilita tramite DataCaptureConfig sull’endpoint, specificando la percentuale di sampling e il bucket S3 di destinazione: SageMaker vi scrive richieste e risposte di inferenza (in JSONL). Senza data capture attiva, Model Monitor non ha dati live da confrontare con la baseline. La cattura si configura sugli endpoint di inferenza (real-time e async); la batch transform ha un flusso di monitoring separato basato sui file di output, non sulla cattura live.

Metriche endpoint e integrazione CloudWatch

SageMaker pubblica automaticamente metriche di endpoint su Amazon CloudWatch: ModelLatency (tempo speso dentro il container del modello), OverheadLatency (overhead aggiunto da SageMaker), Invocations, InvocationsPerInstance, Invocation4XXErrors e Invocation5XXErrors, oltre alle metriche di risorsa dell’istanza (CPUUtilization, MemoryUtilization). Su queste si creano CloudWatch alarm per la salute operativa: SLA di latenza, tasso di errore, saturazione delle istanze (utile anche come segnale per l’auto scaling). Anche Model Monitor emette proprie metriche e violazioni verso CloudWatch, così è possibile allarmare direttamente sul drift.

Retraining automatico con EventBridge

Il loop MLOps si chiude collegando la rilevazione del drift al retraining. Il pattern tipico: una violazione di Model Monitor o un CloudWatch alarm genera un evento che una regola di Amazon EventBridge intercetta per avviare una SageMaker Pipeline di retraining (eventualmente orchestrata via Step Functions o innescata da una Lambda). EventBridge è il bus eventi che disaccoppia la rilevazione dall’azione; evita di legare rigidamente l’allarme al pipeline e permette di reagire anche ad altri eventi (nuovi dati, schedulazioni).

Trappole tipiche d’esame

  • Monitorare la qualità del modello senza ground truth → non è possibile: il Model Quality monitoring richiede le label reali caricate su S3; il Data Quality drift invece si rileva senza etichette, solo dalle statistiche degli input.
  • Endpoint senza data capture → Model Monitor non ha nulla da analizzare: abilitare DataCaptureConfig prima di attivare qualunque scheduling di monitoring.
  • Confondere ModelLatency e OverheadLatency: la prima è il tempo dentro il container del modello, la seconda è l’overhead aggiunto da SageMaker; per problemi di performance del modello si guarda ModelLatency.
  • Trigger di retraining cablato “a mano” → usare EventBridge: è il servizio corretto per instradare violazioni/alarm verso una SageMaker Pipeline, non uno script custom o un cron generico.
  • Metrica sbagliata per il tipo di problema: RMSE per regressione, F1/recall per classificazione sbilanciata; scegliere accuracy su dati sbilanciati è la risposta-trappola.
  • Batch transform trattato come real-time: la data capture e il monitoring su endpoint valgono per l’inferenza online; per la batch transform il monitoring si basa sui file di output, con un flusso dedicato.