Feature engineering: le decisioni che determinano la qualità dei modelli ML

Lunedì mattina entra in produzione un nuovo modello di machine learning e, all’ora di pranzo, gli analisti sono sommersi dai falsi positivi. I casi ad alta priorità non vengono rilevati, quelli di routine vengono inoltrati ai livelli superiori e nessuno sa spiegare perché le prestazioni del modello nel mondo reale siano tanto diverse dai risultati della validazione.

Il problema non è necessariamente l’algoritmo. Potrebbe dipendere dal modo in cui sono stati rappresentati i dati. Forse gli importi delle transazioni sono stati utilizzati come valori grezzi, ma il modello non ha rilevato quanto fosse insolito un acquisto per quello specifico cliente. Oppure le categorie sono state codificate in un modo che ha introdotto relazioni fuorvianti. Il modello potrebbe essere stato addestrato con dati accurati, ma i segnali contenuti nei dati non sono stati tradotti in una forma utilizzabile.

Questo è il compito del feature engineering: trasformare i dati grezzi in input che un modello di machine learning può utilizzare concretamente. Comprende attività comuni di preparazione dei dati, come la gestione dei valori mancanti, la codifica delle categorie e il ridimensionamento dei campi numerici, ma comporta anche decisioni di rappresentazione più profonde su ciò che il modello deve conoscere e sulla forma in cui presentarlo. Queste decisioni determinano la quantità di segnale utile che raggiunge il modello e la qualità delle sue prestazioni quando incontra dati del mondo reale.

Il feature engineering è il processo che utilizza le conoscenze di dominio per creare, trasformare e selezionare dai dati grezzi le variabili di input, dette feature, affinché un modello di machine learning possa produrre previsioni più accurate.

Una feature può essere una colonna di dati di origine utilizzata direttamente, come l’importo della transazione o l’età dell’account in giorni, oppure può essere derivata, come il valore medio degli ordini di un cliente negli ultimi 90 giorni, il numero di tentativi di autenticazione non riusciti nell’ultima ora o il rapporto tra due misure che, considerate singolarmente, forniscono meno informazioni che insieme.

Il feature engineering si colloca tra i dati grezzi e l’addestramento del modello. Si estraggono i segnali dai sistemi di origine, li si trasforma in input pronti per il modello, si valuta quali migliorano le prestazioni di validazione e si trasferisce la logica approvata nelle pipeline di feature o in un feature store, affinché possa essere riutilizzata. Stabilire quali feature servono a un modello significa determinare ciò che il modello deve comprendere del dominio.

Il feature engineering richiede la collaborazione tra data scientist, data engineer ed esperti di dominio, perché traduce nel modello la comprensione condivisa del problema aziendale. Se svolto correttamente, è una delle attività a maggior impatto nel ciclo di vita del machine learning.

La qualità di un modello è limitata dai dati di input. Nessuna selezione dell’algoritmo, attività di tuning degli iperparametri o capacità di calcolo può recuperare un segnale che non era presente fin dall’inizio nel set di feature. È nel feature engineering che si determina questo limite e si esercita un controllo più diretto sulla qualità del modello rispetto a quasi ogni altra fase del ciclo di vita del ML.

Uno dei fattori che determinano questo limite è la rappresentazione. Gli stessi dati sottostanti, espressi in modo diverso, forniscono al modello una rappresentazione del problema radicalmente differente. Si consideri un modello di abbandono basato sui dati di utilizzo del prodotto. Il numero grezzo di accessi negli ultimi 30 giorni indica al modello quanto è stato attivo un cliente. Tuttavia, spesso è la variazione di tale attività a prevedere effettivamente l’abbandono: un cliente che effettua la metà degli accessi rispetto a 60 giorni prima presenta una situazione diversa da quella di chi ha sempre mantenuto la stessa frequenza. I dati sottostanti sono gli stessi. Espressi come tendenza anziché come conteggio, contengono un segnale che il solo valore grezzo non fornisce.

L’articolo di riferimento di Pedro Domingos, A Few Useful Things to Know About Machine Learning, identifica la rappresentazione come uno dei problemi centrali del settore. L’osservazione è ancora valida: se le feature disponibili non rappresentano la struttura del problema, l’algoritmo dispone di meno informazioni, indipendentemente dal tuning applicato.

