Amazon SageMaker 搜索代理通过多轮 RL 获得提升，但一项基准测试表现下滑
Amazon 表示，其 Amazon SageMaker 搜索代理经过单个训练 epoch 后，在一项基准测试中的检索质量提升了 23.7%。经过微调的 Qwen3.6-27B 代理也将该测试中的失败率从 22.89% 降至 0.68%。不过，它并未在所有评估中都有所提升。
这种喜忧参半的结果，比满分成绩更值得关注。AWS 正在测试：企业能否训练较小的模型来驾驭自身搜索工具，而非反复提示前沿模型。若能成功，部分代理竞争将从模型规模转向针对特定环境的训练。
这项实验也暴露了该论点的局限。AWS 将调优模型与自家的未调优基础模型进行比较，而非与当前的前沿模型比较。其基准测试衡量的是受控环境内的检索行为，而非真实企业部署中的准确性、延迟和运营成本。
AWS 为多轮代理训练提供了具体数据
关键变化并非 SageMaker 可以微调模型，而是 AWS 在完整搜索轨迹中评估了一个代理。
AWS 于 2026 年 10 月 2 日发布了这项实验，距离 SageMaker AI 多轮强化学习推出已有数月。该公司利用这项服务，为企业式检索定制了一个 Qwen3.6-27B 模型。
该代理可使用两种搜索方式。词法检索方法 BM25 通过精确术语和词频模式来查找文档。向量搜索则将查询和文档转换为数值表示，有助于匹配采用不同措辞表达的概念。
在这些工具之间做选择只是任务的一部分。代理还必须改写较弱的查询、检查检索到的材料、判断是否值得进行下一次搜索，并在耗尽限制之前停止。每一项选择都会改变下一步可用的上下文。
这种依赖关系正是 AWS 使用多轮强化学习（MTRL）的原因。该技术会对一系列操作中的行为进行评分，而不是将每次模型响应视为孤立事件。SageMaker 的 MTRL documentation 将其目标描述为最大化整个序列中的累积奖励。
在这项实验中，奖励指标为 nDCG@10。排名第 10 位的归一化折损累计增益衡量相关文档是否出现在前十条结果的靠前位置。分数为 1 表示理想排序，零则表示系统未检索到相关文档。
AWS 在代理完成搜索轨迹后应用该评分。当代理超过轮次限制或单轮 token 预算时，系统还会赋予负一的奖励。这一惩罚使高效完成任务成为学习目标的一部分。
该公司汇集了来自 FRAMES、BRIGHT、Enterprise RAG、ESCI、Musique 和 MLQA 的训练材料。这些数据集涵盖多跳问题、重推理检索、企业文档、商品搜索和多语言理解。
Enterprise RAG 基准测试包含超过 50 万份合成企业文档和 500 个问题。AWS 从每个训练数据集中保留了 5% 用于验证。
测试采用四个独立数据集。WixQA 覆盖基于 Wix 文档的支持问题。Wands 评估商品搜索相关性，FreshStack 则聚焦近期开发者问题。BrowseComp-Plus 针对大约 10 万份经人工验证的网页文档，测试高难度研究查询。
这种分离很重要，因为它降低了评估仅奖励记忆化训练示例的可能性。它并不能消除所有形式的基准污染或分布重叠。不过，留出数据集使报告中的提升比单纯训练分数更有意义。
AWS 仅修改了三个公开设置的默认值。它运行了一个 epoch，使用 128 的全局批量大小，并允许 32 个并发 rollout。一次 rollout 是代理为完成多步骤任务而采样的一次尝试。
更广泛的服务负责管理轨迹收集、检查点和模型更新。它还通过托管 MLflow 记录奖励和轮次级追踪。根据原始的 search-agent experiment，训练和验证奖励在结束前趋于平缓之前均有所上升。
这正是标题背后的事件。AWS 现在有了一个公开案例，表明其托管 MTRL 服务改变了未知数据集上的检索排序和失败行为。更值得追问的是，这一结果会如何改变构建代理的默认策略。
前沿模型作为默认选择正面临压力
AWS 正在挑战这样一种假设：可靠性必须来自调用当前最强大的通用模型。
前沿模型通常比小型模型更能处理陌生工具，因为其通用推理和指令遵循能力更强。这一优势可以使其成为原型开发中更稳妥的起点，但也可能掩盖代理环境设计中的弱点。
更大的模型仍不会天然理解企业的搜索索引、过滤条件、权限、元数据或停止规则。团队通常通过提示词和工具 schema 描述这些细节，然后为模型在每项任务中解读这些指导付费。
AWS 提出了另一种分工方式。组织定义环境和成功指标，而强化学习将重复交互转化为模型行为。由此产生的模型更具专门性，也更少依赖大量运行时指令。
这种方法对“提示词加前沿模型”的路线形成压力。竞争从哪个模型知道得最多，转向哪个系统能学会正确的本地操作序列。对于企业搜索而言，即使底层问题多种多样，这些操作也可能较为狭窄。
例如，一个支持搜索代理可能需要识别错误代码、优先进行精确匹配、在结果稀少时扩大查询范围，并在找到权威操作流程后停止。通用模型可以推断这一策略，专用模型则可以通过训练将其编码。
经济性仍是一项主张，而非此次特定评估得出的结果。AWS 表示，较小的专用模型可以带来更低延迟和更低推理成本。不过，已发布表格中没有延迟测量、token 总量、部署成本或与前沿模型的直接对比。
该服务于 2026 年 6 月 3 日以无服务器 SageMaker 定制能力的形式正式可用。AWS 表示，该发布涵盖 rollout 编排、轨迹收集、训练、检查点管理和评估。其 launch announcement 还将 Qwen3.6-27B、Nova Lite 2.0、GPT-OSS-20B 和 Gemma-4-31B-it 列为支持的模型和区域。
无服务器训练降低了基础设施门槛，但并未消除应用层面的工作。团队仍需要可调用的代理环境、具有代表性的任务、可靠的真实标签，以及能反映真实成功的奖励机制。选择不当的奖励可能会让模型优化分数，却错失业务目标。
这一要求有利于拥有可衡量工作流的组织。搜索质量很适合这一模式，因为团队可以标注相关文档并计算排序指标。客户支持、代码执行和结构化运营同样能够产生可验证的结果。
开放式研究则更困难。一个看似合理的答案可能并不完整、缺乏支持，或基于误导性来源。单一的终局分数可能无法捕捉这些差别。
因此，实际压力落在两类群体身上。模型提供商必须证明，对于重复且边界明确的任务，为什么更大的通用模型仍值得使用。企业 AI 团队则必须决定：自身工作负载是否足够稳定，足以证明训练专用策略是合理的。
对于构建可搜索内部系统的团队而言，这一决定始于数据质量，而非模型选择。可靠的 engineering knowledge base 仍需要最新文档、明确的所有权和可追溯的来源。训练无法恢复检索层中原本不存在的信息。
Amazon SageMaker 搜索代理如何学习完整轨迹
这一机制之所以有效，是因为 SageMaker 会奖励最终搜索结果，同时保留产生该结果的决策链。
监督微调会让模型模仿示例。对于多轮搜索代理而言，这些示例必须展示完整且高质量的轨迹。专家需要演示有效查询、合理的工具选择、证据检查、从弱结果中恢复，以及恰当的停止时机。
这类示范的制作成本很高，而且具有环境特异性。为某个文档索引创建的轨迹，可能不适用于拥有不同元数据、检索工具或访问控制的另一套系统。
单轮强化学习避免了部分示范成本，但它带来了另一种不匹配。一次只对一个输出评分，无法充分捕捉那些价值要在数轮之后才显现的决策。
一个宽泛的向量查询起初可能看起来没有成效，但其结果可能揭示一个精确的产品标识符，进而使下一次 BM25 查询取得成功。若独立惩罚第一个操作，便会忽略它对完整搜索的贡献。
MTRL 保留了这种关系。代理与环境交互，接收搜索结果，更新上下文，并选择下一项操作。SageMaker 收集由此产生的轨迹，并利用最终奖励来调整这些决策背后的策略。
AWS 的奖励设计结合了检索质量与明确的失败规避。nDCG@10 衡量最终文档集合的排序，而负向奖励则抑制超过允许轮次或 token 限制的轨迹。
这种组合似乎是最大可靠性结果的核心。在 BrowseComp-Plus 上，基础代理在 830 个问题中的失败率为 22.89%。微调版本的失败率则为 0.68%。
这一结果表明，模型学习到的不仅是如何检索出更好的排序，也包括何时完成任务。该基准测试中的平均轮次也从 7.0 降至 6.3。更少的轮次可能意味着更高效率，但已发布的评估并未将这种减少换算为延迟或成本。
同样的模式并未在所有场景中出现。在 WixQA 上，平均轮次从 4.3 上升至 4.5。Wands 从 2.2 增至 2.9。FreshStack 则从 3.1 降至 2.8。
这些差异表明，“更少轮次”并非衡量更优代理行为的普遍标准。额外一次查询可能改善证据覆盖范围，而过早停止则可能产生较弱的回答。正确的衡量方式必须将轮次数与检索质量及任务完成情况联系起来。
SageMaker 异步运行 rollout 和梯度更新。有界离策略陈旧性限制训练示例与当前正在优化的模型版本之间可能产生的偏离程度。该平台还支持 PPO、CISPO 和重要性采样损失，并提供多种优势估计器。
AWS 在这项实验中将这些选项保留为默认设置。这让配置更容易复现，但也掩盖了究竟是哪些算法选择带来了性能提升。用户获得的是一条托管路径，而不是对每个训练组件的详细消融分析。
这一底层方向并不只得到这篇博客文章的支持。由 Amazon 和学术机构研究人员撰写、经过同行评审的 WebAgent-R1 论文，通过端到端的多轮交互训练智能体。
在 WebArena-Lite 上，这项工作将 Qwen2.5-3B 的任务成功率从 6.1% 提升至 33.9%，将 Llama-3.1-8B 从 8.5% 提升至 44.8%。作者还发现，行为克隆预热会影响结果，这使得“仅靠强化学习即可解决智能体训练”的说法更加复杂。
这项 SageMaker 实验比 WebAgent-R1 更聚焦。它关注文档检索，而非跨不断变化的网站执行操作。但两者都指向同一种机制：当训练保留动作、观察和延迟结果之间的交互关系时，模型会得到改进。
更高的可靠性并不意味着检索能力全面提升
最有力的证据支持的是专业化能力的提升，而非“多轮 RL 会让所有搜索任务都变得更好”这一笼统论断。
经过调优的模型在四个留出基准中的三个上提升了 nDCG@10。BrowseComp-Plus 从 0.5136 升至 0.6354，相对提升 23.7%。WixQA 从 0.5725 提升至 0.6781，增幅为 18.4%。
Wands 从 0.5762 升至 0.6112，提升 6%。FreshStack 则反向变化，从 0.4112 微降至 0.4089。
这一下滑幅度不大，但在分析上很重要。它意味着该实验无法支持一种简单的“训练会让搜索变得更好”的结论。模型学到的策略在不同领域之间迁移得并不均衡。
FreshStack 包含源自 Stack Overflow 和技术文档的近期开发者问题。这些查询可能依赖特定版本的术语和快速变化的事实。在更广泛的检索数据集上训练的策略，未必能够改善这一分布。
AWS 未发布解释该回归的误差分析。目前尚不清楚问题是否源于工具选择、查询改写、过时的源材料、奖励对齐，或是普通的评估波动。
四项测试的规模也存在显著差异：包括 147 个 Wands 问题、400 个 WixQA 问题、672 个 FreshStack 问题和 830 个 BrowseComp-Plus 问题。AWS 没有报告置信区间或统计显著性。
这一缺失并不意味着测量结果无效，但限制了读者对较小差异进行泛化的信心，尤其是 Wands 的 6% 提升以及 FreshStack 的轻微下降。
评估还通过将失败任务的 nDCG@10 计为零，把任务失败与检索质量结合起来。这种处理方式是合理的，因为失败的智能体无法产生有用的排序输出。不过，这意味着 BrowseComp-Plus 分数提升的一部分来自于避免失败。
这一差别对买家很重要。即便成功搜索的文档排序相近，一个不再频繁崩溃的系统显然更有用。然而，可靠性的提升和相关性的提升描述的是不同的工程成果。
没有独立第三方复现过这些确切的 SageMaker 结果。AWS 设计了配置、运行了评估并发布了分析。该报告提供了详细的基准数值，但没有发布完成审计所需的全部训练工件或轨迹。
此外，实验也没有与监督微调、提示驱动的前沿模型，或其他托管 MTRL 平台进行比较。基础 Qwen3.6-27B 智能体是唯一的直接基线。因此，AWS 关于达到前沿级可靠性的更广泛主张在此尚未得到验证。
相关的 Amazon 研究为这一总体方法提供了更多证据，但并非独立确认。在另一组实验中，Amazon 研究人员报告称，强化学习将一个 Qwen2.5-32B 个人助理智能体的任务完成率从 39.20% 提升至 72%。
同一项智能体定制研究还报告了较小检索模型在 Natural Questions 和 Musique 上的提升。这些结果增强了环境交互能够改进智能体的论据，但它们仍来自 Amazon 关联研究，且采用了不同的模型、数据和任务。
安全与治理带来了另一层不确定性。在训练期间，智能体会反复调用真实或模拟工具。隔离不充分的环境可能暴露敏感数据、触发非预期操作，或奖励在生产环境中不可接受的捷径。
搜索系统本身也会变化。文档不断新增，排序服务持续更新，工具 schema 也会演进。即便模型检查点保持不变，为某一环境调优的策略也可能在这些变化后失去准确性。
组织将需要针对完整智能体系统进行回归测试。仅评估模型，无法发现由修改后的索引、权限规则或工具响应带来的所有故障。
因此，现有证据支持的是一个有边界的结论：多轮 RL 提升了该智能体在 AWS 评估中的可靠性和大多数检索分数。它并未证明普适迁移能力、与前沿模型等效，或必然节省成本。
智能体竞争正转向环境与奖励机制
战略资产正变成能够判断智能体是否成功完成整项任务的训练环境。
基础模型依然重要，因为它们决定了初始 rollout 的质量。较弱的基础模型可能无法发现足够多的成功轨迹，供强化学习加以巩固。
AWS 自己的研究也指出了这一效应。能力更强的基础模型可以生成更优的候选行为，从而形成更强的训练信号。专业化并不会抹去通用模型能力的价值。
然而，单个模型并不能定义企业智能体。系统还包括工具、索引、权限、状态、任务限制和评估规则。MTRL 将这些外围组件纳入训练循环。
这一转变改变了企业建立可防御性能优势的方式。两个组织可以从同一个开放模型出发，却产出不同的智能体，因为它们的环境和奖励函数编码了不同的运营知识。
搜索是尤其适合作为验证场景的领域。相关性判断提供可衡量的反馈，检索到的文档也可以与已知答案比较。搜索还迫使智能体在精确匹配、语义检索、查询重构和停止行为之间取得平衡。
其他工作流的配合度较低。销售调研可能存在多种可接受的输出。调查可能发现基准中不存在但有效的证据。知识工作往往除了任务完成度之外，还重视新颖性、细微差别和溯源。
单一的终端奖励可能会过度压缩这些质量维度。团队可能需要复合评估，分别衡量证据质量、引用准确性、政策合规性和行动效率。
因此，基础设施竞争将不止于托管训练。供应商必须帮助客户构建安全环境、调试轨迹、比较检查点，并检测奖励投机。
SageMaker 的 MLflow 集成通过公开逐轮轨迹和奖励，满足了其中一部分需求。可恢复作业同样有所帮助，因为多轮 rollout 的耗时可能长于传统微调。AWS 表示，其默认作业时限为 24 小时，尽管用户可以调整该限制并从检查点恢复。
模型支持和区域可用性仍是限制因素。在实验进行时，Qwen3.6-27B 在美国西部俄勒冈区域支持 MTRL。有数据驻留要求或使用不受支持模型的公司，可能需要不同的部署方案。
无服务器接口也带来了平台依赖。AWS 管理 rollout 编排和优化细节，而自托管团队原本可以自行控制这些内容。这种取舍可以加快部署，但会让底层实验更困难。
开放研究仍在发展替代方案。WebAgent-R1 等框架公开了更多训练设计细节，包括并行 rollout 和上下文压缩。托管服务则将类似思路打包，服务于不希望运营分布式强化学习基础设施的组织。
最可能的划分并非绝对意义上的托管与开放之争。企业将依据工作负载敏感性、模型需求、工程能力，以及控制每个训练组件的价值作出选择。
AWS 的优势在于集成。团队可以连接通过多项 AWS 服务托管的智能体，经由 SageMaker 训练、检查轨迹，并将所得模型部署到 SageMaker 端点或 Amazon Bedrock。
其尚待解决的挑战是证明效果。买家需要证据表明，这条托管路径能够在他们自己的任务上带来可重复的提升，并且能在环境变化后保持稳定。
三个信号将检验 AWS 的小型智能体论点
下一阶段应通过外部复现、生产经济性和跨环境稳定性来评判。
第一个信号是独立复现。另一支团队需要使用已披露的数据集、可比的 Qwen3.6-27B 基线和相同的任务限制，复现检索收益。若能复现 BrowseComp-Plus 的可靠性结果，将增强 AWS 的核心主张。
复现实验应将排序收益与避免失败区分开来，同时纳入不确定性估计和重复运行。如果在这些控制条件下改进消失，当前结果就会显得更局限于 AWS 的评估配置。
第二个信号是与前沿模型进行直接的生产比较。团队应在相同工作负载上衡量答案质量、检索相关性、端到端延迟、消耗的 token 数和人工干预率。训练成本也应与推理行为一并纳入。
如果专业化模型能够匹配更大模型，同时在部署时使用更少资源，经济论据就会变得具体。若团队必须频繁再训练或维护复杂的奖励基础设施，一部分预期节省将转移到技术栈的其他环节。
第三个信号是环境变化后的表现。一个有价值的测试可以修改文档语料库、更新工具 schema，或引入新的搜索筛选器。评估者随后可以衡量智能体能否通过提示适应，还是需要再经历一个训练周期。
稳定的表现将支持 AWS 关于 MTRL 能够教授可迁移搜索行为的主张。急剧下降则表明，模型学到的是一种与原始环境高度绑定的狭窄接口策略。
开发者还应关注 FreshStack 的回归。未来实验需要解释，为什么一个帮助了三个数据集的策略却轻微伤害了这个数据集。有针对性的误差分析将揭示差异是否由时效性、技术词汇或查询策略造成。
企业买家并不需要在每项任务中都在前沿模型与专业化智能体之间二选一。一种务实的架构可以将常见、可衡量的搜索路由给调优模型，并将陌生工作升级交给更广泛的模型。
这种混合方法既保留了灵活性，也能检验专业化是否带来可靠的节省。它还降低了将单一策略强加于每一种信息需求的风险。
Amazon SageMaker 搜索智能体的结果让这一实验值得开展。它显示出失败次数的可衡量减少，以及在大多数留出测试上更好的排序表现。但它也留下了足够的不确定性，要求针对每个组织自己的文档和工作流进行评估。
对于考虑采用这一路径的团队而言，下一步不应是立即部署。应先构建一套具有代表性的测试集，精确定义何为失败，并将微调后的 agent 与现有最强基线进行比较。随后还要检验：这种改进能否经受新文档、工具变更以及棘手边缘案例的考验。
