TensorFlow 2 est fondamentalement différent de TF1.x à plusieurs égards. Vous pouvez toujours exécuter du code TF1.x non modifié ( sauf contrib ) sur les installations binaires TF2 comme ceci :
import tensorflow.compat.v1 as tf
tf.disable_v2_behavior()
Cependant, cela n’exécute pas les comportements et les API TF2, et peut ne pas fonctionner comme prévu avec le code écrit pour TF2. Si vous n’exécutez pas les comportements TF2 actifs, vous exécutez effectivement TF1.x au-dessus d’une installation TF2. Lisez le guide des comportements TF1 vs TF2 pour plus de détails sur la différence entre TF2 et TF1.x.
Ce guide donne un aperçu du processus de migration de votre code TF1.x vers TF2. Cela vous permet de profiter des améliorations de fonctionnalités nouvelles et futures et également de rendre votre code plus simple, plus performant et plus facile à maintenir.
Si vous utilisez les API de haut niveau de tf.keras et que vous vous entraînez exclusivement avec model.fit , votre code devrait plus ou moins être entièrement compatible avec TF2, à l'exception des mises en garde suivantes :
- TF2 propose de nouveaux taux d'apprentissage par défaut pour les optimiseurs Keras.
- TF2 a peut-être modifié le « nom » sous lequel les métriques sont enregistrées.
Processus de migration TF2
Avant de migrer, découvrez le comportement et les différences d'API entre TF1.x et TF2 en lisant le guide .
- Exécutez le script automatisé pour convertir une partie de votre utilisation de l'API TF1.x en
tf.compat.v1. - Supprimez les anciens symboles
tf.contrib(vérifiez TF Addons et TF-Slim ). - Faites en sorte que les passes avant de votre modèle TF1.x s'exécutent dans TF2 avec l'exécution rapide activée.
- Mettez à niveau votre code TF1.x pour les boucles de formation et la sauvegarde/chargement des modèles vers des équivalents TF2.
- (Facultatif) Migrez vos API
tf.compat.v1compatibles TF2 vers des API TF2 idiomatiques.
Les sections suivantes développent les étapes décrites ci-dessus.
Exécutez le script de conversion de symboles
Cela exécute une première passe de réécriture de vos symboles de code pour qu'ils s'exécutent sur les binaires TF 2.x, mais ne rendra pas votre code idiomatique pour TF 2.x et ne rendra pas automatiquement votre code compatible avec les comportements TF2.
Votre code utilisera très probablement toujours les points de terminaison tf.compat.v1 pour accéder aux espaces réservés, aux sessions, aux collections et à d'autres fonctionnalités de style TF1.x.
Lisez le guide pour en savoir plus sur les meilleures pratiques d'utilisation du script de conversion de symboles.
Supprimer l'utilisation de tf.contrib
Le module tf.contrib a été supprimé et plusieurs de ses sous-modules ont été intégrés dans l'API principale de TF2. Les autres sous-modules sont désormais répartis dans d'autres projets comme TF IO et TF Addons .
Une grande quantité d'anciens codes TF1.x utilisent la bibliothèque Slim , qui a été packagée avec TF1.x sous le nom tf.contrib.layers . Lors de la migration de votre code Slim vers TF2, modifiez vos utilisations de l'API Slim pour pointer vers le package pip tf-slim . Ensuite, lisez le guide de mappage de modèles pour savoir comment convertir le code Slim.
Alternativement, si vous utilisez des modèles Slim pré-entraînés, vous pouvez envisager d'essayer les modèles pré-entraînés de Keras à partir de tf.keras.applications ou les TF2 SavedModel de TF Hub exportés à partir du code Slim d'origine.
Exécuter les passes avant du modèle TF1.x avec les comportements TF2 activés
Suivez les variables et les pertes
TF2 ne prend pas en charge les collections globales.
L’exécution hâtive dans TF2 ne prend pas en charge les API basées sur la collection tf.Graph . Cela affecte la façon dont vous construisez et suivez les variables.
Pour le nouveau code TF2, vous utiliseriez tf.Variable au lieu de v1.get_variable et utiliseriez des objets Python pour collecter et suivre les variables au lieu de tf.compat.v1.variable_scope . Il s'agit généralement de l'un des éléments suivants :
Agrégez des listes de variables (comme tf.Graph.get_collection(tf.GraphKeys.VARIABLES) ) avec les attributs .variables et .trainable_variables des objets Layer , Module ou Model .
Les classes Layer et Model implémentent plusieurs autres propriétés qui suppriment le besoin de collections globales. Leur propriété .losses peut remplacer l’utilisation de la collection tf.GraphKeys.LOSSES .
Lisez le guide de mappage de modèle pour en savoir plus sur l'utilisation des cales de modélisation de code TF2 pour intégrer votre code existant basé sur get_variable et variable_scope dans Layers , Models et Modules . Cela vous permettra d'exécuter des passes avant avec une exécution rapide activée sans réécritures majeures.
S'adapter à d'autres changements de comportement
Si le guide de mappage de modèle à lui seul est insuffisant pour faire avancer votre modèle en exécutant d'autres changements de comportement qui peuvent être plus détaillés, consultez le guide sur les comportements TF1.x vs TF2 pour en savoir plus sur les autres changements de comportement et comment vous pouvez vous y adapter. . Consultez également le guide de création de nouveaux calques et modèles via les sous-classes pour plus de détails.
Valider vos résultats
Consultez le guide de validation du modèle pour obtenir des outils et des conseils simples sur la façon dont vous pouvez valider (numériquement) que votre modèle se comporte correctement lorsque l'exécution rapide est activée. Cela peut s'avérer particulièrement utile lorsqu'il est associé au guide de cartographie des modèles .
Mise à niveau de la formation, de l'évaluation et du code d'import/export
Les boucles d'entraînement TF1.x construites avec le style v1.Session tf.estimator.Estimator et d'autres approches basées sur des collections ne sont pas compatibles avec les nouveaux comportements de TF2. Il est important de migrer tout votre code de formation TF1.x, car sa combinaison avec le code TF2 peut entraîner des comportements inattendus.
Pour ce faire, vous pouvez choisir parmi plusieurs stratégies.
L'approche de plus haut niveau consiste à utiliser tf.keras . Les fonctions de haut niveau de Keras gèrent de nombreux détails de bas niveau qui pourraient être faciles à manquer si vous écrivez votre propre boucle de formation. Par exemple, ils collectent automatiquement les pertes de régularisation et définissent l'argument training=True lors de l'appel du modèle.
Reportez-vous au guide de migration d'Estimator pour savoir comment migrer le code de tf.estimator.Estimator pour utiliser les boucles de formation Vanilla et tf.keras personnalisées .
Les boucles d'entraînement personnalisées vous donnent un contrôle plus précis sur votre modèle, comme le suivi du poids des couches individuelles. Lisez le guide sur la création de boucles d'entraînement à partir de zéro pour savoir comment utiliser tf.GradientTape pour récupérer les poids du modèle et les utiliser pour mettre à jour le modèle.
Convertir les optimiseurs TF1.x en optimiseurs Keras
Les optimiseurs de tf.compat.v1.train , tels que l' optimiseur Adam et l' optimiseur de descente de gradient , ont des équivalents dans tf.keras.optimizers .
Le tableau ci-dessous résume la façon dont vous pouvez convertir ces optimiseurs existants en leurs équivalents Keras. Vous pouvez directement remplacer la version TF1.x par la version TF2 sauf si des étapes supplémentaires (telles que la mise à jour du taux d'apprentissage par défaut ) sont requises.
Notez que la conversion de vos optimiseurs peut rendre les anciens points de contrôle incompatibles .
| TF1.x | TF2 | Étapes supplémentaires |
|---|---|---|
| `tf.v1.train.GradientDescentOptimizer` | tf.keras.optimizers.SGD | Aucun |
| `tf.v1.train.MomentumOptimizer` | tf.keras.optimizers.SGD | Inclure l'argument « élan » |
| `tf.v1.train.AdamOptimizer` | tf.keras.optimizers.Adam | Renommez les arguments `beta1` et `beta2` en `beta_1` et `beta_2` |
| `tf.v1.train.RMSPropOptimizer` | tf.keras.optimizers.RMSprop | Renommez l'argument `decay` en `rho` |
| `tf.v1.train.AdadeltaOptimizer` | tf.keras.optimizers.Adadelta | Aucun |
| `tf.v1.train.AdagradOptimizer` | tf.keras.optimizers.Adagrad | Aucun |
| `tf.v1.train.FtrlOptimizer` | tf.keras.optimizers.Ftrl | Supprimez les arguments `accum_name` et `linear_name` |
| `tf.contrib.AdamaxOptimizer` | tf.keras.optimizers.Adamax | Renommez les arguments `beta1` et `beta2` en `beta_1` et `beta_2` |
| `tf.contrib.Nadam` | tf.keras.optimizers.Nadam | Renommez les arguments `beta1` et `beta2` en `beta_1` et `beta_2` |
Mettre à niveau les pipelines d'entrée de données
Il existe de nombreuses façons de transmettre des données à un modèle tf.keras . Ils accepteront les générateurs Python et les tableaux Numpy en entrée.
La méthode recommandée pour transmettre des données à un modèle consiste à utiliser le package tf.data , qui contient un ensemble de classes hautes performances pour manipuler les données. Les dataset appartenant à tf.data sont efficaces, expressifs et s'intègrent bien à TF2.
Ils peuvent être transmis directement à la méthode tf.keras.Model.fit .
model.fit(dataset, epochs=5)
Ils peuvent être itérés directement sur Python standard :
for example_batch, label_batch in dataset:
break
Si vous utilisez toujours tf.queue , celles-ci ne sont désormais prises en charge qu'en tant que structures de données, et non en tant que pipelines d'entrée.
Vous devez également migrer tout le code de prétraitement des fonctionnalités qui utilise tf.feature_columns . Lisez le guide de migration pour plus de détails.
Sauvegarde et chargement de modèles
TF2 utilise des points de contrôle basés sur les objets. Lisez le guide de migration des points de contrôle pour en savoir plus sur la migration des points de contrôle TF1.x basés sur le nom. Lisez également le guide des points de contrôle dans la documentation principale de TensorFlow.
Il n’y a aucun problème de compatibilité significatif pour les modèles enregistrés. Lisez le guide SavedModel pour plus d’informations sur la migration des SavedModel de TF1.x vers TF2. En général,
- Les modèles sauvegardés TF1.x fonctionnent dans TF2.
- Les modèles sauvegardés TF2 fonctionnent dans TF1.x si toutes les opérations sont prises en charge.
Reportez-vous également à la section GraphDef du guide de migration SavedModel pour plus d'informations sur l'utilisation des objets Graph.pb et Graph.pbtxt .
(Facultatif) Migrer les symboles tf.compat.v1
Le module tf.compat.v1 contient l'API TF1.x complète, avec sa sémantique d'origine.
Même après avoir suivi les étapes ci-dessus et obtenu un code entièrement compatible avec tous les comportements de TF2, il est probable qu'il y ait de nombreuses mentions d'API compat.v1 qui se révèlent compatibles avec TF2. Vous devez éviter d'utiliser ces anciennes API compat.v1 pour tout nouveau code que vous écrivez, même si elles continueront à fonctionner pour votre code déjà écrit.
Cependant, vous pouvez choisir de migrer les utilisations existantes vers des API TF2 non héritées. Les docstrings des symboles compat.v1 individuels expliquent souvent comment les migrer vers des API TF2 non héritées. De plus, la section du guide de mappage de modèles sur la migration incrémentielle vers les API TF2 idiomatiques peut également être utile.
Ressources et lectures complémentaires
Comme mentionné précédemment, c'est une bonne pratique de migrer tout votre code TF1.x vers TF2. Lisez les guides de la section Migrer vers TF2 du guide TensorFlow pour en savoir plus.