在 Amazon SageMaker AI 上用知识蒸馏构建高效智能体

智能体任务不是一次模型调用，而是搜索、读取、修正、验证、决策的循环，每个步骤都要单独计费。在生产规模下，这种按任务累积的成本会侵蚀项目 ROI。用更小的模型可以降低延迟和托管成本，但质量通常下降，知识蒸馏正是用来弥补这一差距：把大“教师”模型的行为迁移到小“学生”模型。 文章聚焦序列级知识蒸馏（SeqKD），即用教师模型生成高质量回答，再以监督微调（SFT）训练学生模型。SeqKD 只需要教师的文本输出，不访问 logits，也不需要强化学习基础设施，因此即使教师是闭源或仅提供 API 的模型也能使用。相比 logit 蒸馏和 on-policy 方法，它处于成本最低、可移植性最强的一端；生成的回答会沉淀为数据集，可复用于训练或测试不同学生模型。 示例流程中，Amazon Bedrock 上的 GLM-5.3 开启推理、temperature 设为 1.0，作为 ShoppingBench 智能体在约 270 万件商品的目录中搜索、检查候选并给出推荐。ShoppingBench 发布 750 道合成购物问题，按产品、店铺、优惠券三类各 250 道，每道含隐藏标准答案与约束条件；数据被一次性划分为 426 道训练题和 324 道留出评估题。每个训练题采样两次教师轨迹，共 850 条，再由 ShoppingBench 自带评分器只保留成功解题的轨迹，这一拒绝采样步骤把能力尚不完美的教师转化为干净训练集。 每条成功轨迹包含用户请求、教师每一步的推理与工具调用（搜索、检查、推荐、终止）以及环境返回的观测。轨迹按步编码为 messages 列表，由学生模型自身的 chat template 渲染，使训练所见 token 与推理时一致；损失只落在 assistant 轮次上，让模型学习下一步推理与动作，而非预测环境观测。过滤后成功轨迹展开为约 2600 条训练行和 130 条验证行。数据按问题而非按行划分，留出约 5% 的整题以避免上下文泄漏；由于每行重复累积对话，需压缩占 token 最多的工具观测以控制长度。 学生模型 Qwen3.5-4B 通过 SageMaker AI 模型定制进行无服务器监督微调，随后在留出的 ShoppingBench 测试集上评估，并部署在 SageMaker AI 实时推理端点上运行工具循环。运行该示例需要具备 S3 读写与教师模型调用权限的 IAM 角色、支持的 AWS 区域、Python 3.12 以上内核与 SageMaker Python SDK v3，笔记本环境至少使用 ml.m5.4xlarge 实例。