ArXiv: 2509.00375

🎯 Pitch

A 3B model trained on synthetically generated hierarchical reasoning tasks matches the deep research performance of commercial behemoths like Gemini 2.5 Pro. This tiny model achieves its surprising performance by learning to decompose complex questions into nested sub-problems, each turned into a standalone constraint satisfaction puzzle using a novel automatic tree-based data synthesis process.

1. Executive Summary

This paper introduces InfoSeek, a scalable data synthesis framework for constructing complex Deep Research tasks that require hierarchical multi-step reasoning and evidence synthesis from diverse sources. The authors formalize verifiable Deep Research questions as Hierarchical Constraint Satisfaction Problems (HCSPs), which are fundamentally distinct from simpler multi-hop or flat constraint satisfaction formulations, and operationalize this definition through a dual-agent system that recursively builds Research Trees from large-scale webpages — where intermediate nodes are blurred into valid sub-problems by adding constraints (e.g., requiring a birthplace entity to also satisfy population and language conditions) and then converted into natural language questions that mandate traversing the full hierarchy. The resulting dataset comprises over 50K training examples and 16.5K reasoning trajectories, and a compact 3B model trained on this data via supervised fine-tuning with rejection sampling followed by GRPO reinforcement learning — forming the InfoSeeker agent — achieves 16.5% accuracy on the BrowseComp-Plus benchmark, surpassing much larger 32B open-source models (Qwen3-32B at 3.5%) and lightweight commercial APIs (Gemini 2.5 Flash at 15.5%), establishing that targeted data synthesis for hierarchical reasoning can substitute for model scale only when problems are structurally decomposable into verifiable sub-problems grounded in retrievable evidence.

2. Context and Motivation

The Core Problem: Deep Research Requires Hierarchical Reasoning, But We Have No Data to Train For It

The fundamental gap this paper addresses is deceptively simple: large language models are increasingly expected to perform Deep Research — complex, multi-step information-seeking tasks that require decomposing questions, coordinating evidence from diverse sources, and synthesizing hierarchical reasoning chains — yet there exist virtually no large-scale, open-source training datasets designed to teach models how to do this.

This gap matters because the trajectory of LLM deployment is shifting decisively away from simple factoid question-answering toward autonomous knowledge work. The paper cites OpenAI's Deep Research product (OpenAI, 2025), Google's integration of deep research into Gemini (Citron, 2024), and Perplexity's analogous offering (Perplexity, 2025) as evidence that industry is already betting on this capability as "a cornerstone for the next generation of LLMs, shifting them from conversational assistants to autonomous knowledge engines" (Section 1). These systems are expected to operate in domains like scientific discovery and policy analysis, where problems are open-ended, knowledge landscapes evolve continuously, and answers emerge only through progressive resolution of interdependent sub-questions.

Yet the training data infrastructure has not kept pace. The paper identifies a sharp disconnect between the tasks models are being asked to perform and the datasets on which they are trained. This disconnect is not merely an inconvenience — it means that models deployed for deep research are relying on reasoning capabilities that were never explicitly taught, acquired incidentally through exposure to simpler QA formats and general web text. The consequence is that progress in this area has been driven primarily by inference-time scaffolding (complex workflows, multi-agent orchestration) rather than by fundamental improvements in the models' ability to plan, decompose, and integrate evidence — a brittle approach that the authors argue lacks the flexibility required for diverse deep research scenarios.

Why This Problem Matters: Three Dimensions of Significance

