Zusätzliche Anleitungen für die Trainingspipeline

.

In diesem Abschnitt wird die Trainingspipeline detailliert beschrieben.

Eingabepipeline optimieren

Zusammenfassung: Die Ursachen und der Eingriff von eingabegebundenen Pipelines sind stark aufgabenabhängig. Verwenden Sie einen Profiler und halten Sie nach häufigen Problemen Ausschau.

Verwenden Sie einen angemessenen Profiler, wie im Folgenden beschrieben, um eine eingabegebundene Pipeline zu diagnostizieren:

• Perfetto für JAX
• TensorFlow Profiler für TensorFlow

Letztendlich sind die konkreten Ursachen und Eingriffe arbeitsintensiv. Breitere technische Überlegungen, z. B. zur Minimierung des Laufwerksbedarfs, können die Leistung der Eingabepipeline beeinträchtigen.

Häufige Ursachen für eingabegebundene Pipelines:

• Die Daten werden nicht zusammen mit dem Trainingsprozess gespeichert. Dies führt zu einer E/A-Latenz. Beispielsweise kann das Lesen von Trainingsdaten über ein Netzwerk zu einer E/A-Latenz führen.
• Teure Onlinedatenvorverarbeitung. Erwägen Sie die Vorverarbeitung einmal im Offlinemodus und speichern Sie die Ergebnisse.
• Unabsichtliche Synchronisierungsbarrieren, die den Vorabruf von Datenpipelines beeinträchtigen. Ein Beispiel dafür ist die Synchronisierung von Messwerten zwischen Gerät und Host in CommonLoopUtils.

Für eingabegebundene Pipelines empfehlen wir die folgenden Eingriffe:

• Eingabepipeline für das Instrument zum Vorabruf von Beispielen (z. B. tf.data.Dataset.prefetch).
• Entfernen Sie nicht verwendete Features und Metadaten so früh wie möglich in der Pipeline.
• Erhöhen Sie die Replikation der Anzahl der Jobs, die Beispiele für die Eingabepipeline generieren, z. B. mit dem tf.data-Dienst.

Modellleistung bewerten

Zusammenfassung: Bewertung für größere Batches als Training ausführen. Führen Sie Bewertungen in regelmäßigen Intervallen und nicht in regelmäßigen Intervallen aus.

Einstellungen für die Auswertung

Mithilfe der folgenden Einstellungen können Sie die Leistung Ihrer Modelle bewerten:

• Onlinebewertung: Erfassen Sie Messwerte, wenn das Modell Vorhersagen in einer Produktionsumgebung bereitstellt. Eine Onlinebewertung ermöglicht in der Regel die realistischste Bewertung der Modellqualität, da sie dem Einsatz des Modells entspricht.
• Offlinebewertung: Erfassen Sie Messwerte, wenn das Modell für Offlinetrainings, Validierungen oder Testsätze ausgeführt wird, die für die Produktionsumgebung repräsentativ sind. Je nach Problem kann die Offlinebewertung ziemlich involviert und rechenintensiv sein.
• Regelmäßige Bewertungen: Erfassen Sie Messwerte während des Modelltrainings, die ein Proxy für die Offlinebewertung sein können, und/oder eine Teilmenge der Daten, die für die Offlinebewertung verwendet werden. Regelmäßige Bewertungen sind die praktikabelste und wirtschaftlicheste Option, stellen jedoch unter Umständen nicht die Produktionsumgebung dar. Verwenden Sie einen nutzerfreundlichen Proxy der Offlinebewertung, ohne die Zuverlässigkeit des Signals zu beeinträchtigen, das während des Trainings empfangen wurde.

Regelmäßige Bewertungen einrichten

Wir empfehlen aus folgenden Gründen, während des Trainings regelmäßig Bewertungen durchzuführen:

• Trainingsfortschritt in Echtzeit beobachten.
• Um die Auswahl eines Prüfpunkts für die Retrospektive zu erleichtern.
• Um die Trainingskurven am Ende des Trainings zu untersuchen.

Die einfachste Konfiguration besteht darin, sowohl Trainings- als auch regelmäßige Bewertungen innerhalb derselben Compute-Instanz auszuführen, wobei regelmäßig zwischen Training und Bewertung abwechselnd ist. In diesem Fall sollte die für die Bewertung verwendete Batchgröße mindestens so groß sein wie die für das Training verwendete Batchgröße. Das liegt daran, dass Sie Modellaktivierungen während der Bewertung nicht beibehalten müssen, wodurch die Rechenanforderungen pro Beispiel niedriger sind.

