Indicazioni aggiuntive per la pipeline di addestramento

Questa sezione descrive in dettaglio la pipeline di addestramento.

Ottimizzazione della pipeline di input

Riepilogo: le cause e gli interventi delle pipeline con input dipendono dall'attività. Utilizza un profiler e fai attenzione ai problemi comuni.

Utilizza un profiler appropriato, come uno dei seguenti, per diagnosticare le pipeline con input:

• Perfetto per JAX
• Profiler TensorFlow per TensorFlow.

Sostanzialmente, le cause e gli interventi specifici dipendono fortemente dalle attività. Considerazioni ingegneristiche più ampie (ad esempio, la riduzione al minimo dell'impatto del disco) potrebbero compromettere le prestazioni della pipeline di input.

Di seguito sono riportate le cause comuni delle pipeline con input:

• I dati non vengono coordinati con il processo di addestramento, causando una latenza I/O. Ad esempio, la lettura dei dati di addestramento su una rete potrebbe causare la latenza I/O.
• Pre-elaborazione costosa dei dati online. Considera la pre-elaborazione una volta offline e salva i risultati.
• Barriere di 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.

Consigliamo i seguenti interventi per le pipeline con input:

• Pipeline di input degli strumenti per il precaricamento degli esempi (ad esempio tf.data.Dataset.prefetch).
• Rimuovi le funzionalità e i metadati inutilizzati 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 a gruppi di dimensioni maggiori rispetto all'addestramento. Esegui le valutazioni a intervalli regolari, non a intervalli di tempo regolari.

Impostazioni di valutazione

Per valutare le prestazioni dei tuoi modelli, puoi utilizzare le seguenti impostazioni:

• Valutazione online: raccogli metriche quando il modello gestisce le previsioni in un ambiente di produzione. In genere, la valutazione online fornisce la valutazione più realistica della qualità del modello perché corrisponde al modo in cui verrà utilizzato il modello.
• Valutazione offline: raccogli 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.
• Valutazioni periodiche: raccogli metriche durante l'addestramento del modello che potrebbero essere un proxy per la valutazione offline e/o un sottoinsieme dei dati utilizzati nella valutazione offline. Le valutazioni periodiche sono la scelta più pratica ed economica, ma potrebbero non rappresentare appieno l'ambiente di produzione. Mirare a utilizzare un proxy appropriato della valutazione offline, senza sacrificare l'affidabilità dell'indicatore ricevuto durante l'addestramento.

Configurare valutazioni periodiche

Consigliamo di eseguire valutazioni periodiche durante l'addestramento per i seguenti motivi:

• Monitorare l'avanzamento dell'addestramento in tempo reale.
• Per facilitare la selezione del checkpoint del modello retrospettivo.
• Per esaminare le curve di addestramento al termine dell'addestramento.

La configurazione più semplice è 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, le dimensioni del batch utilizzate per eseguire le valutazioni devono essere almeno uguali a quelle del batch utilizzato 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 dei passi, non a intervalli di tempo. La valutazione basata su intervalli di tempo può rendere più difficile interpretare le curve di addestramento, soprattutto quando l'addestramento potrebbe risentirne di prerilasci dei job di addestramento, problemi di latenza di rete e così via.

La regolarità nelle metriche di convalida e test (quando si utilizza un set di addestramento misto, un set di convalida, una suddivisione del set di test) possono indicare bug di implementazione come:

• Testare i dati che si sovrappongono a quelli dell'addestramento.
• I dati di addestramento non vengono riprodotti in ordine casuale.

La valutazione a intervalli regolari dei passaggi può semplificare l'individuazione di questi problemi.

I batch parziali possono verificarsi quando i set di valutazione non sono divisibili per le dimensioni del batch. Assicurati che gli esempi imbottiti siano ponderati correttamente (come nella media ponderata rispetto agli esempi che calcolano la perdita media sul batch) per evitare che la funzione di perdita venga dedotta da tali errori. Spesso, a questi esempi imbottiti puoi assegnare una ponderazione pari a zero.

Salva informazioni sufficienti per ogni valutazione per supportare l'analisi offline. Idealmente, dovresti salvare le previsioni su una selezione di singoli esempi, dato che possono essere preziosi per il debug. La generazione di artefatti come SavedModels semplifica l'ispezione dei modelli ad hoc 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 nell'intero set di valutazioni offline in un periodo di tempo ragionevole. Questo problema spesso richiede il campionamento dei dati per la valutazione periodica. Quando crei un set di dati campionato, tieni conto dei problemi relativi alle dimensioni del campione e ai problemi speciali nei set di dati non bilanciati.

Dimensioni del campione

Verifica che le prestazioni calcolate sul set di dati campionato utilizzato dal job periodico corrispondano alle prestazioni nell'intero set di valutazione offline; in altre parole, assicurati che non vi siano disallineamenti tra il set di dati campionato e il set di dati completo.

Il set di dati che utilizzi per la valutazione periodica deve essere entrambi:

• Abbastanza piccolo da poter generare facilmente previsioni di modelli nella loro interezza.
• Abbastanza grande per eseguire entrambe le seguenti operazioni:
  • Misura con precisione i miglioramenti del modello, ovvero le misurazioni non devono essere sovraccariche di rumori di etichette.
  • Accogliere più valutazioni di questo tipo in prove diverse in sequenza e produrre comunque stime accurate. ossia abbastanza grande da evitare di adattarsi nel tempo alla convalida impostata in un modo che non può essere generalizzato da un set di test. Tuttavia, questa considerazione è raramente una preoccupazione pratica.

Set di dati non bilanciati

Per i set di dati non bilanciati, le prestazioni nelle classi di minoranza rare sono spesso rumorose. Per i set di dati con un numero ridotto di esempi di minoranza, registra il numero di esempi previsti in modo corretto per ottenere maggiori informazioni sui miglioramenti dell'accuratezza. Ad esempio, il miglioramento della sensibilità di 0,05 è entusiasmante, ma è stato il miglioramento proprio a causa di un altro esempio corretto?

Salvataggio dei checkpoint e selezione retroattiva del posto di controllo migliore

Riepilogo: esegui l'addestramento per un numero fisso di passi e scegli retrospettivamente il checkpoint migliore dell'esecuzione.

La maggior parte dei framework di deep learning supporta il checkpoint dei modelli. In altre parole, lo stato attuale del modello viene salvato periodicamente su disco. Il checkpoint consente al job di addestramento di essere resiliente alle interruzioni delle istanze di calcolo. Il miglior checkpoint non è spesso l'ultimo checkpoint, in particolare quando il rendimento del set di convalida non continua ad aumentare nel tempo, ma piuttosto fluttua su un determinato valore.

Configurare la pipeline per tenere traccia dei N miglior checkpoint osservati finora durante l'addestramento. Alla fine dell'addestramento, la selezione del modello significa semplicemente scegliere il checkpoint migliore. Questo approccio è chiamato selezione ottimale retrospettiva. Supportare l'interruzione anticipata in genere non è necessaria, perché stai prespecificando un budget di prova e stai conservando i N miglior checkpoint osservati finora.

Impostazione del monitoraggio degli esperimenti

Riepilogo: quando monitori diversi esperimenti, monitora una serie di elementi essenziali, ad esempio 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 al punto in cui è archiviata la configurazione per lo studio.
• Note o una breve descrizione dello studio.
• Numero di prove eseguite
• Prestazioni nel set di convalida del checkpoint migliore dello studio.
• Note o comandi specifici di riproduzione per indicare le modifiche non richieste necessarie per avviare l'addestramento.

Trova un pratico sistema di monitoraggio che acquisisca almeno le informazioni elencate in precedenza. Potrebbero anche non esistere esperimenti non monitorati.

Dettagli sull'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 le dimensioni del batch o il numero di host.

La normalizzazione del batch normalizza le attivazioni utilizzando la media e la varianza rispetto al batch attuale. Tuttavia, nell'impostazione multi-dispositivo, queste statistiche variano in base al dispositivo, a meno che non vengano sincronizzate in modo esplicito. I 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 Addestra più a lungo, generalizza meglio: colma il divario di generalizzazione nell'addestramento in batch di grandi dimensioni delle reti neurali). Il disaccoppiamento delle dimensioni totali del batch e del numero di esempi utilizzati per calcolare le statistiche delle regole del batch è particolarmente utile per i confronti relativi alle dimensioni del batch.