Il feature engineering influisce anche sulla generalizzazione. Un modello addestrato con feature che riflettono pattern autentici e persistenti nei dati ha maggiori probabilità di produrre previsioni accurate quando incontra nuovi clienti, nuovi prodotti o un ambiente operativo diverso. Un modello addestrato con feature che risultano correlate al target durante il periodo di addestramento, ma per ragioni contingenti, si deteriora più rapidamente in produzione.

Guarda il video per scoprire come semplificare il feature engineering con il ML agentico:

Il feature engineering parte in genere dal problema di previsione per poi risalire ai dati. Ad esempio, chi sviluppa una previsione della domanda necessita di segnali diversi rispetto a chi classifica i ticket di assistenza, anche quando entrambi utilizzano dati relativi a clienti, prodotti e serie temporali.

Un processo pratico comprende in genere questi passaggi:

1. Comprendere i dati e il problema: definire il target della previsione, la decisione che il modello dovrà supportare e i vincoli relativi a latenza, spiegabilità e accesso ai dati.
2. Esplorare e analizzare i dati grezzi: esaminare distribuzioni, valori mancanti, outlier, correlazioni, cardinalità delle categorie e pattern temporali.
3. Creare e trasformare le feature: derivare misure come rapporti, finestre mobili, conteggi, flag, interazioni e valori normalizzati.
4. Valutare la rilevanza delle feature: utilizzare test statistici, misure di importanza basate sul modello, valutazioni di dominio e risultati della validazione per identificare le feature che contengono segnali utili.
5. Convalidare in base alle prestazioni del modello: addestrare e testare i modelli mediante esperimenti controllati, verificando la presenza di leakage, overfitting e drift tra i dati di addestramento e quelli di produzione.

Il processo è iterativo. Un data scientist può derivare rapporti, conteggi, aggregazioni mobili, feature ritardate, flag, codifiche categoriali o termini di interazione, quindi verificare se questi input migliorano le prestazioni sui dati esclusi dall’addestramento. Alcune feature si dimostrano subito utili. Altre vengono escluse perché causano leakage di informazioni dalla feature, variano eccessivamente tra periodi diversi o dipendono da dati non disponibili al momento dell’inferenza.

Il processo richiede rigore, perché la logica delle feature può propagarsi e divergere. Un calcolo testato in un notebook, riformulato in una pipeline di addestramento e riscritto una terza volta per un servizio di scoring in tempo reale può produrre tre valori leggermente diversi per lo stesso concetto sottostante. Le pipeline di feature riproducibili e i feature store servono a prevenire questo tipo di drift: conservano le definizioni utilizzate durante l’addestramento e le rendono disponibili in modo coerente per l’inferenza batch o in tempo reale.

Il feature engineering utilizza un’ampia gamma di tecniche. Alcune preparano i dati grezzi per la modellazione. Altre costruiscono nuovi segnali a partire dai campi esistenti. La combinazione appropriata dipende dal tipo di dati, dalla famiglia di modelli e dalla decisione che il modello deve supportare.

Imputazione e gestione degli outlier

I valori mancanti devono essere interpretati prima di poter essere gestiti. Un campo vuoto può indicare che un valore era sconosciuto, facoltativo, omesso, non disponibile al momento della raccolta o effettivamente assente. L’imputazione colma le lacune mediante metodi come media, mediana, moda, valori costanti o stime basate su modelli. In molti casi si aggiunge anche un indicatore binario dei valori mancanti, consentendo al modello di apprendere se l’assenza di un valore sia di per sé informativa, come spesso accade.

Anche gli outlier richiedono una valutazione. Una transazione insolitamente elevata può rappresentare una frode, un acquisto aziendale legittimo o un errore di inserimento dei dati. È possibile limitare i valori a una soglia, applicare una trasformazione che riduca l’asimmetria, rimuovere i record chiaramente errati o conservare i valori estremi quando riflettono comportamenti significativi che il modello deve rilevare. Il trattamento degli outlier è una decisione di rappresentazione, perché definisce la versione della realtà su cui viene addestrato il modello.

Scaling e normalizzazione

Lo scaling modifica l’intervallo delle feature numeriche affinché le differenze di grandezza non producano differenze artificiali nel comportamento del modello. Lo scaling min-max mappa i valori in un intervallo fisso. La standardizzazione z-score esprime i valori rispetto alla media e alla deviazione standard della distribuzione. Lo scaling robusto utilizza la mediana e l’intervallo interquartile, risultando meno sensibile agli outlier rispetto ai metodi basati sulla media.

