AWS在SageMaker AI上展示用多轮强化学习（MTRL）微调企业搜索智能体的方法，让模型在多轮交互中选择检索策略并以轨迹级奖励为目标，以提升检索质量与运行可靠性，同时强调训练环境、检索基础设施和验证机制的重要性。
AWS正在把强化学习引入企业搜索智能体的完整工作流程，而不只是优化某一次回答。AWS Machine Learning Blog近日介绍了一套基于 Amazon SageMaker AI 多轮强化学习（Multi-turn Reinforcement Learning，MTRL）的训练方案：让智能体在多轮交互中自行决定搜索方式、查询内容以及何时停止，并以最终检索结果的质量和任务可靠性作为主要学习目标。
这篇文章的直接主题并不是推出一个新的搜索产品，而是展示如何通过训练，让规模较小的模型学会在特定企业环境中使用搜索工具。AWS称，这种方式试图在前沿模型的可靠性与小模型的延迟、成本之间取得平衡。不过，文中数据来自AWS自己的技术实践和评估，不能直接视为适用于所有企业搜索任务的普遍性能保证。
从单次回答转向完整多轮轨迹
企业搜索智能体通常需要连续做出多个决定：先判断用户问题，再选择关键词检索或语义检索，读取结果后修改查询，最后决定是否已经获得足够证据。前一轮检索会影响后一轮的上下文，因此只对单次回答打分，可能无法准确反映整个任务是否完成。
AWS将这种差异与传统监督微调以及单轮强化学习区分开来。监督微调需要大量由专家编写的理想轨迹；单轮强化学习则容易把每次输出孤立起来。MTRL的做法是把一次完整的搜索过程视为一条轨迹，模型在连续交互中选择行动，最终奖励则反映整条轨迹带来的结果。
AWS在今年6月公布SageMaker AI多轮强化学习功能时表示，该能力可通过SageMaker Studio和SageMaker Python SDK使用，并作为模型定制功能的一部分提供。官方文档将其描述为一个让智能体观察环境、采取行动、接收奖励并继续进入下一状态的训练过程。相关功能说明见AWS关于SageMaker AI多轮强化学习的公告和官方开发者文档。
AWS示例：BM25与向量检索由智能体自行选择
在这次技术实践中，AWS使用Qwen3.6-27B作为基础模型，并把它微调为企业搜索智能体。智能体可调用两类工具：一类是基于关键词匹配的BM25检索，适合查找精确术语和标识符；另一类是向量检索，适合处理概念性或语义相近的问题。
训练环境部署在美国西部（俄勒冈）区域。AWS准备了多组训练和测试数据，覆盖多跳问答、需要复杂推理的检索、企业内部知识库、跨语言问答和商品搜索等场景。测试集包括FreshStack、WixQA、BrowseComp-Plus和Wands，规模从147个问题到830个问题不等。
训练时，AWS把nDCG@10作为主要奖励函数。该指标衡量排名靠前的10份文档与理想排序的接近程度，分数越高，意味着相关文档越可能出现在前列。如果智能体达到最大轮数或单轮令牌上限，系统会给予-1的奖励，以鼓励模型避免无休止地搜索。
训练配置本身相对简短。AWS示例只调整了三个关键参数：训练轮数为1，全球批量大小为128，并行轨迹采集数为32；算法、优势估计器以及其他训练选项则采用默认设置。AWS表示，SageMaker AI负责训练循环、轨迹采集、并行生成、检查点管理以及基础设施编排，开发者仍需提供智能体环境、工具接口和任务奖励。
这类“默认配置即可启动”的说法需要结合语境理解。AWS在另一篇关于MTRL训练最佳实践的文章中也强调，环境设计、外部评估、奖励函数和训练监控仍由使用者负责。也就是说，托管训练基础设施降低了工程门槛，但并没有自动解决企业任务如何定义、结果如何验证以及奖励是否会被模型钻空子等问题。
质量提升明显，但并非所有测试集都改善
AWS报告称，微调后的模型在四个留出测试基准中的三个取得了更高的nDCG@10分数。WixQA的分数从0.5725升至0.6781，AWS计算的增幅为18.4%；Wands从0.5762升至0.6112，增幅约6%；BrowseComp-Plus从0.5136升至0.6354，增幅为23.7%。FreshStack则从0.4112轻微下降至0.4089。
可靠性方面，AWS强调的变化更加明显。在BrowseComp-Plus上，基础Qwen3.6-27B的失败率为22.89%，微调后降至0.68%。平均交互轮数也从7.0降至6.3。WixQA的失败率从0.67%降至0.17%，平均轮数则从4.3略升至4.5；Wands的平均轮数从2.2升至2.9，但失败率维持为零。
这些数字说明，MTRL的收益不只体现在“找到了哪些文档”，也体现在能否在轮数和令牌预算内完成任务。但FreshStack的轻微回落提醒人们，某一组训练环境中的策略未必会在所有数据分布上同步提升。AWS没有在该文中提供独立第三方复现实验，因此这些结果应被视为AWS特定模型、工具和数据设置下的报告结果。
检索基础设施与训练数据同样重要
企业搜索智能体的表现，最终取决于模型、检索工具、数据质量和验证方式的共同作用。近期关于企业智能体训练的另一项研究也把重点放在失败轨迹和验证器上：ServiceNow介绍的AutoSynthData尝试从模型在企业环境中的失败中生成下一轮训练样本，并通过执行和状态验证检查数据是否有效。两者的共同点在于，训练目标不再只是让模型生成更像样的文本，而是让它在一个可验证的环境中完成任务。
检索层本身也在变得更加复杂。Cloudflare的AI Search GA发布显示，托管搜索正在把混合检索、向量索引、文档解析和面向智能体的接口组合在一起；而NVIDIA Nemotron 3 Embed的检索模型发布则把召回质量、代理效率和部署成本放在同一个工程问题中讨论。
这意味着，企业部署搜索智能体时，不能只看基础模型的参数规模或某一次问答的准确率。需要同时观察智能体是否选择了合适的检索工具、是否会在无效查询后及时调整、是否能停止在合理时机，以及检索结果是否真正支持最终答案。对于拥有权限边界、内部文档和审批流程的企业，还必须把访问控制、日志审计和数据隔离纳入训练环境，而不能只在上线后补充。
AWS的方案仍处于“官方实践”阶段
AWS Machine Learning Blog将这次实验定位为一份技术实践和部署示例。它展示了如何用SageMaker AI连接搜索工具、构造轨迹级奖励、运行训练并通过MLflow观察智能体的逐轮行为，同时给出了四个测试集上的对比结果。
但从研究证据看，仍有几个问题没有答案：训练后的模型能否迁移到不同企业的检索工具和权限体系，nDCG@10与最终回答的事实正确性之间有多强的对应关系，以及默认算法在更长、更复杂或更高风险的工作流中是否仍然稳定。AWS也没有在这篇文章中提供成本、令牌消耗与外部基线的完整对照。
因此，MTRL更准确的意义，是为企业智能体提供了一条把“多轮决策”纳入训练目标的工程路径。它可能减少小模型在搜索过程中的反复试错，并降低部分任务的运行成本；但能否真正转化为可靠的企业生产系统，仍取决于数据、工具、验证器和权限治理能否一起构成可信的训练环境。
来源：AWS：Fine-tune a search agent with multi-turn RL on Amazon SageMaker AI。AWS原文页面显示发布日期为2026年10月2日；原始新闻输入及AWS博客索引记录为2026年10月1日，本文保留这一日期差异，优先采用原文页面日期。