# 反復トレーニング
## 概要:
反復トレーニングは、トレーニング、評価、エラーの分析、データ/目標/ハイパーパラメータの調整など、さまざまなトレーニング方法で複数のトレーニングサイクルを通じてモデルを繰り返しファインチューニングするプロセスであり、各ラウンドは前のチェックポイントから開始されます。このアプローチにより、モデル障害モードを体系的にターゲットにし、特定の弱点に対処する厳選された例を取り入れ、時間の経過に伴い変化する要件に適応できます。
**シングルパストレーニングの利点:**
+ **ターゲットを絞った改善**: 評価によって検出された特定の障害パターンに対処します
+ **アダプティブな改良**: ディストリビューションシフトや進化する製品要件に対応します
+ **リスク軽減**: 1 回の長いトレーニングランにコミットするのではなく、改善点を段階的に検証します
+ **データ効率**: モデルのパフォーマンスが低い分野にデータ収集の取り組みを集中させます
+ **カリキュラムトレーニング**: 品質が徐々に高くなるデータを用いた複数回のトレーニング
## 仕組み
### チェックポイントの場所とアクセス
各トレーニングジョブが完了すると、トレーニング設定の `output_path` パラメータで指定された出力場所にマニフェストファイルが生成されます。
**チェックポイントにアクセスするには**
+ S3 で指定した `output_path` に移動します
+ `output.tar.gz` ファイルをダウンロードして抽出します
+ ファイル内の `manifest.json` ファイルを開きます
+ トレーニング済みモデルの S3 URI を含む `checkpoint_s3_bucket` パラメータを見つけます
**manifest.json 構造の例**
```
{
"checkpoint_s3_bucket": "s3://customer-escrow--smtj-//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--smtj-/"
data_s3_path: s3:///.jsonl
replicas: 4
```
## 反復トレーニングを使用する場合
### 最適なユースケース
以下の場合は、反復トレーニングを使用します。
+ **フィードバックループがある** – 実際の障害ケースを収集し、体系的に対処する能力がある
+ **動的な環境である** – ドキュメント、API、サポートトピックが変化し、定期的なモデル更新が必要
+ **堅牢な評価基盤がある** – 確実に改善を評価できる強力なベンチマークと評価フレームワーク (以下の例を参照) がある
+ **ML オペレーション体制がある** – 複数のトレーニングサイクルとバージョン管理を管理するためのリソースがある
**堅牢な評価フレームワークの例**
+ 合格/不合格のしきい値を持つ自動ベンチマークスイート
+ 評価者間信頼性メトリクスを使用した人間による評価プロトコル
+ エッジケースと敵対的入力を含むレッドチームテストのシナリオ
+ 本番稼働への影響を測定するための A/B テストインフラストラクチャ
### 一般的なパターン
**SFT → RFT パイプライン**: 頻繁に使用される反復パターンには以下が含まれます。
+ **SFT を先に実施** – デモンストレーション例を通じて問題を解決する方法をモデルに教える
+ **RFT を次に実施** – 報酬シグナルを使用して、より広範な問題領域のパフォーマンスを最適化する
このシーケンスは、モデルのパフォーマンスが初期段階で低い場合に不可欠です。精度がほぼゼロに近いモデルに対して RFT を実施しても、まず SFT を通じて基本的な問題解決機能を確立しない限り、パフォーマンスは向上しません。
### 反復トレーニングを使用しない場合
以下の場合、反復トレーニングは避けてください。
+ **安定し、明確に定義されたタスク** – 一定の要件を持つ固定データで、既にほぼ上限のパフォーマンスを達成している場合
+ **単純な分類の問題** – シングルパストレーニングで十分な狭いタスクである場合
+ **リソースの制約** — 複数のトレーニングサイクルを管理するための専用の 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:///sft-training-data.jsonl
validation_data_s3_path: s3:///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--smtj-/"
data_s3_path: s3:///rft-training-data.jsonl
reward_lambda_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--smtj-/"
data_s3_path: s3:///evaluation-data.jsonl
```
ターゲットメトリクスが満たされない場合は、調整されたデータまたはハイパーパラメータで反復処理を続行します。
**重要**
トレーニング手法 (LoRA またはフルランク) は、すべてのイテレーションで一貫性を保つ必要があります。
**LoRA** で SFT を使用する場合は、**LoRA** で RFT を使用する必要があります
**フルランク**で SFT を使用する場合は、**フルランク**で RFT を使用する必要があります
LoRA とフルランクの中間パイプラインを切り替えることはできません
**重要**
Amazon 所有の出力 S3 バケットで暗号化に KMS キーを使用する場合は、それ以降のすべてのイテレーションに同じ KMS キーを使用する必要があります。
## 各イテレーションにおける進行状況のモニタリング
ジョブの [MLflow を設定する](nova-model-monitor.md#nova-customization-mlflow-setup)ことで、MLflow を介してメトリクスを追跡できます。
### MLflow アプリを作成する
**Studio UI の使用**: Studio UI を使用してトレーニングジョブを作成すると、デフォルトの MLflow アプリが自動的に作成され、[詳細オプション] でデフォルトで選択されます。
**CLI の使用**: CLI を使用する場合は、MLflow アプリを作成し、トレーニングジョブ API リクエストへの入力として渡す必要があります。
```
mlflow_app_name=""
role_arn=""
bucket_name=""
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 出力レートなど)
+ ドメイン固有の評価データの Perplexity
**RFT の場合**
+ トレーニング中の平均報酬スコア
+ 報酬分布 (高報酬レスポンスの割合)
+ 検証データにおける報酬の傾向 (オーバーフィットに注意)
+ タスク固有の成功率 (コード実行の合格率、数学の問題の精度など)
**全般**
+ イテレーション間のベンチマークパフォーマンス差分
+ 代表的なサンプルに対する人間の評価スコア
+ 本番メトリクス (反復的にデプロイする場合)
### 停止するタイミングの判断
以下の場合に反復処理を停止します。
+ **パフォーマンスが頭打ちになった場合** - 追加のトレーニングを行っても、ターゲットメトリクスに有意な改善が見られない
+ **手法の切り替えが有効な場合** - ある手法でパフォーマンスが停滞した場合は、パフォーマンスの上限を突破するために別の手法に切り替えてみてください (例: 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--smtj-/"
```
## コストに関する考慮事項
### チェックポイントストレージ
+ **場所** – エスクローバケットに保存されているチェックポイントには、AWS アカウントに請求される標準の S3 ストレージ料金が発生します
+ **保持** — 明示的に削除されない限り、チェックポイントは無期限に保持されます
+ **管理** – ライフサイクルポリシーを実装して、不要になった古いチェックポイントをアーカイブまたは削除します
**コスト最適化のヒント**
+ 新しいイテレーションを検証した後に中間チェックポイントを削除します
+ チェックポイントを S3 Glacier にアーカイブして、長期保存を低コストで実現します
+ コンプライアンスと実験のニーズに基づいて保持ポリシーを設定します
## 制限事項
### モデルファミリーの整合性
反復トレーニングを行う場合は、すべてのイテレーションで**同じモデルタイプ**を使用する必要があります。
**初期トレーニング**
```
run:
model_type: amazon.nova-2-lite-v1:0:256k
model_name_or_path: "nova-lite-2/prod"
```
**以降のイテレーションでは、同じ model\$1type を使用する必要があります**
```
run:
model_type: amazon.nova-2-lite-v1:0:256k # Must match original
model_name_or_path: "s3://customer-escrow--smtj-/"
```
### トレーニング手法の一貫性
トレーニング手法はイテレーション間で一貫性を保つ必要があります。
+ **LoRA トレーニング済みモデル**は、LoRA を使用してのみ反復トレーニングできます
+ **フルランクトレーニング済みモデル**は、フルランクでのみ反復トレーニングできます
**反復トレーニングにおける LoRA アダプターの仕組み**
+ LoRA トレーニングのイテレーションごとに新しいアダプターの重みが生成されます
+ 新しいアダプターは、以前のアダプターを (スタックではない) 置き換えます
+ ベースモデルはフリーズしたままで、アダプターのみが更新されます
### 技術互換性マトリックス
| 初期トレーニング | 反復可能な手法 |
| --- | --- |
| SFT (フルランク) | SFT (フルランク)、RFT (フルランク) |
| SFT (LoRA) | SFT (LoRA)、RFT (LoRA) |
| RFT (フルランク) | RFT (フルランク) |
| RFT (LoRA) | RFT (LoRA) |
**ジョブを開始する前に互換性を検証する**
+ 以前のトレーニングレシピを確認して、モデルタイプとトレーニング手法 (LoRA とフルランク) を特定します
+ 新しいレシピがモデルタイプと手法の両方と一致することを確認します
+ manifest.json を確認して、チェックポイントパスが正しいことを確認します
## トラブルシューティング
### エラー:「互換性のないモデルトレーニング手法が検出されました」
**原因**: トレーニング手法 (LoRA とフルランク) がチェックポイントの手法と一致しません。
**解決策**: レシピが元のモデルと同じトレーニング手法を使用していることを確認します。
+ チェックポイントが LoRA でトレーニングされている場合は、新しいレシピで LoRA を使用します
+ チェックポイントがフルランクでトレーニングされている場合は、新しいレシピでフルランクを使用します
### エラー:「model\$1name\$1or\$1path から抽出されたジョブのベースモデルが model\$1type と一致しません」
**原因**: `model_type` で指定されたモデルタイプがチェックポイントの実際のモデルと一致しません。
**解決策**: 以下を確認します。
+ レシピの `model_type` が元のモデルタイプと一致している
+ `model_name_or_path` のチェックポイント S3 パスが正しい
+ 正しい manifest.json ファイルからのパスを使用している
**正しい設定の例**
```
run:
model_type: amazon.nova-2-lite-v1:0:256k # Must match checkpoint's model
model_name_or_path: "s3://customer-escrow--smtj-/"
```
### エラー:「モデル設定が見つかりません」
**原因**: `model_name_or_path` の S3 パスが無効またはアクセスできません。
**解決策:**
+ S3 パスが manifest.json ファイルから正しくコピーされていることを確認します
+ IAM ロールにエスクローバケットへのアクセス許可があることを確認します
+ 前のトレーニングジョブが正常に完了したことを確認します
+ パスにタイプミスがないかチェックします
### イテレーション後のパフォーマンスリグレッション
**症状**: 評価メトリクスが新しいトレーニングのイテレーション後に低下する。
**解決策:**
+ **ロールバック** — 前のチェックポイントをベースモデルとして使用します
+ **分析** — 失敗したイテレーションのトレーニングログとデータ品質を確認します
+ **調整** — ハイパーパラメータの変更 (学習率を下げる)、データ品質の向上、またはトレーニングエポックの削減を行います
+ **再試行** — 調整を加えて新しいイテレーションを開始します