Quando scegliere BigQuery ML

BigQuery ML permette di costruire e servire modelli direttamente in SQL (CREATE MODEL, ML.PREDICT, ML.EVALUATE), senza spostare i dati fuori dal warehouse. È la scelta giusta quando i dati sono già in BigQuery, il team padroneggia SQL più di Python e serve un time-to-value rapido. Copre classificazione e regressione (logistic/linear regression, boosted trees, DNN, Wide & Deep), forecasting delle serie temporali (ARIMA_PLUS), clustering (k-means), matrix factorization per i recommender e persino l’import di modelli TensorFlow o la chiamata a modelli remoti Vertex AI.

Il feature engineering vive dentro la pipeline SQL: TRANSFORM incapsula le trasformazioni nel modello così che le stesse preprocessing siano applicate automaticamente in fase di prediction, prevenendo training-serving skew. Le prediction sono batch (una query su una tabella) o accessibili via ML.PREDICT; per l’inferenza online a bassa latenza su singolo record BigQuery ML non è la scelta ideale. Il trade-off chiave: BigQuery ML massimizza velocità e semplicità, ma offre meno controllo di un custom training e non è adatto a deep learning su immagini o testo non strutturato su larga scala.

Vertex AI AutoML e la scelta del modello

Vertex AI AutoML è training no-code per dati tabulari, immagini, testo e video: si fornisce il dataset etichettato e la piattaforma gestisce architecture search e hyperparameter tuning. Va preferito a BigQuery ML quando il problema riguarda dati non strutturati (image classification, object detection, entity extraction) o quando si vuole massima accuratezza senza scrivere codice, accettando tempi di training e costi maggiori. Se invece serve controllo totale su architettura, loss e librerie, la strada è il custom training. Regola pratica d’esame: dati tabulari già in BigQuery + SQL team → BigQuery ML; dati non strutturati + no-code → AutoML; requisiti custom o framework specifici → custom training.

Per i foundation model, Vertex AI Model Garden è il catalogo da cui selezionare Gemini, Imagen, Veo e modelli open (es. famiglia Gemma, modelli di terze parti). La selezione parte dalla modalità (testo, immagine, video), dal trade-off costo/latenza/qualità e dalla necessità o meno di deployment gestito su endpoint.

API AI verticali e foundation model

Prima di addestrare qualsiasi cosa, valuta le pretrained API: Document AI per estrazione strutturata da documenti (fatture, moduli, contratti), Vision API per OCR e classificazione immagini generica, Translation API per la traduzione. Sono la scelta corretta quando il problema è comune e non serve un modello su misura: costo prevedibile, zero training, integrazione immediata. Si passa ad AutoML o custom solo se le API generiche non raggiungono l’accuratezza richiesta sul dominio specifico.

Per adattare i foundation model l’ordine di complessità crescente è: prompt engineering (più economico e veloce), RAG (grounding su dati aziendali freschi senza ri-addestrare, ideale contro le hallucination e per conoscenza che cambia), infine fine-tuning/tuning di Gemini o Imagen (quando servono stile, formato o comportamento specifici non ottenibili col prompt). Per ottimizzare le applicazioni Gemini in produzione si lavora su tre assi: costo (scegliere il modello più piccolo che soddisfa la qualità, context caching per prompt ripetuti, output più brevi), latenza (modello Flash vs Pro, streaming della risposta, batch prediction per carichi offline) e disponibilità (provisioned throughput per capacità garantita, gestione dei quota e retry). Model Armor protegge prompt e response da prompt injection e contenuti dannosi.

Trappole tipiche d’esame

  • Dati tabulari già in BigQuery + time-to-value rapido → BigQuery ML: la distrazione è “usa AutoML per la massima accuratezza”; se i dati sono nel warehouse e il team usa SQL, spostarli su AutoML aggiunge costo e complessità inutili.
  • Estrazione campi da fatture/documenti → Document AI: l’esame propone di addestrare un custom model o usare Vision API generica; Document AI è già specializzato sui documenti e va scelto prima di qualsiasi training.
  • Conoscenza aziendale che cambia spesso + evitare hallucination → RAG, non fine-tuning: il fine-tuning non aggiorna i fatti e va ri-eseguito a ogni cambiamento; il grounding via RAG è più economico e sempre fresco.
  • Latenza troppo alta o costo eccessivo su app Gemini → modello più piccolo (Flash) + context caching: la trappola è “aumenta le risorse dell’endpoint”; con i foundation API-based si ottimizza scegliendo il modello e riducendo i token, non scalando hardware.
  • Forecasting di serie temporali in SQL → ARIMA_PLUS in BigQuery ML: distrattori propongono AutoML tabular o custom training, più lenti da mettere in produzione quando i dati sono già in BigQuery.
  • Selezionare un foundation model open o Gemini/Imagen/Veo → Model Garden: l’esame confonde Model Garden (catalogo di selezione e deploy) con Model Registry (versioning dei propri modelli addestrati); sono due cose diverse.