Le prestazioni di convalida incrociata saranno un'indicazione accurata per prevedere le prestazioni reali su un set di dati indipendente?


9

Ritengo che questa domanda sia collegata alla teoria alla base della convalida incrociata. Vi presento il mio empirica qui e ho scritto una domanda relativa alla teoria della convalida incrociata in .

Ho due modelli M1 e M2, utilizzo lo stesso set di dati per addestrarli ed eseguire la convalida incrociata utilizzando lo stesso set di dati per trovare i parametri ottimali per ciascun modello. Diciamo che alla fine ho scoperto che M1 con il suo parametro ottimale, funziona meglio di M2 con il suo parametro ottimale in termini di punteggio di convalida incrociata di 10 volte. Ora, se ho un altro set di dati di test indipendenti con predittori ed etichette e questo set di dati di test viene generato dalla stessa distribuzione del mio set di dati di allenamento, quindi prima di applicare questi 2 modelli ben calibrati su quel nuovo set di dati di test, posso rivendicazione o dovrei aspettarmi di vedere che M1 continuerà a funzionare meglio di M2 rispetto a quel nuovo set di dati di test?

Stavo giocando l'esempio di Kaggle Titanic. Ho 2 modelli xgboost, M1 è ottimizzato e M2 è meno ottimizzato, nel senso che M1 ha una migliore validazione incrociata di 10 volte sul set di dati di allenamento. Ma poi quando ho presentato entrambi, ho scoperto che il modello meno ottimizzato in realtà ha un punteggio migliore nel set di dati di test. Come potrebbe essere? E se è vero, allora cosa dovremmo cercare quando adattiamo i dati a modelli diversi e ottimizziamo i parametri del modello?

Ecco i miei risultati di presentazione specifici: ho fatto una ricerca casuale della griglia

params_fixed = {'silent': 1,'base_score': 0.5,'reg_lambda': 1,
'max_delta_step': 0,'scale_pos_weight':1,'nthread': 4,
'objective': 'binary:logistic'}
params_grid = {'max_depth': list(np.arange(1,10)),
'gamma': [0,0.05,0.1,0.3, 0.5,0.7,0.9],
'n_estimators':[1,2,5,7,10,15,19,25,30,50], 
'learning_rate': [0.01,0.03,0.05,0.1,0.3,0.5,0.7,0.9,1],
'subsample': [0.5,0.7,0.9], 'colsample_bytree': [0.5,0.7,0.9], 
'min_child_weight': [1,2,3,5], 'reg_alpha': [1e-5, 1e-2, 0.1, 0.5,1,10]
}
rs_grid = RandomizedSearchCV(
          estimator=XGBClassifier(**params_fixed, seed=seed),
          param_distributions=params_grid,
          n_iter=5000,   
          cv=10,
          scoring='accuracy',
          random_state=seed
)

Ogni volta che cambio la variabile n_iter. Innanzitutto, ho impostato n_iter=10, mi dà un insieme di valori di quegli iperparametri, chiamiamo questo vettore e il punteggio cv (tasso di precisione) è 0,83389 , quindi uso per addestrare il mio modello e generare previsione sul test indipendente set di dati, e quando invio a Kaggle genera una vera precisione sul set di dati di test 0.79426α1α1

In secondo luogo, ho impostato n_iter=100, mi dà e il punteggio CV è 0,83614 , vale a dire, più alto del primo, ha senso, ma quando mi sottometto a Kaggle, 0,78469 , inferiore al primo.α2

Terzo, ho impostato n_iter = 1000, mi dà e il punteggio cv è 0,83951 , vale a dire, più alto del secondo, ha senso, ma quando mi sottometto a Kaggle, 0,77990 , inferiore al secondo.α3

In quarto luogo, ho impostato n_iter = 5000, mi dà e il punteggio cv è 0,84512 , vale a dire, più alto del terzo, ha senso, ma quando mi sottometto a Kaggle, 0,72249 , inferiore al terzo.α4

