In questo post capiremo cosa intendiamo per Features Engineering e come questa semplice pratica costuisca un key point di ogni processo di machine learning applicato alla Data Analysis: it’s Data Science Dude!
Recap Generico | Andrea dov’eri finito? Ancora sta Big Mart?
Lunedì 7 febbraio 2019, il mio primo giorno di lavoro, pubbicai “Fine siesta: data scientist? Ancora tanto da fare. Partiamo!” nell’itento di coprire un gar di alcune settimane e riprendere in mano il sito.
Ero carico.
Dannatemente carico.
Pensavo di avere solo due grandi problematiche da gestire: il sito, e il percorso da data scientist che ancora non esisteva.
In realtà stavo per frangermi su uno scoglio troppo alto: il tempo.
Nei giorni, nelle settimane e persino nei mesi successivi alla pubblicazione di quel post avrei avuto davvero poco tempo libero, peraltro di poca qualità a causa della stanchezza.
Ahimé ignoravo ogni cosa.
Così quasi 2 stagioni dopo, eccomi nuovamente qui.
Questa volta però, poco più saggio di prima e conscio degli impegni a venire, eviterò di annunciare al vento progetti e aspettative, limitandomi a presentarti di volta in volta ciò che sono riuscito davvero a realizzare!
Let’ start! As a reminder: it’s data science, dude!
Andrea Provino
Ecco, in breve cosa aspettarti.
Riprenderemo in mano, si spera definitivamente, il progetto Big Mart Sales che avevamo lasciato in sospeso e lo faremo per 3 ragioni:
- coerenza, ho detto che avremmo concluso questo progetto e ora è arrivato il momento di porvi fine.
- continuità, lasciare progetti aperti è fastidioso per me, ma sopratutto per te che puoi leggere post a distanza di 8 mesi in pochi minuti!
- competenza, che ora abbiamo acquisito grazie ad un corso online profesionale.
Recap Progetto | Dall’EDA al Features Engineering!
Il tempo trascorso tra un post e quello successivo è così elevato che è stato necessario rileggere gli articoli così da avere un’idea del Stato Avanzamento Lavori (SAL). Ecco un veloce riassunto:
- Big Mart Sales: Report preliminare | Towards Data Science, qui puoi trovare il post di presentazione del progetto con una breve Data Analysis
- Big Mart Sales | Exploratory Data Analysis: Domande, questo post è invece un Exploratory Data Analysis più approfondito
In questi mesi ho imparato che un bravo Data Scientist ogranizza il proprio lavoro di analisi e machine learning applicato in macrosezioni. L’Exploratoy Data Analsys (o Data Analysis, non cambia nulla) è solo il primo step.
Purtroppo quegli articoli, seppur realizzati con attenzione meticolosa per gli argomenti trattati, sono superficiali e mancano di una reale organizzazione del lavoro.
Per questa ragione, nell’analisi che sto realizzando in jupyter notebook e che pubblicherò, ho seguito un percorso diverso.
Mi rendo conto che risulti tutto un po’ nebuloso. Prossimamente sarò quanto più chiaro possibile, in modo da darti tutti gli strumenti per seguire il mio percorso!
Completata la fase preliminare di esplorazione andrò veloce sulla pulizia dei dati e passerò rapidamente al core del Post: Features Engineering.
Data Cleaning
Questo task è mandatorio poiché la maggioranza degli algoritmi di machine learning non gradisce i NaN (Not A Number).
Ora, esistono molteplici scuole di pensiero che in soldoni distinguiamo in:
- eliminare le osservazioni conteneti i NaN (da scartare se le dimensioni del Dataset sono modeste)
- convertire i NaN usando la media dei valori all’interno della features di appartenenza (per le features numeriche generalmente una delle practice più comune)
- convertire i NaN in 0 creando una nuova feature indicatoria (indicator feature) che consenta agli algoritmi di ‘imparare la mancanza del dato’
Ti faccio notare che negli utlimi due punti del precedente elenco mi riferivo alle sole numeric features. Per le categorical features la best practice è sostituire i NaN con la label ‘Missing’.
Un rapido recap:
- Numeric Features: flag and fill
- Categorical Features: simply fill with ‘Missing’
Per il nostro dataset, loperazione di pulizia dei dati (Data Cleaning) è avvenuta con successo andando ad influenzare ben 3 features.
Prima 
Dopo
Abbiamo poi corretto alcuni errori nei nomi delle classi per la fetaure Item_Fat_Content (Typos) e aggiunta una nuova classe dal momento che gli oggetti non consumabili non hanno un valore di grasso…
Make sense
Features Engineering
La feature Item_Type conteneva 16 classi: un po’ troppe.
Abbiamo creato una nuova features omonima (quindi in realtà si è trattato si un overwriting) il cui criterio discrimiante è basato sulle prime due lettere dell’Item_Identifier, che abbiamo notato avere una particolarità.
Infatti ogni Item è identificato univocamente da un ID composto in questo modo:
[category][alphabeth_letter][2_number_digits] category = [FD,NC,DR] alphabeth_letter = [A-Z]
Per questo abbiamo selezionato le sole prime due lettere e creato una nuova feature classificatoria.
Abbiamo inoltre creato la feature Outlet_Age prendendo come riferimento l’anno di apertura dell’outlet e 2013 (anno di raccolta dati).
Dropping Features
In questa prima iterazione, lasceremo alcune feature che pensiamo possano non influenzare la previsione per due motivi:
- intuizione (es, l’id di un prodotto non pregiudica il prezzo)
- mappa di correlazione (che mostra se e in che misura due features dipendono tra loro)
Quindi elimineremo:
- Item_Identifier
- Outlet_Establishment_Year (create
- Outlet_Identifier*
*Outlet_Identifier è in realtà una fetures che potremmo dover tenere. Il nostro stakeholder ha chiesto di prevedere le vendite di un prodotto in un particolare Outlet. E’ tuttavia poco chiaro se la richiesta indende esattamente un negozio (tramite ID), oppure un outlet-tipo (identificato da grandezza, posizione, e tipologia)
Quindi nel dubbio lo teniamo, ed eventualmente modificheremo in una successiva iterazione.
Per questo Post è tutto! Io e te, ci vediamo alla prossima!
It’s data science, dude!
Andrea Provino
