Nova Forge SDKを用いたNovaカスタマイズ実験の開始

Amazon AWS AI Blog / 2026/3/19

📰 ニュースDeveloper Stack & InfrastructureTools & Practical Usage

要点

  • Nova Forge SDKはLLMのカスタマイズを誰もが扱えるようにし、エンタープライズチームにおける依存関係の管理・イメージ選択・レシピ設定といった課題を軽減します。
  • 本記事はエンドツーエンドのワークフローをデモンストレーションします。SageMaker AI Training Jobsを用いてAmazon Novaモデルをトレーニングし、Stack Overflowデータセットでベースラインのパフォーマンスを評価し、Supervised Fine-Tuning(SFT)を適用し、その後 Reinforcement Fine-Tuning(RFT)を行って結果を改善します。
  • Stack Overflowの質問をHQ、LQ_EDIT、LQ_CLOSEに自動分類するケーススタディを提示し、実用的な利点を示します。
  • このプロセスは、カスタマイズしたモデルをAmazon SageMaker AI Inferenceエンドポイントにデプロイするところで完結します。エンドツーエンドのカスタマイズ、評価、およびデプロイを実演します。

Amazon Simple Storage Service (Amazon S3) へアップロードする前に、変換されたデータを検証するために loader.validate() メソッドを実行します。これにより、実際の評価を妨げるまで待つのではなく、フォーマットの問題を早期に検出できます。

# Validate data format
loader.validate(method=TrainingMethod.EVALUATION, model=MODEL)

Finally, we can save the dataset to Amazon S3 using the loader.save_data() メソッドを使用してデータセットを Amazon S3 に保存し、評価ジョブで使用できるようにします。

# Save to S3
evap_s3_uri = loader.save_data(
    f"s3://{S3_BUCKET}/{S3_PREFIX}/data/eval.jsonl"
)

Run baseline evaluation

データを準備した状態で、ランタイムインフラストラクチャを構成するために SMTJRuntimeManager を初期化します。次に NovaModelCustomizer オブジェクトを初期化し、baseline_customizer.evaluate() を呼び出して、ベースライン評価ジョブを起動します:

# Configure runtime infrastructure
runtime_manager = SMTJRuntimeManager(
    instance_type=INSTANCE_TYPE, 
    instance_count=EVAL_INSTANCE_COUNT, 
    execution_role=EXECUTION_ROLE
)
# Create baseline evaluator
baseline_customizer = NovaModelCustomizer(
    model=MODEL, 
    method=TrainingMethod.EVALUATION, 
    infra=runtime_manager, 
    data_s3_path=eval_s3_uri, 
    output_s3_path=f"s3://{S3_BUCKET}/{S3_PREFIX}/baseline-eval"
)

# Run evaluation
# GEN_QA task provides metrics like ROUGE, BLEU, F1, and Exact Match
baseline_result = baseline_customizer.evaluate( 
    job_name="blogpost-baseline",
    eval_task=EvaluationTask.GEN_QA # Use GEN_QA for classification
)

分類タスクでは、GEN_QA 評価タスクを使用します。これは分類を、モデルがクラスラベルを生成する生成タスクとして扱います。GEN_QAexact_match 指標は分類精度、すなわち予測が真のラベルと完全一致する割合に直接対応します。ベンチマークタスクの全リストは EvaluationTask 列挙型から取得できます。あるいは Amazon Nova ユーザーガイド にも掲載されています。

Understanding the baseline results

ジョブが完了した後、結果は指定された出力パスの Amazon S3 に保存されます。アーカイブには、サンプルごとの予測と対数確率、評価全体の集計指標、および詳細な分析のためのモデルの生データ予測が含まれます。

以下の表では、評価ジョブの出力から得られたすべての評価サンプルの集計指標を確認できます(BLEU は0-100のスケールです):

