反復トレーニング - Amazon SageMaker AI
概要:仕組み反復トレーニングを使用するタイミングワークフローの例: SFT → RFT反復間の進行状況のモニタリングベストプラクティスコストに関する考慮事項制限事項トラブルシューティング

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

反復トレーニング

概要:

反復トレーニングは、トレーニング、評価、エラーの分析、data/objectives/hyperparametersの調整など、さまざまなトレーニング方法で複数のトレーニングサイクルを通じてモデルを繰り返し微調整するプロセスであり、各ラウンドは前のチェックポイントから開始されます。このアプローチにより、モデル障害モードを体系的にターゲットにし、特定の弱点に対処する厳選された例を取り入れ、時間の経過とともに変化する要件に適応できます。

シングルパストレーニングの利点:

  • ターゲットを絞った改善: 評価によって検出された特定の障害パターンに対処する

  • アダプティブな改良: 分散シフトや進化する製品要件への対応

  • リスク軽減: 1 回の長いトレーニングランにコミットするのではなく、改善点を段階的に検証する

  • データ効率: モデルのパフォーマンスが低い分野にデータ収集の取り組みを集中させる

  • カリキュラムトレーニング: 質の高いデータがますます増える複数のトレーニングラウンド

仕組み

チェックポイントの場所とアクセス

各トレーニングジョブが完了すると、トレーニング設定の output_pathパラメータで指定された出力場所にマニフェストファイルが生成されます。

チェックポイントにアクセスするには

  • S3 output_pathで指定した に移動する

  • output.tar.gz ファイルをダウンロードして抽出する

  • 内で manifest.json ファイルを開く

  • トレーニング済みモデルの S3 URI を含む checkpoint_s3_bucketパラメータを見つけます。

manifest.json 構造の例

{  
  "checkpoint_s3_bucket": "s3://customer-escrow-<account-number>-smtj-<unique-identifier>/<job-name>/stepID",  
  ...  
}

エスクローバケットについて

Amazon Nova の重みは独自のものであるため、トレーニング済みのモデルチェックポイントは、アカウントにコピーされるのではなくAWS、管理対象アカウント内のエスクロー S3 バケットに保存されます。これらのエスクローバケット:

  • カスタマイズされたモデルの重みを安全に格納する

  • 他の AWSサービス (推論、評価、およびその後のトレーニングジョブ) で参照可能

  • IAM アクセス許可を介してのみAWSアカウントからアクセス可能

  • アカウントで標準の S3 ストレージ料金が発生する (「コストに関する考慮事項」を参照)

次のトレーニング実行model_name_or_pathでエスクローバケットパスを として使用して、反復トレーニングを続行できます。

反復トレーニングにチェックポイントを使用する

前のチェックポイントをベースモデルとして使用するように次のトレーニングジョブを設定します。

run:  
  name: "my-iterative-training-job"  
  model_type: amazon.nova-2-lite-v1:0:256k  
  model_name_or_path: "s3://customer-escrow-<account-number>-smtj-<unique-identifier>/<previous-job-name>"  
  data_s3_path: s3://<bucket>/<data-file>.jsonl  
  replicas: 4

反復トレーニングを使用するタイミング

理想的なユースケース

以下の場合は、反復トレーニングを使用します。

  • フィードバックループ – 実際の障害ケースを収集し、体系的に対処する能力

  • 動的環境 – 定期的なモデル更新を必要とするドキュメント、APIs、またはサポートトピックの進化

  • 堅牢な評価 – 強力なベンチマークと評価フレームワーク (以下の例を参照) で、確実に改善を評価します。

  • ML オペレーション機能 – 複数のトレーニングサイクルとバージョン管理を管理するためのリソース

堅牢な評価フレームワークの例

  • 合格/不合格のしきい値を持つ自動ベンチマークスイート

  • 評価者間の信頼性メトリクスを使用したヒューマン評価プロトコル

  • エッジケースと敵対的入力をカバーする赤チームテストシナリオ

  • 本番稼働への影響を測定するための A/B テストインフラストラクチャ

一般的なパターン

SFT → RFT パイプライン: 頻繁に使用される反復パターンには以下が含まれます。

  • SFT ファースト – デモンストレーション例を通じて問題を解決する方法をモデルに教える

  • RFT 秒 – 報酬シグナルを使用して、より広範な問題領域のパフォーマンスを最適化する