Practical deployment. As organizations deploy LLMs for increasingly autonomous knowledge work, the reliability of their reasoning becomes paramount. A model that can answer "Who developed the theory of relativity?" but cannot reliably answer "Which mathematician, born in a European city whose official language is English and whose population exceeds five million, studied at Cambridge and later earned a PhD at Princeton University in 1938?" (the paper's running example of an HCSP question in Figure 2) is of limited use for genuine research assistance. The BrowseComp benchmark (Wei et al., 2025), which the paper uses for evaluation, was specifically designed to expose this gap — and as the paper's results show, even powerful 32B open-source models score only 3.5% on it (Table 4). Getting to production-grade performance requires systematic training, not just clever prompting.

Theoretical significance for AI reasoning. The paper's formalization of Deep Research as Hierarchical Constraint Satisfaction Problems (HCSPs) is significant beyond the immediate practical contribution. It provides a clean theoretical language for distinguishing between problem types that are often conflated in the literature. A single-hop factual query ("What is the capital of France?") is a single-constraint CSP. A multi-hop question ("What country's capital was the birthplace of the scientist who solved the Enigma code?") is a chain of dependent inferences. An HCSP ("This mathematician, born in a European city whose official language is English and whose population exceeds five million, studied at Cambridge and later earned his PhD at Princeton University in 1938. Who is he?") introduces hierarchy: intermediate sub-questions are themselves CSPs that must be solved before their answers can propagate upward through the reasoning tree. This is not a minor extension — it changes the nature of the reasoning task from sequential deduction to hierarchical constraint propagation, and it means that errors at any level can invalidate the entire solution. Understanding how models handle this layered structure is a theoretically rich problem that connects to classical AI work on constraint satisfaction, planning, and evidence integration.

Open-source ecosystem implications. Table 1 in the paper provides a stark comparison of dataset availability. Classical QA datasets — Natural Questions (300K+ examples), HotpotQA (100K+) — are large and open-source, but they capture only single-hop or flat multi-hop reasoning. More recent efforts like WebWalkerQA (14.3K examples) and WebDancer (200 examples) target multi-hop web search but remain small and focused on simpler problem structures. WebShaper, the closest precursor to InfoSeek in its formalization-driven approach, produced only 500 examples and its framework is not open-source. Pangu DeepDiver, InForage, and SimpleDeepSearcher either lack public data releases or provide only trajectory data without the underlying question synthesis framework. The paper's characterization is blunt: "The results highlight a scarcity of high-quality, large-scale datasets explicitly designed for Deep Research in the open-source community" (Section 1). InfoSeek fills this gap with 50K+ QA pairs, 16.5K reasoning trajectories, and a fully open-source synthesis pipeline — making it, by the authors' accounting, the first large-scale, open dataset purpose-built for hierarchical reasoning tasks.

Where Existing Approaches Fall Short

The paper identifies specific limitations across four categories of prior work, each of which motivates a different aspect of the InfoSeek design.

1. Existing QA datasets lack structural depth. The dominant training datasets for agentic search and reasoning models are Natural Questions (single-hop factoid) and HotpotQA (two-hop bridge or comparison questions). Table 5 demonstrates the consequence: training on NQ+HotpotQA yields only 3.0% accuracy on BrowseComp-Plus, while training on InfoSeek yields 16.5%. The gap is not about scale — NQ and HotpotQA are larger than InfoSeek — but about structural complexity. Single-hop and two-hop questions simply do not teach the hierarchical decomposition and constraint integration that deep research requires. A model trained exclusively on "What team did the quarterback for the 2015 Super Bowl winning team play for in college?" (a HotpotQA-style bridge question) never learns to handle problems where intermediate nodes are themselves multi-constraint sub-problems that must be independently solved.

This limitation is structural, not superficial. The paper's formalization makes clear why: a two-hop question can be solved by a linear chain of two retrieval operations — find X, then use X to find Y. An HCSP with a research tree of depth 2 and branching factor 3 requires solving three parallel constraint satisfaction sub-problems at the leaf level, integrating their results to satisfy the constraints on the parent node, and then potentially chaining that result through another level of constraints. The computational complexity is qualitatively different, and models trained only on linear chains never develop the capacity for parallel constraint integration.

2. Inference-time agentic frameworks are effective but brittle. A substantial body of work — Agentic Reasoning (Wu et al., 2025c), AgentOrchestra (Zhang et al., 2025), ALITA (Qiu et al., 2025) — constructs sophisticated agentic scaffolding that operates at inference time without modifying model weights. These frameworks decompose problems, delegate sub-tasks to specialized agents or tools, and orchestrate multi-step workflows. The paper acknowledges their effectiveness in narrow domains but identifies a fundamental limitation: they "lack the flexibility required for diverse Deep Research tasks" (Section 1).

This is a deeper criticism than it might appear. Inference-time frameworks are essentially hand-crafted reasoning strategies encoded in prompts and orchestration logic. They work well when the problem structure matches the designer's expectations — say, a problem that decomposes cleanly into search-then-synthesize — but fail when problems require different decomposition strategies, different numbers of reasoning steps, or different integration patterns. The paper's approach is complementary: rather than designing better scaffolding, InfoSeek provides training data that teaches the model itself to perform decomposition, planning, and integration. The trained model internalizes these capabilities, making them available across diverse problem structures without relying on pre-specified workflows. This is a bet on learned reasoning strategies over engineered ones, and the BrowseComp-Plus results — where a 3B trained model outperforms much larger models using inference-time scaffolding — provide empirical support for this bet.

3. Training-based approaches for search and retrieval rely on inadequate data. A parallel line of work — Search-R1 (Jin et al., 2025), Search-o1 (Li et al., 2025b), AutoRefine (Shi et al., 2025b), ZeroSearch (Sun et al., 2025a), InForage (Qian & Liu, 2025) — uses reinforcement learning to train models to interleave search queries with reasoning steps. The paper acknowledges that these methods "achieve gains on traditional and multi-hop QA benchmarks" but then delivers the key critique: "their training still depends heavily on datasets like Natural Questions and HotpotQA, which remain far simpler than real Deep Research scenarios" (Section 1).

This is the central data problem restated: even the most sophisticated training algorithms cannot teach deep research if the training data contains only shallow reasoning. RL can optimize a model's search strategy — teaching it to generate better queries, to decide when to search versus when to reason from context, to filter retrieved documents effectively — but it can only optimize within the reasoning structures present in the training distribution. If the training data consists of single-hop and two-hop questions, RL will produce a model that is excellent at single-hop and two-hop reasoning — and nothing more. The paper's results in Table 5 bear this out: RL on NQ+HotpotQA produces a model that averages only 1.39 search calls on BrowseComp-Plus (indicating it barely attempts multi-step search) and achieves 3.0% accuracy. RL on InfoSeek produces a model that averages 8.24 search calls and achieves 16.5% accuracy. The data distribution, not the training algorithm, is the binding constraint.

4. Automated data synthesis for deep research agents is nascent and mostly closed-source. The most directly relevant prior work — WebShaper (Tao et al., 2025), DeepResearcher (Zheng et al., 2025), WebSailor (Li et al., 2025a), Cognitive Kernel-Pro (Fang et al., 2025) — explores automated synthesis of training data for advanced agents. Table 1 reveals the landscape: WebShaper produces only 500 examples from Wikipedia; SimpleDeepSearcher releases 871 trajectories but no QA dataset; Pangu DeepDiver and WebDancer target web-based multi-hop tasks but their datasets and workflows are not publicly released. The paper's characterization is pointed: "neither their datasets nor their workflows are publicly released" (Section 1).

WebShaper deserves particular attention as the closest precursor. Tao et al. (2025) adopt a similar formalization-driven approach: define a reasoning graph before generating the corresponding question. This ensures logical consistency and verifiability — properties InfoSeek also guarantees. However, WebShaper operates exclusively on Wikipedia, limiting entity diversity and structural complexity, and produces only 500 examples — far too few for effective training (the paper's own ablation in Table 5 shows that even 50K+ InfoSeek examples are necessary for strong performance, and the SFT+RL pipeline further filters these down to 3,450 high-quality trajectories for Round 2 training). The scale gap is not incidental; it reflects a fundamental difference in design philosophy. WebShaper's approach appears to involve substantial manual curation or expensive LLM-based validation, making scaling impractical. InfoSeek's key innovation is making the synthesis pipeline scalable: the expansion operations "rely on lightweight rules (i.e., hyperlink and fact extraction)" (Section 3.4), enabling the authors to produce 50K+ examples for $571.80 in total API costs (Table 2).

5. A subtle but critical omission: prior datasets do not preserve intermediate structure. The paper flags a technical limitation that is easy to overlook: existing datasets for agentic search typically provide only question-answer pairs, sometimes with final answers but without the intermediate reasoning steps, sub-question decompositions, or retrieval labels that would enable sophisticated training signals. InfoSeek, by contrast, "preserves meta-information such as intermediate steps and retrieval labels" (Section 1), which the authors suggest enables "compound reward design and trajectory-level optimization" (Section 7) — reinforcement learning approaches that can provide feedback not just on whether the final answer is correct, but on whether intermediate reasoning steps were valid, whether retrieved evidence was properly integrated, and whether sub-questions were correctly decomposed. This meta-information is a byproduct of InfoSeek's tree-based construction process (each vertex in the research tree corresponds to a sub-problem with known ground-truth constraints), and it represents a qualitatively different kind of training signal than what prior datasets offer.

How This Paper Positions Itself

The paper's positioning is explicit and ambitious: it aims to be the data-centric foundation for deep research, analogous to what ImageNet was for computer vision or what Natural Questions was for open-domain QA — a large-scale, purpose-built dataset that enables a new class of models and training methods. The authors are not proposing a new model architecture or a new RL algorithm; they are proposing a data synthesis methodology and releasing the resulting dataset as infrastructure for the field.

This positioning is reflected in the paper's tripartite contribution structure: (1) a formal definition (HCSPs) that provides theoretical grounding and distinguishes deep research from simpler problem types, (2) a scalable synthesis framework (InfoSeek) that operationalizes this definition, and (3) an empirical validation (InfoSeeker trained on InfoSeek) that demonstrates the dataset's utility. The formal definition is not presented as a theoretical contribution in itself — the mathematics (Equations 1–3) are straightforward set-theoretic constructions — but rather as a design constraint for the synthesis pipeline. By defining exactly what counts as an HCSP (hierarchical, with parallel constraints at each level and sequential dependencies between levels, converging to a unique verifiable answer), the paper establishes a correctness criterion that the synthesis pipeline must satisfy.

The paper also positions itself relative to the open-source vs. closed-source divide in deep research. Table 1 is not merely informational; it is an argument. The column "Framework" shows checkmarks only for SimpleDeepSearcher and InfoSeek, and the checkmark for InfoSeek is accompanied by a dataset size (50K+) that dwarfs all other open efforts. The implicit claim is that the open-source community has been starved of training data for deep research, and InfoSeek fills that gap. The BrowseComp-Plus results then demonstrate that open-source models trained on open-source data can compete with — and in some cases surpass — proprietary systems (Gemini 2.5 Flash, Sonnet 4, GPT-4.1), making the case that the bottleneck has been data, not model architecture or training algorithms.

Finally, the paper positions its dual-agent design (Planner + Browser) as a key enabler of scalability. Rather than relying on a single powerful LLM to generate questions end-to-end — which would be expensive and prone to hallucination, as WebShaper's limited scale suggests — InfoSeek separates the planning function (deciding which vertex to expand and what action to take) from the execution function (extracting entities, relations, and constraints from actual webpages). The Planner operates on the tree structure using global complexity objectives, while the Browser grounds all expansions in real web content, ensuring factual accuracy. This decomposition makes the pipeline both scalable (the Browser's operations are lightweight and parallelizable) and verifiable (every edge in the research tree traces back to a specific webpage and sentence). The authors frame this as "a principled framework that adheres to the HCSP definition, enabling high-quality dataset construction with explicit control over structural complexity and principled scalability" (Section 1), explicitly contrasting it with prior approaches that either lack structural guarantees, scale poorly, or remain closed-source.

In the broader landscape of LLM research, the paper aligns itself with the growing recognition that data quality and structure matter more than data quantity or model size for complex reasoning. This is the same intellectual current that produced works like Orca (Mukherjee et al., 2023, though not cited) and the various "textbooks are all you need" arguments, but applied specifically to the domain of hierarchical information-seeking. The BrowseComp-Plus result — a 3B model outperforming 32B models — is presented as evidence that targeted, structurally-rich training data can substitute for roughly an order of magnitude in parameter count, at least on problems that are decomposable into verifiable sub-problems grounded in retrievable evidence.

3. Technical Approach

This is primarily a data-centric systems paper whose core idea is that verifiable Deep Research questions can be formalized as Hierarchical Constraint Satisfaction Problems (HCSPs) and synthesized at scale by recursively constructing Research Trees from web-scale text, where a dual-agent system—a Planner that governs structural complexity and a Browser that grounds expansions in real web content—incrementally builds trees that are then converted into natural language questions requiring full-hierarchy traversal to solve.

3.1 Reader Orientation

What InfoSeek builds: a fully automated pipeline that, starting from nothing but a large corpus of webpages and Wikipedia articles, produces a dataset of over 50,000 complex questions—each requiring multiple steps of hierarchical reasoning, parallel constraint integration, and evidence synthesis—along with ground-truth answers, intermediate sub-problem decompositions, and retrieval labels, all for roughly $572 in total API costs.

What problem this solves: prior to InfoSeek, no large-scale, open-source dataset existed that required the kind of hierarchical, multi-constraint reasoning that real Deep Research tasks demand; existing datasets like Natural Questions and HotpotQA capture only flat or linear-chain reasoning, and models trained on them fail catastrophically on benchmarks like BrowseComp. The solution's "shape" is a data synthesis framework that is simultaneously structurally principled (every question corresponds to a well-formed HCSP with unique, verifiable answers), scalable (the core expansion operations are lightweight rule-based extractions, not expensive LLM calls), and information-rich (the tree construction process naturally preserves intermediate nodes, constraints, and evidence traces that enable sophisticated training signals beyond simple answer correctness).

3.2 Big-Picture Architecture (Diagram in Words)

The InfoSeek pipeline has five major stages, orchestrated by two cooperating agents:

  1. Knowledge Base Preparation — A preprocessing stage that ingests webpages and the full Wikipedia dump, filtering out invalid or trivial pages, extracting entities (identified by hyperlink presence) and atomic facts (sentences describing relationships between entities), and indexing them as candidate vertices and edges for tree construction. This stage runs once and produces the raw material from which all questions are built.

  2. Planner Agent — Maintains a global view of the partially-constructed Research Tree (the current set of vertices representing entities and facts, and edges representing relationships between them). At each step, the Planner selects a target vertex to expand and chooses among four possible actions (initialize, blur with constraints, extend depth, or terminate) based on global complexity objectives that balance sequential and parallel reasoning demands. The Planner makes strategic decisions; it does not interact with web content directly.

  3. Browser Agent — Executes the Planner's chosen action by interacting with the actual webpages of the selected vertices. For constraint addition, it extracts atomic claims from the entity's page; for depth extension, it extracts hyperlinks that indicate dependencies. All extractions are validated for relevance and recorded with explicit evidence traces (the specific sentence or hyperlink used). The Browser grounds the tree construction in real, verifiable web content.

  4. Question Generation — Once the Planner triggers termination (the tree meets complexity targets and all vertices have sufficient constraints), a powerful LLM (DeepSeek V3 or GPT-4.1) is prompted with the blurred vertex descriptions to generate a natural language question whose solution requires traversing the full hierarchy. This is the only stage that uses a large language model for generation; all tree construction uses lightweight rule-based operations.

  5. Quality Assurance Pipeline — A two-pronged filtering stage: (a) a difficulty check where Qwen2.5-32B-Inst attempts to answer questions directly (without search) and only the 2% it correctly answers are removed, ensuring questions cannot be solved from parametric memory alone; (b) a verifiability check where Gemini 2.5 Flash is given the ground-truth web pages along with distractor documents and must derive the correct answer—questions that yield wrong answers, multiple possible answers, or are unsolvable are filtered out, preventing underdetermined problems.

Information flows linearly: Knowledge Base → Planner selects action → Browser executes action and validates → (repeat until termination) → Question Generation → Quality Assurance → Final Dataset. The dataset includes not just QA pairs but also the underlying research trees, intermediate vertices, constraints, evidence traces, and—after the SFT trajectory construction phase—successful reasoning trajectories.

3.3 Roadmap for the Deep Dive

  • First, the formal HCSP definition (Equations 1–3) and its relationship to CSPs and multi-hop problems, because this formalism is the design specification that the entire synthesis pipeline must satisfy—every question InfoSeek produces must correspond to a well-formed HCSP with unique, verifiable answers.
  • Second, the Research Tree construction process—base case, recursive expansion, the four actions (initialize, blur, extend, terminate)—because the tree is the intermediate representation that bridges the formal definition and the natural language question, and understanding how vertices, edges, and constraints are created and connected is essential to understanding what the dataset actually contains.
  • Third, the Planner and Browser agents—their responsibilities, decision logic, and the lightweight rule-based operations that make the pipeline scalable—because the dual-agent design is the key architectural innovation that enables InfoSeek to produce 50K+ examples for under $600.
  • Fourth, the question generation and quality assurance stages—how structured trees become natural language, and how difficulty and verifiability are validated—because these stages ensure the questions are both challenging and solvable.
  • Fifth, the training pipeline (InfoSeeker)—rejection sampling, SFT, and GRPO reinforcement learning—because this is how InfoSeek's data is used to produce the compact 3B model that achieves strong BrowseComp-Plus performance.
  • Sixth, the workflow design with multi-query search and the Refiner Agent, because this is the inference-time architecture that the trained model uses, and it represents a concrete instantiation of how deep research capabilities manifest at runtime.

3.4 Detailed, Sentence-Based Technical Breakdown

Formalizing Deep Research as Hierarchical Constraint Satisfaction Problems

The paper builds its entire synthesis framework on a precise mathematical characterization of what constitutes a deep research question with a verifiable answer. This formalization serves as both a taxonomy (distinguishing deep research from simpler problem types that are often conflated in the literature) and a correctness specification (every question InfoSeek produces must satisfy these formal properties).

Constraint Satisfaction Problem (CSP) — the base case. The simplest building block is a CSP, where the goal is to identify a unique answer entity by intersecting the sets of entities that satisfy each of several independent constraints. Formally:

A=⋂i=1nS(ci)s.t.∣A∣=1, ∣S(ci)∣≥1 ∀iA = \bigcap_{i=1}^{n} S(c_i) \quad \text{s.t.} \quad |A| = 1, \ |S(c_i)| \geq 1 \ \forall i

where $C_q = \{c_1, c_2, \ldots, c_n\}$ is the set of constraints extracted from the question, $S(c_i)$ is the set of all entities in the knowledge base that satisfy constraint $c_i$, and $A$ is the final answer set.

What it computes: given a question, we first decompose it into its constituent constraints (e.g., "got a PhD from Princeton in 1938", "born in London", "graduated from Cambridge"). For each constraint, we retrieve the set of all entities satisfying that constraint. We then compute the intersection of all these sets. The CSP is well-formed only when exactly one entity survives the intersection — if zero entities remain, the constraints are contradictory; if multiple remain, the question is underdetermined.

Why this form: the intersection operation models the idea that a CSP answer simultaneously satisfies all constraints. This is the natural set-theoretic formulation of conjunctive queries — you are looking for entities that are in $S(c_1)$ AND in $S(c_2)$ AND ... AND in $S(c_n)$. Disjunctive queries (OR) would require a union operation and wouldn't guarantee uniqueness, which is essential for verifiable QA. The constraint on uniqueness ($|A|=1$) encodes the requirement that deep research questions have verifiable answers — if the answer isn't unique, automated evaluation becomes ambiguous.

The paper provides the running example (Figure 2): constraints $c_1$: got PhD from Princeton University in 1938, $c_2$: born in London, $c_3$: graduated from University of Cambridge. The intersection $S(c_1) \cap S(c_2) \cap S(c_3)$ yields $A = \{\text{Alan Turing}\}$.

Multi-hop Problem (MHP) — sequential dependencies. A multi-hop problem is structurally different from a CSP: rather than intersecting parallel constraints, it chains together sequential inference steps where each step's output becomes the input to the next. Formally:

A=S(k)(c)=S∘S∘⋯∘S⏟k times(c)A = S^{(k)}(c) = \underbrace{S \circ S \circ \cdots \circ S}_{k \text{ times}}(c)

where $k$ is the number of reasoning hops, $c$ is the initial constraint, and $S$ is a function that maps an input to the entity satisfying a relation. The composition $S \circ S$ means: apply $S$ to $c$ to get an intermediate entity, then apply $S$ again to that entity, and so on $k$ times.

What it computes: starting from an initial constraint (e.g., "scientist who solved the Enigma code"), we apply $S$ to obtain $S(c) = \{\text{Alan Turing}\}$. We then use this entity as input to the next hop: $S(\text{"birthplace of Alan Turing"}) = \{\text{London}\}$. Finally, $S(\text{"country with London as capital"}) = \{\text{England}\}$. The composition $S^{(3)}(c)$ produces the answer after exactly three sequential steps.

Why this form: the composition operator $\circ$ captures the essential property of multi-hop reasoning: strict sequential dependency. You cannot compute the third hop until you have the output of the second hop; you cannot compute the second hop until you have the output of the first. This is fundamentally different from CSPs, where all constraints can be resolved in parallel (you can look up "people who got PhDs from Princeton in 1938" and "people born in London" simultaneously) and only the final intersection requires integration. The paper emphasizes that this sequential dependency creates a specific failure mode: "errors at intermediate steps propagate forward, potentially invalidating the final result" (Section 2.1). A model that retrieves the wrong scientist for the Enigma code constraint will necessarily produce the wrong country, regardless of how well it performs subsequent steps.

Hierarchical Constraint Satisfaction Problem (HCSP) — the full formulation. An HCSP combines and generalizes both CSPs and MHPs by introducing hierarchy: the answer is not directly computable from a flat set of constraints or a linear chain, but must be progressively uncovered by solving a tree of interdependent sub-problems, where sub-problems at higher levels depend on the solutions of sub-problems at lower levels. Formally:

H(x)=⋂i=1kS(ci)∩⋂j=1mH(yj),with⋂∅:=UH(x) = \bigcap_{i=1}^{k} S(c_i) \cap \bigcap_{j=1}^{m} H(y_j), \quad \text{with} \quad \bigcap \emptyset := U

where $x$ is the HCSP question, $C_x = \{c_1, \ldots, c_k\}$ is the set of direct constraints (analogous to a CSP's constraints), $Y_x = \{y_1, \ldots, y_m\}$ is the set of sub-questions, $H(y_j)$ is the recursive application of the HCSP decomposition to sub-question $y_j$, and $U$ is the universal set of all entities (the identity for intersection: intersecting with the universal set changes nothing).

What it computes: the decomposition operator $H(\cdot)$ takes a question and produces the set of entities that satisfy it. For a question $x$, we compute the intersection of two families of sets: (1) the sets $S(c_i)$ of entities satisfying each direct constraint $c_i$, and (2) the recursively computed answer sets $H(y_j)$ for each sub-question $y_j$. If there are no sub-questions ($m = 0$), the second intersection is with $U$ (the universal set), which is a no-op, and $H(x)$ reduces to a standard CSP. If there are no direct constraints ($k = 0$) and only a single sub-question with a chain structure, $H(x)$ reduces to a multi-hop problem. The final answer is $A = H(q_H)$ where $q_H$ is the root question.

Why this form: the recursive decomposition captures the essential hierarchical structure of deep research. Consider the paper's running example (Figure 2, right panel): the question "This mathematician, born in a European city whose official language is English and whose population exceeds five million, studied at Cambridge and later earned his PhD at Princeton University in 1938. Who is he?" decomposes into direct constraints (studied at Cambridge, earned PhD at Princeton in 1938) and a sub-question (which mathematician was born in a European city whose official language is English and population exceeds five million?). That sub-question is itself a CSP with three constraints (European city, English official language, population > 5 million) that must be solved first to identify London, which then feeds into the higher-level constraints. The recursion continues until reaching base-case CSPs at the leaves.

The paper explicitly notes (Section 2.2) that both CSP and MHP "emerge as special cases of HCSP," which means any synthesis pipeline that can produce HCSPs can also produce CSPs and MHPs if desired — but the paper's focus is on generating problems at the full HCSP complexity level that prior datasets cannot capture.

The critical uniqueness condition. Across all three problem types, the paper imposes the requirement that $|A| = 1$ — the answer must be unique. This is not just a mathematical convenience; it is what makes automated evaluation and training possible. If a question admits multiple valid answers, any training signal based on exact match is ambiguous, and any evaluation metric is unreliable. This uniqueness requirement flows through the entire synthesis pipeline: the tree construction operations are designed to add constraints until the answer set at each vertex converges to a singleton.

Research Trees: The Intermediate Representation

The paper argues that every HCSP admits an underlying tree structure (Section 2.3), and this insight is what enables the systematic synthesis pipeline. Rather than generating questions directly from text — which risks hallucination, shortcut reasoning, or structural incoherence — InfoSeek first builds a Research Tree that encodes all the logical dependencies, then generates the question from the tree. This separation of concerns (structure first, language second) is the key design decision that enables both scalability and quality control.

Tree definition. Formally, a Research Tree $T = (V, E)$ is a connected, acyclic graph where:

  • Each vertex $v \in V$ represents either a knowledge entity (e.g., "Alan Turing", "University of Cambridge", "Princeton University") or a trivial fact (e.g., "1910s", "summer of 1925"). Entities are things that can be retrieved and reasoned about; trivial facts are atomic pieces of information that serve as constraints on entities.
  • Each edge $(v, w) \in E$ connects two vertices and represents a relationship between them, grounded in a specific sentence from a source webpage (e.g., "Alan Turing graduated from the University of Cambridge", "Alan Turing was born in the 1910s").

Why a tree (acyclic) rather than a general graph: the acyclic property ensures that the HCSP has a well-defined hierarchical structure with a unique root (the final answer). In a general graph with cycles, constraints could be mutually dependent in ways that prevent clean decomposition into independent sub-problems. The tree structure also guarantees that the recursive HCSP construction in Equations 6–7 is well-founded: every sub-problem eventually bottoms out at leaf vertices, with no circular dependencies.

Recursive construction — base case. The simplest Research Tree is a single vertex with no edges:

T=({r},∅)T = (\{r\}, \emptyset)

where $r$ is the root vertex representing the final answer entity. This corresponds to a question with zero constraints — trivially, any entity could be the answer, which violates the uniqueness condition. This base case is only the starting point for construction; the actual synthesis process immediately adds constraints and depth through the expansion operations.

Recursive construction — expansion step. Given a tree $T = (V, E)$, we can expand it by introducing a new vertex $w \notin V$ (either a new entity or a new fact) and connecting it with exactly one edge to some existing vertex $v \in V$:

T′=(V∪{w},E∪{(v,w)})T' = (V \cup \{w\}, E \cup \{(v, w)\})

What this does: each expansion operation adds one new piece of information to the tree. If $w$ is a leaf entity connected to $v$, it represents a dependency: to identify $v$, you must first identify $w$ (sequential reasoning — this is depth extension, Action 3). If $w$ is a factual constraint connected to $v$, it represents a condition that narrows the candidate set for $v$ (parallel constraint — this is blurring, Action 2). The recursive application of this expansion operation, guided by the Planner agent's decisions about which vertices to expand and what type of expansion to apply, builds trees of arbitrary complexity.

Converting trees to HCSPs — base case. For a vertex $v$ whose children are all leaves (height 1 in the tree), each edge $(v, w_i)$ connecting $v$ to a leaf child $w_i$ is converted into a constraint $c_i$. The question $q_v$ corresponding to this vertex is formed by combining these constraints:

qv=Q(Cv),where v=H(qv), Cv={c1,…,cn}q_v = Q(C_v), \quad \text{where } v = H(q_v), \ C_v = \{c_1, \ldots, c_n\}

Here $Q(\cdot)$ is the function that converts a set of constraints into a natural language question (performed by the LLM in the question generation stage), and $H(\cdot)$ is the HCSP decomposition operator from Equation 3. This base case reduces to constructing a standard CSP: the answer to $q_v$ is the unique entity that satisfies all constraints in $C_v$.

Converting trees to HCSPs — recursive step. For a vertex $v$ with children that include both leaves $\{w_1, \ldots, w_k\}$ and internal nodes $\{w_{k+1}, \ldots, w_n\}$ (height ≥ 1):

qv=Q(Cv∪{Q(wj)∣j=k+1,…,n})q_v = Q\left(C_v \cup \{Q(w_j) \mid j = k+1, \ldots, n\}\right)

What this computes: each leaf child $w_i$ contributes a direct constraint $c_i$ as before. Each internal child $w_j$ is itself the root of a subtree, and we recursively construct a sub-question $Q(w_j)$ for that subtree. The question $q_v$ is then formed by combining both the direct constraints and the sub-questions into a single natural language formulation. This means that to answer $q_v$, a model must first answer each sub-question $Q(w_j)$ (which may themselves require solving further sub-questions), then integrate those answers with the direct constraints.

Why this recursive formulation matters for data synthesis: it provides a constructive procedure. Given a Research Tree, we can mechanically generate the corresponding HCSP question by recursing from leaves to root, converting constraints into sub-questions at each level. The construction guarantees that the resulting question has the hierarchical structure implied by the tree, with no missing dependencies and no spurious ones. This is fundamentally different from prompting an LLM to "generate a complex multi-hop question," which provides no structural guarantees and often produces questions with shortcut reasoning paths or ambiguous answers.

Two potential issues in tree-based construction. The paper explicitly identifies two failure modes that the quality assurance pipeline must guard against (Section 2.4):

  1. Underdetermination: even after combining all constraints at a vertex, the answer set $A$ might contain multiple entities ($|A| > 1$). The question would then be ambiguous — multiple answers satisfy all constraints, and any single answer would be only partially correct. The verifiability check (Gemini 2.5 Flash deriving the answer from ground-truth pages) is designed to catch this: if the LLM cannot uniquely determine the answer from the provided evidence, the question is filtered out.

  2. Overdetermination: a single constraint (or a small subset) might already yield a unique solution ($|S(c_i)| = 1$ for some $c_i$), making the other constraints and the hierarchical structure unnecessary. A model could solve the question by satisfying only $c_i$ and ignoring the rest of the tree, which defeats the purpose of training hierarchical reasoning. The paper addresses this during tree construction by ensuring "that the resulting candidate sets are mutually exclusive, i.e., without inclusion relations" (Section 3.2, discussing Action 2). In practice, this is enforced by the Browser agent when selecting claims: it chooses constraints such that no single constraint's candidate set is a subset of another's, and the intersection of all constraints is necessary for uniqueness.

These two issues are in tension: adding more constraints resolves underdetermination but risks overdetermination. The Planner agent's global complexity objectives (balancing sequential and parallel reasoning demands) implicitly manage this tension by adding constraints only until uniqueness is achieved, then adding depth (new entities connected sequentially) rather than further parallel constraints at the same vertex.

The Dual-Agent Synthesis Pipeline: Planner and Browser

The core architectural innovation of InfoSeek is the decomposition of the tree construction process into two cooperating agents with distinct responsibilities. This design is what enables scalability: the Planner makes high-level strategic decisions (which are rare and can afford some computational cost), while the Browser executes lightweight, parallelizable operations grounded in actual web content. The paper is explicit that "the expansion operations rely on lightweight rules (i.e., hyperlink and fact extraction)" (Section 3.4), which is what keeps the per-example synthesis cost low enough to produce 50K+ examples for $571.80.

The Planner Agent. The Planner maintains a global view of the partially-constructed Research Tree $T_t$ at step $t$. Its responsibilities are:

  • Vertex selection: at each step, choose which vertex $v \in V_t$ to expand. The selection is guided by global complexity objectives that aim to produce trees with balanced sequential and parallel reasoning demands — not all depth (which would reduce to multi-hop) and not all breadth (which would reduce to flat CSP). The paper does not specify the exact selection algorithm (it may be heuristic or random sampling with constraints), but the key point is that the Planner has visibility into the entire tree structure, enabling it to make choices that maintain balance.

  • Action selection: given a selected vertex, choose among four possible actions (described in detail below). The action choice depends on the vertex's current state: if it lacks sufficient constraints for uniqueness, Action 2 (blur with constraints) is available; if it represents an entity that can be further decomposed into dependencies, Action 3 (extend depth) is available; if the tree has reached the desired complexity and all vertices are sufficiently constrained, Action 4 (terminate) is triggered.

  • Complexity control: the Planner monitors the overall tree structure — total number of vertices, maximum depth, branching factor at each level — and decides when the tree has reached sufficient complexity. The paper notes (Section 3.4) that "termination is triggered only when the research tree achieves the desired complexity and all vertices have sufficient constraints," which implies explicit thresholds or targets for these structural metrics, though the specific values are not reported. Table 2 shows that the resulting dataset concentrates on 4–6 reasoning vertices, with the largest category being 6-vertex problems (17,714 out of 52,138 total), suggesting that the Planner targets this range as the sweet spot for challenging but solvable problems.

The Browser Agent. The Browser executes the Planner's chosen action by directly interacting with the source webpages of the relevant entities. Its responsibilities are:

  • Constraint extraction (for Action 2): given a target vertex $v$, the Browser accesses $v$'s corresponding webpage (via Wikipedia or the web corpus), extracts atomic claims — sentences that describe a relationship between $v$ and some other entity or fact — and selects a subset of $k$ claims that, when combined, uniquely identify $v$. The selection criteria include mutual exclusivity (no inclusion relations between candidate sets) and collective sufficiency (the intersection of all $k$ constraint-satisfying entity sets must be exactly $\{v\}$). Each selected claim becomes a new child vertex $w_i$ of $v$, connected by an edge labeled with the relationship.

  • Dependency extraction (for Action 3): given a target vertex $v$ that represents an entity, the Browser extracts hyperlinks from $v$'s webpage that indicate a dependency relationship — for example, a sentence like "Turing was influenced by the work of Max Newman" contains a hyperlink on "Max Newman" that connects Turing to his PhD advisor. The Browser selects one such hyperlinked entity to become a new child vertex $w$ of $v$, extending the tree's depth and creating a sequential dependency: to identify $v$, a model must first identify $w$ (or vice versa, depending on the dependency direction). The paper gives the example of "v was discovered by w" as a typical dependency pattern.

  • Evidence recording: for every expansion operation — whether adding a constraint or extending depth — the Browser records an explicit evidence trace: the source webpage URL, the specific sentence or hyperlink used, and the extracted relationship. This trace guarantees verifiability: any edge in the final Research Tree can be traced back to its source in the original web corpus, and automated checks (the verifiability step in quality assurance) can confirm that the extracted information is accurate.

  • Validation: before accepting any extraction, the Browser validates it for relevance — ensuring that the extracted claim or hyperlink actually describes a meaningful relationship to the target vertex, not an incidental mention. The paper does not specify the validation mechanism in detail, but it likely involves rule-based checks (e.g., the hyperlink must appear in a sentence where the target entity is the subject) combined with possibly lightweight LLM filtering.

Why separate Planner and Browser: this decomposition reflects a deliberate engineering choice about what operations need to be "smart" (require strategic reasoning) versus what needs to be "fast and grounded" (require factual accuracy and throughput). The Planner's decisions — which vertex to expand and what action to take — involve reasoning about global tree structure and complexity tradeoffs. These decisions are relatively infrequent (one per expansion step, with perhaps 4–6 expansion steps per tree, given the vertex counts in Table 2) and can afford some computational cost. The Browser's operations — extracting claims and hyperlinks from webpages, validating them — are frequent and must be fast to achieve scale. By keeping the Browser's operations lightweight (hyperlink extraction, fact extraction via simple pattern matching or lightweight NLP), the pipeline can process tens of thousands of webpages efficiently. The paper explicitly contrasts this with approaches that use LLMs for every step of question synthesis, which would be "expensive and prone to hallucination" (implied by the emphasis on lightweight rules in Section 3.4).

The four actions in detail. A complete synthesis iteration follows a fixed pattern (Section 3, opening paragraph): it begins with Action 1 (initialization), followed by a series of actions alternating between Action 2 (blurring) and Action 3 (depth extension), and ends with Action 4 (termination and question generation). The alternation between Actions 2 and 3 is the mechanism that ensures the tree has both parallel constraints (breadth) and sequential dependencies (depth), producing the hierarchical structure characteristic of HCSPs.

Action 1: Initialization from Research Anchors

The synthesis pipeline begins by selecting a root entity — the final answer to the eventual question. The Browser samples a valid entity from the preprocessed knowledge base (the set of Wikipedia pages and webpages that survived filtering for sufficient content and non-triviality). This entity becomes the root vertex $r$ of the initial Research Tree:

T0=({r},∅)T_0 = (\{r\}, \emptyset)

The Browser then performs the first expansion immediately: it selects a related entity — an entity mentioned in $r$'s webpage with a hyperlink — and creates a child vertex $w$ with edge $(r, w)$. This gives the tree an initial depth of 1 and provides a starting point for subsequent expansions. The paper does not specify the criteria for selecting this first related entity; it may be random, or it may prefer entities with rich webpages that will support further expansions.

After initialization, the Planner enters the main expansion loop, alternating between Actions 2 and 3 to build out the tree's structure.

Action 2: Blurring Parent with Constraints

This action addresses one of the central challenges in synthesizing complex reasoning questions: ensuring that intermediate nodes in the reasoning chain are themselves non-trivial sub-problems, not just simple lookups. The paper's term "blurring" refers to the process of making a parent vertex harder to identify directly by adding constraints — you "blur" the entity so that a model cannot simply retrieve it from memory but must satisfy multiple conditions to narrow down the candidate set.

The problem this solves. Without blurring, a vertex like "London" in the research tree would be trivially identifiable — a model asked "What is the capital of England?" can answer from parametric memory alone, defeating the purpose of the hierarchical search and reasoning that deep research is supposed to train. By blurring "London" with additional constraints — "a European city whose official language is English and whose population exceeds five million" — the sub-problem becomes a genuine CSP that requires either multiple retrieval operations or reasoning across multiple facts, and whose solution constrains the higher-level reasoning.

How it works. The Planner first identifies a vertex $v$ whose current constraints (from any previous blurring operations) are insufficient to uniquely identify $v$. The Browser then accesses $v$'s webpage and selects $k$ atomic claims (sentences describing factual relationships involving $v$) such that:

  1. Collective sufficiency: the intersection of the entity sets satisfying each claim is exactly $\{v\}$. If you know that an entity satisfies all $k$ claims, you can uniquely determine that it is $v$.
  2. Mutual exclusivity: no claim's candidate set is a subset of another's. This prevents overdetermination: if $S(c_i) \subseteq S(c_j)$, then satisfying $c_j$ already implies satisfying $c_i$, making $c_i$ redundant. The paper explicitly states that it ensures "the resulting candidate sets are mutually exclusive, i.e., without inclusion relations" (Section 3.2).
  3. Individual non-uniqueness: each claim individually should not uniquely identify $v$ (otherwise the problem is overdetermined). If "population exceeds five million" alone narrowed the candidate set to just London, the other constraints would be unnecessary.

Each selected claim becomes a new child vertex $w_i$ of $v$, connected by an edge representing the relationship described in the claim (e.g., "is a European city", "has official language English", "has population exceeding 5 million").

Why the $k$ claims are chosen from the entity's own webpage: this grounds the constraints in verifiable facts. The Browser extracts claims directly from the source text, so each constraint is traceable to a specific sentence. This also means that the constraint discovery process is efficient — rather than searching the entire knowledge base for facts about $v$, the Browser only needs to parse $v$'s own webpage, which naturally aggregates information about $v$.

The blurring operation and the HCSP formalization. After blurring, the vertex $v$ becomes a CSP: to identify $v$, a model must find the unique entity that satisfies all $k$ leaf constraints simultaneously. This maps exactly to the base case of the tree-to-HCSP conversion (Equation 6): $q_v = Q(\{c_1, \ldots, c_k\})$, where each $c_i$ corresponds to one of the claims. The answer $v$ is recovered as $H(q_v) = \bigcap_{i=1}^{k} S(c_i) = \{v\}$.

Action 3: Extending the Tree

While blurring adds parallel constraints (breadth), Action 3 adds sequential dependencies (depth). The Planner selects an existing vertex $v$ that represents an entity, and the Browser extracts a hyperlink from $v$'s webpage that indicates a dependency relationship. This creates a new child vertex $w$ such that identifying $v$ requires first identifying $w$.

What constitutes a valid dependency. The paper gives the example pattern "v was discovered by w" — a relationship where $w$ is a prerequisite for understanding or identifying $v$. More generally, any hyperlink where the linked entity plays a causal, temporal, or logical role in the story of $v$ qualifies. The Browser selects one such hyperlinked entity and creates the new edge $(v, w)$.

How this produces sequential reasoning. In the resulting tree, $v$ now has an internal child $w$ rather than (or in addition to) leaf children representing direct constraints. When the tree is converted to an HCSP, the question at $v$ will include a sub-question $Q(w)$ — meaning a model must first solve $Q(w)$ to identify $w$, then use $w$ to help resolve the constraints on $v$. This is the recursive case of the tree-to-HCSP conversion (Equation 7).

Sequential vs. parallel dependencies. Action 3 creates a fundamentally different type of reasoning requirement than Action 2. With Action 2, the constraints on $v$ are parallel — a model can look up all $k$ constraints simultaneously and intersect the results. With Action 3, the dependency on $w$ is sequential — a model cannot fully resolve $v$ until it has identified $w$, which may itself require resolving further dependencies. The paper's alternating pattern between Actions 2 and 3 ensures that the resulting trees contain both types of reasoning, producing the hierarchical structure characteristic of HCSPs.

The relationship between Actions 2 and 3 and the HCSP definition. After applying both actions, a vertex $v$ might have both leaf children (from blurring, converted to direct constraints $c_i$) and internal children (from depth extension, converted to sub-questions $Q(w_j)$). The resulting question at $v$ is then:

qv=Q({c1,…,ck}∪{Q(wk+1),…,Q(wn)})q_v = Q(\{c_1, \ldots, c_k\} \cup \{Q(w_{k+1}), \ldots, Q(w_n)\})

This is exactly the recursive form from Equation 7: the question combines direct constraints and sub-questions into a coherent natural language formulation. The HCSP answer $H(q_v)$ is the intersection of the entity sets satisfying the direct constraints AND the recursively computed answer sets for the sub-questions.

Action 4: Termination and Generation of the Question

The Planner monitors the tree's structural complexity throughout the expansion process. Termination is triggered only when two conditions are simultaneously met:

  1. Complexity target achieved: the tree has reached the desired structural complexity, measured in terms of total vertices, maximum depth, and branching factor. Table 2's distribution (concentrated on 4–6 vertices, with a tail extending to 7+) suggests that the Planner targets trees in the medium-complexity range — complex enough to require genuine hierarchical reasoning but not so complex that the resulting questions become unsolvable or the trees become unmanageably large.

  2. All vertices sufficiently constrained: for every internal vertex $v$, the combination of its direct constraints and its sub-question dependencies is sufficient to uniquely identify $v$. This is the condition that prevents underdetermination — there are no "loose ends" in the tree where a sub-problem has multiple possible solutions.

When termination is triggered, the Planner constructs the final question from the complete Research Tree by applying the recursive tree-to-HCSP conversion (Equations 6–7). This involves:

  • Traversing the tree from leaves to root, recursively constructing sub-questions for each internal node.
  • At the root $r$, combining all direct constraints and sub-questions into a single prompt for a powerful LLM (DeepSeek V3 or GPT-4.1).
  • The LLM is instructed to generate a natural language question whose solution requires traversing the full hierarchy — that is, a question that cannot be answered without solving the intermediate sub-problems in order.

The paper emphasizes (Section 3.4) that this is the only stage that uses a large language model for content generation — "because the expansion operations rely on lightweight rules (i.e., hyperlink and fact extraction), the process is highly scalable and enables the cost-efficient synthesis of large-scale datasets." All tree construction uses deterministic, rule-based extraction from actual webpages, which is both cheaper and less prone to hallucination than LLM-based generation.

The question generation prompt. While the paper does not provide the exact prompt text, the description in Section 3.4 and the examples in Figure 2 indicate that the LLM is given the "blurred vertex descriptions" — that is, for each vertex in the tree, the set of constraints and sub-question relationships — and is instructed to produce a question that naturally incorporates all these conditions. The resulting questions should "enforce genuine multi-step reasoning, prevent potential shortcut, and yield a unique, verifiable answer grounded in factual evidence" (Section 1). The use of the term "blurred" descriptions is important: the LLM does not see the entity names directly (e.g., it sees "a European city whose official language is English and whose population exceeds five million" rather than "London"), which prevents the LLM from generating questions that leak the answer or provide unintended shortcuts.

Data Quality Assurance

After question generation, every example passes through a two-pronged quality assurance protocol (Section 3.5) designed to validate the two properties that make the dataset useful for training: difficulty (the question cannot be solved from parametric memory alone) and verifiability (the question is factually grounded and has a unique correct answer).

Difficulty check. The paper challenges Qwen2.5-32B-Inst to answer each generated question directly — that is, without any search or retrieval, using only the model's parametric knowledge. The model is given the question text and must produce an answer. The paper reports that the model correctly answered only 2% of questions, confirming that "the dataset's high degree of challenge" — the questions are not solvable by simply recalling facts memorized during pretraining. The 2% of questions that the model does answer correctly are removed from the dataset to increase difficulty, since these questions have effective shortcuts (the model can answer them without the hierarchical reasoning the training is supposed to teach).

Why Qwen2.5-32B-Inst as the difficulty checker: the paper chooses a strong open-source model (32B parameters) that is substantially larger than the target training model (3B). If even a 32B model with strong parametric knowledge cannot answer the questions, it is highly unlikely that a 3B model could do so without search and reasoning. This establishes a lower bound on difficulty: any model that succeeds on these questions must be using the search and reasoning capabilities that the training aims to develop, not relying on memorization.

Verifiability check. This check addresses the underdetermination problem: even if the Research Tree construction procedures aim to ensure uniqueness, there may be edge cases where the constraints are ambiguous or contradictory, or where the source webpages contain factual errors. To validate verifiability, the paper presents Gemini 2.5 Flash with:

  1. The ground-truth web pages from the constructed search path — the actual pages that the Browser agent used to extract entities, relations, and constraints during tree construction.
  2. A set of distractor documents — web pages that are topically related but do not contain the answer.
  3. The task of deriving the correct answer from this provided context.

Questions are filtered out if Gemini 2.5 Flash produces a wrong answer, identifies multiple possible answers, or declares the question unsolvable. This process "effectively prevents the underdetermined issue" (Section 3.5) by ensuring that when a capable LLM is given exactly the information that the tree construction used, it can uniquely determine the correct answer.

Why Gemini 2.5 Flash as the verifiability checker: the verifiability check requires a model that can accurately read and synthesize information from multiple documents — exactly the capability that deep research agents are supposed to have. Gemini 2.5 Flash is a strong commercial API that the paper also uses as a baseline for comparison on BrowseComp-Plus, making it a credible validator. Using a different model for validation than for difficulty checking (Qwen2.5-32B-Inst vs. Gemini 2.5 Flash) also provides independent signals: difficulty is validated against parametric memory, while verifiability is validated against retrieval-augmented reading comprehension.

Why quality assurance filters rather than fixes: the paper's approach is to discard problematic questions rather than attempt to repair them. This is a practical choice: repairing an underdetermined question would require adding more constraints, which might introduce new factual errors or change the tree structure in ways that affect other vertices. Filtering is simpler, more reliable, and — given the pipeline's scalability (producing 50K+ examples for $571.80) — the cost of discarding some fraction of generated questions is acceptable. The final dataset of 52,138 questions (Table 2) represents the output after both filtering stages.

From Dataset to Trained Model: The InfoSeeker Training Pipeline

The paper does not merely release a dataset; it demonstrates the dataset's utility by training a compact 3B model (InfoSeeker) that achieves strong performance on deep research benchmarks. This section explains the training pipeline in detail, since it represents a concrete instantiation of how InfoSeek's data enables model optimization.

The two-stage training philosophy. The paper adopts a two-stage approach common in contemporary LLM post-training: supervised fine-tuning (SFT) to bootstrap capabilities from teacher demonstrations, followed by reinforcement learning (RL) to further optimize through exploration and reward. The key innovation is not the training algorithms themselves (SFT and GRPO are both well-established in the literature) but rather the data construction strategies — rejection sampling to create high-quality SFT trajectories, and the use of InfoSeek's multi-layered problems as the RL training environment.

Rejection sampling for SFT trajectory construction. The fundamental challenge in training deep research agents is the "vast exploration space of complex, multi-step reasoning tasks" (Section 4.2). A model acting on its own from scratch would rarely stumble upon correct multi-step reasoning chains — the space of possible sequences of search queries, reasoning steps, and answer syntheses is combinatorially large, and the reward signal (correct final answer) is sparse. Direct RL from the base model would be "unstable and inefficient."

To solve this, the paper uses rejection sampling to construct a dataset of successful reasoning trajectories. The process:

  1. Take the 50K+ InfoSeek questions (plus 5K NQ and HotpotQA examples to preserve general agentic search capability).
  2. For each question, use a teacher model — Qwen2.5-72B, a substantially larger and more capable model than the 3B target — to attempt to solve the question using the InfoSeeker workflow (multi-query search, Refiner Agent, think-before-action, etc., described in the next section). Roll out each question twice.
  3. Retain only those trajectories where the teacher model successfully completes the task and produces a demonstrably correct final answer.
  4. Further filter using Gemini 2.5 Flash to check for search or reasoning shortcuts — trajectories where the answer was found trivially (e.g., the first search query directly returned the answer, bypassing the hierarchical reasoning structure).
  5. The paper reports obtaining 24K valid trajectories from 55K attempts (50K InfoSeek + 5K NQ/HotpotQA, each rolled out twice), implying a teacher model accuracy of approximately 21.8% on the InfoSeek problems under the InfoSeeker workflow. The paper deliberately retains shortcut cases among the correct trajectories, arguing that "preserving diverse solution strategies offers valuable learning signals for small LLMs during the early stages of training" (Appendix A.1).

These 24K trajectories form the SFT dataset. Each trajectory includes the full sequence of thinking steps, search queries, retrieved results, Refiner Agent summaries, and the final answer — enabling the student model to learn not just what the answer is, but how to arrive at it.

Round 1 SFT. The base model (Qwen2.5-3B-Inst) is fine-tuned on the 24K trajectories for 2 epochs with hyperparameters: learning rate $1 \times 10^{-5}$, weight decay 0.01, context length 16,384 tokens. Training runs on a single 8×H100 node and completes in 2 hours, yielding InfoSeeker-3B-SFT-Round1. The short training time and modest compute requirements are notable — this is a practical training recipe, not a resource-intensive one.

Round 1 RL with GRPO. Following SFT, the model undergoes reinforcement learning using Group Relative Policy Optimization (GRPO), a policy gradient algorithm introduced by Shao et al. (2024) and used in DeepSeek-R1 (Guo et al., 2025). The objective function is:

JGRPO(θ)=E[1G∑i=0G1∣Y∣−∣K∣∑t=1:I(Yt)=1∣Y∣min⁡(ri,tAi,t,clip(ri,t,1−ϵ,1+ϵ)Ai,t)−βDKL(πθ∣∣πref)]J_{\text{GRPO}}(\theta) = \mathbb{E}\left[ \frac{1}{G} \sum_{i=0}^{G} \frac{1}{|Y| - |K|} \sum_{t=1: I(Y_t)=1}^{|Y|} \min(r_{i,t} A_{i,t}, \text{clip}(r_{i,t}, 1 - \epsilon, 1 + \epsilon) A_{i,t}) - \beta D_{\text{KL}}(\pi_\theta || \pi_{\text{ref}}) \right]

where:

  • $G$ is the number of outputs in a group (rollout size, set to 5 in the paper)
  • $Y$ is the output sequence
  • $K$ is a subset of tokens (details not fully specified, but typical in GRPO implementations it refers to tokens that are part of retrieved content, which may be treated differently in the loss computation)
  • $I(Y_t) = 1$ indicates tokens that are part of the model's generated content (not tool outputs)
  • $r_{i,t} = \frac{\pi_\theta(Y_{i,t} | X, Y_{i,<t}, K_{i,<t})}{\pi_{\theta_{\text{old}}}(Y_{i,t} | X, Y_{i,<t}, K_{i,<t})}$ is the probability ratio between the current policy $\pi_\theta$ and the old policy $\pi_{\theta_{\text{old}}}$ used to generate the rollout
  • $A_{i,t}$ is the advantage estimate for token $t$ in output $i$
  • $\epsilon$ is the clipping parameter (standard PPO-style clipping to prevent excessively large policy updates)
  • $\beta$ controls the strength of the KL divergence penalty $D_{\text{KL}}(\pi_\theta || \pi_{\text{ref}})$, which keeps the policy close to a reference policy (typically the SFT model) to prevent catastrophic forgetting

What it computes: GRPO is a policy gradient method that optimizes the model's policy $\pi_\theta$ (the probability distribution over output tokens given the input context) to maximize expected reward. Unlike standard PPO, GRPO does not use a separate value network to estimate advantages. Instead, for each input $X$, it generates a group of $G$ outputs using the old policy, computes a reward for each, and estimates the advantage as the normalized reward:

Ai,t=Ri−mean(R)std(R)A_{i,t} = \frac{R_i - \text{mean}(R)}{\text{std}(R)}

where $R = \{R_1, R_2, \ldots, R_G\}$ are the rewards for the $G$ outputs in the group. This means an output earns positive advantage if its reward is above the group mean and negative advantage if below — the model is trained to increase the probability of outputs that outperform their peers and decrease the probability of those that underperform.

Why GRPO over PPO: the key advantage of GRPO for this setting is that it eliminates the need for a value network, which (1) reduces memory requirements — important for training on a single 8×H100 node — and (2) avoids the challenge of training a value function that can accurately predict future returns in the complex, sparse-reward setting of multi-step search and reasoning. The group-based advantage normalization provides a simple but effective signal: on each question, the best-performing trajectories are reinforced relative to the worst-performing ones.

Round 1 reward design. The paper uses a binary outcome-based reward:

R={1if format and extracted answer are both correct0otherwiseR = \begin{cases} 1 & \text{if format and extracted answer are both correct} \\ 0 & \text{otherwise} \end{cases}

This is deliberately simple. The model has already learned the desired output format (thinking, search queries, answer extraction) from SFT; the RL phase only needs to reinforce correct answers. The binary reward provides a clear, unambiguous signal: only trajectories that produce both the correct format and the correct answer receive positive reinforcement.

Round 1 RL configuration: batch size 256, maximum 10 turns per rollout, rollout size 5, temperature 0.8, search restricted to top-5 retrieved results. Training runs for 200 GRPO steps, yielding InfoSeeker-3B-RL-Round1.

Round 2: iterative refinement. The paper observes that one round of SFT+RL is not sufficient — to achieve strong deep research performance, a second round of data filtering and training is necessary. The Round 2 process:

  1. Rejection sampling with the Round 1 model: InfoSeeker-3B-RL-Round1 is used to generate trajectories on 55K source samples. The model produces 16,494 trajectories.
  2. Gemini 2.5 Flash filtering: these trajectories are evaluated by Gemini 2.5 Flash, which checks for multi-turn search patterns, fine-grained task decomposition, and accurate step-by-step reasoning. Only 3,450 trajectories pass this quality filter — a 20.9% acceptance rate.
  3. Round 2 SFT: the 3,450 high-quality trajectories are used to fine-tune the model again with the same hyperparameters as Round 1 (2 epochs, lr $1 \times 10^{-5}$, weight decay 0.01, context length 16,384), yielding InfoSeeker-3B-SFT.
  4. Round 2 RL: from the original 55K data pool, 17K harder samples are selected (15K InfoSeek, 2K NQ/HotpotQA). Before training, the model generates preliminary answers, and only the 14K samples it fails on are retained for RL — this ensures the model focuses on problems it cannot yet solve. GRPO is run for 100 steps without KL loss (the KL penalty term is removed, allowing the model to move further from the reference policy on these challenging problems), yielding the final InfoSeeker-3B.

Why the two-round approach: the first round bootstraps basic deep research capabilities from teacher demonstrations; the second round refines them by focusing on the model's own failures. The Gemini 2.5 Flash filtering in Round 2 is crucial — it selects for trajectories that exhibit the desired reasoning patterns (multi-turn search, fine-grained decomposition) rather than just correct answers, providing a quality signal beyond binary correctness. The progressive focusing on harder problems in Round 2 RL (selecting only problems the model fails on) is a standard curriculum learning strategy that prevents the model from wasting capacity on problems it already solves easily.

The InfoSeeker Workflow: Runtime Architecture with Multi-Query Search and Refiner Agent

The InfoSeeker model, after training, operates using a specific inference-time workflow (Section 4.1, Figure 3) that is separate from the data synthesis pipeline but represents the runtime manifestation of the capabilities the training imparts. The workflow is designed to address a specific practical challenge in agentic search: as models perform multi-turn, multi-query search, the context window quickly fills with redundant or noisy evidence, causing models to lose focus.

Think Before Action. Each reasoning turn begins with an explicit thinking phase, delimited by XML-style tags: thinking and response. During this phase, the model reflects on what has already been gathered and plans what information remains necessary. The paper cites Yao et al. (2023) (ReAct), Jaech et al. (2024) (OpenAI o1), and Guo et al. (2025) (DeepSeek-R1) as precedents for explicit thinking phases that improve reasoning quality. The thinking phase produces structured text (not shown to the user or search engine) that guides the subsequent query generation.

Parallelized Multi-Query Search. A central innovation in the InfoSeeker workflow is that, within a single reasoning step, the model generates multiple diverse search queries rather than a single one. These queries are enclosed within <search> and </search> tags and are designed to comprehensively address the current information need from multiple angles. The paper argues that this parallel approach "broadens the informational coverage and accelerates the exploration process compared to a sequential, single-query strategy" (Section 4.1).

Why parallel queries help: a single query might retrieve documents focused on one aspect of a multi-faceted question, missing other relevant angles. Multiple queries, each targeting a different constraint or sub-question of the HCSP, increase the probability that all needed information is retrieved in a single step rather than requiring multiple sequential search rounds. This is particularly important for HCSPs, where the model needs to satisfy multiple parallel constraints that may be documented in different sources.

Refiner Agent for Summarization. The most distinctive component of the InfoSeeker workflow is the Refiner Agent — a separate, lightweight model (Qwen2.5-7B-Inst, chosen for efficiency and sufficiency) that processes raw search results into concise summaries. For each query generated by InfoSeeker:

  1. The search engine returns the top-k retrieved results (the paper uses top-5).
  2. These results are passed to the Refiner Agent, which extracts salient evidence and produces a summary aligned with the query's intent.
  3. The Refiner Agent also offers "recommendations for subsequent reasoning steps" (Section 4.1) — meta-commentary that helps InfoSeeker decide what to search for next.
  4. Summaries are paired with their originating queries and wrapped in <information> and </information> tags before being added to InfoSeeker's context.

Why a separate Refiner Agent rather than having InfoSeeker process raw results: the paper identifies a critical scaling problem — "in multi-turn, agentic ReAct rollouts, this quickly leads to bloated contexts filled with redundant or noisy evidence, causing the model to lose focus" (Section 4.1). By offloading summarization to a dedicated agent, InfoSeeker's working context remains compact and tractable while maintaining high recall. This is an inference-time architecture choice that complements the training data: InfoSeek teaches the model what to search for and how to integrate evidence; the Refiner Agent helps manage the practical challenge of too much evidence.

Output Answer. When InfoSeeker determines that sufficient information has been accumulated, or when the maximum number of search steps (10 turns in the RL configuration) is reached, it produces the final answer enclosed within <answer> and </answer> tags.

The complete inference loop. One full step of the InfoSeeker workflow proceeds as: (1) Think phase — model reflects and plans; (2) Query generation — model produces multiple <search> queries; (3) Retrieval — search engine returns top-5 results per query; (4) Refinement — Refiner Agent summarizes each query's results; (5) Integration — summaries are added to context within <information> tags; (6) Decision — model decides whether more information is needed (go to step 1) or whether to produce the final answer (go to output). This loop continues until termination, with the model's context growing incrementally through Refiner Agent summaries rather than raw search results.

Why this workflow design matters for the overall paper: it demonstrates that InfoSeek's training data produces models that not only answer questions correctly but also exhibit sophisticated search behaviors — generating multiple queries in parallel, interleaving thinking with retrieval, and coordinating with auxiliary agents for information processing. These behaviors emerge from training on data that was itself constructed through hierarchical reasoning (the Research Tree process), suggesting that the structural properties of the training data shape the model's learned reasoning strategies. The BrowseComp-Plus results (Table 4) show InfoSeeker-3B averaging 8.24 search calls — substantially more than the 0.92 calls of the untrained Qwen3-32B — indicating that the model has learned to engage in extended, multi-step search rather than attempting to answer from memory or with a single retrieval.

4. Key Insights and Innovations

Innovation 1: Deep Research as Hierarchical Constraint Satisfaction — A Formal Definition That Separates Problem Types

The paper's most foundational contribution is not any specific algorithm or dataset, but rather the conceptual reframing of verifiable Deep Research questions as Hierarchical Constraint Satisfaction Problems (HCSPs). This formalization does something that prior work in agentic search and multi-hop QA had not done: it provides a principled, mathematically precise distinction between problem types that the field had previously conflated under vague terms like "complex reasoning" or "multi-step QA."

What the field had before. Prior work organized reasoning tasks along a single axis of complexity — single-hop vs. multi-hop, with "multi-hop" serving as a catch-all for anything requiring more than one retrieval or inference step. HotpotQA (Yang et al., 2018) defined the two-hop bridge and comparison question formats; 2WikiMultihopQA (Ho et al., 2020) extended this to longer chains; Musique (Trivedi et al., 2022b) composed multi-hop questions from single-hop building blocks. All of these share a common structural assumption: reasoning proceeds as a linear chain of dependencies, where each step's output feeds into the next. Even when questions involved multiple constraints, these constraints were either flattened into the chain structure or treated as independent retrieval targets.

The problem with this assumption is that it fails to capture what makes real Deep Research tasks qualitatively different. Consider the paper's running example (Figure 2): "This mathematician, born in a European city whose official language is English and whose population exceeds five million, studied at Cambridge and later earned his PhD at Princeton University in 1938. Who is he?" This is not simply a 4-hop or 5-hop chain — it requires solving a parallel constraint satisfaction sub-problem (identifying London from three simultaneous conditions) before integrating that result with sequential dependencies (the education history). A model that has only been trained on linear chains will never encounter the need to perform parallel constraint intersection as a sub-routine within a larger sequential reasoning process.

The HCSP formalization as a diagnostic tool. The paper's mathematical characterization (Equations 1–3) decomposes the reasoning space along two orthogonal axes: parallel constraints (breadth — how many independent conditions must be simultaneously satisfied at each reasoning node) and sequential dependencies (depth — how many layers of sub-problems must be resolved before reaching the answer). CSPs are pure parallel (breadth, no depth), multi-hop problems are pure sequential (depth, no breadth at each node beyond a single constraint), and HCSPs combine both in a tree structure where intermediate nodes are themselves CSPs that must be solved before their outputs propagate upward.

This decomposition is more than taxonomic — it is mechanistically predictive. The paper's experimental results in Section 5 demonstrate that models trained on flat CSP data (NQ, single-hop) and linear-chain data (HotpotQA, two-hop) fail catastrophically on HCSP-structured problems (3.0% on BrowseComp-Plus, Table 5), while models trained on HCSP data succeed (16.5%). The formalization explains why: flat and linear-chain training distributions do not teach the parallel constraint integration operations that HCSPs require at intermediate nodes. A model that has never learned to intersect three candidate sets to identify a city cannot spontaneously develop this capability when confronted with a problem that embeds such an intersection within a larger reasoning chain.

Theoretical significance beyond this paper. The HCSP framework connects Deep Research to classical AI work on constraint satisfaction, hierarchical planning, and evidence integration — literatures that have been largely separate from the modern LLM-based agentic search community. By formalizing Deep Research in these terms, the paper opens the door to importing techniques from constraint propagation, arc consistency, and hierarchical task networks into LLM-based reasoning systems. The tree representation (Section 2.3) is particularly significant because it provides a constructive bridge: any HCSP can be represented as a Research Tree, and any well-formed Research Tree can be converted to an HCSP. This means that the problem of synthesizing deep research training data reduces to the problem of constructing valid Research Trees — a much more tractable engineering challenge than generating complex questions directly from text.

This is a fundamental conceptual advance, not an incremental refinement of existing QA taxonomies. It changes the question from "how do we make models better at multi-hop reasoning?" (which implicitly accepts the linear-chain framing) to "how do we teach models to perform hierarchical constraint propagation?" — a qualitatively different capability that the field had not previously named or isolated.

Evidence anchor. The BrowseComp-Plus results in Table 4 and the training data ablation in Table 5 provide the strongest empirical support. If HCSP structure were merely a relabeling of multi-hop complexity, training on NQ+HotpotQA (which covers both single-hop and linear-chain multi-hop) should transfer at least partially to BrowseComp-Plus. The near-zero transfer (3.0% accuracy) demonstrates that the structural gap between linear-chain reasoning and hierarchical constraint satisfaction is real and large — models do not generalize across this gap without explicit training on HCSP-structured data.

Innovation 2: A Scalable, Grounded Synthesis Pipeline That Replaces LLM-Based Generation with Rule-Based Tree Construction

The paper's second major insight is an architectural choice about how to synthesize complex reasoning data at scale, and it represents a departure from the dominant paradigm in the field. Most prior work on synthetic data generation for reasoning tasks — from WebShaper (Tao et al., 2025) to the various distillation pipelines used in Orca-style training — relies on large language models as the primary content generation engine: prompt an LLM with specifications, have it generate questions, filter the output. This approach can produce high-quality individual examples but scales poorly because each example requires an expensive LLM inference call, and the generated content is prone to hallucination, factual inconsistency, and structural drift (the LLM may produce questions that appear complex but contain unintended shortcuts or violate the intended reasoning structure).

InfoSeek inverts this paradigm: structure first, language second. The core synthesis operations — extracting entities from webpages, identifying relationships via hyperlinks, selecting atomic claims for constraint addition, building and expanding the Research Tree — are all rule-based, deterministic, and grounded in actual web content. The only stage that uses an LLM for generation is the final conversion of the completed Research Tree into natural language, and even this stage is tightly constrained: the LLM receives the structured "blurred" vertex descriptions and is instructed to produce a question that requires traversing the full hierarchy. The LLM is not inventing the reasoning structure; it is translating a pre-computed structure into fluent text.

Why this matters for scalability. The paper reports producing 52,138 high-quality questions for 571.80intotalAPIcosts(Table2).Atthispricepoint—approximately571.80 in total API costs (Table 2). At this price point — approximately 0.011 per question — InfoSeek makes large-scale deep research data synthesis economically viable for the open-source community. Prior approaches that rely on LLMs for every step of question generation would be orders of magnitude more expensive: even at conservative per-call costs for GPT-4-level models, generating 50K complex questions via pure LLM prompting could cost tens of thousands of dollars. This cost differential is not incidental; it is what enables InfoSeek to be the first large-scale open-source deep research dataset (Table 1).

The deeper insight: groundedness as a correctness guarantee. By extracting all entities, relationships, and constraints directly from actual webpages — with explicit evidence traces recording the specific sentence or hyperlink used — InfoSeek eliminates the hallucination problem that plagues LLM-based data synthesis. When an LLM generates a question like "Which scientist, born in a city that..." it may produce constraints that are factually incorrect, internally inconsistent, or that admit multiple answers. InfoSeek's approach guarantees that every constraint corresponds to a real sentence in a real webpage, and the tree construction procedures ensure (with quality assurance validation) that the constraints collectively identify a unique answer. This groundedness is not just about factual accuracy — it is about verifiability as a property of the synthesis process itself, not just a post-hoc check.

Comparison to WebShaper. Tao et al. (2025) adopted a similar formalization-driven philosophy — define the reasoning graph before generating the question — but their implementation appears to have relied more heavily on LLM-based generation and manual curation, yielding only 500 examples. The contrast with InfoSeek's 50K+ examples highlights that the key insight is not the idea of formalization-driven synthesis (which WebShaper also had) but the engineering decision to make the core construction operations rule-based and grounded in web-scale text rather than LLM-generated. This is an incremental refinement of WebShaper's conceptual approach but a fundamental advance in scalability and practical utility — it transforms a proof-of-concept into infrastructure.

The dual-agent decomposition as scalability enabler. The separation of Planner and Browser (Section 3) embodies a deeper design principle: separate strategic decisions (which are rare and can afford computational cost) from tactical execution (which is frequent and must be cheap). The Planner makes high-level choices about tree structure — which vertex to expand, whether to add constraints or depth — decisions that occur perhaps 4-7 times per question (given the vertex counts in Table 2). The Browser performs the actual content extraction — parsing webpages for claims and hyperlinks — operations that may occur dozens of times per question but are lightweight and parallelizable. This decomposition is not theoretically novel (it echoes classical AI architectures like STRIPS planners with separate execution monitors), but its application to data synthesis at this scale is distinctive. Prior work in synthetic data generation for reasoning has not, to my knowledge, employed this kind of structured two-agent pipeline with the explicit goal of making synthesis scalable and grounded.

Evidence anchor. Table 2 provides the direct evidence: 52,138 questions synthesized for $571.80. The cost breakdown is not itemized by stage, but the implication is clear — the rule-based tree construction dominates the pipeline in terms of volume while contributing negligibly to cost, and the LLM-based question generation and quality assurance stages (which do use commercial APIs) account for the reported costs. The BrowseComp-Plus results (Table 4) then validate that this cheaply-produced data is effective for training — the quality has not been sacrificed for scale.

Innovation 3: Demonstrating That Structured Training Data Can Substitute for Model Scale — With Sharp Boundary Conditions

The paper's headline result — a 3B model trained on InfoSeek outperforming 32B open-source models and competing with commercial APIs on BrowseComp-Plus (Figure 1, Table 4) — is not merely a performance claim. It is an empirical argument about the relationship between data structure and model capacity that challenges a dominant assumption in the field: that complex reasoning capabilities require large models.

The implicit assumption in prior work. The agentic search and reasoning literature has largely operated on the premise that deep research requires large, capable models. Systems like Search-o1 (Li et al., 2025b), Search-R1 (Jin et al., 2025), and commercial offerings like Gemini Deep Research and OpenAI's Deep Research product are built on top of frontier-scale LLMs. The inference-time agentic frameworks surveyed in Section 6 — Agentic Reasoning, AgentOrchestra, Cognitive Kernel-Pro — are designed to orchestrate powerful models, not to make small models capable. The underlying assumption is that the planning, decomposition, and evidence synthesis required for deep research are emergent properties of scale, and that smaller models simply lack the capacity to perform these operations.

InfoSeek's results challenge this assumption by demonstrating that a 3B model — roughly 1/250th the parameter count of frontier models — can achieve deep research performance comparable to much larger systems when trained on appropriately structured data. InfoSeeker-3B's 16.5% on BrowseComp-Plus surpasses Qwen3-32B (3.5%), SearchR1-32B (3.9%), Gemini 2.5 Flash (15.5%), Sonnet 4 (14.3%), and GPT-4.1 (14.6%). These are not marginal improvements; they represent a qualitative jump in capability that cannot be attributed to differences in training algorithms (many of the baselines use similar SFT+RL pipelines) or inference-time scaffolding (InfoSeeker uses a straightforward search-and-refine workflow).

The mechanism: data structure as a compression of reasoning capability. The paper's implicit argument — never stated explicitly but evident in the experimental design — is that the structural properties of the training data encode reasoning patterns that large models discover through scale, and that explicitly providing these patterns in the data can compensate for reduced model capacity. An HCSP-structured question requires a model to perform specific operations: decompose a complex query into sub-problems, recognize which sub-problems are parallel vs. sequential, execute parallel constraint intersections, propagate intermediate results upward, and synthesize a final answer. A large model might learn to perform these operations implicitly from exposure to diverse text during pretraining, while a small model needs them explicitly demonstrated in its fine-tuning data. InfoSeek provides exactly these demonstrations, and the results suggest they are sufficient.

This is not a universal claim — the paper is careful to show that InfoSeek's advantage is domain-specific and comes with sharp boundary conditions. The single-hop and multi-hop QA results in Table 3 show InfoSeeker-3B performing competitively but not dramatically better than baselines — the structural advantages of HCSP training data are most pronounced on HCSP-structured evaluation tasks (BrowseComp-Plus), and they provide diminishing returns on simpler problem types where flat or linear-chain reasoning suffices. This is exactly what one would expect if the mechanism is data-structure-to-capability compression: the training data teaches specific reasoning patterns that are only useful when the evaluation requires those patterns.

The BrowseComp-Plus results as a diagnostic, not just a benchmark. The paper's choice of BrowseComp-Plus as the primary evaluation is significant because this benchmark was specifically designed (Wei et al., 2025; Chen et al., 2025b) to require deep, multi-step web search and evidence synthesis — precisely the HCSP-like reasoning that InfoSeek trains for. The fact that Qwen3-32B scores only 3.5% while InfoSeeker-3B scores 16.5% is not just a metric gap; it is evidence that BrowseComp-Plus captures a capability dimension that is orthogonal to model scale and is instead determined by training data structure. The 0.92 average search calls for Qwen3-32B vs. 8.24 for InfoSeeker-3B (Table 4) further supports this interpretation: the larger model barely attempts multi-step search, suggesting it does not recognize that the problems require it, while the smaller trained model engages in extended search behavior that mirrors the hierarchical decomposition patterns in its training data.

Comparison to scaling laws literature. This finding connects to a broader debate about whether reasoning capabilities are emergent properties of scale (Wei et al., 2022, on emergent abilities) or can be induced in smaller models through targeted training (the Orca/distillation literature). InfoSeek provides evidence for the latter position in the specific domain of hierarchical information-seeking, but with an important nuance: the training data must encode the structural properties of the target reasoning patterns, not just the surface form. Simply training on more NQ or HotpotQA examples (which Table 5 shows fails to transfer to BrowseComp-Plus) is insufficient; the data must be structurally isomorphic to the target tasks.

This is a significant empirical finding rather than a theoretical advance — it does not propose a new theory of why data structure matters, but it provides strong evidence that it does matter, and that the effect size can be large enough (4–5× improvement over same-size baselines, exceeding models 10× larger) to be practically consequential. The finding is incremental in the sense that it extends the "data quality over quantity" narrative that has been building in the field, but it is distinctive in providing a clear mechanistic hypothesis (HCSP structure teaches hierarchical constraint propagation) and a clean experimental test (BrowseComp-Plus as a held-out benchmark that requires exactly this capability).

Evidence anchor. Figure 1 and Table 4 provide the primary evidence: InfoSeeker-3B at 16.5% vs. Qwen3-32B at 3.5% on BrowseComp-Plus. Table 5 provides the ablation that isolates data structure as the causal factor: same backbone model (Qwen2.5-3B-Inst), same training algorithm (RL), but InfoSeek training data yields 16.5% while NQ+HQA yields 3.0%. The 5.5× gap cannot be explained by model scale, training algorithm, or inference-time scaffolding — it must be attributed to the structural properties of the training data.

Innovation 4: Preserving Intermediate Structure as a Byproduct of Tree-Based Synthesis Enables Richer Training Signals

The paper flags a technical contribution that is easy to undervalue because it is not a metric or an algorithm, but rather a property of the data that emerges from the synthesis methodology: because InfoSeek constructs questions by building Research Trees — where every vertex, edge, constraint, and evidence trace is explicitly recorded — the resulting dataset preserves meta-information that is absent from virtually all prior QA datasets. This includes the decomposition of each question into sub-problems, the specific constraints at each reasoning node, the ground-truth intermediate entities, and the retrieval provenance (which webpage and sentence supports each fact).

What prior datasets provide. Standard QA datasets like Natural Questions and HotpotQA provide question-answer pairs. Some (like HotpotQA) include supporting facts or evidence documents, but these are at the question level — they document which passages support the final answer, not how the reasoning should decompose into intermediate steps. Recent agentic search trajectory datasets (SimpleDeepSearcher's 871 trajectories, WebDancer's 200 examples) provide reasoning traces, but these are execution traces from specific models solving specific problems, not ground-truth decompositions that encode the intended reasoning structure. They tell you "how Model X solved problem Y" rather than "what the logical structure of problem Y is."

What InfoSeek provides that is distinctive. Because InfoSeek constructs the Research Tree before generating the question, the tree itself serves as a ground-truth reasoning blueprint. For any question in the dataset, one can recover:

  • The full tree structure showing which sub-problems must be solved and in what order
  • The specific constraints at each vertex (e.g., for the London sub-problem: "European city," "official language English," "population > 5 million")
  • The ground-truth answer at each intermediate node (London, Cambridge, Princeton, etc.)
  • The evidence provenance for each constraint (the specific webpage and sentence)
  • The dependency relationships encoded in edges (which facts must be retrieved before which reasoning steps can proceed)

This meta-information enables training signals that go beyond binary answer correctness. The paper explicitly notes this as enabling "compound reward design and trajectory-level optimization" (Section 1, Section 7) — reinforcement learning approaches that can provide feedback not just on whether the final answer is correct, but on whether intermediate reasoning steps were valid, whether the model correctly decomposed the problem, whether retrieved evidence was properly integrated, and whether sub-questions were correctly formulated. These richer signals could address a key challenge in training deep research agents: the sparsity of outcome-based rewards in complex, multi-step reasoning tasks.

Why this matters for future work. The paper does not itself exploit this meta-information beyond the basic SFT+RL pipeline (which uses only binary outcome rewards) — the authors flag it as an opportunity for future work. But the availability of this information in an open-source dataset is itself a contribution that could enable a new class of training methods. Consider: with InfoSeek's intermediate labels, one could train a process reward model (PRM) for deep research — analogous to the PRMs used in mathematical reasoning (Lightman et al., 2023) — that scores not just final answers but the validity of individual sub-question decompositions, the relevance of retrieved evidence, and the logical soundness of constraint integration steps. Such a PRM could then guide test-time search over reasoning strategies in the same way that math PRMs guide search over solution steps, potentially enabling compute-optimal test-time scaling for deep research tasks. This is speculative, but the point is that InfoSeek's meta-information makes such approaches possible, whereas prior datasets provide no foundation for them.

Comparison to process supervision in reasoning. The paper's emphasis on preserving intermediate structure parallels a major trend in mathematical reasoning research, where process supervision (step-level feedback) has been shown to be more effective than outcome supervision (final answer only) for training models and guiding search (Lightman et al., 2023; Uesato et al., 2022). InfoSeek brings this insight to the domain of information-seeking and evidence synthesis, but with a crucial difference: in math reasoning, process supervision requires expensive human annotation of intermediate solution steps, whereas in InfoSeek, the intermediate structure is a free byproduct of the tree-based synthesis methodology. This is a significant practical advantage because it means process-supervised training for deep research does not face the annotation bottleneck that limits math reasoning research — the training signal is generated automatically as part of data synthesis.

Evidence anchor. This innovation is not directly evaluated with an ablation (the paper does not compare training with vs. without the intermediate labels), so the significance is prospective rather than demonstrated. The paper points to the meta-information availability in Section 1 ("InfoSeek preserves meta-information such as intermediate steps and retrieval labels, it offers valuable signals for designing more sophisticated RL rewards") and Section 7 ("it opens new opportunities for compound reward design and trajectory-level optimization"), and the tree construction procedures in Section 3 explicitly record all intermediate structure. The innovation is a capability claim about the dataset rather than an empirical finding, but it is substantively important because it differentiates InfoSeek from prior datasets in a dimension that the field has identified as valuable (process supervision) but has struggled to provide at scale.

5. Experimental Analysis

Evaluation Methodology

  • Dataset. The paper evaluates on two tiers of benchmarks. For single-hop and multi-hop QA, it uses Natural Questions (NQ; Kwiatkowski et al., 2019), TriviaQA (TQA; Joshi et al., 2017), PopQA (Mallen et al., 2022), HotpotQA (HQA; Yang et al., 2018), 2WikiMultihopQA (2Wiki; Ho et al., 2020), Musique (MSQ; Trivedi et al., 2022b), and Bamboogle (Bamb; Press et al., 2022). For deep research capability, it uses BrowseComp-Plus (Chen et al., 2025b), a filtered subset of 830 problems from the original BrowseComp benchmark (Wei et al., 2025), with a fixed corpus of 100K web pages. The choice of BrowseComp-Plus is deliberate: it was specifically designed to test open-ended, search-intensive reasoning that cannot be solved from parametric memory alone, making it a natural evaluation target for the HCSP-structured capabilities that InfoSeek trains for.

  • Base model(s). The primary model trained and evaluated is Qwen2.5-3B-Inst (Group, 2025), a 3-billion-parameter instruction-tuned LLM. The choice of a 3B model is strategic: it allows the paper to test whether structured training data can compensate for limited model capacity, and the results are compared against models up to 10× larger (32B) and commercial APIs of unknown but presumably much larger scale. For the FLOPs-matched-style comparison (Table 4), the baselines include Qwen3-32B (Yang et al., 2025), SearchR1-32B (Jin et al., 2025), Gemini 2.5 Flash and Pro (Comanici et al., 2025), Sonnet 4 (Anthropic, 2025), GPT-4.1 (OpenAI, 2023), and GPT-5 (OpenAI, 2025). For the difficulty check during data quality assurance (Section 3.5), Qwen2.5-32B-Inst serves as the parametric memory probe. For the Refiner Agent during inference, Qwen2.5-7B-Inst (Yang et al., 2024) is used.

  • Metrics. For single-hop and multi-hop QA benchmarks (NQ, TQA, PopQA, HQA, 2Wiki, MSQ, Bamb), the metric is Exact Match (EM) — the fraction of questions for which the model's extracted answer string exactly matches the ground-truth answer after normalization. For BrowseComp-Plus, the paper follows the official evaluation protocol using LLM-as-judge to assess answer correctness. Additionally, Table 4 reports average search calls per question as a behavioral metric indicating how extensively the model engages in multi-step retrieval. Table 2 reports Qwen2.5-72B failure rate under Chain-of-Thought prompting (Wei et al., 2022) as a proxy for dataset difficulty, and token length statistics for questions and answers.

  • Baselines. The paper compares against three categories of prior work. RAG-based methods: (1) Vanilla RAG, which retrieves top-k documents once and prepends them to the prompt; (2) IRCoT (Trivedi et al., 2022a), which alternates retrieval with chain-of-thought reasoning; (3) RQRAG (Chan et al., 2024), which refines queries through rewriting and decomposition; (4) Self-RAG (Asai et al., 2023), which introduces self-reflection for critiquing and revising outputs based on retrieved evidence. Agentic search methods: (1) Search-o1-3B (Li et al., 2025b), which adds an agentic retrieval module and a Reason-in-Documents component; (2) Search-R1-3B (Jin et al., 2025), which uses RL to teach interleaving search queries with reasoning; (3) ZeroSearch-3B (Sun et al., 2025a), which trains search agents via RL without real search engines by simulating retrieval; (4) AutoRefine-3B (Shi et al., 2025b), which introduces search-and-refine-during-think via RL; (5) InForage-3B (Qian & Liu, 2025), which incorporates intermediate retrieval rewards into agentic RL training. BrowseComp-Plus commercial and open-source baselines: Gemini 2.5 Flash, Gemini 2.5 Pro, Sonnet 4, GPT-4.1, GPT-5, Qwen3-32B, and SearchR1-32B.

  • Generation budget / compute accounting. For the single-hop and multi-hop QA benchmarks, retrieval uses Wikipedia-25 as the corpus with documents segmented into 512-token chunks, and BGE-M3 (Chen et al., 2023) for embedding-based retrieval with top-5 documents selected. For BrowseComp-Plus, BM25 (Robertson et al., 2009) serves as the retrieval method over the 100K web page corpus. The paper does not report total FLOPs or wall-clock time for inference, but Table 4 reports average search calls per question as a behavioral metric (InfoSeeker-3B averages 8.24 calls, while Qwen3-32B averages 0.92 calls and GPT-5 averages 23.23 calls). The RL training budget is specified in terms of GRPO steps (200 for Round 1, 100 for Round 2) with rollout size 5, batch size 256, and maximum 10 turns per rollout. SFT training completes in 2 hours on a single 8xH100 node (Appendix A.1).

  • Cross-validation / statistical protocol. The paper does not employ formal cross-validation or statistical significance testing for the main experimental results in Tables 3–5. The two-fold cross-validation described in Section 3.2 applies to the compute-optimal strategy selection within the InfoSeeker training pipeline (selecting SFT trajectories and RL checkpoints), not to the final evaluation. The absence of confidence intervals or standard deviations on any reported metrics is a limitation — particularly for BrowseComp-Plus, where the 830-question test set, when split across the many model comparisons, means differences of a few percentage points may not be statistically reliable. For the data quality assurance stage, the difficulty check uses Qwen2.5-32B-Inst as the sole parametric memory probe, and the verifiability check uses Gemini 2.5 Flash as the sole validator — single-model validation introduces potential systematic biases if these models have idiosyncratic failure modes.

Main Quantitative Results

Single-Hop and Multi-Hop QA Performance

Headline result. InfoSeeker-3B achieves the highest average performance across seven single-hop and multi-hop QA benchmarks (43.5% average EM), outperforming all RAG-based methods (best: InForage-3B at 40.6%) and all agentic search methods of comparable scale (best: AutoRefine-3B at 39.6%). This is reported in Table 3.

The pattern is not uniform across benchmarks. InfoSeeker-3B's advantage is concentrated on the harder multi-hop benchmarks: 52.0% on 2Wiki (vs. 42.8% for the next-best InForage-3B — a 9.2 percentage point gap), 44.6% on HotpotQA (vs. 40.9% for InForage-3B), and 20.5% on Musique (vs. 17.2% for InForage-3B). On simpler single-hop benchmarks, InfoSeeker-3B is competitive but not dominant: 42.7% on NQ (vs. 43.6% for AutoRefine-3B), 57.1% on TQA (vs. 61.5% for ZeroSearch-3B). On PopQA, InfoSeeker-3B achieves 48.0%, the highest in the table. On Bamboogle — a benchmark specifically designed to test compositional generalization — InfoSeeker-3B achieves 39.8% (vs. 36.0% for InForage-3B and 33.6% for AutoRefine-3B).

What this pattern means. The results suggest that InfoSeeker-3B's training on HCSP-structured data provides the largest benefits on problems requiring compositional reasoning (2Wiki, Musique, Bamboogle) and multi-hop integration (HotpotQA), while providing more modest benefits on single-hop factual lookup (NQ, TQA). This is consistent with the paper's theoretical framing: HCSP training teaches hierarchical constraint propagation and parallel evidence integration — capabilities that are most useful when questions require coordinating multiple pieces of information, and less useful when a single retrieval or parametric memory lookup suffices.

Comparison to RAG methods. InfoSeeker-3B substantially outperforms all RAG-based methods across all seven benchmarks. The gap is largest on Bamboogle: InfoSeeker-3B at 39.8% vs. the best RAG method (RQRAG) at 12.9% — a 26.9 percentage point gap. This is notable because Bamboogle was designed to require compositional reasoning that standard RAG pipelines struggle with. The gap is also large on 2Wiki (52.0% vs. 30.7% for RQRAG) and Musique (20.5% vs. 10.1% for RQRAG). These results validate the paper's central claim that training on structurally complex data teaches capabilities that cannot be replicated by inference-time retrieval augmentation alone.

Comparison to other agentic search methods. InfoSeeker-3B outperforms all other 3B-scale agentic search models on average, but the margins vary. On the multi-hop benchmarks where InfoSeek's training is most relevant, the gaps are substantial (2Wiki: 52.0% vs. 42.8% for InForage-3B; HotpotQA: 44.6% vs. 40.9% for InForage-3B). On single-hop benchmarks, the gaps narrow — InfoSeeker-3B actually underperforms ZeroSearch-3B on TQA (57.1% vs. 61.5%) and AutoRefine-3B on NQ (42.7% vs. 43.6%). This suggests that InfoSeek's HCSP-structured data does not degrade single-hop performance relative to methods trained on flat QA data, but it does not dramatically improve it either — the training data's structural advantages are specific to the reasoning patterns they encode.

Deep Research Performance on BrowseComp-Plus

Headline result. InfoSeeker-3B achieves 16.5% accuracy on BrowseComp-Plus, surpassing several closed-source commercial systems (Gemini 2.5 Flash at 15.5%, Sonnet 4 at 14.3%, GPT-4.1 at 14.6%) and dramatically outperforming open-source baselines (Qwen3-32B at 3.5%, SearchR1-32B at 3.9%). This is reported in Table 4.

The scale-performance inversion. The most striking result in Table 4 is not the absolute accuracy of InfoSeeker-3B, but its relationship to model scale. Qwen3-32B — a model with more than 10× the parameters, from a newer model generation (Qwen3 vs. Qwen2.5), and presumably trained on more and better data — achieves only 3.5% on BrowseComp-Plus. SearchR1-32B, which is Qwen2.5-32B fine-tuned with RL specifically for agentic search, achieves only 3.9%. InfoSeeker-3B's 16.5% is 4.7× higher than Qwen3-32B and 4.2× higher than SearchR1-32B. This is a rare instance of a smaller model substantially outperforming a much larger one on a challenging benchmark, and it provides strong evidence that data structure, not model scale, is the binding constraint on BrowseComp-Plus performance.

The search behavior gap. Table 4 reports average search calls per question: InfoSeeker-3B makes 8.24 calls on average, while Qwen3-32B makes only 0.92 calls. This behavioral difference is revealing: the larger model barely attempts multi-step search, suggesting it does not recognize BrowseComp-Plus problems as requiring extended investigation. InfoSeeker-3B, having been trained on data that explicitly requires hierarchical multi-step reasoning, engages in substantially more search. The causality is plausible: InfoSeek's training data teaches the model that complex problems require multiple rounds of querying and evidence integration, while the larger models' training (dominated by simpler QA formats and general web text) does not instill this expectation.

Comparison to GPT-5. GPT-5 achieves 55.9% on BrowseComp-Plus — dramatically higher than any other model — and averages 23.23 search calls. This establishes a clear performance ceiling and suggests that the path to further improvement involves both more scale (GPT-5 is presumably much larger than all other models) and more extensive search behavior (GPT-5 makes nearly 3× the search calls of InfoSeeker-3B). The paper's claim is not that InfoSeeker-3B matches frontier models, but rather that structured training data enables a compact model to reach the performance tier of mid-range commercial APIs while dramatically outperforming same-scale and larger-scale open-source alternatives.

The Gemini 2.5 Flash and Pro comparison. InfoSeeker-3B (16.5%) narrowly surpasses Gemini 2.5 Flash (15.5%) and falls short of Gemini 2.5 Pro (19.0%). However, Gemini 2.5 Pro achieves its 19.0% with fewer average search calls (7.44) than InfoSeeker-3B (8.24), suggesting more efficient use of retrieval — each search call yields more useful information. This efficiency gap could reflect the Pro model's larger capacity for reading comprehension and evidence synthesis, or it could reflect differences in the underlying retrieval infrastructure (Gemini models may have access to better search ranking or document processing). The paper does not control for retrieval quality, so the comparison between InfoSeeker-3B and the Gemini models conflates model capability with search engine quality.

Interpretation of the 16.5% absolute number. A 16.5% accuracy rate on BrowseComp-Plus may seem modest, but the benchmark was designed to be extremely difficult — GPT-5, the strongest model tested, achieves only 55.9%. The 16.5% represents a substantial improvement over the near-zero performance of untrained open-source models and places InfoSeeker-3B in the company of commercial APIs that likely have hundreds of billions of parameters and access to proprietary search infrastructure. The paper does not report human performance on BrowseComp-Plus, so it is unclear what the ceiling is — but the fact that even GPT-5 fails on 44.1% of questions suggests the benchmark contains genuinely hard problems that resist current methods.

Training Data Ablation: InfoSeek vs. NQ+HotpotQA

Headline result. Training on InfoSeek yields 16.5% BrowseComp-Plus accuracy vs. 3.0% when training on NQ+HotpotQA, using the same backbone model (Qwen2.5-3B-Inst) and the same training algorithm (RL). InfoSeek-trained models also make substantially more search calls (8.24 vs. 1.39). This is reported in Table 5.

What this ablation isolates. By holding constant the model architecture, the training algorithm, and the evaluation benchmark, and varying only the training dataset, this ablation provides the paper's cleanest evidence that InfoSeek's structural properties are causally responsible for the observed deep research capabilities. The NQ+HotpotQA baseline represents the standard training data used by most prior agentic search work (Search-R1, ZeroSearch, AutoRefine all train on NQ and HotpotQA). The 5.5× performance gap (16.5% vs. 3.0%) cannot be attributed to differences in model scale, training methodology, or evaluation protocol — it must be attributed to the structural complexity of the training data.

The search behavior interpretation. The NQ+HotpotQA-trained model averages only 1.39 search calls on BrowseComp-Plus, barely above the single-retrieval baseline. This suggests that training on flat and linear-chain QA data does not teach models to engage in the extended, multi-turn search behavior that BrowseComp-Plus requires. The InfoSeek-trained model averages 8.24 search calls — a nearly 6× increase — consistent with the hypothesis that HCSP-structured training teaches models to decompose problems into sub-questions and iteratively gather evidence. The gap in search calls is arguably more informative than the accuracy gap: it reveals a learned behavioral strategy (extended investigation vs. single-shot answering) that the training data either instills or fails to instill.

Limitation of this ablation. The NQ+HotpotQA baseline uses only 5K examples (Section 4.2, "5K NQ & HQA samples for preserving general agentic search capability"), while InfoSeek uses 50K+ examples. The paper does not equalize the number of training examples, so the ablation conflates dataset size with dataset structure. A fairer comparison would train on 50K NQ+HotpotQA examples (or downsample InfoSeek to 5K) to isolate structure from scale. The paper's claim that InfoSeek's structural properties drive the performance gap is plausible but not rigorously isolated from the confound of dataset size. The fact that NQ and HotpotQA collectively contain 400K+ examples (Table 1) and the paper chose to use only 5K suggests that simply increasing the number of NQ+HotpotQA examples might not close the gap — but this hypothesis is not tested.

Dataset Statistics and Difficulty Validation

Headline result. The InfoSeek dataset contains 52,138 questions after quality filtering, with a total synthesis cost of $571.80. Qwen2.5-72B with Chain-of-Thought prompting achieves only a 8.4% success rate (91.6% failure rate), confirming the dataset's difficulty. Failure rate increases monotonically with vertex count: from 88.1% for 3-vertex problems to 94.1% for 7+-vertex problems. This is reported in Table 2.

Vertex count distribution. The dataset is concentrated on medium-complexity problems: 15,263 problems with 4 vertices, 15,051 with 5 vertices, and 17,714 with 6 vertices — together accounting for 92% of the dataset. Only 269 problems have 7 or more vertices, and 3,841 have 3 vertices. This distribution reflects the Planner agent's complexity targets: problems with 3 vertices are likely too simple (single CSP with few constraints), while problems with 7+ vertices may become unsolvable or require excessively long reasoning chains. The sweet spot of 4–6 vertices corresponds to trees with moderate depth (2–3 levels) and moderate branching (2–3 constraints or dependencies per internal node) — complex enough to require hierarchical reasoning but tractable enough for the teacher model to solve at a 21.8% rate (Appendix A.1).

The failure rate as a difficulty metric. The 91.6% overall failure rate for Qwen2.5-72B with CoT is reported as a "reliable proxy for deep research difficulty, as established by prior work (Wei et al., 2025)." This interpretation is reasonable: if a strong 72B model with explicit chain-of-thought reasoning cannot answer the question from parametric knowledge and reasoning alone, the question presumably requires external information retrieval — exactly the capability that deep research training should develop. The monotonic relationship between vertex count and failure rate (88.1% → 94.1%) validates that the synthesis process meaningfully controls complexity: more vertices correspond to harder problems.

Cost breakdown and scalability. The total cost of 571.80for52,138questions(571.80 for 52,138 questions (0.011 per question) makes InfoSeek economically viable for community use. The cost scales roughly linearly with vertex count: 3-vertex problems cost 43.90perthousandquestions(43.90 per thousand questions (0.0114 per question), while 6-vertex problems cost 214.40perthousandquestions(214.40 per thousand questions (0.0121 per question). This near-constant per-question cost across complexity levels suggests that the LLM-based question generation and quality assurance stages dominate the cost, with the rule-based tree construction contributing negligibly.

Token length statistics. The average question length is 53.43 tokens, increasing from 31.97 tokens for 3-vertex problems to 81.59 tokens for 7+-vertex problems. This linear scaling of question length with vertex count is expected: more vertices mean more constraints and sub-questions to describe in natural language. The average answer length is short (5.79 tokens overall, decreasing slightly with vertex count), confirming that answers are primarily entity names or short phrases — consistent with the HCSP definition requiring unique, verifiable answers.

Ablation Studies and Robustness Checks

  • Training data source ablation (Table 5): training on InfoSeek vs. NQ+HotpotQA, holding backbone model (Qwen2.5-3B-Inst) and training algorithm (RL) constant. InfoSeek-trained model achieves 16.5% on BrowseComp-Plus with 8.24 average search calls; NQ+HotpotQA-trained model achieves 3.0% with 1.39 average search calls. This is the most important ablation in the paper because it isolates data structure as the causal factor. However, the confound of dataset size (50K vs. 5K examples) weakens the causal interpretation. The paper does not report an ablation with equalized dataset sizes.

  • Scaling behavior with vertex count (Table 2): Qwen2.5-72B failure rate increases from 88.1% (3 vertices) to 94.1% (7+ vertices), a 6.0 percentage point increase across the complexity range. This monotonic trend validates that the synthesis process controls complexity, but the relatively small dynamic range (only 6 percentage points) suggests that even 3-vertex problems are already quite difficult for the 72B model — the "floor" is high. The paper does not report failure rates for simpler problems (1–2 vertices, which would be standard CSPs or single-hop questions) that would establish a lower baseline for comparison.

  • Round 1 vs. Round 2 training (Appendix A.1): the two-round training process is itself an implicit ablation. Round 1 SFT on 24K teacher trajectories yields InfoSeeker-3B-SFT-Round1; Round 1 RL adds GRPO optimization; Round 2 rejection sampling on the Round 1 model's own outputs yields 3,450 high-quality trajectories (from 16,494 generated — a 20.9% acceptance rate after Gemini 2.5 Flash filtering); Round 2 SFT + RL on harder examples (selected for model failure) yields the final InfoSeeker-3B. The paper does not report intermediate BrowseComp-Plus performance after each stage, making it impossible to assess the marginal contribution of Round 2. This is a significant omission — understanding whether the second round provides diminishing returns or is essential for the final performance would inform practitioners about the cost-benefit tradeoff of multi-round training.

  • Teacher model accuracy under InfoSeeker workflow (Appendix A.1): Qwen2.5-72B achieves 21.8% accuracy (24K valid trajectories from 55K samples × 2 rollouts each = 110K attempts — though the paper says "each rolled out twice" for 55K samples, implying 110K total rollouts with 24K correct, which would be 21.8%). This establishes the teacher model's performance ceiling: even a 72B model can solve only about one-fifth of InfoSeek questions under the InfoSeeker workflow. This low teacher accuracy implies that the SFT trajectories are biased toward the subset of problems the teacher can solve — which may be systematically easier than the full dataset. The Round 2 rejection sampling on InfoSeeker-3B-RL-Round1's own outputs (3,450 accepted from 16,494) has an even lower acceptance rate (20.9%), further concentrating training on problems the model can already solve. This raises a concern: the training may not be exposing the model to the hardest problems, potentially limiting its upward scaling.

  • NQ+HotpotQA inclusion in training data (Appendix A.1): both SFT rounds include 5K NQ and HotpotQA examples "for preserving general agentic search capability." This is a pragmatic choice to prevent catastrophic forgetting of basic QA skills, but it means the training data is not purely InfoSeek — the model receives a mixed diet. The paper does not ablate the NQ+HotpotQA inclusion, so its contribution to the final performance is unknown. The single-hop and multi-hop QA results in Table 3 show InfoSeeker-3B performing competitively on NQ (42.7%) and TQA (57.1%), suggesting the mixed training successfully preserves general QA capability, but whether this comes at the cost of reduced deep research performance is untested.

  • Gemini 2.5 Flash filtering in Round 2 (Appendix A.1): the 3,450 accepted trajectories were selected by Gemini 2.5 Flash to exhibit "multi-turn search, finer-grained task decomposition, and more accurate step-by-step reasoning." This introduces a potential bias: the training data is filtered by a model that InfoSeeker-3B is later compared against on BrowseComp-Plus (Table 4). If Gemini 2.5 Flash has systematic preferences for certain reasoning patterns, and those patterns are incidentally effective on BrowseComp-Plus, the evaluation may favor InfoSeeker-3B for reasons unrelated to InfoSeek's structural properties. This is a subtle form of data leakage — the filter model and the evaluation baseline are from the same API family, and while they are different models (Flash vs. potential Pro for evaluation), they likely share training data and architectural biases.

  • Retrieval method across benchmarks: for single-hop and multi-hop QA, retrieval uses BGE-M3 embeddings with Wikipedia-25; for BrowseComp-Plus, retrieval uses BM25 over a 100K web page corpus. This confound makes cross-benchmark comparisons difficult — differences in performance could reflect retrieval quality rather than model capability. The paper does not justify why different retrieval methods are used, nor does it ablate retrieval method on BrowseComp-Plus (e.g., does InfoSeeker-3B's advantage persist with embedding-based retrieval?). This is particularly relevant because BM25 is a lexical retrieval method that may miss semantically relevant documents, potentially underestimating model capability if the model would benefit from denser retrieval.

  • No ablation on Refiner Agent: the InfoSeeker workflow includes a separate Refiner Agent (Qwen2.5-7B-Inst) that summarizes retrieved documents. The paper does not report performance without the Refiner Agent (e.g., feeding raw search results directly to InfoSeeker-3B) or with a different refiner model. The Refiner Agent's contribution to overall performance is therefore unknown — it is possible that a substantial fraction of InfoSeeker-3B's BrowseComp-Plus performance comes from the Refiner Agent's summarization quality rather than InfoSeeker-3B's reasoning capability.

  • No ablation on parallel multi-query search: the InfoSeeker workflow generates multiple queries per reasoning step. The paper does not compare this to a single-query-per-step baseline, so the marginal benefit of parallelization is unknown. The paper's motivation for parallel queries — "broadens the informational coverage and accelerates the exploration process" (Section 4.1) — is plausible but undemonstrated.

Critical Assessment

Claim 1: InfoSeek produces structurally complex Deep Research data that prior datasets cannot capture. The evidence for this claim is strong within the paper's own framework but has an important circularity: the paper defines "structurally complex" in terms of HCSP properties, constructs a dataset that satisfies those properties, and then measures the dataset's difficulty in terms that correlate with those properties (vertex count vs. Qwen2.5-72B failure rate, Table 2). The 91.6% CoT failure rate for a 72B model does demonstrate that the questions are difficult for parametric reasoning, but it does not independently validate that the hierarchical structure — as opposed to other sources of difficulty like obscure entities or ambiguous phrasing — is what makes them hard. A controlled experiment comparing HCSP-structured questions to complexity-matched flat CSP questions (same number of constraints, but all at a single level with no sub-question hierarchy) would isolate the hierarchical structure's contribution to difficulty, but this experiment is not performed. The comparison to NQ+HotpotQA in Table 5 conflates structure with scale (50K vs. 5K examples), and the single-hop/multi-hop QA results in Table 3 show InfoSeeker-3B performing competitively but not dominantly — suggesting that HCSP training does not confer universal advantages, only advantages on tasks that share HCSP structure. The claim that InfoSeek captures "structural depth" that prior datasets lack is supported by construction (the Research Tree methodology) and by the BrowseComp-Plus transfer results, but the specific contribution of hierarchy vs. other factors (entity diversity, constraint count, corpus breadth) is not isolated.

Claim 2: InfoSeek enables scalable, cost-effective synthesis of deep research data. The $571.80 total cost for 52,138 questions is well-documented (Table 2). The paper's assertion that prior approaches "lack the flexibility required for diverse Deep Research tasks" (Section 1) and that InfoSeek provides "principled scalability" is supported by the scale achieved. However, the cost accounting is incomplete: it includes only API costs for question generation and quality assurance, not the cost of preprocessing the knowledge base (filtering webpages and Wikipedia, extracting entities and facts), running the Planner and Browser agents (which, while rule-based, still require computation), or the human effort in designing and tuning the synthesis pipeline. These uncounted costs could be substantial, particularly the initial knowledge base construction, which must be done before any questions can be generated. The claim of "scalability" is demonstrated for the 50K scale but its limits are not tested — would the pipeline continue to produce high-quality questions at 500K or 5M scale, or would entity diversity become a bottleneck? The paper does not report the size of the underlying knowledge base (how many unique entities are available for root selection), which determines the maximum dataset size before entities are reused and questions become repetitive.

Claim 3: A 3B model trained on InfoSeek can outperform much larger models and compete with commercial APIs on deep research tasks. This is the paper's headline empirical claim, and the evidence in Table 4 is striking: InfoSeeker-3B at 16.5% vs. Qwen3-32B at 3.5% and SearchR1-32B at 3.9%. However, the claim requires careful qualification. First, the advantage is demonstrated on exactly one benchmark (BrowseComp-Plus). The paper does not evaluate on other deep research benchmarks (there are few publicly available alternatives, but the generality of the finding is limited to a single test distribution). Second, the baseline models (Qwen3-32B, SearchR1-32B) are evaluated with BM25 retrieval, which may not be the retrieval method they were designed or optimized for — SearchR1-32B, for example, was trained with a different retrieval setup. Third, the commercial API comparison is to specific API endpoints at a specific point in time — model versions and underlying infrastructure may change, making the comparison non-reproducible. Fourth, GPT-5 at 55.9% demonstrates that the absolute performance ceiling is far higher, and the gap between InfoSeeker-3B (16.5%) and GPT-5 (55.9%) is 39.4 percentage points — larger than the gap between InfoSeeker-3B and the weakest baseline. The claim that InfoSeeker-3B "competes with commercial APIs" should be qualified: it surpasses some commercial APIs (Gemini 2.5 Flash, Sonnet 4, GPT-4.1) by small margins (0.2–2.2 percentage points), but these margins may not be statistically significant on an 830-question test set. The paper does not report confidence intervals.

Claim 4: InfoSeek's meta-information enables richer training signals for future work. This claim is prospective, not demonstrated. The paper does not train models using process rewards, sub-question supervision, or retrieval provenance — the SFT+RL pipeline uses only binary outcome rewards. The claim that the meta-information "opens new opportunities for compound reward design and trajectory-level optimization" (Section 7) is a statement about potential, not an empirical finding. This is a legitimate contribution — releasing data with rich annotations enables future work — but the claim should not be conflated with demonstrated improvements from using those annotations. The paper would be strengthened by even a small-scale experiment showing that process-level rewards (using the intermediate vertex answers) improve training efficiency or final performance compared to outcome-only rewards.

Missing experiments that would strengthen the paper:

  • Equalized dataset size ablation: train on 50K NQ+HotpotQA examples (or downsample InfoSeek to 5K) to isolate structure from scale in Table 5.
  • Round-by-round performance reporting: evaluate InfoSeeker after SFT-Round1, RL-Round1, SFT-Round2, and RL-Round2 on BrowseComp-Plus to quantify the marginal contribution of each training stage and the two-round approach.
  • Refiner Agent ablation: evaluate InfoSeeker-3B with and without the Refiner Agent (feeding raw search results directly) to measure its contribution.
  • Parallel vs. single-query ablation: compare the multi-query-per-step workflow to a single-query-per-step baseline on BrowseComp-Plus.
  • Alternate deep research benchmark: evaluate on at least one additional benchmark requiring hierarchical reasoning (if one exists) to test generality beyond BrowseComp-Plus.
  • Statistical significance: report confidence intervals or standard deviations across multiple evaluation runs or bootstrap samples, particularly for the small-margin comparisons (InfoSeeker-3B vs. Gemini 2.5 Flash at 16.5% vs. 15.5%).
  • Human performance on BrowseComp-Plus: establish a ceiling to contextualize the 16.5% absolute accuracy.
  • Retrieval method ablation on BrowseComp-Plus: test whether InfoSeeker-3B's advantage persists with embedding-based retrieval (as used in the single-hop/multi-hop benchmarks) rather than BM25.
  • Process reward experiment: train a model using the intermediate vertex answers as process supervision and compare to the outcome-only reward baseline, even at small scale, to support the meta-information contribution claim.

Genuine weaknesses:

  • Single-benchmark evaluation for the main claim. The paper's central empirical finding — that InfoSeek-trained models excel at deep research — rests on exactly one benchmark (BrowseComp-Plus). While BrowseComp-Plus was designed specifically for this purpose and the single-hop/multi-hop results in Table 3 provide convergent evidence of general capability, the absence of an additional deep research evaluation limits confidence in the generality of the finding. The field lacks standardized deep research benchmarks, so this is partly a limitation of the evaluation landscape, but the paper could have constructed a held-out subset of InfoSeek as an additional test set — though this would introduce distributional overlap concerns.

  • The Refiner Agent is an uncontrolled variable. InfoSeeker-3B's BrowseComp-Plus performance depends on the Refiner Agent (Qwen2.5-7B-Inst), which is a separate model with its own capabilities. The paper does not report what fraction of InfoSeeker-3B's performance is attributable to the Refiner Agent's summarization quality vs. InfoSeeker-3B's reasoning and query generation. At the extreme, one could imagine a scenario where a weak reasoning model paired with a strong Refiner Agent achieves good performance by generating mediocre queries but receiving high-quality summaries — the Refiner Agent compensates for the reasoning model's weaknesses. The absence of a Refiner Agent ablation makes it impossible to assess this.

  • The knowledge base preprocessing cost is unaccounted for. The $571.80 figure includes only API costs for the LLM-based stages. The paper does not report the computational cost of webpage crawling, entity extraction, fact extraction, or the Planner/Browser agent operations. For a paper whose contribution is "scalable data synthesis," the total cost of synthesis — not just the API portion — matters for practitioners deciding whether to adopt the framework.

  • The teacher model's 21.8% accuracy creates a selection bias in SFT data. The SFT trajectories come only from problems the teacher model (Qwen2.5-72B) can solve. If the teacher systematically fails on certain types of HCSPs (e.g., those requiring very deep trees or those with rare entities), the SFT data will underrepresent those problem types, and the trained model will inherit this blind spot. The paper does not analyze the distribution of accepted vs. rejected trajectories to characterize this selection bias. The Round 2 filtering by Gemini 2.5 Flash and the selection of problems the model fails on for RL partially mitigate this (the model gets to practice on problems it initially gets wrong), but the initial SFT distribution still shapes what reasoning patterns the model is exposed to.

  • The 830-question BrowseComp-Plus test set is small for fine-grained comparisons. With 830 questions and accuracy differences of 1–3 percentage points between InfoSeeker-3B and the commercial APIs it "surpasses," the statistical reliability of these rankings is questionable. A difference of 1 percentage point on 830 questions corresponds to roughly 8 questions — small enough that sampling variance or minor differences in evaluation protocol could flip the ranking. The paper would benefit from a more powerful evaluation (more questions, multiple evaluation runs) or from reporting confidence intervals to contextualize the precision of the estimates.

  • The FLOPs-matched comparison is asymmetric with respect to retrieval. InfoSeeker-3B makes 8.24 search calls on average; Qwen3-32B makes 0.92. This means InfoSeeker-3B is retrieving and processing substantially more text than the larger models. The comparison is therefore not just about model capability — it is about model capability plus retrieval budget. If Qwen3-32B were forced to make 8+ search calls (through prompting or workflow design), its performance might improve substantially, narrowing or reversing the gap. The paper's claim that structured training data substitutes for model scale is confounded with the fact that the trained model also uses more retrieval. An experiment that controls for retrieval budget (e.g., giving all models the same number of search calls with the same retrieved documents) would isolate the model capability contribution from the search behavior contribution.

Where the claims hold conditionally:

  • The claim that InfoSeek enables scalable synthesis holds under the assumption that the knowledge base is sufficiently large and diverse to support synthesis at the desired scale without entity reuse. The paper demonstrates this for 52K questions but does not establish the upper bound of scalability.
  • The claim that InfoSeeker-3B outperforms larger models holds on BrowseComp-Plus with BM25 retrieval and the specific InfoSeeker workflow (including the Refiner Agent). It may not hold with different retrieval methods, without the Refiner Agent, or on different deep research benchmarks.
  • The claim that training on InfoSeek transfers to general agentic search capability holds for the single-hop and multi-hop benchmarks in Table 3, but InfoSeeker-3B is not uniformly best on these benchmarks — it underperforms some baselines on TQA and NQ. The transfer is positive on average but not universal across all question types.
  • The claim that InfoSeek's meta-information enables richer training signals is entirely prospective — no experiments demonstrate improvements from using this meta-information in training. The dataset enables such experiments, but the paper does not conduct them.

6. Limitations and Trade-offs

6.1 The Difficulty Estimation Cost Is Unaccounted for and Dominates the Headline Synthesis Budget

The assumption or constraint. The paper reports a total data synthesis cost of 571.80for52,138questions(Table2),butthisfigureaccountsonlyforAPIcallstoLLMsduringthequestiongenerationandqualityassurancestages(DeepSeekV3orGPT−4.1forquestiongeneration;Gemini2.5FlashandQwen2.5−32B−Instforvalidation).Thecostoftheknowledgebasepreprocessingpipeline—crawlingandfilteringwebpagesandthefullWikipediadump,extractingentitiesviahyperlinkdetection,parsingsentencesforatomicclaims,indexingcandidateverticesandedges—isentirelyunaccountedfor.Thesepreprocessingstepsmustbecompletedbeforeanyquestionscanbesynthesized,andtheyarenotamortizedacrossthe52Kquestionsinthereported571.80 for 52,138 questions (Table 2), but this figure accounts only for API calls to LLMs during the question generation and quality assurance stages (DeepSeek V3 or GPT-4.1 for question generation; Gemini 2.5 Flash and Qwen2.5-32B-Inst for validation). The cost of the knowledge base preprocessing pipeline — crawling and filtering webpages and the full Wikipedia dump, extracting entities via hyperlink detection, parsing sentences for atomic claims, indexing candidate vertices and edges — is entirely unaccounted for. These preprocessing steps must be completed before any questions can be synthesized, and they are not amortized across the 52K questions in the reported 571.80 figure. The paper does not estimate this cost or acknowledge it as part of the total synthesis budget.

The quality assurance pipeline adds a less obvious but equally significant uncounted cost. The difficulty check requires running Qwen2.5-32B-Inst inference on every generated question (52K+ questions before filtering), and the verifiability check requires Gemini 2.5 Flash API calls with ground-truth web pages plus distractor documents. The paper reports removing the 2% of questions that Qwen2.5-32B-Inst answered correctly, which implies inference was run on all questions. The Gemini 2.5 Flash API costs for verifiability checking are included in the $571.80 total (Table 2), but the Qwen2.5-32B-Inst inference cost is not itemized.

The consequence. A practitioner attempting to replicate the InfoSeek pipeline would face substantially higher total costs than the headline 571.80figuresuggests.Theknowledgebasepreprocessingstageinvolvesweb−scalecrawling(thepaperuses"webpagesandthefullWikipediadump"astheknowledgebase;Section3),entityextractionacrossmillionsofdocuments,andconstructionoftheentity−factindexthattheBrowseragentqueriesduringtreeconstruction.Thesearenon−trivialengineeringandcomputationalinvestmentsthatthepaper′scostaccountingrendersinvisible.The571.80 figure suggests. The knowledge base preprocessing stage involves web-scale crawling (the paper uses "webpages and the full Wikipedia dump" as the knowledge base; Section 3), entity extraction across millions of documents, and construction of the entity-fact index that the Browser agent queries during tree construction. These are non-trivial engineering and computational investments that the paper's cost accounting renders invisible. The 0.011 per-question figure is therefore a lower bound that applies only after the knowledge base infrastructure is already in place — it is the marginal cost of producing one additional question, not the total cost of establishing the synthesis capability.

Furthermore, the difficulty check's computational cost creates a tension that the paper does not address. The 2% of questions that Qwen2.5-32B-Inst answered correctly were removed to "further enhance difficulty" (Section 3.5), but the cost of identifying these 2% (running 32B-model inference on all 52K+ questions) is not reported. If the marginal benefit of removing these questions is small relative to the filtering cost, a practitioner might reasonably choose to skip this step — but the paper provides no evidence to evaluate this tradeoff.

What evidence exists in the paper. Table 2 reports 571.80asthetotalcostandbreaksitdownbyvertexcount,showingcostsrangingfrom571.80 as the total cost and breaks it down by vertex count, showing costs ranging from 43.90 (3-vertex problems) to $214.40 (6-vertex problems) — but these are per-category totals, not per-unit costs. Section 3 describes the knowledge base preprocessing steps (entity extraction, fact mining, webpage filtering) but provides no cost estimates. The paper does not report the size of the underlying knowledge base (number of entities, number of webpages, total storage), the computational resources required for preprocessing, or the one-time setup cost.

Mitigation status. The paper does not acknowledge this limitation explicitly. The cost reporting in Table 2 is presented as a positive claim about scalability — "total data curation cost as $571.8, provided for reproducibility" — without caveats about uncounted preprocessing or validation inference costs. The omission of setup costs is a standard practice in dataset papers (which typically report only the marginal cost of producing the dataset given existing infrastructure), but it is particularly consequential here because the paper's central contribution is a scalable synthesis framework — the total cost of establishing the framework matters for its claimed value proposition.

6.2 Single-Benchmark Evaluation for the Central Claim of Deep Research Capability

The assumption or constraint. The paper's headline empirical finding — that a 3B model trained on InfoSeek outperforms much larger models and competes with commercial APIs on deep research tasks — rests on evaluation against exactly one benchmark: BrowseComp-Plus (830 questions, 100K web page corpus). The single-hop and multi-hop QA results in Table 3 demonstrate that InfoSeeker-3B generalizes to simpler reasoning tasks, but these benchmarks do not test the hierarchical constraint satisfaction capability that is InfoSeek's raison d'être. There is no additional evaluation on a second benchmark requiring HCSP-like reasoning, no held-out subset of InfoSeek used as a test set (which would introduce distributional concerns but provide convergent evidence), and no human performance baseline to contextualize the 16.5% absolute accuracy.

The paper acknowledges that BrowseComp-Plus was "specifically designed to test open-ended, search-intensive reasoning that cannot be solved from parametric memory alone" (Section 5.1), which makes it a natural evaluation target. But the paper does not discuss the implications of validating its central claim on a single test distribution. BrowseComp-Plus, like any benchmark, has specific properties — the types of entities it covers, the depth of reasoning required, the nature of the web corpus, the evaluation protocol — that may or may not generalize to other deep research tasks.

The consequence. The paper's claim that InfoSeek enables deep research capability is, strictly speaking, a claim about performance on BrowseComp-Plus specifically, not about deep research capability in general. If BrowseComp-Plus happens to align particularly well with InfoSeek's data distribution — for example, if the entities and relationship types in BrowseComp-Plus overlap with those in the Wikipedia and web corpus used for InfoSeek synthesis — then the reported performance advantage might not transfer to other deep research tasks with different entity distributions or reasoning patterns.

This is not a hypothetical concern. The InfoSeek synthesis pipeline constructs questions from the same knowledge sources (Wikipedia and webpages) that BrowseComp-Plus uses for its retrieval corpus. While the paper uses a "fixed webpage corpus (100K)" from BrowseComp-Plus with BM25 retrieval for evaluation, the underlying entity and fact distributions may be correlated. A model trained on questions derived from Wikipedia entities might perform better on a benchmark whose retrieval corpus includes Wikipedia-derived web content than on a benchmark built from entirely different sources (e.g., scientific literature, legal documents, proprietary databases).

The absence of a second deep research benchmark also makes it impossible to assess whether InfoSeeker-3B's advantage over baselines (e.g., 16.5% vs. 15.5% for Gemini 2.5 Flash) is a robust finding or an artifact of BrowseComp-Plus's specific properties. A 1 percentage point difference on 830 questions corresponds to approximately 8 questions — small enough that benchmark-specific quirks (how the LLM judge evaluates certain answer formats, how the retrieval corpus covers specific entities) could determine the ranking.

What evidence exists in the paper. Table 4 reports BrowseComp-Plus as the sole deep research evaluation. Table 3 reports single-hop and multi-hop QA results, which demonstrate general agentic search capability but do not test hierarchical reasoning. The paper does not report performance on any other complex reasoning benchmark, construct an InfoSeek-derived test set, or discuss the generalizability limitations of single-benchmark evaluation.

Mitigation status. The paper does not acknowledge the single-benchmark limitation. Section 5.2 presents the BrowseComp-Plus results as evidence that "InfoSeeker exhibits strong deep research capability" without qualification. The field's lack of standardized deep research benchmarks beyond BrowseComp is a genuine constraint — the paper cannot evaluate on benchmarks that do not exist — but the authors could have addressed this by (1) constructing a held-out InfoSeek test set as a secondary evaluation, (2) reporting results on related complex QA benchmarks that partially capture hierarchical reasoning (if any exist), or (3) explicitly acknowledging the limitation and the need for additional deep research benchmarks in the broader community.

6.3 The Training Data Ablation Confounds Dataset Structure with Dataset Size

The assumption or constraint. The paper's most important ablation — Table 5, comparing models trained on InfoSeek vs. NQ+HotpotQA — uses 50K+ InfoSeek examples versus only 5K NQ+HotpotQA examples (Section 4.2 and Appendix A.1 confirm the "5K NQ & HQA samples"). The paper attributes the 5.5× performance gap (16.5% vs. 3.0% on BrowseComp-Plus) to the structural complexity of InfoSeek's HCSP questions versus the flat and linear-chain structure of NQ and HotpotQA:

"The results in Table 5 demonstrate that training on InfoSeek yields substantially stronger deep research performance and more effective use of search tools." (Section 5.3)

But because dataset size is not equalized, the ablation cannot distinguish between two competing explanations: (1) HCSP-structured data is qualitatively better for training deep research capabilities, or (2) having 10× more training examples is beneficial regardless of structure, and InfoSeek's advantage would diminish or vanish if the NQ+HotpotQA baseline were trained on an equal number of examples.

The consequence. The paper's central causal claim — that InfoSeek's structural properties (hierarchical constraints, parallel sub-problems, sequential dependencies) are what drive the BrowseComp-Plus performance gains — is not rigorously isolated from the confound of dataset size. A practitioner deciding whether to adopt the InfoSeek synthesis pipeline needs to know whether the investment in building a complex tree-based synthesis system is necessary, or whether simply scaling up existing simpler QA datasets to 50K+ examples would yield comparable benefits.

The search behavior gap (8.24 vs. 1.39 average search calls) provides some circumstantial evidence that structure matters: the InfoSeek-trained model learns to engage in extended multi-step search, while the NQ+HotpotQA-trained model does not. But even this could be confounded by dataset size — a model trained on 50K NQ+HotpotQA examples might also learn to make more search calls simply from seeing more diverse examples, even if those examples are structurally simpler.

The paper's choice to use only 5K NQ+HotpotQA examples (when NQ and HotpotQA collectively contain 400K+ examples; Table 1) is not explained. Possible reasons include computational budget (training on more examples takes longer), a desire to match the number of InfoSeek examples used in SFT (the InfoSeek training itself uses only 24K SFT trajectories from the 50K dataset), or an implicit assumption that NQ+HotpotQA's simpler structure means additional examples would provide diminishing returns. But none of these potential justifications are stated or tested.

What evidence exists in the paper. Table 5 reports the comparison: InfoSeek training yields 16.5% accuracy and 8.24 search calls; NQ+HQA training yields 3.0% accuracy and 1.39 search calls. The 5K figure for NQ+HQA is confirmed in Appendix A.1 ("5K NQ & HQA samples for preserving general agentic search capability"). The 50K+ figure for InfoSeek is reported in Table 2 and Section 3.6. The paper does not report an ablation with equalized dataset sizes, nor does it discuss the confound.

Mitigation status. Not addressed. The paper does not acknowledge that dataset size differs between the two conditions, nor does it discuss the implications for causal interpretation. This is the most significant methodological weakness in the experimental design because Table 5 is the paper's primary evidence that InfoSeek's structural properties — rather than other factors like entity diversity, question length, or training data volume — are responsible for the BrowseComp-Plus results.

6.4 The Refiner Agent and Parallel Multi-Query Search Are Unablated Components with Unknown Contributions

The assumption or constraint. The InfoSeeker inference-time workflow (Section 4.1, Figure 3) includes two distinctive components whose individual contributions to performance are never measured: the Refiner Agent (Qwen2.5-7B-Inst), which condenses raw search results into concise summaries with reasoning recommendations, and parallelized multi-query search, which generates multiple diverse queries per reasoning step rather than a single query. Both components are presented as beneficial design choices — the Refiner Agent "maintains high recall while keeping the working context compact and tractable," and parallel queries "broaden the informational coverage and accelerate the exploration process" — but neither is ablated against simpler alternatives (no Refiner Agent, feeding raw search results directly; single-query-per-step search).

The Refiner Agent is not a lightweight post-processing step; it is a separate 7B-parameter LLM that reads retrieved documents, extracts salient evidence, produces summaries aligned with query intent, and generates recommendations for subsequent reasoning. Its outputs become part of InfoSeeker-3B's working context, directly shaping what information the model sees and what reasoning paths it pursues. If the Refiner Agent is highly effective at extracting relevant evidence from noisy search results, it could compensate for weaknesses in InfoSeeker-3B's own query generation or evidence synthesis capabilities — meaning a substantial fraction of the reported BrowseComp-Plus performance might be attributable to the Refiner Agent rather than to InfoSeeker-3B's learned deep research capabilities.

The consequence. The BrowseComp-Plus results conflate two distinct capabilities: InfoSeeker-3B's ability to plan, generate queries, and synthesize evidence (what InfoSeek training is supposed to teach), and the Refiner Agent's ability to extract useful information from raw search results (which depends on Qwen2.5-7B-Inst's pretraining and instruction tuning, not on InfoSeek). A practitioner cannot determine from the reported results whether InfoSeeker-3B's strong performance comes from better reasoning and query generation (supporting the paper's claim that InfoSeek data teaches deep research) or from pairing a mediocre reasoning model with a strong document processing pipeline (supporting a much weaker claim that structured search workflows help).

The same concern applies to parallel multi-query search. Generating multiple queries per step increases the probability that at least one query retrieves relevant information, but it also increases the computational cost (more search engine calls, more documents for the Refiner Agent to process). If parallel queries are the primary driver of BrowseComp-Plus performance, then the paper's claim about training data structure is confounded with an inference-time engineering choice that any model — trained on InfoSeek or not — could adopt.

What evidence exists in the paper. The paper describes the Refiner Agent and parallel query generation in Section 4.1 and Figure 3, but reports no ablation experiments. The search call counts in Table 4 (InfoSeeker-3B averages 8.24 calls) include all queries across all steps, but the number of queries per step is not reported, making it impossible to determine how many reasoning turns the model takes versus how many parallel queries it generates per turn. Table 4's comparison to other models (e.g., Gemini 2.5 Pro at 7.44 search calls) is confounded by the fact that these models likely use different search workflows (single-query vs. multi-query, with or without a refiner).

Mitigation status. Not addressed. The paper presents the Refiner Agent and parallel queries as integral components of the InfoSeeker workflow without measuring their individual contributions. A practitioner seeking to reproduce or build upon InfoSeeker cannot determine whether these components are essential for the reported performance or whether simpler alternatives would suffice.

6.5 The 21.8% Teacher Model Accuracy Creates Selection Bias in SFT Data, and Round 2 Filtering Narrows Rather Than Expands the Training Distribution

The assumption or constraint. The SFT trajectory construction process (Section 4.2, Appendix A.1) uses rejection sampling: the teacher model (Qwen2.5-72B) attempts to solve InfoSeek questions under the InfoSeeker workflow, and only trajectories that produce correct final answers are retained. The paper reports that the teacher model achieves 21.8% accuracy (24K valid trajectories from 55K samples × 2 rollouts each, implying 110K total attempts), meaning 78.2% of the InfoSeek dataset is effectively excluded from SFT training because the teacher model cannot solve those problems.

This creates a selection bias: the SFT data represents only the subset of InfoSeek problems that a 72B model can solve under the InfoSeeker workflow. If these solvable problems are systematically easier or structurally different from the unsolvable ones — for example, if they tend to involve shallower trees, more common entities, or less ambiguous constraints — then SFT trains the model on a biased sample that may not represent the full difficulty distribution of the InfoSeek dataset or the BrowseComp-Plus benchmark.

The Round 2 training pipeline compounds this narrowing rather than broadening it. Round 2 rejection sampling uses InfoSeeker-3B-RL-Round1's own outputs, filtered by Gemini 2.5 Flash for quality, yielding only 3,450 accepted trajectories from 16,494 generated (20.9% acceptance rate). This means Round 2 SFT trains on problems the model can already solve (since the trajectories come from its own successful rollouts) and that Gemini 2.5 Flash deems high-quality. The Round 2 RL phase partially addresses this by selecting 14K problems the model fails on from a 17K hard-problem subset, but these are used only for RL (exploration and reward-based optimization), not for SFT (demonstration-based learning). The SFT phases — which establish the model's foundational reasoning patterns — are trained exclusively on problems within the model's (or its teacher's) current capability envelope.

The consequence. The model may never be exposed to demonstrations of how to solve the hardest InfoSeek problems (those the 72B teacher cannot solve), nor to the reasoning patterns that distinguish successful from unsuccessful attempts on problems at the boundary of its capability. The SFT data teaches the model how to solve problems it (or its teacher) can already solve, while RL optimizes the model's existing strategies rather than teaching fundamentally new ones. This creates an inherent ceiling: the model's deep research capability is bounded by what the teacher model can demonstrate and what RL can discover from the model's own exploration, which is constrained by the strategies it learned during SFT.

The 16.5% BrowseComp-Plus accuracy, while strong relative to baselines, might represent a local optimum within the training distribution's capability envelope rather than the best achievable performance given InfoSeek's data. Expanding the SFT distribution — for example, by including unsuccessful teacher trajectories with annotations about where and why they failed, or by using a stronger teacher model — could raise this ceiling. The paper does not explore these alternatives.

What evidence exists in the paper. Appendix A.1 reports the teacher model accuracy (21.8% — "24K valid trajectories from 55K samples, each rolled out twice") and the Round 2 acceptance rate (20.9% — "3,450 high-quality trajectories from 16,494 generated"). The paper does not analyze the distribution of accepted vs. rejected problems (e.g., by vertex count, entity rarity, tree depth), nor does it compare the characteristics of problems the model solves after SFT vs. after RL to assess whether RL expands the model's capability boundary beyond the SFT distribution. Table 4's BrowseComp-Plus result and Table 5's ablation are the only post-training evaluations reported; intermediate checkpoints are not evaluated.

Mitigation status. The paper partially addresses this limitation through the Round 2 RL phase, which selects problems the model fails on (14K from a 17K hard subset) for reinforcement learning. This ensures the model receives some training signal on problems outside its current capability — but only through RL's sparse reward signal, not through demonstration-based SFT that could teach new reasoning strategies. The paper does not discuss the SFT selection bias explicitly or propose methods to mitigate it (e.g., using multiple teachers, incorporating partial-credit trajectories, or using stronger models for trajectory generation).

6.6 The Approach Provides No Path Forward for Problems Where the Base Model's Retrieval or Reasoning Capability Is Fundamentally Insufficient

The assumption or constraint. InfoSeek's synthesis pipeline and InfoSeeker's training pipeline both assume that the problems, while structurally complex, are solvable given access to web search and the reasoning capabilities imparted by SFT+RL training. The paper's HCSP formalization requires that every question has a unique, verifiable answer grounded in retrievable evidence. The quality assurance pipeline enforces this: questions are filtered out if Gemini 2.5 Flash cannot derive the correct answer from the ground-truth web pages.

This design ensures the dataset is clean but also defines a hard capability boundary: InfoSeek trains models to solve problems that are structurally complex but factually within the reach of web search and multi-step reasoning. The paper provides no mechanism for handling problems where the necessary evidence is not retrievable (e.g., paywalled content, non-public databases, information that exists only in unstructured formats that search engines index poorly), where the reasoning requires capabilities the base model lacks (e.g., quantitative analysis beyond simple constraint intersection, causal reasoning, counterfactual evaluation), or where the question admits multiple valid answers and requires judgment or synthesis rather than constraint satisfaction.

The BrowseComp-Plus results in Table 4 illustrate this boundary concretely: InfoSeeker-3B achieves 16.5% accuracy, meaning it fails on 83.5% of questions. The paper does not analyze the failure modes — whether failures occur because of retrieval failures (the search engine cannot find relevant pages), reasoning failures (the model cannot integrate the evidence it retrieves), or structural failures (the questions require capabilities InfoSeek training does not teach). GPT-5's 55.9% accuracy, while much higher, still represents failure on 44.1% of questions, suggesting that even frontier models encounter fundamental difficulty on a substantial fraction of BrowseComp-Plus problems.

The consequence. InfoSeek's training methodology — and the HCSP formalization that underlies it — is fundamentally a framework for amplifying existing reasoning and retrieval capabilities, not for creating new ones. A model trained on InfoSeek learns to decompose questions into sub-problems, query for evidence, intersect constraints, and propagate results through a hierarchy — but only to the extent that its base reasoning capabilities (from pretraining) and its retrieval infrastructure (search engine quality, corpus coverage) support these operations. If a problem requires reasoning about concepts the base model does not understand, or retrieving information that is not in the search corpus, no amount of HCSP-structured training will help.

This limitation is analogous to the finding in the test-time compute scaling paper (Snell et al., 2024) that additional inference compute cannot compensate for problems fundamentally outside the base model's capability range: test-time compute amplifies existing capability but does not create it from nothing. InfoSeek training similarly amplifies a model's ability to perform structured search and reasoning, but it cannot teach the model to reason about domains it does not understand or to retrieve information that does not exist in accessible form.

What evidence exists in the paper. The 16.5% BrowseComp-Plus accuracy (Table 4) is the primary evidence of this capability boundary, but the paper does not analyze what distinguishes the 16.5% of solved problems from the 83.5% of unsolved ones. Table 2 shows that Qwen2.5-72B failure rate increases with vertex count (88.1% to 94.1%), suggesting that structural complexity is one dimension of difficulty, but this analysis is for parametric (no-search) performance, not for the full search-augmented InfoSeeker workflow. The paper does not report how InfoSeeker-3B's BrowseComp-Plus accuracy varies with InfoSeek training data complexity (e.g., does it perform better on problems similar to those in the SFT distribution?), nor does it report ablation studies varying retrieval quality to assess the interaction between model capability and search infrastructure.

Mitigation status. The paper does not explicitly acknowledge this capability boundary. The conclusion (Section 7) presents InfoSeek as enabling "more robust reasoning and tool use capabilities" without discussing the fundamental limits of what structured training on retrievable-evidence problems can achieve. The paper's framing — that InfoSeek "yields datasets that are structurally diverse, complexity-controllable, and intrinsically verifiable" — emphasizes the framework's strengths while not addressing the class of deep research problems that fall outside the HCSP formalization (open-ended synthesis, judgment under uncertainty, reasoning across non-intersectable evidence). This is a legitimate scope limitation — no framework can cover all problem types — but the paper would be strengthened by explicitly delineating what HCSP-structured training can and cannot achieve, helping practitioners understand when InfoSeek is appropriate and when alternative approaches are needed.

7. Implications and Future Directions

How This Work Changes the Landscape

InfoSeek represents a significant methodological shift in how the field approaches training data for complex reasoning, but it is better understood as a reframing and new diagnostic rather than a paradigm shift. The paper's central contribution — that verifiable Deep Research questions can be formalized as Hierarchical Constraint Satisfaction Problems and synthesized at scale from web text through rule-based tree construction — does not introduce fundamentally new algorithms or architectures. What it changes is the unit of analysis for reasoning tasks and the economic model for producing training data that teaches hierarchical reasoning.

The reframing: from "complex reasoning" to "hierarchical constraint propagation." Prior to this work, the field organized reasoning tasks along an underspecified complexity axis — single-hop vs. multi-hop, with "multi-hop" serving as a catch-all for anything requiring more than one retrieval or inference step. This flattened taxonomy obscured a crucial structural distinction: parallel constraint integration (do you need to intersect multiple independent conditions simultaneously?) versus sequential dependency chaining (do you need to resolve A before B before C?). InfoSeek's HCSP formalization (Equations 1–3) makes this distinction explicit and shows that genuine Deep Research requires both — parallel constraints at intermediate nodes that are themselves embedded within sequential dependency chains. This is not merely a relabeling; the experimental evidence in Table 5 demonstrates that the distinction has practical consequences: training on data that teaches only linear-chain reasoning (NQ+HotpotQA) yields 3.0% on BrowseComp-Plus, while training on data that teaches hierarchical integration (InfoSeek) yields 16.5% — a 5.5× gap that cannot be explained by model scale, training algorithm, or inference-time scaffolding.

The reframing's significance extends beyond this paper because it provides a diagnostic language for reasoning about reasoning. When a model fails on a complex QA task, is it failing at decomposing the question into sub-problems? At identifying which sub-problems are parallel vs. sequential? At executing parallel constraint intersections? At propagating intermediate results upward? Prior work could only say "the model fails at multi-hop reasoning"; InfoSeek's framework enables finer-grained diagnosis by mapping the question onto a Research Tree and checking which vertices the model resolves correctly and where errors propagate. This diagnostic capability — even if not fully exploited in the current paper — provides a foundation for targeted improvements that was absent from the flat-complexity view.

The economic shift: making structured data synthesis cheap enough to be infrastructure. The paper's 571.80totalcostfor52,138questions—approximately571.80 total cost for 52,138 questions — approximately 0.011 per question — changes the economics of training data production for complex reasoning. Prior to InfoSeek, the dominant approaches to synthetic data generation for reasoning were either expensive (LLM-based generation requiring per-example inference calls to frontier models) or small-scale (WebShaper's 500 examples, SimpleDeepSearcher's 871 trajectories). At $0.011 per question, InfoSeek makes it economically feasible for academic labs and smaller companies to build custom deep research training datasets tailored to specific domains or knowledge bases. This is analogous to what the shift from hand-labeled to automatically constructed QA datasets did for open-domain QA a decade ago — it transforms data from a scarce resource into a commodity, enabling a new class of experiments that were previously cost-prohibitive.

The key engineering insight enabling this cost — that the core tree construction operations can be rule-based (hyperlink extraction, atomic claim parsing) rather than LLM-based — is likely to influence subsequent data synthesis efforts beyond deep research. The paper demonstrates that you can separate the strategic decisions (what structure to build, which the Planner makes) from the tactical execution (extracting specific facts from webpages, which the Browser performs using lightweight rules), and that this decomposition yields orders-of-magnitude cost reductions while maintaining quality. This design pattern — structured planning with lightweight grounded execution — could apply to synthesizing training data for other reasoning-intensive tasks (legal analysis, scientific literature review, competitive intelligence) where the reasoning structure can be formalized but the factual content must be grounded in real documents.

Reconciling prior contradictions. The paper indirectly resolves a tension in the agentic search literature between two camps: those who argue that complex reasoning is an emergent property of scale (implicitly, the large-model baselines in Table 4 that score near zero on BrowseComp-Plus despite having 10× more parameters) and those who argue that targeted training can induce reasoning capabilities in smaller models (the Orca/distillation tradition). InfoSeek's results show that both positions are partially correct, but they depend on a variable that neither camp had adequately characterized: the structural isomorphism between training data and evaluation tasks. A large model trained on flat and linear-chain data (Qwen3-32B) fails on hierarchical tasks not because it lacks capacity, but because it has never been trained to perform the specific operations (parallel constraint intersection, hierarchical propagation) that hierarchical tasks require. A small model trained on structurally matched data (InfoSeeker-3B) succeeds not because it is "smarter," but because its training data taught it exactly the operations the evaluation demands. This reconciles the conflicting findings: scale produces emergent general capability only when the training distribution covers the structural patterns required at test time; targeted training produces capability in small models only when the training data is structurally faithful to the target task. The BrowseComp-Plus results (Table 4) thus serve as a natural experiment demonstrating that structural mismatch, not absolute model capacity, is the binding constraint.

Research directions that become more attractive. The paper makes several research directions newly tractable or more compelling:

  • Process-supervised training for information-seeking becomes practical because InfoSeek provides intermediate labels (vertex answers, constraint decompositions, evidence provenance) for free as a byproduct of tree-based synthesis. Prior to InfoSeek, process supervision for QA required expensive human annotation of reasoning steps (analogous to the PRM800k dataset for math reasoning). InfoSeek eliminates this annotation bottleneck, making it feasible to train process reward models or to provide step-level feedback during RL — directions the paper flags but does not explore.

  • Compute-optimal inference-time scaling for deep research — analogous to the test-time compute scaling work for math reasoning (Snell et al., 2024) — becomes analyzable because InfoSeek provides a principled difficulty metric (Research Tree complexity, measured by vertex count and tree depth) that can be used to study how inference budgets should be allocated across problems of varying structural complexity. The paper's Table 2 shows that Qwen2.5-72B failure rate increases monotonically with vertex count, establishing a difficulty gradient; future work could study whether more difficult problems benefit from different search strategies (more parallel queries? deeper sequential chains?).

  • Data-structure-to-capability compression as a general phenomenon can now be studied systematically. InfoSeek provides a controlled setting where the structural properties of training data (tree depth, branching factor, constraint type) are explicitly manipulated and recorded, enabling experiments that measure how specific structural features of training data translate into specific reasoning capabilities in trained models. This moves beyond the coarse "data quality matters" narrative to a more mechanistic understanding of what kinds of data structure teach what kinds of reasoning.

Research directions that become less attractive. The paper's results also diminish the case for certain approaches:

  • Pure inference-time agentic scaffolding without training — frameworks like Agentic Reasoning (Wu et al., 2025c) and AgentOrchestra (Zhang et al., 2025) that orchestrate existing models without modifying their weights — faces an implicit challenge from the BrowseComp-Plus results. If a 3B model trained on structured data can outperform a 32B model using inference-time scaffolding, then the returns to better scaffolding may be diminishing relative to the returns to better training data. Inference-time frameworks are not rendered obsolete, but the paper suggests that the highest-leverage investment for improving deep research capability is in training data structure, not in more sophisticated orchestration.

  • Training exclusively on NQ and HotpotQA for agentic search — the standard practice in the Search-R1, ZeroSearch, and AutoRefine lines of work — is shown to produce models that barely attempt multi-step search on BrowseComp-Plus (1.39 average search calls, Table 5) and achieve near-zero accuracy. The paper does not prove that NQ+HotpotQA training is useless (the models do well on single-hop and multi-hop benchmarks in Table 3), but it demonstrates that such training does not transfer to hierarchical reasoning tasks. Future work on agentic search training should either use InfoSeek or adopt InfoSeek's synthesis methodology to produce structurally appropriate training data.

Follow-Up Research This Work Enables

1. Process-supervised RL for deep research using InfoSeek's intermediate labels. The paper preserves intermediate vertex answers, constraint decompositions, and evidence provenance as a byproduct of tree-based synthesis, but its training pipeline uses only binary outcome rewards. A natural next step is to design a compound reward function that provides feedback at multiple granularities: a process reward for correctly identifying intermediate entities (e.g., successfully determining that the blurred city is London), a decomposition reward for generating sub-queries that match the ground-truth sub-problem structure, and an evidence integration reward for correctly intersecting constraint sets. A strong experiment would train three variants — outcome-only reward (the paper's current approach), process reward using the intermediate vertex answers from InfoSeek's trees, and a combined reward — and compare final BrowseComp-Plus accuracy as well as training efficiency (how many GRPO steps to reach a given accuracy threshold). This would directly test the paper's claim that the meta-information "opens new opportunities for compound reward design" and would quantify the marginal benefit of process supervision in the information-seeking domain. The hypothesis, motivated by findings in mathematical reasoning (Lightman et al., 2023), is that process rewards would accelerate training and improve final performance by providing denser learning signals, particularly for problems with deep trees where the outcome signal is very sparse.

2. Equalized-dataset-size ablation to isolate InfoSeek structure from scale. The paper's critical ablation (Table 5) compares 50K+ InfoSeek examples to 5K NQ+HotpotQA examples, confounding dataset structure with dataset size. A direct follow-up would train InfoSeeker on matched dataset sizes — for example, 50K NQ examples, 50K HotpotQA examples, and 50K InfoSeek examples, all using the same backbone model and training algorithm — and evaluate on BrowseComp-Plus. If InfoSeek maintains its advantage at equal scale, this provides strong evidence that hierarchical structure is the causal factor. If the gap narrows substantially, it would suggest that dataset size explains a significant fraction of the reported improvement, weakening the paper's central structural claim. Additional conditions could include training on 50K examples of a "flat CSP" dataset (InfoSeek trees restricted to depth 1, all parallel constraints with no sequential dependencies) to isolate the contribution of hierarchy specifically, and on 50K examples of a "pure sequential" dataset (trees with branching factor 1, only depth) to isolate the contribution of parallel constraint integration. This experiment would produce a decomposition of InfoSeek's BrowseComp-Plus performance into components attributable to scale, breadth (parallel constraints), depth (sequential chains), and their interaction (hierarchy).

3. Refiner Agent ablation and scaling analysis. The InfoSeeker workflow's Refiner Agent (Qwen2.5-7B-Inst) is an uncontrolled variable whose contribution to BrowseComp-Plus performance is unknown. A systematic ablation would evaluate InfoSeeker-3B with: (a) no Refiner Agent, feeding raw search results directly; (b) the current Refiner Agent (Qwen2.5-7B-Inst); (c) a larger Refiner Agent (e.g., Qwen2.5-32B-Inst); (d) a Refiner Agent trained specifically on InfoSeek's evidence extraction patterns. The key metric is BrowseComp-Plus accuracy, but secondary metrics should include average context length (to measure the "context compaction" benefit the paper claims) and per-step reasoning quality (e.g., whether the model's subsequent queries are more targeted after receiving refined summaries). If the Refiner Agent accounts for a large fraction of InfoSeeker-3B's performance, this would shift the paper's narrative from "InfoSeek data teaches deep research" to "structured search workflows enable deep research" — a weaker but still valuable claim. If the Refiner Agent contributes minimally, it validates InfoSeek training as the primary driver. Additionally, testing whether the Refiner Agent can be eliminated after further training (e.g., by distilling its summarization capability into InfoSeeker-3B through an additional fine-tuning stage) would assess whether the current two-model workflow is a training crutch or a permanent architectural requirement.

4. Difficulty-adaptive search strategy allocation as a function of Research Tree complexity. InfoSeek's Research Trees provide a ground-truth measure of problem complexity (vertex count, tree depth, branching factor) that is independent of any particular model's performance. This enables a study analogous to compute-optimal test-time scaling: for a given inference budget (total search calls), how should the model allocate parallel vs. sequential search as a function of estimated problem complexity? The experiment would vary the InfoSeeker workflow's parallel query count and maximum reasoning turns as a function of predicted difficulty (using a lightweight classifier trained on InfoSeek's tree statistics), and measure whether difficulty-adaptive allocation achieves higher BrowseComp-Plus accuracy than fixed-allocation baselines at the same total search budget. The paper already shows (Table 2) that problem difficulty correlates with vertex count; a follow-up would determine whether different search strategies are optimal for different difficulty levels. One might hypothesize that shallow-but-broad trees (many parallel constraints, few sequential steps) benefit from more parallel queries per turn, while deep-but-narrow trees benefit from more sequential turns with fewer queries each. This would extend the paper's contribution from "what data to train on" to "how to deploy the trained model efficiently."

5. Cross-domain transfer: does HCSP training generalize beyond the InfoSeek entity distribution? InfoSeek synthesizes questions from Wikipedia and general webpages, and BrowseComp-Plus uses a 100K web page corpus that likely overlaps in entity and topic distribution. To test whether HCSP-structured training teaches general hierarchical reasoning or domain-specific search patterns, a follow-up would construct a deep research benchmark in a domain not represented in InfoSeek's knowledge base — for example, scientific literature (questions requiring navigating paper citation graphs and intersecting findings across studies), legal documents (questions requiring hierarchical constraint satisfaction across statutes and precedents), or financial filings (questions requiring multi-step evidence synthesis from SEC documents). If InfoSeeker-3B maintains its relative advantage over NQ+HotpotQA-trained models in these out-of-domain settings, it would support the claim that HCSP training teaches transferable reasoning strategies. If the advantage disappears, it would suggest that InfoSeek training primarily teaches domain-specific search patterns (which Wikipedia entities to query, what types of constraints to expect) rather than general hierarchical reasoning. This experiment is particularly important because the paper's single-benchmark evaluation (BrowseComp-Plus) cannot distinguish between these interpretations.

6. Negative result: stress-testing the HCSP formalization's boundaries — what happens when problems cannot be cleanly formalized as constraint intersections? The HCSP framework assumes that deep research questions can be decomposed into sub-problems with unique, verifiable answers obtained through constraint intersection. But many real-world deep research tasks involve reasoning that does not fit this mold: evaluating contradictory evidence (where constraint satisfaction fails because different sources disagree), generating synthetic insights (where the answer is not a pre-existing entity but a novel conclusion), or navigating ambiguous constraints (where "population exceeds five million" is clear but "significant economic impact" is not). A stress-test experiment would construct a dataset of such "non-HCSP" deep research problems — either by modifying InfoSeek to introduce ambiguity (blurring constraints with vague terms, introducing conflicting evidence sources, requiring synthesis rather than entity identification) or by curating real-world tasks from existing complex QA benchmarks — and evaluate whether InfoSeek-trained models outperform baselines or whether their HCSP-shaped training becomes a liability (e.g., the model inappropriately tries to intersect constraints that cannot be cleanly intersected, or insists on unique answers when multiple are valid). A negative result (InfoSeek training degrades performance on non-HCSP tasks) would refine our understanding of when structured training data helps vs. hurts, and would motivate research on training data that spans a broader range of reasoning structures.

Practical Applications and Downstream Use Cases

Cost-efficient batch inference for complex research queries. Organizations that need to answer large volumes of complex, multi-step research questions — think tanks producing policy analyses, competitive intelligence firms tracking industry developments, legal researchers conducting due diligence — currently face a choice between expensive human analysts and expensive API calls to frontier models. InfoSeek's results suggest an intermediate path: fine-tune a small model (3B parameters) on a domain-specific InfoSeek-style dataset synthesized from the organization's own document corpus, then deploy it for batch inference with a lightweight search infrastructure. At $0.011 per training example for data synthesis and 2 hours of training on a single 8×H100 node, the total cost of producing a domain-specialized deep research model is in the low thousands of dollars — comparable to a few dozen hours of human analyst time. The model would not match frontier API performance (16.5% vs. GPT-5's 55.9% on BrowseComp-Plus), but for applications where recall matters more than precision — identifying promising leads for human analysts to investigate, filtering large document sets for relevant evidence — a 16.5% hit rate with near-zero marginal cost per query could dramatically reduce the human effort required for initial research phases. The key enabler is InfoSeek's open-source synthesis framework, which allows organizations to build training data from their own knowledge bases rather than relying on generic QA datasets.

On-device or edge-deployed research assistants with privacy guarantees. Many deep research applications involve sensitive documents that cannot be sent to cloud APIs — corporate internal documents, medical records, legal case files. InfoSeeker-3B's 3B parameter count makes it feasible to run on consumer-grade hardware or edge servers, enabling fully local deep research with no data exfiltration. The model's 8.24 average search calls on BrowseComp-Plus (Table 4) indicate that it engages in extended investigation, but with optimization (reducing Refiner Agent overhead, quantizing the model) the workflow could run entirely on-device with a local document index. The 16.5% BrowseComp-Plus accuracy is modest in absolute terms, but for privacy-sensitive applications where the alternative is no automated research at all (because cloud APIs are prohibited), even modest accuracy provides substantial value. The open-source nature of both the dataset and the training pipeline means organizations can adapt the model to their specific document collections and query patterns without dependence on external API providers.

Data generation for self-improving research agents. The paper's two-round training pipeline (SFT → RL → rejection sampling → SFT → RL) is itself a template for iterative self-improvement: train a model on synthesized HCSP data, use it to generate solution trajectories, filter the trajectories for quality, and retrain. InfoSeek's preservation of intermediate structure (vertex answers, constraint decompositions) makes this loop more powerful than standard outcome-based self-improvement because the filtering stage can validate not just final answers but intermediate reasoning steps. A concrete deployment scenario: an organization starts with InfoSeek's general-domain dataset, trains a base model, deploys it on their domain-specific document collection, collects successful trajectories (verified by domain experts or by automated checks against known answers), and uses those trajectories — enriched with InfoSeek-style intermediate annotations — for further fine-tuning. Over multiple iterations, the model would progressively specialize to the organization's domain while maintaining the hierarchical reasoning patterns learned from InfoSeek. The low cost of InfoSeek-style data synthesis ($0.011 per question) means organizations could also continuously expand their training data as their document collections grow, maintaining model freshness without expensive human annotation.

Benchmarking and diagnosing reasoning failures in production systems. InfoSeek's Research Tree structure provides a diagnostic framework that could be applied to evaluate and debug deployed deep research systems. For any complex question a production system fails on, an engineer could manually (or semi-automatically) construct the corresponding Research Tree — identifying the sub-problems, constraints, and dependencies — and then trace where in the tree the system's reasoning diverges from the ground truth. Is it failing at the leaf level (retrieving wrong facts for individual constraints)? At the integration level (correctly retrieving facts for all constraints but failing to intersect them)? At the propagation level (solving sub-problems correctly but not integrating their results into higher-level reasoning)? This diagnostic precision, enabled by the HCSP formalization, could guide targeted improvements — if failures concentrate at constraint intersection, invest in better evidence integration training; if they concentrate at retrieval, invest in better query generation or document processing. This application does not require adopting InfoSeek's full synthesis pipeline; it only requires adopting the HCSP conceptual framework as a diagnostic lens, making it immediately applicable to any deployed deep research system.