Preelaborazione dei dati per il machine learning: opzioni e raccomandazioni

Questo documento è il primo di una serie in due parti che esplora il tema dell'ingegneria dei dati e dell'ingegneria delle funzionalità per l'apprendimento automatico (ML), con particolare attenzione alle attività di apprendimento supervisionato. Questa prima parte illustra le best practice per la preelaborazione dei dati in una pipeline di ML su Google Cloud. Il documento si concentra sull'utilizzo di TensorFlow e della libreria open source TensorFlow Transform ( tf.Transform ) per preparare i dati, addestrare il modello e servire il modello per la previsione. Questo documento evidenzia le sfide della preelaborazione dei dati per il machine learning e descrive le opzioni e gli scenari per eseguire in modo efficace la trasformazione dei dati su Google Cloud.

Questo documento presuppone che tu abbia familiarità con BigQuery , Dataflow , Vertex AI e l'API TensorFlow Keras .

Il secondo documento, Preelaborazione dei dati per ML con Google Cloud , fornisce un tutorial passo passo su come implementare una pipeline tf.Transform .

Introduzione

Il machine learning ti aiuta a trovare automaticamente modelli complessi e potenzialmente utili nei dati. Questi modelli vengono condensati in un modello ML che può quindi essere utilizzato su nuovi punti dati, un processo chiamato fare previsioni o eseguire inferenze .

La creazione di un modello ML è un processo in più fasi. Ogni passaggio presenta le proprie sfide tecniche e concettuali. Questa serie in due parti si concentra sulle attività di apprendimento supervisionato e sul processo di selezione, trasformazione e aumento dei dati di origine per creare potenti segnali predittivi per la variabile target. Queste operazioni combinano la conoscenza del dominio con le tecniche di data science. Le operazioni sono l'essenza dell'ingegneria delle funzionalità .

La dimensione dei set di dati di addestramento per i modelli ML del mondo reale può essere facilmente uguale o superiore a un terabyte (TB). Pertanto, sono necessari framework di elaborazione dati su larga scala per elaborare questi set di dati in modo efficiente e distribuito. Quando utilizzi un modello ML per effettuare previsioni, devi applicare le stesse trasformazioni utilizzate per i dati di training sui nuovi punti dati. Applicando le stesse trasformazioni, presenti il ​​set di dati in tempo reale al modello ML nel modo previsto dal modello.

Questo documento discute queste sfide per diversi livelli di granularità delle operazioni di ingegneria delle funzionalità: aggregazioni a livello di istanza, passaggio completo e finestra temporale. Questo documento descrive inoltre le opzioni e gli scenari per eseguire la trasformazione dei dati per il machine learning su Google Cloud.

Questo documento fornisce anche una panoramica di TensorFlow Transform ( tf.Transform ), una libreria per TensorFlow che consente di definire la trasformazione dei dati sia a livello di istanza che a passaggio completo attraverso pipeline di preelaborazione dei dati. Queste pipeline vengono eseguite con Apache Beam e creano artefatti che consentono di applicare le stesse trasformazioni durante la previsione di quando viene servito il modello.

Preelaborazione dei dati per ML

Questa sezione introduce le operazioni di preelaborazione dei dati e le fasi di preparazione dei dati. Vengono inoltre discussi i tipi di operazioni di preelaborazione e la loro granularità.

Ingegneria dei dati rispetto all'ingegneria delle funzionalità

La preelaborazione dei dati per il machine learning coinvolge sia l'ingegneria dei dati che l'ingegneria delle funzionalità. L'ingegneria dei dati è il processo di conversione dei dati grezzi in dati preparati . L'ingegneria delle funzionalità ottimizza quindi i dati preparati per creare le funzionalità previste dal modello ML. Questi termini hanno i seguenti significati:

Dati grezzi (o semplicemente dati )

I dati nel loro formato originale, senza alcuna preparazione preliminare per il ML. In questo contesto, i dati potrebbero essere nella loro forma grezza (in un data lake) o in forma trasformata (in un data warehouse). I dati trasformati presenti in un data warehouse potrebbero essere stati convertiti dalla forma grezza originale per essere utilizzati per l'analisi. Tuttavia, in questo contesto, dati grezzi significa che i dati non sono stati preparati appositamente per la tua attività di ML. I dati sono considerati dati grezzi anche se vengono inviati da sistemi di streaming che eventualmente chiamano modelli ML per le previsioni.

Dati preparati

Il set di dati nel modulo è pronto per la tua attività di ML: le origini dati sono state analizzate, unite e inserite in un formato tabellare. I dati preparati vengono aggregati e riepilogati con la giusta granularità: ad esempio, ogni riga nel set di dati rappresenta un cliente univoco e ogni colonna rappresenta informazioni di riepilogo per il cliente, come la spesa totale nelle ultime sei settimane. In una tabella dati preparata, le colonne non pertinenti sono state eliminate e i record non validi sono stati filtrati. Per le attività di apprendimento supervisionato, è presente la funzionalità target.

Funzionalità ingegnerizzate

Il set di dati con le funzionalità ottimizzate previste dal modello, ovvero le funzionalità create eseguendo determinate operazioni specifiche di ML sulle colonne nel set di dati preparato e creando nuove funzionalità per il modello durante l'addestramento e la previsione, come descritto più avanti in Operazioni di preelaborazione . Esempi di queste operazioni includono il ridimensionamento delle colonne numeriche su un valore compreso tra 0 e 1, il ritaglio di valori e le funzionalità categoriche di codifica a caldo .

Il diagramma seguente, Figura 1, mostra i passaggi coinvolti nella preparazione dei dati preelaborati:

In pratica, i dati provenienti dalla stessa fonte si trovano spesso a stadi di preparazione diversi. Ad esempio, un campo di una tabella nel data warehouse potrebbe essere utilizzato direttamente come funzionalità progettata. Allo stesso tempo, un altro campo nella stessa tabella potrebbe dover subire delle trasformazioni prima di diventare una funzionalità progettata. Allo stesso modo, le operazioni di ingegneria dei dati e di ingegneria delle funzionalità potrebbero essere combinate nella stessa fase di preelaborazione dei dati.

Operazioni di preelaborazione

La preelaborazione dei dati comprende diverse operazioni. Ogni operazione è progettata per aiutare il machine learning a creare modelli predittivi migliori. I dettagli di queste operazioni di preelaborazione non rientrano nell'ambito di questo documento, ma alcune operazioni vengono brevemente descritte in questa sezione.

Per i dati strutturati, le operazioni di preelaborazione dei dati includono quanto segue:

• Pulizia dei dati: rimozione o correzione di record che presentano valori danneggiati o non validi dai dati grezzi e rimozione di record a cui manca un gran numero di colonne.
• Selezione e partizionamento delle istanze: selezione di punti dati dal set di dati di input per creare set di training, valutazione (convalida) e test . Questo processo include tecniche per il campionamento casuale ripetibile, il sovracampionamento delle classi minoritarie e il partizionamento stratificato.
• Ottimizzazione delle funzionalità: miglioramento della qualità di una funzionalità per ML, che include il ridimensionamento e la normalizzazione dei valori numerici, l'attribuzione di valori mancanti, il ritaglio di valori anomali e la regolazione di valori con distribuzioni distorte.
• Trasformazione delle funzionalità: conversione di una funzionalità numerica in una funzionalità categoriale (tramite bucketization ) e conversione di funzionalità categoriali in una rappresentazione numerica (tramite codifica one-hot, apprendimento con conteggi , incorporamenti di funzionalità sparse, ecc.). Alcuni modelli funzionano solo con funzionalità numeriche o categoriali, mentre altri possono gestire funzionalità di tipo misto. Anche quando i modelli gestiscono entrambi i tipi, possono trarre vantaggio da rappresentazioni diverse (numeriche e categoriali) della stessa caratteristica.
• Estrazione di funzionalità: ridurre il numero di funzionalità creando rappresentazioni di dati di dimensioni inferiori e più potenti utilizzando tecniche come PCA , incorporamento dell'estrazione e hashing .
• Selezione delle funzionalità: selezionare un sottoinsieme delle funzionalità di input per l'addestramento del modello e ignorare quelle irrilevanti o ridondanti, utilizzando metodi di filtro o wrapper . La selezione delle funzionalità può anche implicare semplicemente l'eliminazione delle funzionalità se alle funzionalità manca un gran numero di valori.
• Costruzione di caratteristiche: creazione di nuove caratteristiche utilizzando tecniche tipiche, come l'espansione polinomiale (utilizzando funzioni matematiche univariate) o l'incrocio di caratteristiche (per catturare le interazioni delle caratteristiche). Le funzionalità possono anche essere costruite utilizzando la logica aziendale dal dominio del caso d'uso ML.

Quando lavori con dati non strutturati (ad esempio immagini, audio o documenti di testo), il deep learning sostituisce l'ingegneria delle funzionalità basata sulla conoscenza del dominio inserendola nell'architettura del modello. Uno strato convoluzionale è un preprocessore automatico di funzionalità. Costruire la giusta architettura del modello richiede una certa conoscenza empirica dei dati. Inoltre, è necessaria una certa quantità di preelaborazione, come la seguente:

• Per documenti di testo: radice e lemmatizzazione , calcolo TF-IDF ed estrazione di n grammi , ricerca per incorporamento.
• Per le immagini: ritaglio, ridimensionamento, ritaglio, sfocatura gaussiana e filtri canary.
• Per tutti i tipi di dati (inclusi testo e immagini): trasferimento dell'apprendimento , che tratta tutti gli strati tranne gli ultimi del modello completamente addestrato come un passaggio di progettazione delle funzionalità.

Granularità della preelaborazione

In questa sezione viene illustrata la granularità dei tipi di trasformazioni dei dati. Mostra perché questa prospettiva è fondamentale quando si preparano nuovi punti dati per le previsioni utilizzando trasformazioni applicate ai dati di training.

Le operazioni di preelaborazione e trasformazione possono essere classificate come segue, in base alla granularità dell'operazione:

• Trasformazioni a livello di istanza durante l'addestramento e la previsione . Si tratta di trasformazioni semplici, in cui per la trasformazione sono necessari solo i valori della stessa istanza. Ad esempio, le trasformazioni a livello di istanza potrebbero includere il ritaglio del valore di una funzionalità fino a una soglia, l'espansione polinomiale di un'altra funzionalità, la moltiplicazione di due funzionalità o il confronto di due funzionalità per creare un flag booleano.

  Queste trasformazioni devono essere applicate in modo identico durante l'addestramento e la previsione, poiché il modello verrà addestrato sulle caratteristiche trasformate, non sui valori di input grezzi. Se i dati non vengono trasformati in modo identico, il modello si comporta in modo inadeguato perché vengono presentati dati con una distribuzione di valori con cui non è stato addestrato. Per ulteriori informazioni, vedere la discussione sull'inclinazione del servizio di formazione nella sezione Sfide di preelaborazione .

• Trasformazioni a passaggio completo durante l'addestramento, ma trasformazioni a livello di istanza durante la previsione . In questo scenario, le trasformazioni sono stateful perché utilizzano alcune statistiche precalcolate per eseguire la trasformazione. Durante l'addestramento, si analizza l'intero corpo dei dati di addestramento per calcolare quantità quali minimo, massimo, media e varianza per trasformare i dati di addestramento, i dati di valutazione e i nuovi dati al momento della previsione.

  Ad esempio, per normalizzare una caratteristica numerica per l'addestramento, calcolarne la media (μ) e la deviazione standard (σ) sull'insieme dei dati di addestramento. Questo calcolo è chiamato operazione di passaggio completo (o analisi ). Quando servi il modello per la previsione, il valore di un nuovo punto dati viene normalizzato per evitare distorsioni nel servizio di training. Pertanto, i valori μ e σ calcolati durante l'addestramento vengono utilizzati per regolare il valore della caratteristica, che è la seguente semplice operazione a livello di istanza :

  $$ value_{scaled} = (value_{raw} - \mu) \div \sigma $$

  Le trasformazioni a passaggio completo includono quanto segue:

  • MinMax ridimensiona le caratteristiche numeriche utilizzando il minimo e il massimo calcolati dal set di dati di addestramento.
  • Caratteristiche numeriche di ridimensionamento standard (normalizzazione del punteggio z) utilizzando μ e σ calcolati sul set di dati di addestramento.
  • Separazione di caratteristiche numeriche mediante l'uso dei quantili.
  • Assegnazione dei valori mancanti utilizzando la mediana (caratteristiche numeriche) o la moda (caratteristiche categoriali).
  • Conversione di stringhe (valori nominali) in numeri interi (indici) estraendo tutti i valori distinti (vocabolario) di una caratteristica categorica di input.
  • Conteggio dell'occorrenza di un termine (valore della caratteristica) in tutti i documenti (istanze) per calcolare TF-IDF.
  • Calcolo della PCA delle caratteristiche di input per proiettare i dati in uno spazio dimensionale inferiore (con caratteristiche linearmente dipendenti).

  Dovresti utilizzare solo i dati di training per calcolare statistiche come μ, σ, min e max . Se aggiungi i dati di test e valutazione per queste operazioni, stai perdendo informazioni dai dati di valutazione e test per addestrare il modello. Ciò influisce sull'affidabilità del test e sui risultati della valutazione. Per garantire l'applicazione di una trasformazione coerente a tutti i set di dati, utilizzare le stesse statistiche calcolate dai dati di training per trasformare i dati di test e valutazione.

• Aggregazioni storiche durante l'allenamento e la previsione . Ciò comporta la creazione di aggregazioni, derivazioni e flag aziendali come segnali di input per l'attività di previsione, ad esempio la creazione di metriche di recency, frequenza e monetarie (RFM) per consentire ai clienti di creare modelli di propensione. Questi tipi di funzionalità possono essere precalcolati e archiviati in un archivio di funzionalità per essere utilizzati durante l'addestramento del modello, il punteggio batch e la pubblicazione delle previsioni online. È inoltre possibile eseguire ulteriore progettazione di funzionalità (ad esempio, trasformazione e ottimizzazione) su queste aggregazioni prima dell'addestramento e della previsione.

