Perché solo tre partizioni? (formazione, validazione, test)

Quando si tenta di adattare i modelli a un set di dati di grandi dimensioni, il consiglio comune è quello di suddividere i dati in tre parti: formazione, convalida e set di dati di test.

Questo perché i modelli di solito hanno tre "livelli" di parametri: il primo "parametro" è la classe del modello (ad esempio SVM, rete neurale, foresta casuale), il secondo set di parametri sono i parametri di "regolarizzazione" o "iperparametri" ( ad es. coefficiente di penalizzazione del lazo, scelta del kernel, struttura della rete neurale) e il terzo insieme sono quelli che sono generalmente considerati i "parametri" (ad es. coefficienti per le covariate).

Data una classe di modello e una scelta di iperparametri, si selezionano i parametri scegliendo i parametri che minimizzano l'errore sul set di addestramento. Data una classe di modello, si ottimizzano gli iperparametri minimizzando l'errore sul set di validazione. Uno seleziona la classe del modello in base alle prestazioni sul set di test.

Ma perché non più partizioni? Spesso si possono dividere gli iperparametri in due gruppi e utilizzare una "validazione 1" per adattarsi alla prima e "validazione 2" per adattarsi alla seconda. Oppure si potrebbe anche trattare la dimensione dei dati di allenamento / dati di validazione divisi come un iperparametro da sintonizzare.

È già una pratica comune in alcune applicazioni? C'è qualche lavoro teorico sul partizionamento ottimale dei dati?

machine-learning model-selection data-mining

— charles.y.zheng
fonte

Risposte:

Innanzitutto, penso che ti sbagli su ciò che fanno le tre partizioni. Non effettuare alcuna scelta in base ai dati del test. I tuoi algoritmi regolano i loro parametri in base ai dati di allenamento. Quindi li esegui sui dati di convalida per confrontare i tuoi algoritmi (e i loro parametri addestrati) e decidere un vincitore. Quindi esegui il vincitore sui tuoi dati di test per darti una previsione di come andrà nel mondo reale.

Non convalidi i dati di allenamento perché ciò si adatterebbe troppo ai tuoi modelli. Non ti fermi al punteggio del vincitore del passaggio di convalida perché hai modificato in modo iterativo le cose per ottenere un vincitore nel passaggio di convalida, quindi hai bisogno di un test indipendente (che non ti stai adattando in modo specifico) per darti un idea di quanto bene farai al di fuori dell'arena attuale.

Secondo, ritengo che un fattore limitante qui sia la quantità di dati che hai. Il più delle volte, non vogliamo nemmeno dividere i dati in partizioni fisse, quindi CV.

— Wayne
fonte

Il problema concettuale che ho avuto è che se si confrontano abbastanza modelli, si stanno adattando efficacemente i dati di validazione quando si "decide su un vincitore" usando i dati di validazione. Quindi può ancora essere un punto nel partizionamento dei dati di validazione.

— charles.y.zheng,

Penso che il livello di convalida dell'allenamento e il livello di verifica della convalida servano in qualche modo a scopi diversi e che alla fine dovrai confrontare i modelli su un set di convalida comune se intendi dichiarare un vincitore. Quindi non sono sicuro che i livelli aggiuntivi aiutino. (Anche se la mia conoscenza non è abbastanza approfondita da saperlo davvero.) La cosa più vicina a cui posso pensare al tuo suggerimento è come è stata organizzata la competizione Netflix. Credo che abbiano usato set di test parziali per impedire ai team di salire sul gradiente del set di test, ma penso che sia diverso.

— Wayne,

@ user10882, il tuo commento non è corretto, né Firebugs. Entrambi i parametri del modello (1) (pesi, soglie) e (2) i cosiddetti parametri "iper" (numero di strati nascosti, numero di alberi decisionali) possono avere interpretazioni e sensazioni molto diverse, ma sono tutti solo parametri che distinguono tra differenti modelli . Usa i dati di addestramento per ottimizzarli tutti, usa i dati di validazione per evitare un eccesso di adattamento e usa la validazione incrociata per assicurarti che i risultati siano stabili. I dati del test servono solo per specificare le prestazioni previste del modello, non utilizzarlo per accettarlo / rifiutarlo.

— Ytsen de Boer,

@RubenvanBergen: ho capito cosa dici ed è utile e utile segnalarlo a user10882. Ma continuo a sostenere che si tratta in definitiva di un tecnicismo. Supponi di utilizzare un algoritmo di discesa gradiente che utilizza i dati di allenamento per inferire la direzione del passo (incluso il grado polinomiale ) insieme a una procedura di convalida che aggiunge la perdita di convalida alla perdita di allenamento in ciascun passaggio dell'algoritmo di discesa gradiente (simile al primo arresto). Ora la differenza tra "normale" o "iper" non è più rilevante: dipende dalla procedura.

n

$n$

— Ytsen de Boer,

@YtsendeBoer: Abbastanza giusto - se usi sth come l'arresto anticipato basato sulla validazione, sono d'accordo che i confini si offuscano, almeno in termini di procedura di ottimizzazione. A mio avviso, tuttavia, ciò non fonde pienamente il concetto di "iperparametro" con quello di un normale. Ci sono ancora molte situazioni in cui vengono trattate in modo diverso e penso anche a loro in modo diverso in termini di ruoli nella definizione di un modello. Ad ogni modo, spero che questa discussione sia stata utile ad altri per illustrare le differenze (sottili) e le somiglianze tra questi concetti =).

— Ruben van Bergen,

Questa è una domanda interessante, e l'ho trovato utile con la risposta di @Wayne.

Dalla mia comprensione, la divisione del set di dati in una diversa partizione dipende dallo scopo dell'autore e dai requisiti del modello nell'applicazione nel mondo reale.

Normalmente abbiamo due set di dati: allenamento e test. Quello di formazione viene utilizzato per trovare i parametri dei modelli o per adattarli. Quello di test viene utilizzato per valutare le prestazioni del modello in dati invisibili (o dati del mondo reale).

Se facciamo solo un passo nella formazione, è ovvio che ci sono una formazione e un processo di verifica (o convalida).

Tuttavia, in questo modo, potrebbe sollevare il problema di adattamento eccessivo quando il modello viene addestrato con un set di dati, una volta. Ciò può portare all'instabilità del modello nel problema del mondo reale. Un modo per risolvere questo problema è la convalida incrociata (CV) del modello nel set di dati di addestramento. Ciò significa che dividiamo il datset di allenamento in diverse pieghe, ne manteniamo una per testare il modello che viene allenato con altre pieghe. Il vincitore è ora quello che dà la perdita minima (in base alla nostra funzione oggettiva) nell'intero processo CV. In questo modo, possiamo assicurarci di ridurre al minimo le possibilità di adattamento eccessivo al processo di allenamento e selezionare il vincitore giusto. Il set di test viene nuovamente utilizzato per valutare il vincitore nei dati invisibili.

— Dao Vu Hoang
fonte