Conseils supplémentaires pour le pipeline d'entraînement

Cette section décrit en détail le pipeline d'entraînement.

Optimiser le pipeline d'entrée

Résumé : Les causes et les interventions des pipelines liés aux entrées dépendent fortement de la tâche. Utilisez un profileur et recherchez les problèmes courants.

Utilisez un profileur approprié, tel que l'un des suivants, pour diagnostiquer les pipelines liés aux entrées :

• Perfetto pour JAX
• TensorFlow Profiler pour TensorFlow.

En fin de compte, les causes et les interventions spécifiques dépendent fortement de la tâche. Des considérations d'ingénierie plus générales (par exemple, la réduction de l'empreinte disque) peuvent nuire aux performances du pipeline d'entrée.

Voici les causes courantes des pipelines liés aux entrées :

• Les données ne sont pas colocalisées avec le processus d'entraînement, ce qui entraîne une latence d'E/S. Par exemple, la lecture des données d'entraînement sur un réseau peut entraîner une latence d'E/S.
• Prétraitement coûteux des données en ligne. Envisagez de prétraiter les données hors connexion une seule fois et d'enregistrer les résultats.
• Barrières de synchronisation involontaires qui interfèrent avec la prélecture du pipeline de données. Par exemple, lors de la synchronisation des métriques entre l'appareil et l'hôte dans CommonLoopUtils.

Nous vous suggérons les interventions suivantes pour les pipelines liés aux entrées :

• Instrumentez le pipeline d'entrée pour précharger les exemples (par exemple, tf.data.Dataset.prefetch).
• Supprimez les fonctionnalités et les métadonnées inutilisées de chacun le plus tôt possible dans le pipeline.
• Augmentez la réplication du nombre de jobs générant des exemples pour le pipeline d'entrée, par exemple en utilisant le service tf.data.

Évaluer les performances du modèle