• Aggregazioni storiche durante l'addestramento, ma aggregazioni in tempo reale durante la previsione . Questo approccio prevede la creazione di una funzionalità riepilogando i valori in tempo reale nel tempo. In questo approccio, le istanze da aggregare sono definite tramite clausole di finestra temporale. Ad esempio, puoi utilizzare questo approccio se desideri addestrare un modello che stima il tempo di viaggio del taxi in base ai parametri di traffico per il percorso negli ultimi 5 minuti, negli ultimi 10 minuti, negli ultimi 30 minuti e in altri casi. intervalli. È inoltre possibile utilizzare questo approccio per prevedere il guasto di una parte del motore in base alla media mobile dei valori di temperatura e vibrazione calcolati negli ultimi 3 minuti. Sebbene queste aggregazioni possano essere preparate offline per l'addestramento, vengono calcolate in tempo reale da un flusso di dati durante l'elaborazione.

  Più precisamente, quando si preparano i dati di training, se il valore aggregato non è presente nei dati grezzi, il valore viene creato durante la fase di ingegneria dei dati. I dati grezzi vengono solitamente archiviati in un database con un formato (entity, timestamp, value) . Negli esempi precedenti, entity è l'identificatore del segmento di percorso per le tratte in taxi e l'identificatore della parte del motore per il guasto del motore. Puoi utilizzare le operazioni di finestra per calcolare (entity, time_index, aggregated_value_over_time_window) e utilizzare le funzionalità di aggregazione come input per l'addestramento del modello.

  Quando viene fornito il modello per la previsione in tempo reale (online), il modello prevede funzionalità derivate dai valori aggregati come input. Pertanto, puoi utilizzare una tecnologia di elaborazione del flusso come Apache Beam per calcolare le aggregazioni dai punti dati in tempo reale trasmessi in streaming nel tuo sistema. La tecnologia di elaborazione del flusso aggrega i dati in tempo reale in base a finestre temporali man mano che arrivano nuovi punti dati. È inoltre possibile eseguire la progettazione di funzionalità aggiuntive (ad esempio, trasformazione e ottimizzazione) su queste aggregazioni prima dell'addestramento e della previsione.

Pipeline di machine learning su Google Cloud

Questa sezione illustra i componenti principali di una tipica pipeline end-to-end per addestrare e servire modelli TensorFlow ML su Google Cloud utilizzando servizi gestiti. Viene inoltre illustrato dove è possibile implementare diverse categorie di operazioni di pre-elaborazione dei dati e le sfide comuni che potresti incontrare quando implementi tali trasformazioni. La sezione Come funziona tf.Transform mostra come la libreria TensorFlow Transform aiuta ad affrontare queste sfide.

Architettura di alto livello

Il diagramma seguente, figura 2, mostra un'architettura di alto livello di una tipica pipeline ML per l'addestramento e la gestione dei modelli TensorFlow. Le etichette A, B e C nel diagramma si riferiscono ai diversi punti della pipeline in cui può avvenire la preelaborazione dei dati. I dettagli su questi passaggi sono forniti nella sezione seguente.

La pipeline è composta dai seguenti passaggi:

1. Dopo aver importato i dati non elaborati, i dati tabulari vengono archiviati in BigQuery e altri dati come immagini, audio e video vengono archiviati in Cloud Storage. La seconda parte di questa serie utilizza come esempio i dati tabulari archiviati in BigQuery.
2. L'ingegneria dei dati (preparazione) e l'ingegneria delle funzionalità vengono eseguite su larga scala utilizzando Dataflow. Questa esecuzione produce set di test, valutazione e formazione pronti per il machine learning archiviati in Cloud Storage. Idealmente, questi set di dati vengono archiviati come file TFRecord , che è il formato ottimizzato per i calcoli TensorFlow.
3. Un pacchetto di addestramento del modello TensorFlow viene inviato a Vertex AI Training, che utilizza i dati preelaborati dei passaggi precedenti per addestrare il modello. L'output di questo passaggio è un TensorFlow SavedModel addestrato che viene esportato in Cloud Storage.
4. Il modello TensorFlow addestrato viene distribuito a Vertex AI Prediction come servizio dotato di un'API REST in modo che possa essere utilizzato per le previsioni online. Lo stesso modello può essere utilizzato anche per lavori di previsione batch.
5. Dopo che il modello è stato distribuito come API REST, le app client e i sistemi interni possono richiamare l'API inviando richieste con alcuni punti dati e ricevendo risposte dal modello con previsioni.
6. Per orchestrare e automatizzare questa pipeline, puoi utilizzare Vertex AI Pipelines come pianificatore per richiamare i passaggi di preparazione dei dati, training del modello e distribuzione del modello.

Puoi anche utilizzare Vertex AI Feature Store per archiviare funzionalità di input per fare previsioni. Ad esempio, puoi creare periodicamente funzionalità ingegnerizzate dai dati grezzi più recenti e archiviarli nel Vertex AI Feature Store. Le app client recuperano le funzionalità di input richieste da Vertex AI Feature Store e le inviano al modello per ricevere previsioni.

Dove eseguire la preelaborazione

Nella figura 2, le etichette A, B e C mostrano che le operazioni di preelaborazione dei dati possono avvenire in BigQuery, Dataflow o TensorFlow. Le sezioni seguenti descrivono il funzionamento di ciascuna di queste opzioni.

Opzione A: BigQuery

In genere, la logica viene implementata in BigQuery per le seguenti operazioni:

• Campionamento: selezione casuale di un sottoinsieme di dati.
• Filtraggio: rimozione di istanze irrilevanti o non valide.
• Partizionamento: suddivisione dei dati per produrre set di training, valutazione e test.

Gli script SQL BigQuery possono essere utilizzati come query di origine per la pipeline di preelaborazione di Dataflow, che è la fase di elaborazione dei dati nella figura 2. Ad esempio, se un sistema viene utilizzato in Canada e il data warehouse include transazioni da tutto il mondo, filtrando ottenere dati di addestramento solo per il Canada è meglio farlo in BigQuery. La progettazione delle funzionalità in BigQuery è semplice e scalabile e supporta l'implementazione di trasformazioni di funzionalità di aggregazioni cronologiche e a livello di istanza.

Tuttavia, ti consigliamo di utilizzare BigQuery per l'ingegneria delle funzionalità solo se utilizzi il modello per la previsione batch (punteggio) o se le funzionalità sono precalcolate in BigQuery, ma archiviate in Vertex AI Feature Store per essere utilizzate durante la previsione online. Se prevedi di distribuire il modello per le previsioni online e non disponi della funzionalità progettata in un archivio di funzionalità online, devi replicare le operazioni di preelaborazione SQL per trasformare i punti dati non elaborati generati da altri sistemi. In altre parole, devi implementare la logica due volte: una volta in SQL per preelaborare i dati di addestramento in BigQuery e una seconda volta nella logica dell'app che utilizza il modello per preelaborare i punti dati online per la previsione.

Ad esempio, se l'app client è scritta in Java, è necessario reimplementare la logica in Java. Ciò può introdurre errori dovuti a discrepanze di implementazione, come descritto nella sezione disallineamento del servizio di formazione delle sfide di preelaborazione più avanti in questo documento. È anche un sovraccarico aggiuntivo mantenere due diverse implementazioni. Ogni volta che si modifica la logica in SQL per preelaborare i dati di training, è necessario modificare di conseguenza l'implementazione Java per preelaborare i dati al momento dell'elaborazione.

Se utilizzi il modello solo per la previsione batch (ad esempio, utilizzando la previsione batch Vertex AI) e se i dati per il punteggio provengono da BigQuery, puoi implementare queste operazioni di preelaborazione come parte dello script SQL BigQuery. In tal caso, è possibile utilizzare lo stesso script SQL di preelaborazione per preparare sia i dati di training che quelli di punteggio.

Le trasformazioni stateful full-pass non sono adatte per l'implementazione in BigQuery. Se utilizzi BigQuery per trasformazioni a passaggio completo, hai bisogno di tabelle ausiliarie per archiviare le quantità necessarie per le trasformazioni con stato, come medie e varianze per ridimensionare le caratteristiche numeriche. Inoltre, l'implementazione di trasformazioni full-pass utilizzando SQL su BigQuery crea una maggiore complessità negli script SQL e crea una dipendenza complessa tra l'addestramento e gli script SQL di punteggio.

Opzione B: flusso di dati

Come mostrato nella figura 2, è possibile implementare operazioni di preelaborazione computazionalmente costose in Apache Beam ed eseguirle su larga scala utilizzando Dataflow. Dataflow è un servizio di scalabilità automatica completamente gestito per l'elaborazione di dati in batch e in flusso. Quando utilizzi Dataflow, puoi anche utilizzare librerie specializzate esterne per l'elaborazione dei dati, a differenza di BigQuery.

Dataflow può eseguire trasformazioni a livello di istanza e trasformazioni di funzionalità di aggregazione cronologica e in tempo reale. In particolare, se i modelli ML prevedono una funzionalità di input come total_number_of_clicks_last_90sec , le funzioni di finestra di Apache Beam possono calcolare queste funzionalità in base all'aggregazione dei valori delle finestre temporali dei dati degli eventi (streaming) in tempo reale (ad esempio, eventi di clic). Nella discussione precedente sulla granularità delle trasformazioni , si parlava di "aggregazioni storiche durante l'addestramento, ma aggregazioni in tempo reale durante la previsione".

Il diagramma seguente, figura 3, mostra il ruolo di Dataflow nell'elaborazione dei dati del flusso per previsioni quasi in tempo reale.

Come illustrato nella figura 3, durante l'elaborazione, gli eventi denominati punti dati vengono inseriti in Pub/Sub . Dataflow utilizza questi punti dati, calcola le funzionalità in base agli aggregati nel tempo e quindi chiama l'API del modello ML distribuito per le previsioni. Le previsioni vengono quindi inviate a una coda Pub/Sub in uscita. Da Pub/Sub, le previsioni possono essere utilizzate dai sistemi downstream come il monitoraggio o il controllo oppure possono essere inviate (ad esempio, come notifiche) al client richiedente originale. Le previsioni possono anche essere archiviate in un archivio dati a bassa latenza come Cloud Bigtable per il recupero in tempo reale. Cloud Bigtable può essere utilizzato anche per accumulare e archiviare queste aggregazioni in tempo reale in modo che possano essere consultate quando necessario per la previsione.

La stessa implementazione di Apache Beam può essere utilizzata per elaborare in batch i dati di addestramento provenienti da un datastore offline come BigQuery ed elaborare in streaming dati in tempo reale per fornire previsioni online.

In altre architetture tipiche, come quella illustrata nella figura 2, l'app client chiama direttamente l'API del modello distribuito per le previsioni online. In tal caso, se in Dataflow vengono implementate operazioni di preelaborazione per preparare i dati di addestramento, le operazioni non vengono applicate ai dati di previsione che vanno direttamente al modello. Pertanto, trasformazioni come queste dovrebbero essere integrate nel modello durante la pubblicazione delle previsioni online.

Il flusso di dati può essere utilizzato per eseguire trasformazioni full-pass, calcolando le statistiche richieste su larga scala. Tuttavia, queste statistiche devono essere archiviate da qualche parte per essere utilizzate durante la previsione per trasformare i punti dati della previsione. Utilizzando la libreria TensorFlow Transform ( tf.Transform ), puoi incorporare direttamente queste statistiche nel modello invece di memorizzarle altrove. Questo approccio viene spiegato più avanti in Come funziona tf.Transform .

Opzione C: TensorFlow

Come mostrato nella figura 2, è possibile implementare operazioni di preelaborazione e trasformazione dei dati nel modello TensorFlow stesso. Come mostrato nella figura, la preelaborazione implementata per l'addestramento del modello TensorFlow diventa parte integrante del modello quando il modello viene esportato e distribuito per le previsioni. Le trasformazioni nel modello TensorFlow possono essere realizzate in uno dei seguenti modi:

• Implementazione di tutta la logica di trasformazione a livello di istanza nella funzione input_fn e nella serving_fn . La funzione input_fn prepara un set di dati utilizzando l' API tf.data.Dataset per addestrare un modello. La serving_fn riceve e prepara i dati per le previsioni.
• Inserendo il codice di trasformazione direttamente nel tuo modello TensorFlow utilizzando i livelli di preelaborazione Keras o creando livelli personalizzati .

Il codice logico di trasformazione nella serving_fn definisce l'interfaccia di servizio del tuo SavedModel per la previsione online. Se implementi le stesse trasformazioni utilizzate per preparare i dati di training nel codice della logica di trasformazione della serving_fn , garantisci che le stesse trasformazioni vengano applicate ai nuovi punti dati di previsione quando vengono serviti.

Tuttavia, poiché il modello TensorFlow elabora ogni punto dati in modo indipendente o in un piccolo batch, non puoi calcolare le aggregazioni da tutti i punti dati. Di conseguenza, le trasformazioni a passaggio completo non possono essere implementate nel modello TensorFlow.

Sfide di preelaborazione

Di seguito sono riportate le principali sfide legate all'implementazione della preelaborazione dei dati:

• Distorsione del servizio di formazione . Lo squilibrio tra servizio e allenamento si riferisce alla differenza tra l'efficacia (prestazione predittiva) durante l'allenamento e durante il servizio. Questa distorsione può essere causata da una discrepanza tra il modo in cui gestisci i dati nelle pipeline di addestramento e di servizio. Ad esempio, se il tuo modello viene addestrato su una funzionalità trasformata logaritmicamente, ma viene presentata con la funzionalità grezza durante l'elaborazione, l'output della previsione potrebbe non essere accurato.

  Se le trasformazioni diventano parte del modello stesso, può essere semplice gestire le trasformazioni a livello di istanza, come descritto in precedenza in Opzione C: TensorFlow . In tal caso, l'interfaccia di servizio del modello (la serving_fn ) prevede dati grezzi, mentre il modello trasforma internamente questi dati prima di calcolare l'output. Le trasformazioni sono le stesse applicate ai punti dati grezzi di addestramento e previsione.

• Trasformazioni a passaggio completo . Non è possibile implementare trasformazioni a passaggio completo come trasformazioni di ridimensionamento e normalizzazione nel modello TensorFlow. Nelle trasformazioni a passaggio completo, alcune statistiche (ad esempio, i valori max e min per ridimensionare le caratteristiche numeriche) devono essere calcolate in anticipo sui dati di training, come descritto in Opzione B: Flusso di dati . I valori devono quindi essere archiviati da qualche parte per essere utilizzati durante la fornitura del modello per la previsione per trasformare i nuovi punti dati grezzi come trasformazioni a livello di istanza, evitando così distorsioni nel servizio di training. Puoi utilizzare la libreria TensorFlow Transform ( tf.Transform ) per incorporare direttamente le statistiche nel tuo modello TensorFlow. Questo approccio viene spiegato più avanti in Come funziona tf.Transform .

