WebThinker: Empowering Large Reasoning Models with Deep Research Capability

Thank you very much for your valuable and detailed review. We sincerely appreciate your constructive feedback and the opportunity to further clarify and strengthen our work. Please find our point-by-point responses below.

Q1: Please provide more details about the cost of training and evaluation tasks (time/dollar amount/token usage)?

We provide a breakdown of the estimated costs for training, inference, and evaluation, using H100 80G GPU hours as the unit. The actual dollar amount will depend on current market prices.

• Training Cost: This consists of two main components: data construction and model training.

  • (1) Data Construction: This is the most time-consuming phase. We utilize 4 nodes, each with 8 NVIDIA H100 80G GPUs, running vLLM to serve all required models. Data collection is performed over 3 rounds, corresponding to 3 DPO training iterations. Each round of data collection takes approximately 25 hours, totaling about 2400 H100 GPU hours.
  • (2) Model Training: For each DPO iteration, we use 1 node with 8 NVIDIA H100 80G GPUs. Each iteration takes about 18 hours, and with 3 rounds, this sums to roughly 432 H100 GPU hours.
  • (3) Total: The overall training cost is therefore about 2832 H100 GPU hours (equivalent to 3.7 days using 4 nodes of 8 GPUs).

• Inference Cost:

  • Inference is performed on 1 node with 8 NVIDIA H100 80G GPUs using vLLM. For GPQA, GAIA, and WebWalkerQA, each dataset requires about 1.2–2 hours; HLE takes about 5 hours; and Glaive report generation takes about 1 hour. The total inference time is approximately 10 hours.

• Evaluation Cost:

  • For evaluation, we use DeepSeek-R1-671B and GPT-4o. GPT-4o processes about 1.6 million tokens, while DeepSeek-R1-671B processes about 1.8 million tokens.

Q2: Did you conduct any experiments or analyses regarding the latency of answer generation?

Thank you for this important question. Computational overhead and efficiency are common challenges for all current deep research methods.

WebThinker is designed to balance performance improvements with efficiency, which is particularly challenging when leveraging large-scale web information. Specifically, we introduced a deep web explorer module to intelligently process and integrate external web content, returning only refined, relevant information rather than indiscriminately inserting all retrieved pages into the reasoning chain. This avoids excessively long contexts and maintains reasoning coherence and efficiency. A similar approach is used for report generation, where auxiliary LLMs are employed for writing, checking, and editing, rather than inserting the entire report into the main reasoning chain.

To empirically assess efficiency, we compared the inference time of different methods. All methods use 32B models as backbone and are evaluated on the GAIA benchmark with a single node of 8 NVIDIA H800 80G GPUs. The results are as follows:

These results show that WebThinker achieves significantly higher answer accuracy (48.5%) while keeping inference time and sequence length within the same order of magnitude as traditional RAG methods. Notably, the main reasoning chain in WebThinker is even shorter than in Standard and Iterative RAG, which directly stack retrieved content. In practical deployment, smaller auxiliary LLMs can be used to further reduce inference time and computational cost, as these models only handle simple sub-tasks.

Q3: What is the token limit for the language models in the tools?

We use the Qwen2.5 architecture (QwQ and Qwen2.5), which supports a maximum context length of 128k tokens.

However, in practice, the actual sequence lengths are much shorter than this limit. For specific average sequence lengths, please refer to the statistical table in the answer to Q2.

Q4: What are the differences to other web search implementations used for example in KGoT [1] or Hugging Face Agents [2]? I think [1] was inspired by [2] if I recall correctly.

Both KGoT and Hugging Face Agents are primarily based on the Surfer Agent from Hugging Face Agents for web search. The Surfer Agent provides core functionalities such as:

• Google search (via SerpAPI)
• Wikipedia page access
• Web navigation (including page scrolling, keyword search, URL access, etc.)

These systems employ an iterative tool-calling framework with a variety of tools, but integrating them coherently with the reasoning chain of the main model can be challenging.

