Questa sezione descrive in dettaglio la pipeline di addestramento.
Ottimizzazione della pipeline di input
Riepilogo: le cause e gli interventi delle pipeline vincolate all'input dipendono fortemente dall'attività. Utilizza un profiler e cerca problemi comuni.
Utilizza un profiler appropriato, ad esempio uno dei seguenti, per diagnosticare le pipeline vincolate all'input:
- Perfetto per JAX
- TensorFlow Profiler per TensorFlow.
In definitiva, le cause e gli interventi specifici dipendono molto dall'attività. Considerazioni ingegneristiche più ampie (ad esempio, ridurre al minimo l'ingombro del disco) possono influire negativamente sulle prestazioni della pipeline di input.
Di seguito sono riportate le cause comuni delle pipeline vincolate all'input:
- I dati non vengono collocati insieme al processo di addestramento, causando latenza I/O. Ad esempio, la lettura dei dati di addestramento su una rete potrebbe causare latenza I/O.
- Pre-elaborazione dei dati online costosa. Valuta la possibilità di eseguire il pre-elaborazione una volta offline e di salvare i risultati.
- Barriere alla sincronizzazione involontarie che interferiscono con il precaricamento della pipeline di dati. Ad esempio, quando sincronizzi le metriche tra il dispositivo e l'host in CommonLoopUtils.
Per le pipeline vincolate all'input, suggeriamo i seguenti interventi:
- Strumenta la pipeline di input per precaricare gli esempi (ad esempio, tf.data.Dataset.prefetch).
- Rimuovi le funzionalità e i metadati inutilizzati da ciascun elemento il prima possibile nella pipeline.
- Aumenta la replica del numero di job che generano esempi per la pipeline di input, ad esempio utilizzando il servizio tf.data.
Valutazione delle prestazioni del modello
Riepilogo: esegui la valutazione con batch di dimensioni maggiori rispetto all'addestramento. Esegui valutazioni a intervalli di passi regolari, non a intervalli di tempo regolari.
Impostazioni di valutazione
Puoi utilizzare le seguenti impostazioni per valutare il rendimento dei tuoi modelli:
- Valutazione online: raccogli metriche quando il modello fornisce previsioni in un ambiente di produzione. La valutazione online in genere fornisce la valutazione più realistica della qualità del modello perché corrisponde al modo in cui verrà utilizzato.
- Valutazione offline: raccogli le metriche quando il modello viene eseguito su set di addestramento, convalida o test offline rappresentativi dell'ambiente di produzione. A seconda del problema, la valutazione offline può essere piuttosto complessa e costosa dal punto di vista computazionale.
- Valutazioni periodiche: raccogli metriche durante l'addestramento del modello che potrebbero essere un proxy per la valutazione offline e/o su un sottoinsieme dei dati utilizzati nella valutazione offline. Le valutazioni periodiche sono la scelta più pratica ed economica, ma potrebbero non rappresentare completamente l'ambiente di produzione. Cerca di utilizzare un proxy rapido della valutazione offline, senza sacrificare l'affidabilità del segnale ricevuto durante l'addestramento.
Configurare valutazioni periodiche
Ti consigliamo di eseguire valutazioni periodiche durante l'addestramento per i seguenti motivi:
- Per monitorare l'avanzamento dell'addestramento in tempo reale.
- Per facilitare la selezione retrospettiva dei checkpoint del modello.
- Per esaminare le curve di addestramento alla fine dell'addestramento.
La configurazione più semplice consiste nell'eseguire sia l'addestramento che le valutazioni periodiche all'interno della stessa istanza di computing, alternando periodicamente l'addestramento e la valutazione. In questo caso, la dimensione del batch utilizzata per eseguire le valutazioni deve essere almeno pari alla dimensione del batch utilizzata per l'addestramento. Questo perché non è necessario mantenere le attivazioni del modello durante la valutazione, il che riduce i requisiti di calcolo per esempio.
Esegui valutazioni periodiche a intervalli regolari di passi, non di tempo. La valutazione in base agli intervalli di tempo può rendere più difficile l'interpretazione delle curve di addestramento, soprattutto quando l'addestramento può risentire di interruzioni dei job di addestramento, problemi di latenza di rete e così via.
La periodicità nelle metriche di convalida e test (quando si utilizza un set di addestramento, un set di convalida e un set di test suddivisi in modo casuale) può indicare bug di implementazione, ad esempio:
- Dati di test che si sovrappongono ai dati di addestramento.
- I dati di addestramento non vengono mischiati correttamente.
La valutazione a intervalli regolari può semplificare l'individuazione di questi problemi.
I batch parziali possono verificarsi quando i set di valutazione non sono divisibili per la dimensione del batch. Assicurati che gli esempi di padding siano ponderati correttamente (come nella media ponderata degli esempi che calcolano la perdita media sul batch) per evitare che la funzione di perdita sia influenzata da questi esempi. Spesso, puoi assegnare a questi esempi di riempimento un peso pari a zero.
Salva informazioni sufficienti per ogni valutazione per supportare l'analisi offline. Idealmente, salva le previsioni su una selezione di singoli esempi, in quanto possono essere preziose per il debug. La generazione di artefatti come SavedModels semplifica l'ispezione ad hoc del modello al termine dei job di valutazione.
Scelta di un campione per la valutazione periodica
Il job di valutazione periodica potrebbe non essere eseguito abbastanza rapidamente per calcolare le metriche sull'intero set di valutazione offline in un periodo di tempo ragionevole. Questo problema spesso richiede il campionamento dei dati per una valutazione periodica. Quando crei un set di dati campionati, considera i problemi relativi alle dimensioni del campione e i problemi speciali nei set di dati sbilanciati.
Dimensioni del campione
Verifica che il rendimento calcolato sul set di dati campionato utilizzato dal job periodico corrisponda al rendimento dell'intero set di valutazione offline, ovvero assicurati che non vi sia distorsione tra il set di dati campionato e il set di dati completo.
Il set di dati che utilizzi per la valutazione periodica deve soddisfare entrambi i seguenti requisiti:
- Abbastanza piccolo da generare facilmente previsioni del modello nella sua interezza.
- Abbastanza grande da consentire entrambe le seguenti operazioni:
- Misura con precisione i miglioramenti al modello, ovvero le misurazioni non devono essere influenzate dal rumore delle etichette.
- Consente di eseguire più valutazioni di questo tipo in sequenza nelle prove e di produrre stime accurate. ovvero sufficientemente grande da evitare di "adattarsi" in modo adattivo al set di convalida nel tempo in modo da non generalizzare a un set di test separato. Tuttavia, questa considerazione è raramente un problema pratico.
Set di dati sbilanciati
Per i set di dati sbilanciati, il rendimento delle classi minoritarie rare è spesso rumoroso. Per i set di dati con un numero ridotto di esempi di minoranze, registra il numero di esempi previsti correttamente per ottenere maggiori informazioni sui miglioramenti dell'accuratezza. Ad esempio, un miglioramento della sensibilità di 0,05 sembra entusiasmante, ma il miglioramento è dovuto solo a un esempio in più corretto?
Salvataggio dei checkpoint e selezione retrospettiva del checkpoint migliore
Riepilogo: esegui l'addestramento per un numero fisso di passaggi e scegli a posteriori il miglior checkpoint dell'esecuzione.
La maggior parte dei framework di deep learning supporta il checkpointing del modello. ovvero lo stato attuale del modello viene salvato periodicamente su disco. Il checkpoint consente al job di addestramento di essere resiliente alle interruzioni dell'istanza di calcolo. Il checkpoint migliore spesso non è l'ultimo, soprattutto quando il rendimento del set di convalida non continua ad aumentare nel tempo, ma oscilla intorno a un valore particolare.
Configura la pipeline per tenere traccia dei migliori N checkpoint visualizzati finora durante l'addestramento. Al termine dell'addestramento, la selezione del modello significa semplicemente scegliere il miglior checkpoint. Chiamiamo questo approccio selezione retrospettiva del checkpoint ottimale. In genere non è necessario supportare l'interruzione anticipata prospettica, perché specifichi in anticipo un budget di prova e conservi i migliori N checkpoint visti finora.
Configurare il monitoraggio degli esperimenti
Riepilogo: quando monitori diversi esperimenti, monitora una serie di elementi essenziali, come il rendimento migliore di un checkpoint nello studio e una breve descrizione dello studio.
Ti consigliamo di monitorare i risultati dell'esperimento in un foglio di lavoro. I nostri fogli di lavoro contengono spesso le seguenti colonne:
- Nome studio
- Un link alla posizione in cui è archiviata la configurazione dello studio.
- Note o una breve descrizione dello studio.
- Numero di prove eseguite
- Rendimento sul set di convalida del miglior checkpoint dello studio.
- Comandi di riproduzione specifici o note sulle modifiche non inviate necessarie per avviare l'addestramento.
Trova un sistema di monitoraggio pratico che acquisisca almeno le informazioni elencate sopra. Gli esperimenti non monitorati potrebbero non esistere.
Dettagli di implementazione della normalizzazione batch
Riepilogo: al giorno d'oggi, spesso puoi sostituire la normalizzazione batch con LayerNorm, ma nei casi in cui non puoi eseguire la sostituzione, ci sono dettagli complessi quando modifichi la dimensione batch o il numero di host.
La normalizzazione dei batch normalizza le attivazioni utilizzando la media e la varianza del batch corrente. Tuttavia, nell'impostazione multi-dispositivo, queste statistiche differiscono su ogni dispositivo, a meno che non vengano sincronizzate esplicitamente. Report aneddotici (principalmente su ImageNet) indicano che il calcolo di queste statistiche di normalizzazione utilizzando solo circa 64 esempi funziona meglio nella pratica. (Consulta la descrizione della normalizzazione batch fantasma in Train longer, generalize better: closing the generalization gap in large batch training of neural networks.) Il disaccoppiamento della dimensione totale del batch e del numero di esempi utilizzati per calcolare le statistiche di normalizzazione batch è particolarmente utile per i confronti della dimensione del batch.
Le implementazioni della normalizzazione batch fantasma non gestiscono sempre correttamente il caso in cui la dimensione del batch per dispositivo è maggiore della dimensione del batch virtuale. In questo caso, dovrai eseguire il sottocampionamento del batch su ogni dispositivo per ottenere il numero corretto di esempi di statistiche di normalizzazione batch.
Le medie mobili esponenziali (EMA) utilizzate nella normalizzazione batch in modalità test sono solo una combinazione lineare di statistiche di addestramento. Pertanto, devi sincronizzare queste medie mobili esponenziali solo prima di salvarle nei checkpoint. Tuttavia, alcune implementazioni comuni della normalizzazione batch non sincronizzano queste EMA e salvano solo l'EMA del primo dispositivo.
Considerazioni per le pipeline multi-host
Riepilogo: per logging, valutazioni, RNG, checkpoint e partizionamento dei dati, l'addestramento multihost può semplificare l'introduzione di bug.
Per le pipeline multi-host:
- Assicurati che la pipeline esegua la registrazione e il checkpoint su un solo host.
- Sincronizza le statistiche di normalizzazione batch tra gli host prima di valutare o creare checkpoint.
- Distribuisci i file di dati tra gli host, in quanto ciò di solito migliora le prestazioni.
Critico:assicurati di avere seed RNG uguali su tutti gli host (per l'inizializzazione del modello) e seed diversi su tutti gli host (per il rimescolamento/preelaborazione dei dati). Pertanto, assicurati di contrassegnarli in modo appropriato.