• Preparare i dati in anticipo per una migliore efficienza della formazione . L'implementazione di trasformazioni a livello di istanza come parte del modello può ridurre l'efficienza del processo di formazione. Questo peggioramento si verifica perché le stesse trasformazioni vengono applicate ripetutamente agli stessi dati di training in ogni epoca. Immagina di avere dati di addestramento non elaborati con 1.000 funzionalità e di applicare un mix di trasformazioni a livello di istanza per generare 10.000 funzionalità. Se implementi queste trasformazioni come parte del tuo modello e poi fornisci al modello i dati di training grezzi, queste 10.000 operazioni vengono applicate N volte su ciascuna istanza, dove N è il numero di epoche. Inoltre, se utilizzi acceleratori (GPU o TPU), rimangono inattivi mentre la CPU esegue tali trasformazioni, il che non costituisce un uso efficiente dei tuoi costosi acceleratori.

  Idealmente, i dati di addestramento vengono trasformati prima dell'addestramento, utilizzando la tecnica descritta in Opzione B: Flusso di dati , in cui le 10.000 operazioni di trasformazione vengono applicate solo una volta su ciascuna istanza di addestramento. I dati di training trasformati vengono quindi presentati al modello. Non vengono applicate ulteriori trasformazioni e gli acceleratori sono sempre occupati. Inoltre, l'utilizzo di Dataflow ti aiuta a preelaborare grandi quantità di dati su larga scala, utilizzando un servizio completamente gestito.

  La preparazione anticipata dei dati di addestramento può migliorare l'efficienza dell'addestramento. Tuttavia, l'implementazione della logica di trasformazione al di fuori del modello (gli approcci descritti in Opzione A: BigQuery o Opzione B: Dataflow ) non risolve il problema dell'asimmetria del servizio di formazione. A meno che non si memorizzi la funzionalità progettata nell'archivio funzionalità da utilizzare sia per il training che per la previsione, la logica di trasformazione deve essere implementata da qualche parte per essere applicata ai nuovi punti dati in arrivo per la previsione, poiché l'interfaccia del modello prevede dati trasformati. La libreria TensorFlow Transform ( tf.Transform ) può aiutarti a risolvere questo problema, come descritto nella sezione seguente.

Come funziona tf.Transform

La libreria tf.Transform è utile per le trasformazioni che richiedono un passaggio completo. L'output della libreria tf.Transform viene esportato come grafico TensorFlow che rappresenta la logica di trasformazione a livello di istanza e le statistiche calcolate dalle trasformazioni a passaggio completo, da utilizzare per l'addestramento e la gestione. L'utilizzo dello stesso grafico sia per l'addestramento che per il servizio può evitare distorsioni, poiché in entrambe le fasi vengono applicate le stesse trasformazioni. Inoltre, la libreria tf.Transform può essere eseguita su larga scala in una pipeline di elaborazione batch su Dataflow per preparare i dati di training in anticipo e migliorare l'efficienza della formazione.

Il diagramma seguente, figura 4, mostra come la libreria tf.Transform preelabora e trasforma i dati per il training e la previsione. Il processo è descritto nelle sezioni seguenti.

Trasforma i dati di formazione e valutazione

Preelabori i dati di training non elaborati utilizzando la trasformazione implementata nelle API tf.Transform Apache Beam e la esegui su larga scala su Dataflow. La preelaborazione avviene nelle seguenti fasi:

• Fase di analisi: durante la fase di analisi, le statistiche richieste (come medie, varianze e quantili) per le trasformazioni con stato vengono calcolate sui dati di training con operazioni di passaggio completo. Questa fase produce una serie di artefatti di trasformazione, incluso il grafico transform_fn . Il grafico transform_fn è un grafico TensorFlow che ha la logica di trasformazione come operazioni a livello di istanza. Include le statistiche calcolate nella fase di analisi come costanti.
• Fase di trasformazione: durante la fase di trasformazione, il grafico transform_fn viene applicato ai dati di training grezzi, in cui le statistiche calcolate vengono utilizzate per elaborare i record di dati (ad esempio, per ridimensionare le colonne numeriche) a livello di istanza.

Un approccio in due fasi come questo affronta la sfida della preelaborazione rappresentata dall'esecuzione di trasformazioni full-pass.

Quando i dati di valutazione vengono preelaborati, vengono applicate solo le operazioni a livello di istanza, utilizzando la logica nel grafico transform_fn e le statistiche calcolate dalla fase di analisi nei dati di training. In altre parole, non si analizzano i dati di valutazione in modo completo per calcolare nuove statistiche, come μ e σ, per normalizzare le caratteristiche numeriche nei dati di valutazione. Utilizza invece le statistiche calcolate dai dati di training per trasformare i dati di valutazione a livello di istanza.

I dati di addestramento e valutazione trasformati vengono preparati su larga scala utilizzando Dataflow, prima di essere utilizzati per addestrare il modello. Questo processo di preparazione dei dati batch affronta la sfida della preelaborazione di preparare i dati in anticipo per migliorare l'efficienza della formazione. Come mostrato nella figura 4, l'interfaccia interna del modello prevede funzionalità trasformate.

Allega trasformazioni al modello esportato

Come notato, il grafico transform_fn prodotto dalla pipeline tf.Transform viene archiviato come grafico TensorFlow esportato. Il grafico esportato è costituito dalla logica di trasformazione come operazioni a livello di istanza e da tutte le statistiche calcolate nelle trasformazioni a passaggio completo come costanti del grafico. Quando il modello addestrato viene esportato per l'elaborazione, il grafico transform_fn viene collegato a SavedModel come parte della relativa funzione serving_fn .

Mentre serve il modello per la previsione, l'interfaccia di servizio del modello prevede punti dati nel formato non elaborato (ovvero prima di qualsiasi trasformazione). Tuttavia, l'interfaccia interna del modello prevede che i dati siano nel formato trasformato.

Il grafico transform_fn , che ora fa parte del modello, applica tutta la logica di preelaborazione al punto dati in ingresso. Utilizza le costanti memorizzate (come μ e σ per normalizzare le caratteristiche numeriche) nell'operazione a livello di istanza durante la previsione. Pertanto, il grafico transform_fn converte il punto dati non elaborati nel formato trasformato. Il formato trasformato è quello previsto dall'interfaccia interna del modello per produrre la previsione, come mostrato nella figura 4.

Questo meccanismo risolve la sfida di preelaborazione dell'inclinazione che serve da allenamento, poiché la stessa logica (implementazione) che viene utilizzata per trasformare i dati di formazione e valutazione viene applicata per trasformare i nuovi punti dati durante il servizio di previsione.

Riepilogo delle opzioni di preelaborazione

La tabella seguente riassume le opzioni di preelaborazione dei dati discusse questo documento. Nella tabella, "N/A" sta per "non applicabile".

^* Con Tensorflow, trasformazioni come l'incrocio, l'incorporamento e la codifica a un colpo devono essere eseguite dichiaratamente come colonne feature_columns .

Qual è il prossimo passo?

• Per implementare una pipeline tf.Transform ed eseguirla utilizzando DataFlow, leggi la seconda parte di questa serie, preelaborazione dei dati per ML utilizzando la trasformazione Tensorflow .
• Prendi la specializzazione Coursera su ML con Tensorflow su Google Cloud .
• Scopri le migliori pratiche per l'ingegneria ML nelle regole di ML .
• Per ulteriori architetture di riferimento, diagrammi e migliori pratiche, esplorare le soluzioni cloud TFX .

Questo documento è il primo di una serie in due parti che esplora l'argomento dell'ingegneria dei dati e dell'ingegneria delle caratteristiche per l'apprendimento automatico (ML), con particolare attenzione alle attività di apprendimento supervisionato. Questa prima parte discute le migliori pratiche per la preelaborazione dei dati in una pipeline ML su Google Cloud. Il documento si concentra sull'uso della libreria TensorFlow e Open Source Tensorflow ( tf.Transform ) per preparare i dati, addestrare il modello e servire il modello per la previsione. Questo documento evidenzia le sfide della preelaborazione dei dati per ML e descrive le opzioni e gli scenari per l'esecuzione della trasformazione dei dati su Google Cloud in modo efficace.

Questo documento presuppone che tu abbia familiarità con BigQuery , DataFlow , Vertex AI e Tensorflow Keras API.

Il secondo documento, la preelaborazione dei dati per ML con Google Cloud , fornisce un tutorial passo-passo su come implementare una pipeline tf.Transform .

Introduzione

ML ti aiuta a trovare automaticamente modelli complessi e potenzialmente utili nei dati. Questi modelli sono condensati in un modello ML che può quindi essere utilizzato su nuovi punti dati, un processo chiamato previsioni o eseguire l'inferenza .

Costruire un modello ML è un processo a più fasi. Ogni passaggio presenta le proprie sfide tecniche e concettuali. Questa serie in due parti si concentra su attività di apprendimento supervisionato e sul processo di selezione, trasformazione e aumento dei dati di origine per creare potenti segnali predittivi alla variabile target. Queste operazioni combinano la conoscenza del dominio con le tecniche di scienze dei dati. Le operazioni sono l'essenza dell'ingegneria delle caratteristiche .

La dimensione dei set di dati di addestramento per i modelli ML del mondo reale può essere facilmente uguale o maggiore di un terabyte (TB). Pertanto, sono necessari framework di elaborazione di dati su larga scala per elaborare questi set di dati in modo efficiente e distribuito. Quando si utilizza un modello ML per fare previsioni, è necessario applicare le stesse trasformazioni utilizzate per i dati di allenamento sui nuovi punti dati. Applicando le stesse trasformazioni, si presenta il set di dati live al modello ML nel modo in cui il modello si aspetta.

Questo documento discute queste sfide per diversi livelli di granularità delle operazioni di ingegneria delle funzionalità: aggregazioni a livello di istanza, passaggio completo e finestra temporale. Questo documento descrive anche le opzioni e gli scenari per eseguire la trasformazione dei dati per ML su Google Cloud.

Questo documento fornisce anche una panoramica della trasformazione di Tensorflow ( tf.Transform ), una libreria per Tensorflow che consente di definire la trasformazione dei dati a livello intero e di full passa attraverso pipeline di preelaborazione dei dati. Queste condutture vengono eseguite con Apache Beam e creano artefatti che consentono di applicare le stesse trasformazioni durante la previsione di quando viene servito il modello.

Preprocessing Data per ML

Questa sezione introduce le operazioni di preelaborazione dei dati e le fasi della prontezza dei dati. Discute anche i tipi di operazioni di preelaborazione e la loro granularità.

Ingegneria dei dati rispetto all'ingegneria delle funzionalità

La preelaborazione dei dati per ML coinvolge sia l'ingegneria dei dati che l'ingegneria delle funzionalità. L'ingegneria dei dati è il processo di conversione dei dati grezzi in dati preparati . L'ingegneria delle funzionalità sintonizza quindi i dati preparati per creare le funzionalità previste dal modello ML. Questi termini hanno i seguenti significati:

Dati grezzi (o solo dati )

I dati nella sua forma di origine, senza alcuna preparazione precedente per ML. In questo contesto, i dati potrebbero essere nella sua forma grezza (in un lago dati) o in una forma trasformata (in un data warehouse). I dati trasformati che si trovano in un data warehouse potrebbero essere stati convertiti dalla sua forma grezza originale da utilizzare per l'analisi. Tuttavia, in questo contesto, dati grezzi significa che i dati non sono stati preparati specificamente per l'attività ML. I dati sono anche considerati dati grezzi se vengono inviati da sistemi di streaming che alla fine chiamano modelli ML per le previsioni.

Dati preparati

Il set di dati nel modulo pronto per l'attività ML: le fonti di dati sono state analizzate, unite e messe in una forma tabulare. I dati preparati sono aggregati e riassunti alla giustizia giusta, ad esempio ogni riga nel set di dati rappresenta un cliente unico e ogni colonna rappresenta le informazioni di riepilogo per il cliente, come il totale speso nelle ultime sei settimane. In una tabella di dati preparata, sono state eliminate colonne irrilevanti e sono stati filtrati record non validi. Per le attività di apprendimento supervisionato, è presente la funzione target.

Caratteristiche ingegnerizzate

Il set di dati con le funzionalità sintonizzate che sono previste dal modello, ovvero funzionalità create eseguendo determinate operazioni specifiche per ML sulle colonne nel set di dati preparato e creando nuove funzionalità per il tuo modello durante la formazione e la previsione, come descritto in seguito in Operazioni di preelaborazione . Esempi di queste operazioni includono il ridimensionamento di colonne numeriche a un valore compreso tra 0 e 1, valori di clipping e caratteristiche categoriche a codifica un hot .

Il seguente diagramma, la Figura 1, mostra i passaggi che sono coinvolti nella preparazione dei dati preelaborati:

In pratica, i dati della stessa fonte sono spesso in diverse fasi di prontezza. Ad esempio, un campo da una tabella nel data warehouse potrebbe essere utilizzato direttamente come funzione ingegnerizzata. Allo stesso tempo, un altro campo nella stessa tabella potrebbe dover passare attraverso le trasformazioni prima che diventi una funzione ingegnerizzata. Allo stesso modo, le operazioni di ingegneria dei dati e ingegneria delle funzionalità potrebbero essere combinate nella stessa fase di preelaborazione dei dati.

Operazioni di preelaborazione

La preelaborazione dei dati include diverse operazioni. Ogni operazione è progettata per aiutare ML a costruire modelli predittivi migliori. I dettagli di queste operazioni di preelaborazione sono al di fuori dell'ambito di questo documento, ma alcune operazioni sono brevemente descritte in questa sezione.

Per i dati strutturati, le operazioni di preelaborazione dei dati includono quanto segue:

• Pulizia dei dati: rimozione o correzione dei record che hanno valori danneggiati o non validi dai dati grezzi e rimozione di record che mancano un gran numero di colonne.
• Selezione e partizionamento delle istanze: selezione dei punti dati dal set di dati di input per creare formazione, valutazione (convalida) e set di test . Questo processo include tecniche per il campionamento casuale ripetibile, il sovracampionamento delle classi minoritarie e il partizionamento stratificato.
• Sintesa delle caratteristiche: miglioramento della qualità di una funzione per ML, che include il ridimensionamento e la normalizzazione dei valori numerici, l'imputazione di valori mancanti, i valori anomali e la regolazione dei valori che hanno distribuzioni distorte.
• Trasformazione delle caratteristiche: conversione di una caratteristica numerica in una funzione categorica (tramite bottetizzazione ) e convertire le caratteristiche categoriche in una rappresentazione numerica (tramite codifica una hot, apprendimento con conteggi , incorporamenti di funzionalità sparse, ecc.). Alcuni modelli funzionano solo con funzionalità numeriche o categoriche, mentre altri possono gestire funzionalità di tipo misto. Anche quando i modelli gestiscono entrambi i tipi, possono beneficiare di rappresentazioni diverse (numeriche e categoriche) della stessa caratteristica.
• Estrazione delle caratteristiche: riduzione del numero di funzionalità creando rappresentazioni di dati più potenti a bassa dimensione utilizzando tecniche come PCA , estrazione incorporata e hashing .
• Selezione delle funzionalità: selezione di un sottoinsieme delle funzionalità di input per l'addestramento del modello e ignorando quelli irrilevanti o ridondanti, utilizzando metodi filtro o wrapper . La selezione delle funzionalità può anche comportare una semplice caduta di funzionalità se le funzionalità mancano un gran numero di valori.
• Costruzione di funzionalità: creazione di nuove funzionalità utilizzando tecniche tipiche, come l'espansione polinomiale (utilizzando funzioni matematiche univariate) o incrocio di funzionalità (per acquisire interazioni con le funzionalità). Le funzionalità possono anche essere costruite utilizzando la logica aziendale dal dominio del caso d'uso ML.