Questo è davvero frustrato. Il modello sta migliorando sempre di più nel punteggio di convalida incrociata ma, se eseguito su un set di dati indipendente reale, le sue prestazioni stanno peggiorando. Ho interpretato i punteggi del CV in modo esattamente opposto? Vedo alcuni articoli menzionati che il punteggio CV può essere troppo ottimista per dedurre il punteggio del test vero. Tuttavia, anche se questo è vero, penso che i punteggi CV per tutti i miei 4 modelli dovrebbero essere tutti ottimisti riguardo al proprio punteggio di test vero, cioè l'ordine dovrebbe preservare. Ma quando si applica sul set di dati di test reali, l'ordine si inverte.

L'unica ragione che posso immaginare sarebbe che quel set di dati di test ha una distribuzione diversa rispetto al set di dati di training. Tuttavia, se è davvero il caso, credo che non esista un metodo sotto il sole per curare questo problema.

Risposte:


3

Prima di tutto, una risposta pragmatica: non scartare la possibilità che il set di test provenga da una distribuzione leggermente diversa rispetto al set di dati che si sta utilizzando per la formazione e la convalida incrociata. Potresti pensare che non dovrebbe succedere, ma in pratica sembra accadere.

Detto questo, andiamo con il tuo ipotetico e supponiamo che il set di test provenga esattamente dalla stessa distribuzione del resto dei tuoi dati. In tal caso, è possibile che la convalida incrociata ti porti fuori strada su quale modello sia migliore, se stai utilizzando la convalida incrociata per selezionare gli iperparametri.

È possibile utilizzare la convalida incrociata per (a) selezionare gli iperparametri o (b) stimare l'accuratezza del modello, ma non entrambi contemporaneamente.

Sembra che tu stia utilizzando la convalida incrociata per selezionare gli iperparametri ottimali: provi molte diverse scelte per gli iperparametri, per ogni scelta stimare l'accuratezza di quella scelta usando la convalida incrociata e selezionare la scelta migliore. Quando lo fai, non c'è garanzia che l'accuratezza risultante (con il miglior parametro) sia predittiva delle prestazioni sul set di test - potrebbe essere una sopravvalutazione (a causa di un eccesso di adattamento). Se è più sopravvalutato per M1 che per M2, potresti vedere quello che hai visto.

Se si desidera sia selezionare i parametri ipertestuali sia stimare l'accuratezza, suggerisco di disporre di un set di convalida separato per la stima dell'accuratezza o di utilizzare la convalida incrociata nidificata. Vedi https://stats.stackexchange.com/q/65128/2921 e http://scikit-learn.org/stable/auto_examples/model_selection/plot_nested_cross_validation_iris.html .


Conosci altri riferimenti più teorici (dal lato della teoria della probabilità) che spiegano perché è necessario un CV nidificato rispetto a un CV semplice per la selezione del modello? Voglio capire il meccanismo sottostante che porta al problema che avevo riscontrato
KevinKim,

1
Suggerisco anche di utilizzare la convalida incrociata nidificata. se stai facendo un CV esterno di 3 volte e un CV interno di 10 volte, potrai testare i 3 modelli che ti alleni durante i CV interni su tre set di dati diversi; che ti darà una migliore comprensione di come il tuo processo di costruzione del modello finirà per funzionare quando incontra diversi set di dati.
darXider,

@darXider Ho letto alcuni dei CV nidificati, sembra che sia usato per confrontare 2 classi di modelli, ad esempio RF e GBT in modo tale che nel CV interno, scelga l'iperparametro "migliore" (errore CV più basso) di RF e GBT rispettivamente, quindi nel CV esterno, calcola l'errore di generalizzazione di RF e GBT con gli iperparametri scelti dal CV interno. Nel mio caso, ho solo una classe di modello, GBT, voglio eseguire il tuning dell'iperparametro. In che modo il cv nidificato mi aiuta a farlo?
KevinKim,

@KevinKim AFAIK, l'obiettivo del CV nidificato è quello di dare un'idea di come il processo di costruzione del modello si generalizzerà e non di confrontare diverse classi di modelli. Poiché il tuo obiettivo finale è quello di utilizzare il tuo modello addestrato (sia RF che XGB) su dati futuri / invisibili, potresti usare una migliore comprensione delle sue prestazioni se usi un CV nidificato. Ovviamente, fai anche l'ottimizzazione dell'iperparametro nel tuo CV nidificato 3x10; alla fine, otterrai, per esempio, 3 modelli XGB che sono equivalenti tra loro (nota che non dovresti scegliere uno dei tre, ma puoi combinarli, diciamo, usando vari metodi di assemblaggio).
darXider,

