商品目錄很少以乾淨的結構化欄位送到你手上。品名、描述、分類路徑來自不同來源，而且持續變動；搜尋、推薦與分類導覽都依賴一致的標籤，但人工為數千個 SKU 貼標既慢又難維持一致。
AWS Machine Learning Blog 在 2026 年 9 月 15 日發布的 walkthrough 提出一個明確的判斷：當分類體系穩定、輸出可以用程式評分時，客製化一個較小的開源權重模型，可能比用通用前沿模型加 prompt engineering 更合適。理由是這類高頻貼標工作的目標很窄——用正確的 schema 穩定回傳正確的屬性——你不需要為每次請求都付費購買用不到的通才能力。
這條流程把三件事拆開
根據這篇 walkthrough，整體工作流刻意分成資料準備、serverless 模型客製化、推論三個關注點。資料先轉成有版號的資產，SFT 教模型認識貼標 schema，RLVR 再針對可驗證的獎勵優化行為，最後把模型打包上線。
值得注意的是「serverless」在這裡只指訓練路徑。推論端用的是 Amazon SageMaker Asynchronous Inference，跑在 provisioned 的 ml.g6.2xlarge 上，適合批次式的目錄充實。這個區分對成本估算很重要：訓練容量由 AWS 挑選與釋放，但推論仍是你自己的執行個體。
從 SFT 到 RLVR：什麼時候需要第二步
流程先用 supervised fine-tuning 客製化 Qwen3-8B，再以 RLVR 搭配 GRPO 優化。AWS 的說明指出，SFT 預期帶來 schema 遵循度最大的躍升，因為它直接示範了期望的輸入輸出；RLVR 則用來處理剩下的品質取捨，而不是重新學格式。
RLVR 之所以可行，是因為貼標輸出是結構化的，可以直接和參考答案比對，不需要另一個 LLM 來評判每個 completion。獎勵函式是確定性的：檢查九類輸出格式，並以 0.5 門檻做模糊比對。文中給出的權重是 recall、precision、accuracy 各 0.30，match_quality 與 formatting 各 0.05，而且排程會隨訓練階段改變強調重點，早期偏向 recall，避免模型漏掉應該出現的標籤。
這裡的關鍵設計是：當你的評分方式可以寫成規則，客製化小模型就從「感覺比較便宜」變成「訊號可驗證」。
與舊做法的差別在哪
AWS 對比了兩種路徑。amazon-sagemaker-examples 裡先前的 Qwen3-8B 範例使用 SageMaker Training Jobs，由客戶挑選 GPU 執行個體並自備訓練映像；這次的 walkthrough 改用 Amazon SageMaker Python SDK v3 的 serverless 客製化 trainer（SFTTrainer 與 RLVRTrainer）。不提供 compute 設定時，SageMaker 會自行選擇並釋放訓練容量。
如果你正在評估同類工作，這個對比比模型選擇更值得先想清楚：你要自己管訓練基礎設施，還是把容量調度交出去，換取較少的控制權。
上線前要先確認的幾件事
這篇 walkthrough 列出的前置條件相當具體，而且多數和模型無關。你需要 SageMaker AI 權限來管理客製化任務、AI Registry 資料集與評估器、model package group、endpoints 與非同步推論；需要 S3 讀寫來源目錄、轉換後的訓練資料與模型產物；只有在自行建置與託管 vLLM 推論映像時才需要 ECR。
另外要確認所選 Region 與模型／技術組合支援 Qwen3-8B 的 SFT 與 RLVR，並保留足夠的 hosting quota 給 ml.g6.2xlarge 與非同步 endpoint。資料集部分，示範用 Kaggle 上的 Amazon Sales Dataset，超過 1,000 筆商品記錄；正式環境應改用自己核准的目錄與可信標籤。本機工具需要 Python 3.11+、AWS CLI v2、pandas、SageMaker Python SDK v3，以及建置映像時才需要的 Docker。驗證建議走 IAM Identity Center 或其他短期憑證流程，避免 root 與長效 access key。
這類「把重複的判斷交給受控流程」的思路，和我們先前談 Amazon Bedrock prompt caching 如何壓低重複 context 成本 是同一個問題的不同切面：先辨識出工作裡真正重複、可預期的部分，再決定要為它付出多少推論成本。
實務上的下一步
如果你的目錄規模還小、分類體系仍在頻繁變動，這條路徑的前提就不成立——RLVR 的獎勵需要穩定的參考答案，schema 一直改就沒有可驗證的訊號。反過來說，當標籤類別固定、你能寫出評分規則、而且貼標量足以攤平客製化成本時，先做 SFT 拿到 schema 遵循度，再視漏標與多標的實際比例決定要不要進 RLVR，是比較容易驗證順序的做法。
需要提醒的是，這篇 walkthrough 的內容在獎勵函式設計段落後截斷，後續的評估與部署細節並未完整呈現；上述流程以已提供的部分為準。
參考來源
本文由 AI 協助自上述來源整理，經人工審核後發布。