Czy batch_size w Keras ma jakikolwiek wpływ na jakość wyników?

Mam zamiar wytrenować dużą sieć LSTM z 2-3 milionami artykułów i walczę z błędami pamięci (używam AWS EC2 g2x2large).

Dowiedziałem się, że jednym z rozwiązań jest zmniejszenie batch_size. Nie jestem jednak pewien, czy ten parametr dotyczy tylko problemów z wydajnością pamięci lub czy wpłynie to na moje wyniki. W rzeczywistości zauważyłem również, że batch_sizew przykładach zwykle stosuje się potęgę dwóch, czego też nie rozumiem.

Nie przeszkadza mi, że trenowanie mojej sieci trwa dłużej, ale chciałbym wiedzieć, czy obniżenie batch_sizejakości obniży jakość moich prognoz.

Dzięki.

Po półtora roku wracam do mojej odpowiedzi, ponieważ moja poprzednia odpowiedź była błędna.

Wielkość partii ma znaczący wpływ na naukę. Po przełożeniu partii przez sieć następuje uśrednienie gradientów. Pomysł polega na tym, że jeśli rozmiar partii jest wystarczająco duży, zapewni to wystarczająco stabilne oszacowanie gradientu pełnego zestawu danych. Pobierając próbki ze zbioru danych, oceniasz gradient, jednocześnie znacznie obniżając koszty obliczeniowe. Im niżej zejdziesz, tym mniej dokładne będzie twoje oszacowanie, jednak w niektórych przypadkach te głośne gradienty mogą pomóc uniknąć lokalnych minimów. Gdy jest zbyt niska, waga sieci może po prostu przeskakiwać, jeśli dane są hałaśliwe i może nie być w stanie się uczyć lub zbiega się bardzo powoli, co negatywnie wpływa na całkowity czas obliczeń.

Kolejną zaletą przetwarzania wsadowego jest obliczanie GPU, procesory graficzne są bardzo dobre w równoległym wykonywaniu obliczeń w sieciach neuronowych, jeśli część obliczeń jest taka sama (na przykład powtarzane mnożenie macierzy przez tę samą macierz wagową twojej sieci). Oznacza to, że wielkość partii 16 zajmie mniej niż dwukrotność wielkości partii 8.

W przypadku, gdy potrzebujesz większych rozmiarów partii, ale nie zmieści się ona na twoim GPU, możesz nakarmić małą partię, zapisać szacunkowe gradienty i nakarmić jedną lub więcej partii, a następnie wykonać aktualizację wagi. W ten sposób uzyskasz bardziej stabilny gradient, ponieważ zwiększyłeś swój wirtualny rozmiar partii.

ŹLE, STARA ODPOWIEDŹ: [[[Nie, rozmiar partii średnio wpływa tylko na szybkość uczenia się, a nie na jakość uczenia się. Batch_sizes również nie musi być potęgami 2, chociaż rozumiem, że niektóre pakiety pozwalają tylko na potęgi 2. Powinieneś spróbować uzyskać swój batch_size możliwie najwyższy, który wciąż mieści się w pamięci twojego GPU, aby uzyskać maksymalną możliwą prędkość .]]]]

Uważam, że zaakceptowana odpowiedź jest prawdopodobnie błędna. Istnieją warianty w algorytmach spadku gradientu .

1. Zanikanie gradientu waniliowego : Tutaj oblicza się gradient na wszystkich punktach danych na jednym zdjęciu i przyjmuje się średnią. Dlatego mamy płynniejszą wersję gradientu, której nauka zajmuje więcej czasu.

2. Stochastyczne zejście gradientu : tutaj jeden punkt danych na raz, stąd gradient jest agresywny (hałaśliwe gradienty), stąd będzie dużo oscylacji (używamy parametrów Momentum - np. Nesterov do kontrolowania tego). Jest więc szansa, że ​​twoje oscylacje mogą sprawić, że algorytm nie osiągnie lokalnego minimum (rozbieżność).

3. Mini-Batch Gradient Descent : który bierze zalety obu poprzednich uśrednia gradienty małej partii. Dlatego nie jest zbyt agresywny jak SGD i pozwala na naukę online, czego nigdy nie pozwalał Vanilla GD.

Im mniejsza Mini-Batch, tym lepsza byłaby wydajność twojego modelu (nie zawsze) i oczywiście ma to związek z zbyt szybkim uczeniem się epok. Jeśli trenujesz na dużym zbiorze danych, potrzebujesz szybszej konwergencji z dobrą wydajnością, dlatego wybieramy Batch-GD.

SGD ma ustalony parametr uczenia, dlatego uruchamiamy inne Adaptacyjne Optymalizatory, takie jak Adam, AdaDelta, RMS Prop itp., Które zmieniają parametr uczenia na podstawie historii Gradientów.

Co dziwne, odkryłem, że większe rozmiary partii za pomocą keras wymagają więcej epok do zbiegania się.

Na przykład dane wyjściowe tego skryptu oparte na teście integracji keras to

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

Związane z

• Keras problem 4708 : użytkownik okazał się używać BatchNormalization, co wpłynęło na wyniki.
• Ten samouczek na temat LSTM, sekcja Strojenie wielkości partii
• wyniki wyszukiwania dla wielkości partii keras lstm wpływ na wynik
• Moja sieć neuronowa nie działa! Co powinienem zrobić? , punkt 5 (Użyłeś zbyt dużego rozmiaru partii) dokładnie to omawia

Użycie zbyt dużej wielkości partii może mieć negatywny wpływ na dokładność sieci podczas treningu, ponieważ zmniejsza stochastyczność spadku gradientu.

Większość czasu, zwiększając edytuj batch_sizepożądane jest, aby przyspieszyć obliczenia, ale istnieją inne prostszych sposobów, aby to zrobić, jak przy użyciu typów danych mniejszym ślad za pośrednictwem dtypeargumentu, czy to w Keras lub tensorflow , np float32zamiastfloat64