Feature engineering: dove si vince davvero

Nel 2014, in una competizione Kaggle sulla previsione dei clic pubblicitari, i primi dieci classificati usavano quasi tutti lo stesso algoritmo: le factorization machines. Quello che separava il primo dal decimo non era il modello, ma le colonne del dataset che ciascuno si era costruito. Il vincitore aveva passato settimane a inventare variabili nuove: quante volte quell’utente aveva già visto quel banner, a che ora del giorno, con quale frequenza negli ultimi sette giorni. Il modello era intercambiabile. Le feature no.

È una lezione che chi lavora nel machine learning impara presto, e che i corsi tendono a rimandare: la maggior parte del valore non si crea scegliendo l’algoritmo giusto, ma trasformando i dati grezzi in una rappresentazione che l’algoritmo possa capire. Questo lavoro si chiama feature engineering, e resta — anche nell’epoca del deep learning — il posto dove si vince davvero.

Cosa vede davvero un modello

Un modello di machine learning classico non vede il mondo: vede una tabella di numeri. Non sa che 2026-07-11 è un venerdì d’estate, non sa che «Via Roma 12, Milano» è un indirizzo in una zona cara, non sa che due acquisti a distanza di tre minuti sono probabilmente correlati. Sa solo confrontare numeri tra loro.

Il feature engineering è l’atto di tradurre la conoscenza del dominio in colonne numeriche. Dalla data grezza si estraggono il giorno della settimana, il mese, un flag «è festivo». Dall’indirizzo si ricava il quartiere o il reddito mediano della zona. Dalla sequenza di acquisti si calcola il tempo trascorso dall’ultimo. Ogni trasformazione è un pezzo di sapere umano che viene reso digeribile per la macchina.

L’analogia più onesta è quella del traduttore. Il modello è un lettore straniero molto attento ma che conosce solo la sua lingua: se gli consegni il testo originale non capisce nulla, per quanto sia intelligente. Il feature engineer è chi traduce. E come in ogni traduzione, si può perdere il senso o si può addirittura chiarirlo meglio dell’originale.

Il flusso: dal grezzo al modello

Il percorso tipico ha tre stazioni. Si parte dai dati grezzi — log, transazioni, testi, timestamp — che sono ricchi ma illeggibili per un algoritmo. Si passa per la costruzione delle feature: aggregazioni, rapporti, conteggi, codifiche. Si arriva al modello, che a quel punto fa un lavoro quasi banale: trovare pesi e soglie su variabili già eloquenti.

Il flusso del feature engineering: i dati grezzi vengono tradotti in variabili numeriche eloquenti, e solo allora il modello può imparare pesi e soglie.

Il punto controintuitivo è dove sta la difficoltà. La terza stazione — addestrare il modello — è oggi quasi una commodity: tre righe di scikit-learn o di XGBoost. La seconda è artigianato puro, e non esiste una libreria che la faccia al posto tuo, perché richiede di sapere cosa significano i dati.

Il repertorio di base

Alcune famiglie di trasformazioni tornano in quasi ogni progetto:

• Codifiche delle categorie. Un modello non digerisce «Milano, Roma, Napoli» come testo: serve one-hot encoding (una colonna binaria per città) o, quando le categorie sono migliaia, target encoding (sostituire la categoria con la media della variabile obiettivo per quella categoria — potente, ma da maneggiare con cura perché rischia di far trapelare informazioni dal futuro).
• Trasformazioni di scala. Il logaritmo dei prezzi, la radice dei conteggi: molte variabili reali hanno code lunghe, e comprimerle aiuta i modelli lineari a non farsi dominare dai valori estremi.
• Aggregazioni temporali. Media, massimo, conteggio negli ultimi 7, 30, 90 giorni. È il pane della previsione su serie storiche e sul comportamento utente.
• Interazioni e rapporti. Il rapporto tra debito e reddito dice più delle due variabili separate. Un modello ad alberi può scoprirlo da solo, ma dargli il rapporto già pronto gli risparmia profondità e dati.
• Feature di dominio. Le più preziose e le meno automatizzabili: la distanza dal negozio più vicino, il flag «primo acquisto dopo un reso», l’indice di massa corporea al posto di peso e altezza separati.

Dove si sbaglia: il leakage

Il pericolo principale del feature engineering ha un nome preciso: data leakage. Succede quando una feature contiene, anche indirettamente, informazione che al momento della previsione non sarebbe disponibile. L’esempio classico: prevedere se un paziente ha una malattia usando come feature «numero di esami specialistici prescritti» — esami che vengono prescritti proprio perché il medico sospetta la malattia. Il modello in validazione sembra formidabile; in produzione è inutile.

Una feature troppo buona per essere vera quasi sempre non è vera: sta copiando la risposta invece di predirla.

La difesa è disciplinare, non tecnica: per ogni feature bisogna chiedersi «questo dato esisteva già nel momento in cui avrei dovuto fare la previsione?». Le aggregazioni temporali vanno calcolate solo su finestre passate; il target encoding va fatto con schemi out-of-fold; la validazione, quando c’è una dimensione temporale, deve rispettarla — si addestra sul passato e si valuta sul futuro, mai il contrario.

E il deep learning non aveva risolto tutto?

Una promessa ricorrente del deep learning è che le feature le impara la rete: si parla infatti di representation learning. Su immagini, audio e testo è andata davvero così — nessuno oggi disegna a mano filtri per riconoscere i bordi, e i transformer costruiscono da soli rappresentazioni del linguaggio. Dove il dato è «percettivo» e abbondante, il feature engineering manuale è quasi sparito.

Sui dati tabellari — quelli di banche, ospedali, e-commerce, logistica, cioè la maggioranza dei problemi aziendali reali — la storia è diversa. I benchmark pubblici degli ultimi anni mostrano con costanza che il gradient boosting su feature ben costruite regge il confronto con le reti neurali, spesso vincendolo, con una frazione del costo computazionale. Il motivo è strutturale: in una tabella ogni colonna ha una semantica propria e i dati sono relativamente pochi; la rete non ha abbastanza esempi per riscoprire da sola ciò che un analista sa già.

C’è poi una via di mezzo sempre più comune: usare modelli pre-addestrati come generatori di feature. L’embedding di una descrizione prodotto prodotto da un language model, concatenato alle colonne tabellari classiche, dà spesso il meglio dei due mondi. Il feature engineering non è morto: ha cambiato strumenti.

Perché ti riguarda

Se lavori con i dati, la conseguenza pratica è una riallocazione del tempo. La tentazione — alimentata da tutorial e paper — è passare le giornate a confrontare modelli: e se provassi una rete più profonda, un boosting più aggressivo, l’ultimo AutoML? L’evidenza empirica di vent’anni di progetti e competizioni dice il contrario: un’ora spesa a capire i dati e a costruire una feature sensata rende quasi sempre più di un’ora spesa a ottimizzare iperparametri.

E c’è un corollario incoraggiante: il feature engineering è la parte del machine learning dove la conoscenza del dominio — il tuo mestiere, il tuo settore, quello che sai del comportamento dei tuoi clienti o dei tuoi macchinari — vale più di qualunque GPU. È il punto in cui un esperto di logistica con Python di base può battere un data scientist generico con un cluster. In un campo che sembra premiare solo la scala, è il posto dove l’esperienza umana resta il vantaggio competitivo. Conviene coltivarlo.