BigQuery ML: modelli con SQL dove vivono i dati

BigQuery ML permette di creare, addestrare e usare modelli di machine learning direttamente in BigQuery con istruzioni SQL (CREATE MODEL, ML.PREDICT, ML.EVALUATE), senza spostare i dati né gestire infrastruttura. È la scelta naturale quando il dataset è già nel data warehouse e il team parla SQL più che Python.

Copre i task più comuni: regression (lineare) per valori continui, classification (logistic regression per problemi binari/multiclasse, boosted trees, DNN) per predire categorie o probabilità, clustering (k-means) non supervisionato, matrix factorization per raccomandazioni e ARIMA_PLUS per il time-series forecasting con stagionalità. BigQuery ML può anche chiamare modelli remoti (CREATE MODEL ... REMOTE WITH CONNECTION), inclusi endpoint Vertex AI e modelli di linguaggio, applicando l’inferenza su intere tabelle con SQL. Valuti sempre le metriche con ML.EVALUATE e ispezioni i dati con ML.FEATURE_INFO: BigQuery ML gestisce automaticamente encoding e split train/eval, ma la qualità del feature engineering resta responsabilità tua.

Il punto di forza è la velocità di iterazione su dati tabellari a grande volume; il limite è il controllo fine su architetture custom, tuning avanzato e workflow MLOps completi.

Vertex AI: controllo completo su training, serving e pipeline

Vertex AI è la piattaforma gestita end-to-end per quando serve più flessibilità di quella offerta dall’SQL. Consente custom training con i tuoi container e framework (TensorFlow, PyTorch, scikit-learn), AutoML per costruire modelli su tabelle, immagini o testo senza scrivere codice del modello, e hyperparameter tuning gestito.

Sul fronte serving offre endpoint per online prediction a bassa latenza e batch prediction per volumi elevati, con scalabilità gestita. Le Vertex AI Pipelines orchestrano l’intero ciclo (preparazione dati, training, valutazione, deploy) in modo riproducibile e versionato, tipicamente integrandosi con gli altri servizi dati come Dataflow per il preprocessing.

Il Feature Store centralizza le feature calcolate: le rende riutilizzabili tra progetti, serve gli stessi valori sia in training sia in online serving e riduce il training-serving skew (la discrepanza tra come una feature è calcolata offline e online). È la risposta corretta quando lo scenario evidenzia feature condivise tra più modelli o team, o esigenze di point-in-time correctness.

API pre-addestrate: task comuni senza addestrare nulla

Per problemi standard non serve costruire un modello. Le API pre-addestrate espongono modelli già addestrati da Google via chiamata: Vision API (rilevamento oggetti, OCR, label, contenuti espliciti), Speech-to-Text e Text-to-Speech, Natural Language API (sentiment, entity, sintassi), Translation e Video Intelligence. Sono immediate, non richiedono dati di training né competenze ML, e si pagano a consumo. Le scegli quando il task rientra nelle loro capacità; passi ad AutoML o custom training solo se ti serve un modello specifico sul tuo dominio (es. classi personalizzate assenti dal modello generico).

BigQuery ML vs Vertex AI: come scegliere

Il criterio decisivo è competenze del team, dati e requisiti. Dati già in BigQuery, team SQL, task tabellare classico, iterazione rapida → BigQuery ML. Necessità di framework custom, tuning avanzato, pipeline MLOps riproducibili, feature condivise o serving a bassa latenza fuori dal warehouse → Vertex AI. Task comune coperto da un modello Google → API pre-addestrata. Non sono mutuamente esclusivi: puoi prototipare in BigQuery ML, registrare/servire il modello via Vertex AI ed esporre l’inferenza di nuovo in SQL con un remote model.

Trappole tipiche d’esame

  • Dati già in BigQuery, team SQL, servono predizioni rapide → BigQuery ML: distrattori come “esporta in Vertex AI e addestra un modello custom” aggiungono complessità inutile quando CREATE MODEL risolve in SQL.
  • Previsione di una serie storica con stagionalità → ARIMA_PLUS in BigQuery ML: non usare regressione lineare né un modello custom se il task è forecasting temporale univariato/multivariato.
  • Stesse feature riusate da più modelli / eliminare training-serving skew → Vertex AI Feature Store: ricalcolare le feature separatamente in training e serving è la risposta sbagliata.
  • OCR, sentiment o trascrizione audio → API pre-addestrata: addestrare un modello da zero è overkill quando Vision, Natural Language o Speech-to-Text coprono già il task.
  • Framework custom, tuning avanzato o pipeline MLOps riproducibili → Vertex AI (custom training + Pipelines): BigQuery ML non è la risposta quando servono controllo architetturale e orchestrazione.
  • Inferenza su un’intera tabella con un modello già su Vertex AI → remote model in BigQuery ML: non serve estrarre i dati; ML.PREDICT su un modello REMOTE applica l’endpoint in SQL.