搜索相关-论文阅读
(2505) WebDancer: Towards Autonomous Information Seeking Agency
- paper, web-agent (webdancer,+webwalker)
- 提出数据构造+轨迹采样+SFT+RL四阶段方法,用于构建多步骤信息搜索web-agent。旨在解决复杂真实问题所需的信息获取和多步推理能力。
- WebDancer在GAIA和WebWalkerQA上性能出色,自主构建的数据质量比开源QA数据效果好。
❓问题背景
- 传统搜索引擎难以满足用户深层次、多步骤信息获取的需求。
- 但构建自主思考决策、多步挖掘推理的Agent存在挑战。
- 如理解复杂网页内容、多步决策和推理、适应动态网络环境、自主行动等。
- 高质量多步训练推理数据稀缺
📕核心方法
WebDancer四阶段框架
- 阶段1:浏览数据构建
- CrawlQA方法:模拟人类在知识网站上收集页面信息,利用GPT-4o构建问答对。
- E2HQA方法:由简单到复杂逐步合成问答对。
- 比如先选1个实体,搜索获取信息,再重新构造问题,把简单转换成复杂问题。
- 阶段2:轨迹采样
- 构建出高质量问答对后,需采样高质量轨迹来指导agent学习。
- 结合短思考(ReAct,GPT-4o)和长思考(QwQ-plus)2种策略。
- 长思考:后者逐步提供历史action和observation,让模型自主决定下一步动作。
- 阶段3:SFT冷启动
- 采用高质量轨迹进行微调,适应任务格式和环境。
- 阶段4:RL
- 增强模型在多步、多工具使用场景下的能力。
- DAPO算法:通过动态采样,有效利用SFT未充分利用的问答对,提高效率和鲁棒性。

✍️实验设置
- 模型:Qwen2.5-7B/32B、QwQ-32B
- 算法:SFT、RL(DAPO),verl框架
- 机器:32节点,单节点8块H20(96GB)
🍑关键结果
- 性能显著提升:在GAIA和WebWalkerQA上,WebDancer获得显著提升,证明训练范式有效。
- 数据质量至关重要: 使用CrawlQA和E2HQA方法严格过滤的数据,远优于开源QA数据。
- RL提升了推理和行为的复杂性:RL能使Agent学习更长、更连贯的轨迹,自主决定中间步骤和子目标。
⛳未来方向
- 多工具集成:引入复杂工具,比如浏览器建模、python等;执行更复杂任务,如浏览网页、数据抓去、API调用等。
- 任务泛化:目前以短答案检索为主,后期扩展至开放域常温表写作任务。
(2505) MASKSEARCH: A Universal Pre-Training Framework to Enhance Agentic Search Capability
- paper, code, 提升智能体搜索能力的新框架
- 针对搜索场景,提出MaskSearch框架,使用检索增强掩码预测(RAMP)任务,在预训练阶段使用搜索工具来做完形填空任务,赋予模型通用搜索推理能力。
- 经过预训练的模型,在下游任务中,具有更好效果和泛化性。
❓问题背景
- Agent泛化能力差:现有Agent方法大都依赖特定任务的数据。
- 传统RAG的局限:检索和生成相对分离限制了模型多步骤、主动信息探索的能力。
- 缺乏通用预训练方法:缺乏从根本上教会模型如何使用搜索和推理的范式,而不仅仅是解决某个具体问题。
📕核心方法
MaskSearch框架:RAMP预训练任务 + 完善的训练策略。
- 预训练任务:检索增强掩码预测(RAMP)
- 把文本中的关键信息(实体/日期/数字等)替换成
[mask]
标签 - 使用外部搜索工具来查找信息,不能仅依赖上下文
- 把文本中的关键信息(实体/日期/数字等)替换成
- 两阶段训练范式
- 第一阶段(预训练):在海量数据上执行RAMP任务,学习通用搜索和推理能力
- SFT:多智能体生成数据,Planner(分解任务,生成查询) + Observer(分析搜索结果) + Rewiter(优化查询)
- RL:采用DAPO算法,优化模型的搜索策略。
- 奖励:格式奖励+答案奖励(token召回率或模型评分)。
- 课程学习:按mask数量,逐渐增加难度
- 第二阶段(下游微调):在具体任务(如HotpotQA)上进行微调,
- 第一阶段(预训练):在海量数据上执行RAMP任务,学习通用搜索和推理能力

