View a markdown version of this page

RFT トレーニングのモニタリング - Amazon Nova
追跡する主要なメトリクスRFT 後の評価ファインチューニングされたモデルの使用制限事項とベストプラクティストラブルシューティング

RFT トレーニングのモニタリング

トレーニング中に主要なメトリクスをモニタリングして効果的な学習となるようにし、潜在的な問題を早期に特定します。

追跡する主要なメトリクス

トレーニング中に MlFlow を使用して次のメトリクスをモニタリングします。

報酬メトリクス

  • 平均報酬スコア: モデルレスポンスの全体的な品質 (時間の経過とともに増加)

  • 報酬分布: 高、中、低の報酬を受け取るレスポンスの割合

  • トレーニングと検証の報酬: 比較してオーバーフィットを検出する

トレーニングメトリクス:

  • ポリシーの更新: 正常な重みの更新の数

  • ロールアウト完了率: 正常に評価されたサンプルの割合

懸念されるパターン:

  • 報酬のプラトーイング (学習不足を示す)

  • トレーニング報酬の増加中に検証報酬がドロップする (オーバーフィット)

  • 報酬の変動が時間の経過とともに大幅に増加 (不安定)

  • 報酬関数エラーの割合が高い (実装の問題)

トレーニングを停止するタイミング:

  • 目標パフォーマンスメトリクスが達成される

  • 報酬が停滞し、改善しなくなった

  • 検証パフォーマンスが低下した (オーバーフィットが検出された)

  • 最大トレーニング予算に達した

RFT 後の評価

トレーニングが完了したら、ファインチューニングされたモデルを評価してパフォーマンスの向上を評価します。

  • RFT 評価ジョブを実行する: RFT トレーニングのチェックポイントをモデルとして使用する

  • ベースラインと比較する: 同じテストセットでベースモデルとファインチューニングされたモデルの両方を評価する

  • メトリクスを分析する: タスク固有のメトリクス (精度、報酬スコアなど) を確認する

  • 定性的レビューを実施する: サンプル出力の品質を手動で検査する

詳細な評価手順については、「評価」セクションを参照してください。

ファインチューニングされたモデルの使用

チェックポイントへのアクセス:

トレーニングが完了したら、チェックポイントを見つけます。

  1. S3 で output_path に移動します

  2. output.tar.gz をダウンロードおよび抽出します

  3. manifest.json を開きます

  4. checkpoint_s3_bucket 値をコピーします

推論のためのデプロイ:

推論や追加のトレーニングにはチェックポイント S3 パスを使用します。

run:
    model_type: amazon.nova-2-lite-v1:0:256k
    model_name_or_path: "s3://customer-escrow-<account-number>-smtj-<unique-identifier>/<job-name>"

デプロイと推論の手順については、「推論」セクションを参照してください。

制限事項とベストプラクティス

現在の制限事項:

ベータ版の制限事項:

  • RFT 用の新しい RIG グループを作成する必要があります。この制限は GA までに解決されます。

  • インスタンスタイプの要件: P5 インスタンスのみがサポートされています (最小 8x P5.48xlarge)。近日公開: 小規模なインスタンスタイプのサポート (ETA: 2025 年 1 月中旬)。

機能的制限

  • 15 分の Lambda タイムアウト: 報酬関数は 15 分以内に完了する必要があります

  • シングルターンのみ: マルチターン会話はサポートされていません

  • 検証データセット: トレーニング中はサポートされていません。個別の評価ジョブを使用して、トレーニングの進行状況を評価します。

トレーニングに関する考慮事項:

  • 低報酬シナリオ: 肯定的な報酬を受け取る例が 5% 未満の場合、問題が発生する可能性があります。まず SFT を検討してください

  • データ要件: 効果的に学習するには十分な多様性が必要です

  • 計算コスト: 教師ありファインチューニングよりも高価

