【标题】亚马逊在大规模工单分类中用 Strands Decider 替换 Sonnet 4.6，成本狂降 98% 的启示录
【摘要】亚马逊将海量工单分类从生成式模型迁移至专用的决策模型，验证了在大规模固定分类任务中，生成式 AI 往往是昂贵的性能冗余。
【正文】
在 AWS 内部，处理每天海量的工单分类曾是一场军备竞赛。为了给各类异常告警、安全威胁和客户申诉打上正确的标签，工程团队一度将 Claude Sonnet 4.6 推到了台前。这种做法在短期内看似是用最好的工具解决最复杂的问题，但随着数据量级爆炸，账单上的数字迅速变得无法忽视。
最近，两个亚马逊工程师做了一个反直觉的决定：把这套昂贵的生成式模型撤掉，换成了基于 Gemma 4 的专用决策模型 Strands Decider。结果并非降级，而是系统效率的质变：单次调用延迟降低了 78%，成本更是一举砍掉了 98%。
这不仅仅是一次省钱的迁移，它代表了一种工程思维的回归。当任务逻辑是闭环的选择题而非开放的叙述题时，生成式模型往往是过度的性能浪费。
从写作文到算概率
生成式模型的核心竞争力在于创造，但大多数工业级任务根本不需要创造。工单分类本质上是一个受限的判别问题，即输入工单信息，在 20 个预设标签中选出正确的一个。
Claude Sonnet 4.6 之所以贵，是因为它在做每一步决策时都在写作文。为了输出一个 JSON 格式的答案，它需要消耗成千上万的 Token，包含推理过程、系统提示词以及长文本的冗余解析。
Strands Decider 的策略则是降维打击。它基于 Gemma 4 E4B 模型，不再生成冗长的文本，而是直接输出各个标签的概率分布。这本质上将分类任务从生成式推理还原为了概率计算。对于企业内部这种具有明确目录的场景，模型只需要根据上下文给出的置信度打分，速度自然成倍提升，带宽压力也随之归零。
三向开关：工程的安全垫
这次迁移成功的核心，不在于选了哪个模型，而在于这套三向平滑切换机制。
工程团队在 AWS AppConfig 中埋了一个开关，支持三种运行模式：
- BEDROCK 模式.只运行 Claude Sonnet。
- DECIDER 模式.只运行 Strands Decider。
- DUAL 模式.两个模型并行运行。
在最终切换前，团队长时间在 DUAL 模式下观察两个模型的输出差异。如果 Sonnet 的准确率是基准，那么 Decider 只要在分歧点上表现出色，就可以被信任。这种影子运行策略，消除了盲目上线新模型带来的业务风险。这比所谓的评测集跑分要诚实得多。
现实的边界与代价
当然，决策模型并非银弹。亚马逊工程师也明确指出了一些隐形成本：
- 数据预处理的苦力活.为了适应 Strands Decider 较小的上下文窗口，团队必须对长工单进行截断，剔除旧评论。这意味着为了省钱，你需要额外投入工程资源进行数据清洗。
- 工程细节的敏感性.实验中发现，输入 JSON 的键值顺序居然会影响模型输出，偏移量高达 0.19。如果不进行强制排序，模型就像一个心情不定的算命先生。
- 适用边界.如果你的分类标签每周都在变，或者你需要生成长篇大论的分析报告，那么这种路径反而会把你困住。
- 提醒.这并非模型能力的进化，而是架构选择的范式转移。如果你的任务是固定分类，不要试图用通用模型覆盖一切，那是在为不必要的推理能力买单。
在 AI 技术狂飙的今天，我们很容易陷入模型越大越好的叙事陷阱。但亚马逊的这次实验提醒我们，企业的核心竞争力有时不来自于模型参数的大小，而来自于如何把那些昂贵的算力精准地砍掉。
“天下熙熙，皆为利来。”对于 AWS 而言，把百万美元级别的开销压到几万美元，远比在实验室里刷高百分之零点几的准确率更具商业意义。这就是工业级 AI 的落地逻辑。
【锐评】大模型看着更强，但用在错的地方反而更虚。能算概率的题，别非要让模型写作文。