Quando si lavora con dati non strutturati (ad esempio, immagini, audio o documenti di testo), Deep Learning sostituisce l'ingegneria di funzionalità basata sulla conoscenza del dominio piegandolo nell'architettura del modello. Un livello convoluzionale è un preprocessore automatico. La costruzione dell'architettura del modello giusta richiede alcune conoscenze empiriche dei dati. Inoltre, è necessaria una certa quantità di preelaborazione, come la seguente:

• Per documenti di testo: steming e lemmatizzazione , calcolo TF-IDF ed estrazione di n-grammi , ricerca incorporata.
• Per le immagini: ritagli, ridimensionamento, ritaglio, sfocatura gaussiana e canarini.
• Per tutti i tipi di dati (inclusi testo e immagini): trasferimento dell'apprendimento , che tratta i livelli tutto-macini del modello completamente addestrato come fase di ingegneria delle caratteristiche.

Granularità di preelaborazione

Questa sezione discute la granularità dei tipi di trasformazioni di dati. Mostra perché questa prospettiva è fondamentale quando si preparano nuovi punti dati per le previsioni utilizzando trasformazioni applicate ai dati di training.

Le operazioni di preelaborazione e trasformazione possono essere classificate come segue, in base alla granularità dell'operazione:

• Trasformazioni a livello di istanza durante la formazione e la previsione . Queste sono trasformazioni semplici, in cui sono necessari solo valori della stessa istanza per la trasformazione. Ad esempio, le trasformazioni a livello di istanza potrebbero includere il ritaglio del valore di una funzione ad una soglia, l'espansione polinomia di un'altra funzionalità, moltiplicando due funzionalità o confrontando due funzionalità per creare una bandiera booleana.

  Queste trasformazioni devono essere applicate in modo identico durante la formazione e la previsione, poiché il modello verrà addestrato sulle caratteristiche trasformate, non sui valori di input grezzo. Se i dati non vengono trasformati in modo identico, il modello si comporta male perché viene presentato con dati che hanno una distribuzione di valori con cui non sono stati addestrati. Per ulteriori informazioni, consultare la discussione sull'incontro con la formazione della formazione nella sezione sfide di preelaborazione .

• Trasformazioni a passaggio completo durante l'addestramento, ma trasformazioni a livello di istanza durante la previsione . In questo scenario, le trasformazioni sono statali, perché usano alcune statistiche precomputate per eseguire la trasformazione. Durante l'allenamento, si analizza l'intero corpo dei dati di allenamento per calcolare quantità come minimo, massimo, medio e varianza per trasformare i dati di allenamento, i dati di valutazione e i nuovi dati al momento della previsione.

  Ad esempio, per normalizzare una caratteristica numerica per l'allenamento, si calcola la sua media (μ) e la sua deviazione standard (σ) su tutti i dati di allenamento. Questo calcolo è chiamato un'operazione passa-passa (o analizza ). Quando si serve il modello per la previsione, il valore di un nuovo punto dati viene normalizzato per evitare l'inclinazione che serve l'allenamento. Pertanto, i valori μ e σ calcolati durante l'allenamento vengono utilizzati per regolare il valore della funzionalità, che è la seguente semplice operazione a livello di istanza :

  $$ value_{scaled} = (value_{raw} - \mu) \div \sigma $$

  Le trasformazioni passa-pass includono quanto segue:

  • Caratteristiche numeriche di ridimensionamento MinMax che utilizzano Min e Max calcolate dal set di dati di addestramento.
  • Caratteristiche numeriche di ridimensionamento standard (Score Z) che utilizzano μ e σ calcolati sul set di dati di addestramento.
  • Caratteristiche numeriche che utilizzano quantili.
  • Imputando valori mancanti usando la mediana (caratteristiche numeriche) o la modalità (caratteristiche categoriche).
  • Conversione di stringhe (valori nominali) in numeri interi (indici) estraendo tutti i valori distinti (vocabolario) di una caratteristica categorica di input.
  • Contare il verificarsi di un termine (valore della caratteristica) in tutti i documenti (istanze) da calcolare per TF-IDF.
  • Calcolo del PCA delle funzionalità di input per proiettare i dati in uno spazio dimensionale inferiore (con caratteristiche linearmente dipendenti).

  È necessario utilizzare solo i dati di allenamento per calcolare statistiche come μ, σ, min e max . Se si aggiungono i dati di test e valutazione per queste operazioni, si perdono informazioni dalla valutazione e dai dati di test per formare il modello. Ciò influisce sull'affidabilità dei risultati del test e della valutazione. Per assicurarsi di applicare una trasformazione coerente a tutti i set di dati, si utilizza le stesse statistiche calcolate dai dati di formazione per trasformare i dati di test e valutazione.

• Aggregazioni storiche durante la formazione e la previsione . Ciò implica la creazione di aggregazioni di business, derivazioni e flag come segnali di input per l'attività di previsione, ad esempio creando metriche di recency, frequenza e monetaria (RFM) per i clienti per creare modelli di propensione. Questi tipi di funzionalità possono essere precomputati e archiviati in un negozio di funzionalità da utilizzare durante la formazione del modello, il punteggio batch e il servizio di previsione online. È inoltre possibile eseguire ulteriori ingegneria delle funzionalità (ad esempio trasformazione e messa a punto) in queste aggregazioni prima della formazione e della previsione.

• Aggregazioni storiche durante la formazione, ma aggregazioni in tempo reale durante la previsione . Questo approccio prevede la creazione di una funzione riassumendo i valori in tempo reale nel tempo. In questo approccio, le istanze da aggregare sono definite attraverso clausole di finestre temporali. Ad esempio, puoi utilizzare questo approccio se si desidera addestrare un modello che stima il tempo di viaggio in taxi in base alle metriche del traffico per il percorso negli ultimi 5 minuti, negli ultimi 10 minuti, negli ultimi 30 minuti e in altri intervalli. È inoltre possibile utilizzare questo approccio per prevedere il fallimento di una parte del motore in base alla media mobile della temperatura e dei valori di vibrazione calcolati negli ultimi 3 minuti. Sebbene queste aggregazioni possano essere preparate offline per la formazione, vengono calcolate in tempo reale da un flusso di dati durante il servizio.

  Più precisamente, quando si prepara i dati di addestramento, se il valore aggregato non è nei dati grezzi, il valore viene creato durante la fase di ingegneria dei dati. I dati grezzi sono generalmente archiviati in un database con un formato di (entity, timestamp, value) . Negli esempi precedenti, entity è l'identificatore del segmento del percorso per le rotte dei taxi e l'identificatore della parte del motore per il guasto del motore. È possibile utilizzare le operazioni di finestre per calcolare (entity, time_index, aggregated_value_over_time_window) e utilizzare le funzionalità di aggregazione come input per la formazione del modello.

  Quando viene servito il modello per la previsione in tempo reale (online), il modello prevede caratteristiche derivate dai valori aggregati come input. Pertanto, è possibile utilizzare una tecnologia di elaborazione del flusso come Apache Beam per calcolare le aggregazioni dai punti dati in tempo reale trasmessi nel sistema. La tecnologia di elaborazione del flusso aggrega i dati in tempo reale in base alle finestre temporali man mano che arrivano nuovi punti dati. È inoltre possibile eseguire ulteriori ingegneria delle funzionalità (ad esempio trasformazione e messa a punto) in queste aggregazioni prima della formazione e della previsione.

Ml Pipeline su Google Cloud

Questa sezione discute i componenti principali di una tipica pipeline end-to-end per formare e servire modelli ML Tensorflow su Google Cloud utilizzando i servizi gestiti. Viene inoltre illustrato dove è possibile implementare diverse categorie di operazioni di pre-elaborazione dei dati e le sfide comuni che potresti incontrare quando implementi tali trasformazioni. La sezione come TF.Transform funziona come la libreria di trasformazione Tensorflow aiuta ad affrontare queste sfide.

Architettura di alto livello

Il seguente diagramma, la Figura 2, mostra un'architettura di alto livello di una tipica pipeline ML per l'addestramento e il servizio di modelli Tensorflow. Le etichette A, B e C nel diagramma si riferiscono ai diversi luoghi della pipeline in cui può avvenire la preelaborazione dei dati. I dettagli su questi passaggi sono forniti nella sezione seguente.

La pipeline è composta dai seguenti passaggi:

1. Dopo l'importazione di dati grezzi, i dati tabulari vengono archiviati in BigQuery e altri dati come immagini, audio e video vengono archiviati in Cloud Storage. La seconda parte di questa serie utilizza i dati tabulari archiviati in BigQuery come esempio.
2. L'ingegneria dei dati (preparazione) e l'ingegneria delle funzionalità vengono eseguite su larga scala utilizzando il flusso di dati. Questa esecuzione produce formazione, valutazione e test pronte per ML memorizzati nella memoria del cloud. Idealmente, questi set di dati sono archiviati come file Tfrecord , che è il formato ottimizzato per i calcoli Tensorflow.
3. Un pacchetto di trainer modello Tensorflow viene inviato alla formazione AI Vertex, che utilizza i dati preelaborati dai passaggi precedenti per formare il modello. L'output di questo passaggio è un Tensorflow addestrato SavedModel che viene esportato in Cloud Storage.
4. Il modello di tensorflow addestrato viene distribuito sulla previsione dell'IA Vertex come servizio che ha un'API REST in modo che possa essere utilizzato per le previsioni online. Lo stesso modello può essere utilizzato anche per i lavori di previsione batch.
5. Dopo che il modello è stato distribuito come API REST, le app client e i sistemi interni possono invocare l'API inviando richieste con alcuni punti dati e ricevendo risposte dal modello con previsioni.
6. Per orchestrare e automatizzare questa pipeline, è possibile utilizzare pipeline di AI Vertex come scheduler per invocare la preparazione dei dati, la formazione del modello e le fasi di distribuzione dei modelli.

È inoltre possibile utilizzare le funzionalità di vertice AI per archiviare le funzionalità di input per fare previsioni. Ad esempio, è possibile creare periodicamente funzionalità ingegnerizzate dagli ultimi dati grezzi e memorizzarli nel negozio di funzionalità Vertex AI. Le app client recuperano le funzionalità di input richieste da Vertex AI Feature Store e inviale al modello per ricevere previsioni.

Dove fare preelaborazione

Nella Figura 2, le etichette A, B e C mostrano che le operazioni di preelaborazione dei dati possono avvenire in BigQuery, DataFlow o Tensorflow. Le seguenti sezioni descrivono come funzionano ciascuna di queste opzioni.

Opzione A: BigQuery

In genere, la logica è implementata in BigQuery per le seguenti operazioni:

• Campionamento: selezione casuale di un sottoinsieme dai dati.
• Filtro: rimozione di istanze irrilevanti o non valide.
• Partizionamento: dividere i dati per produrre set di formazione, valutazione e test.

Gli script SQL di BigQuery possono essere utilizzati come query di origine per la pipeline di preelaborazione del flusso di dati, che è la fase di elaborazione dei dati nella Figura 2. Ad esempio, se un sistema viene utilizzato in Canada e il data warehouse ha transazioni da tutto il mondo, filtrando a Ottieni i dati di formazione solo in Canada è meglio eseguito in BigQuery. L'ingegneria di funzionalità in BigQuery è semplice e scalabile e supporta l'implementazione di aggregazioni a livello di istanza e storiche.

Tuttavia, ti consigliamo di utilizzare BigQuery per l'ingegneria delle funzionalità solo se si utilizza il modello per la previsione di batch (punteggio) o se le funzionalità sono precompitate in bigQuery, ma memorizzate nel negozio di funzionalità Vertex AI da utilizzare durante la previsione online. Se si prevede di distribuire il modello per le previsioni online e se non si dispone della funzione ingegnerizzata in un negozio di funzionalità online, è necessario replicare le operazioni di preelaborazione SQL per trasformare i punti dati grezzi che altri sistemi generano. In altre parole, è necessario implementare due volte la logica: una volta in SQL per preelaborare i dati di formazione in BigQuery e una seconda volta nella logica dell'app che consuma il modello per preelaborare i punti dati online per la previsione.

Ad esempio, se l'app client è scritta in Java, è necessario reimplementare la logica in Java. Ciò può introdurre errori a causa di discrepanze di implementazione, come descritto nella sezione di disgustazione alle forze delle sfide di preelaborazione più avanti in questo documento. È anche un sovraccarico extra mantenere due diverse implementazioni. Ogni volta che si modifica la logica in SQL per preelaborare i dati di training, è necessario modificare di conseguenza l'implementazione Java per preelaborare i dati al momento dell'elaborazione.

Se stai utilizzando il tuo modello solo per la previsione batch (ad esempio, utilizzando la previsione batch di AI Vertex) e se i tuoi dati per il punteggio provengono da BigQuery, è possibile implementare queste operazioni di preelaborazione come parte dello script SQL di BigQuery. In tal caso, è possibile utilizzare lo stesso script SQL di preelaborazione per preparare sia i dati di addestramento che di punteggio.

Le trasformazioni statali passa-pass non sono adatte all'implementazione in BigQuery. Se usi BigQuery per le trasformazioni passa-pass, sono necessarie tabelle ausiliarie per archiviare le quantità necessarie per trasformazioni statali, come mezzi e varianze per ridimensionare le caratteristiche numeriche. Inoltre, l'implementazione di trasformazioni passa-pass che utilizzano SQL su BigQuery crea una maggiore complessità negli script SQL e crea una complessa dipendenza tra l'allenamento e gli script SQL di punteggio.

Opzione B: flusso di dati

Come mostrato nella Figura 2, è possibile implementare operazioni di preelaborazione computazionalmente costose in Apache Beam ed eseguirle su larga scala utilizzando il flusso di dati. DataFlow è un servizio di automatica automatico completamente gestito per l'elaborazione dei dati batch e streaming. Quando si utilizza il flusso di dati, è anche possibile utilizzare librerie specializzate esterne per l'elaborazione dei dati, a differenza di BigQuery.

DataFlow può eseguire trasformazioni a livello di istanza e trasformazioni storiche e di aggregazione in tempo reale. In particolare, se i modelli ML si aspettano una funzione di input come total_number_of_clicks_last_90sec , le funzioni di finestra di Apache Beam possono calcolare queste funzionalità in base all'aggregazione dei valori delle finestre temporali dei dati degli eventi in tempo reale (streaming) (ad esempio, fare clic su eventi). Nella precedente discussione sulla granularità delle trasformazioni , questo è stato definito "aggregazioni storiche durante la formazione, ma aggregazioni in tempo reale durante la previsione".

