Esplorare e preprocessare i dati: scegliere lo strumento per scala e complessità

La domanda ricorrente nel Professional Machine Learning Engineer non è “come si trasforma un dato”, ma “quale strumento a parità di risultato costa meno e scala meglio”. I criteri sono la posizione del dato, il volume e la complessità della logica.

  • BigQuery SQL quando i dati sono già in BigQuery e le trasformazioni sono esprimibili in SQL su tabelle strutturate a scala petabyte: serverless, nessuna infrastruttura, si porta il calcolo al dato invece di esportarlo. Con BigQuery ML puoi anche addestrare e valutare modelli direttamente in SQL (CREATE MODEL, ML.PREDICT, ML.EVALUATE) senza muovere il dataset: ideale per baseline rapide, feature engineering SQL e team di data analyst.
  • Dataflow (Apache Beam gestito) per pipeline di preprocessing complesse, soprattutto streaming o batch a grande scala, con lo stesso codice riutilizzabile in entrambe le modalità e autoscaling gestito.
  • Apache Spark su Dataproc quando esiste già una codebase Spark/PySpark o serve l’ecosistema Hadoop/MLlib.
  • Framework Python in-memory (pandas, scikit-learn) solo per dataset che stanno in memoria, tipicamente in fase di prototipazione nel notebook.

Il trade-off chiave: più il volume cresce, più conviene spostarsi verso BigQuery/Dataflow; il Python in-memory scala male ed è una risposta quasi sempre sbagliata su dataset di produzione.

Feature Store e gestione dei dati sensibili

Il Vertex AI Feature Store serve a consolidare, versionare e condividere feature tra team e modelli, eliminando la duplicazione e riducendo il training-serving skew (usare la stessa definizione di feature in training e in inferenza). Offre serving online a bassa latenza per l’inferenza real-time e serving offline per costruire i training set con correttezza point-in-time (evitando data leakage temporale). La scelta a esame: se più modelli riusano le stesse feature o serve latenza bassa in produzione, la risposta è Feature Store, non un file o una tabella ad hoc ricalcolata ogni volta.

Per la privacy, i dati con PII vanno trattati con Sensitive Data Protection (de-identification, masking, tokenizzazione) prima di finire in training o feature, affiancato da controlli IAM e isolamento di rete. Non si addestrano modelli su PII in chiaro quando esiste un requisito di conformità.

Prototipazione ed esperimenti

Per il prototyping i due ambienti gestiti sono Vertex AI Workbench (notebook managed integrati con i servizi Vertex, adatti a sviluppo individuale e accesso ai dati GCP) e Colab Enterprise (notebook collaborativi con governance e sicurezza enterprise). Entrambi supportano PyTorch, scikit-learn e JAX.

Il tracciamento è affidato a Vertex AI Experiments, che registra parametri, metriche e run per confrontarli in modo riproducibile, appoggiandosi a Vertex ML Metadata per artifact e lineage (dataset → run → modello → endpoint). Questo è ciò che rende un esperimento auditabile, non lo screenshot di una metrica.

La valutazione va oltre le metriche classiche (accuracy, AUC, RMSE): per i modelli gen AI, dove non esiste una ground truth esatta, si usano il servizio di evaluation e il pattern LLM-as-a-judge, cioè un modello che valuta gli output di un altro secondo una rubrica, utile per qualità, coerenza e sicurezza delle risposte.

Trappole tipiche d’esame

  • Preprocessing su dataset petabyte già in BigQuery → BigQuery SQL/BigQuery ML: esportare in pandas per usare scikit-learn non scala; porta il calcolo al dato. Il Python in-memory è la distrazione tipica.
  • Stesse feature usate da più team o serving real-time a bassa latenza → Vertex AI Feature Store: ricalcolare le feature per ogni modello introduce duplicazione e training-serving skew.
  • Preprocessing in streaming e batch con un solo codebase → Dataflow (Beam): Dataproc/Spark è la scelta giusta solo se esiste già codice Spark o l’ecosistema Hadoop.
  • Dati con PII prima del training → Sensitive Data Protection: de-identify/tokenize a monte; IAM da solo non basta a soddisfare un requisito di privacy sul contenuto.
  • Confronto riproducibile e auditabile fra molte run → Vertex AI Experiments + ML Metadata (lineage): tenere i risultati in fogli o log manuali è la trappola.
  • Valutare output gen AI senza ground truth esatta → LLM-as-a-judge / evaluation gen AI: le metriche di classificazione classiche non misurano qualità o coerenza di testo generato.