摘要： 商品目錄送到手上時，很少是乾淨的結構化欄位。品名、描述與分類路徑各自來自不同來源，而且一直在變；搜尋、推薦與分類導覽全都得靠一致的標籤才運作得起來，可是要人工替數千個 SKU 貼標，不只慢，一致性也很難維持。 真正的關鍵設計在這裡：只要評分方式能用規則寫出來，客製化小模型就不只是「感覺比較便宜」，而是「訊號可驗證」。
商品目錄送到手上時，很少是乾淨的結構化欄位。品名、描述與分類路徑各自來自不同來源，而且一直在變；搜尋、推薦與分類導覽全都得靠一致的標籤才運作得起來，可是要人工替數千個 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 的說明，schema 遵循度最大的躍升預期會來自 SFT，因為它直接把期望的輸入輸出示範給模型看；至於剩下的品質取捨，才交給 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 的內容在獎勵函式設計段落之後就截斷了，後續的評估與部署細節並未完整呈現；上述流程以已提供的部分為準。