このシーケンスは、最初にモデルのパフォーマンスが低い場合に不可欠です。ゼロに近い精度モデルでは、最初に SFT を通じて基本的な問題解決機能を確立しない限り、RFT のパフォーマンスは向上しません。

反復トレーニングを使用しない場合

以下の反復トレーニングは避けてください。

  • 安定した明確に定義されたタスク – 一定の要件を持つ固定データで、すでにほぼ上限に近いパフォーマンスを達成

  • 単純な分類の問題 – シングルパストレーニングで十分である狭いタスク

  • リソースの制約 — 複数のトレーニングサイクルを管理するための専用の ML オペレーション機能がない

  • 限界利益 – オーバーヘッドが最小限のパフォーマンス向上を正当化しない場合

ワークフローの例: SFT → RFT

この例では、推論モデルの一般的な反復トレーニングパターンを示しています。

ステップ 1: 初期 SFT トレーニング

データセットを使用して SFT トレーニングジョブを設定して起動します。

run:  
  name: "initial-sft-training"  
  model_type: amazon.nova-2-lite-v1:0:256k  
  model_name_or_path: "nova-lite-2/prod"  
  data_s3_path: s3://<bucket>/sft-training-data.jsonl  
  validation_data_s3_path: s3://<bucket>/sft-validation-data.jsonl

根拠: SFT は、モデル出力を目的の形式と音声に形成し、基本的な機能を確立する追加のデモンストレーションを提供します。

トレーニング完了後

  • トレーニングジョブでoutput_path設定された を書き留めます。

  • その場所output.tar.gzからダウンロードする

  • 抽出して見つける manifest.json

  • checkpoint_s3_bucket 値をコピーする

ステップ 2: SFT チェックポイントでの RFT トレーニング

SFT チェックポイントを使用して新しい RFT トレーニングジョブを作成します。

run:  
  name: "rft-on-sft-checkpoint"  
  model_type: amazon.nova-2-lite-v1:0:256k  
  model_name_or_path: "s3://customer-escrow-<account-number>-smtj-<unique-identifier>/<initial-sft-training>"  
  data_s3_path: s3://<bucket>/rft-training-data.jsonl  
  reward_lambda_arn: <your-reward-function-arn>

根拠: RFT トレーニングは SFT 基盤に基づいて構築されるため、モデルは報酬関数によって最適化されたより複雑な推論パターンを開発できます。

ステップ 3: 評価と反復

RFT チェックポイントで評価を実行してパフォーマンスを評価します。

run:  
  name: "evaluate-rft-checkpoint"  
  model_type: amazon.nova-2-lite-v1:0:256k  
  model_name_or_path: "s3://customer-escrow-<account-number>-smtj-<unique-identifier>/<rft-on-sft-checkpoint>"  
  data_s3_path: s3://<bucket>/evaluation-data.jsonl

ターゲットメトリクスが満たされない場合は、調整されたデータまたはハイパーパラメータで反復処理を続行します。

重要

⚠️ 重要: トレーニング手法 (LoRA とフルランク) は、すべての反復で一貫性を保つ必要があります。

  • LoRA で SFT を使用する場合は、LoRA で RFT を使用する必要があります。

  • フルランクで SFT を使用する場合は、フルランクで RFT を使用する必要があります

  • LoRA とフルランクの中間パイプラインを切り替えることはできません

反復間の進行状況のモニタリング

メトリクスは MLFlow 経由で追跡できます。

MLflow アプリを作成する

Studio UI の使用: Studio UI を使用してトレーニングジョブを作成すると、デフォルトの MLflow アプリが自動的に作成され、アドバンストオプションでデフォルトで選択されます。

CLI の使用: CLI を使用する場合は、MLflow アプリを作成し、トレーニングジョブ API リクエストへの入力として渡す必要があります。

mlflow_app_name="<enter your MLflow app name>"  
role_arn="<enter your role ARN>"   
bucket_name="<enter your bucket name>"   
region="<enter your region>"  
  
mlflow_app_arn=$(aws sagemaker create-mlflow-app \  
  --name $mlflow_app_name \  
  --artifact-store-uri "s3://$bucket_name" \  
  --role-arn $role_arn \  
  --region $region)