Nova Forge は、以下のようにこのような制限の一部をなくします。

  • マルチターン会話をサポート

  • 15 分のタイムアウトを超える報酬関数を許可

  • 高度なアルゴリズムと調整オプションを提供

  • フロンティアモデルを構築するように特別に調整された、複雑なエンタープライズユースケース向けに設計

ベストプラクティス:

小規模から始めてスケールする:

  • 最小限のデータセット (100～200 サンプル) と少数のトレーニングエポックから始める

  • スケールアップする前にアプローチを検証する

  • 結果に基づいてデータセットのサイズとトレーニングステップを徐々に増やす

最初に SFT を使用するベースライン:

  • 報酬スコアが一貫して低い場合 (例: 常に 0)、RFT の前に SFT を実行します

  • RFT では、効果的に改善するために合理的なベースラインパフォーマンスが必要です

次のように、効率的な報酬関数を設計します。

  • 数分ではなく秒単位で実行する

  • 外部 API コールを最小化する

  • 効率的なアルゴリズムとデータ構造を使用する

  • 適切なエラー処理を実装する

  • トレーニング前に徹底的にテストする

  • Lambda の並列スケーリング機能を活用する

次のように、トレーニングをアクティブにモニタリングします。

  • 平均報酬スコアを経時的に追跡する

  • サンプル間の報酬分布を監視する

  • トレーニングと検証の報酬を比較する

  • 関連するパターン (プラトー、オーバーフィット、不安定性) を探す

次のように、結果に基づいて反復処理します。

  • 何度か繰り返しても報酬が改善しない場合は、報酬関数の設計を調整する

  • データセットの多様性を高めて、より明確な学習シグナルを提供する

  • 報酬がゼロに近いままの場合は、SFT に切り替えることを検討する

  • さまざまなハイパーパラメータ (学習レート、バッチサイズ) を試す

次のように、データ品質を最適化します。

  • 多様で代表的なサンプルとなるようにする

  • エッジケースと難しいサンプルを含める

  • 報酬関数がすべてのサンプルタイプを正しくスコアリングすることを確認する

  • 報酬関数を混乱させるサンプルを削除または修正する

トラブルシューティング

報酬関数のエラー:

症状: トレーニング中の報酬関数呼び出しのエラー率が高い

問題

症状

解決策

Lambda タイムアウト

15 分後の頻繁なタイムアウト

関数のパフォーマンスを最適化する。複雑な評価には Nova Forge を検討する

同時実行が不十分

Lambda スロットリングエラー

lambda_concurrency_limit を増やすか、クォータの引き上げをリクエストする

戻り形式が無効

トレーニングが形式エラーで失敗する

戻り構造が必須のインターフェイス形式と一致することを確認する

処理されない例外

断続的なエラー

包括的なエラー処理とログ記録を追加する

外部 API の障害

スコアリングの不整合

再試行ロジックとフォールバック戦略を実装する

トレーニングパフォーマンスの低下:

症状: 報酬が改善しないか、低値で停滞する

解決策:

  • 報酬関数の正確性を検証する: 既知の良い例と悪い例でテストする

  • ベースラインパフォーマンスを確認する: ベースモデルを評価します。精度がゼロに近い場合は、最初に SFT を実行します

  • データの多様性を高める: さまざまなシナリオをカバーするより多様な例を追加する

  • ハイパーパラメータを調整する: さまざまな学習レートまたはバッチサイズを試す

  • 報酬シグナルの品質を確認する: 良いレスポンスと悪いレスポンスで報酬が区別されるようにする

オーバーフィット:

症状: トレーニング報酬は増加し、検証報酬は減少する

解決策:

  • トレーニングステップを減らす: トレーニングを早期に停止する

  • データセットサイズを増やす: トレーニング例をさらに追加する

  • 正規化の追加: weight_decay または entropy_coeff を調整する

  • データの多様性を高める: トレーニングセットが完全なディストリビューションを表していることを確認する