1

posso richiedere o devo aspettarmi di vedere che M1 continuerà a funzionare meglio di M2 rispetto a quel nuovo set di dati di test?

Si, dovresti. Naturalmente alle condizioni che

  1. i dati del test provengono dallo stesso processo di generazione dei dati di addestramento e convalida e
  2. disponi di dati sufficienti in ciascun set per rendere improbabili le fluttuazioni statistiche.

Il modello sta migliorando sempre di più nel punteggio di convalida incrociata ma, se eseguito su un set di dati indipendente reale, le sue prestazioni stanno peggiorando.

Posso pensare a due motivi:

  1. Il set di dati di test non viene infatti generato allo stesso modo. Pertanto, è meglio non fare affidamento sul set di test Kaggle a cui non si ha accesso. Usa i dati che hai.

  2. Stai esagerando, il che significa che non stai eseguendo correttamente la validazione incrociata. Assicurati davvero che l'addestramento dei parametri avvenga sui dati dell'allenamento e, allo stesso tempo, che la convalida avvenga sui dati che non hai utilizzato per l'allenamento. Confronta gli istogrammi delle perdite di addestramento e le perdite di validazione. Le perdite di addestramento dovrebbero essere costantemente inferiori alle perdite di validazione. Fare lo stesso per le perdite sui dati del test per ottenere un'immagine coerente.

Come e nota finale: è prevedibile che le prestazioni sul set di test siano inferiori a quelle sul set di validazione. Questo perché il modello viene scelto in base al set di convalida. Quindi è distorto da quel set di dati.


Ho il codice nel mio post, non credo di aver abusato della procedura CV (hai trovato qualcosa di sbagliato nel mio codice?). E in effetti ho visto che l'errore di addestramento è molto meno e stabile (con un piccolo standard) rispetto all'errore di validazione. Capisco che il vero errore del test sarà superiore all'errore di convalida, ma mi aspetto che ciò accada anche a tutto il mio modello (intendo XBGT con diverso valore degli iperparametri). Da quello che ho visto, sembra che alcuni modelli ciò avvenga meno di altri modelli, il che crea questo "fenomeno inverso". Quindi non so quale direzione sto cercando di mettere a punto l'iperpara
KevinKim,

Ho visto molte persone suggerire di rompere il Din 3 parti, treno, validazione e test, e dopo aver messo a punto hyperP nel set di validazione, quindi applicare il modello sul set di test per vedere come questo modello si comporterà su un test reale (dato che anche il passaggio di validazione ha dei bias). Quindi, dopo il test, interrompi la sintonizzazione dell'hyperP, come se lo facessi, inizierà anche a ottenere bias (come nel set di validazione). Capisco. Ma se dopo il set di test non sono ancora soddisfatto delle prestazioni del mio modello, cosa devo fare?
KevinKim,

Penso in pratica, anche se viviamo in un mondo di "big data", anche il numero di funzionalità è in aumento. Dato che abbiamo la maledizione della dimensione, è molto probabile che abbiamo anche un numero enorme di righe, ancora per ogni parte dello spazio delle caratteristiche, non abbiamo ancora abbastanza punti dati. Quindi la fluttuazione statistica è sempre lì. Quindi mi chiedo se questa procedura di ottimizzazione dell'hyperP sia ancora corretta o utile per ottenere un modello con buone prestazioni su set di dati di test reali? Se il CV non è utile per svolgere questa attività, qual è la procedura corretta?
KevinKim,

Verifica se le perdite di addestramento nella tua procedura di validazione sono comparabili tra loro, cioè coerenti. In caso contrario, prova con un altro modello / selezione di funzionalità. Non continuare fino a quando non avrai questo diritto. Quindi fai la stessa cosa per le perdite di convalida. Se questi non sono comparabili, prova un altro modello / selezione funzionalità / metodo di convalida. Quando lo sono, procedere con il set di test. Se la perdita non ti soddisfa, respingi la procedura completa e prova qualcos'altro. Se si avvia l'ottimizzazione utilizzando il set di test, non è possibile fare affidamento sulle prestazioni dal vivo, poiché saranno distorte dal set di test.
Ytsen de Boer,

0