In contrast, WebThinker is designed to tightly couple web exploration with the reasoning process, enabling model-driven, autonomous deep exploration. It can thoroughly analyze webpage content, identify useful information, and decide whether to continue searching or follow links for deeper information. WebThinker departs from predefined workflows and emphasizes autonomy. Nevertheless, the web exploration tools in KGoT and Hugging Face Agents are valuable references, and we plan to further adapt and cite these related works.

Q5: Document memory M: How does this knowledge base work?

In WebThinker, Document Memory M is a dynamic cumulative knowledge base used to store and manage all the web page information obtained through the Deep Web Explorer tool. Its working mechanism is as follows:

1. Storage Method

• Source: All web page content obtained through Deep Web Explorer search or link clicks (such as title, summary, full text summary, etc.) will be automatically stored in M.
• Update Timing: After each call to the search tool ($T_{exp}$), new web page information will be appended to M, forming an incremental knowledge base.

2. Retrieval and Use

• Retrieval Trigger: When the main model (Main LRM) calls the report writing tool (such as $T_{draft}$, $T_{edit}$), the assistant model (Assistant LLM) will retrieve Top-K relevant documents (based on semantic similarity) from M.
• Retrieval Basis: When retrieving, reference two parts:
  • Current Writing Instruction (such as chapter topic).
  • Historical Report Content (to avoid repetition or contradictions).

3. Role and Advantage

• Global Consistency: Ensure that information sources referenced in different chapters are unified, avoiding contradictions.
• Dynamic Expansion: With the deepening of search, the knowledge base continues to enrich, supporting deep writing in subsequent chapters.
• Efficient Access: Through Top-K retrieval, avoid injecting all webpage content into the main model context, reducing redundancy.

Through this design, Document Memory M acts as a bridge between dynamic information acquisition and high-quality report generation, balancing information coverage with computational efficiency.

Q6: Although the authors use some evaluation benchmarks that were not used during training, to what extent can these be considered out-of-distribution?

To better illustrate the contribution of each data component, we trained WebThinker on each individual dataset and evaluated performance across all benchmarks. The results are as follows:

The experimental results indicate:

1. Models trained on a single dataset perform best on their corresponding evaluation task. For example, training on WebWalkerQA yields 44.7% accuracy on the WebWalkerQA evaluation set, outperforming other single-dataset trainings on that benchmark.

2. Different types of training data contribute variably to generalization. For instance, models trained on SuperGPQA and WebWalkerQA also perform well on other tasks, suggesting these datasets contain more generalizable reasoning patterns.

3. Training on the combined dataset yields the best overall performance across all evaluation tasks, with average accuracy improvements of 3–6 percentage points. This demonstrates the complementary nature of different data types in enhancing overall model performance.

We hope these responses have addressed your concerns and clarified the design and evaluation of WebThinker. Thank you once again for your insightful feedback and suggestions. We look forward to further discussion.

Best regards,

The Authors of WebThinker

In addition to our responses to your Questions, we would also like to address your comments regarding Weaknesses and Paper Formatting Concerns.

Leak of Details on paper main body

Thank you very much for your careful reading and feedback. Due to space limitations in the current version, we have aimed to provide more detailed information about WebThinker through the appendix and code. We will do our best to supplement more details about WebThinker and make our descriptions clearer in the updated version.

Limited Novelty

We would like to further clarify the main contributions of this paper as follows:

1. We introduce WebThinker, a deep research agent that autonomously search, deeply explore web pages, and draft research reports, all within its thinking process. Unlike traditional predefined workflow, WebThinker enables the LRM itself to perform actions on its own while thinking, achieving end-to-end task execution in a single generation.

2. We propose a Deep Web Explorer that empowers LRMs with web search and navigation capabilities to deeply gather, traverse, and extract high-quality information from the web.

3. We introduce an Autonomous Think-Search-and-Draft strategy that enables real-time report writing during the thinking and searching process.

4. We develop RL-based training strategies that iteratively synthesize tool-usage preference data and apply online DPO training to enhance the LRM's tool utilization capabilities.

5. We demonstrate the effectiveness of WebThinker on complex reasoning tasks and scientific report generation tasks with both QwQ-based and DeepSeek-R1-based LRM backbones.

