Чи має batch_size в Керасі вплив на якість результатів?

Я збираюся тренувати велику мережу LSTM з 2-3 мільйонами статей і борюся з помилками пам'яті (я використовую AWS EC2 g2x2large).

Я з'ясував, що одне рішення - зменшити batch_size. Однак я не впевнений, чи цей параметр пов’язаний лише з проблемами ефективності пам'яті чи він вплине на мої результати. Власне кажучи, я також помітив, що batch_sizeвикористання в прикладах зазвичай є силою двох, чого я також не розумію.

Я не заперечую, якщо тренуватись у моїй мережі довше, але я хотів би знати, чи зменшення якості batch_sizeзнизить якість моїх прогнозів.

Спасибі.

Через півтора року я повертаюся до своєї відповіді, оскільки моя попередня відповідь була неправильною.

Розмір партії значно впливає на навчання. Що відбувається, коли ви розміщуєте партію через вашу мережу, це те, що ви оцінюєте середні градієнти. Концепція полягає в тому, що якщо розмір вашої партії досить великий, це дасть достатньо стабільну оцінку того, яким буде градієнт повного набору даних. Беручи зразки з вашого набору даних, ви оцінюєте градієнт, значно зменшуючи обчислювальні витрати. Чим нижче ви йдете, тим менш точним буде ваш показник, проте в деяких випадках ці галасливі градієнти насправді можуть допомогти уникнути місцевих мінімумів. Коли він занадто низький, ваги вашої мережі можуть просто стрибати, якщо ваші дані галасливі, і вони можуть не в змозі дізнатися або вони зближуються дуже повільно, що негативно впливає на загальний час обчислення.

Ще одна перевага пакетного пакетування - це для обчислення GPU, GPU дуже добре паралелізують обчислення, які відбуваються в нейронних мережах, якщо частина обчислень однакова (наприклад, повторне множення матриць на ту саму вагову матрицю вашої мережі). Це означає, що розмір партії 16 займе менше, ніж удвічі більше, ніж розмір партії 8.

У випадку, якщо вам потрібні великі розміри партії, але вона не підходить для вашого GPU, ви можете подати невелику партію, зберегти оцінки градієнта і подати одну або декілька партій, а потім зробити оновлення ваги. Таким чином ви отримуєте більш стабільний градієнт, оскільки ви збільшили розмір віртуальної партії.

WRONG, СТАРИЙ ВІДПОВІДЬ: [[[Ні, batch_size в середньому впливає лише на швидкість вашого навчання, а не на якість навчання. Batch_size також не повинні бути повноваженнями 2, хоча я розумію, що деякі пакети дозволяють отримати потужність лише 2. Ви повинні спробувати отримати свій batch_size максимальний, що все ще може відповідати пам’яті вашого GPU, щоб отримати максимальну швидкість .]]]]

Я вважаю, що прийнята відповідь, можливо, неправильна. Існують варіанти в алгоритмах спуску градієнта .

1. Спуск градієнта ванілі : Тут градієнт обчислюється по всіх точках даних за один кадр, і приймається середнє значення. Отже, у нас більш плавна версія градієнта потребує більше часу для вивчення.

2. Стохастичний спуск градієнта : Тут точка однієї інформації за один раз, отже, градієнт є агресивним (галасливі градієнти), отже, буде багато коливань (ми використовуємо параметри імпульсу - наприклад, Нестеров для управління цим). Тож є ймовірність, що ваші коливання можуть змусити алгоритм не досягти локального мінімуму. (Розходяться).

3. Міні-пакетний градієнт спуск : який приймає переваги обох попередніх, в середньому градієнти невеликої партії. Отже, не надто агресивний, як SGD, і дозволяє навчатись в Інтернеті, яке Ванільний GD ніколи не дозволяв.

Чим менше Mini-Batch, тим краще буде продуктивність вашої моделі (не завжди), і звичайно, це має відношення до ваших епох занадто швидкого навчання. Якщо ви тренуєтесь за великим набором даних, ви хочете швидшого зближення з хорошою продуктивністю, тому ми вибираємо Batch-GD.

SGD має фіксований параметр навчання, тому ми запускаємо інші адаптивні оптимізатори, такі як Adam, AdaDelta, RMS Prop тощо, який змінює параметр навчання на основі історії градієнтів.

Як не дивно, я виявив, що більші розміри партії з керами вимагають більше епох, щоб сходитися.

Наприклад, вихід цього сценарію на основі інтеграційного тесту керасу є

epochs 15   , batch size 16   , layer type Dense: final loss 0.56, seconds 1.46
epochs 15   , batch size 160  , layer type Dense: final loss 1.27, seconds 0.30
epochs 150  , batch size 160  , layer type Dense: final loss 0.55, seconds 1.74

Пов'язані

• Випуск Keras 4708 : користувач виявився, що користується BatchNormalization, що вплинуло на результати.
• Цей підручник з LSTM, розділ Налаштування розміру партії
• результати пошуку для керасу lstm розмір партії ефект на результат
• Моя нейронна мережа не працює! Що я повинен зробити? , пункт 5 (Ви використовували занадто великий розмір партії) обговорює саме це

Використання занадто великого розміру партії може негативно впливати на точність вашої мережі під час тренування, оскільки це зменшує стохастичність градієнтного спуску.

Edit: в більшості випадків, збільшення batch_sizeбажано прискорити обчислення, але є й інші більш прості способи зробити це, як використання типів даних меншою займаної площі з допомогою dtypeаргументу, то чи в keras або tensorflow , напр float32замістьfloat64