✍️实验设置
- 模型:Qwen2.5-1.5B/3B/7B, LLaMA3等。
- RAMP任务:
- 维基百科数据源,构造10MCoT数据(14b tokens),QwenMax来过滤,
- 后250k、500k、1M数据
- 下游任务:
- 训练集:HotPotQA
- 评测集:HotPotQA、FanoutQA、Musique、2Wiki、Bamboogle、FreshQA
- Baseline:RAG-PE、Agent-PE、Distill Search-R1、Search-R1
- 评估指标:生成结果和标准答案直接的 Token-level Recall

🍑关键结果
- 效果好、有泛化:与Search-R1相比,域内任务3-5%召回率,域外任务提升10%,具有较好泛化性。
- 预训练是关键:RAMP预训练后的Qwen2.5-1.5B,下游任务平均分从59.55提升至65.27
- RL(预训练)+RL(微调)组合能取得更好效果。
⛳未来方向
- 扩展工具集:目前单一(仅搜索),未来使用多样化工具,应对复杂场景
- 探索更多应用场景:RAMP思想应用到代码生成、科学分析等其他任务。
(2505) ZeroSearch: Incentivize the Search Capability of LLMs without Searching
❓问题背景
- RAG存在问题:依赖复杂prompt或SFT数据,泛化性弱。
- RL和真实搜索引擎交互,虽然能提升效果,但面临问题
- 成本太高:训练需要调用上万次搜索API,成本高且难以scale
- 文章质量不可控:搜索引擎返回质量参差不齐,可能在训练过程中引入噪声和不稳定性
📕核心方法
提出ZeroSearch方法
- 核心功能:使用模拟搜索环境训练,就能激发LLM使用真实搜索引擎的能力
- 1)轻量SFT(
qwen-14b
):LLM模拟搜索引擎- 数据构建:在真实搜索环境,构建query-documents数据
- SFT训练:根据指令生成不同质量的搜索结果(噪音可控)
- 2)RL课程学习训练(
qwen-3b/7b
):Curriculum Rollout,由易到难,逐步学习推理- 初期:LLM搜索引擎生成高质量有用的文档,帮助模型快速学习基本搜索流程和任务格式
- 中期:逐步提高文档噪声增加难度,让模型学会搜索/筛选/辨别/整合信息,激发推理判断能力
- 后期:模型学会处理不同质量的文档

✍️实验设置
- 主模型:Qwen2.5-7B/3B,LLaMA-3.2-3B,
- 模拟搜索引擎模型:Qwen-2.5-14B-Instruct
- 训练数据:NQ、HotpotQA
- 评估数据:
- 单跳:NQ、TrivaQA、PopQA
- 多跳:HotptQA、Musique、Bamboogle
- 丰富的baseline
- Prompt方法:直接回答、CoT、标准RAG
- 高级RAG方法:RAgent、Search-O1
- RL微调方法:Search-R1 (使用真实搜索引擎进行训练, GoogleAPI)
🍑关键结果
- 训练使用LLM模拟搜索引擎,显著降低训练成本,且效果较好超过真实搜索训练
- 模拟引擎LLM越大,效果越好。7B 和谷歌搜索引擎相对,14B甚至能超越真实搜索。
- 课程学习对模型稳定学习很重要,方法泛化能力强。
⛳未来方向
- 基础设施成本优化:部署模拟引擎LLM需要GPU,未来让多个RL训练任务共享一个模拟LLM
- 把LLM作为更广泛的模拟器:模拟更复杂、更多样的环境,促进安全/低成本的agent训练。
(2505) O²-Searcher: A Reinforcement Learning Agent for Open-Domain Open-Ended Question Answering
❓问题背景
- LLM自身限制:依赖于自身预训练内容,具有知识过期、专业不足等问题。
- 开放式问答挑战
- 多角度探索:通常需要多个角度来审查主题
- 多源信息综合:答案来自多个来源的整合
- 自适应搜索策略:搜索策略不是固定的,而是自适应和迭代的
- 质量评估
封闭式问答
vs 开放式问答