Résumé : Exécutez l'évaluation avec des tailles de lot plus importantes que celles de l'entraînement. Exécutez les évaluations à intervalles réguliers (en nombre d'étapes), et non à intervalles réguliers (en temps).

Paramètres d'évaluation

Vous pouvez utiliser les paramètres suivants pour évaluer les performances de vos modèles :

• Évaluation en ligne : collecte de métriques lorsque le modèle fournit des prédictions dans un environnement de production. L'évaluation en ligne fournit généralement l'évaluation la plus réaliste de la qualité du modèle, car elle correspond à la façon dont le modèle sera utilisé.
• Évaluation hors connexion : collectez des métriques lorsque le modèle est exécuté sur des ensembles d'entraînement, de validation ou de test hors connexion représentatifs de l'environnement de production. Selon le problème, l'évaluation hors connexion peut être assez complexe et coûteuse en termes de calcul.
• Évaluations périodiques : collectez des métriques pendant l'entraînement du modèle qui peuvent servir de proxy pour l'évaluation hors connexion et/ou sur un sous-ensemble des données utilisées dans l'évaluation hors connexion. Les évaluations périodiques sont le choix le plus pratique et le plus économique, mais elles ne représentent pas forcément l'environnement de production dans son intégralité. Essayez d'utiliser un proxy approprié pour l'évaluation hors connexion, sans sacrifier la fiabilité du signal reçu pendant l'entraînement.

Configurer des évaluations périodiques

Nous vous recommandons d'effectuer des évaluations périodiques pendant l'entraînement pour les raisons suivantes :

• Pour surveiller la progression de l'entraînement en temps réel.
• Pour faciliter la sélection rétrospective des points de contrôle du modèle.
• Examinez les courbes d'entraînement à la fin de l'entraînement.

La configuration la plus simple consiste à effectuer l'entraînement et les évaluations périodiques dans la même instance de calcul, en alternant périodiquement entre l'entraînement et l'évaluation. Dans ce cas, la taille de lot utilisée pour effectuer les évaluations doit être au moins aussi importante que celle utilisée pour l'entraînement. En effet, vous n'avez pas besoin de maintenir les activations de modèle pendant l'évaluation, ce qui réduit les exigences de calcul par exemple.

Effectuez des évaluations périodiques à intervalles réguliers, et non à intervalles de temps. L'évaluation basée sur des intervalles de temps peut rendre l'interprétation des courbes d'entraînement plus difficile, en particulier lorsque l'entraînement peut souffrir de préemptions des jobs d'entraînement, de problèmes de latence réseau, etc.

La périodicité des métriques de validation et de test (lorsque vous utilisez une répartition aléatoire des ensembles d'entraînement, de validation et de test) peut indiquer des bugs d'implémentation, par exemple :

• Données de test qui se chevauchent avec les données d'entraînement.
• Les données d'entraînement ne sont pas correctement mélangées.

L'évaluation à intervalles réguliers peut faciliter l'identification de ces problèmes.

Des lots partiels peuvent se produire lorsque les ensembles d'évaluation ne sont pas divisibles par la taille du lot. Assurez-vous que les exemples complétés sont correctement pondérés (comme dans la moyenne pondérée sur les exemples qui calcule la perte moyenne sur le lot) pour éviter que la fonction de perte ne soit biaisée par eux. Vous pouvez souvent attribuer un poids nul à ces exemples complétés.

Enregistrez suffisamment d'informations par évaluation pour permettre une analyse hors connexion. Dans l'idéal, enregistrez les prédictions sur une sélection d'exemples individuels, car elles peuvent être très utiles pour le débogage. La génération d'artefacts tels que SavedModels simplifie l'inspection ad hoc des modèles une fois les jobs d'évaluation terminés.

Choisir un échantillon pour l'évaluation périodique

Il est possible que le job d'évaluation périodique ne s'exécute pas assez rapidement pour calculer les métriques sur l'ensemble complet des données d'évaluation hors connexion dans un délai raisonnable. Ce problème nécessite souvent d'échantillonner les données pour une évaluation périodique. Lorsque vous créez un ensemble de données échantillonné, tenez compte des problèmes liés à la taille de l'échantillon et des préoccupations spécifiques aux ensembles de données déséquilibrés.

Taille de l'échantillon

Vérifiez que les performances calculées sur l'ensemble de données échantillonné utilisé par le job périodique correspondent à celles de l'ensemble de données d'évaluation hors connexion complet. En d'autres termes, assurez-vous qu'il n'y a pas de biais entre l'ensemble de données échantillonné et l'ensemble de données complet.

L'ensemble de données que vous utilisez pour l'évaluation périodique doit répondre aux deux critères suivants :

• Il doit être suffisamment petit pour générer facilement des prédictions de modèle sur l'ensemble des données.
• être suffisamment grand pour effectuer les deux opérations suivantes :
  • Mesurez précisément les améliorations apportées au modèle. En d'autres termes, les mesures ne doivent pas être masquées par le bruit des libellés.
  • Prendre en compte plusieurs évaluations de ce type dans des essais consécutifs, tout en produisant des estimations précises. C'est-à-dire suffisamment grand pour éviter un "ajustement" adaptatif à l'ensemble de validation au fil du temps, d'une manière qui ne se généralise pas à un ensemble de test retenu. Toutefois, cette considération est rarement un problème pratique.

Ensembles de données déséquilibrés

Pour les ensembles de données déséquilibrés, les performances des classes minoritaires rares sont souvent bruyantes. Pour les ensembles de données ne comportant qu'un petit nombre d'exemples minoritaires, enregistrez le nombre d'exemples correctement prédits pour mieux comprendre les améliorations de la précision. Par exemple, une amélioration de la sensibilité de 0,05 semble intéressante, mais est-elle simplement due à un exemple supplémentaire correct ?

Enregistrer des points de contrôle et sélectionner rétrospectivement le meilleur point de contrôle

Résumé : Exécutez l'entraînement pour un nombre fixe d'étapes et choisissez rétrospectivement le meilleur point de contrôle de l'exécution.

La plupart des frameworks de deep learning sont compatibles avec le checkpointing des modèles. Autrement dit, l'état actuel du modèle est régulièrement enregistré sur le disque. La création de points de contrôle permet à la tâche d'entraînement de résister aux interruptions des instances de calcul. Le meilleur point de contrôle n'est souvent pas le dernier, en particulier lorsque les performances de l'ensemble de validation ne continuent pas d'augmenter au fil du temps, mais fluctuent plutôt autour d'une valeur particulière.

Configurez le pipeline pour suivre les N meilleurs points de contrôle observés jusqu'à présent pendant l'entraînement. À la fin de l'entraînement, la sélection du modèle consiste simplement à choisir le meilleur point de contrôle. Nous appelons cette approche la sélection rétrospective du point de contrôle optimal. Il n'est généralement pas nécessaire de prendre en charge l'arrêt anticipé prospectif, car vous prédéfinissez un budget d'essai et conservez les N meilleurs points de contrôle observés jusqu'à présent.

Configurer le suivi des tests

Résumé : lorsque vous suivez différentes expériences, suivez un certain nombre d'éléments essentiels, comme les meilleures performances d'un point de contrôle dans l'étude et une brève description de l'étude.

Nous vous recommandons de suivre les résultats des tests dans une feuille de calcul. Nos feuilles de calcul contiennent souvent les colonnes suivantes :

• Nom de l'étude
• Lien vers l'emplacement de stockage de la configuration de l'étude.
• Notes ou brève description de l'étude.
• Nombre d'essais exécutés
• Performances sur l'ensemble de validation du meilleur point de contrôle de l'étude.
• Commandes de reproduction spécifiques ou notes sur les modifications non envoyées nécessaires pour lancer l'entraînement.

Trouvez un système de suivi pratique qui enregistre au moins les informations listées ci-dessus. Les tests non suivis sont inutiles.

Détails de l'implémentation de la normalisation par lots

Résumé : De nos jours, vous pouvez souvent remplacer la normalisation par lot par LayerNorm, mais dans les cas où vous ne pouvez pas effectuer ce remplacement, il existe des détails délicats lorsque vous modifiez la taille du lot ou le nombre d'hôtes.

La normalisation par lots normalise les activations en utilisant leur moyenne et leur variance sur le lot actuel. Toutefois, dans le paramètre multi-appareils, ces statistiques diffèrent sur chaque appareil, sauf si elles sont explicitement synchronisées. Des rapports anecdotiques (principalement sur ImageNet) indiquent que le calcul de ces statistiques de normalisation à l'aide d'environ 64 exemples fonctionne mieux en pratique. (Consultez la description de la normalisation par lots fantômes dans Train longer, generalize better: closing the generalization gap in large batch training of neural networks.) Le découplage de la taille de lot totale et du nombre d'exemples utilisés pour calculer les statistiques de normalisation par lot est particulièrement utile pour les comparaisons de taille de lot.

Les implémentations de la normalisation par lots fantômes ne gèrent pas toujours correctement le cas où la taille de lot par appareil est supérieure à la taille de lot virtuelle. Dans ce cas, vous devez sous-échantillonner le lot sur chaque appareil pour obtenir le nombre approprié d'exemples de statistiques de normalisation par lot.

Les moyennes mobiles exponentielles (EMA) utilisées dans la normalisation par lots en mode test ne sont qu'une combinaison linéaire des statistiques d'entraînement. Par conséquent, vous n'avez besoin de synchroniser ces EMA qu'avant de les enregistrer dans des points de contrôle. Toutefois, certaines implémentations courantes de la normalisation par lots ne synchronisent pas ces EMA et n'enregistrent que l'EMA du premier appareil.

Points à prendre en compte pour les pipelines multihôtes

Résumé : pour la journalisation, les évaluations, les RNG, la création de points de contrôle et le partitionnement des données, l'entraînement multihôte peut très facilement introduire des bugs.

Pour les pipelines multi-hôtes, procédez comme suit :

• Assurez-vous que le pipeline ne consigne et ne crée des points de contrôle que sur un seul hôte.
• Synchronisez les statistiques de normalisation par lot entre les hôtes avant l'évaluation ou la création de points de contrôle.
• Segmentez les fichiers de données sur plusieurs hôtes, car cela améliore généralement les performances.

Important : Assurez-vous d'avoir des graines RNG identiques sur tous les hôtes (pour l'initialisation du modèle) et des graines différentes sur tous les hôtes (pour le brassage/le prétraitement des données). Veillez donc à les marquer correctement.