web-dev-qa-db-fra.com

Signification des étapes de validation dans Keras Liste des paramètres fit_generator séquentiels

J'utilise Keras avec un backend Tensorflow en Python. Pour être plus précis tensorflow 1.2.1 et sa version intégrée contrib.keras lib.

Je veux utiliser le fit_generator-Method d'un objet de modèle séquentiel, mais je suis confus avec ce que je devrais passer en tant que paramètres de méthode.

En lisant la doc ici j'ai eu l'information suivante:

  • générateur : a python) générateur de batch de données d'entraînement; boucle infinie sur ses données d'entraînement
  • validation_data : - dans mon cas - a python générateur de lots de données de validation; la doc ne mentionne pas une boucle sans fin sur ses données de validation
  • steps_per_Epoch : number of training batches = uniqueTrainingData / batchSize
  • étapes de validation : ???; = uniqueValidationData/taille du lot ???
  • use_multiprocessing : boolean; ne pas passer des arguments non picklables ???
  • travailleurs : nombre maximal de processus utilisés

Comme indiqué ci-dessus avec ??? Je ne sais pas vraiment ce que signifie validation_steps. Je connais la définition du document lié ci-dessus (Number of steps to yield from validation generator at the end of every Epoch) mais cela ne confond que my dans le contexte donné. D'après le document, je sais que le générateur validation_data doit générer des données, étiquetez des nuplets de la forme (inputs, targets). Contrairement à cela, la déclaration ci-dessus indique qu'il doit y avoir plusieurs "étapes à générer du générateur de validation à la fin de chaque époque", ce qui signifierait, dans ce contexte, que plusieurs lots de validation seraient générés après chaque époque de formation.

Questions sur validation_steps:

  • Est-ce que ça marche vraiment comme ça? Si oui, pourquoi? Je pensais qu'après chaque époque, un lot de validation, qui n'était idéalement pas utilisé auparavant, est utilisé pour la validation afin de s'assurer que la formation est validée sans risquer de "former" le modèle afin qu'il fonctionne mieux sur les ensembles de validation déjà utilisés.
  • Dans le contexte de la question précédente: Pourquoi le nombre recommandé d’étapes de validation est-il uniqueValidationData / batches et pas uniqueValidationData / epochs? N'est-il pas préférable d'avoir par exemple 100 lots de validation pour 100 époques au lieu de x lots de validation où x pourrait être inférieur ou supérieur au nombre spécifié d'époques? Autre solution: si le nombre de lots de validation est bien inférieur à celui du nombre d'époches, le modèle est-il formé sans validation pour le reste des périodes ou les ensembles de validation sont-ils réutilisés/redistribués +?
  • Est-il important que les lots d'apprentissage et de validation aient la même taille (diviseur partagé des dividendes trainingDataCount et validationDataCount)?

Question supplémentaire sur use_multiprocessing:

  • Les tableaux numpy sont-ils sélectionnables ou dois-je les convertir en listes multidimensionnelles?
parameterskerasgeneratordata-fitting
20
Philipp Lange

Le générateur de validation fonctionne exactement comme le générateur de formation. Vous définissez le nombre de lots qu’il utilisera par époque.

  • Le générateur de formation donnera steps_per_Epoch lots.
  • Quand l’époque se termine, le générateur de validation donnera validation_steps lots.

Mais les données de validation n'ont absolument aucun rapport avec les données d'apprentissage. Il n'est pas nécessaire de séparer les lots de validation en fonction des lots de formation (je dirais même que cela ne sert à rien de le faire, à moins que vous n'ayez une intention très précise). De plus, le nombre total d'échantillons dans les données d'apprentissage n'est pas lié au nombre total d'échantillons dans les données de test.

L’intérêt de disposer de nombreux lots est simplement d’épargner la mémoire de votre ordinateur. Vous devez donc tester les petits packs les uns après les autres. Probablement, vous trouvez une taille de lot qui convient à votre mémoire ou à la durée d’entraînement prévue et utilisez cette taille.

Cela dit, Keras vous offre une méthode totalement gratuite, vous permettant ainsi de déterminer les lots de formation et de validation à votre guise.

Epoques:

Idéalement, vous utilisez toutes vos données de validation à la fois. Si vous n'utilisez qu'une partie de vos données de validation, vous obtiendrez des mesures différentes pour chaque lot. Ce qui peut vous faire penser que votre modèle s'est dégradé ou qu'il a été amélioré alors qu'il ne l'a pas été, vous venez de mesurer différents ensembles de validation.

C'est pourquoi ils suggèrent validation_steps = total_validation_samples // validation_batch_size.
Théoriquement, vous testez l’ensemble de vos données à chaque époque, de la même façon que vous devriez normalement former l’ensemble de vos données à chaque époque.

Donc, théoriquement, chaque époque donne:

  • steps_per_Epoch = TotalTrainingSamples / TrainingBatchSize
  • validation_steps = TotalvalidationSamples / ValidationBatchSize

En gros, les deux vars sont: combien de lots par époque vous allez céder.
Cela garantit que, à chaque époque:

  • Vous entraînez exactement votre ensemble d'entraînement
  • Vous validez exactement votre ensemble de validation

Néanmoins, la manière dont vous séparez vos données de formation et de validation dépend entièrement de vous.

Si vous voulez avoir un lot différent par époque (les époques utilisant moins que la totalité de vos données), c'est bon, passez simplement steps_per_Epoch=1 ou validation_steps=1, par exemple. Le générateur n'étant pas réinitialisé après chaque époque, la deuxième époque prend le second lot, et ainsi de suite, jusqu'à ce qu'il se répète en boucle vers le premier lot.

Je préfère former toutes les données par époque, et si le temps est trop long, j'utilise un callback qui affiche les journaux à la fin de chaque lot:

from keras.callbacks import LambdaCallback

callbacks = callbacks=[LambdaCallback(on_batch_end=lambda batch,logs:print(logs))]

Multitraitement

Je n'ai jamais pu utiliser use_multiprocessing=True, il gèle au début de la première époque.

J'ai remarqué que les workers sont liés au nombre de lots préchargés à partir du générateur. Si vous définissez max_queue_size=1, vous aurez exactement workers quantité de lots préchargés.

Ils vous suggèrent d'utiliser keras Sequences lors du multitraitement. Les séquences fonctionnent plutôt comme un générateur, mais elles gardent une trace de l'ordre/de la position de chaque lot.

40
Daniel Möller