La sensibilità allo scaling varia in base al tipo di modello. I modelli lineari, le reti neurali e gli algoritmi basati sulla distanza risentono maggiormente delle feature non sottoposte a scaling. I modelli basati su alberi sono generalmente meno sensibili, anche se è possibile standardizzare il preprocessing quando lo stesso set di feature alimenta più modelli o sistemi downstream.

Codifica delle variabili categoriali

La maggior parte dei modelli di ML richiede che i valori categoriali siano espressi numericamente. La codifica one-hot crea una colonna indicatrice binaria per ogni categoria, una soluzione semplice quando la cardinalità è bassa. La codifica ordinale preserva un ordine significativo, come basso, medio e alto. La codifica tramite etichette assegna ID interi alle categorie, ma può suggerire involontariamente un ordine inesistente.

I campi ad alta cardinalità, come gli identificativi degli esercenti, gli SKU dei prodotti o i codici geografici, richiedono maggiore attenzione. Una categoria con migliaia di livelli rende impraticabile la codifica one-hot. Il target encoding e il mean encoding sostituiscono le etichette delle categorie con statistiche derivate dalla variabile target, ma richiedono una validazione rigorosa per evitare il data leakage dal set di holdout.

Trasformazione, binning e discretizzazione

Le trasformazioni modificano la distribuzione di una feature o la sua relazione con il target. Una trasformazione log può ridurre l’influenza dei valori con distribuzioni a coda lunga, come ricavi, durata della sessione o saldo del conto. Il Box-Cox e le trasformazioni correlate possono rendere le feature numeriche più adatte ai modelli che presuppongono determinate distribuzioni, anche se la trasformazione Box-Cox richiede valori strettamente positivi.

Il binning raggruppa i valori continui in intervalli discreti. Un modello può ricevere fasce di età anziché l’età grezza, fasce di permanenza anziché il numero esatto di giorni trascorsi dalla registrazione oppure livelli di spesa anziché gli importi delle transazioni. Il binning può rendere alcuni pattern più facili da apprendere e, nei contesti regolamentati, da spiegare. Quando le soglie di dominio sono già rilevanti, come limiti normativi, confini tra livelli di prodotto o intervalli clinici, i bin allineati a tali soglie producono spesso feature più significative rispetto ai valori numerici grezzi.

Creazione delle feature

La creazione delle feature è la fase in cui la conoscenza del dominio produce l’effetto più diretto. Un retailer che prevede la domanda può richiedere feature relative alla recente velocità delle vendite, ai livelli delle scorte, alla tempistica delle promozioni e alla vicinanza a eventi locali. Un modello di sicurezza può richiedere la frequenza dei tentativi di accesso non riusciti, punteggi di novità del dispositivo, indicatori di spostamenti impossibili e deviazioni comportamentali rispetto alla baseline dell’account. Un modello di customer health può richiedere le tendenze di engagement con il prodotto, i pattern delle interazioni con l’assistenza e le variazioni dello stato contrattuale.

Il feature crossing combina i campi per rilevare le interazioni: categoria di prodotto per area geografica, segmento di clientela per canale e tipo di dispositivo per ora del giorno. Le feature polinomiali consentono ad alcune famiglie di modelli di rappresentare relazioni non lineari. Le feature temporali estraggono informazioni strutturate dai timestamp: ora del giorno, giorno della settimana, tempo trascorso dall’ultimo evento, medie mobili, valori ritardati e codifiche cicliche per i pattern ricorrenti.

Riduzione della dimensionalità

Quando un set di dati contiene molte colonne, rumore o feature fortemente correlate, i metodi di riduzione della dimensionalità possono comprimere lo spazio delle feature preservando le informazioni utili. L’analisi delle componenti principali proietta le feature numeriche correlate in un insieme più piccolo di componenti. Gli autoencoder e metodi analoghi possono apprendere rappresentazioni compatte da input più complessi.

Il compromesso riguarda l’interpretabilità. Una rappresentazione ridotta può migliorare l’efficienza e, in alcuni casi, le prestazioni del modello, ma le componenti risultanti potrebbero non corrispondere a concetti interpretabili da una persona esperta del dominio. Nei casi d’uso critici o regolamentati, questa perdita di trasparenza comporta conseguenze concrete ed è necessario valutare il beneficio rispetto a ciò a cui si rinuncia.

