トレーニング パイプラインに関する追加のガイダンス

このセクションでは、トレーニング パイプラインについて詳しく説明します。

入力パイプラインの最適化

概要: 入力バウンド パイプラインの原因と介入は、タスクに大きく依存します。プロファイラを使用して、一般的な問題を探します。

次のいずれかなど、適切なプロファイラを使用して、入力バウンド パイプラインを診断します。

最終的に、具体的な原因と介入はタスクに大きく依存します。エンジニアリング上の考慮事項（ディスク フットプリントの最小化など）が入力パイプラインのパフォーマンスに影響する可能性があります。

入力バウンド パイプラインの一般的な原因は次のとおりです。

  • データがトレーニング プロセスとコロケーションされていないため、I/O レイテンシが発生します。たとえば、ネットワーク経由でトレーニング データを読み取ると、I/O レイテンシが発生する可能性があります。
  • 高価なオンライン データの前処理。オフラインで 1 回前処理を行い、結果を保存することを検討してください。
  • データ パイプラインのプリフェッチを妨げる意図しない同期バリア。たとえば、CommonLoopUtils のデバイスとホストの間で指標を同期する場合などです。

入力バウンド パイプラインには、次の介入をおすすめします。

モデル性能の評価

概要: トレーニングよりも大きなバッチサイズで評価を実行します。評価は、定期的な時間間隔ではなく、定期的なステップ間隔で実行します。

評価設定

次の設定を使用して、モデルのパフォーマンスを評価できます。

  • オンライン評価: モデルが本番環境で予測を提供しているときに指標を収集します。オンライン評価は、モデルの使用方法と一致するため、モデルの品質を最も現実的に評価できます。
  • オフライン評価: 本番環境を代表するオフライン トレーニング セット、検証セット、テストセットでモデルを実行するときに指標を収集します。問題によっては、オフライン評価がかなり複雑になり、計算コストが高くなることがあります。
  • 定期的な評価: オフライン評価のプロキシとなる可能性のある指標、またはオフライン評価で使用されるデータの一部をモデルのトレーニング中に収集します。定期的な評価は最も実用的で経済的な選択肢ですが、本番環境を完全に表すことはできません。トレーニング中に受信したシグナルの信頼性を損なうことなく、オフライン評価の迅速なプロキシを使用することを目指します。

定期的な評価の設定

トレーニング中に定期的な評価を実行することをおすすめする理由は次のとおりです。

最もシンプルな構成は、同じコンピューティング インスタンス内でトレーニングと定期的な評価の両方を行い、トレーニングと評価を定期的に交互に行うことです。この場合、評価の実行に使用するバッチサイズは、トレーニングに使用するバッチサイズ以上にする必要があります。これは、評価中にモデルのアクティベーションを維持する必要がないため、例ごとの計算要件が低くなるためです。

定期的な評価は、時間間隔ではなく、定期的なステップ間隔で実行します。時間間隔に基づいて評価すると、トレーニング曲線が解釈しにくくなることがあります。特に、トレーニング ジョブのプリエンプションやネットワーク レイテンシの問題などにより、トレーニングが影響を受ける可能性がある場合はなおさらです。

検証指標とテスト指標の周期性（シャッフルされたトレーニング セット、検証セット、テストセットの分割を使用する場合）は、次のような実装バグを示している可能性があります。

  • テストデータがトレーニング データと重複している。
  • トレーニング データが適切にシャッフルされていない。

定期的なステップ間隔で評価すると、これらの問題を簡単に検出できます。

評価セットがバッチサイズで割り切れない場合、部分バッチが発生する可能性があります。パディングされた例が正しく重み付けされていることを確認します（バッチの平均損失を計算する例の加重平均など）。これにより、損失関数がパディングされた例によってバイアスされないようにします。多くの場合、これらのパディングされた例に重み 0 を指定できます。

オフライン分析をサポートするために、評価ごとに十分な情報を保存します。デバッグに役立つため、個々の例の選択で予測を保存することをおすすめします。SavedModels などのアーティファクトを生成すると、評価ジョブの完了後にアドホック モデル検査を簡素化できます。

定期的な評価のサンプルを選択する

定期的な評価ジョブは、妥当な時間内にオフライン評価セット全体で指標を計算するのに十分な速さで実行されない可能性があります。この問題では、定期的な評価のためにデータをサンプリングする必要があることがよくあります。サンプリングされたデータセットを構築する場合は、サンプルサイズの問題と、不均衡なデータセットの特別な懸念事項を考慮してください。

サンプル数

定期的なジョブで使用されるサンプル データセットで計算されたパフォーマンスが、オフライン評価セット全体のパフォーマンスと一致することを確認します。つまり、サンプル データセットと完全なデータセットの間にスキューがないことを確認します。