指標 スコア
ROUGE-1 0.1580 (±0.0148)
ROUGE-2 0.0269 (±0.0066)
ROUGE-L 0.1580 (±0.0148)
正解一致(EM) 0.1300 (±0.0151)
準EM(QEM) 0.1300 (±0.0151)
F1 スコア 0.1380 (±0.0149)
F1 スコア(準) 0.1455 (±0.0148)
BLEU 0.4504 (±0.0209)

この3クラス分類タスクにおけるベースモデルは正解一致精度がわずか13.0%にとどまり、ランダム推測では33.3%となることを示しています。これはファインチューニングの必要性を明確に示しており、改善を測る定量的なベースラインを確立します。

次のセクションで見るように、これは主に問題のフォーマット要件をモデルが無視することに起因します。説明や分析を含む冗長な回答は無効と見なされます。以下の classification_accuracy ユーティリティ関数を用いて、モデルの出力テキストから3つのラベルを抽出して、形式に依存しない分類精度を導出できます。

def classification_accuracy(samples): 
    """Extract predicted class via substring match and compute accuracy."""
    correct, total, no_pred = 0, 0, 0 
    for s in samples: 
        gold = s["gold"].strip().upper() 
        pred_raw = s["inference"][0] if isinstance(s["inference"], list) else s["inference"] 
        pred_cat = extract_category(pred_raw) 
        if pred_cat is None: 
            no_pred += 1 
            continue 
        total += 1 
        if pred_cat == gold: 
            correct += 1 
    acc = correct / total if total else 0 
    print(f"Classification Accuracy: {correct}/{total} ({acc*100:.1f}%)") 
    print(f" No valid prediction: {no_pred}/{total + no_pred}") 
    return acc

print("???? Baseline Classification Accuracy (extracted class labels):")
baseline_accuracy = classification_accuracy(baseline_samples)

しかし、冗長性を無視する寛容な指標を用いても、分類精度はわずか52.2%にとどまります。これは、ベースモデルの性能を向上させるためのファインチューニングが必要であることを明確に示しています。

Conduct baseline failure analysis

以下の画像は、ベースラインの失敗分析を示しています。応答の長さ分布から、システムプロンプトがカテゴリ名のみを求めているにもかかわらず、すべての応答に冗長な説明と推論が含まれていたことが分かります。さらに、ベースラインの混同行列は真のラベル(y軸)と生成されたラベル(x軸)を比較します。LLM は実際の分類に関係なく、メッセージを High Quality と分類する傾向が明確です。

指示の従順性の失敗と HQ への分類バイアスというこれらのベースライン結果を踏まえ、モデルにタスク構造と出力形式を理解させるために SFT を適用し、その後、望ましくない挙動を罰する報酬関数を用いた強化学習(RL)を行います。

Stage 2: Supervised fine-tuning

ステージ 2: 教師ありファインチューニング

Now that we have completed our baseline and conducted the failure space analysis, we can use Supervised Fine Tuning to improve our performance. For this example, we use a Parameter Efficient Fine-Tuning approach, because it’s a technique that gives us initial signals on models learning capability.

Data preparation for supervised fine-tuning

With the Nova Forge SDK, we can bring our datasets and use the SDKs data preparation helper functions to curate the SFT datasets with in-build data validations.

As before, we use the SDK’s CSVDatasetLoader to load our training CSV data and transform it into the required format:

loader = CSVDatasetLoader(
    question='Body', # Stack Overflow question text
    answer='Y', # Classification label (HQ, LQ_EDIT, LQ_CLOSE)
    system='system' # System prompt column
)

loader.load('sft.csv')
loader.transform(method=TrainingMethod.SFT_LORA, model=Model.NOVA_LITE_2)
loader.show(n=3)

After this transformation, each row of our dataset will be structured in Converse API 形式, as shown in the following image:

{ 
    "system": [ 
        {"text": "<system prompt>"} 
    ], 
    "messages": [ 
        { 
            "role": "user", 
            "content": [ 
                {"text": "<input data>"} 
            ] 
        }, 
        { 
            "role": "assistant", 
            "content": [ 
                {"text": "<output data>"} 
            ] 
        } 
    ]
}