Link to the code repository

We sincerely apologize for the oversight regarding the appendix link. Thank you for kindly pointing this out. We have tried our best to make the link invalid. We appreciate your understanding and will be more attentive to such details in the future.

Typos in Figure 3, formats in references, and sentence expression

Thank you very much for your thorough review and thoughtful corrections. Your suggestions will significantly enhance the quality of our paper. In the revised version, we will ensure that all typos and reference formatting issues are properly addressed.

page 24: Is the duplication of the initial prompt part before the json part intentional?

Yes, this duplication is intentional. Because multiple deep research reports generated by different models are inserted in the middle—resulting in a very long context (up to ~50k tokens)—we include the evaluation instruction at both the beginning and the end. This approach helps the model better adhere to the instruction. Although current LLMs such as DeepSeek-R1 and GPT-4o can process such long contexts, it remains best practice to reinforce the instruction in this way to ensure optimal performance.

checklist, question 16 (LLM usage): authors use LLMs in their writing tools as well as RLMs as coordinators and for reasoning

Thank you for highlighting this point. We previously misunderstood the question. We will update our answer from [N/A] to [Yes] accordingly.

We sincerely look forward to your continued feedback and discussion. Thank you again for your valuable time!

Best regards,

Authors of WebThinker

Dear Reviewer,

As the rebuttal phase is coming to an end, we would like to kindly check if our previous response has addressed your concerns. We would greatly appreciate any further comments or suggestions you may have.

Thank you again for your time and consideration.

Sincerely,

The Authors

Thank you very much for your thorough review of our paper. We greatly appreciate the opportunity to address your questions and concerns. Please find our detailed responses to each of your points below.

Q1: In Figure 2(b), what would happen if we replaced "Traditional LLMs" with "LRMs"? Although there are subsequent experimental validations, the figure here cannot highlight the advantages of your paper's architecture/training method because it introduces a second variable. I suggest optimizing this in future versions.

Thank you for your insightful question. You are correct that in Figure 2(a) and (b), the backbone model used is a traditional LLM, whereas in Figure 2(c) and (d), the backbone model is an LRM. This inconsistency may cause confusion.

This is primarily because the workflow-based RAG methods depicted in Figure 2(a) and (b) are typically paired with traditional LLMs. In these approaches, each LLM generation predicts a single action for the current state based on a specific instruction (such as query planning or search necessity prediction). Each task step only requires the LLM to make a brief prediction, without the need for the LRM to generate lengthy chains of thought at every stage.

In contrast, the end-to-end agentic reasoning proposed by WebThinker in Figure 2(c) is better suited for LRMs. Here, LRMs can autonomously invoke research tools throughout a single, extended reasoning process, enabling them to complete an entire task within one coherent generation.

To resolve this inconsistency, we will update Figures 2(a) and (b) in the revised paper to use LRMs as the backbone model, thereby more clearly highlighting the unique advantages of WebThinker.

Q2: Why not test on AIME24/25, AMC23?

The primary reason is that WebThinker is designed to enhance the LRM reasoning process by incorporating search, web exploration, and report writing capabilities, with the goal of enabling Deep Research.

As demonstrated in prior work such as Search-o1 [1], experimental results indicate that mathematical tasks benefit only marginally from search operations, with relatively few search calls being made. This is because success in mathematical tasks typically depends more on the correctness of the problem-solving approach than on access to external knowledge. Consequently, we did not include mathematical tasks in our main evaluation, which is consistent with the methodology adopted by most deep research works, including OpenAI Deep Research [2], Kimi Researcher [3], Search-R1 [4], DeepResearcher [5], and WebDancer [6].

To more precisely assess the impact of WebThinker’s design on reasoning tasks such as AIME24/25 and AMC23, we conducted targeted experiments, summarized as follows:

From these results, we observe that on the three mathematical reasoning datasets—AIME 2024, AIME 2025, and AMC 2023—WebThinker-32B achieves performance comparable to or slightly better than QwQ-32B and Search-o1-32B, with improvements of 1–2 questions in the AIME series. This suggests that WebThinker’s design exhibits a certain degree of generalization to mathematical tasks. However, since mathematical problems generally require less external knowledge, the overall improvement remains limited.