MLflow アプリにアクセスする

CLI の使用: MLflow アプリ UI にアクセスするための署名付き URL を作成します。

aws sagemaker create-presigned-mlflow-app-url \  
  --arn $mlflow_app_arn \  
  --region $region \  
  --output text

Studio UI の使用: Studio UI は、MLflow に保存されている主要なメトリクスを表示し、MLflow アプリ UI へのリンクを提供します。

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

これらのメトリクスを反復的にモニタリングして改善を評価し、ジョブの進行状況を追跡します。

SFT の場合

  • トレーニング損失曲線

  • 消費されたサンプルの数とサンプルの処理時間

  • ホールドアウトテストセットのパフォーマンス精度

  • 形式コンプライアンス (有効な JSON 出力レートなど)

  • ドメイン固有の評価データの多重度

RFT の場合

  • トレーニングの平均報酬スコア

  • 報酬分布 (高報酬レスポンスの割合)

  • 検証報酬の傾向 (オーバーフィットに注意)

  • タスク固有の成功率 (コード実行の合格率、数学問題の精度など)

全般

  • 反復間のパフォーマンス差分をベンチマークする

  • 代表的なサンプルの人間の評価スコア

  • 本番稼働用メトリクス (反復デプロイの場合)

停止するタイミングの決定

次の場合に反復を停止します。

  • パフォーマンスの台頭 — 追加のトレーニングによってターゲットメトリクスが意味的に改善されなくなりました

  • テクニック切り替えが役立つ – 1 つのテクニックが停滞した場合は、切り替え (SFT → RFT → SFT など) してパフォーマンスの上限を突破してみてください。

  • 達成されたターゲットメトリクス — 成功基準が満たされている

  • 検出された回帰 — 新しい反復によりパフォーマンスが低下します (以下のロールバック手順を参照)

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

ベストプラクティス

小規模から始めて徐々にスケールする

最小限のデータセットと単一のトレーニングエポックから始めて、スケールアップする前にアプローチを検証します。これにより信頼が構築され、問題を早期に特定するのに役立ちます。

明確な成功メトリクスを確立する

開始する前に、定量的および定性的な指標を定義します。

ユースケース別の成功メトリクスの例

  • 質問への回答 – 完全一致精度、F1 スコア、人間の好みの評価

  • コード生成 — ユニットテストの合格率、コンパイルの成功、実行時間

  • 推論タスク – ステップの精度、最終回答の正確性、報酬スコア

  • コンテンツ生成 – コヒーレンススコア、事実精度、スタイル準拠

自動評価の実装

各ラウンド後にパフォーマンスを追跡するように自動評価パイプラインを設定し、迅速な反復と目標比較を可能にします。

厳格なバージョン管理を維持する

各イテレーションのドキュメント:

  • データセットのバージョンと変更

  • モデルチェックポイントの場所

  • ハイパーパラメータの変更

  • パフォーマンスメトリクスと差分

  • 定性的観測値

これにより、組織の知識が構築され、デバッグが可能になります。

数量よりもデータ品質に焦点を当てる

以前のラウンドの失敗ケースを分析し、単にデータセットサイズを増やすのではなく、ターゲットを絞った高品質の例を追加します。

反復予算を計画する

一般的な範囲として 3～5 回の反復を計画します。

  • 1～2 回の反復 — 多くの場合、簡単な改善や最終ポリッシングに十分です。

  • 3～5 回の反復 – 複数の改良サイクルを必要とする複雑なタスクに適しています

  • 5 回以上の反復 — リターンの低下や異なるアプローチの必要性を示している可能性があります

計算予算とパフォーマンス改善率に基づいて調整します。

ロールバック機能を実装する

反復によってリグレッションが発生する場合:

  • 回帰を特定する – チェックポイント間で評価メトリクスを比較する

  • 前のチェックポイントに戻る – 前のチェックポイントの S3 パスを model_name_or_path

  • トレーニングアプローチの調整 – 再試行する前にデータ、ハイパーパラメータ、または手法を変更する

  • 失敗を文書化する – 繰り返しを避けるために回帰の原因を記録します。

ロールバックの例

