Значение validation_steps в списке параметров Keras Sequential fit_generator

Я использую Keras с бэкэндом Tensorflow в Python. Точнее, тензор потока 1.2.1 и его сборка -in contrib.keras lib.

Я хочу использовать метод fit_generator объекта последовательной модели, но меня смущает то, что я должен передать в качестве метода-параметров.

Прочитав документ здесь, я получил следующую информацию:

генератор: генератор пакетов данных обучения Python; бесконечно перебирая свои тренировочные данные
validation_data: -in мой случай - генератор пакетов данных проверки Python; в документе не упоминается бесконечный цикл по проверочным данным
steps_per_epoch: number of training batches = uniqueTrainingData / batchSize
этапы проверки: ???; = uniqueValidationData/размер пакета???
use_multiprocessing: логический; не передавайте неприемлемые аргументы???
рабочие: максимальное количество используемых процессов

Как указано выше с??? Я действительно не знаю, что означает validation_steps. Я знаю определение вышеупомянутого связанного документа (Number of steps to yield from validation generator at the end of every epoch), но это только сбивает меня с толку в данном контексте. Из документа я знаю, что генератор validation_data должен выдавать данные, пометить кортежи в форме (inputs, targets). В противоположность этому вышеприведенное утверждение указывает на то, что должно быть несколько "шагов для получения из генератора валидации в конце каждой эпохи", что в этом контексте означало бы, что после каждой эпохи обучения будет получено несколько пакетов валидации.

Вопросы о validation_steps:

Это действительно так работает? Если так: почему? Я думал, что после каждой эпохи одна партия валидации, которая в идеале не использовалась ранее, используется для валидации, чтобы убедиться, что тренинг проходит валидацию, не рискуя "обучить" модель работать лучше на уже используемых наборах валидации.
В контексте предыдущего вопроса: почему рекомендуемое количество шагов проверки uniqueValidationData / batches, а не uniqueValidationData / epochs? Не лучше ли иметь, например, 100 пакетов проверки для 100 эпох вместо x пакетов проверки, где x может быть меньше или больше указанного числа эпох? Альтернативно: если у вас намного меньше пакетов проверки, чем количество эпох, будет ли модель обучена без проверки для оставшихся эпох, или наборы проверки будут повторно использованы/переставлены + повторно использованы?
Важно ли, чтобы пакеты обучения и проверки имели одинаковый размер пакета (общий делитель дивидендов trainingDataCount и validationDataCount)?

Дополнительный вопрос о use_multiprocessing:

Можно ли добавлять к множеству массивов или мне нужно конвертировать их в многомерные списки?

Ответ 1

Генератор проверки работает точно так же, как обучающий генератор. Вы определяете, сколько партий он будет иметь за эпоху.

Тренировочный генератор выдаст партии steps_per_epoch.
Когда эпоха заканчивается, генератор проверки выдаст партии validation_steps.

Но данные валидации не имеют абсолютно никакого отношения к данным обучения. Нет необходимости разделять контрольные пакеты в соответствии с учебными пакетами (я бы даже сказал, что в этом нет никакого смысла, если только у вас нет особого намерения). Кроме того, общее количество выборок в обучающих данных не связано с общим количеством выборок в тестовых данных.

Смысл в том, чтобы иметь много пакетов, просто для того, чтобы сэкономить память компьютера, поэтому вы тестируете меньшие пакеты по одной за раз. Возможно, вы найдете размер партии, который будет соответствовать вашей памяти или ожидаемому времени тренировки, и будете использовать этот размер.

Тем не менее, Keras дает вам совершенно бесплатный метод, так что вы можете определять тренировку и пакеты проверки по своему желанию.

Эпохи:

В идеале вы должны использовать все свои данные проверки сразу. Если вы используете только часть своих данных проверки, вы будете получать разные показатели для каждого пакета, что может заставить вас думать, что ваша модель становилась хуже или лучше, чем на самом деле, вы просто измеряли разные наборы проверки.

Вот почему они предлагают validation_steps = total_validation_samples // validation_batch_size.
Теоретически, вы проверяете все данные каждую эпоху, так как теоретически вы должны также тренировать все данные каждую эпоху.

Итак, теоретически каждая эпоха дает:

steps_per_epoch = TotalTrainingSamples / TrainingBatchSize
validation_steps = TotalvalidationSamples / ValidationBatchSize

По сути, две переменные таковы: сколько партий за эпоху вы дадите.
Это гарантирует, что в каждую эпоху:

Вы тренируете ровно весь свой тренировочный набор
Вы подтверждаете весь свой набор проверки

Тем не менее, это зависит только от вас, как вы разделяете ваши данные обучения и проверки.

Если вы хотите иметь одну отдельную партию для каждой эпохи (эпохи, использующие меньше ваших данных), все в порядке, просто, например, передайте steps_per_epoch=1 или validation_steps=1. Генератор не сбрасывается после каждой эпохи, поэтому вторая эпоха будет принимать вторую партию и т.д. До тех пор, пока она снова не вернется к первой партии.

Я предпочитаю тренировать все данные за эпоху, и если время слишком велико, я использую callback, который показывает журналы в конце каждого пакета:

from keras.callbacks import LambdaCallback

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

Multiprocessing

Я никогда не мог использовать use_multiprocessing=True, он замирает в начале первой эпохи.

Я заметил, что workers связаны с тем, сколько партий предварительно загружено из генератора. Если вы определите max_queue_size=1, у вас будет точно workers количество предварительно загруженных партий.

Они предлагают вам использовать keras Sequence при многопроцессорной обработке. последовательности работают как генератор, но отслеживают порядок/положение каждой партии.