Il diagramma seguente, la Figura 3, mostra il ruolo del flusso di dati nell'elaborazione dei dati del flusso per previsioni quasi in tempo reale.

Come mostrato nella Figura 3, durante l'elaborazione, gli eventi chiamati punti dati vengono ingeriti in pub/sub . DataFlow consuma questi punti dati, calcola le funzionalità in base agli aggregati nel tempo e quindi chiama l'API del modello ML distribuita per le previsioni. Le previsioni vengono quindi inviate a un pub/sotto coda in uscita. Da pub/sub, le previsioni possono essere consumate da sistemi a valle come il monitoraggio o il controllo, oppure possono essere respinte (ad esempio, come notifiche) al cliente richiesto originale. Le previsioni possono anche essere archiviate in un archivio di dati a bassa latenza come Cloud BigTable per il recupero in tempo reale. Cloud BigTable può anche essere usato per accumulare e archiviare queste aggregazioni in tempo reale in modo che possano essere cercate quando necessario per la previsione.

La stessa implementazione del raggio di Apache può essere utilizzata per i dati di formazione in batch-process che provengono da un dataStore offline come BigQuery e dati in tempo reale del processo di streaming per servire le previsioni online.

In altre architetture tipiche, come l'architettura mostrata nella Figura 2, l'app client chiama direttamente l'API del modello distribuito per le previsioni online. In tal caso, se le operazioni di preelaborazione sono implementate nel flusso di dati per preparare i dati di formazione, le operazioni non vengono applicate ai dati di previsione che vanno direttamente al modello. Pertanto, trasformazioni come queste dovrebbero essere integrate nel modello durante il servizio di previsioni online.

Il flusso di dati può essere utilizzato per eseguire la trasformazione passa-pass, calcolando le statistiche richieste su scala. Tuttavia, queste statistiche devono essere archiviate da qualche parte da utilizzare durante la previsione per trasformare i punti dati di previsione. Usando la libreria Tensorflow Transform ( tf.Transform ), è possibile incorporare direttamente queste statistiche nel modello invece di memorizzarle altrove. Questo approccio è spiegato più avanti in come funziona TF.Transform .

Opzione C: Tensorflow

Come mostrato nella Figura 2, è possibile implementare le operazioni di preelaborazione e trasformazione dei dati nel modello Tensorflow stesso. Come mostrato nella figura, la preelaborazione che si implementa per la formazione del modello Tensorflow diventa parte integrante del modello quando il modello viene esportato e distribuito per le previsioni. Le trasformazioni nel modello Tensorflow possono essere realizzate in uno dei seguenti modi:

• Implementazione di tutta la logica di trasformazione a livello di istanza nella funzione input_fn e nella funzione serving_fn . La funzione input_fn prepara un set di dati utilizzando l' API tf.data.Dataset per la formazione di un modello. La funzione serving_fn riceve e prepara i dati per le previsioni.
• Mettere il codice di trasformazione direttamente nel modello TensorFlow utilizzando i livelli di preelaborazione di Keras o creando livelli personalizzati .

Il codice logico di trasformazione nella funzione serving_fn definisce l'interfaccia di servizio del tuo moto salvato per la previsione online. Se si implementano le stesse trasformazioni utilizzate per la preparazione dei dati di addestramento nel codice logico della trasformazione della funzione serving_fn , assicura che le stesse trasformazioni vengano applicate a nuovi punti dati di previsione quando vengono serviti.

Tuttavia, poiché il modello Tensorflow elabora ciascun punto dati in modo indipendente o in un piccolo batch, non è possibile calcolare le aggregazioni da tutti i punti dati. Di conseguenza, le trasformazioni passa-pass non possono essere implementate nel modello Tensorflow.

Sfide di preelaborazione

Le seguenti sono le principali sfide dell'implementazione della preelaborazione dei dati:

• Inclinazione allenatore . L'incendio che serve da allenamento si riferisce a una differenza tra efficacia (prestazioni predittive) durante la formazione e durante il servizio. Questa inclinazione può essere causata da una discrepanza tra il modo in cui si gestiscono i dati nella formazione e nelle condutture. Ad esempio, se il tuo modello è addestrato su una funzione trasformata logaritmicamente, ma viene presentata con la funzione RAW durante la porzione, l'output di previsione potrebbe non essere accurato.

  Se le trasformazioni diventano parte del modello stesso, può essere semplice gestire le trasformazioni a livello di istanza, come descritto in precedenza nell'opzione C: Tensorflow . In tal caso, l'interfaccia che serve modello (la funzione serving_fn ) si aspetta dati grezzi, mentre il modello trasforma internamente questi dati prima di calcolare l'output. Le trasformazioni sono le stesse di quelle che sono state applicate sui punti dati di addestramento e di previsione grezzi.

• Trasformazioni passa-passa . Non è possibile implementare trasformazioni passa-pass come trasformazioni di ridimensionamento e normalizzazione nel modello Tensorflow. Nelle trasformazioni passa-pass, alcune statistiche (ad esempio, i valori max e min per ridimensionare le funzionalità numeriche) devono essere calcolate in anticipo sui dati di addestramento, come descritto nell'opzione B: flusso di dati . I valori devono quindi essere archiviati da qualche parte da utilizzare durante la previsione del modello per trasformare i nuovi punti di dati grezzi come trasformazioni a livello di istanza, che evitano l'albero dell'allenamento. È possibile utilizzare la libreria Tensorflow Transform ( tf.Transform ) per incorporare direttamente le statistiche nel modello Tensorflow. Questo approccio è spiegato più avanti in come funziona TF.Transform .

• Preparare i dati in anticipo per una migliore efficienza di allenamento . L'implementazione di trasformazioni a livello di istanza nell'ambito del modello può degradare l'efficienza del processo di formazione. Questo degrado si verifica perché le stesse trasformazioni vengono ripetutamente applicate agli stessi dati di addestramento su ogni epoca. Immagina di avere dati di formazione grezzi con 1.000 funzionalità e applichi un mix di trasformazioni a livello di istanza per generare 10.000 funzioni. Se si implementano queste trasformazioni come parte del tuo modello e se si alimenta il modello i dati di allenamento grezzo, queste 10.000 operazioni vengono applicate n volte su ogni istanza, dove n è il numero di epoche. Inoltre, se utilizzi acceleratori (GPU o TPU), rimangono inattivi mentre la CPU esegue tali trasformazioni, il che non costituisce un uso efficiente dei tuoi costosi acceleratori.

  Idealmente, i dati di formazione vengono trasformati prima dell'allenamento, utilizzando la tecnica descritta nell'opzione B: flusso di dati , in cui le 10.000 operazioni di trasformazione vengono applicate una sola volta su ogni istanza di formazione. I dati di formazione trasformati vengono quindi presentati al modello. Non vengono applicate ulteriori trasformazioni e gli acceleratori sono sempre occupati. Inoltre, l'utilizzo del flusso di dati ti aiuta a preelaborare grandi quantità di dati su larga scala, utilizzando un servizio completamente gestito.

  La preparazione dei dati di allenamento in anticipo può migliorare l'efficienza dell'allenamento. Tuttavia, l'implementazione della logica di trasformazione al di fuori del modello (gli approcci descritti nell'opzione A: BigQuery o Option B: DataFlow ) non risolve il problema dell'albero di allenamento. A meno che non si memorizzi la funzione ingegnerizzata nel negozio di funzionalità da utilizzare sia per la formazione che per la previsione, la logica di trasformazione deve essere implementata da qualche parte da applicare su nuovi punti dati in arrivo per la previsione, poiché l'interfaccia del modello prevede dati trasformati. La libreria TensorFlow Transform ( tf.Transform ) può aiutarti ad affrontare questo problema, come descritto nella sezione seguente.

Come funziona TF.Transform

La libreria tf.Transform è utile per le trasformazioni che richiedono un passaggio completo. The output of the tf.Transform library is exported as a TensorFlow graph that represents the instance-level transformation logic and the statistics computed from full-pass transformations, to be used for training and serving. Using the same graph for both training and serving can prevent skew, because the same transformations are applied in both stages. In addition, the tf.Transform library can run at scale in a batch processing pipeline on Dataflow to prepare the training data up front and improve training efficiency.

The following diagram, figure 4, shows how the tf.Transform library preprocesses and transforms data for training and prediction. The process is described in the following sections.

Transform training and evaluation data

You preprocess the raw training data using the transformation implemented in the tf.Transform Apache Beam APIs, and run it at scale on Dataflow. The preprocessing occurs in the following phases:

• Analyze phase: During the analyze phase, the required statistics (like means, variances, and quantiles) for stateful transformations are computed on the training data with full-pass operations. This phase produces a set of transformation artifacts, including the transform_fn graph. The transform_fn graph is a TensorFlow graph that has the transformation logic as instance-level operations. It includes the statistics computed in the analyze phase as constants.
• Transform phase: During the transform phase, the transform_fn graph is applied to the raw training data, where the computed statistics are used to process the data records (for example, to scale numerical columns) in an instance-level fashion.

A two-phase approach like this addresses the preprocessing challenge of performing full-pass transformations.

When the evaluation data is preprocessed, only instance-level operations are applied, using the logic in the transform_fn graph and the statistics computed from the analyze phase in the training data. In other words, you don't analyze the evaluation data in a full-pass fashion to compute new statistics, such as μ and σ, to normalize numeric features in evaluation data. Instead, you use the computed statistics from the training data to transform the evaluation data in an instance-level fashion.

The transformed training and evaluation data are prepared at scale using Dataflow, before they are used to train the model. This batch data-preparation process addresses the preprocessing challenge of preparing the data up front to improve training efficiency. As shown in figure 4, the model internal interface expects transformed features.

Attach transformations to the exported model

As noted, the transform_fn graph that's produced by the tf.Transform pipeline is stored as an exported TensorFlow graph. The exported graph consists of the transformation logic as instance-level operations, and all of the statistics computed in the full-pass transformations as graph constants. When the trained model is exported for serving, the transform_fn graph is attached to the SavedModel as part of its serving_fn function.

While it's serving the model for prediction, the model serving interface expects data points in the raw format (that is, before any transformations). However, the model internal interface expects the data in the transformed format.

The transform_fn graph, which is now part of the model, applies all the preprocessing logic on the incoming data point. It uses the stored constants (like μ and σ to normalize the numeric features) in the instance-level operation during prediction. Therefore, the transform_fn graph converts the raw data point into the transformed format. The transformed format is what is expected by the model internal interface in order to produce prediction, as shown in figure 4.

This mechanism resolves the preprocessing challenge of the training-serving skew, because the same logic (implementation) that is used to transform the training and evaluation data is applied to transform the new data points during prediction serving.

Preprocessing options summary

The following table summarizes the data preprocessing options that this document discussed. In the table, "N/A" stands for "not applicable."

^* With TensorFlow, transformations like crossing, embedding, and one-hot encoding should be performed declaratively as feature_columns columns.

Qual è il prossimo passo?

• To implement a tf.Transform pipeline and run it using Dataflow, read part two of this series, Data preprocessing for ML using TensorFlow Transform .
• Take the Coursera specialization on ML with TensorFlow on Google Cloud .
• Learn about best practices for ML engineering in Rules of ML .
• For more reference architectures, diagrams, and best practices, explore the TFX Cloud Solutions .

This document is the first in a two-part series that explores the topic of data engineering and feature engineering for machine learning (ML), with a focus on supervised learning tasks. This first part discusses the best practices for preprocessing data in an ML pipeline on Google Cloud. The document focuses on using TensorFlow and the open source TensorFlow Transform ( tf.Transform ) library to prepare data, train the model, and serve the model for prediction. This document highlights the challenges of preprocessing data for ML, and it describes the options and scenarios for performing data transformation on Google Cloud effectively.

This document assumes that you're familiar with BigQuery , Dataflow , Vertex AI , and the TensorFlow Keras API.

The second document, Data preprocessing for ML with Google Cloud , provides a step-by-step tutorial for how to implement a tf.Transform pipeline.

Introduzione

ML helps you automatically find complex and potentially useful patterns in data. These patterns are condensed in an ML model that can then be used on new data points—a process called making predictions or performing inference .

Building an ML model is a multistep process. Each step presents its own technical and conceptual challenges. This two-part series focuses on supervised learning tasks and the process of selecting, transforming, and augmenting the source data to create powerful predictive signals to the target variable. These operations combine domain knowledge with data science techniques. The operations are the essence of feature engineering .

The size of training datasets for real-world ML models can easily be equal to or greater than one terabyte (TB). Therefore, you need large-scale data processing frameworks in order to process these datasets efficiently and distributedly. When you use an ML model to make predictions, you have to apply the same transformations that you used for the training data on the new data points. By applying the same transformations, you present the live dataset to the ML model the way that the model expects.

Questo documento discute queste sfide per diversi livelli di granularità delle operazioni di ingegneria delle funzionalità: aggregazioni a livello di istanza, passaggio completo e finestra temporale. This document also describes the options and scenarios to perform data transformation for ML on Google Cloud.

This document also provides an overview of TensorFlow Transform ( tf.Transform ), a library for TensorFlow that lets you define both instance-level and full-pass data transformation through data preprocessing pipelines. These pipelines are executed with Apache Beam , and they create artifacts that let you apply the same transformations during prediction as when the model is served.

Preprocessing data for ML

This section introduces data preprocessing operations and stages of data readiness. It also discusses the types of the preprocessing operations and their granularity.

Data engineering compared to feature engineering

Preprocessing the data for ML involves both data engineering and feature engineering. Data engineering is the process of converting raw data into prepared data . Feature engineering then tunes the prepared data to create the features that are expected by the ML model. These terms have the following meanings:

Raw data (or just data )

The data in its source form, without any prior preparation for ML. In this context, the data might be in its raw form (in a data lake) or in a transformed form (in a data warehouse). Transformed data that's in a data warehouse might have been converted from its original raw form to be used for analytics. However, in this context, raw data means that the data hasn't been prepared specifically for your ML task. Data is also considered raw data if it's sent from streaming systems that eventually call ML models for predictions.

Prepared data

The dataset in the form ready for your ML task: data sources have been parsed, joined, and put into a tabular form. Prepared data is aggregated and summarized to the right granularity—for example, each row in the dataset represents a unique customer, and each column represents summary information for the customer, like the total spent in the last six weeks. In a prepared data table, irrelevant columns have been dropped, and invalid records have been filtered out. For supervised learning tasks, the target feature is present.

Engineered features

The dataset with the tuned features that are expected by the model—that is, features that are created by performing certain ML-specific operations on the columns in the prepared dataset, and creating new features for your model during training and prediction, as described later in Operazioni di preelaborazione . Examples of these operations include scaling numerical columns to a value between 0 and 1, clipping values, and one-hot-encoding categorical features.

