Orchestrare pipeline ML: quale servizio scegliere

Una pipeline ML end-to-end incapsula i passi ripetibili (ingestion, validazione dati, preprocessing, training, valutazione, deploy) in un grafo versionato e tracciabile. Su Google Cloud il default ML-native e’ Vertex AI Pipelines: orchestrazione serverless, pagamento per esecuzione, lineage automatico degli artifact in Vertex ML Metadata. Le pipeline si definiscono con il Kubeflow Pipelines (KFP) SDK o con TFX; scegli TFX quando ti servono componenti standard per validazione dati e feature engineering coerente.

I criteri di scelta tra orchestratori sono un classico d’esame:

  • Vertex AI Pipelines — workflow ML gestiti, nessuna gestione di cluster, metadata e lineage integrati. Scelta di default per l’MLOps su GCP.
  • Kubeflow su GKE — quando servono controllo completo dell’infrastruttura, un cluster GKE gia’ esistente o scenari ibridi/multicloud. Paghi la complessita’ operativa del cluster.
  • Cloud Composer / Managed Service for Apache Airflow — orchestrazione general-purpose a DAG, ideale quando devi coordinare data engineering e sistemi eterogenei oltre all’ML, o se hai gia’ un investimento in Airflow.
  • Ray su Vertex AI — calcolo distribuito per training e hyperparameter tuning che devono scalare (data parallelism su piu’ nodi), non un orchestratore di workflow ma un motore di esecuzione distribuita.

Preprocessing coerente e training-serving skew

Il training-serving skew e’ la divergenza tra le prestazioni in training e in produzione causata, tipicamente, da logiche di preprocessing diverse nei due percorsi. Va distinto da data drift (la distribuzione degli input cambia nel tempo) e da concept drift (cambia la relazione tra feature e target). Per evitare lo skew occorre condividere la stessa logica di trasformazione tra training e serving: usa TFX Transform per generare un grafo di trasformazione riutilizzabile, oppure il Vertex AI Feature Store per servire online, a bassa latenza, esattamente gli stessi valori di feature calcolati in batch. Vertex AI Model Monitoring rileva sia lo skew (confronto tra input di serving e baseline di training) sia il drift (confronto tra serving recente e storico).

Retraining policy: schedulato, a soglia, guidato dal drift

La retraining policy definisce quando riaddestrare. Le tre strategie con i relativi trade-off:

  • Schedulato — riaddestri a cadenza fissa (es. settimanale). Semplice, prevedibile, ma rischia di riaddestrare inutilmente o troppo tardi.
  • A soglia (performance-based) — riaddestri quando una metrica monitorata scende sotto una soglia. Efficiente ma richiede ground-truth labels tempestive per misurare la performance reale.
  • Guidato dal drift — Model Monitoring rileva skew o drift ed emette un alert che avvia la pipeline di retraining. Ottimo quando il drift e’ imprevedibile: eviti costi di training inutili, ma serve l’infrastruttura di monitoring.

CI/CD/CT con Cloud Build

L’MLOps maturo estende CI/CD con la CT (continuous training). Cloud Build orchestra le tre fasi: la CI testa il codice, valida i componenti della pipeline e builda le container image; la CD rilascia la pipeline e fa il deploy del modello su un Vertex AI endpoint con traffic split per canary o A/B; la CT riaddestra e ridistribuisce automaticamente al verificarsi di un trigger. Un trigger su commit (GitHub o Cloud Source Repositories) avvia la build, esegue la pipeline e applica un model validation gate: il nuovo modello viene promosso solo se supera il modello in produzione o una soglia minima. Le versioni approvate vengono registrate nel Vertex AI Model Registry.

Trappole tipiche d’esame

  • Workflow ML gestito senza gestire cluster → Vertex AI Pipelines: se lo scenario chiede orchestrazione ML con lineage e minimo overhead operativo, scegli Vertex AI Pipelines, non Kubeflow su GKE (che implica gestire il cluster).
  • Serve orchestrare anche data engineering eterogeneo → Cloud Composer / Managed Airflow: quando il DAG coordina sistemi non-ML oltre al training, Composer batte Vertex AI Pipelines.
  • Predizioni buone in test ma degradate subito in produzione → training-serving skew: e’ un problema di preprocessing incoerente (usa Feature Store / TFX Transform), non data drift, che invece si manifesta gradualmente nel tempo.
  • Riaddestrare solo quando serve minimizzando i costi → retraining guidato dal drift: un alert di Model Monitoring che innesca la pipeline batte lo scheduling fisso; lo schedulato riaddestra anche senza necessita’.
  • Non promuovere modelli peggiori → model validation gate in Cloud Build: la pipeline deve confrontare il candidato col modello in produzione prima del deploy, non pubblicare automaticamente ogni run.
  • Scalare un training distribuito di grandi dimensioni → Ray su Vertex AI (o data parallelism): Ray e’ motore di calcolo distribuito, non un orchestratore; non confonderlo con Vertex AI Pipelines.