📕核心方法
O2-Searcher由多个组件组成,实现有效知识获取和答案生成。
- 搜索环境:模拟真实世界的搜索引擎
- Agent架构:和DeepSearcher/R1-Searcher++ 有点类似,
<think>
,<search><query>
,<answer>
- 状态评估:当前知识是否足够回答问题
- 行动选择:搜索 或 回答
- 搜索内容:制定搜索query 查询结果
- 信息提取:搜索结果和现有知识进行整合
- RL 训练
- 算法:GRPO
- 奖励设置
- 封闭式问题:事实奖励;
- 开放式问题:格式(markdown) + 多样性(语义) + 事实奖励(f1)


✍️实验设置
- 任务:构建了O2-QA Benchmark,300个不同领域的问题
- 如:开发自动驾驶汽车的主要挑战是什么?
- 训练数据:NQ(单跳)、HotpotQA(多跳)
- 算法:GRPO
- 模型:Qwen2.5-3B-Instruct
- 评估:开放式和封闭式QA
🍑关键结果
- 提出O2-QA Bench,O2-Searcher比其他RL/SFT/Prompt方法更好,在真实搜索环境中更稳健
- 在封闭式QA Bench上,取得了最先进的结果,包括HotpotQA,2Wiki,MusiQue,Bamboogle
⛳未来方向
- 更大模型,更复杂推理,领域扩展等
(2505) WebThinker: Empowering Large Reasoning Models with Deep Research Capability
- WebThinker Paper,code
- 基于DeepWebExploer(搜索->浏览网页->提取信息)的WebThinker,能回答搜索复杂问题和撰写报告,构建偏好对做DPO训练。
- 在搜索部分,和其他工作差不多,有点像DeepResercher,对信息存储一个Memory。
❓问题背景
- LLM知识受限于自身,无法覆盖专有小众问题。
- 当前方法(RAG)存在问题(特别是需要多步推理、整合不同来源信息场景时):
- 标准RAG:只是浅层搜索、无法跟踪和深入搜索
- 预定义RAG:多次检索,不够自主灵活
📕核心方法
WebThinker框架
- 功能:可在连续思考过程中、自主调用工具
- 两种模式
- 问题解决模式:回答复杂问题,多步推理和网络搜索交错结合。
- 报告生成模式:自主计划研究写报告
- 研究规划 -> 逐节写作 -> 检查和编辑
- Deep Web Explorer
- 搜索信息:使用搜索引擎
- 浏览网页:可以点击链接、按钮来浏览网站
- 提取和存储信息:类似记忆库,存储网页信息,模型可以参考和使用。
- 训练方法:生成使用轨迹的traj,创建偏好对,DPO训练

✍️实验设置
- 算法:DPO
- 模型:QwQ-32B
- 评测集:
- 基准测试:GPQA、GAIA、WebWalker、HLE
- 科学报告:Scientfic Report Generation
🍑关键结果
- WebThinker 效果优于 QwQ、RAG-QwQ、Search-o1,未对比R1-Searcher等工作😞。
- 深度搜索有效果(链接)、报告生成组件有效果

