Kerasのbatch_sizeは結果の品質に影響を与えますか?


38

2-3百万の記事で大きなLSTMネットワークをトレーニングしようとしていますが、メモリエラーに苦労しています(AWS EC2 g2x2largeを使用しています)。

解決策の1つはを減らすことであることがわかりましたbatch_size。ただし、このパラメーターがメモリ効率の問題にのみ関連するのか、それが結果に影響するのかはわかりません。実際のところ、batch_size例で使用されているのは通常2のべき乗であることに気づきましたが、どちらもわかりません。

ネットワークのトレーニングに時間がかかるかどうかは気にしませんが、これを減らすbatch_sizeと予測の品質が低下するかどうかを知りたいです。

ありがとう。


この質問はケラスに固有のものではありません。私は一般的なconsesusが小さいサンプルサイズが遅く収束するが、極小値で立ち往生しにくいということであると思う
アレックス

バッチサイズが大きすぎると、同じ数のトレーニングエポックでも収束が妨げられる場合があります。
カーティスホワイト

回答:


43

1年半後、以前の答えが間違っていたため、答えに戻ります。

バッチサイズは学習に大きな影響を与えます。ネットワークにバッチを配置すると、勾配が平均化されます。コンセプトは、バッチサイズが十分に大きい場合、これにより、完全なデータセットの勾配がどの程度になるかを十分に安定して推定できるということです。データセットからサンプルを取得することにより、計算コストを大幅に削減しながら勾配を推定します。低くなるほど、推定値の精度は低くなりますが、場合によっては、これらのノイズの多い勾配が局所的な最小値から逃れるのに役立つことがあります。それが低すぎると、データにノイズがあり、学習できないか、収束が非常に遅い場合、ネットワークの重みが飛び跳ねて、計算時間全体に悪影響を及ぼします。

バッチ処理のもう1つの利点は、GPU計算の場合です。GPUは、計算の一部が同じ場合(たとえば、ネットワークの同じ重み行列での行列乗算の繰り返し)にニューラルネットワークで発生する計算の並列化に非常に優れています。これは、16のバッチサイズが8のバッチサイズの2倍未満の量で済むことを意味します。

より大きなバッチサイズが必要であるがGPUに収まらない場合は、小さなバッチをフィードし、勾配推定値を保存して1つ以上のバッチをフィードしてから、重みの更新を行うことができます。この方法では、仮想バッチサイズを増やしたため、より安定した勾配が得られます。

間違った古い回答:[[[いいえ、batch_sizeは平均して学習速度にのみ影響し、学習の質には影響しません。また、batch_sizesは2のべき乗である必要はありませんが、特定のパッケージでは2のべき乗しか許可されていないことを理解しています。 。]]]]


32を買う余裕はありませんが、16を買う余裕はあります。しかし、遅すぎることに気付きました。16〜32の値を試すか、16に固執する必要があると思いますか?
-hipoglucido

私はいくつかの値を試してみます。すべてのエポックはほぼ同じ時間である必要があるため、時間がかかりすぎません。この2のべき乗がGPUやKerasのバックエンドに依存しているので、これに興味があるので、まず17を試して、それが速いか遅いかを確認してください。しかし、私はちょうどつばにそれを充填する可能性が最高だと思う
ヤン・ファン・デア・Vegt

9
バッチサイズは学習の質に影響しないと確信していますか?いくつかのブログ/論文(?)を読んだことを覚えていますが、小さなバッチは大きなバッチよりもノイズの多いグラデーションを生成しますが、ノイズはローカルミニマムから抜け出すのに役立ちます。ただし、これがLSTMに適用されるかどうか/どのように適用されるかはわかりません。
-stmax

完全に確信しているわけではなく、十分な経験がありませんが、それを読んでいます。グラデーションの安定性が低いので、オフになっている可能性があります。
ヤン・ファン・デル・ベクト

2
1年半後、さらに多くの知識を得ることができ、同意します。私は私の答えを変更するつもりだ
ヤンファンVegtデア・

11

受け入れられた答えはおそらく間違っていると思う。Gradient Descent Algorithmsにはバリアントがあります。

  1. Vanilla Gradient Descent:ここでは、1回のショットですべてのデータポイントで勾配が計算され、平均が取得されます。したがって、グラデーションのよりスムーズなバージョンでは、学習に時間がかかります。

  2. 確率的勾配降下:ここでは一度に1つのデータポイントであるため、勾配は積極的(ノイズの多い勾配)であるため、多くの振動が発生します(これを制御するためにNesterovを使用します)。そのため、振動によりアルゴリズムが局所的な最小値に到達しない可能性があります(発散)。

  3. Mini-Batch Gradient Descent:前の両方の特典を利用して、小さなバッチの勾配を平均化します。したがって、SGDのように攻撃的すぎず、Vanilla GDが決して許可しなかったオンライン学習を許可します。

ミニバッチが小さければ小さいほど、モデルのパフォーマンスは向上します(常にではありません)。もちろん、エポックに関係しているため、学習が速すぎます。大規模なデータセットでトレーニングしている場合は、パフォーマンスを向上させて収束を高速化する必要があるため、Batch-GDを選択します。

SGDには学習パラメータが固定されていたため、Adam、AdaDelta、RMS Propなど、勾配の履歴に基づいて学習パラメータを変更する他の適応オプティマイザーを開始します。


3)通常ミニバッチと呼ばれる
アレックス

@Alex:変更を追加しました。
ジルジョンジュク

1
batch-sizeパラメーターに関する規則がないことに同意します。しかし、「ミニバッチが小さければ小さいほど、モデルのパフォーマンスは良くなります」というステートメントは、一般的なルールに反しています。通常、バッチサイズを最大化する必要があります
MonsieurBeilto

4

奇妙なことに、ケラスを含むより大きなバッチサイズでは、収束するためにより多くのエポックが必要になることがわかりました。

たとえば、kerasの統合テストに基づくこのスクリプトの出力は次のとおりです。

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

関連する

バッチサイズが大きすぎると、勾配降下の確率が低下するため、トレーニング中のネットワークの精度に悪影響を与える可能性があります。

編集:時間のほとんど、増加batch_sizeの計算を高速化することが望まれるが、経由で小さなフットプリントのデータ型を使用してのように、これを行うには、他のシンプルな方法がありますdtype内の引数かどうか、kerasまたはtensorflow例えば、float32代わりには、float64


より大きなバッチ(したがって、エポックあたりの数が少ない)を使用すると、エポックあたりの勾配の更新が少なくなります。「エポック」は、「トレーニング中にデータを1回通過する」ためのMLの専門用語です。トレーニングをスピードアップしようとしている場合、壁時間を測定し、エポックを無視します。
アンドリューワグナー
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.