Organizzare i dati e scegliere l’SDK di training

Prima di addestrare devi decidere dove vivono i dati e con quale strumento li elabori. Dati tabellari stanno naturalmente in BigQuery (dove puoi anche addestrare in SQL con BigQuery ML: CREATE MODEL, ML.PREDICT, ML.EVALUATE), mentre testo, speech, immagini e video vanno su Cloud Storage come oggetti, spesso referenziati da un manifest o da un managed dataset di Vertex AI.

La scelta dell’SDK segue il trade-off effort/controllo:

  • Vertex AI AutoML: training no-code su dati strutturati o non strutturati, quando il team non ha competenze di modeling e vuole una baseline solida in fretta.
  • Tabular Workflows: pipeline gestite per dati tabellari su larga scala (es. AutoML tabular, XGBoost, Wide & Deep) con feature engineering integrato.
  • Vertex AI custom training: hai il tuo codice (TensorFlow, PyTorch, JAX) in un container; massimo controllo su architettura, loss e loop di training.
  • Kubeflow su GKE: quando servono orchestrazione portabile e controllo fine sul cluster; ricorda però che per pipeline ML gestite senza gestire infrastruttura la scelta idiomatica è Vertex AI Pipelines (KFP/TFX).

Hyperparameter tuning e troubleshooting

L’hyperparameter tuning cerca la combinazione migliore di learning rate, batch size, numero di layer, regolarizzazione, ottimizzando una metrica che tu dichiari (accuracy, AUC, loss di validazione). Definisci lo spazio di ricerca e la strategia (grid, random, o Bayesian/Vizier per campionamento intelligente); usa early stopping per terminare i trial poco promettenti e ridurre il costo. Attenzione a non confonderlo con il tuning dei parametri del modello (i pesi), che è invece il risultato del training stesso.

Per il troubleshooting dei fallimenti: OOM (out-of-memory) si risolve riducendo batch size o passando a device con più memoria; loss che diverge o va a NaN indica learning rate troppo alto o dati non normalizzati; una loss di validazione che sale mentre quella di training scende è overfitting. Controlla sempre i log del training job e le metriche, non solo l’exit code.

Fine-tuning vs prompt vs RAG

Con i foundation models (Model Garden: Gemini, Imagen, modelli open) hai tre leve, in ordine di costo/complessità crescente:

  • Prompt engineering: parti da qui. Nessun training, iterazione immediata; adatto quando il modello base sa già fare il task ma va guidato.
  • RAG: quando serve conoscenza aggiornata, proprietaria o verificabile con citazioni. Recuperi contesto da una fonte esterna e lo inietti nel prompt; eviti di riaddestrare quando i dati cambiano spesso.
  • Fine-tuning: quando ti serve un cambio di stile/formato/comportamento stabile, o il modello base non padroneggia il dominio nemmeno con buon prompting. Richiede dataset di qualità e ha costo maggiore; non è la soluzione per “aggiungere fatti freschi” (quello è compito di RAG).

Hardware: CPU/GPU/TPU e training distribuito

La scelta dell’acceleratore è un classico trade-off costo/tempo:

  • CPU: carichi piccoli, preprocessing, modelli leggeri o inferenza a basso volume.
  • GPU: general-purpose per deep learning, ottime per modelli di media dimensione e per PyTorch/framework con ampio supporto.
  • TPU: pensate per grandi training di deep learning (matrici massive, transformer, batch grandi) con il miglior throughput per costo su quei carichi.

Quando il modello o i dati superano un singolo device usi il training distribuito:

  • Data parallelism: ogni device tiene una copia identica dei pesi ma processa shard di dati diversi; i gradienti vengono aggregati. È il caso più comune, per accelerare il training.
  • Model parallelism: il modello è troppo grande per stare su un device, quindi lo spezzi tra più device. Necessario per modelli molto grandi, ma introduce overhead di comunicazione.

Trappole tipiche d’esame

  • Servono fatti aggiornati/proprietari con citazioni → RAG, non fine-tuning: il fine-tuning cambia comportamento e stile, non è il modo per iniettare conoscenza fresca.
  • Modello troppo grande per la memoria di un acceleratore → model parallelism: se invece vuoi solo andare più veloce con lo stesso modello che ci sta, è data parallelism.
  • Grande training deep learning transformer sensibile al costo → TPU: la GPU è la scelta general-purpose, ma per throughput su carichi massivi le TPU vincono; la CPU è un distrattore per carichi piccoli.
  • Baseline rapida senza competenze di modeling → Vertex AI AutoML (o BigQuery ML su dati in BigQuery): custom training è la risposta sbagliata quando il team non deve/può scrivere codice.
  • Training job va OOM → riduci batch size o usa device con più memoria: aumentare il learning rate o i trial di tuning non c’entra nulla.
  • Ottimizzare learning rate/batch size su una metrica → hyperparameter tuning con early stopping: non confonderlo con l’ottimizzazione dei pesi, che è il training stesso.