SageMakerのサーバーレス微調整でECの商品タグ付けを自動化 — SFT＋強化学習でスコアが0.35から0.69へ、報酬関数がそのままビジネスポリシーになる設計

9月16日、AWSが「Build an AI-powered product tagging system with Amazon SageMaker serverless model customization」と題した記事を公開した。Amazon SageMaker のサーバーレスモデルカスタマイズ機能を使い、Qwen3-8B を SFT と RLVR でファインチューニングして商品タグ付けシステムを構築する手順が詳しく解説されている。

なぜ汎用LLMではなくカスタマイズなのか

ECサイトのカタログ管理において、商品タグの一貫性は検索や推薦の精度に直結する。しかし数千〜数万SKUに対して人手でタグを付与し続けるのは現実的でない。商品数の増加やカテゴリの多様化に伴い、タグ付けの抜け・揺れ・誤分類が蓄積すると、レコメンデーションエンジンや検索インデックスの品質劣化に直結するという課題は、EC業界において広く共通する問題だ。

汎用の大規模モデルをプロンプトエンジニアリングで使う方法もあるが、タグ付けのように「決まったスキーマで正しい属性を返す」という狭い目的には、小規模なオープンウェイトモデルをカスタマイズする方が費用対効果が高い。記事が採用したのは **Qwen3-8B**（Alibaba製の80億パラメータモデル）で、SFT（教師あり微調整）でスキーマを学習させ、その後 RLVR（検証可能な報酬による強化学習）で出力品質を最適化するという2段階のアプローチだ。

Qwen3-8Bが選ばれた背景としては、Apache 2.0ライセンスで商用利用が可能である点、8Bクラスのモデルとしてベンチマーク上の性能が高い点、そしてSageMakerのモデルカタログに huggingface-reasoning-qwen3-8b として登録済みであり追加の持ち込み作業が不要な点が挙げられる。強化学習手法としてGRPOを選んでいる点も注目に値する。PPOと比較してGRPOは参照モデルや価値関数ネットワークを別途必要とせず、複数候補のグループ内相対スコアのみでポリシーを更新するため、実装コストとメモリ使用量が抑えられる。GRPO論文（DeepSeekMath）では数学的推論タスクでの有効性が示されており、正解が決定論的に評価できるタスクへの適性が高い。

構成の全体像

ワークフローは「データ準備 → サーバーレスモデルカスタマイズ → 推論」の3フェーズに分割されている。

訓練: Amazon SageMaker サーバーレスモデルカスタマイズ（コンピュートの選択・管理はAWS側が担う）
推論: Amazon SageMaker Asynchronous Inference（ml.g6.2xlarge インスタンスを使用する）

「サーバーレス」は訓練フェーズに限った話で、推論エンドポイントはプロビジョニング型である点に注意が必要だ。なお、SageMakerのサーバーレスモデルカスタマイズ機能は2025年に一般提供が開始されたもので、インフラ管理の負荷を削減しながらLoRAベースの微調整を実行できる点が特徴だ。

Step 1: データ準備

Kaggle上の Amazon Sales Dataset（1,000件以上の商品レコード）を使用する。SageMaker Processing ジョブでカタログテキストを正規化し、9カテゴリのタグスキーマにマッピングしてJSONL形式に変換する。各行は以下の形式だ。

{"messages": [
  {"role": "system", "content": "Use the nine-category schema."},
  {"role": "user", "content": "Name: USB-C Cable | Category: Cables"},
  {"role": "assistant", "content": "1, Product Name: USB-C Cable\n...\n9, Occasion:"}
]}

変換後のファイルは Amazon SageMaker AI Registry にバージョン管理されたデータセットとして登録し、訓練ジョブはそのARNを参照する。

Step 2: SFTでスキーマを叩き込む

Python SDK v3 の SFTTrainer を使い、LoRA（Low-Rank Adaptation）でQwen3-8Bを微調整する。コンピュート引数を省略するだけでサーバーレス訓練になる。