Führen Sie regelmäßig Überprüfungen in regelmäßigen Abständen durch, keine Zeitintervalle. Eine Bewertung auf der Grundlage von Zeitintervallen kann die Interpretation der Trainingskurven erschweren, insbesondere wenn das Training durch vorzeitiges Beenden der Trainingsjobs, Probleme mit der Netzwerklatenz usw. beeinträchtigt werden kann.

Regelmäßigkeit in Validierungs- und Testmesswerten (bei Verwendung eines gemischten Trainings-Datasets, Validierungs-Datasets und Test-Set-Splits) kann auf Implementierungsfehler hinweisen, z. B.:

• Testdaten, die sich mit Trainingsdaten überschneiden.
• Trainingsdaten werden nicht richtig angeordnet.

Eine Bewertung in regelmäßigen Schrittintervallen kann das Erkennen dieser Probleme erleichtern.

Es kann zu partiellen Batches kommen, wenn die Bewertungssätze nicht durch die Batchgröße teilbar sind. Achten Sie darauf, dass die abgesetzten Beispiele korrekt gewichtet sind, wie z. B. bei dem gewichteten Durchschnitt aus Beispielen, die den durchschnittlichen Verlust im Batch berechnen. So verhindern Sie, dass die Verlustfunktion von ihnen beeinflusst wird. Diese gepolsterten Beispiele haben oft eine Gewichtung von null.

Speichern Sie genügend Informationen pro Bewertung, um Offlineanalysen zu unterstützen. Am besten speichern Sie Vorhersagen bei einer Auswahl einzelner Beispiele, da sie für die Fehlerbehebung von unschätzbarem Wert sind. Das Generieren von Artefakten wie Overlays vereinfacht die Prüfung des Ad-hoc-Modells nach Bewertungsjobs.

Auswahl einer Stichprobe für die regelmäßige Evaluierung

Der Job für die regelmäßige Bewertung wird möglicherweise nicht schnell genug ausgeführt, um Messwerte für einen vollständigen Zeitraum der Offlinebewertung in einem angemessenen Zeitraum zu berechnen. Für dieses Problem sind häufig Stichprobendaten für eine regelmäßige Evaluierung erforderlich. Berücksichtigen Sie beim Erstellen eines Datasets mit Stichproben ein Problem mit der Stichprobengröße und spezielle Bedenken in unausgeglichenen Datasets.

Stichprobengröße

Prüfen Sie, ob die Leistung, die für das Stichproben-Dataset, das vom regelmäßigen Job verwendet wird, berechnet wird, mit der Leistung des gesamten Offline-Bewertungssatzes übereinstimmt. Das heißt, es darf keine Verschiebung zwischen dem Stichproben-Dataset und dem vollständigen Dataset auftreten.

Das Dataset, das Sie für die regelmäßige Evaluierung verwenden, sollte Folgendes sein:

• Klein genug, um ganz einfach Modellvorhersagen in seiner Gesamtheit zu generieren.
• Diese sind ausreichend groß, um Folgendes zu erreichen:
  • Messen Sie Verbesserungen am Modell präzise, d. h., Messungen sollten nicht durch Label-Rauschen überfordert werden.
  • Sie können mehrere solcher Bewertungen in mehreren Testphasen hintereinander durchführen und dennoch genaue Schätzungen erstellen. Das heißt, es ist groß genug, um „angepasst“ zu werden und sich im Laufe der Zeit nicht an das Validierungs-Dataset anzupassen, das dann nicht auf einen solchen Test angewendet wird. Allerdings ist dies nur selten praktisch.

Unausgeglichene Datasets

Bei unausgeglichenen Datasets ist die Leistung für seltene Nebenklassen häufig laut. Bei Datasets mit wenigen Beispielen für Minderheiten müssen Sie die Anzahl der korrekt vorhergesagten Beispiele protokollieren, um mehr Informationen zu Genauigkeitsverbesserungen zu erhalten. Eine Verbesserung der Sensibilität von 0,05 klingt beispielsweise interessant, aber war die Verbesserung nur dadurch verursacht, dass ein weiteres Beispiel korrekt war?

Prüfpunkte speichern und rückblickend den besten Prüfpunkt auswählen

Zusammenfassung: Führen Sie das Training für eine feste Anzahl von Schritten aus und wählen Sie rückwirkend den besten Prüfpunkt für die Ausführung aus.

Die meisten Deep-Learning-Frameworks unterstützen die Modellprüfung. Das heißt, der aktuelle Status des Modells wird regelmäßig auf dem Laufwerk gespeichert. Prüfpunkte ermöglichen es dem Trainingsjob, Instanzunterbrechungen zu berechnen. Der beste Prüfpunkt ist oft nicht der letzte Prüfpunkt, insbesondere wenn sich die Leistung des Validierungssatzes im Laufe der Zeit nicht erhöht, sondern bei einem bestimmten Wert schwankt.

