翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
Amazon Nova モデルによるファインチューニング (RFT) の強化
概要:
RFT とは
強化ファインチューニング (RFT) は、正確な正解ではなく、モデルのパフォーマンスを示す測定可能なスコアや報酬などのフィードバックシグナルをトレーニングすることで、モデルのパフォーマンスを向上させます。入出力ペアから学習する教師ありファインチューニングとは異なり、RFT は報酬関数を使用してモデルレスポンスを評価し、モデルを繰り返し最適化してこれらの報酬を最大化します。このアプローチは、正確な出力を定義するのが困難な場合に優れていますが、応答品質を確実に測定できます。
RFT を使用するタイミング
明確で測定可能な成功基準を定義できるが、トレーニングのための正確な出力の提供に苦労する場合は、RFT を使用します。これは、以下に最適です。
-
品質が主観的または多面的であるタスク (創造的な記述、コードの最適化、複雑な推論)
-
複数の有効なソリューションがあり、一部のソリューションが他のソリューションよりも明らかに優れているシナリオ
-
反復的な改善、パーソナライゼーション、または複雑なビジネスルールの遵守を必要とするアプリケーション
-
高品質のラベル付き例の収集が高価または実用的でないケース
ベストプラクティス
RFT は、出力品質を客観的に測定できるが、最適な応答を事前に定義することが難しいドメインに優れています。
-
数学的な問題解決とコード生成
-
科学的推論と構造化データ分析
-
step-by-stepの推論または複数ターンの問題解決を必要とするタスク
-
複数の目標 (精度、効率、スタイル) のバランスを取るアプリケーション
-
実行結果またはパフォーマンスメトリクスを通じてプログラムで成功を検証できるシナリオ
サポートされているモデル
Nova Lite 2.0
データ形式の概要
RFT トレーニングデータは、OpenAI 強化ファインチューニング形式
-
systemおよびuserロールを使用した会話ターンのmessages配列 -
報酬計算の期待される出力または評価基準を含む
reference_answerフィールド
現在の制限事項
-
テキストのみ
データ形式の例
各例は JSONL ファイルの 1 行上にあり、1 行に 1 つの JSON オブジェクトが必要です。
reference_answer フィールドには、報酬関数がモデルのレスポンスをスコアリングするために使用する期待される出力または評価基準が含まれます。構造化された出力に限定されず、報酬関数が品質を評価するのに役立つ任意の形式を含めることができます。
データセットサイズの推奨事項
開始点
-
最小 100 個のトレーニング例
-
最小 100 の評価例
評価ファーストのアプローチ
大規模な RFT トレーニングに投資する前に、モデルのベースラインパフォーマンスを評価します。
-
高パフォーマンス (>95% の報酬) – RFT は不要な場合があります。モデルのパフォーマンスは既に良好です。
-
パフォーマンスが非常に低い (0% の報酬) — まず SFT に切り替えて基本的な機能を確立する
-
中程度のパフォーマンス — RFT が適切である可能性が高い
小さいデータセットから始めると、次のことが可能になります。
-
報酬関数にバグがないことを検証する
-
RFT がユースケースに適したアプローチであることを確認する
-
問題を早期に特定して修正する
-
スケールアップする前にワークフローをテストする
検証が完了すると、より大きなデータセットに拡張してパフォーマンスをさらに向上させることができます。
効果的なトレーニングデータの特徴
明確性と一貫性
優れた RFT の例には、さまざまなモデル出力にわたって正確な報酬計算を可能にする明確であいまいな入力データが必要です。以下を含むデータのノイズを避けます。
-
フォーマットの不整合
-
矛盾するラベルまたは指示
-
あいまいなプロンプト
-
参照回答の競合
あいまいさがあると、トレーニングプロセスが誤解され、モデルが意図しない動作を学習します。
多様性
データセットは、堅牢な実際のパフォーマンスを確保するために、本番稼働用ユースケースの完全な多様性をキャプチャする必要があります。インクルード:
-
さまざまな入力形式とエッジケース
-
ログとユーザー分析から実際の本番稼働用使用パターンをマッピングする
-
ユーザータイプ、地理的リージョン、季節的なバリエーションにわたるサンプル
-
単純な問題から複雑な問題まで、難易度レベルを含める
報酬関数に関する考慮事項
効率的なトレーニングのために報酬関数を設計します。
-
数秒以内 (数分ではない) に実行する
-
Lambda と効果的に並列化する
-
一貫性のある信頼できるスコアを返す
-
さまざまなタイプのモデル出力を適切に処理する
高速でスケーラブルな報酬関数により、迅速な反復と費用対効果の高い実験が可能になります。
その他のプロパティ
RFT データ形式は、コアスキーマ要件 (messages および ) を超えるカスタムフィールドをサポートしますreference_answer。この柔軟性により、報酬関数が適切な評価に必要な追加データを追加できます。
注記
レシピでこれを設定する必要はありません。データ形式は本質的に追加のフィールドをサポートします。トレーニングデータ JSON に含めるだけで、 metadataフィールドの報酬関数に渡されます。
一般的な追加プロパティ
メタデータフィールドの例:
-
task_id– 追跡用の一意の識別子 -
difficulty_level– 問題の複雑さインジケータ -
domain– サブジェクトエリアまたはカテゴリ -
expected_reasoning_steps– ソリューションのステップ数
追加プロパティの例
{ "messages": [ { "role": "system", "content": "You are a math tutor" }, { "role": "user", "content": "Solve: 2x + 5 = 13" } ], "reference_answer": { "solution": "x = 4", "steps": ["2x = 13 - 5", "2x = 8", "x = 4"] }, "task_id": "algebra_001", "difficulty_level": "easy", "domain": "algebra", "expected_reasoning_steps": 3 }
これらの追加フィールドは評価中に報酬関数に渡されるため、特定のユースケースに合わせた高度なスコアリングロジックが可能になります。
トレーニング設定
サンプルレシピ
# Note: # This recipe can run on p5.48xlarge and p5en.48xlarge instance types. run: name: "my-rft-run" # Unique run name (appears in logs/artifacts). model_type: amazon.nova-2-lite-v1:0:256k model_name_or_path: nova-lite-2/prod data_s3_path: s3://<bucket>/<data file> # Training dataset in JSONL; replicas: 4 reward_lambda_arn: "" ## SMTJ GRPO Training specific configs training_config: max_length: 8192 # Context window (tokens) for inputs+prompt; global_batch_size: 16 # Total samples per optimizer step across all replicas (16/32/64/128/256). reasoning_effort: high # Enables reasoning mode high / low / or null for non-reasoning rollout: # How responses are generated for GRPO/advantage calc. advantage_strategy: number_generation: 2 # N samples per prompt to estimate advantages (variance vs cost). generator: max_new_tokens: 6000 # Cap on tokens generated per sample set_random_seed: true # Seed generation for reproducibility across runs. temperature: 1 # Softmax temperature; top_k: 1 # Sample only from top-K logits rewards: preset_reward_function: null # Usage of reward functions built into Verl [exact_match, code_executions, math_answers] api_endpoint: lambda_arn: "" lambda_concurrency_limit: 12 # Max concurrent Lambda invocations (throughput vs. throttling). trainer: max_steps: 2 # Steps to train for. One Step = global_batch_size save_steps: 5 test_steps: 1 save_top_k: 5 # RL parameters ent_coeff: 0.0 # A bonus added to the policy loss that rewards higher-output entropy. kl_loss_coef: 0.001 # Weight on the KL penalty between the actor (trainable policy) and a frozen reference model optim_config: # Optimizer settings lr: 7e-7 # Learning rate weight_decay: 0.0 # L2 regularization strength (0.0–1.0) adam_beta1: 0.9 adam_beta2: 0.95 peft: # Parameter-efficient fine-tuning (LoRA) peft_scheme: "lora" # Enable LoRA for PEFT lora_tuning: alpha: 32 lora_plus_lr_ratio: 64.0 # LoRA+ learning rate scaling factor (0.0–100.0)
LLM を審査員として使用する RFT トレーニング
概要:
大規模言語モデル (LLMs) は、強化ファインチューニング (RFT) ワークフローの審査員としてますます使用され、モデルの最適化をガイドする自動報酬シグナルを提供します。このアプローチでは、LLM は、正確性、品質、スタイルの準拠性、セマンティック同等性など、指定された基準に照らしてモデル出力を評価し、強化学習プロセスを促進する報酬を割り当てます。
これは、さまざまな表現 (「1/3」、「0.333」、「1/3」など) が意味的に同等かどうかを判断する、一貫性や関連性などの微妙な性質を評価するなど、従来の報酬関数をプログラムで定義することが難しいタスクに特に役立ちます。LLM ベースの審査員を報酬関数として使用することで、広範な人間の注釈を必要とせずに RFT を複雑なドメインにスケールできるため、従来のアラインメントの問題を超えたさまざまなユースケースでモデルの迅速な反復と継続的な改善が可能になります。
推論モードの選択
使用可能なモード
-
none – 理由なし (Reasoning_effort フィールドを省略)
-
低 – 推論オーバーヘッドを最小限に抑える
-
high – 最大推論機能 (Reasoning_effort が指定されている場合のデフォルト)
注記
RFT にメディアオプションはありません。reasoning_effort フィールドが設定にない場合、推論は無効になります。推論が有効になっている場合は、拡張推論出力に対応するように max_new_tokensを 32768 に設定する必要があります。
各モードを使用するタイミング
次の場合は、高い推論を使用します。
-
複雑な分析タスク
-
数学的な問題解決
-
複数ステップの論理的減算
-
step-by-stepの思考が価値を追加するタスク
以下には、なし (Reasoning_effort を省略) または低い推論を使用します。
-
単純な事実クエリ
-
直接分類
-
速度とコストの最適化
-
簡単な質問への回答
コストとパフォーマンスのトレードオフ
推論モードの増加:
-
トレーニングの時間とコスト
-
推論のレイテンシーとコスト
-
複雑な推論タスクのモデル機能
LLM 審査員の検証
LLM-as-a-judge を本番環境にデプロイする前に、審査員モデルの評価が人間の判断と一致していることを確認します。これには以下が含まれます。
-
タスクの代表的なサンプルに関する LLM 判事と人間の評価者間の契約率の測定
-
LLM の人間との契約が人間間の契約レート以上であることを確認する
-
判事モデルの潜在的なバイアスを特定する
-
報酬シグナルがモデルを意図した方向に導くという信頼の構築
この検証ステップは、自動評価プロセスが本番品質基準を満たすモデルを生成するのに役立ちます。
LLM judge の Lambda 設定
LLM を審査員として使用することは、検証可能な報酬による強化学習 (RLVR) に Lambda 関数を使用する拡張機能です。Lambda 関数内で、Amazon Bedrock でホストされているいずれかのモデルを呼び出します。
重要な設定要件:
| 設定 | 要件 | Details |
|---|---|---|
| Amazon Bedrock スループット | 十分なクォータ | 使用する Amazon Bedrock モデルのスループットクォータがトレーニングワークロードに十分であることを確認します。 |
| Lambda タイムアウト | 延長タイムアウト | Lambda 関数のタイムアウトを最大 15 分に設定します。デフォルト設定は 3 秒で、Amazon Bedrock モデルレスポンスでは不十分です |
| Lambda の同時実行 | 同時実行数の増加 | Lambda はトレーニング中に並行して呼び出されます。同時実行数を増やして利用可能なスループットを最大化する |
| レシピ設定 | Lambda 設定の一致 | 同時実行制限はレシピで設定する必要があります |
ジョブの作成と実行
トレーニングジョブの開始
SageMaker AI トレーニングジョブノートブックテンプレートを使用します。 https://docs.aws.amazon.com/sagemaker/latest/dg/nova-fine-tuning-training-job.html#nova-model-training-jobs-notebook
インスタンスの要件
コンテナは、Full-Rank トレーニングと LoRA トレーニングの両方をサポートしています。
-
LoRA トレーニング – 2/4/6/8 × p5.48xlarge または p5en.48xlarge インスタンス
-
フルランクトレーニング – 2/4/6/8 × p5.48xlarge インスタンス (必須)
トレーニングのモニタリング
トレーニングログには、各ステップの包括的なメトリクスが含まれています。主要なメトリクスカテゴリ:
報酬メトリクス
-
critic/rewards/mean、critic/rewards/max、critic/rewards/min– 報酬ディストリビューション -
val-score/rewards/mean@1– 検証報酬
モデルの動作
-
actor/entropy– ポリシーのバリエーション (高 = 探索的)
トレーニングの状態
-
actor/pg_loss– ポリシーグラデーション損失 -
actor/pg_clipfrac– クリップされた更新の頻度 -
actor/grad_norm– グラデーションの大きさ
レスポンスの特性
-
prompt_length/mean、prompt_length/max、prompt_length/min– 入力トークン統計 -
response_length/mean、response_length/max、response_length/min– 出力トークン統計 -
response/aborted_ratio– 不完全な生成レート (0 = すべて完了)
パフォーマンス
-
perf/throughput– トレーニングスループット -
perf/time_per_step– トレーニングステップあたりの時間 -
timing_per_token_ms/*– トークンごとの処理時間
リソースの使用状況
-
perf/max_memory_allocated_gb、perf/max_memory_reserved_gb— GPU メモリ -
perf/cpu_memory_used_gb— CPU メモリ
微調整されたモデルの使用
トレーニングが完了すると、最終的なモデルチェックポイントが指定された出力場所に保存されます。チェックポイントパスは次の場所で使用できます。
-
トレーニングログ
-
manifest.json出力 Amazon S3 の場所の ファイル (ノートブックoutput_s3_uriで で定義)
制限とベストプラクティス
制限事項
-
Lambda タイムアウト – 報酬関数は 15 分以内に完了する必要があります (暴走プロセスを防ぎ、コストを管理します)
-
シングルターンのみ — マルチターン会話はサポートされていません
-
データ要件 – 十分な多様性が必要で、報酬がまばらである (<5% 肯定的な例)
-
計算コスト – 教師ありファインチューニングよりも高価
-
マルチモーダルデータなし – テキストデータ型のみがサポートされています
ベストプラクティス
小さく始める
-
100~200 の例から始める
-
報酬関数の正確性を検証する
-
結果に基づいて徐々にスケールする
トレーニング前評価
-
RFT の前にベースラインモデルのパフォーマンスをテストする
-
報酬が一貫して 0% の場合、まず SFT を使用して基本的な機能を確立します。
-
報酬が >95% の場合、RFT は不要である可能性があります
トレーニングのモニタリング
-
平均報酬スコアと分布を追跡する
-
オーバーフィットに注意する (トレーニング報酬は増加し、検証報酬は減少する)
-
関連するパターンを探します。
-
報酬が 0.15 を下回る
-
時間の経過に伴う報酬分散の増加
-
検証パフォーマンスの低下
-
報酬関数の最適化
-
数秒以内 (数分ではない) に実行する
-
外部 API コールの最小化
-
効率的なアルゴリズムを使用する
-
適切なエラー処理を実装する
-
Lambda の並列スケーリングを活用する
反復戦略
報酬が改善されない場合:
-
報酬関数の設計を調整する
-
データセットの多様性を高める
-
その他の代表的な例を追加する
-
報酬シグナルが明確で一貫性があることを確認する
高度な機能: Nova Forge
標準の RFT 制限を超える高度な機能を必要とするユーザー向けに、Nova Forge は有料サブスクリプションサービスとして利用できます。
-
マルチターン会話のサポート
-
>15 分の実行時間で関数に報酬を与える
-
追加のアルゴリズムと調整オプション
-
カスタムトレーニングレシピの変更
-
State-of-the-art手法
Nova Forge は SageMaker AI HyperPod 上で動作し、エンタープライズのお客様が独自のフロンティアモデルを構築できるように設計されています。
便利なコマンドとヒント
オブザーバビリティスクリプト
使用可能なスクリプトは次のとおりです。
-
トレーニングジョブのステータス更新の E メール通知の有効化
-
ジョブ設定に基づくトレーニング時間の見積もりの取得
-
進行中のジョブのトレーニングにかかると予想される時間の近似値を取得する
インストール
注記
以下のスクリプトを使用する前に、必ず AWS 認証情報を更新してください。
pip install boto3 git clone https://github.com/aws-samples/amazon-nova-samples.git cd amazon-nova-samples/customization/SageMakerUilts/SageMakerJobsMonitoring/
基本的な使用法
# Enabling email notifications for training job status updates python enable_sagemaker_job_notifs.py --email test@amazon.com test2@gmail.com --region us-east-1 --platform SMTJ Creating resources........ Please check your email for a subscription confirmation email, and click 'Confirm subscription' to start receiving job status email notifications! You'll receive the confirmation email within a few minutes.
# Obtaining training time estimates based on job configurations python get_training_time_estimate.py
# Obtaining approximations for how long training is expected to take for in-progress jobs python get-training-job-progress.py --region us-east-1 --job-name my-training-job --num-dataset-samples 1000
その他の詳細と例については、こちら