Le implementazioni di normalizzazione batch fantasma non sempre gestiscono correttamente il caso in cui le dimensioni del batch per dispositivo sono superiori a quelle del batch virtuale. In questo caso, dovrai sottocampionare il batch su ogni dispositivo per ottenere il numero corretto di esempi statistici di base dei batch.

Le medie mobili esponenziali (EMA) utilizzate nella normalizzazione batch in modalità di test sono solo una combinazione lineare di statistiche di addestramento. Pertanto, devi sincronizzare questi EMA solo prima di salvarli nei checkpoint. Tuttavia, alcune implementazioni comuni della normalizzazione batch non sincronizzano queste EMA e salvano solo l'EMA dal primo dispositivo.

Considerazioni sulle pipeline multi-host

Riepilogo: per logging, eval, RNG, checkpoint e partizionamento dati, l'addestramento multi-host può semplificare l'introduzione dei bug.

Per le pipeline multi-host:

• Assicurarsi che la pipeline registri e controlli un solo host su un host.
• Sincronizza le statistiche di normalizzazione batch tra gli host prima di valutare o checkpoint.
• Esegui il sharding dei file di dati su più host poiché in genere migliora le prestazioni.

Critici:assicurati di avere semi di GNG uguali per gli host (per l'inizializzazione del modello) e semi diversi per gli host (per l'ordinamento/pre-elaborazione dei dati). Pertanto, assicurati di contrassegnarli in modo appropriato.