⛳未来方向
- 多模态推理
- 工具改进
- GUI Web探索:复杂界面交互等
- 研究代理
(2505) SimpleDeepSearcher: Deep Information Seeking via Web-Powered Reasoning Trajectory Synthesis
- SimpleDeepSeacher Paper, SimpleDeepSearcher Code。
R1-Searcher团队的工作
- 核心是精心构建数据做SFT,验证成本比RL低,效果比标准RAG好。
❓问题背景
- RAG通常是单步检索,不满足多跳推理的复杂查询。
- DeepSearch存在挑战
- 高质量数据少:多步推理-搜索的高质轨迹数据很难获得
- 真实搜索效果差:模拟环境和真实搜索环境分布不一致,真实网络搜索具有动态性
- RL计算开销大:很多实际应用不切实际🤔❓
📕核心方法
- 核心:数据工程+SFT微调
- 核心框架:推理 -> 搜索 -> 总结 -> 回答
- 同人类思路一致,分析需要哪些信息,一直搜索循环,直到信息足够。
- 基于此框架,来收集训练数据。
- 数据工程方法
- 多样性采样:利用现有问答数据集
- 真实环境模拟:真实api,反应最新内容
- 多维度质量管理:确保高质量训练数据。维度包括格式/推理长度/问题难度/搜索有效性等。

✍️实验设置
- 训练数据:871个精心构建的样本
- 模型:Qwen-7B,Qwen-32B,DDQ-32B, QwQ-32B
- 算法:SFT
- 评估数据:2Wiki、MusiQue、Bamboogle、Frames、GAIA
🍑关键结果
- SFT 比 RL所需的计算资源少、训练更稳定
- 效果比标准RAG、Search-o1效果好,在Qwen-7B比DeepResearcher好。
(2504) DeepResearcher: Scaling Deep Research via Reinforcement Learning in Real-world Environments
❓问题背景
LLM+搜索很有潜力,但当前方法(Prompt/RAG)有限,创建强大可靠的Agent仍具有挑战。
- Prompt:效果不好、复杂场景很难做。
- RAG:在受控环境运行(预定义的文档),虽稳定,但对于真实世界信息的动态性、不可预测性,仍具有挑战。
📕核心方法
DeepResearcher是一个Agent框架,主要应对真实搜索的复杂性。
整体流程
- 用户提出问题
- 思考, DeepResearcher 开始
<think>
,判断是否需要搜索 - 搜索,调用网页搜索工具
<web_search_tool>
,得到搜索结果标题
、url
、摘要
,前k个。 - 浏览,调用web浏览agent
web browser agent
,为每个query维护1个短期记忆库,根据query、短期记忆、搜索结果,来行动:- 继续阅读还是停止:继续看或停止
- 更新短期记忆:如果有相关信息,则加到短期记忆中
- 信息汇总:决定停止时,做信息汇总
- 再次思考,DeepReseacher
<think>
,判断信息是否足够❓- 足够:回答
- 不足:重复搜索、浏览 过程。
- 回答,如果信息足够,生成答案。
<answer>
奖励设置
主要是f1
,

✍️实验设置
- 模型:Qwen-2.5-7B-Instruct
- 训练数据
- 单跳:NQ、TriviaQA
- 多跳:HotpotQA、2WikiMultiHopQA
- 2阶段过滤:排除时间敏感/主观/有害内容,排除模型已经知道答案的内容
- 算法:VeRL框架
- 设置:bs=256,16 rollouts,单rollout 最多10次工具调用,mini-bs=4096
🍑关键结果
- 性能优越:在TQ、HotpotQA、2Wiki、Musique、Bamboogle、PopQA上评测。
- 比Prompt高28.9pt,比RAG的RL Agent高7.2pt
- 涌现认知行为:复杂环境RL

