Il data leakage è senza alcun dubbio la bestia nera e feroce che preda sul data scientist, giovane o senior che sia.
È quel fenomeno che può colpire proprio tutti - anche professionisti con anni di esperienza nel settore.
Insieme all'over/underfitting rappresenta la causa principale di fallimento di progetti di machine learning che vanno in produzione.
Ma perché il data leakage miete così tante vittime?
Perché anche dopo molti esperimenti e valutazioni nella fase di sviluppo, i nostri modelli possono fallire in maniera spettacolare in uno scenario di produzione.
Evitare il data leakage non è cosa semplice. Ora capirai perché leggendo il continuo dell'articolo 👇
Esempi di data leakage
Siamo degli sviluppatori di IA applicata e veniamo assunti da una azienda che fabbrica giocattoli per bambini in serie.
Il nostro compito è quello di creare un modello di machine learning per identificare se un giocattolo sarà oggetto di richiesta di rimborso entro 3 giorni dalla sua vendita.
Otteniamo i dati dalla fabbrica, sotto forma di immagini che catturano il giocattolo prima dell'inscatolamento.
Utilizziamo queste immagini per addestrare il nostro modello che performa molto bene in cross validazione e sul test set.
Consegnamo il modello e per il primo mese il cliente riporta solo il 5% di richieste di rimborso di giocattoli difettati.
Al secondo mese ci prepariamo per il retraining del modello. La fabbrica ci manda altre fotografie, che andiamo ad usare per espandere il dataset di addestramento iniziale.
Di nuovo, il modello performa bene in fase di cross-validazione e test.
Stavolta però riceviamo una comunicazione che i clienti stanno facendo richiesta e che di tali richieste, il 90% fanno riferimento ad un giocattolo difettato.
Iniziamo a guardare le foto....e notiamo che le foto inviate dal cliente nell'ultima batch mostrano i giocattoli oggetto di rimborso durante il primo mese.
Le nuove fotografie fornite dalla fabbrica includono involontariamente l'informazione riguardante la richiesta di rimborso entro 3 giorni dalla vendita del giocattolo.
In pratica il cliente ci ha mandato immagini selezionate dopo che la richiesta di rimborso è stata effettuata, quindi catturano caratteristiche specifiche dei giocattoli che sono stati restituiti. Questo può includere danni visibili o difetti evidenti che sono stati rilevati dal cliente e che hanno portato alla richiesta di rimborso.
Di conseguenza capiamo che il modello è molto abile a identificare specifici difetti, mostrando quindi una alta performance in fase di sviluppo ma non di produzione.
Tocca chiamare il cliente, spiegargli la situazione e pulire il dataset di addestramento.
Cause comuni di data leakage
Vediamo ora alcune delle cause più frequenti che portano al data leakage.
1. Sequenze temporali divise casualmente invece che sul tempo
Normalmente ci viene insegnato che dividere i dati set di addestramento, validazione e test in modo casuale sia la scelta corretta.
Molto spesso però i nostri dati possono essere correlati su base temporale, il che significa che la variabile temporale influenza la distribuzione delle nostre etichette.
Prendiamo ad esempio una serie temporale che viene dal mercato azionario.
Se dividessimo in modo casuale tale dataset, il data leakage si manifesterebbe al 100%.
Questo perché dati di giorni successivi verrebbero casualmente mischiati al dataset di addestramento. Il nostro modello sarebbe esposto alle etichette "corrette" senza doverle apprendere.
È un po' come se un ragazzo a scuola avesse le risposte corrette al test che sta facendo. Prestazioni alte, ma conoscenza molto bassa.
Per evitare il problema, è utile dividere i dati in base al tempo: ad esempio se abbiamo dati per un mese, addestriamo il modello sui primi 20 giorni, e testiamo sui restanti 10, in maniera sequenziale.
2. Trasformare i dati prima di dividerli
Questa è una delle cause più comuni tra i neofiti della data science.
Ecco come si manifesta questo errore
from sklearn import model_selection
from sklearn import preprocessing
# ...
scaler = preprocessing.StandardScaler()
data = scaler.fit_transform(data)
train, test = model_selection.train_test_split(data, test_size=0.2, random_state=42)
# ...L'errore è quello di scalare tutti i dati prima di dividerli in set di addestramento e test.
In questo caso, l'oggetto scaler richiede di conoscere la media e la deviazione standard del dataset alla quale è applicato.
Fornendogli tutto il dataset, questo avrà immagazzinato e usato anche informazioni dal test set, che andranno a spostare la media e la deviazione standard.
Per risolvere questo problema, dividi sempre i tuoi dati prima di applicare una trasformazione come lo scaling.
3. Riempire i dati mancanti con informazioni provenienti dal test set
Un po' simile al punto sopra, ma da un altro angolo.
Un metodo comune per imputare i dati mancanti di una colonna è quella di riempire le celle con la media o mediana di tutti i dati presenti nella colonna.
Se la media viene calcolata anche sui valori che appartengono al test set, stiamo generando leakage nel training set.
Anche qui, dividiamo i nostri dati prima di applicare l'imputazione.
4. Mancata rimozione dei duplicati
Se abbiamo dei record duplicati nel nostro dataset, c'è il rischio che alcuni di questi possano apparire sia in training che in test set.
Da qui, il leakage. Il nostro modello sarà chiaramente abile nel predire il valore di tali duplicati, riducendo l'errore di predizione considerevolmente (ma in maniera errata).
Per evitare questo errore, occorre rimuovere i duplicati prima di effettuare il train-test split.
Se per caso facciamo oversampling, cioè creare dei duplicati artificiali per addestrare un modello su un dataset sbilanciato, allora occorre farlo dopo aver splitatto i dati.
5. Processo di generazione dei dati sbagliato
Come l'esempio di cui sopra della fabbrica di giocattoli.
A volte il leakage proviene da come vengono generati e consegnati i dati su cui dobbiamo addestrare il modello.
Non c'è modo per evitare questo scenario. Dobbiamo solo essere vigili, fare domande e non dare nulla per scontato, soprattutto quando non siamo in controllo del processo di generazione dei dati proprio come nel caso della fabbrica di giocattoli.
In generale, il consiglio è sempre di controllare i dati se questi non vengono processati / consegnati da un team di data science
Conclusioni
Hai imparato cosa è il data leakage e perché è così difficile da gestire, anche per data scientist esperti.
Le sue insidie si nascondono nei dettagli, che possono essere facilmente ignorati durante la scrittura di codice.
Gli esempi che ti ho mostrato dovrebbero aiutarti a valutare se il tuo progetto è vittima di leakage.
Di solito, se noti performance molto alte in fase di sviluppo, controlla sempre per il leakage.
Non vogliamo mai che il nostro modello fallisca in produzione!
Alla prossima,
Andrea
Commenti dalla community