Richten Sie die Pipeline so ein, dass Sie die bisher bis zu N während des Trainings bekannten n Prüfpunkte im Blick behalten. Am Ende des Trainings bedeutet die Modellauswahl einfach, den besten Prüfpunkt auszuwählen. Wir nennen diesen Ansatz retrospektive optimale Prüfpunktauswahl. In der Regel ist es nicht erforderlich, das potenzielle vorzeitige Beenden zu unterstützen, da Sie ein Testbudget vorab angeben und die N bisher besten Prüfpunkte beibehalten werden.

Test-Tracking einrichten

Zusammenfassung: Wenn Sie verschiedene Tests erfassen, verfolgen Sie eine Reihe von Grundlagen, z. B. die beste Leistung eines Prüfpunkts in der Studie und eine kurze Beschreibung der Studie.

Wir empfehlen, die Testergebnisse in einer Tabelle zu erfassen. Unsere Tabellen enthalten häufig die folgenden Spalten:

• Name der Studie
• Ein Link zum Speicherort der Konfiguration für die Studie.
• Hinweise oder eine kurze Beschreibung der Studie
• Anzahl der ausgeführten Tests
• Leistung am Überprüfungs-Dataset des besten Prüfpunkts in der Studie
• Spezifische Reproduktionsbefehle oder Hinweise zu den nicht eingereichten Änderungen, die zum Starten des Trainings erforderlich waren.

Suchen Sie nach einem praktischen Tracking-System, mit dem mindestens die oben aufgeführten Informationen erfasst werden. Nicht erfasste Tests sind unter Umständen nicht vorhanden.

Details zur Implementierung der Batch-Normalisierung

Zusammenfassung: Heutzutage können Sie häufig die Batchnormalisierung durch LayerNorm ersetzen. Wenn Sie dies jedoch nicht tun können, sind beim Ändern der Batchgröße oder Anzahl der Hosts komplizierte Details erforderlich.

Die Batch-Normalisierung normalisiert Aktivierungen anhand ihres Durchschnitts und der Varianz über den aktuellen Batch. In der geräteübergreifenden Einstellung unterscheiden sich diese Statistiken jedoch auf jedem Gerät, sofern sie nicht ausdrücklich synchronisiert werden. Anekdotenberichte (meist auf ImageNet) deuten darauf hin, dass die Berechnung dieser Normalisierungen nur anhand von etwa 64 Beispielen in der Praxis besser funktioniert. Weitere Informationen finden Sie in der Beschreibung der Ghost-Batch-Normalisierung unter länger trainieren, besser generalisieren: Die Generalisierungslücke beim großen Batch-Training von neuronalen Netzwerken schließen. Das Entkoppeln der Batchgröße und der Anzahl von Beispielen, die zur Berechnung von Batchnormen verwendet werden, ist besonders hilfreich für Vergleiche von Batchgrößen.

Implementierungen von Ghost-Batchnormalisierungen funktionieren nicht immer richtig, wenn die Batchgröße pro Gerät größer ist als die virtuelle Batchgröße. In diesem Fall müssten Sie den Batch auf jedem Gerät subtrahieren, um die richtige Anzahl von Statistikbeispielen für die Batchnorm zu erhalten.

Die für die Batchnormalisierung im Testmodus verwendeten exponentiellen gleitenden Durchschnitte sind nur eine lineare Kombination aus Trainingsstatistiken. Daher müssen Sie diese EMAs nur synchronisieren, bevor Sie sie an Prüfpunkten speichern. Einige gängige Implementierungen der Batchnormalisierung synchronisieren diese jedoch nicht und speichern das EMA nur vom ersten Gerät.

Überlegungen zu Pipelines mit mehreren Hosts

Zusammenfassung: Bei Logging, Auswertungen, RNGs, Prüfpunkten und Datenfragmentierung kann Multi-Host-Training sehr einfach sein, um Fehler einzuführen.

Führen Sie für Pipelines mit mehreren Hosts die folgenden Schritte aus:

• Achten Sie darauf, dass die Pipeline nur auf einem Host Logging und Prüfpunkte enthält.
• Synchronisieren Sie Batch-Normalisierungsstatistiken für alle Hosts vor der Bewertung oder Prüfpunktprüfung.
• Shard-Datendateien auf allen Hosts, da dies normalerweise die Leistung verbessert.

Kritisch: Achten Sie darauf, dass Sie RNG-Seeds (für die Modellinitialisierung) und für die verschiedenen Hosts (für die Daten-Shuffles/Vorverarbeitung) identisch sind. Achten Sie daher darauf, sie entsprechend zu markieren.