实验细节
prompt示例:
<|im_start|>system
## Background information
* Today is 2025-06-10
* You are Deep AI Research Assistant
The question I give you is a complex question that requires a *deep research* to answer.
I will provide you with two tools to help you answer the question:
* A web search tool to help you perform google search.
* A webpage browsing tool to help you get new page content.
You don't have to answer the question now, but you should first think about the research plan or what to search next.
Your output format should be one of the following two formats:
<think>
YOUR THINKING PROCESS
</think>
<answer>
YOUR ANSWER AFTER GETTING ENOUGH INFORMATION
</answer>
or
<think>
YOUR THINKING PROCESS
</think>
<tool_call>
YOUR TOOL CALL WITH CORRECT FORMAT
</tool_call>
You should always follow the above two formats strictly.
Only output the final answer (in words, numbers or phrase) inside the <answer></answer> tag, without any explanations or extra information. If this is a yes-or-no question, you should only answer yes or no.
# Tools
You may call one or more functions to assist with the user query.
You are provided with function signatures within <tools></tools> XML tags:
<tools>
{"type": "function", "function": {"name": "web_search", "description": "Search the web for relevant information from google. You should use this tool if the historical page content is not enough to answer the question. Or last search result is not relevant to the question.", "parameters": {"type": "object", "properties": {"query": {"type": "array", "items": {"type": "string", "description": "The query to search, which helps answer the question"}, "description": "The queries to search"}}, "required": ["query"], "minItems": 1, "uniqueItems": true}}}
{"type": "function", "function": {"name": "browse_webpage", "description": "Browse the webpage and return the content that not appeared in the conversation history. You should use this tool if the last action is search and the search result maybe relevant to the question.", "parameters": {"type": "object", "properties": {"url_list": {"type": "array", "items": {"type": "string", "description": "The chosen url from the search result, do not use url that not appeared in the search result"}, "description": "The chosen urls from the search result."}}, "required": ["url_list"]}}}
</tools>
For each function call, return a json object with function name and arguments within <tool_call></tool_call> XML tags:
<tool_call>
{"name": <function-name>, "arguments": <args-json-object>}
</tool_call><|im_end|>
<|im_start|>user
Where was the director of film The Feature born?<|im_end|>
<|im_start|>assistant
<think>
(2503) ReSearch: Learning to Reason with Search for LLMs via Reinforcement Learning
- ReSearch paper
- 引入搜索工具,Reward包括答案f1和格式,使用Musique作为训练数据,在域内外都有效果提升。
- 思路和R1-Searcher、Search-R1一致😞。
❓问题背景
- LLM引入外部知识时,现有多步RAG方法主要靠prompt或sft方法来指导检索过程,依赖大量人力且难以扩展。
📕核心方法
提出ReSearch框架
- 标签框架:
<think>
、<search>
、<result>
- 奖励设置:答案奖励(f1)、格式奖励。

✍️实验设置
- 模型:Qwen2.5-7B/32B Base/Instruct
- 算法:GRPO/PPO
- 训练数据(in domain):Musique (多跳问答)
- 评测数据(out domain):HotPotQA、2WikiMultiHopQA、Bamboogle
- 评估方法:Exact Match、LLM-as-Judge(gpt-4o-mini)
🍑关键结果
- ReSearch对EM/LJ评估方式,都提升显著😊。
- Ins模型进行训练,可进一步提高ReSearch性能😐。
- Research泛化性好,可推广到其他问题及Bench 😘;与R1-Searcher、Search-R1类似😞。

(2503) Search-R1: Training LLMs to Reason and Leverage Search Engines with Reinforcement Learning
- Search-R1-paper , 知乎-Search-R1, code
- Search-R1为1阶段RL,引入搜索工具,支持多轮搜索,Reward仅靠答案正确性。
- 在域内外有26%的平均提升。许多后续工作基于此开发。
❓问题背景
- LLM在获取新信息、特定知识存在挑战。
- 现有RAG方法在多轮搜索、检索质量方面,存在局限性。
📕核心方法
提出Search-R1
,思路和R1-Searcher
一致,不过为1阶段RL
- 集成搜索引擎:LLM可内部推理或使用搜索。
- 多轮搜索支持:
<search>
、<information>
、<answer>
- 奖励:仅看最终答案是否正确,如Exact Match指标。