We also validate the dataset to confirm that it fits the required format for training:

loader.validate(method=TrainingMethod.SFT_LORA, model=Model.NOVA_LITE_2)

データが適切に整形され、正しい形式になったので、訓練データ・検証データ・テストデータに分割し、それら3つを Amazon S3 にアップロードして、訓練ジョブが参照できるようにします。

# S3 へ保存 train_path = loader.save_data(f\"s3://{S3_BUCKET}/{S3_PREFIX}/data/train.jsonl\")

教師付きファインチューニング(SFT)ジョブを開始

データを準備し、Amazon S3 にアップロードした状態で、教師付きファインチューニング(SFT)ジョブを開始します。

Nova Forge SDK は、トレーニング用のインフラストラクチャを指定するのを手助けし、Amazon SageMaker Training Jobs か Amazon SageMaker Hyperpod のいずれかでプロセスを合理化します。必要なインスタンスを用意し、トレーニングジョブの起動を促進するため、レシピ構成や API フォーマットを気にする必要がなくなります。

SFT トレーニングでは、4 ml.p5.48xlarge インスタンスを使用する Amazon SageMaker Training Jobs を引き続き使用します。ジョブの開始を試みるとき、SDK は選択したモデルに対するサポート値に対して環境とインスタンス構成を検証し、ジョブが送信された後にエラーが発生するのを防ぎます。

runtime = SMTJRuntimeManager( 
    instance_type=INSTANCE_TYPE, 
    instance_count=TRAIN_INSTANCE_COUNT, 
    execution_role=EXECUTION_ROLE
)

次に、トレーニング自体の設定を行い、ジョブを実行します。 overrides パラメータを使用して、デフォルト値からトレーニング設定を変更して性能を向上させることができます。ここでは、max_steps を比較的小さな値に設定して、このテストの実行時間を短くしています。

customizer = NovaModelCustomizer( 
    model=MODEL, 
    method=TrainingMethod.SFT_LORA, 
    infra=runtime, 
    data_s3_path=train_path, 
    output_s3_path=f\"s3://{S3_BUCKET}/{S3_PREFIX}/sft-output\"
)

training_config = {
    \"lr\": 5e-6, # 学習率
    \"warmup_steps\": 17, # 段階的な学習率の増加
    \"max_steps\": 100, # 総トレーニングステップ
    \"global_batch_size\": 64, # 勾配更新ごとのサンプル数
    \"max_length\": 8192, # トークンの最大シーケンス長
}

result = customizer.train( 
    job_name=\"blogpost-sft\", 
    overrides=training_config
)

You can use the Nova Forge SDK to run training jobs in dry_run mode. This mode runs all the validations that the SDK would execute, while actually running a job, but doesn’t start the execution if all validations fail. This helps you to know in advance whether a training setup is valid before trying to use it, for instance when generating configs automatically or exploring possible settings:

result = customizer.train( 
    job_name=\"blogpost-sft\", 
    overrides=training_config, 
    dry_run=True
)

これで dry_run が成功したことを確認できたので、ジョブの起動に進みます:

result = customizer.train( 
    job_name=\"blogpost-sft\", 
    overrides=training_config
)

ジョブの保存と読み込み

作成したジョブのデータを保存するには、結果オブジェクトを JSON ファイルに直列化し、後で取得して前回の続きから再開できます:

