UIUC开源s3:仅需少量样本,高效训练搜索智能体RAG

UIUC开源s3,一种高效训练搜索智能体RAG的RL范式。仅需2.4k样本,即可在问答任务中超越现有模型。

原文标题:搜索智能体RAG落地不佳?UIUC开源s3,仅需2.4k样本,训练快效果好

原文作者:机器之心

冷月清谈:

UIUC与Amazon提出的s3(Search-Select-Serve)是一种高效的RL训练范式,用于优化Agentic RAG。该方法通过Gain Beyond RAG (GBR)奖励函数,专注于提升搜索器对生成效果的实际贡献。s3解决了现有RL Agentic RAG方案中优化目标偏离、检索与生成耦合、评价标准不准确等问题。实验表明,仅使用2.4k训练样本,s3在多个领域问答任务中超越了数据规模更大的基线模型。s3通过冻结生成器、预筛除简单样本等方式提升训练效率,并采用Generation Accuracy(GenAcc)指标进行评估,保证了与人类判断的高度一致性。消融实验验证了s3框架中“从原始问题开始检索”和“文档选择”机制的关键作用。

怜星夜思:

1、s3方法中,冻结生成器有哪些优势?除了文章中提到的提升训练效率和便于模型迁移,还有没有其他潜在的好处或限制?
2、文章提到s3使用了Generation Accuracy(GenAcc)指标来评估生成效果,相比Exact Match,GenAcc的优势在哪里?在实际应用中,GenAcc可能会遇到哪些挑战?
3、s3方法在训练时预筛除掉了“naive RAG 就能答对”的样本,这个策略的目的是什么?在什么情况下,这种策略可能会带来负面影响?

原文内容


当前,Agentic RAG(Retrieval-Augmented Generation)正逐步成为大型语言模型访问外部知识的关键路径。但在真实实践中,搜索智能体的强化学习训练并未展现出预期的稳定优势。一方面,部分方法优化的目标与真实下游需求存在偏离,另一方面,搜索器与生成器间的耦合也影响了泛化与部署效率。