Questi termini ricorrono spesso insieme perché indicano attività strettamente correlate nel workflow di ML. Ecco una breve panoramica di ciascuno.

Feature engineering

Il feature engineering è la pratica generale di preparazione degli input del modello a partire dai dati grezzi. Comprende la creazione di feature, la trasformazione dei valori, la gestione dei dati mancanti, la codifica delle categorie, l’applicazione della riduzione della dimensionalità e l’identificazione delle feature da utilizzare per l’addestramento. Le altre attività descritte di seguito sono sottoinsiemi o complementi di questo ambito più ampio.

Selezione delle feature

La selezione delle feature identifica quali feature dell’insieme disponibile includere nel modello. Si eliminano le feature ridondanti, instabili, debolmente correlate al target, difficili da spiegare nei contesti di produzione o non disponibili al momento dell’inferenza.

La selezione riduce l’overfitting e migliora l’efficienza del modello. Offre inoltre vantaggi operativi. Un modello con un numero inferiore di feature stabili e ben comprese è in genere più facile da monitorare in produzione e sottoporre ad audit rispetto a un modello che dipende da molti input deboli o sovrapposti. Gli approcci comuni includono metodi di filtro statistico, metodi wrapper che valutano sottoinsiemi di feature rispetto alle prestazioni del modello e metodi integrati che utilizzano elementi interni del modello, come coefficienti di regolarizzazione e punteggi di importanza basati su alberi, per identificare le feature più rilevanti.

Estrazione delle feature

L’estrazione delle feature ricava strutture da dati grezzi o complessi. Da un timestamp è possibile ricavare il giorno della settimana, il mese o il tempo trascorso da un evento di riferimento. Un campo di testo libero può produrre frequenze dei termini, punteggi di sentiment o embedding vettoriali densi. Un modello di elaborazione delle immagini può estrarre contorni, texture o rappresentazioni apprese dai livelli intermedi della rete.

In pratica, l’estrazione si sovrappone in larga misura alla creazione delle feature. La distinzione riguarda l’enfasi: l’estrazione si concentra sul ricavare strutture dagli input grezzi, mentre il feature engineering comprende il workflow più ampio di preparazione di tali input per la modellazione.

Feature store

Un feature store è un repository gestito per le definizioni delle feature, i valori calcolati delle feature e i metadati associati. Consente di riutilizzare le feature in più progetti, ridurre la duplicazione della logica delle pipeline e mantenere coerenti le definizioni delle feature tra addestramento e inferenza.

La data augmentation amplia i dati di addestramento generando versioni modificate degli esempi esistenti. È utilizzata soprattutto nella computer vision e nell’elaborazione del linguaggio naturale, dove determinate modifiche aumentano la varietà del set di addestramento senza cambiare l’etichetta.

Per le immagini, l’augmentation può includere ribaltamenti, rotazioni, ritagli, regolazioni della luminosità o piccole traslazioni. Per il testo, può includere la sostituzione di sinonimi, la parafrasi o perturbazioni controllate. Per i dati tabulari con classi sbilanciate, tecniche come SMOTE generano esempi sintetici per le classi sottorappresentate.

La domanda fondamentale in qualsiasi decisione relativa all’augmentation è se l’esempio modificato continui a rappresentare lo stesso elemento. La rotazione dell’immagine di un prodotto può preservare l’etichetta in un’attività di classificazione per l’ecommerce. In un modello per il rilevamento dei difetti nel settore manifatturiero, l’orientamento può contenere informazioni sul tipo di difetto. L’augmentation è utile quando riflette variazioni rispetto alle quali il modello deve essere robusto, ma è controproducente quando elimina il segnale.

Gli embedding sono rappresentazioni vettoriali dense che codificano le relazioni presenti nei dati. Sono comuni nei workflow per testo, immagini, raccomandazioni e dati categorici ad alta cardinalità, nei quali i valori grezzi richiedono una forma numerica più ricca di quella fornita dagli schemi di codifica.

Ad esempio, l’ID di un prodotto ha poco significato intrinseco come numero intero grezzo, ma un embedding può collocare il prodotto vicino a prodotti simili in base a descrizioni, comportamenti di acquisto congiunto, attributi visivi o pattern di navigazione. Un embedding di testo può collocare espressioni semanticamente correlate in posizioni vicine nello spazio vettoriale, risultando utile per la ricerca, la classificazione, le raccomandazioni e la retrieval-augmented generation (RAG).