# ファイルへ保存
result.dump(file_path=\".\", file_name=\"training_result.json\")

# ファイルから読み込み
result = TrainingResult.load(\"training_result.json\")

SFT起動後のログ監視

SFT ジョブを起動した後、Amazon CloudWatch に公開されるログをモニターできます。ログには、損失、学習率、スループットなどのステップごとの指標が表示され、リアルタイムで収束を追跡できます。

Nova Forge SDK には、ノートブック環境で直接、各プラットフォームタイプのログを簡単に抽出・表示するための組み込みユーティリティが備わっています。

monitor = CloudWatchLogMonitor.from_job_result(result)
monitor.show_logs(limit=50)

カスタマイザーオブジェクトにログを直接要求することもでき、それは生成した最新のジョブのログをインテリジェントに取得します:

customizer.get_logs(limit=20)

さらに、ジョブのステータスをリアルタイムで追跡でき、ジョブが成功したか失敗したかを追跡するのに役立ちます:

result.get_job_status() # 返されます (JobStatus.IN_PROGRESS, ...) または (JobStatus.COMPLETED, ...)

Evaluating the SFT model

トレーニングが完了したら、ベースライン評価に使用した同じデータセットで微調整済みモデルを評価し、ベースラインと比べてどれだけ改善したかを理解します。Nova Forge SDK は、トレーニングジョブで生成されたモデルの評価を実行することをサポートしています。以下の例はこれを示します:

# ランタイムインフラの設定
runtime_manager = SMTJRuntimeManager( 
    instance_type=INSTANCE_TYPE, 
    instance_count=EVAL_INSTANCE_COUNT, 
    execution_role=EXECUTION_ROLE
)

# ベースライン評価者の作成
baseline_customizer = NovaModelCustomizer( 
    model=MODEL, 
    method=TrainingMethod.EVALUATION, 
    infra=runtime_manager, 
    data_s3_path=eval_s3_uri, 
    output_s3_path=f\"s3://{S3_BUCKET}/{S3_PREFIX}/sft-eval\"
)

# 評価の実行
baseline_result = baseline_customizer.evaluate( 
    job_name=\"blogpost-eval\", 
    eval_task=EvaluationTask.GEN_QA
    job_result=result, # トレーニング結果から自動的にチェックポイントパスを導出
)

Post-SFT evaluation results

以下の表には、SFT トレーニングを適用した後の同じ評価データセットに対する集計指標が表示されています:

指標 スコア 差分
ROUGE-1 0.8290 (±0.0157) 0.671
ROUGE-2 0.4860 (±0.0224) 0.4591
ROUGE-L 0.8290 (±0.0157) 0.671
完全一致(EM) 0.7720 (±0.0188) 0.642
準EM(QEM) 0.7900 (±0.0182) 0.66
F1 スコア 0.7720 (±0.0188) 0.634
F1 スコア(準) 0.7900 (±0.0182) 0.6445
BLEU 0.0000 (±0.1031) -0.4504

短いトレーニング実行でも、BLEU を除くすべての指標で改善が見られ、完全一致指標の正確度は 77.2% にまで上昇します。

print(\"Post-SFT Classification Accuracy (extracted class labels):\")
sft_accuracy = classification_accuracy(sft_samples)

自分の分類精度指標を確認すると、評価データポイントの 79.0% が正しい分類を得ていることがわかります。分類精度と完全一致スコアの間の小さな差は、モデルが必要な形式を正しく学習したことを示しています。

詳細なパフォーマンス指標から、応答長の分布が非冗長な応答へ完全に偏っていることが分かります。混同行列では、LQ_EDITおよびLQ_CLOSEクラスの分類精度が劇的に向上し、HQとして行を分類するモデルのバイアスを低減しています。

ステップ3: 強化微調整

前のデータに基づくと、SFTはモデルを所定のフォーマットに適合させる訓練には優れていますが、生成ラベルの精度をさらに向上させる余地があります。次に、訓練済みのSFTチェックポイントの上に、強化微調整を反復的に追加していきます。これは、要求フォーマットへ適合させる以上の複雑なケースで問題を定量的な報酬の観点で捉えられるタスクを含む場合など、モデルの精度向上を図る際に一般的に有益です。

報酬関数の構築

分類のために、正しい予測には正のスコア(+1)を、誤った予測には負のスコア(-1)を付与するAWS Lambda関数を作成します:

  • 1.0: 正しい予測
  • -1.0: 不正解の予測

この関数は3つの品質カテゴリ(HQLQ_EDITLQ_CLOSE)を扱い、モデル出力の小さな書式の違いに対処する柔軟なテキスト抽出を使用します(例: “HQ”、”HQ.”、”The answer is HQ”)。この堅牢な抽出により、わずかに冗長な応答を生成している場合でも、モデルが正確な報酬信号を受け取ることが保証されます。二値の報酬構造は、高品質と低品質のコンテンツカテゴリを区別するのに役立つ、強く明確な勾配を生み出します。

"""Binary reward function for classification: +1 correct, -1 wrong.
Simple and clear signal:
- Correct prediction: +1.0
- Wrong prediction: -1.0
"""

def calculate_reward(prediction: str, ground_truth: str) -> float: 
    """ Calculates binary reward """ 
    extracted = extract_category(prediction) # Extracts category from prediction and normalize it 
    truth_norm = normalize_text(ground_truth) # Normalize the groundtruth

 # Correct prediction
    if extracted and extracted == truth_norm: return 1.0

 # Wrong prediction
    return -1.0

def lambda_handler(event, context): 
    """ Lambda handler with binary rewards. """ 
    scores: List[RewardOutput] = [] 
    
    for sample in event: 
        idx = sample.get("id", "no_id") 
        ground_truth = sample.get("reference_answer", "") 
        prediction = last_message.get("content", "")

 # Calculate binary reward
        reward = calculate_reward(prediction, ground_truth) 
 scores.append(RewardOutput(id=idx, aggregate_reward_score=reward)) 
 return [asdict(score) for score in scores]

Deploy this Lambda function to AWS and note the ARN for use in the RFT training configuration.

Next we deploy the lambda function to AWS account, and get the deployed lambda ARN, so it can be used while launching the RFT training.

Make sure to add Lambda Invoke Policies to your customization IAM role, so that Amazon SageMaker AI can invoke the Lambda policies after training begins.

Data preparation towards RFT

SFT の実験設定と同様に、Nova Forge SDK を使用してデータセットを厳選し、RFT スキーマの検証を行うことができます。これによりデータセットを RFT に適した OpenAI スキーマへ変換できます。以下のスニペットはデータセットを RFT データセットへ変換する方法を示しています。

RFT_DATA = './rft.csv' 

rft_loader = CSVDatasetLoader( 
    query='Body', 
    response='Y', 
    system='system'
) 

rft_loader.load(RFT_DATA)

# Transform for RFT
rft_loader.transform(method=TrainingMethod.RFT_LORA, model=MODEL)
rft_loader.validate(method=TrainingMethod.RFT_LORA, model=MODEL)

# Save to S3
rft_s3_uri = rft_loader.save_data( 
    f"s3://{S3_BUCKET}/{S3_PREFIX}/data/rft.jsonl"
)

After this transformation you will get data in following OpenAI format:

{ 
    "system": [ 
        { 
            "text": "<system prompt>"
        } 
    ], 
    "messages": [ 
        { 
            "role": "user", 
            "content": [ 
                { 
                    "text": "<input data>" 
                } 
            ] 
        } 
    ], 
    "reference_answer": "<reference answer>"
    #any other metadata field you use in data loader mapping
}

Launching RFT on SFT checkpoint and Monitoring Logs

Next, we will initialize the RFT job itself on top of our SFT checkpoint. For this step, Nova Forge SDK helps you launch your RFT job by bringing the formatted dataset along with the reward function to be used. The following snippet shows an example of how to run RFT on top of SFT checkpoint, with RFT data and reward function.

REWARD_LAMBDA_ARN = "arn:aws:lambda:us-east-1:ACCOUNT:function:classification-reward"

# Configure RFT infrastructure
RFT_INSTANCE_COUNT = 2 

rft_runtime = SMTJRuntimeManager( 
    instance_type=INSTANCE_TYPE, 
    instance_count=RFT_INSTANCE_COUNT, 
    execution_role=EXECUTION_ROLE
)

# Create RFT customizer
rft_customizer = NovaModelCustomizer( 
    model=MODEL, 
    method=TrainingMethod.RFT_LORA, 
    infra=rft_runtime, 
    data_s3_path=rft_s3_uri, 
    output_s3_path=f"s3://{S3_BUCKET}/{S3_PREFIX}/rft-output",
    model_path=sft_checkpoint # Start from SFT checkpoint
)

We use the following hyperparameters for the RFT training run. To explore the hyperparameters, we aim for only 40 steps for this RFT job to keep the training time low.

rft_overrides = {
    "lr": 0.00001, # Learning rate
    "number_generation": 4, # N samples per prompt to estimate advantages (variance vs cost).
    "reasoning_effort": "null", # Enables reasoning mode High / Low / or null for  non-reasoning
    "max_new_tokens": 50, # This cuts off verbose outputs
    "kl_loss_coef": 0.02, # Weight on the KL penalty between the actor  (trainable policy) and a frozen reference model
    "temperature": 1, # Softmax temperature
    "ent_coeff": 0.01, # A bonus added to the policy loss that rewards  higher-output entropy
    "max_steps": 40, # Steps to train for. One Step = global_batch_size
    "save_steps": 30, # Steps after which a checkpoint will be saved
	"top_k": 5, # Sample only from top-K logits
    "global_batch_size": 64, # Total samples per optimizer step across all  replicas (16/32/64/128/256)
}

# Start RFT training
rft_result = rft_customizer.train( 
    job_name="stack-overflow-rft", 
    rft_lambda_arn=REWARD_LAMBDA_ARN, 
    overrides = rft_overrides
)

We can monitor the RFT training logs using the show_logs() method:

rft_result = CloudWatchLogMonitor.from_job_result(rft_result)
rft_result.show_logs()

Key metrics in the RFT training logs include:

  1. 報酬の統計:生成された応答に対して、Lambda 関数が割り当てた平均品質スコア。
  2. クリティックスコア:価値モデルが将来の報酬をどれだけ適切に予測するか。
  3. ポリシー勾配の指標(損失と KL 発散など):トレーニングの安定性と初期状態からの変化量。
  4. 応答長の統計:出力の冗長さを追跡。
  5. スループット(トークン/秒)、メモリ使用量、1学習ステップあたりの時間などのパフォーマンス指標。

これらのログを監視することで、報酬崩壊(平均報酬の低下)、ポリシーの不安定性(高い KL 発散)、生成の問題(応答長が max_token 数に近づく)といった問題を特定できます。問題を特定した後は、必要に応じてハイパーパラメータや報酬関数を調整します。

RFT 報酬分布

前回の RFT トレーニングでは、正解の応答(中に正しいラベルを含む応答)には +1.0、誤った応答には -1.0 の報酬関数を使用しました。

これは、SFT のトレーニングがすでにモデルに所定のフォーマットを教えたためです。SFT の調整パターンを崩しすぎず過剰訓練を避ければ、応答はすでに適切な冗長性を持ち、モデルは正しい答えを返そうとします(フォーマットを崩してしまうことや、フォーマットを不正に利用することは避けられます)。

既存の SFT トレーニングをサポートするため、kl_loss_coef を追加して SFT によって誘発されたパターンからの発散を遅らせます。また、max_tokens を制限することで、長い応答よりも短い応答を促します(分類トークンがウィンドウ内に収まることが保証されているため)。短いトレーニング期間を考慮すると、RFT の調整がモデルの性能を改善することを示すには十分です。

SFT+RFT後の実験を評価

ベースラインおよびポスト-SFTの評価と同じ評価設定を使用して、ポスト SFT+RFT のカスタマイズモデルを評価します。これにより、反復トレーニングでどれだけの改善を実現できるかを理解できます。従来同様、Nova Forge SDK を使用して、モデルの性能向上を見つけるためのもう一度の評価を迅速に実行できます。

結果

指標 スコア デルタ
ROUGE-1 0.8400 (±0.0153) 0.011
ROUGE-2 0.4980 (±0.0224) 0.012
ROUGE-L 0.8400 (±0.0153) 0.011
完全一致 (EM) 0.7880 (±0.0183) 0.016
準完全一致 (QEM) 0.8060 (±0.0177) 0.016
F1 スコア 0.7880 (±0.0183) 0.016
F1 スコア(準) 0.8060 (±0.0177) 0.016
BLEU 0.0000 (±0.0984) 0

強化Fine-Tuning(RFT)を既存モデルに組み込んだ結果、ベースラインおよび単独のSFTモデルと比較して性能が向上しました。すべての指標は概ね1%程度向上しました。

指標を比較すると、改善データ量の順序がSFTファインチューニングとは異なることがわかります。これは、RFT が SFT 実行からの教訓を強化するのではなく、モデルの異なるパターンを調整していることを示しています。


詳細なパフォーマンス指標は、モデルが引き続き要求された出力形式に従い、SFT実行の教訓を覚えていることを示しています。さらに、分類自体は正しい対角線により集中しており、混同行列の誤分類マスごとに母数が減少しています。

これらの予備的な所見は、反復的なトレーニングが単一のトレーニングセッションだけを超えて性能をさらに向上させるのに役立つ可能性があることを示しています。より長いトレーニング実行でハイパーパラメータを調整すれば、これらの改善をさらに進めることができます。

最終結果の分析

指標 ベースライン SFT後 RFT後 デルタ(RFT-ベース)
ROUGE-1 0.158 0.829 0.84 0.682
ROUGE-2 0.0269 0.486 0.498 0.4711
ROUGE-L 0.158 0.829 0.84 0.682
正解一致 (EM) 0.13 0.772 0.788 0.658
準正解一致 (QEM) 0.13 0.79 0.806 0.676
F1 スコア 0.138 0.772 0.788 0.65
F1 スコア (準) 0.1455 0.79 0.806 0.6605
BLEU 0.4504 0 0 -0.4504

Across all evaluation metrics, we see:

  • Overall Improvement: The two-stage customization approach (SFT + RFT) achieved consistent improvements across all metrics, with ROUGE-1 improving by +0.682, EM by +0.658, and F1 by +0.650 over baseline.
  • SFT vs RFT Roles: SFT provides the foundation for domain adaptation with the largest performance gains, while RFT fine-tunes decision-making through reward-based learning.
  • BLEU scores are not meaningful for this classification task, as BLEU measures n-gram overlap for generation tasks. Since our model outputs single-token classifications (HQ, LQ_EDIT, LQ_CLOSE), BLEU cannot capture the quality of these categorical predictions and should be disregarded in favor of exact match (EM) and F1 metrics.

ステップ4: Amazon SageMaker AI Inference へのデプロイ

最終モデルが準備できたので、実際の予測を提供できる場所へデプロイできます。Nova Forge SDK はデプロイを容易にします。完全に管理された推論を提供する Amazon Bedrock を選ぶ場合でも、インフラストラクチャをより細かく制御したい場合には Amazon SageMaker AI を選ぶ場合でも、デプロイは容易です。

SDK は2つのデプロイメントターゲットをサポートし、それぞれに異なる利点があります:

  • Amazon Bedrock は、2つのオプションを備えた完全に管理されたエクスペリエンスを提供します:
    • On-Demand: 自動スケーリングと従量課金制を備えたサーバーレス推論で、変動するワークロードと開発に最適です
    • Provisioned Throughput: 一定のトラフィックを持つ本番ワークロード向けの予測可能なパフォーマンスを提供する専用容量
  • Amazon SageMaker AI Inference は、カスタムインスタンスタイプや特定の環境構成が必要な場合に柔軟性を提供します。インスタンスタイプや初期インスタンス数を指定し、環境変数を通じてモデルの挙動を設定することができ、SDK がデプロイの複雑さを処理します。
  • このデモンストレーションでは、Amazon SageMaker AI Inference にデプロイします。

    ENDPOINT_NAME = "blogpost-sdkg6"
    deployment_result = rft_customizer.deploy( 
        job_result = rft_result, 
        deploy_platform=DeployPlatform.SAGEMAKER, 
        unit_count=1, 
        endpoint_name= ENDPOINT_NAME, 
        execution_role_name="blogpost-sagemaker", 
        sagemaker_instance_type="ml.p5.48xlarge", 
        sagemaker_environment_variables={ 
            "CONTEXT_LENGTH": "12000", 
            "MAX_CONCURRENCY": "16" 
        }
    )
    

    これにより、実行ロール blogpost-sagemaker が存在しない場合に作成され、デプロイ時に使用されます。すでに使用したいロールがある場合は、そのロール名を直接渡すことができます。

    エンドポイントの呼び出し

    エンドポイントがデプロイされた後、SDKを使って呼び出すことができます。invoke_inference メソッドは SageMaker のエンドポイントにはストリーミング出力を、Amazon Bedrock のエンドポイントには非ストリーミング出力を提供します。以下のコードを使って呼び出すことができます:

    streaming_chat_request = { 
        "messages": [{"role": "user", "content": "Tell me a short story"}], 
        "max_tokens": 200, 
        "stream": True,}
    ENDPOINT_NAME = f"arn:aws:sagemaker:REGION:ACCOUNT_ID:endpoint/{ENDPOINT_NAME}"
    
    inference_result = rft_customizer.invoke_inference( 
        request_body=streaming_chat_request, 
        endpoint_arn=ENDPOINT_NAME
    )
    inference_result.show()
    

    ステップ5: クリーンアップ

    デプロイのテストが完了したら、継続的な AWS の料金を避けるためにこれらのリソースをクリーンアップしてください。

    Amazon SageMaker エンドポイントの削除

    import boto3
    
    sagemaker_client = boto3.client('sagemaker')
    
    # Delete endpoint
    sagemaker_client.delete_endpoint(EndpointName='your-endpoint-name')
    

    IAM ロールとポリシーの削除

    import boto3
    
    iam_client = boto3.client('iam')
    role_name = 'your-role-name'
    
    # Detach managed policies
    attached_policies = iam_client.list_attached_role_policies(RoleName=role_name)
    for policy in attached_policies['AttachedPolicies']: 
        iam_client.detach_role_policy( 
            RoleName=role_name, 
            PolicyArn=policy['PolicyArn'] 
        )
    
    # Delete inline policies
    inline_policies = iam_client.list_role_policies(RoleName=role_name)
    for policy_name in inline_policies['PolicyNames']: 
        iam_client.delete_role_policy( 
            RoleName=role_name, 
            PolicyName=policy_name 
    )
    
    # Remove from instance profiles
    instance_profiles = iam_client.list_instance_profiles_for_role(RoleName=role_name)
    for profile in instance_profiles['InstanceProfiles']: 
        iam_client.remove_role_from_instance_profile( 
            InstanceProfileName=profile['InstanceProfileName'], 
            RoleName=role_name 
        )
    
    # Delete the role
    iam_client.delete_role(RoleName=role_name)
    

    Conclusion

    Nova Forge SDKは、複雑でインフラ依存のプロセスから、アクセスしやすく開発者に優しいワークフローへとモデルカスタマイズを変革します。我々のStack Overflow分類ケーススタディを通じて、反復的なトレーニングを通じてSDKを活用し、ベースライン精度13%からSFT後に79%、追加のRFTで80.6%に達するという測定可能な改善をチームが達成できることを示しました。

    従来のLLMカスタマイズにおける障壁、技術的専門知識の要件、および時間投資を取り除くことで、Nova Forge SDKは、基盤モデルの価値を損なうことなく、組織が自社の独自の文脈を理解するモデルを構築できるようにします。SDKは計算リソースの構成、カスタマイズパイプライン全体の指揮、トレーニングジョブの監視、およびエンドポイントのデプロイを扱います。その結果、専門性と知性を備えた企業向けAIが生まれ、ドメインエキスパートでありながら広く対応力を持つようになります。

    独自のNovaモデルをカスタマイズする準備はできましたか? GitHub の Nova Forge SDK から始め、完全なドキュメント を参照して、企業ニーズに合わせたモデルの作成を開始してください。


    著者について