SageMaker HyperPod Data Capture：部署后才发现的盲区如何变成训练数据
AWS 技术博客完整演示了一条闭环：支持工单路由器捕获生产流量，Athena 查询发现新产品盲区，SQL 策略自动标注，60 秒 LoRA 微调在同一集群上完成，新类别召回率从零提升到满额。作者用合成数据走完全程，同时指出置信度校准和关键词策略的局限。
部署后的模型会碰到训练集里根本没有的输入。新产品的专有名词、用户行为的变化、意料之外的格式——这些在离线基准测试里完全隐形，因为基准冻结在过去。AWS 这篇博客的核心论点很直接：没有生产推理数据的记录，团队无法检测漂移、发现失败模式，也无法用真实交互改进模型。SageMaker HyperPod 新增的 Data Capture 功能把每次推理的输入和输出写入 S3，分三个独立层级（端点、负载均衡器、模型 Pod），作者称延迟影响极小且不影响模型可用性。
文章用一个具体场景把闭环走通：一家家电零售商部署了支持工单路由器，用 vLLM 引导 JSON 解码把工单分类到六个产品类别。上线后零售商推出了 Arctis 系列空调，路由器没有这个类别，只能把空调工单塞进 Other 或错误地路由到 ProductFridge。作者用 900 条合成工单模拟上线前后的流量，通过 Tier 3 捕获全部记录到 S3，然后用 Athena 查询发现 Other 类别的占比从上线前的 4.8% 跳到上线后的 36.8%，且词频分析显示 arctis 一词出现 141 次——盲区被精确定位。
定位之后，作者把诊断写成一条 SQL 标注策略：关键词匹配 arctis、air condition、ac unit、mini split 的工单重新标为 ProductAC，其余保持原预测，混合信号的留给人工审核。这条策略从捕获数据中生成了 900 条训练样本，然后在同一集群的第二块 GPU 上用 HyperPod 训练算子跑了 60 秒 LoRA 微调（rank 16，约 2990 万可训练参数），把合并后的模型部署为第二个端点。在 280 条留出评估集上，新类别 ProductAC 的召回率从 0/40 提升到 40/40，五个原有类别没有回退。
但作者自己标注了几处重要限制。第一，模型自报的 confidence 字段不是校准概率：14 条被误路由到 ProductFridge 的空调工单中有 10 条报了 0.9 以上的置信度，说明用置信度做过滤规则会保留大量错误标签。第二，合成数据的评估集和训练集来自同一个生成器，所以 100% 留出准确率反映的是模板一致性而非泛化能力；作者另写了 24 条手工探针测试，微调后得分 20/24，暴露了两个捷径——把cooling等同于空调，以及任何提到 Arctis 的工单都标为 ProductAC（包括库存和价格咨询）。第三，关键词策略只在新类别边界清晰时有效，模糊或重叠类别需要路由到 Ground Truth 人工标注。整篇是厂商自测的合成数据走查，不是独立验证的生产结果。