Looking ahead, we plan to integrate additional tools such as calculators and Python code executors to further enhance WebThinker’s capabilities on mathematical and other specialized tasks.

Q3: For report generation, should we test the effectiveness of LLMs as evaluators, i.e., compare the difference between LLM evaluators and human scores?

Thank you for this important question. In our work, we employ the LLM-as-a-Judge approach, where large language models are used to evaluate reports generated by different systems in a listwise fashion, assigning comparative scores to assess their relative quality. We initially opted not to use human evaluation because many of our colleagues are already familiar with the report generation features of products like OpenAI, Gemini, and Grok Deep Research, which could introduce bias into their scoring.

To validate the reliability of the LLM-as-a-Judge method, we invited four volunteers from finance, literature, and pharmacy backgrounds—individuals who rarely use Deep Research products and are thus unfamiliar with the report generation characteristics of each model—to manually score all reports (on a scale of 1–10) produced by each system. We then calculated the average score for each evaluation metric. The table below presents the results of this human evaluation:

As shown, the average human evaluation scores across various metrics are largely consistent with the trends observed in LLM-as-a-Judge scoring. For instance, both WebThinker-32B-RL and Gemini2.0 Deep Research significantly outperform RAG-DeepSeek-R1 and Grok3 DeeperSearch on all indicators, with WebThinker-32B-RL being comparable to or slightly surpassing Gemini2.0 in terms of comprehensiveness and thoroughness. This strongly suggests that the LLM-as-a-Judge method can accurately reflect the actual quality of the reports.

One notable difference is that Grok3 DeeperSearch receives higher scores than RAG-DeepSeek-R1 in human evaluation, but lower scores in LLM-as-a-Judge assessments. This may be because Grok3 DeeperSearch produces reports that are more aligned with human reading preferences, even if the content is not as detailed as that of RAG-DeepSeek-R1.

In future revisions, we will incorporate these human evaluation results into the main text, along with a more detailed discussion and analysis.

Q4: For particularly long reports, how should this be handled if the LLM's context window is not large enough?

The report generation mechanism in WebThinker is specifically designed to address the challenge of generating entire reports in a single pass, which can easily exceed the model’s context window. In our approach, whenever the main LRM invokes the "write section" operation, the auxiliary LLM is only responsible for generating the content of the current section, rather than the full report. Similarly, for "edit section" operations, the auxiliary LLM produces only the revised content based on the relevant section of the report, not the entire document. As a result, as long as the report length remains within the LLM’s context window (for example, Qwen2.5 supports up to 128k tokens), the system functions smoothly.

In practice, we have rarely encountered reports exceeding 128k tokens—our average report length is around 10k tokens. Should such a scenario arise, particularly during edit operations, we can segment the report, locate the relevant paragraph within these segments, and perform the necessary edits accordingly.

Q5: What are the specific metrics for report evaluation? I think this should be clearly explained in the main text.

Thank you for this valuable suggestion. Previously, due to space constraints, we included all specific evaluation prompts in Appendix C.3.2 and did not elaborate on them in the main text. If possible, we will provide a detailed explanation of these metrics in the main text of the camera-ready version.

Q6: For the reasoning task, should we use pass@k as a metric?

We currently use the Pass@1 metric, as in practical applications, user experience is typically determined by whether the system can generate a correct response in a single attempt, rather than across multiple generations. However, to better reflect the system’s potential reasoning capabilities, evaluating Pass@k for k > ### 1 is certainly meaningful.

Accordingly, we also conducted experiments with Pass@3 and Pass@5, with the following results:

These results show that, across all datasets, Pass@3 and Pass@5 accuracy rates are noticeably higher than Pass@1. Specifically, Pass@3 improves by approximately 6 percentage points on average over Pass@1, and Pass@5 provides a further 3–4 percentage point increase. This demonstrates that WebThinker is capable of generating more diverse answers across multiple attempts, thereby increasing the likelihood of producing a correct response. Nevertheless, it is important to note that even with Pass@5, the improvement on challenging datasets such as HLE remains limited, highlighting the intrinsic difficulty of these tasks. This observation also points to future directions, such as end-to-end RL training and hierarchical RL training, to further enhance the model’s reasoning abilities.

We hope the above responses address your questions. We sincerely appreciate your valuable feedback and continued support for WebThinker. We look forward to further feedback and discussion.

Best regards,

Authors of WebThinker

References:

[1] Search-o1: Agentic Search-Enhanced Large Reasoning Models

[2] Introducing deep research.

[3] Kimi-Researcher: End-to-End RL Training for Emerging Agentic Capabilities

[4] Search-R1: Training LLMs to Reason and Leverage Search Engines with Reinforcement Learning

[5] DeepResearcher: Scaling Deep Research via Reinforcement Learning in Real-world Environments

[6] WebDancer: Towards Autonomous Information Seeking Agency

Thank you very much for your valuable and detailed review. We sincerely appreciate your constructive feedback and the opportunity to further clarify and strengthen our work. Please find our point-by-point responses below.

W1: WebThinker is a fairly complex framework, and the paper does not discuss the framework's inference lantency, computational cost, or efficiency comparison with the standard RAG approach.

Thank you for this important question. Computational overhead and efficiency issues are common pain points for all current Deep Research related methods.

WebThinker's design aims to balance performance improvement and efficiency, which is a challenging issue when leveraging large amounts of web information. Specifically, we designed an additional deep web explorer module to understand and integrate external web page information, returning refined helpful information rather than directly inserting all web pages into the reasoning chain. This would damage reasoning coherence and produce extremely long contexts, leading to poor performance and efficiency. This design philosophy is also applied to report generation, which utilizes additional LLMs for writing, checking, and editing report content instead of directly inserting the complete report into the reasoning chain.

To verify this point, we conducted experiments to compare the inference time consumption of different methods. All methods use 32B models as backbone, tested on the GAIA benchmark using one node of 8 NVIDIA H800 80G GPUs. The results are as follows:

From the experimental results, it can be seen that WebThinker achieves higher answer accuracy (48.5%) while maintaining inference time and sequence length at the same order of magnitude as traditional RAG methods. Notably, WebThinker's main reasoning chain length is even lower than Standard RAG and Iterative RAG methods that directly stack retrieved content. In actual deployment, we can completely adopt smaller auxiliary LLMs to further reduce inference time and computational costs, as auxiliary LLMs only handle simple sub-tasks.

W2: The performance of the system is highly dependent on external tools, such as the Bing search engine and the Crawl4AI crawler. The quality of the results returned by the search engine, the stability and coverage of the web crawling tools, will directly affect the final performance of WebThinker. The paper does not provide ablation experiments in this regard.

Indeed, WebThinker's performance is affected by the type and quality of search engines, as well as the success rate of web crawling, but this is also a problem that all web search-based agents must face. Our experiments use Bing Search API and Crawl4AI crawler, and in actual deployment, we can completely use other search engines and web crawling methods.

To verify the impact of search engines and crawler tools on WebThinker's performance, we conducted the following ablation experiments:

We systematically evaluated WebThinker's performance on four benchmark datasets (GPQA, GAIA, WebWalkerQA, and HLE) under different search engines (Bing, Google Serper API) and whether to integrate Crawl4AI crawler tools. The experimental setup is as follows:

• Bing: Use Bing Search API for web retrieval.
• Google Serper: Use Google Serper API for web retrieval.
• Crawl4AI: Based on retrieval results, further utilize Crawl4AI tools to crawl web page content, improving information coverage.
• Request: Only use the requests library to obtain web page content.

The table below summarizes the accuracy (Accuracy, %) of WebThinker on each dataset under different configurations:

Analysis:

• Impact of Search Engines: Experiments show that Google Serper API and Bing Search API have similar overall performance, proving that WebThinker's performance has low dependency on search engine types and has good adaptability.
• Impact of Crawler Tools: Compared to using only the Request library, after adopting Crawl4AI to crawl web page content, all datasets achieved slight improvements in accuracy. This indicates that more efficient web page acquisition capabilities do help enhance system performance, but the improvement is limited, indicating that WebThinker has relatively low dependency on specific crawler tools.

W3: WebThinker is limited to processing static web pages based on text and links, which reduces its ability to be used in real-world scenarios.

WebThinker indeed primarily processes static web pages based on text and links, but this does not significantly reduce its applicability in real-world scenarios for the following reasons:

First, most knowledge and information on the internet still exists in the form of text and hyperlinks. Internet content is still primarily text-based, which means WebThinker can process the vast majority of information resources on the internet.

Second, our system design considers the diversity of practical application scenarios:

1. Value of Static Content Processing: In key application scenarios such as academic research, fact-checking, and knowledge-intensive Q&A, text information is the primary information carrier. WebThinker demonstrates excellent performance in these scenarios, as shown by the GPQA and GAIA benchmark results.

2. Extensibility for Dynamic Web Pages: WebThinker adopts a modular design and can extend its ability to process dynamic content through plugins. In our follow-up research, we have begun integrating JavaScript execution environments to enable the system to interact with dynamic web page elements. The current version focuses on establishing robust text understanding and link navigation foundations, which are necessary prerequisites for handling more complex web interactions.

Additionally, we discuss this limitation in detail in Section 5.3 of the paper and propose clear future work directions, including integrating web rendering engines and adding multimodal understanding capabilities to expand the system's processing scope.

Therefore, although the current version of WebThinker does focus on processing static web page content, this design choice is based on a trade-off between practical application needs and technical feasibility, and does not significantly limit its applicability in real-world scenarios. On the contrary, it lays the foundation for building more complex web agent interaction systems.

Thank you again for your valuable comments and suggestions. We hope our responses have addressed your concerns and clarified the strengths and limitations of our work. We look forward to further feedback and discussion.

Best regards, Authors of WebThinker

Dear Reviewer,

As the rebuttal phase is coming to an end, we would like to kindly check if our previous response has addressed your concerns. We would greatly appreciate any further comments or suggestions you may have.

Thank you again for your time and consideration.

Sincerely,

The Authors

Thank you very much for your detailed review. We have addressed your concerns point by point and further supported our responses with comprehensive quantitative analyses:

Q1: Fair Comparison: Concerns about computational costs and inference time comparisons between WebThinker and baselines

Thank you for raising this important point. Computational overhead and efficiency are indeed common challenges faced by all current Deep Research methods.

WebThinker is designed to strike a balance between performance gains and efficiency, which is particularly challenging when incorporating large volumes of web information. To address this, we introduced a deep web explorer module that intelligently understands and integrates external web content, returning distilled and relevant information rather than indiscriminately inserting entire web pages into the reasoning chain. Directly including all retrieved content would disrupt reasoning coherence and result in excessively long contexts, ultimately degrading both performance and efficiency. This design philosophy also extends to report generation, where we employ additional LLMs for writing, checking, and editing report content, instead of embedding the entire report into the main reasoning chain.

To empirically validate this approach, we conducted experiments comparing the inference time of different methods. All methods utilized 32B models as the backbone and were evaluated on the GAIA benchmark using a single node equipped with 8 NVIDIA H800 80G GPUs. The results are summarized below:

As shown, WebThinker achieves significantly higher answer accuracy (48.5%) while keeping inference time and sequence length within the same order of magnitude as traditional RAG methods. Notably, the main reasoning chain length in WebThinker is even shorter than that of Standard RAG and Iterative RAG, which directly stack retrieved content. In practical deployment, we can further reduce inference time and computational costs by employing smaller auxiliary LLMs, since these only handle relatively simple sub-tasks.

Q2: Clarity: The authors say "The objective is to generate a comprehensive answer solution for a given task query q" (Line 96). What does "comprehensive" mean here specifically? Why is this important in all cases?

In this context, "comprehensive" encompasses both the entire reasoning process and the final answer or report. We believe that, whether in problem-solving or report generation scenarios, both the reasoning process and the final output are essential, which is why we use this term.