The following diagram, figure 1, shows the steps that are involved in preparing preprocessed data:

In practice, data from the same source is often at different stages of readiness. For example, a field from a table in your data warehouse might be used directly as an engineered feature. At the same time, another field in the same table might need to go through transformations before it becomes an engineered feature. Similarly, data engineering and feature engineering operations might be combined in the same data preprocessing step.

Preprocessing operations

Data preprocessing includes several operations. Each operation is designed to help ML build better predictive models. The details of these preprocessing operations are outside the scope of this document, but some operations are briefly described in this section.

For structured data, data preprocessing operations include the following:

• Data cleansing: removing or correcting records that have corrupted or invalid values from raw data, and removing records that are missing a large number of columns.
• Instances selection and partitioning: selecting data points from the input dataset to create training, evaluation (validation), and test sets . Questo processo include tecniche per il campionamento casuale ripetibile, il sovracampionamento delle classi minoritarie e il partizionamento stratificato.
• Feature tuning: improving the quality of a feature for ML, which includes scaling and normalizing numeric values, imputing missing values, clipping outliers, and adjusting values that have skewed distributions.
• Feature transformation: converting a numeric feature to a categorical feature (through bucketization ), and converting categorical features to a numeric representation (through one-hot encoding, learning with counts , sparse feature embeddings, etc.). Some models work only with numeric or categorical features, while others can handle mixed type features. Even when models handle both types, they can benefit from different representations (numeric and categorical) of the same feature.
• Feature extraction: reducing the number of features by creating lower-dimension, more powerful data representations using techniques such as PCA , embedding extraction, and hashing .
• Feature selection: selecting a subset of the input features for training the model, and ignoring the irrelevant or redundant ones, using filter or wrapper methods . Feature selection can also involve simply dropping features if the features are missing a large number of values.
• Feature construction: creating new features by using typical techniques, such as polynomial expansion (by using univariate mathematical functions) or feature crossing (to capture feature interactions). Features can also be constructed by using business logic from the domain of the ML use case.

When you work with unstructured data (for example, images, audio, or text documents), deep learning replaces domain-knowledge-based feature engineering by folding it into the model architecture. A convolutional layer is an automatic feature preprocessor. Constructing the right model architecture requires some empirical knowledge of the data. In addition, some amount of preprocessing is needed, such as the following:

• For text documents: stemming and lemmatization , TF-IDF calculation, and n-gram extraction, embedding lookup.
• For images: clipping, resizing, cropping, Gaussian blur, and canary filters.
• For all types of data (including text and images): transfer learning , which treats all-but-last layers of the fully trained model as a feature engineering step.

Preprocessing granularity

This section discusses the granularity of types of data transformations. Mostra perché questa prospettiva è fondamentale quando si preparano nuovi punti dati per le previsioni utilizzando trasformazioni applicate ai dati di training.

Preprocessing and transformation operations can be categorized as follows, based on operation granularity:

• Instance-level transformations during training and prediction . These are straightforward transformations, where only values from the same instance are needed for the transformation. For example, instance-level transformations might include clipping the value of a feature to some threshold, polynomially expanding another feature, multiplying two features, or comparing two features to create a Boolean flag.

  These transformations must be applied identically during training and prediction, because the model will be trained on the transformed features, not on the raw input values. If the data isn't transformed identically, then the model behaves poorly because it is presented with data that has a distribution of values that it wasn't trained with. For more information, see the discussion of training-serving skew in the Preprocessing challenges section.

• Trasformazioni a passaggio completo durante l'addestramento, ma trasformazioni a livello di istanza durante la previsione . In this scenario, transformations are stateful, because they use some precomputed statistics to perform the transformation. During training, you analyze the whole body of training data to compute quantities such as minimum, maximum, mean, and variance for transforming training data, evaluation data, and new data at prediction time.

  For example, to normalize a numeric feature for training, you compute its mean (μ) and its standard deviation (σ) across the whole of the training data. This computation is called a full-pass (or analyze ) operation. When you serve the model for prediction, the value of a new data point is normalized to avoid training-serving skew. Therefore, μ and σ values that are computed during training are used to adjust the feature value, which is the following simple instance-level operation:

  $$ value_{scaled} = (value_{raw} - \mu) \div \sigma $$

  Full-pass transformations include the following:

  • MinMax scaling numerical features using min and max computed from the training dataset.
  • Standard scaling (z-score normalization) numerical features using μ and σ computed on the training dataset.
  • Bucketizing numerical features using quantiles.
  • Imputing missing values using the median (numerical features) or the mode (categorical features).
  • Conversione di stringhe (valori nominali) in numeri interi (indici) estraendo tutti i valori distinti (vocabolario) di una caratteristica categorica di input.
  • Counting the occurrence of a term (feature value) in all the documents (instances) to calculate for TF-IDF.
  • Computing the PCA of the input features to project the data into a lower dimensional space (with linearly dependent features).

  You should use only the training data to compute statistics like μ, σ, min , and max . If you add the test and evaluation data for these operations, you are leaking information from the evaluation and test data to train the model. Doing so affects the reliability of the test and evaluation results. To ensure that you apply a consistent transformation to all datasets, you use the same statistics computed from the training data to transform the test and evaluation data.

• Historical aggregations during training and prediction . This involves creating business aggregations, derivations, and flags as input signals to the prediction task—for example, creating recency, frequency, and monetary (RFM) metrics for customers to build propensity models. These types of features can be precomputed and stored in a feature store to be used during model training, batch scoring, and online prediction serving. You can also perform additional feature engineering (for example, transformation and tuning) to these aggregations before training and prediction.

• Historical aggregations during training, but real-time aggregations during prediction . This approach involves creating a feature by summarizing real-time values over time. In this approach, the instances to be aggregated are defined through temporal window clauses. For example, you can use this approach if you want to train a model that estimates the taxi trip time based on the traffic metrics for the route in the last 5 minutes, in the last 10 minutes, in the last 30 minutes, and at other intervals. You can also use this approach to predict the failure of an engine part based on the moving average of temperature and vibration values computed over the last 3 minutes. Although these aggregations can be prepared offline for training, they are computed in real time from a data stream during serving.

  More precisely, when you prepare training data, if the aggregated value isn't in the raw data, the value is created during the data engineering phase. The raw data is usually stored in a database with a format of (entity, timestamp, value) . In the previous examples, entity is the route segment identifier for the taxi routes and the engine part identifier for the engine failure. You can use windowing operations to compute (entity, time_index, aggregated_value_over_time_window) and use the aggregation features as an input for your model training.

  When the model for real-time (online) prediction is served, the model expects features derived from the aggregated values as an input. Therefore, you can use a stream-processing technology like Apache Beam to compute the aggregations from the real-time data points streamed into your system. Stream-processing technology aggregates real-time data based on time windows as new data points arrive. You can also perform additional feature engineering (for example, transformation and tuning) to these aggregations before training and prediction.

ML pipeline on Google Cloud

This section discusses the core components of a typical end-to-end pipeline to train and serve TensorFlow ML models on Google Cloud using managed services. Viene inoltre illustrato dove è possibile implementare diverse categorie di operazioni di pre-elaborazione dei dati e le sfide comuni che potresti incontrare quando implementi tali trasformazioni. The How tf.Transform works section shows how the TensorFlow Transform library helps to address these challenges.

High-level architecture

The following diagram, figure 2, shows a high-level architecture of a typical ML pipeline for training and serving TensorFlow models. The labels A, B, and C in the diagram refer to the different places in the pipeline where data preprocessing can take place. Details about these steps are provided in the following section.

La pipeline è composta dai seguenti passaggi:

1. After raw data is imported, tabular data is stored in BigQuery, and other data like images, audio, and video, is stored in Cloud Storage. The second part of this series uses tabular data stored in BigQuery as an example.
2. Data engineering (preparation) and feature engineering are executed at scale using Dataflow. This execution produces ML-ready training, evaluation, and test sets that are stored in Cloud Storage. Ideally, these datasets are stored as TFRecord files, which is the optimized format for TensorFlow computations.
3. A TensorFlow model trainer package is submitted to Vertex AI Training, which uses the preprocessed data from the previous steps to train the model. The output of this step is a trained TensorFlow SavedModel that is exported to Cloud Storage.
4. The trained TensorFlow model is deployed to Vertex AI Prediction as a service that has a REST API so that it can be used for online predictions. The same model can also be used for batch prediction jobs.
5. After the model is deployed as a REST API, client apps and internal systems can invoke the API by sending requests with some data points, and receiving responses from the model with predictions.
6. For orchestrating and automating this pipeline, you can use Vertex AI Pipelines as a scheduler to invoke the data preparation, model training, and model deployment steps.

You can also use Vertex AI Feature Store to store input features to make predictions. For example, you can periodically create engineered features from the latest raw data and store them in Vertex AI Feature Store. Client apps fetch the required input features from Vertex AI Feature Store and send them to the model to receive predictions.

Where to do preprocessing

In figure 2, the labels A, B, and C show that data preprocessing operations can take place in BigQuery, Dataflow, or TensorFlow. The following sections describe how each of these options work.

Option A: BigQuery

Typically, logic is implemented in BigQuery for the following operations:

• Sampling: randomly selecting a subset from the data.
• Filtering: removing irrelevant or invalid instances.
• Partitioning: splitting the data to produce training, evaluation, and test sets.

BigQuery SQL scripts can be used as a source query for the Dataflow preprocessing pipeline, which is the data processing step in figure 2. For example, if a system is used in Canada, and the data warehouse has transactions from around the world, filtering to get Canada-only training data is best done in BigQuery. Feature engineering in BigQuery is simple and scalable, and supports implementing instance-level and historical aggregations feature transformations.

However, we recommend that you use BigQuery for feature engineering only if you use your model for batch prediction (scoring), or if the features are precomputed in BigQuery, but stored in Vertex AI Feature Store to be used during online prediction. If you plan to deploy the model for online predictions, and if you don't have the engineered feature in an online feature store, you have to replicate the SQL preprocessing operations to transform the raw data points that other systems generate. In other words, you need to implement the logic twice: one time in SQL to preprocess training data in BigQuery, and a second time in the logic of the app that consumes the model to preprocess online data points for prediction.

For example, if your client app is written in Java, you need to reimplement the logic in Java. This can introduce errors due to implementation discrepancies, as described in the training-serving skew section of Preprocessing challenges later in this document. It's also extra overhead to maintain two different implementations. Ogni volta che si modifica la logica in SQL per preelaborare i dati di training, è necessario modificare di conseguenza l'implementazione Java per preelaborare i dati al momento dell'elaborazione.

If you are using your model only for batch prediction (for example, using Vertex AI batch prediction ), and if your data for scoring is sourced from BigQuery, you can implement these preprocessing operations as part of the BigQuery SQL script. In that case, you can use the same preprocessing SQL script to prepare both training and scoring data.

Full-pass stateful transformations aren't suitable for implementation in BigQuery. If you use BigQuery for full-pass transformations, you need auxiliary tables to store quantities needed by stateful transformations, such as means and variances to scale numerical features. Further, implementation of full-pass transformations using SQL on BigQuery creates increased complexity in the SQL scripts, and creates intricate dependency between training and the scoring SQL scripts.

Option B: Dataflow

As shown in figure 2, you can implement computationally expensive preprocessing operations in Apache Beam, and run them at scale using Dataflow. Dataflow is a fully managed autoscaling service for batch and stream data processing. When you use Dataflow, you can also use external specialized libraries for data processing, unlike BigQuery.

Dataflow can perform instance-level transformations, and historical and real-time aggregation feature transformations. In particular, if your ML models expect an input feature like total_number_of_clicks_last_90sec , Apache Beam windowing functions can compute these features based on aggregating the values of time windows of real-time (streaming) events data (for example, click events). In the earlier discussion of granularity of transformations , this was referred to as "Historical aggregations during training, but real-time aggregations during prediction."

The following diagram, figure 3, shows the role of Dataflow in processing stream data for near real-time predictions.

As shown in figure 3, during processing, events called data points are ingested into Pub/Sub . Dataflow consumes these data points, computes features based on aggregates over time, and then calls the deployed ML model API for predictions. Predictions are then sent to an outbound Pub/Sub queue. From Pub/Sub, predictions can be consumed by downstream systems like monitoring or control, or they can be pushed back (for example, as notifications) to the original requesting client. Predictions can also be stored in a low-latency data store like Cloud Bigtable for real-time fetching. Cloud Bigtable can also be used to accumulate and store these real-time aggregations so they can be looked up when needed for prediction.

The same Apache Beam implementation can be used to batch-process training data that comes from an offline datastore like BigQuery and stream-process real-time data for serving online predictions.

In other typical architectures, such as the architecture shown in figure 2, the client app directly calls the deployed model API for online predictions. In that case, if preprocessing operations are implemented in Dataflow to prepare the training data, the operations aren't applied to the prediction data that goes directly to the model. Therefore, transformations like these should be integrated in the model during serving for online predictions.

Dataflow can be used to perform full-pass transformation, by computing the required statistics at scale. However, these statistics need to be stored somewhere to be used during prediction to transform prediction data points. By using the TensorFlow Transform ( tf.Transform ) library, you can directly embed these statistics in the model instead of storing them elsewhere. This approach is explained later in How tf.Transform works .

Option C: TensorFlow

As shown in figure 2, you can implement data preprocessing and transformation operations in the TensorFlow model itself. As shown in the figure, the preprocessing that you implement for training the TensorFlow model becomes an integral part of the model when the model is exported and deployed for predictions. Transformations in the TensorFlow model can be accomplished in one of the following ways:

• Implementing all of the instance-level transformation logic in the input_fn function and in the serving_fn function. The input_fn function prepares a dataset using the tf.data.Dataset API for training a model. The serving_fn function receives and prepares the data for predictions.
• Putting the transformation code directly in your TensorFlow model by using Keras preprocessing layers or creating custom layers .

The transformation logic code in the serving_fn function defines the serving interface of your SavedModel for online prediction. If you implement the same transformations that were used for preparing training data in the transformation logic code of the serving_fn function, it ensures that the same transformations are applied to new prediction data points when they're served.

However, because the TensorFlow model processes each data point independently or in a small batch, you can't calculate aggregations from all data points. As a result, full-pass transformations can't be implemented in your TensorFlow model.

Preprocessing challenges

The following are the primary challenges of implementing data preprocessing:

• Training-serving skew . Training-serving skew refers to a difference between effectiveness (predictive performance) during training and during serving. This skew can be caused by a discrepancy between how you handle data in the training and the serving pipelines. For example, if your model is trained on a logarithmically transformed feature, but it's presented with the raw feature during serving, the prediction output might not be accurate.

  If the transformations become part of the model itself, it can be straightforward to handle instance-level transformations, as described earlier in Option C: TensorFlow . In that case, the model serving interface (the serving_fn function) expects raw data, while the model internally transforms this data before computing the output. The transformations are the same as those that were applied on the raw training and prediction data points.