Gli embedding occupano una posizione particolare rispetto al feature engineering. Possono fungere da feature apprese e trasferite ai modelli downstream, come avviene per le feature create manualmente. Rappresentano inoltre una modalità diversa di sviluppo delle feature: le rappresentazioni vengono apprese da grandi set di dati anziché essere definite mediante l’analisi del dominio. In pratica, molti sistemi ML in produzione combinano entrambi gli approcci: embedding appresi per le feature relative a contenuti o identità e feature ingegnerizzate per i segnali comportamentali, temporali e contestuali.

Il feature engineering automatizzato utilizza software per generare su larga scala feature candidate a partire da dati grezzi. Strumenti come Featuretools utilizzano metodi tra cui Deep Feature Synthesis per creare sistematicamente feature da tabelle correlate. I sistemi AutoML possono generare trasformazioni, codifiche e feature di interazione nell’ambito di un workflow più ampio per lo sviluppo dei modelli.

L’automazione è particolarmente utile quando lo spazio di ricerca è ampio o le trasformazioni candidate sono ripetitive. Un sistema può generare aggregazioni mobili, campi derivati dalle date, codifiche categoriche e riepiloghi a livello di tabella più rapidamente rispetto alla creazione manuale di ogni feature.

La conoscenza del dominio deve comunque guidare il lavoro: la revisione da parte di esperti, la convalida e la governance determinano quali feature sia opportuno utilizzare.

Il feature engineering in produzione richiede più del solo codice di trasformazione. Sono necessari accesso governato ai dati di origine, capacità di elaborazione scalabile per set di dati di grandi dimensioni, definizioni riutilizzabili delle feature, aggiornamento affidabile delle feature e un percorso chiaro dai dati di addestramento al modello distribuito.

Snowflake supporta questo workflow tramite Snowflake ML, un insieme integrato di funzionalità per il machine learning end‑to‑end basato su dati governati, che comprende feature engineering, addestramento dei modelli e inferenza.

Con Snowpark, è possibile scrivere trasformazioni delle feature in Python o SQL ed eseguirle vicino ai dati, senza trasferire questi ultimi in un ambiente esterno. Snowflake Feature Store fornisce definizioni e viste delle feature gestite, consentendo di creare, materializzare, recuperare e gestire pipeline di feature in Snowflake. Le viste delle feature possono incapsulare pipeline Python o SQL che trasformano i dati grezzi in feature pronte per i modelli, mentre le viste delle feature gestite da Snowflake possono aggiornarsi automaticamente secondo una pianificazione definita.

Le Dynamic Tables supportano pipeline incrementali di feature quando le trasformazioni definite in SQL devono restare aggiornate. Snowflake gestisce le Dynamic Tables come una pipeline, tiene traccia delle dipendenze e coordina gli aggiornamenti affinché le tabelle downstream riflettano uno snapshot coerente dei rispettivi input. Le Dynamic Tables supportano anche il target lag, una specifica che definisce il livello di aggiornamento richiesto per i dati, e l’aggiornamento incrementale per i pattern di trasformazione supportati.

Per il machine learning in produzione, Snowflake Feature Store può essere utilizzato insieme a Snowflake Model Registry. Il registro archivia e gestisce versioni, metriche e metadati dei modelli, supporta l’inferenza tramite Python, SQL o endpoint API REST e gestisce l’accesso ai modelli mediante il controllo degli accessi basato sui ruoli (RBAC).

Il feature engineering è talvolta descritto come il lavoro di preparazione che precede la modellazione vera e propria. Questa descrizione, tuttavia, non coglie l’importanza del lavoro né ciò che comporta effettivamente. Ogni decisione su come rappresentare una variabile, gestire un valore mancante, codificare una categoria o creare una feature ritardata determina ciò che il modello riesce a comprendere del dominio in cui opera.

Su scala di produzione, le decisioni sulla rappresentazione si moltiplicano. Le feature vengono riutilizzate in più modelli, ricreate da team diversi e ricalcolate in ambienti differenti. Mantenere coerenti queste definizioni, dall’esplorazione al training fino all’inferenza, incide direttamente sulla qualità del modello.

Per questo motivo, il feature engineering e il MLOps sono strettamente connessi. Il feature engineering determina i dati da cui apprende il modello, mentre il MLOps garantisce che le definizioni delle feature rimangano coerenti, osservabili e affidabili durante il passaggio dei modelli dallo sviluppo alla produzione.