La journée communautaire ML est le 9 novembre ! Rejoignez - nous pour les mises à jour de tensorflow, JAX et plus En savoir plus

Format Hub TF1

Lors de son lancement en 2018, TensorFlow Hub proposait un seul type d'actif : le format TF1 Hub pour l'import dans les programmes TensorFlow 1.

Cette page explique comment utiliser le format TF1 Hub de TF1 (ou le mode de compatibilité de TF1 TF2) avec la hub.Module classe et les API associées. (L'utilisation typique est de construire un tf.Graph , peut - être dans un TF1 Estimator , en combinant un ou plusieurs modèles au format TF1 Hub avec tf.compat.layers ou tf.layers ).

Les utilisateurs de tensorflow 2 ( en dehors du mode de compatibilité TF1) doivent utiliser la nouvelle API avec hub.load() ou hub.KerasLayer . Les nouvelles charges API nouveau TF2 SavedModel type d'actif, mais a également limité le soutien pour le format de chargement TF1 Hub dans TF2 .

Utilisation d'un modèle au format Hub TF1

Instanciation d'un modèle au format Hub TF1

Un modèle au format TF1 Hub est importé dans un programme de tensorflow en créant un hub.Module objet à partir d' une chaîne avec son URL ou le chemin système de fichiers, tels que:

m = hub.Module("path/to/a/module_dir")

Cela ajoute les variables du module au graphique TensorFlow actuel. L'exécution de leurs initialiseurs lira leurs valeurs pré-entraînées à partir du disque. De même, les tableaux et autres états sont ajoutés au graphique.

Modules de mise en cache

Lors de la création d'un module à partir d'une URL, le contenu du module est téléchargé et mis en cache dans le répertoire temporaire du système local. L'emplacement où les modules sont mises en cache peut être surchargée à l' aide TFHUB_CACHE_DIR variable d'environnement. Pour plus de détails, voir Mise en cache .

Application d'un module

Une fois instancié, un module m peut être appelé zéro ou plusieurs fois comme une fonction Python de tenseurs entrées vers les sorties tenseurs:

y = m(x)

Chacun de ces appels ajoute des opérations au graphique en cours de tensorflow pour calculer y de x . S'il s'agit de variables avec des poids entraînés, ceux-ci sont partagés entre toutes les applications.

Les modules peuvent définir plusieurs signatures nommées afin de permettre d' être appliquées dans plus d'une façon (similaire à la façon dont les objets Python ont des méthodes). La documentation d'un module doit décrire les signatures disponibles. L'appel applique au- dessus de la signature du nom "default" par "default" . Toute signature peut être sélectionnée en passant son nom à option signature= argument.

Si une signature a plusieurs entrées, elles doivent être transmises sous forme de dict, avec les clés définies par la signature. De même, si une signature a plusieurs sorties, celles - ci peuvent être récupérés comme dict en passant as_dict=True , sous les touches définies par la signature (la clé "default" par as_dict=False "default" est la seule sortie de retour si as_dict=False ). Ainsi, la forme la plus générale d'application d'un module ressemble à :

outputs = m(dict(apples=x1, oranges=x2), signature="fruit_to_pet", as_dict=True)
y1 = outputs["cats"]
y2 = outputs["dogs"]

Un appelant doit fournir toutes les entrées définies par une signature, mais il n'est pas obligatoire d'utiliser toutes les sorties d'un module. Tensorflow ne tourne que les parties du module qui finissent comme dépendances d'une cible dans tf.Session.run() . En effet, les éditeurs de modules peuvent choisir de fournir différentes sorties pour des usages avancés (comme des activations de couches intermédiaires) en plus des sorties principales. Les consommateurs de module doivent gérer les sorties supplémentaires avec élégance.

Essayer des modules alternatifs

Chaque fois qu'il existe plusieurs modules pour la même tâche, TensorFlow Hub encourage à les équiper de signatures (interfaces) compatibles, de sorte qu'en essayer différentes est aussi simple que de faire varier le descripteur de module en tant qu'hyperparamètre à valeur de chaîne.

À cette fin, nous maintenons une collection de recommandations Signatures communes pour les tâches populaires.

Création d'un nouveau module

Note de compatibilité

Le format Hub TF1 est orienté vers tensorflow 1. Il est seulement partiellement pris en charge par TF Hub tensorflow 2. S'il vous plaît n'envisage de publier dans le nouveau TF2 SavedModel le format à la place.

Le format TF1 Hub est similaire au format SavedModel de TensorFlow 1 au niveau syntaxique (mêmes noms de fichiers et messages de protocole) mais sémantiquement différent pour permettre la réutilisation, la composition et le recyclage des modules (par exemple, stockage différent des initialiseurs de ressources, étiquetage différent conventions pour les métagraphes). La est la présence ou l' absence de la meilleure façon de les différencier sur le disque tfhub_module.pb fichier.

Approche générale

Pour définir un nouveau module, un éditeur appelle hub.create_module_spec() avec une fonction module_fn . Cette fonction construit un graphe représentant la structure interne, à l' aide du module tf.placeholder() pour les entrées devant être fournies par l'appelant. Il définit ensuite les signatures en appelant hub.add_signature(name, inputs, outputs) une ou plusieurs fois.

Par exemple:

def module_fn():
  inputs = tf.placeholder(dtype=tf.float32, shape=[None, 50])
  layer1 = tf.layers.dense(inputs, 200)
  layer2 = tf.layers.dense(layer1, 100)
  outputs = dict(default=layer2, hidden_activations=layer1)
  # Add default signature.
  hub.add_signature(inputs=inputs, outputs=outputs)

...
spec = hub.create_module_spec(module_fn)

Le résultat de hub.create_module_spec() peut être utilisé, au lieu d'un chemin d' accès, pour instancier un objet de module à l' intérieur d' un diagramme de tensorflow particulier. Dans ce cas, il n'y a pas de point de contrôle et l'instance de module utilisera les initialiseurs de variables à la place.

Toute instance de module peut être sérialisé sur le disque via son export(path, session) méthode. Exportation d' un module sérialise son ensemble de définition avec l'état actuel de ses variables en session dans le chemin passé. Cela peut être utilisé lors de l'exportation d'un module pour la première fois, ainsi que lors de l'exportation d'un module affiné.

Pour la compatibilité avec tensorflow Estimateurs, hub.LatestModuleExporter exportations modules du dernier point de contrôle, tout comme tf.estimator.LatestExporter exporte le modèle entier du dernier point de contrôle.

Les éditeurs module devraient mettre en œuvre une signature commune lorsque cela est possible, afin que les consommateurs peuvent facilement échanger des modules et trouver le meilleur pour leur problème.

Exemple réel

Jetez un oeil à notre texte intégrant exportateur le module pour un exemple concret de la façon de créer un module d'un format intégrant de texte commun.

Réglage fin

La formation des variables d'un module importé en même temps que ceux du modèle autour d' elle est appelée réglage fin. Un réglage fin peut entraîner une meilleure qualité, mais ajoute de nouvelles complications. Nous conseillons aux consommateurs de se pencher sur le réglage fin uniquement après avoir exploré des réglages de qualité plus simples, et uniquement si l'éditeur du module le recommande.

Pour les consommateurs

Pour activer le réglage fin, instancier le module avec hub.Module(..., trainable=True) pour rendre ses variables et Trainable d'importation tensorflow REGULARIZATION_LOSSES . Si le module comporte plusieurs variantes de graphiques, assurez-vous de choisir celle qui convient à la formation. Habituellement, c'est celui avec les balises {"train"} .

Choisissez un régime d'entraînement qui ne gâche pas les poids pré-entraînés, par exemple, un taux d'apprentissage inférieur à celui d'un entraînement à partir de zéro.

Pour les éditeurs

Pour faciliter le réglage fin pour les consommateurs, veuillez tenir compte des points suivants :

  • La mise au point nécessite une régularisation. Votre module est exporté avec la REGULARIZATION_LOSSES collection, qui est ce qui met votre choix tf.layers.dense(..., kernel_regularizer=...) , etc. , dans ce que le consommateur obtient de tf.losses.get_regularization_losses() . Préférez cette façon de définir les pertes de régularisation L1/L2.

  • Dans le modèle de l' éditeur, éviter de définir la régularisation L1 / L2 par l'intermédiaire des l1_ et l2_regularization_strength paramètres de tf.train.FtrlOptimizer , tf.train.ProximalGradientDescentOptimizer , et d' autres optimiseurs proximale. Ceux-ci ne sont pas exportés avec le module, et la définition globale des forces de régularisation peut ne pas être appropriée pour le consommateur. À l'exception de la régularisation L1 dans les modèles larges (c'est-à-dire linéaires clairsemés) ou larges et profonds, il devrait être possible d'utiliser à la place des pertes de régularisation individuelles.

  • Si vous utilisez l'abandon, la normalisation par lots ou des techniques de formation similaires, définissez leurs hyperparamètres sur des valeurs qui ont du sens pour de nombreuses utilisations attendues. Le taux d'abandon peut devoir être ajusté à la propension du problème cible au surapprentissage. Dans la normalisation par lots, la quantité de mouvement (c'est-à-dire le coefficient de décroissance) doit être suffisamment petite pour permettre un réglage fin avec de petits ensembles de données et/ou de grands lots. Pour les consommateurs avancés, envisagez d'ajouter une signature qui expose le contrôle des hyperparamètres critiques.