定期的な評価に使用するデータセットは、次の両方を満たしている必要があります。

  • モデルの予測を全体にわたって簡単に生成できるほど小さい。
  • 次の両方を行うのに十分な大きさ:
    • モデルの改善を正確に測定する。つまり、ラベルノイズによって測定が圧倒されないようにします。
    • トライアル全体で複数の評価を順番に処理し、正確な推定値を生成する。つまり、ホールドアウト テストセットに一般化されない方法で、検証セットに時間とともに適応的に「適合」することを回避するのに十分な大きさです。ただし、この考慮事項が実際に問題になることはほとんどありません。

不均衡なデータセット

不均衡なデータセットの場合、まれな少数派クラスのパフォーマンスはノイズが多くなることがよくあります。少数派の例が少ないデータセットの場合は、正しく予測された例の数を記録して、精度の向上に関する詳細な分析情報を取得します。たとえば、感度が 0.05 向上したと聞くと素晴らしいように思えますが、その改善は 1 つの例が正しかっただけによるものでしょうか？

チェックポイントを保存して、最適なチェックポイントを事後的に選択する

概要: 固定数のステップでトレーニングを実行し、実行後に最適なチェックポイントを選択します。

ほとんどのディープ ラーニング フレームワークは、モデルのチェックポイントをサポートしています。つまり、モデルの現在の状態が定期的にディスクに保存されます。チェックポイントにより、トレーニング ジョブはコンピューティング インスタンスの中断に対して復元力を発揮できます。最適なチェックポイントは、特に検証セットのパフォーマンスが時間とともに増加し続けるのではなく、特定の値の周りで変動する場合は、最後のチェックポイントではないことがよくあります。

トレーニング中にこれまでに確認された上位 N 個のチェックポイントを追跡するようにパイプラインを設定します。トレーニングの終了時にモデルを選択するということは、最適なチェックポイントを選択することに他なりません。このアプローチを回顧的最適チェックポイント選択と呼びます。通常、見込みのある早期停止をサポートする必要はありません。トライアル予算を事前に指定し、これまでに確認された上位 N 個のチェックポイントを保持しているためです。

テストのトラッキングを設定する

概要: さまざまなテストをトラッキングするときは、調査のチェックポイントの最高のパフォーマンスや調査の簡単な説明など、いくつかの重要な要素をトラッキングします。

テストの結果はスプレッドシートで追跡することをおすすめします。スプレッドシートには、次の列が含まれていることがよくあります。

  • 調査名
  • スタディの構成が保存されている場所へのリンク。
  • スタディのメモまたは簡単な説明。
  • 実行されたトライアルの数
  • この研究における最適なチェックポイントの検証セットでのパフォーマンス。
  • トレーニングを開始するために必要な未送信の変更に関する具体的な再現コマンドまたはメモ。

上記の情報を少なくとも取得できる便利な追跡システムを見つけます。追跡されていないテストは存在しないのと同じです。

バッチ正規化の実装の詳細

概要: 現在では、バッチ正規化を LayerNorm に置き換えることがよくありますが、置き換えられない場合は、バッチサイズやホスト数を変更する際に注意すべき点があります。

バッチ正規化では、現在のバッチの平均と分散を使用してアクティベーションを正規化します。ただし、マルチデバイス設定では、明示的に同期しない限り、これらの統計情報はデバイスごとに異なります。逸話的な報告（主に ImageNet）によると、これらの正規化統計量を約 64 個の例のみを使用して計算する方が、実際にはうまく機能することが示されています。（Train longer, generalize better: closing the generalization gap in large batch training of neural networks の Ghost Batch Normalization の説明をご覧ください）。バッチサイズの合計とバッチ正規化統計の計算に使用されるサンプル数を分離することは、バッチサイズの比較に特に役立ちます。

ゴースト バッチ正規化の実装では、デバイスごとのバッチサイズが仮想バッチサイズよりも大きい場合を正しく処理できないことがあります。この場合、各デバイスでバッチをサブサンプリングして、バッチ正規化統計情報の適切な数のサンプルを取得する必要があります。

テストモードのバッチ正規化で使用される指数移動平均（EMA）は、トレーニング統計の線形結合にすぎません。したがって、これらの EMA はチェックポイントに保存する前に同期するだけで済みます。ただし、バッチ正規化の一般的な実装の中には、これらの EMA を同期せず、最初のデバイスの EMA のみを保存するものがあります。

マルチホスト パイプラインに関する考慮事項

概要: ロギング、評価、RNG、チェックポイント処理、データ シャーディングでは、マルチホスト トレーニングでバグが簡単に発生する可能性があります。

マルチホスト パイプラインの場合は、次の操作を行います。

  • パイプラインが 1 つのホストでのみロギングとチェックポイントを行っていることを確認します。
  • 評価またはチェックポイントの前に、ホスト間でバッチ正規化統計情報を同期します。
  • 通常、パフォーマンスが向上するため、ホスト間でデータファイルをシャードします。

重要: ホスト間で同じ RNG シード（モデルの初期化用）と、ホスト間で異なるシード（データのシャッフル/前処理用）があることを確認してください。そのため、適切にマークしてください。

前へ
各トレーニング実行のステップ数の決定
次へ
学習率