• Full-pass transformations . You can't implement full-pass transformations such as scaling and normalization transformations in your TensorFlow model. In full-pass transformations, some statistics (for example, max and min values to scale numeric features) must be computed on the training data beforehand, as described in Option B: Dataflow . The values then have to be stored somewhere to be used during model serving for prediction to transform the new raw data points as instance-level transformations, which avoids training-serving skew. You can use the TensorFlow Transform ( tf.Transform ) library to directly embed the statistics in your TensorFlow model. This approach is explained later in How tf.Transform works .

• Preparing the data up front for better training efficiency . Implementing instance-level transformations as part of the model can degrade the efficiency of the training process. This degradation occurs because the same transformations are repeatedly applied to the same training data on each epoch. Imagine that you have raw training data with 1,000 features, and you apply a mix of instance-level transformations to generate 10,000 features. If you implement these transformations as part of your model, and if you then feed the model the raw training data, these 10,000 operations are applied N times on each instance, where N is the number of epochs. Inoltre, se utilizzi acceleratori (GPU o TPU), rimangono inattivi mentre la CPU esegue tali trasformazioni, il che non costituisce un uso efficiente dei tuoi costosi acceleratori.

  Ideally, the training data is transformed before training, using the technique described under Option B: Dataflow , where the 10,000 transformation operations are applied only once on each training instance. The transformed training data is then presented to the model. No further transformations are applied, and the accelerators are busy all of the time. In addition, using Dataflow helps you to preprocess large amounts of data at scale, using a fully managed service.

  Preparing the training data up front can improve training efficiency. However, implementing the transformation logic outside of the model (the approaches described in Option A: BigQuery or Option B: Dataflow ) doesn't resolve the issue of training-serving skew. Unless you store the engineered feature in the feature store to be used for both training and prediction, the transformation logic must be implemented somewhere to be applied on new data points coming for prediction, because the model interface expects transformed data. The TensorFlow Transform ( tf.Transform ) library can help you to address this issue, as described in the following section.

How tf.Transform works

The tf.Transform library is useful for transformations that require a full pass. The output of the tf.Transform library is exported as a TensorFlow graph that represents the instance-level transformation logic and the statistics computed from full-pass transformations, to be used for training and serving. Using the same graph for both training and serving can prevent skew, because the same transformations are applied in both stages. In addition, the tf.Transform library can run at scale in a batch processing pipeline on Dataflow to prepare the training data up front and improve training efficiency.

The following diagram, figure 4, shows how the tf.Transform library preprocesses and transforms data for training and prediction. The process is described in the following sections.

Transform training and evaluation data

You preprocess the raw training data using the transformation implemented in the tf.Transform Apache Beam APIs, and run it at scale on Dataflow. The preprocessing occurs in the following phases:

• Analyze phase: During the analyze phase, the required statistics (like means, variances, and quantiles) for stateful transformations are computed on the training data with full-pass operations. This phase produces a set of transformation artifacts, including the transform_fn graph. The transform_fn graph is a TensorFlow graph that has the transformation logic as instance-level operations. It includes the statistics computed in the analyze phase as constants.
• Transform phase: During the transform phase, the transform_fn graph is applied to the raw training data, where the computed statistics are used to process the data records (for example, to scale numerical columns) in an instance-level fashion.

A two-phase approach like this addresses the preprocessing challenge of performing full-pass transformations.

When the evaluation data is preprocessed, only instance-level operations are applied, using the logic in the transform_fn graph and the statistics computed from the analyze phase in the training data. In other words, you don't analyze the evaluation data in a full-pass fashion to compute new statistics, such as μ and σ, to normalize numeric features in evaluation data. Instead, you use the computed statistics from the training data to transform the evaluation data in an instance-level fashion.

The transformed training and evaluation data are prepared at scale using Dataflow, before they are used to train the model. This batch data-preparation process addresses the preprocessing challenge of preparing the data up front to improve training efficiency. As shown in figure 4, the model internal interface expects transformed features.

Attach transformations to the exported model

As noted, the transform_fn graph that's produced by the tf.Transform pipeline is stored as an exported TensorFlow graph. The exported graph consists of the transformation logic as instance-level operations, and all of the statistics computed in the full-pass transformations as graph constants. When the trained model is exported for serving, the transform_fn graph is attached to the SavedModel as part of its serving_fn function.

While it's serving the model for prediction, the model serving interface expects data points in the raw format (that is, before any transformations). However, the model internal interface expects the data in the transformed format.

The transform_fn graph, which is now part of the model, applies all the preprocessing logic on the incoming data point. It uses the stored constants (like μ and σ to normalize the numeric features) in the instance-level operation during prediction. Therefore, the transform_fn graph converts the raw data point into the transformed format. The transformed format is what is expected by the model internal interface in order to produce prediction, as shown in figure 4.

This mechanism resolves the preprocessing challenge of the training-serving skew, because the same logic (implementation) that is used to transform the training and evaluation data is applied to transform the new data points during prediction serving.

Preprocessing options summary

The following table summarizes the data preprocessing options that this document discussed. In the table, "N/A" stands for "not applicable."

^* With TensorFlow, transformations like crossing, embedding, and one-hot encoding should be performed declaratively as feature_columns columns.

Qual è il prossimo passo?

• To implement a tf.Transform pipeline and run it using Dataflow, read part two of this series, Data preprocessing for ML using TensorFlow Transform .
• Take the Coursera specialization on ML with TensorFlow on Google Cloud .
• Learn about best practices for ML engineering in Rules of ML .
• For more reference architectures, diagrams, and best practices, explore the TFX Cloud Solutions .

This document is the first in a two-part series that explores the topic of data engineering and feature engineering for machine learning (ML), with a focus on supervised learning tasks. This first part discusses the best practices for preprocessing data in an ML pipeline on Google Cloud. The document focuses on using TensorFlow and the open source TensorFlow Transform ( tf.Transform ) library to prepare data, train the model, and serve the model for prediction. This document highlights the challenges of preprocessing data for ML, and it describes the options and scenarios for performing data transformation on Google Cloud effectively.

This document assumes that you're familiar with BigQuery , Dataflow , Vertex AI , and the TensorFlow Keras API.

The second document, Data preprocessing for ML with Google Cloud , provides a step-by-step tutorial for how to implement a tf.Transform pipeline.

Introduzione

ML helps you automatically find complex and potentially useful patterns in data. These patterns are condensed in an ML model that can then be used on new data points—a process called making predictions or performing inference .

Building an ML model is a multistep process. Each step presents its own technical and conceptual challenges. This two-part series focuses on supervised learning tasks and the process of selecting, transforming, and augmenting the source data to create powerful predictive signals to the target variable. These operations combine domain knowledge with data science techniques. The operations are the essence of feature engineering .

The size of training datasets for real-world ML models can easily be equal to or greater than one terabyte (TB). Therefore, you need large-scale data processing frameworks in order to process these datasets efficiently and distributedly. When you use an ML model to make predictions, you have to apply the same transformations that you used for the training data on the new data points. By applying the same transformations, you present the live dataset to the ML model the way that the model expects.

Questo documento discute queste sfide per diversi livelli di granularità delle operazioni di ingegneria delle funzionalità: aggregazioni a livello di istanza, passaggio completo e finestra temporale. This document also describes the options and scenarios to perform data transformation for ML on Google Cloud.

This document also provides an overview of TensorFlow Transform ( tf.Transform ), a library for TensorFlow that lets you define both instance-level and full-pass data transformation through data preprocessing pipelines. These pipelines are executed with Apache Beam , and they create artifacts that let you apply the same transformations during prediction as when the model is served.

Preprocessing data for ML

This section introduces data preprocessing operations and stages of data readiness. It also discusses the types of the preprocessing operations and their granularity.

Data engineering compared to feature engineering

Preprocessing the data for ML involves both data engineering and feature engineering. Data engineering is the process of converting raw data into prepared data . Feature engineering then tunes the prepared data to create the features that are expected by the ML model. These terms have the following meanings:

Raw data (or just data )

The data in its source form, without any prior preparation for ML. In this context, the data might be in its raw form (in a data lake) or in a transformed form (in a data warehouse). Transformed data that's in a data warehouse might have been converted from its original raw form to be used for analytics. However, in this context, raw data means that the data hasn't been prepared specifically for your ML task. Data is also considered raw data if it's sent from streaming systems that eventually call ML models for predictions.

Prepared data

The dataset in the form ready for your ML task: data sources have been parsed, joined, and put into a tabular form. Prepared data is aggregated and summarized to the right granularity—for example, each row in the dataset represents a unique customer, and each column represents summary information for the customer, like the total spent in the last six weeks. In a prepared data table, irrelevant columns have been dropped, and invalid records have been filtered out. For supervised learning tasks, the target feature is present.

Engineered features

The dataset with the tuned features that are expected by the model—that is, features that are created by performing certain ML-specific operations on the columns in the prepared dataset, and creating new features for your model during training and prediction, as described later in Operazioni di preelaborazione . Examples of these operations include scaling numerical columns to a value between 0 and 1, clipping values, and one-hot-encoding categorical features.

The following diagram, figure 1, shows the steps that are involved in preparing preprocessed data:

In practice, data from the same source is often at different stages of readiness. For example, a field from a table in your data warehouse might be used directly as an engineered feature. At the same time, another field in the same table might need to go through transformations before it becomes an engineered feature. Similarly, data engineering and feature engineering operations might be combined in the same data preprocessing step.

Preprocessing operations

Data preprocessing includes several operations. Each operation is designed to help ML build better predictive models. The details of these preprocessing operations are outside the scope of this document, but some operations are briefly described in this section.

For structured data, data preprocessing operations include the following:

• Data cleansing: removing or correcting records that have corrupted or invalid values from raw data, and removing records that are missing a large number of columns.
• Instances selection and partitioning: selecting data points from the input dataset to create training, evaluation (validation), and test sets . Questo processo include tecniche per il campionamento casuale ripetibile, il sovracampionamento delle classi minoritarie e il partizionamento stratificato.
• Feature tuning: improving the quality of a feature for ML, which includes scaling and normalizing numeric values, imputing missing values, clipping outliers, and adjusting values that have skewed distributions.
• Feature transformation: converting a numeric feature to a categorical feature (through bucketization ), and converting categorical features to a numeric representation (through one-hot encoding, learning with counts , sparse feature embeddings, etc.). Some models work only with numeric or categorical features, while others can handle mixed type features. Even when models handle both types, they can benefit from different representations (numeric and categorical) of the same feature.
• Feature extraction: reducing the number of features by creating lower-dimension, more powerful data representations using techniques such as PCA , embedding extraction, and hashing .
• Feature selection: selecting a subset of the input features for training the model, and ignoring the irrelevant or redundant ones, using filter or wrapper methods . Feature selection can also involve simply dropping features if the features are missing a large number of values.
• Feature construction: creating new features by using typical techniques, such as polynomial expansion (by using univariate mathematical functions) or feature crossing (to capture feature interactions). Features can also be constructed by using business logic from the domain of the ML use case.

When you work with unstructured data (for example, images, audio, or text documents), deep learning replaces domain-knowledge-based feature engineering by folding it into the model architecture. A convolutional layer is an automatic feature preprocessor. Constructing the right model architecture requires some empirical knowledge of the data. In addition, some amount of preprocessing is needed, such as the following:

• For text documents: stemming and lemmatization , TF-IDF calculation, and n-gram extraction, embedding lookup.
• For images: clipping, resizing, cropping, Gaussian blur, and canary filters.
• For all types of data (including text and images): transfer learning , which treats all-but-last layers of the fully trained model as a feature engineering step.

Preprocessing granularity

This section discusses the granularity of types of data transformations. Mostra perché questa prospettiva è fondamentale quando si preparano nuovi punti dati per le previsioni utilizzando trasformazioni applicate ai dati di training.

Preprocessing and transformation operations can be categorized as follows, based on operation granularity:

• Instance-level transformations during training and prediction . These are straightforward transformations, where only values from the same instance are needed for the transformation. For example, instance-level transformations might include clipping the value of a feature to some threshold, polynomially expanding another feature, multiplying two features, or comparing two features to create a Boolean flag.

  These transformations must be applied identically during training and prediction, because the model will be trained on the transformed features, not on the raw input values. If the data isn't transformed identically, then the model behaves poorly because it is presented with data that has a distribution of values that it wasn't trained with. For more information, see the discussion of training-serving skew in the Preprocessing challenges section.

• Trasformazioni a passaggio completo durante l'addestramento, ma trasformazioni a livello di istanza durante la previsione . In this scenario, transformations are stateful, because they use some precomputed statistics to perform the transformation. During training, you analyze the whole body of training data to compute quantities such as minimum, maximum, mean, and variance for transforming training data, evaluation data, and new data at prediction time.

  For example, to normalize a numeric feature for training, you compute its mean (μ) and its standard deviation (σ) across the whole of the training data. This computation is called a full-pass (or analyze ) operation. When you serve the model for prediction, the value of a new data point is normalized to avoid training-serving skew. Therefore, μ and σ values that are computed during training are used to adjust the feature value, which is the following simple instance-level operation:

  $$ value_{scaled} = (value_{raw} - \mu) \div \sigma $$

  Full-pass transformations include the following:

  • MinMax scaling numerical features using min and max computed from the training dataset.
  • Standard scaling (z-score normalization) numerical features using μ and σ computed on the training dataset.
  • Bucketizing numerical features using quantiles.
  • Imputing missing values using the median (numerical features) or the mode (categorical features).
  • Conversione di stringhe (valori nominali) in numeri interi (indici) estraendo tutti i valori distinti (vocabolario) di una caratteristica categorica di input.
  • Counting the occurrence of a term (feature value) in all the documents (instances) to calculate for TF-IDF.
  • Computing the PCA of the input features to project the data into a lower dimensional space (with linearly dependent features).

  You should use only the training data to compute statistics like μ, σ, min , and max . If you add the test and evaluation data for these operations, you are leaking information from the evaluation and test data to train the model. Doing so affects the reliability of the test and evaluation results. To ensure that you apply a consistent transformation to all datasets, you use the same statistics computed from the training data to transform the test and evaluation data.

• Historical aggregations during training and prediction . This involves creating business aggregations, derivations, and flags as input signals to the prediction task—for example, creating recency, frequency, and monetary (RFM) metrics for customers to build propensity models. These types of features can be precomputed and stored in a feature store to be used during model training, batch scoring, and online prediction serving. You can also perform additional feature engineering (for example, transformation and tuning) to these aggregations before training and prediction.