from sagemaker.train.sft_trainer import SFTTrainer

trainer = SFTTrainer(
    model="huggingface-reasoning-qwen3-8b",
    training_type=TrainingType.LORA,
    model_package_group=model_package_group,
    training_dataset=TRAINING_DATASET_ARN,
    validation_dataset=VALIDATION_DATASET_ARN,
    sequence_length="4K",
    s3_output_path=S3_OUTPUT_PATH,
    role=ROLE_ARN,
    # compute引数なし → サーバーレス
)

trainer.hyperparameters.max_epochs = 3
trainer.hyperparameters.lora_rank = 16
trainer.hyperparameters.merge_weights = True

Step 3〜4: GRPOでリコールと精度を調整する

SFT後のモデルはスキーマに従えるが、属性の抜けや余分なタグが残ることがある。ここで GRPO（Group Relative Policy Optimization）を用いたRLVRが登場する。

GRPOは各プロンプトに対して複数の候補（本実装では rollout_n=8）を生成し、決定論的な報酬関数でスコアリングしてグループ内の相対的な優位性を計算する。報酬関数には別のLLMが不要で、参照タグとのファジーマッチング（閾値0.5）を使う。PPOと異なりクリティックネットワークや参照モデルの常駐が不要なため、同一ハードウェアでより大きなバッチサイズを扱いやすい点も実用上のメリットだ。

報酬の内訳は以下のとおりだ。

Overall = 0.30 × recall + 0.30 × precision + 0.30 × accuracy + 0.05 × match_quality + 0.05 × formatting

さらに訓練の進行に合わせて重みを変える「プログレッシブ報酬スケジュール」を採用している。序盤はリコール重視（属性の抜けを減らす）、後半はプレシジョン重視（不要なタグを減らす）という設計だ。このビジネス上のトレードオフを報酬関数に明示的に組み込んでいる点が特徴的で、報酬関数の設計がそのままビジネスポリシーの表明になるという構造になっている。

trainer = RLVRTrainer(
    model=SFT_MODEL_PACKAGE_ARN,
    custom_reward_function=REWARD_EVALUATOR_ARN,
    training_dataset=training_dataset,
    # compute引数なし → サーバーレス
)
trainer.hyperparameters.rollout_n = 8
trainer.hyperparameters.max_epochs = 4
trainer.hyperparameters.learning_rate = 1e-5

評価結果：SFTが主役、GRPOが微調整

3段階の評価結果は以下のとおりだ。

モデル	Overall	Recall	Precision	Accuracy
ベースライン	0.354	0.327	0.397	0.327
SFT	0.6827	0.6689	0.652	0.6689
GRPO	0.6941	0.703	0.638	0.686

品質向上の大部分はSFTによるもの（Overall: 0.354 → 0.683）で、GRPOは追加の改善を提供しつつリコールを優先した調整を行っている（リコール: 0.669 → 0.703、プレシジョンは0.652 → 0.638に微減）。

記事では「属性の抜けがダウンストリームで高コストな場合はGRPOが有効。逆に余分なタグが問題になる場合は報酬の重みをプレシジョン寄りに変更せよ」と明示している。報酬関数のウェイト調整という技術的操作が、そのまま「何を優先するか」というビジネス判断と1対1で対応する点は、実務担当者にとって扱いやすい設計だ。

推論: 非同期エンドポイントへのデプロイ

訓練済みモデルは ml.g6.2xlarge の非同期推論エンドポイントにデプロイし、リクエストをS3経由でキューイングする形式をとる。カタログのバッチ処理に適した構成だ。

response = sagemaker_runtime.invoke_endpoint_async(
    EndpointName=ENDPOINT_NAME,
    ContentType="application/json",
    InputLocation=input_location,
)
output_location = response["OutputLocation"]

本番環境ではキュー深度に応じたオートスケーリングポリシーの追加が推奨されている。

詳細はBuild an AI-powered product tagging system with Amazon SageMaker serverless model customizationを参照していただきたい。