Il comportamento di un sistema di machine learning non dipende solo dalle regole scritte nel codice: dipende anche dai dati da cui è stato appreso. Per questo un modello in produzione si degrada senza che nessuno abbia toccato una riga — cambiano le distribuzioni in ingresso, cambia il comportamento degli utenti, si apre uno scarto fra i dati di addestramento e quelli di servizio. Il monitoraggio decide se il riaddestramento parte per tempo o dopo il danno.

Senza raccolta dei dati di produzione non c è monitoraggio

Il monitoraggio di Azure Machine Learning confronta statisticamente i dati di inferenza di produzione con dei dati di riferimento, quindi il primo passo è procurarsi i primi. Su un deployment verso un endpoint online si abilita il data collector, che registra in tempo reale input e output del modello e li salva su Azure Blob Storage: si dichiara nello scoring script con l oggetto collector e si configura nel YAML del deployment, con la possibilità di impostare una frequenza di campionamento invece di raccogliere tutto.

La conseguenza da ricordare è simmetrica: se il modello è distribuito fuori da Azure Machine Learning oppure su un batch endpoint, la raccolta dei dati di produzione è responsabilità di chi progetta la soluzione, e il monitor va puntato su quei dati.

I segnali e le metriche che li misurano

I segnali predefiniti lavorano su dati tabulari. Il data drift confronta la distribuzione degli input con quella dei dati di riferimento usando distanza di Jensen-Shannon, Population Stability Index, distanza di Wasserstein normalizzata, test di Kolmogorov-Smirnov a due campioni e chi quadro di Pearson. Il prediction drift applica una logica analoga agli output del modello, con in più la distanza di Chebyshev. La data quality non guarda le distribuzioni ma l integrità dell input, con tre metriche: null value rate, data type error rate e out-of-bounds rate, quest ultimo calcolato sull intervallo o sull insieme di valori dedotto dai dati di riferimento. Il feature attribution drift, in anteprima, confronta l importanza delle feature in produzione con quella in addestramento usando il normalized discounted cumulative gain, e richiede obbligatoriamente i dati di training come riferimento. Il segnale di model performance, anch esso in anteprima, misura accuracy, precision e recall per la classificazione e MAE, MSE e RMSE per la regressione, ma richiede la ground truth. Per le applicazioni generative esiste un segnale di generation safety and quality, in anteprima.

La scelta dei dati di riferimento è materia d esame: per data drift e data quality la baseline consigliata è il dataset di addestramento, per il prediction drift quello di validazione, in alternativa dati di produzione recenti. Le finestre si esprimono in formato ISO 8601 con una dimensione e uno scostamento: per default quella di produzione coincide con la frequenza del monitor e ha scostamento zero, quella di riferimento parte dall intero dataset. La regola pratica è che le due non si sovrappongano. Con i dati di addestramento come riferimento si possono monitorare solo le prime N feature per importanza, riducendo costo di calcolo e rumore.

Degrado del modello e degrado del servizio non sono la stessa cosa

Una latenza che sale non è drift, e un drift non produce codici di errore: le due famiglie di metriche vivono in posti diversi. Le metriche operative degli endpoint online stanno in Azure Monitor — a livello di endpoint latenza delle richieste, richieste al minuto, byte di rete e codici di risposta; a livello di deployment utilizzo di CPU, GPU, memoria e disco. I log finiscono in Log Analytics nelle tabelle del traffico, della console del container e degli eventi, e su quelle metriche si costruiscono gli alert di disponibilità.

Il segnale di model performance sarebbe la misura più onesta della qualità, ma dipende dalla ground truth, che quasi sempre arriva con giorni o settimane di ritardo. Per questo data drift e feature attribution drift si usano come allarme precoce: dicono che qualcosa è cambiato prima che si possa dimostrare che il modello sbaglia.

Soglie, alert e ciò che scatta

Un monitor si crea come schedule con CLI v2, SDK v2 o studio, e gira su un pool Spark serverless. La configurazione minima, detta out-of-box, si aggancia a un deployment online con data collection attiva, usa i dati di produzione recenti come riferimento, include data drift, prediction drift e data quality con soglie predefinite e manda una email a chi ha creato il monitor quando una soglia viene superata. Quella avanzata dichiara esplicitamente segnali, riferimenti e soglie.

trigger:
  type: recurrence
  frequency: day
  interval: 1
create_monitor:
  compute:
    instance_type: standard_e4s_v3
    runtime_version: "3.4"
  monitoring_target:
    ml_task: classification
    endpoint_deployment_id: azureml:credit-default:main
  alert_notification:
    emails:
      - mlops@contoso.com
az ml schedule create -f ./monitoring.yaml

Il riaddestramento automatico si costruisce sopra gli eventi: le esecuzioni del monitor pubblicano eventi su Azure Event Grid, e da lì si innesca una pipeline di retraining o un workflow di GitHub Actions. Le soglie però vanno decise prima, insieme a chi conosce il modello: troppo strette producono affaticamento da alert e vengono ignorate, troppo larghe rendono il monitor decorativo. Due limiti dichiarati da ricordare: il monitoraggio non supporta l isolamento di rete gestito in modalità solo uscita approvata, e conviene evitare i file MLTable complessi perché il calcolo si appoggia a Spark.

Da ricordare per l esame

  • Il monitoraggio richiede dati di inferenza di produzione: sugli endpoint online li fornisce il data collector, altrove la raccolta è a carico tuo.
  • Data drift guarda gli input, prediction drift gli output, data quality l integrità (null value rate, data type error rate, out-of-bounds rate).
  • Feature attribution drift e model performance sono in anteprima; il secondo richiede la ground truth, motivo per cui il drift funziona da allarme precoce.
  • Baseline consigliate: dati di addestramento per data drift e data quality, dati di validazione per il prediction drift; le finestre di riferimento e di produzione non devono sovrapporsi.
  • Il monitor gira su Spark serverless a ricorrenza, notifica via email al superamento delle soglie e pubblica eventi su Event Grid per innescare il riaddestramento.