• Historical aggregations during training, but real-time aggregations during prediction . This approach involves creating a feature by summarizing real-time values over time. In this approach, the instances to be aggregated are defined through temporal window clauses. For example, you can use this approach if you want to train a model that estimates the taxi trip time based on the traffic metrics for the route in the last 5 minutes, in the last 10 minutes, in the last 30 minutes, and at other intervals. You can also use this approach to predict the failure of an engine part based on the moving average of temperature and vibration values computed over the last 3 minutes. Although these aggregations can be prepared offline for training, they are computed in real time from a data stream during serving.

  More precisely, when you prepare training data, if the aggregated value isn't in the raw data, the value is created during the data engineering phase. The raw data is usually stored in a database with a format of (entity, timestamp, value) . In the previous examples, entity is the route segment identifier for the taxi routes and the engine part identifier for the engine failure. You can use windowing operations to compute (entity, time_index, aggregated_value_over_time_window) and use the aggregation features as an input for your model training.

  When the model for real-time (online) prediction is served, the model expects features derived from the aggregated values as an input. Therefore, you can use a stream-processing technology like Apache Beam to compute the aggregations from the real-time data points streamed into your system. Stream-processing technology aggregates real-time data based on time windows as new data points arrive. You can also perform additional feature engineering (for example, transformation and tuning) to these aggregations before training and prediction.

ML pipeline on Google Cloud

This section discusses the core components of a typical end-to-end pipeline to train and serve TensorFlow ML models on Google Cloud using managed services. Viene inoltre illustrato dove è possibile implementare diverse categorie di operazioni di pre-elaborazione dei dati e le sfide comuni che potresti incontrare quando implementi tali trasformazioni. The How tf.Transform works section shows how the TensorFlow Transform library helps to address these challenges.

High-level architecture

The following diagram, figure 2, shows a high-level architecture of a typical ML pipeline for training and serving TensorFlow models. The labels A, B, and C in the diagram refer to the different places in the pipeline where data preprocessing can take place. Details about these steps are provided in the following section.

La pipeline è composta dai seguenti passaggi:

1. After raw data is imported, tabular data is stored in BigQuery, and other data like images, audio, and video, is stored in Cloud Storage. The second part of this series uses tabular data stored in BigQuery as an example.
2. Data engineering (preparation) and feature engineering are executed at scale using Dataflow. This execution produces ML-ready training, evaluation, and test sets that are stored in Cloud Storage. Ideally, these datasets are stored as TFRecord files, which is the optimized format for TensorFlow computations.
3. A TensorFlow model trainer package is submitted to Vertex AI Training, which uses the preprocessed data from the previous steps to train the model. The output of this step is a trained TensorFlow SavedModel that is exported to Cloud Storage.
4. The trained TensorFlow model is deployed to Vertex AI Prediction as a service that has a REST API so that it can be used for online predictions. The same model can also be used for batch prediction jobs.
5. After the model is deployed as a REST API, client apps and internal systems can invoke the API by sending requests with some data points, and receiving responses from the model with predictions.
6. For orchestrating and automating this pipeline, you can use Vertex AI Pipelines as a scheduler to invoke the data preparation, model training, and model deployment steps.

You can also use Vertex AI Feature Store to store input features to make predictions. For example, you can periodically create engineered features from the latest raw data and store them in Vertex AI Feature Store. Client apps fetch the required input features from Vertex AI Feature Store and send them to the model to receive predictions.

Where to do preprocessing

In figure 2, the labels A, B, and C show that data preprocessing operations can take place in BigQuery, Dataflow, or TensorFlow. The following sections describe how each of these options work.

Option A: BigQuery

Typically, logic is implemented in BigQuery for the following operations:

• Sampling: randomly selecting a subset from the data.
• Filtering: removing irrelevant or invalid instances.
• Partitioning: splitting the data to produce training, evaluation, and test sets.

BigQuery SQL scripts can be used as a source query for the Dataflow preprocessing pipeline, which is the data processing step in figure 2. For example, if a system is used in Canada, and the data warehouse has transactions from around the world, filtering to get Canada-only training data is best done in BigQuery. Feature engineering in BigQuery is simple and scalable, and supports implementing instance-level and historical aggregations feature transformations.

However, we recommend that you use BigQuery for feature engineering only if you use your model for batch prediction (scoring), or if the features are precomputed in BigQuery, but stored in Vertex AI Feature Store to be used during online prediction. If you plan to deploy the model for online predictions, and if you don't have the engineered feature in an online feature store, you have to replicate the SQL preprocessing operations to transform the raw data points that other systems generate. In other words, you need to implement the logic twice: one time in SQL to preprocess training data in BigQuery, and a second time in the logic of the app that consumes the model to preprocess online data points for prediction.

For example, if your client app is written in Java, you need to reimplement the logic in Java. This can introduce errors due to implementation discrepancies, as described in the training-serving skew section of Preprocessing challenges later in this document. It's also extra overhead to maintain two different implementations. Ogni volta che si modifica la logica in SQL per preelaborare i dati di training, è necessario modificare di conseguenza l'implementazione Java per preelaborare i dati al momento dell'elaborazione.

If you are using your model only for batch prediction (for example, using Vertex AI batch prediction ), and if your data for scoring is sourced from BigQuery, you can implement these preprocessing operations as part of the BigQuery SQL script. In that case, you can use the same preprocessing SQL script to prepare both training and scoring data.

Full-pass stateful transformations aren't suitable for implementation in BigQuery. If you use BigQuery for full-pass transformations, you need auxiliary tables to store quantities needed by stateful transformations, such as means and variances to scale numerical features. Further, implementation of full-pass transformations using SQL on BigQuery creates increased complexity in the SQL scripts, and creates intricate dependency between training and the scoring SQL scripts.

Option B: Dataflow

As shown in figure 2, you can implement computationally expensive preprocessing operations in Apache Beam, and run them at scale using Dataflow. Dataflow is a fully managed autoscaling service for batch and stream data processing. When you use Dataflow, you can also use external specialized libraries for data processing, unlike BigQuery.

Dataflow can perform instance-level transformations, and historical and real-time aggregation feature transformations. In particular, if your ML models expect an input feature like total_number_of_clicks_last_90sec , Apache Beam windowing functions can compute these features based on aggregating the values of time windows of real-time (streaming) events data (for example, click events). In the earlier discussion of granularity of transformations , this was referred to as "Historical aggregations during training, but real-time aggregations during prediction."

The following diagram, figure 3, shows the role of Dataflow in processing stream data for near real-time predictions.

As shown in figure 3, during processing, events called data points are ingested into Pub/Sub . Dataflow consumes these data points, computes features based on aggregates over time, and then calls the deployed ML model API for predictions. Predictions are then sent to an outbound Pub/Sub queue. From Pub/Sub, predictions can be consumed by downstream systems like monitoring or control, or they can be pushed back (for example, as notifications) to the original requesting client. Predictions can also be stored in a low-latency data store like Cloud Bigtable for real-time fetching. Cloud Bigtable can also be used to accumulate and store these real-time aggregations so they can be looked up when needed for prediction.

The same Apache Beam implementation can be used to batch-process training data that comes from an offline datastore like BigQuery and stream-process real-time data for serving online predictions.

In other typical architectures, such as the architecture shown in figure 2, the client app directly calls the deployed model API for online predictions. In that case, if preprocessing operations are implemented in Dataflow to prepare the training data, the operations aren't applied to the prediction data that goes directly to the model. Therefore, transformations like these should be integrated in the model during serving for online predictions.

Dataflow can be used to perform full-pass transformation, by computing the required statistics at scale. However, these statistics need to be stored somewhere to be used during prediction to transform prediction data points. By using the TensorFlow Transform ( tf.Transform ) library, you can directly embed these statistics in the model instead of storing them elsewhere. This approach is explained later in How tf.Transform works .

Option C: TensorFlow

As shown in figure 2, you can implement data preprocessing and transformation operations in the TensorFlow model itself. As shown in the figure, the preprocessing that you implement for training the TensorFlow model becomes an integral part of the model when the model is exported and deployed for predictions. Transformations in the TensorFlow model can be accomplished in one of the following ways:

• Implementing all of the instance-level transformation logic in the input_fn function and in the serving_fn function. The input_fn function prepares a dataset using the tf.data.Dataset API for training a model. The serving_fn function receives and prepares the data for predictions.
• Putting the transformation code directly in your TensorFlow model by using Keras preprocessing layers or creating custom layers .

The transformation logic code in the serving_fn function defines the serving interface of your SavedModel for online prediction. If you implement the same transformations that were used for preparing training data in the transformation logic code of the serving_fn function, it ensures that the same transformations are applied to new prediction data points when they're served.

However, because the TensorFlow model processes each data point independently or in a small batch, you can't calculate aggregations from all data points. As a result, full-pass transformations can't be implemented in your TensorFlow model.

Preprocessing challenges

The following are the primary challenges of implementing data preprocessing:

• Training-serving skew . Training-serving skew refers to a difference between effectiveness (predictive performance) during training and during serving. This skew can be caused by a discrepancy between how you handle data in the training and the serving pipelines. For example, if your model is trained on a logarithmically transformed feature, but it's presented with the raw feature during serving, the prediction output might not be accurate.

  If the transformations become part of the model itself, it can be straightforward to handle instance-level transformations, as described earlier in Option C: TensorFlow . In that case, the model serving interface (the serving_fn function) expects raw data, while the model internally transforms this data before computing the output. The transformations are the same as those that were applied on the raw training and prediction data points.

• Full-pass transformations . You can't implement full-pass transformations such as scaling and normalization transformations in your TensorFlow model. In full-pass transformations, some statistics (for example, max and min values to scale numeric features) must be computed on the training data beforehand, as described in Option B: Dataflow . The values then have to be stored somewhere to be used during model serving for prediction to transform the new raw data points as instance-level transformations, which avoids training-serving skew. You can use the TensorFlow Transform ( tf.Transform ) library to directly embed the statistics in your TensorFlow model. This approach is explained later in How tf.Transform works .

• Preparing the data up front for better training efficiency . Implementing instance-level transformations as part of the model can degrade the efficiency of the training process. This degradation occurs because the same transformations are repeatedly applied to the same training data on each epoch. Imagine that you have raw training data with 1,000 features, and you apply a mix of instance-level transformations to generate 10,000 features. If you implement these transformations as part of your model, and if you then feed the model the raw training data, these 10,000 operations are applied N times on each instance, where N is the number of epochs. Inoltre, se utilizzi acceleratori (GPU o TPU), rimangono inattivi mentre la CPU esegue tali trasformazioni, il che non costituisce un uso efficiente dei tuoi costosi acceleratori.

  Ideally, the training data is transformed before training, using the technique described under Option B: Dataflow , where the 10,000 transformation operations are applied only once on each training instance. The transformed training data is then presented to the model. No further transformations are applied, and the accelerators are busy all of the time. In addition, using Dataflow helps you to preprocess large amounts of data at scale, using a fully managed service.

  Preparing the training data up front can improve training efficiency. However, implementing the transformation logic outside of the model (the approaches described in Option A: BigQuery or Option B: Dataflow ) doesn't resolve the issue of training-serving skew. Unless you store the engineered feature in the feature store to be used for both training and prediction, the transformation logic must be implemented somewhere to be applied on new data points coming for prediction, because the model interface expects transformed data. The TensorFlow Transform ( tf.Transform ) library can help you to address this issue, as described in the following section.

How tf.Transform works

The tf.Transform library is useful for transformations that require a full pass. The output of the tf.Transform library is exported as a TensorFlow graph that represents the instance-level transformation logic and the statistics computed from full-pass transformations, to be used for training and serving. Using the same graph for both training and serving can prevent skew, because the same transformations are applied in both stages. In addition, the tf.Transform library can run at scale in a batch processing pipeline on Dataflow to prepare the training data up front and improve training efficiency.

The following diagram, figure 4, shows how the tf.Transform library preprocesses and transforms data for training and prediction. The process is described in the following sections.

Transform training and evaluation data

You preprocess the raw training data using the transformation implemented in the tf.Transform Apache Beam APIs, and run it at scale on Dataflow. The preprocessing occurs in the following phases:

• Analyze phase: During the analyze phase, the required statistics (like means, variances, and quantiles) for stateful transformations are computed on the training data with full-pass operations. This phase produces a set of transformation artifacts, including the transform_fn graph. The transform_fn graph is a TensorFlow graph that has the transformation logic as instance-level operations. It includes the statistics computed in the analyze phase as constants.
• Transform phase: During the transform phase, the transform_fn graph is applied to the raw training data, where the computed statistics are used to process the data records (for example, to scale numerical columns) in an instance-level fashion.

A two-phase approach like this addresses the preprocessing challenge of performing full-pass transformations.

When the evaluation data is preprocessed, only instance-level operations are applied, using the logic in the transform_fn graph and the statistics computed from the analyze phase in the training data. In other words, you don't analyze the evaluation data in a full-pass fashion to compute new statistics, such as μ and σ, to normalize numeric features in evaluation data. Instead, you use the computed statistics from the training data to transform the evaluation data in an instance-level fashion.

The transformed training and evaluation data are prepared at scale using Dataflow, before they are used to train the model. This batch data-preparation process addresses the preprocessing challenge of preparing the data up front to improve training efficiency. As shown in figure 4, the model internal interface expects transformed features.

Attach transformations to the exported model

As noted, the transform_fn graph that's produced by the tf.Transform pipeline is stored as an exported TensorFlow graph. The exported graph consists of the transformation logic as instance-level operations, and all of the statistics computed in the full-pass transformations as graph constants. When the trained model is exported for serving, the transform_fn graph is attached to the SavedModel as part of its serving_fn function.

While it's serving the model for prediction, the model serving interface expects data points in the raw format (that is, before any transformations). However, the model internal interface expects the data in the transformed format.

The transform_fn graph, which is now part of the model, applies all the preprocessing logic on the incoming data point. It uses the stored constants (like μ and σ to normalize the numeric features) in the instance-level operation during prediction. Therefore, the transform_fn graph converts the raw data point into the transformed format. The transformed format is what is expected by the model internal interface in order to produce prediction, as shown in figure 4.

This mechanism resolves the preprocessing challenge of the training-serving skew, because the same logic (implementation) that is used to transform the training and evaluation data is applied to transform the new data points during prediction serving.

Preprocessing options summary

The following table summarizes the data preprocessing options that this document discussed. In the table, "N/A" stands for "not applicable."

^* With TensorFlow, transformations like crossing, embedding, and one-hot encoding should be performed declaratively as feature_columns columns.

Qual è il prossimo passo?

• To implement a tf.Transform pipeline and run it using Dataflow, read part two of this series, Data preprocessing for ML using TensorFlow Transform .
• Take the Coursera specialization on ML with TensorFlow on Google Cloud .
• Learn about best practices for ML engineering in Rules of ML .
• For more reference architectures, diagrams, and best practices, explore the TFX Cloud Solutions .