run:  
  name: "rollback-to-iteration-2"  
  model_type: amazon.nova-2-lite-v1:0:256k  
  # Use iteration 2 checkpoint instead of failed iteration 3  
  model_name_or_path: "s3://customer-escrow-<account-number>-smtj-<unique-identifier>/<iteration-2-job-name>"

コストに関する考慮事項

チェックポイントストレージ

  • 場所 – エスクローバケットに保存されているチェックポイントには、AWSアカウントに請求される標準の S3 ストレージ料金が発生します。

  • 保持 — 明示的に削除されない限り、チェックポイントは無期限に保持されます

  • 管理 – ライフサイクルポリシーを実装して、不要になった古いチェックポイントをアーカイブまたは削除します。

コスト最適化のヒント

  • 新しい反復を検証した後に中間チェックポイントを削除する

  • チェックポイントを S3 Glacier にアーカイブして、長期保存を低コストで実現

  • コンプライアンスと実験のニーズに基づいて保持ポリシーを設定する

制限事項

モデルファミリーの整合性

反復トレーニングを行う場合は、すべての反復で同じモデルタイプを使用する必要があります。

初期トレーニング

run:  
  model_type: amazon.nova-2-lite-v1:0:256k  
  model_name_or_path: "nova-lite-2/prod"

以降の反復では、同じ model_type を使用する必要があります

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

トレーニング手法の一貫性

トレーニング手法は反復間で一貫性を保つ必要があります。

  • LoRA トレーニング済みモデルは、LoRA を使用してのみ反復トレーニングできます

  • Full-Rank-trainedモデルは Full-Rank でのみ反復トレーニングできます

LoRA アダプターが反復トレーニングでどのように機能するか

  • LoRA トレーニングの反復ごとに新しいアダプターの重みが生成されます

  • 新しいアダプターは、以前のアダプターを (スタックではなく) 置き換えます。

  • ベースモデルはフリーズしたままで、アダプターのみが更新されます。

技術互換性マトリックス

初期トレーニング で反復可能
SFT (フルランク) SFT (Full-Rank)、RFT (Full-Rank)
SFT (LoRA) SFT (LoRA)、RFT (LoRA)
RFT (フルランク) RFT (フルランク)
RFT (LoRA) RFT (LoRA)

ジョブを開始する前に互換性を検証する

  • 以前のトレーニングレシピを確認して、モデルタイプとトレーニング手法 (LoRA とフルランク) を特定します。

  • 新しいレシピがモデルタイプと手法の両方と一致することを確認します。

  • manifest.json を確認して、チェックポイントパスが正しいことを確認します。

トラブルシューティング

エラー：「互換性のないモデルトレーニング手法が検出されました」

原因: トレーニング手法 (LoRA とフルランク) がチェックポイントの手法と一致しません。

解決策: レシピが元のモデルと同じトレーニング手法を使用していることを確認します。

  • チェックポイントが LoRA でトレーニングされている場合は、新しいレシピで LoRA を使用します。

  • チェックポイントがフルランクでトレーニングされている場合は、新しいレシピでフルランクを使用します。

エラー：「model_name_or_path does not match model_type」

原因: で指定されたモデルタイプmodel_typeがチェックポイントの実際のモデルと一致しません。

解決策: 以下を確認します。

  • レシピmodel_typeの が元のモデルタイプと一致する

  • のチェックポイント S3 パスmodel_name_or_pathが正しい

  • 正しい manifest.json ファイルからのパスを使用している

正しい設定の例

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

エラー: "モデル設定が見つかりません"

原因: の S3 パスmodel_name_or_pathが無効またはアクセスできません。

解決策:

  • S3 パスが manifest.json ファイルから正しくコピーされていることを確認します。

  • IAM ロールにエスクローバケットへのアクセス許可があることを確認します。

  • 前のトレーニングジョブが正常に完了したことを確認する

  • パスでタイプミスをチェックする

反復後のパフォーマンス回帰

症状: 評価メトリクスは、新しいトレーニングの反復後に低下します。

解決策:

  • ロールバック – 前のチェックポイントをベースモデルとして使用します。

  • 分析 — 失敗した反復のトレーニングログとデータ品質を確認する

  • 調整 — ハイパーパラメータの変更 (学習率の低下）、データ品質の向上、またはトレーニングエポックの削減

  • 再試行 — 調整を含む新しいイテレーションを起動する