✍️实验配置
- 模型:Qwen2.5-3B/7B,LLaMA3.2-3B,base及instruct版本
- 训练数据:NQ(一般问答)、HotPotQA (多跳问答)
- 评估数据:
- 域内:NQ、HotpotQA
- 域外:2WikiMultiHopQA、Musique、Bambgoogle
- 评估指标:EM
🍑关键结果
- Search-R1 实现26%的平均改进(Qwen7B, 域内外)。
(2505) R1-Searcher++: Incentivizing Dynamic Knowledge Acquisition in Large Language Models
❓问题背景
- LLM限制:依赖自身知识(幻觉/过时)
- RAG 问题:
- 计算成本高:过度依赖外部搜索结果(即使自身知识能回答),执行过多检索
- 泛化性差:依赖记住的解决方案
📕核心方法
R1-Searcher++
- 核心:智能决定何时使用内部知识 或 寻求外部信息。
- 内部利用:利用已有知识直接回答,
<in>
标记 - 外部搜索:内部不确定时进行搜索,
<ex>
标记
- 内部利用:利用已有知识直接回答,
- 两阶段训练策略
- SFT冷启动:精心挑选数据,mask文档内容,强制格式
- RL优化:Reinforce++提高效率,动态决策何时内答或使用工具,持续优化
- Reward:答案(Cover EM) + 格式 +
:群体奖励机制,鼓励减少外部搜索依赖

✍️实验设置
- 任务:多跳问答
- 模型:Qwen2.5-7B
- 算法:Reinforce++
- 评测:HotPotQA、2Wiki、Bamboogle、Musique
🍑关键结果
- 多跳QA效果有提升(+4.3%),有较好OOD泛化性,问答性能稳健
- 保证效果且降低了检索次数:与R1-Searcher、Search-r1相比减少30%、52.9%
⛳未来方向
- 扩展到更大模型
- 领域适配
- 多模态扩展
(2503) R1-Searcher: Incentivizing the Search Capability in LLMs via Reinforcement Learning
- R1-Searcher 论文,知乎论文分享-R1-Searcher
- 搜索问答场景,R1-Searcher为检索和回答两阶段RL方法,让LLM学会自主调用搜索工具
- 使用HotPotQA/2wiki训练数据,在域内域外效果都较好,对在线搜索有较好适应性,GoogleAPI Bamgoogle达62.4%
❓问题背景
- LLM在需要外部知识的任务中存在不准确/幻觉等问题,尤其
时效性
,多知识点复杂查询
等。 - 传统方法有弊端
Prompt工程
难以泛化、依赖大量人工;SFT
难以泛化、是记住而非学会搜索,Test-time Scaling/MCTS
开销太大。
📕核心方法
提出R1-Searcher
框架,两阶段RL方法
,自主调用搜索工具,无需过程奖励或蒸馏,性能优于RAG。是
Stage-1:学会使用外部检索
检索奖励:n为工具使用次数,激发模型去搜索。
格式奖励:
<think></..>, <answer></..>, <begin_of_query></..>
Stage-2:根据检索结果准确回答
格式奖励:
答案奖励: 利用F1_score来作为答案奖励, PN表示预测答案字数,RN表示参考答案字数,IN表示交集字数。
训练期间检索到的文档会被mask,防止外部知识影响loss计算。
✍️实验配置
- 模型:Qwen2.5-7B-Base, LLama-3.1-8B
- 训练数据in-domain:HotPotQ (复杂推理), 2WikiMultiHopQA (多跳知识整合)。
- rollout次数和问题难度有关:
- 评估数据Out-of-domain:Musique、Bamboogle。
- 评估指标:
ACC_R
:关键词精准匹配,ACC_L
:GPT-4o-mini作为Judge。
🍑关键结果
- 域内和域外性能都较好
- HotpotQA Qwen达75%,base(GPT-4o, ReARTeR) 50.6%。2WikiMultiHopQA 达65%, base 54.5%
- Bamboogle 54.4%, base 54.4%。Musique 31.4%, base 30.2%
- 对在线搜索有强大适应性:GoogleAPI Bamboogle达 62.4%

👿局限性和不足
- 多轮交互(框架为单轮)、检索质量等。