このセクションでは、トレーニング パイプラインについて詳しく説明します。
入力パイプラインの最適化
概要: 入力バウンド パイプラインの原因と介入はタスクに大きく依存します。プロファイラを使用して、一般的な問題を探します。
入力バインドされたパイプラインを診断するには、次のいずれかのプロファイラを使用します。
- Perfetto（JAX 用）
- TensorFlow の TensorFlow Profiler。
具体的な原因と介入は、タスクに大きく依存します。 エンジニアリングに関する幅広い考慮事項（ディスク フットプリントの最小化など）により、入力パイプラインのパフォーマンスが低下する可能性があります。
入力バウンド パイプラインの一般的な原因は次のとおりです。
- データがトレーニング プロセスと同じ場所に配置されないため、I/O レイテンシが発生します。たとえば、ネットワーク経由でトレーニング データを読み取ると、I/O レイテンシが発生することがあります。
- 高コストのオンライン データの前処理。オフラインになったら前処理を行い、結果を保存することを検討してください。
- データ パイプラインのプリフェッチを妨害する意図しない同期障壁。たとえば、CommonLoopUtils のデバイスとホストの間で指標を同期する場合。
入力バウンド パイプラインには、次の介入をおすすめします。
- 入力をインストルメント化してサンプルをプリフェッチする（tf.data.Dataset.prefetch など）
- パイプラインの早い段階で、使用しない機能とメタデータをそれぞれから削除する。
- たとえば、tf.data サービスを使用して、入力パイプラインのサンプルを生成するジョブの数を増やします。
モデル性能の評価
概要: トレーニングよりも大きなバッチサイズで評価を実行します。評価は、一定の時間間隔ではなく一定のステップ間隔で実行します。
評価の設定
モデルのパフォーマンスを評価するには、次の設定を使用します。
- オンライン評価: モデルが本番環境で予測を提供しているときに指標を収集します。一般的に、オンライン評価では、モデルの使用方法と一致する最も現実的なモデル品質の評価を提供します。
- オフライン評価: 本番環境を代表するオフライン トレーニング、検証、またはテストセットでモデルが実行されたときに、指標を収集します。問題によっては、オフライン評価が複雑になり、計算コストが高くなる場合があります。
- 定期的な評価: モデルのトレーニング中に、オフライン評価のプロキシとなる可能性のある指標や、オフライン評価で使用されるデータのサブセットに関する指標を収集します。定期的な評価が最も現実的で経済的な選択肢ですが、本番環境が十分に反映されていない場合があります。トレーニング中に受信した信号の信頼性を犠牲にすることなく、オフライン評価の適切なプロキシを使用することを目指します。
定期的な評価の設定
トレーニング中は、次の理由により定期的な評価を行うことをおすすめします。
- トレーニングの進行状況をリアルタイムでモニタリングする。
- 遡及的なモデルのチェックポイント選択を容易にするため。
- トレーニングの最後にトレーニング曲線を調べる。
最も簡単な構成は、同じコンピューティング インスタンス内でトレーニングと定期的な評価の両方を実行し、トレーニングと評価で定期的に交互に行うことです。この場合、評価に使用するバッチサイズは、トレーニングに使用されるバッチサイズ以上の大きさにする必要があります。これは、評価中にモデルの有効化を維持する必要がないためです。これにより、例ごとの計算要件が低くなります。
時間間隔ではなく一定のステップ間隔で定期的に評価を行います。時間間隔に基づいて評価すると、特にトレーニング ジョブのプリエンプションやネットワーク レイテンシの問題などでトレーニングが影響を受ける可能性がある場合に、トレーニング曲線の解釈が難しくなることがあります。
検証指標とテスト指標の周期は（シャッフル トレーニング セット、検証セット、テストセット分割を使用する場合）、次のような実装バグを示していることがあります。
- トレーニング データと重複するデータをテストし、
- トレーニング データが適切にシャッフルされない。
一定のステップ間隔で評価することで、このような問題を検出しやすくなります。
部分バッチは、評価セットをバッチサイズで割り切れない場合に発生することがあります。損失関数がバイアスによってバイアスされないように、パディングされたサンプルに適切な重み付け（バッチの平均損失を計算するサンプルの加重平均など）を行います。パディングされた例に 0 の重みを与えることもよくあります。
評価ごとに十分な情報を保存して、オフライン分析に役立てます。個々のサンプルに対する予測は、デバッグを行う際非常に重要であるため、保存するのが理想的です。SavedModels などのアーティファクトを生成すると、評価ジョブの完了後のアドホック モデル検査が簡素化されます。
定期的な評価に使用するサンプルの選択
定期的な評価ジョブの実行速度が遅くなり、完全なオフライン評価セットの指標を妥当な時間で計算できない場合があります。多くの場合、定期的な評価のためにサンプリング データが必要になります。サンプリングされたデータセットを構築するときは、サンプルサイズと不均衡なデータセットにおける特別な懸念事項を考慮してください。
サンプル数
定期的なジョブで使用されるサンプリングされたデータセットで計算されたパフォーマンスが、オフライン評価セット全体のパフォーマンスと一致していることを確認します。つまり、サンプリングされたデータセットと完全なデータセットの間にスキューがないことを確認します。
定期的な評価に使用するデータセットは、次の両方にする必要があります。
- モデル予測全体を簡単に生成できる小さいサイズ。
- 次の両方を行うのに十分な大きさ
- モデルの改善を正確に測定します。つまり、測定値がラベルノイズによって過負荷にならないようにする必要があります。
- トライアル全体を通した複数の評価を順番に行い、それでも正確な見積もりを生成する。これは、ホールドアウトしたテストセットに一般化されない方法で、検証セットへの「適応」を経時的に適応させるのに十分な大きさです。ただし、この点を考慮することは現実的なものではありません。
不均衡なデータセット
不均衡なデータセットでは、まれにマイノリティ クラスでのパフォーマンスにノイズが生じます。少数のマイノリティ サンプルしかないデータセットの場合は、正しく予測されたサンプルの数を記録し、精度の改善に関する詳細な分析情報を取得します。たとえば、.05 の感度向上は楽しそうに聞こえますが、正しい例が 1 つあるだけで改善されたのでしょうか。
チェックポイントの保存と、最も遡及的なチェックポイントの遡及的な選択
概要: 一定のステップのトレーニングを実施し、遡及的に最適なチェックポイントを選択します。
ほとんどのディープ ラーニング フレームワークはモデルのチェックポイントをサポートしています。つまり、モデルの現在の状態はディスクに定期的に保存されます。チェックポイントを設定することで、コンピューティング インスタンスの中断に対するトレーニング ジョブの復元力を高めることができます。特に検証セットのパフォーマンスが時間の経過とともに向上せず、特定の値に関して変動する場合は、最良のチェックポイントが最後のチェックポイントではないことがよくあります。
トレーニング中にこれまでに見つかった N 個の最適なチェックポイントを追跡するようにパイプラインを設定します。トレーニングの最後に、モデルの選択とは、最適なチェックポイントを選択することを指します。このアプローチは、遡及的な最適なチェックポイント選択と呼ばれます。トライアルの予算を事前に指定し、これまでに見つかった N 個の最適なチェックポイントを保持するため、通常、早期停止のサポートは必要ありません。
テスト追跡の設定
サマリー: さまざまなテストをトラッキングする場合は、調査におけるチェックポイントのパフォーマンスの最高値や、調査の簡単な説明など、多くの基本事項を追跡します。
テスト結果はスプレッドシートでトラッキングすることをおすすめします。スプレッドシートには次の列が含まれていることがよくあります。
- 調査名
- スタディの構成が保存されている場所へのリンク。
- 調査のメモまたは簡単な説明。
- 実行したトライアルの数
- スタディの最適なチェックポイントの検証セットでのパフォーマンス。
- 未送信の変更に関してトレーニングを開始するために必要な、特定の再現コマンドまたはメモ。
少なくとも上記の情報をキャプチャできる便利なトラッキング システムを探します。トラッキングできないテストが存在する可能性もあります。
バッチ正規化の実装の詳細
概要: 最近は、バッチ正規化を LayerNorm で置き換えることができますが、置き換えができない場合は、バッチサイズまたはホスト数を変更するときに詳細な情報が必要になります。
バッチ正規化は、現在のバッチの平均と分散を使用して活性化を正規化します。ただし、マルチデバイス設定では、明示的に同期しない限り、これらの統計情報はデバイスごとに異なります。 エピソード レポート（主に ImageNet 上）は、実際には約 64 個のサンプルのみを使用してこれらの正規化統計を計算する方が、実際はより優れていることを示しています。（ニューラル ネットワークの大規模なバッチ トレーニングで一般化のギャップを埋める: 「トレーニング、より一般化」のほうが、ゴーストのバッチ正規化に関する説明を参照）バッチサイズの比較には、バッチサイズの合計とバッチノルム統計の計算に使用されるサンプル数の分離が特に役立ちます。
ゴーストのバッチ正規化実装は、デバイスごとのバッチサイズが仮想バッチサイズより大きい場合、常に正しく処理されないことがあります。この場合、バッチノルム統計の例の適切な数を取得するには、各デバイスでバッチをサブサンプリングする必要があります。
テストモードのバッチ正規化で使用される指数移動平均（EMA）は、トレーニング統計の線形の組み合わせです。したがって、これらの EMA はチェックポイントに保存する前に同期するだけで済みます。ただし、バッチ正規化の一般的な実装では、これらの EMA が同期されず、最初のデバイスからのみ EMA が保存されます。
マルチホスト パイプラインに関する考慮事項
概要: ロギング、評価、RNG、チェックポインティング、データ シャーディングのために、マルチホスト トレーニングではバグが発生しやすくなります。
マルチホスト パイプラインの場合は、次の操作を行います。
- パイプラインが 1 つのホストでのみロギングとチェックポイントを実行していることを確認します。
- 評価またはチェックポイント処理を行う前に、ホスト間でバッチ正規化の統計情報を同期します。
- ホスト間でデータファイルをシャーディングすると、通常はパフォーマンスが向上するため。
重要: ホスト間で同じ RNG シード（モデル初期化用）とホスト間で異なるシード（データ シャッフル/前処理用）があることを確認します。そのため、アプリを適切にマークする必要があります。