Perché BigQuery ML per un data practitioner

BigQuery ML porta il machine learning dentro il data warehouse: crei e usi modelli scrivendo SQL, senza esportare i dati né gestire infrastruttura separata. Per un data practitioner il valore è nella semplicità operativa — i dati restano in BigQuery e il modello si addestra dove vivono le tabelle, riducendo movimenti di dati e costi di integrazione.

Il primo passo dell’esame è riconoscere lo use case ML. Devi capire se un problema è di regressione (prevedere un valore numerico, es. fatturato), di classificazione (prevedere una categoria, es. churn sì/no), di clustering (segmentare clienti con K-means) o di forecasting su serie temporali. Se invece il problema si risolve con una query aggregata o una regola deterministica, non serve ML: l’esame ama proporre scenari dove la risposta corretta è “non usare un modello”.

BigQuery ML in SQL vs AutoML

La scelta chiave è tra scrivere il modello a mano e delegarlo ad AutoML. Con BigQuery ML in SQL usi CREATE MODEL specificando il tipo (per esempio linear_reg o logistic_reg): hai controllo, tempi rapidi e costi contenuti, ideale quando conosci le feature e vuoi un modello interpretabile. AutoML Tables, invocabile come opzione di training da BigQuery ML, esplora automaticamente algoritmi e feature engineering: lo scegli quando vuoi massimizzare la qualità predittiva su dati tabellari complessi senza tuning manuale, accettando training più lungo e costi maggiori.

Il flusso di un progetto ML standard resta lo stesso a prescindere dal tipo: raccolta e preparazione dati in BigQuery, split in training e set di valutazione, training del modello, valutazione delle metriche, infine prediction sui nuovi dati. Saltare la fase di valutazione prima di andare in prediction è un errore classico.

Creare, valutare e usare i modelli

Il ciclo pratico in SQL ruota attorno a poche funzioni. CREATE MODEL addestra e registra il modello a partire da una query di training. ML.EVALUATE restituisce le metriche di qualità (per la classificazione, tipicamente precision, recall e AUC; per la regressione, errori come RMSE) su dati che il modello non ha visto in training: è il passaggio che ti dice se il modello è utilizzabile. ML.PREDICT applica il modello a nuove righe per generare le previsioni.

Il vantaggio è che valutazione e inference sono normali query SQL: puoi filtrare, aggregare e unire i risultati della prediction con altre tabelle senza pipeline esterne.

LLM pre-addestrati e Model Registry

BigQuery ML non serve solo modelli addestrati da te. Puoi invocare LLM pre-addestrati di Google (famiglia Gemini) direttamente da SQL tramite una remote connection: crei una connessione a Vertex AI, definisci un modello remoto in BigQuery e poi generi testo, riassunti o classificazioni sulle tue tabelle. È l’opzione giusta quando l’esigenza è NLP generativa su dati già in BigQuery, senza costruire un modello da zero.

Il Model Registry (in Vertex AI) è dove i modelli vengono organizzati, versionati e governati centralmente. Puoi registrare un modello BigQuery ML nel Model Registry per gestirne le versioni, condividerlo e prepararlo al deployment come endpoint. Concettualmente separa il “dove alleni” (BigQuery) dal “dove governi e servi” (Vertex AI Model Registry).

Trappole tipiche d’esame

  • Serve OLTP o lookup a bassa latenza per riga → soluzione: non è ML e non è BigQuery. BigQuery è un data warehouse analitico serverless; per accessi transazionali usa Cloud SQL o Bigtable, non un modello.
  • Massima qualità predittiva senza tuning manuale → soluzione: AutoML; modello controllato, veloce e interpretabile con feature note → BigQuery ML in SQL con CREATE MODEL.
  • Generare testo/riassunti con un LLM Gemini in BigQuery → soluzione: modello remoto via remote connection a Vertex AI, non CREATE MODEL locale.
  • “Andiamo subito in prediction” → soluzione: prima ML.EVALUATE su dati non visti; senza valutazione non sai se il modello regge.
  • Versionare e governare i modelli centralmente → soluzione: Model Registry in Vertex AI, non tabelle o dataset improvvisati in BigQuery.
  • Prevedere una categoria vs un numero → soluzione: classificazione (logistic_reg) per la categoria, regressione (linear_reg) per il valore numerico; scambiarle è un tranello frequente.