當前，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 的核心理念是：如果我們想真正優化搜索效果，不應讓生成器被訓練，否則會混淆「搜索變好」與「語言模型變強」帶來的增益。凍結生成器不僅提升了訓練效率（節省大模型微調成本），也便于模型遷移到不同任務與生成器，真正做到「搜索能力即插即用」。