我们(UIUC & Amazon)提出的 s3(Search-Select-Serve)是一种训练效率极高、结构松耦合、生成效果导向的 RL 范式。该方法使用名为 Gain Beyond RAG (GBR的奖励函数,衡量搜索器是否真的为生成带来了有效提升。实验表明,s3 在使用仅 2.4k 训练样本的情况下,便在多个领域问答任务中超越了数据规模大百倍的强基线(如 Search-R1、DeepRetrieval)。



  • 论文标题:s3: You Don’t Need That Much Data to Train a Search Agent via RL

  • 论文链接:https://arxiv.org/pdf/2505.14146

  • 代码仓库:https://github.com/pat-jj/s3



研究动机


RAG 的发展轨迹:从静态检索到 Agentic 策略



我们将 RAG 系统的发展分为三阶段:


1.Classic RAG:使用固定 query、BM25 等 retriever,生成器对结果无反馈;


2.Pre-RL-Zero Active RAG:引入多轮 query 更新,如 IRCoT、Self-RAG 等,部分通过 prompt 引导 LLM 检索新信息。Self-RAG 进一步通过蒸馏大型模型的行为,训练小模型模拟多轮搜索行为;


3.RL-Zero 阶段:强化学习开始用于驱动检索行为,代表方法如:


  1. DeepRetrieval:以 Recall、NDCG 等搜索指标为优化目标,专注于检索器本身的能力;

  2. Search-R1:将检索与生成联合建模,以最终答案是否 Exact Match 作为强化信号,优化整合式的搜索 - 生成策略。


尽管 RL 方法在思路上更具主动性与交互性,但在实际落地中仍面临诸多挑战。


当前 RL-based Agentic RAG 落地表现不佳的原因


我们对当前 Agentic RAG 方案效果不稳定、训练难、迁移能力弱的原因,归纳为三点:


1. 优化目标偏离真实下游任务


Search-R1 等方法采用 Exact Match (EM) 作为主要奖励指标,即答案是否与参考答案字面一致。这一指标过于苛刻、对语义变体不敏感,在训练初期信号稀疏,容易导致模型优化答案 token 对齐而非搜索行为本身


例如,对于问题美国第 44 任总统是谁?


  • 回答Barack Obama:✅

  • 回答The 44th president was Barack Obama.:❌(EM=0)


这种不合理的信号会诱导模型在生成阶段做格式补偿,从而无法反映搜索策略本身是否有效


2. 检索与生成耦合,干扰搜索优化


将生成纳入训练目标(如 Search-R1),虽然可以提升整体答案准确率,但也会带来问题:


  • 无法判断性能提升究竟来自更好的搜索,还是更强的语言生成对齐能力

  • 对 LLM 参数依赖强,不利于模型迁移或集成;

  • 微调大模型成本高,限制了训练效率和模块替换的灵活性。



3. 现有评价标准无法准确衡量搜索贡献


EM、span match 等传统 QA 指标主要关注输出结果,与搜索质量关联有限。而 search-oriented 指标(如 Recall@K)虽可度量 retriever 性能,却无法体现这些信息是否真的被模型用好。这些偏差直接导致现有 RL Agentic RAG 方法在评估、训练和泛化上均存在瓶颈。


s3 - 专注搜索效果优化的 search agent RL 训练框架



s3 的出发点很简单


如果我们真正关心的是搜索提升了生成效果,那就应该只训练搜索器、冻结生成器,并以生成结果提升为奖励


这便是Gain Beyond RAG(GBR)的定义:



即:用 s3 搜索到的上下文喂给 Frozen Generator 之后的生成效果,相比初始的 top-k 检索结果是否更好。值得注意的是,s3 训练时始终初始化于相同的原始 query,从而能清晰对比 s3 检索对结果带来的真实增益


准确率(Acc)评估标准


我们采用了更语义友好的 Generation Accuracy(GenAcc指标。它结合了两种机制:


  1. Span Match:判断生成答案是否包含参考答案的任意 token span

  2. LLM Judge:由一个轻量 LLM 判断答案是否语义正确


两者只要任意一个通过,则视为正确。这一指标在人工对比中与人类判断一致率高达 96.4%,相比之下,EM 仅为 15.8%


训练与优化 - 仅需 2.4k 样本即可完成 ppo 训练:


我们采用 PPO 进行策略优化。为了提升训练效率:


  • 我们预筛除掉了naive RAG 就能答对的样本;

  • 将训练样本集中在需要真正检索的新信息的任务上;

  • Generator 完全冻结,训练代价完全集中在 Searcher。



s3 训练总时间只需 114 分钟(vs Search-R1 的 3780 分钟),数据也减少约 70 倍。


实验分析


General QA w/ RAG


实验一:通用 QA 任务,s3 优于 Search-R1 和 DeepRetrieval。



我们在六个通用数据集上评估了 Direct Inference、Naive RAG、IRCoT、DeepRetrieval、Search-o1、Search-R1 以及 s3 的性能。实验中,我们使用了不同的下游 LLM,包括 Qwen2.5-7B-Instruct,Qwen2.5-14B-Instruct 和 Claude-3-Haiku。


尽管 s3 仅使用了 2.4k 条 NQ+HotpotQA 训练数据(training source 和 Search-R1 一样),它在其中五个数据集上实现了最优表现,展现出显著的泛化能力。


Medical QA w/ RAG


实验二:医学 QA 任务,s3 展现惊人的跨领域能力



我们随后在五个医学领域的 QA 数据集上进一步评估了模型性能,测试使用了两个语料库:Wikipedia2018(与通用测试一致)和 MedCorp(ACL 2024)。结果显示,Search-R1 在其训练语料上表现良好,但在语料变更后显现出过拟合趋势;相比之下,s3 能稳定迁移至不同的数据集与语料库,凸显出其基于 searcher-only 优化策略的强泛化能力。


reward 优化曲线



图 5 展示了我们的 reward 曲线,可以看出 s3 在接近 10 个训练步骤(batch size 为 120)内便迅速收敛。这一现象支持两个推断:(1)预训练语言模型本身已具备一定的搜索能力,我们只需通过合理的方式激活这种能力;(2)在一定范围内,适当增加每轮搜索的文档数量和最大轮次数,有助于提升最终性能。


消融实验


在不同配置下,移除组件对性能的影响(平均准确率)。我们使用了三组设定进行对比,结果表明 s3 的设计在准确性与效率之间达到了最优平衡。


我们进一步通过消融实验,验证了 s3 框架中两个关键设计的必要性:


  • 从原始问题开始检索是方向正确的保障:我们发现,以用户原始问题作为第一轮检索的起点,有助于模型明确搜索目标、建立有效的检索路径。若不设置这一初始点,搜索策略往往偏离主题,导致性能显著下降。

  • 文档选择机制显著降低 token 消耗:该机制允许模型在每轮检索后主动筛选信息,从而避免将所有检索结果一股脑送入生成器。通过这一设计,s3 的输入 token 平均减少了 2.6 至 4.2 倍,不仅提升了效率,也减少了噪声干扰,对生成效果有正面作用。


总体来看,s3 设计中的起点初始化 + 动态选择是支撑其高效、强泛化性能的关键。即使在某些数据集上通过增加输入内容能获得短期增益,s3 原始结构在训练效率、推理速度与生成准确率上依然展现出更稳定的优势。


FAQ


Q1:为什么我们报告的 Search-R1 结果与原论文不一致?


A1:Search-R1 原文使用 Exact Match(EM)作为 reward 和评估指标,并对模型进行了针对性微调。将这种针对 EM 优化的模型,与其他 zero-shot 方法比较,略显不公平,也难以衡量搜索本身的效果。因此我们采用更语义友好的 Generation Accuracy(GenAcc),结合 span 匹配和 LLM 判断,与人类评估一致率达 96.4%。相比之下,EM 只能捕捉字面一致,反而容易误导模型优化方向。


Q2:s3 为什么不训练生成器?这样是否限制了模型性能?


A2:我们设计 s3 的核心理念是:如果我们想真正优化搜索效果,不应让生成器被训练,否则会混淆搜索变好语言模型变强带来的增益。冻结生成器不仅提升了训练效率(节省大模型微调成本),也便于模型迁移到不同任务与生成器,真正做到搜索能力即插即用


© THE END 

转载请联系本公众号获得授权

投稿或寻求报道:liyazhou@jiqizhixin.com

我觉得冻结生成器能让研究人员更专注于优化搜索策略本身,而不会被生成器的能力所干扰。相当于控制了一个变量,更容易评估搜索器的真实效果。而且,如果生成器是商业API,冻结也能避免额外的成本。但是,如果搜索器过于依赖特定的生成器特性,泛化能力可能会受限吧。

GenAcc的优势在于容错性更高,能够识别语义等价的答案。比如,“美国第44任总统”和“奥巴马”虽然字面上不完全匹配,但GenAcc可以判断为正确。挑战在于,LLM Judge的成本较高,大规模评估可能会比较耗费资源。另外,如何保证LLM Judge的公平性,避免偏见,也是一个需要考虑的问题。

就像考试前先刷掉送分题一样,s3是想把算力集中在更有价值的case上。避免模型在简单问题上浪费时间,提高训练效率。但是,如果过滤规则太严格,可能会误伤一些“看起来简单,但实际上需要复杂推理”的问题。导致模型在一些corner case上的表现不佳。

冻结生成器相当于在训练搜索器时做了一个“正交化”,保证了搜索器能力的纯粹性。好处是解耦了两个模块,方便独立升级和维护。但是,现实场景中,搜索和生成往往是相互影响的,完全解耦可能无法达到最优效果。也许可以考虑一些弱耦合的方式,比如在生成器中引入少量搜索器的反馈信息?

GenAcc更看重语义上的正确,而不是字面上的完全一致,这更符合人类的判断标准。Exact Match太死板了,稍微改动一下说法就判错,很不合理。不过,GenAcc依赖LLM Judge,这个Judge本身的标准是否稳定、可靠,也是个问题。万一Judge抽风了,评估结果可能就不准确了。

从机器学习的角度看,预筛除简单样本相当于对训练数据进行加权,提高困难样本的权重。这种做法的假设是,所有样本对模型的贡献不是均等的。但是,如果模型本身存在偏差,这种加权可能会放大偏差,导致模型在某些群体上的表现更差。因此,需要谨慎选择筛选策略。

谢邀,从理论角度分析,冻结生成器简化了优化目标,使得强化学习算法更容易收敛。这符合奥卡姆剃刀原则,在效果相近的情况下,选择更简单的模型。但是,如果生成器的能力存在瓶颈,可能会限制整体性能的上限。因此,选择合适的生成器也很重要。

我觉得这个策略是典型的hard negative mining思路,让模型更多地接触困难样本,从而提升模型的区分能力。但如果筛选标准不合理,可能会导致训练数据分布不均衡,影响模型的泛化能力。比如,只在某些特定领域的问题上表现良好,而在其他领域表现很差。

从信息检索的角度看,GenAcc尝试衡量生成答案的“相关性”,而Exact Match只关注“精确性”。相关性更符合用户的信息需求,但同时也引入了主观性。为了提高GenAcc的可靠性,可以采用多个LLM Judge进行投票,或者引入人工评估作为gold standard。