È possibile. Pensa a uno scenario semplice in cui il modello M1ha appreso la varianza del set di dati di training Dmeglio del modello M2poiché i suoi parametri sono ottimizzati. Questo significa M1prestazioni migliori Ddi M2.

Ma quando li testiamo sul set di test T, è possibile che M2funzioni meglio come M1potrebbe essere un overfitting Dmentre M2non lo era. Quindi M1funziona peggio Tdi M2.

Ciò potrebbe essere dovuto al fatto che hai eseguito la convalida incrociata sullo stesso set di dati anziché su un set di convalida. Se ti alleni e convalidi nello stesso set, è probabile che ti manchi il fatto che potrebbe essere troppo adatto. Quindi è sempre meglio addestrare, validare e testare su diversi set di dati. Quindi il flusso dovrebbe essere

  1. Allena diversi modelli nello stesso set di allenamento
  2. Convalidato al set di convalida
  3. Scegli le prestazioni base del modello con le migliori prestazioni al set di validazione
  4. Usalo per segnare il tuo set di test.

Tuttavia, la convalida incrociata sul set di dati Dha già tenuto conto dei problemi di overfitting. Comprendo che se non si esegue affatto la convalida incrociata, vale a dire che si adatta il modello al set di dati De si risolve quel problema di ottimizzazione e si ottengono i parametri ottimali, quindi questo modello avrà l'errore di treno minimo ed è molto probabile un eccesso. In questo caso, sono d'accordo che questo optimizedmodello tenderà a funzionare male su un set di dati di test indipendenti. Ma penso che questo problema sia stato curato dalla validazione incrociata sul set di dati D, non è vero?
KevinKim,

1
In particolare, quando esegui un CV di 10 volte D, prima tagli Din modo casuale in circa 10 pezzi di uguali dimensioni, quindi in ogni iterazione, inserisci M1 e M2 sullo stesso 9/10 di D, quindi li applichi lo stesso 1 / 10 di Dottenere il tuo test error, quindi ripeti questo processo 10 volte e ogni volta, il set di treni e set di test è diverso dall'iterazione precedente. Quindi, dopo 10 iterazioni, si calcola la media dell'errore di test per M1 e M2, quindi si riscontra che M1 ha meno errore di test, quindi non è sufficiente concludere che M1 è migliore di M2 e questa procedura sembra aver già curato l'
overfit

Sì, è sufficiente concludere che "M1 è meglio di M2". Tuttavia, se la procedura di selezione del modello si riduce alla selezione di M1 in base alle prestazioni di convalida , la scelta del modello migliore (M1 in questo caso) è distorta dal set di convalida. Da qui la necessità di un controllo finale sul set di test, per ottenere un'indicazione di quanto bene si esibirà sui dati live.
Ytsen de Boer,

@YtsendeBoer Finalmente mi sono convinto di quello che hai detto. Sono d'accordo. Ma poi, se su un altro set di test indipendente, ho scoperto che M1 è peggiore di M2 (il richiamo M1 è migliore di M2 sul set di validazione), quindi in questo caso, dovrei scegliere M1 o M2 come modello finale per fare una vera previsione nel futuro? Se scelgo M1, allora chiaramente il risultato del test contro M1. Ma se scelgo M2, anche M2 non si adatta a questo specifico set di dati di test? vale a dire, allo stesso modo di M1 overfitting sul set di convalida specifico?
KevinKim,

Sì, è esattamente per questo che non dovresti fare la selezione del modello sul set di test. Hai selezionato M1 nella procedura di selezione del modello utilizzando il set di convalida. Quindi esegui M1 sul set di test e decidi se il risultato è abbastanza buono. Dimentica M2 a questo punto, anche se sembra funzionare meglio su un altro set di test. Se, tuttavia, hai dei dubbi sui tuoi risultati, allora dovresti aggiungere il tuo "altro set di test indipendenti" al resto dei tuoi dati (più dati sono migliori), riavviare la procedura e attenersi ad essa .
Ytsen de Boer,

0

La teoria alla base della validazione incrociata (v-fold cross validation) è stata affrontata in molti articoli. Ne è una prova in una serie di articoli pubblicati dal 2003-2007. Fare riferimento a: - selettore dell'oracolo. 2006 - super discente 2007 - super discente nella previsione 2010 - convalida incrociata unificata 2003

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.