Suddivisioni e fughe di dati

La perdita di dati si verifica quando il modello ottiene dati durante l'inferenza, nel momento in cui il modello è in produzione e riceve richieste di previsione, a cui non dovrebbe avere accesso, ad esempio campioni di dati utilizzati per la formazione o informazioni che non saranno disponibili quando il modello viene distribuito in produzione.

Se il modello viene inavvertitamente testato su dati di addestramento, la perdita di dati potrebbe causare un sovraadattamento. Un sovradimensionamento significa che il modello non si generalizza bene sui dati invisibili. Questa sezione fornisce le migliori pratiche per evitare la perdita e l'overfit dei dati.

Dividi i dati in almeno tre set

Una fonte comune di perdita di dati è la divisione (suddivisione) impropria dei dati durante l'allenamento. Ad esempio, il data scientist potrebbe aver addestrato consapevolmente o inconsapevolmente il modello sui dati utilizzati per i test. In tali situazioni, è possibile osservare metriche di successo molto elevate causate dall'overfitting. Per risolvere questo problema, è necessario suddividere i dati in almeno tre set:training,validation, e. testing

Suddividendo i dati in questo modo, è possibile utilizzare il validation set per scegliere e ottimizzare i parametri utilizzati per controllare il processo di apprendimento (iperparametri). Quando hai raggiunto il risultato desiderato o raggiunto un livello di miglioramento costante, esegui una valutazione sul set. testing Le metriche delle prestazioni per il testing set devono essere simili alle metriche per gli altri set. Ciò indica che non vi è alcuna discrepanza di distribuzione tra i set e si prevede che il modello generalizzi bene in produzione.

Utilizzate un algoritmo di divisione stratificato

Quando dividi i dati in training e testing per piccoli set di dati o quando lavori con dati altamente squilibrati, assicurati di utilizzare un algoritmo di suddivisione stratificato. validation La stratificazione garantisce che ogni suddivisione contenga all'incirca lo stesso numero o distribuzione di classi per ogni suddivisione. La libreria ML scikit-learn implementa già la stratificazione, così come Apache Spark.

Per quanto riguarda la dimensione del campione, assicurati che i set di validazione e test contengano dati sufficienti per la valutazione, in modo da poter trarre conclusioni statisticamente significative. Ad esempio, una dimensione di suddivisione comune per set di dati relativamente piccoli (meno di 1 milione di campioni) è del 70%, 15% e 15% pertraining, validation e. testing Per set di dati molto grandi (più di 1 milione di campioni), è possibile utilizzare il 90%, il 5% e il 5% per massimizzare i dati di addestramento disponibili.

In alcuni casi d'uso, è utile suddividere i dati in set aggiuntivi, poiché i dati di produzione potrebbero aver subito cambiamenti radicali e improvvisi nella distribuzione durante il periodo in cui venivano raccolti. Ad esempio, prendiamo in considerazione un processo di raccolta dati per creare un modello di previsione della domanda per gli articoli dei negozi di alimentari. Se il team di data science raccogliesse i training dati nel corso del 2019 e testing i dati da gennaio 2020 a marzo 2020, un modello avrebbe probabilmente un buon punteggio sul testing set. Tuttavia, quando il modello viene impiegato nella produzione, il modello di consumo per determinati articoli sarebbe già cambiato in modo significativo a causa della pandemia del COVID -19 e il modello genererebbe scarsi risultati. In questo scenario, sarebbe opportuno aggiungere un altro set (ad esempiorecent_testing) come ulteriore protezione per l'approvazione del modello. Questa aggiunta potrebbe impedirvi di approvare un modello per la produzione che avrebbe immediatamente prestazioni scadenti a causa di una mancata corrispondenza nella distribuzione.

In alcuni casi, potreste voler creare testing set aggiuntivi validation o che includano tipi specifici di campioni, ad esempio dati associati a popolazioni minoritarie. Questi campioni di dati sono importanti da correggere, ma potrebbero non essere ben rappresentati nel set di dati complessivo. Questi sottoinsiemi di dati sono chiamati slice.

Prendiamo in considerazione il caso di un modello di machine learning per l'analisi del credito basato su dati relativi a un intero paese e bilanciato in modo da tenere conto in modo equo dell'intero dominio della variabile obiettivo. Inoltre, considera che questo modello potrebbe avere una City funzionalità. Se la banca che utilizza questo modello espande la propria attività in una città specifica, potrebbe essere interessata alle prestazioni del modello per quella regione. Pertanto, una pipeline di approvazione non dovrebbe solo valutare la qualità del modello sulla base dei dati dei test per l'intero paese, ma dovrebbe anche valutare i dati dei test per una determinata porzione di città.

Quando i data scientist lavorano su un nuovo modello, possono facilmente valutare le funzionalità del modello e tenere conto dei casi limite integrando sezioni sottorappresentate nella fase di convalida del modello.

Prendi in considerazione campioni duplicati quando esegui suddivisioni casuali

Un'altra fonte di perdita, meno comune, riguarda i set di dati che potrebbero contenere troppi campioni duplicati. In questo caso, anche se si dividono i dati in sottoinsiemi, diversi sottoinsiemi potrebbero avere campioni in comune. A seconda del numero di duplicati, l'overfitting potrebbe essere confuso con una generalizzazione.

Considerate le funzionalità che potrebbero non essere disponibili quando ricevete inferenze in fase di produzione

La perdita di dati si verifica anche quando i modelli vengono addestrati con funzionalità che non sono disponibili in produzione, nel momento in cui vengono richiamate le inferenze. Poiché i modelli sono spesso creati sulla base di dati storici, questi dati potrebbero essere arricchiti con colonne o valori aggiuntivi che non erano presenti in un determinato momento. Prendiamo in considerazione il caso di un modello di approvazione del credito dotato di una funzione che tiene traccia del numero di prestiti che un cliente ha concesso alla banca negli ultimi sei mesi. Esiste il rischio di una fuga di dati se questo modello viene implementato e utilizzato per l'approvazione del credito per un nuovo cliente che non ha una storia di sei mesi con la banca.

Amazon SageMaker Feature Store aiuta a risolvere questo problema. Puoi testare i tuoi modelli in modo più accurato con l'uso di query sui viaggi nel tempo, che puoi utilizzare per visualizzare i dati in momenti specifici.