Я працюю над розпізнаванням мовлення з Tensorflow і планую навчити LSTM NN з масивними наборами хвиль. Через підвищення продуктивності я планую використовувати tfrecords. В Інтернеті є кілька прикладів (Inception for ex.), Де файли tfrecords розбиті на фрагменти. Моє запитання: яка користь від створення файлів tfrecords в черепки? Чи є додаткове підвищення продуктивності цього розколу?
Відповіді:
Досліджуючи переваги розбиття на декілька файлів, єдиний розумний відповідь прийшов від одного з людей, що займаються Google.
Вони сказали, що підвищення продуктивності є незначним, але я згоден, що розділення файлів може допомогти, особливо якщо ви хочете перенести набір даних в інше місце.
Майте на увазі, що тепер вам не потрібно перетасовувати перед збереженням, оскільки (на даний момент) рекомендований метод для читання TFRecords використовує tf.data.TFRecordDatasetякий реалізує дуже корисний .shuffle()метод.
Для тих, хто все ще цікавиться: це так, що ви можете переміщувати свої дані. Завдяки TFrecords в одному файлі ви не можете перетасувати замовлення. Зазвичай це необхідно для SGD.
Однак, за допомогою осколків, ви можете змінити порядок роботи фрагментів, що дозволяє наблизити перетасування даних, як якщо б ви мали доступ до окремих записів TFRecord. Це явно краще, ніж нічого, і очевидно, чим більше осколків у вас є, тим краще це наближення.
Альтернативою є попереднє переміщення даних шляхом їх дублювання або взагалі не використовувати TFRecords.
Розбиття файлів TFRecord на осколки допомагає перетасувати великі набори даних, які не впишуться в пам'ять.
Уявіть, що у вас є мільйони прикладів тренувань, збережених на диску, і ви хочете кілька разів запускати їх через навчальний процес. Крім того, припустимо, що для кожного повторення навчальних даних (тобто кожної епохи) ви хочете завантажувати дані в абсолютно випадковому порядку.
Один із підходів - мати один файл на прикладі навчання та генерувати список усіх імен файлів. Потім на початку кожної епохи ви перетасовуєте список імен і завантажуєте окремі файли. Проблема такого підходу полягає в тому, що ви завантажуєте мільйони файлів з випадкових місць на свій диск. Це може бути повільним, особливо на жорсткому диску. Навіть масив RAID 0 не допоможе зі швидкістю, якщо ви завантажуєте мільйони невеликих файлів з випадкових місць. Проблема ще більше загострюється, якщо ви отримуєте доступ до файлів через мережеве з'єднання.
Іншим підходом є читання навчальних прикладів послідовно з одного великого файлу TFRecord та переміщення прикладів у пам'яті за допомогою буфера перетасовки. Однак буфер переміщення зазвичай не може бути більшим, ніж пам'ять DDR, доступна вашому процесору. І якщо буфер перетасовки значно менший, ніж ваш набір даних, він може не адекватно переміщувати дані. Дані можуть бути переміщені "локально", але не "глобально" перемішуватися. Тобто приклади з початку набору даних можуть бути не змішані з прикладами з кінця набору даних.
Хорошим рішенням є використання збалансованої комбінації перерахованих вище двох підходів, розділивши ваш набір даних на декілька файлів TFRecord (звані фрагментами). Під час кожної епохи ви можете переміщувати імена файлів відтінків, щоб отримати глобальне переміщення, і використовувати буфер перетасовки для отримання локального перетасування. Хороший баланс зробить осколки досить великими, щоб запобігти проблемам швидкості диска, але збереже осколки досить маленькими, щоб забезпечити адекватне переміщення за допомогою буфера перетасовки.
Ось точні кроки:
Розщеплення файлу TFRecords на кілька фрагментів має, по суті, три переваги:
.shuffle()метод не є ідеальним рішенням, якщо у вас є один великий файл tfrecord. Перемішаний вихід деяким чином пов'язаний з початковим порядком, якщо ви не використовуєте великий розмір буфера. Я думаю, що попередньо перетасувати дані перед збереженням на tfrecord або розбиттям на фрагменти потрібно, коли у вас є великий набір даних.