论文标题：s3:YouDon’tNeedThatMuchDatatoTrainaSearchAgentviaRL

代码仓库：

研究动机

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

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

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

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

当前RL-basedAgenticRAG落地表现不佳的原因

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

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

例如，对于问题「美国第44任总统是谁？」，

回答「BarackObama」：✅

回答「The44thpresidentwasBarackObama.」：❌（EM=0）

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

对LLM参数依赖强，不利于模型迁移或集成；

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

s3的出发点很简单：

这便是「GainBeyondRAG（GBR）」的定义：

准确率（Acc）评估标准

我们采用了更语义友好的GenerationAccuracy（GenAcc）指标。它结合了两种机制：

SpanMatch：判断生成答案是否包含参考答案的任意tokenspan

LLMJudge：由一个轻量LLM判断答案是否语义正确

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

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

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

我们预筛除掉了「naiveRAG就能答对」的样本；

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

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

s3训练总时间只需114分钟（vsSearch-R1的3780分钟），数据也减少约70倍。

实验分析

GeneralQAw/RAG

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

我们在六个通用数据集上评估了DirectInference、NaiveRAG、IRCoT、DeepRetrieval、Search-o1、Search-R1以及s3的性能。实验中，我们使用了不同的下游LLM，包括，和Claude-3-Haiku。

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

MedicalQAw/RAG

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

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

reward优化曲线

消融实验

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

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

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

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

FAQ

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

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