However, we acknowledge that this expression could be clearer. A more precise formulation would be: The objective is to generate a comprehensive reasoning process and answer for a given task query q, guided by an instruction I, which better conveys our focus on both the completeness of the reasoning process and the thoroughness of the final answer.

Q3: Transparency: Concerns about redundancy in the search process and potential for unnecessary searches

Good question. Indeed, redundant search calls by the Search Agent can lead to unnecessary computational costs, making efficiency a critical concern in this field. To address this, WebThinker mitigates redundancy at the training data level by constructing preference pairs: reasoning trajectories with fewer and more accurate search calls are treated as positive examples, while those with incorrect or excessive search calls are treated as negative examples.

To more concretely illustrate the impact of this design on search efficiency, we conducted the following ablation experiments:

As shown, the full DPO training strategy significantly reduces the average number of search calls (from 7.3 to 4.9, a 32.9% reduction) and substantially increases the effective search ratio (from 42.5% to 68.7%). Here, the "effective search ratio" refers to the proportion of searches along the labeled path relative to the total number of searches, serving as a measure of the model’s search efficiency. These results indicate that our training strategy effectively guides the model to search more selectively, thereby reducing redundant operations.

Importantly, this improvement in search efficiency does not come at the expense of performance. On the contrary, accuracy on the WebWalkerQA benchmark increases by 3.8 percentage points. This demonstrates that our approach not only enhances efficiency but also improves the model’s overall reasoning ability, enabling it to better determine when additional information is needed and what content should be retrieved.

Q4: Training details: It is not clear how long and how many trajectories does the model need to be effective? In Section 3.5, what are the percentages of different types of DPO pairs?

Below are the detailed quantities and proportions of each data type in our training set:

As shown, SuperGPQA and WebWalkerQA contribute 2,973 and 2,891 data points, respectively, while OpenThoughts, NaturalReasoning, and NuminaMath provide 1,637, 1,108, and 842 data points, for a total of 9,451. These cover a wide range of scientific, knowledge-intensive, mathematical, logical reasoning, and open-ended tasks, aiming to encompass as many real-world task types as possible.

To investigate the impact of training duration and data volume on model effectiveness, we trained the model on a single node with 8 NVIDIA H800 80G GPUs using the above 9,451 data points (batch size 32), and evaluated performance on the GAIA and WebWalkerQA datasets every 200 steps. The table below shows accuracy progression with training steps:

The results indicate that as training progresses, the model’s accuracy on both datasets steadily improves and converges around 800 steps, suggesting that the current data volume and training epochs are sufficient to fully realize the model’s potential. Notably, even after just 200 steps, the model exhibits significant performance gains, demonstrating that the current training data is already highly effective.

Q5: (Minor) Novelty: One has to admit that many components in WebThinker are not new and explored in the previous works, but in general this looks like a useful approach. Therefore the issue is a minor concern to me.

Thank you for raising this point. The primary goal of WebThinker is to equip large reasoning models with deep research capabilities, with web exploration and report writing being the two most critical functionalities. While prior work has addressed these tasks, most existing methods rely on predefined workflows, making it difficult to seamlessly integrate with extended reasoning processes.

WebThinker addresses this by abstracting web exploration, report writing, and editing as "research tools," enabling the reasoning model to autonomously invoke these tools within a single, end-to-end agentic reasoning process to accomplish complex tasks. This approach—especially in the context of report generation and tool integration—remains underexplored in the current literature.

We hope the above clarifications and experimental results address your questions. Thank you again for your valuable feedback.

Best regards, Authors of WebThinker

Dear Reviewer,

As the rebuttal phase is coming to an end, we would like to kindly check if our previous response has addressed your concerns. We would greatly appreciate any further comments or suggestions you may have.

Thank you again for your time and consideration.

Sincerely,

The Authors

Thanks the author for the response. While I still hold a bit of the concern on the novelty part and I think the statement "most existing methods rely on predefined workflows" is not entirely fair, I keep my original recommendation for now.