Dal prototipo alla scala: inquadrare il problema

Prima di scegliere un prodotto, l’esame vuole che tu classifichi il problema e i suoi vincoli: tipo di dato, volume, latenza richiesta in inferenza, budget e competenze del team. Il tipo di modello segue il problema. Per le serie temporali (domanda, traffico, vendite) il riferimento è ARIMA, disponibile in BigQuery ML come ARIMA_PLUS con gestione automatica di stagionalità e festività. Per dati tabellari con relazioni non lineari, boosted trees o DNN offrono più accuratezza. Per testo, immagini o task generativi si passa a LLM e modelli foundation (Model Garden: Gemini, Imagen, modelli open). Regola generale: non introdurre una DNN o un LLM dove un modello più semplice soddisfa già il requisito — paghi complessità, costo e tempo di training e minore interpretabilità senza guadagno reale.

Scegliere il prodotto: AutoML, BigQuery ML o custom

Il trade-off centrale è controllo contro velocità di consegna.

  • BigQuery ML quando i dati sono già in BigQuery e il team ragiona in SQL: modelli con CREATE MODEL, valutazione con ML.EVALUATE, inferenza con ML.PREDICT. Ideale per prototipare rapidamente regressione/classificazione, ARIMA_PLUS e boosted trees senza spostare dati né gestire infrastruttura.
  • Vertex AI AutoML per training no-code su tabellari, immagini, testo: massimizza l’accuratezza con minimo feature engineering, a costo di minore controllo su architettura e iperparametri.
  • Vertex AI custom training quando servono framework, architetture o training loop specifici: porti il tuo codice in container, scegli gli acceleratori (TPU per grandi training deep learning, GPU general-purpose, CPU per carichi piccoli) e scali con data parallelism (stessi pesi, dati diversi) o model parallelism (modello troppo grande spezzato tra device).

Per orchestrare l’intero flusso in modo ripetibile e automatizzabile (CT) si usano Vertex AI Pipelines (KFP/TFX), con Model Registry per il versioning e Feature Store per il serving online delle feature a bassa latenza. Per gli LLM, valuta il trade-off tra prompt engineering, RAG (conoscenza aggiornata senza riaddestrare) e fine-tuning (adattamento profondo, più costoso).

Deployment: batch vs online, A/B e canary

La strategia di serving nasce dal requisito di latenza. L’inferenza batch è adatta a predizioni programmate su grandi volumi; l’inferenza online su Vertex AI Prediction endpoint serve richieste in tempo reale con autoscaling. Per rilasciare nuove versioni riducendo il rischio: traffic split per A/B testing (confronto misurato tra versioni su quote di traffico) e canary (esposizione graduale a una piccola quota prima del rollout completo). Dopo il deploy, Vertex AI Model Monitoring rileva training-serving skew e data/concept drift, segnalando quando riaddestrare.

Accuratezza contro interpretabilità

Quando servono spiegazioni — settori regolati, decisioni contestabili — i modelli lineari e gli alberi sono intrinsecamente più interpretabili delle deep network. Se però l’accuratezza richiede modelli complessi, non rinunci alla trasparenza: Vertex Explainable AI fornisce feature attributions (quanto ogni feature contribuisce alla singola predizione), integrabile sia con AutoML sia con custom models. È il modo tipico con cui l’esame concilia “serve accuratezza” e “serve spiegabilità”.

Trappole tipiche d’esame

  • Serie temporale con stagionalità, dati già in BigQuery → BigQuery ML ARIMA_PLUS: non serve custom training né una DNN; risolvi in SQL con gestione automatica di stagionalità e festività.
  • Poco tempo/skill ML ma serve buona accuratezza su tabellari → Vertex AI AutoML: scegliere custom training in questo scenario aggiunge complessità inutile.
  • Serve architettura o framework specifico / controllo del training loop → Vertex AI custom training: AutoML e BigQuery ML non offrono quel livello di controllo.
  • Modello accurato ma “black box” in un contesto regolato → Vertex Explainable AI (feature attributions): la risposta non è ripiegare per forza su un modello lineare se le attributions bastano a soddisfare la spiegabilità.
  • Rilascio a rischio ridotto di una nuova versione → traffic split/canary su Vertex AI Prediction: distingui canary (rollout graduale) da A/B (confronto misurato tra due versioni).
  • Degrado delle predizioni in produzione → Vertex AI Model Monitoring: distingui training-serving skew (mismatch train vs serving) da data/concept drift (distribuzione che cambia nel tempo).