Я работаю над распознаванием речи с Tensorflow и планирую тренировать LSTM NN с массивом массивных волн. Из-за увеличения производительности я планирую использовать tfrecords. В Интернете есть несколько примеров (Inception for ex.), Где файлы tfrecords разбиты на фрагменты. У меня такой вопрос: какая польза от использования файла tfrecords в шарды? Есть ли дополнительный выигрыш в производительности этого сплита?
Ответы:
При исследовании преимуществ разделения на несколько файлов единственный разумный ответ пришел от одного из ребят из Google.
Они сказали, что прирост производительности незначительный, но я согласен, что разделение файлов может помочь, особенно если вы хотите перенести набор данных в другое место.
Имейте в виду, что теперь вам не нужно перемешивать перед сохранением, потому что (в настоящее время) рекомендуемый метод чтения TFRecords использует, tf.data.TFRecordDatasetкоторый реализует очень полезный .shuffle()метод.
Для тех, кто все еще задается вопросом: это так, что вы можете перемешать свои данные. С вашими записями TF в одном файле вы не можете перетасовать заказ. Это обычно необходимо с SGD.
Тем не менее, с помощью шардов вы можете перетасовать порядок сегментов, что позволит вам приблизиться к перетасовке данных, как если бы у вас был доступ к отдельным TFRecords. Это явно лучше, чем ничего, и, очевидно, чем больше у вас осколков, тем лучше это приближение.
Альтернативой является предварительная перетасовка ваших данных путем дублирования или не использование TFRecords вообще.
Разделение файлов TFRecord на осколки помогает перетасовать большие наборы данных, которые не помещаются в память.
Представьте, что у вас есть миллионы обучающих примеров, сохраненных на диске, и вы хотите многократно выполнять их в процессе обучения. Кроме того, предположим, что для каждого повторения обучающих данных (т.е. для каждой эпохи) вы хотите загружать данные в совершенно случайном порядке.
Один из подходов состоит в том, чтобы иметь один файл на учебный пример и генерировать список всех имен файлов. Затем в начале каждой эпохи вы перемешиваете список имен файлов и загружаете отдельные файлы. Проблема этого подхода заключается в том, что вы загружаете миллионы файлов из случайных мест на вашем диске. Это может быть медленным, особенно на жестком диске. Даже массив RAID 0 не поможет со скоростью, если вы загружаете миллионы маленьких файлов из случайных мест. Проблема становится еще хуже, если вы получаете доступ к файлам через сетевое соединение.
Другой подход заключается в чтении обучающих примеров по порядку из одного большого файла TFRecord и перемешивании примеров в памяти с использованием буфера перемешивания. Однако буфер случайного воспроизведения обычно не может быть больше памяти DDR, доступной вашему ЦП. И если буфер перемешивания значительно меньше, чем ваш набор данных, то он может не адекватно перемешивать данные. Данные могут быть «локально» перетасованы, но не «глобально» перетасованы. То есть примеры из начала набора данных не могут быть перемешаны с примерами из конца набора данных.
Хорошее решение - использовать сбалансированную комбинацию двух вышеупомянутых подходов, разделив ваш набор данных на несколько файлов TFRecord (называемых осколками). В течение каждой эпохи вы можете перетасовывать имена осколков для получения глобальной перестановки и использовать буфер перестановок для получения локальной перестановки. Хороший баланс сделает шарды достаточно большими, чтобы предотвратить проблемы со скоростью диска, но при этом шарды будут достаточно маленькими, чтобы можно было адекватно перетасовать буфер перемешивания.
Вот точные шаги:
Разделение файла TFRecords на несколько сегментов имеет по существу 3 преимущества:
.shuffle()Метод не является идеальным решением, если у вас есть один большой файл tfrecord. Перемешанный вывод несколько связан с исходным порядком, если вы не используете большой размер буфера. Я думаю, что необходимо предварительно перемешать данные перед сохранением в tfrecord или разбить их на фрагменты, когда у вас большой набор данных.