HybridResearcher: Bridging the Structured-Unstructured Boundary for Deep Research Agents

From measuring the hybrid gap to training for it

Enterprise questions rarely stay inside one system. Take this question:
"Which of our Tier-1 suppliers are affected by a port strike, and what did we spend with them last quarter?"
To answer it, an agent has to run a precise query over governed tables. It also has to search messy, fast-changing text on the web. It then has to carry the result of one step into the other without losing any constraints along the way.

In HybridDeepResearch: Enforcing Rigor Across SQL and Web Search for Enterprise Agents, we showed that agents most often fail at the handoff. This post asks the next question: can we teach the handoff directly to a small model?

Our answer is HybridResearcher. It's a full training recipe, covering data construction, SFT and RL, for agents that must connect structured and unstructured sources in a single chain of reasoning.

TL;DR

• Real questions span more than one source: AI agents are getting good at finding and combining evidence from a single type of source, such as database tables or web text. But real business questions often need both. For example, one enterprise question may need a result computed over an internal database plus evidence found on the web.
• Benchmarks confirm the real gap: HybridDeepResearch benchmark showed that even frontier agents struggle when evidence must move between a database and the web.
• HybridResearcher trains a small agent to connect both sources: We built HybridResearcher-4B, a 4B-parameter agent trained on examples that require both sources. Each example starts from a text-to-SQL or web-search task that has already been validated. We then synthesize the missing source around a "bridge entity" taken from that task's own output. We keep an example only when strict checks confirm that neither source can answer it alone. Then we train the model with supervised fine-tuning (SFT), followed by reinforcement learning (RL).
• Results: On the HybridDeepResearch benchmark, HybridResearcher-4B scored 30.0 points higher in pass@8 than its base model, Qwen3.5-4B, in our evaluation. It also scored 8.3 points higher than the much larger Qwen3.5-397B-A17B under the same setup.
• Single-source capabilities improve too: The model also beat its base model on held-out single-source benchmarks (BrowseComp, BrowseComp-Plus and Spider 2.0-lite). This suggests small models can learn to reason across sources without losing the skills they already have.

Why more single-source training data does not teach the bridge

There is plenty of training data for text-to-SQL and for web search on their own. So the obvious first step is to train on both and hope the skills combine. We tried this and found two obstacles.

Single-source skills don't combine on their own. We fine-tuned Qwen3.5-4B on successful trajectories from SQL-only data, search-only data and a mix of both. We then evaluated each model on the 120-question hard subset of HybridDeepResearch. None of the three versions helped. SQL-only training reached 31.67% pass@8, within one question of the base model's 30.83%. The mixed and search-only versions dropped to 29.17% and 15.83%. Single-source trajectories never use the output of one tool as the input to the other, so the model never learns that step.

Naive hybrid data invites shortcuts. We looked at teacher trajectories that passed standard correctness filters. In 79.5% of them, the agent never ran a meaningful SQL query. Instead, it answered from memory and skipped the cross-source step entirely. A model trained on these trajectories learns to fake the bridge. Adding more uncurated data only makes the problem worse.

Growing hybrid tasks from validated seeds

HybridResearcher avoids building hybrid tasks from scratch. Instead, each training task starts from a seed whose difficulty is already established: an existing text-to-SQL task or a hard web-search question. We then build the missing source around a bridge entity taken from the seed itself. That way, the new task inherits the seed's difficulty. Figure 1 shows the full pipeline, from preparing question-answer pairs, to generating agent trajectories, to training the final model.

Each task goes in one of two directions:

• SQL-to-Search (SQL2S): The SQL result produces the entity that the web search needs.
• Search-to-SQL (S2SQL): The web search produces the value that the SQL query consumes.

Figure 1: The HybridResearcher pipeline. We start from validated text-to-SQL and deep research seeds and build both single-source and cross-source (SQL2S/S2SQL) question-answer pairs. A hybrid agent then generates candidate trajectories. Successful trajectories are used for SFT, and hard or incomplete cases are used for RL.

Starting from SQL

We use text-to-SQL datasets with real databases as seeds, including BIRD, Spider 1.0, KaggleDBQA, BULL, Archer and Classics, plus the synthetic SynSQL-2.5M. This yields about 36K SQL-originated question-answer pairs.

For SQL2S, we pick a cell from the SQL output to act as the bridge, such as the store "Northstar" in Figure 2. A membership check confirms that this value appears in the output but not in the question, so the agent has to run the query to find it. To stop the model from answering from memory, we invent new facts about the bridge entity using made-up but pronounceable names. Each invented fact comes with a gold document and hard-negative documents that each change exactly one constraint. The correct answer satisfies every clue. Each distractor misses exactly one.

For S2SQL, we go the other way. We take a string value from the gold SQL's WHERE clause, such as "Oslo," hide it in the question and replace it with web clues that point to it. An execution check confirms that the value matters: removing it has to change the query result.

Figure 2: Building SQL2S and S2SQL tasks from SQL seeds. Top: an output cell becomes the bridge, and invented facts about it become search constraints. Bottom: a WHERE-clause value becomes the anchor, and the agent must resolve it through web search before writing the query.

Starting from search

For hard search seeds, we build a synthetic database around an entity from the question or the answer. In Figure 3, the city "Qujing" is taken from the question and becomes the answer to a new SQL task (SQL2S). The answer "1994" becomes a parameter that a new SQL query needs (S2SQL). Each database goes through five stages: plan, improve, build, bridge and a final improvement. At the planning stage, we pick SQL patterns such as ranking or grouped aggregation. The schema stores only raw event-level records and leaves out any columns that would give away the answer. We also add similar entities so the target is hidden among realistic data. That way, the SQL side can't be solved with a simple lookup.

Figure 3: The search-originated pipeline. One hard-search item can produce either a SQL2S or an S2SQL task, depending on whether the bridge comes from the question or the answer.

For both directions, a task has to pass strict checks before it becomes training data. The bridge can't leak into the question or into the final SQL result, and the database must require a real query rather than acting as a lookup table for a puzzle the agent has already solved.

Training: SFT for the basics, RL for the hard cases

SFT. We generated trajectories with strong teacher models (Qwen3.5-397B-A17B-FP8 or DeepSeek-V4-Flash) running inside our agent harness. We kept only the trajectories that an LLM judge marked correct. Alongside these trajectories, the SFT mix includes about 10K hybrid examples from our earlier HyDRA work and about 26K text-to-SQL examples used as-is. All training runs in an offline environment built on a frozen corpus and a local retriever, which keeps experiments reproducible.

RL data curation. We collected 21K hybrid tasks that the model still couldn't solve after SFT and filtered them down to 0.7K high-signal tasks in three stages:

1. Difficulty filtering: Remove tasks that are always solved or never solved.
2. Quality filtering: Remove tasks with unclear answers or inconsistent evidence.
3. Balancing: Split the final set 1:1 between SQL-originated and search-originated tasks, and 1:1 between the two directions.

RL stability. Our RL training builds on CISPO and adds two techniques. The first is hard gating. A rollout ends early with zero reward if it makes malformed or nonexistent tool calls, repeats the same queries, or fails to produce a valid answer. As Figure 4 shows, without hard gating, rollouts grow longer and duplicate tool calls pile up as training goes on. The second is a five-vote judge ensemble. On our training rollouts, a single judge disagreed with the majority 8.2% of the time. That rose to 12.2% for S2SQL tasks, where the judge has to evaluate SQL output together with entities found on the web.

Figure 4: Rollout length, tool calls per rollout and share of rollouts with duplicate calls during RL training, with and without hard gating.

Results: a 4B agent that competes with much larger models

We evaluated on the 120-question hard subset of HybridDeepResearch, split evenly across S2SQL, SQL2S and parallel tasks. We report pass@8, the share of questions solved at least once in eight attempts, and avg@8, the average accuracy across those eight attempts. None of the evaluation benchmarks appear in our training data.

Figure 5: HybridDeepResearch hard subset results (pass@8 and avg@8, %). HybridResearcher-4B compared with its base model and larger reference models in our evaluation setup.

SFT nearly doubled overall pass@8, from 30.83% to 59.17%. RL added further gains, especially in consistency: overall avg@8 rose from 23.75% to 27.19%, and S2SQL avg@8 rose from 26.88% to 31.56%. In this setup, the final 4B model scored higher than Qwen3.5-397B-A17B-FP8 on both metrics and came within about five points of pass@8 of GLM-5.2-FP4 and Claude Sonnet 4.6. SQL2S remains the hardest direction for all the models we tested.

Hybrid training also improved single-source skills. A common risk when teaching a small model new behavior is that it forgets what it already knew. We didn't see that here. As Figure 6 shows, hybrid SFT raised BrowseComp pass@8 from 54.03% to 61.37%, BrowseComp-Plus from 60.84% to 69.76% and Spider 2.0-lite execution accuracy from 59.26% to 65.19%. After RL, all three benchmarks stayed above the base model, and BrowseComp-Plus rose further to 73.13%.

Figure 6: Held-out single-source benchmarks before and after hybrid training (pass@8, %). BrowseComp uses the live web, BrowseComp-Plus uses a fixed corpus of about 100K documents, and Spider 2.0-lite measures text-to-SQL execution accuracy.

What changed inside the agent

When we examined the agent's behavior, we found clear differences between the training stages:

• The base model searches a lot but reads very little. It averages 38.6 web searches per rollout but only 0.29 page visits per search.
• SFT teaches the model to read. Searches dropped to 22.1 per rollout while page visits per search rose to 0.50. The model moved from searching blindly to reading what it retrieved.
• RL makes search more precise. Queries became longer and more specific, and exact repeat queries fell by 63%. On SQL2S, when the gold answer showed up in a search result, the agent used it correctly more often: 27.2% of the time after RL, compared with 18.5% after SFT. RL made these gains without increasing turn counts or token usage.

Some bottlenecks remain. On S2SQL, the bridge entity never showed up in 22.2% of rollouts. And 82.0% of the RL model's wrong answers mentioned a time budget, effort already spent or a guess. In other words, the model often gave an answer while it still knew it was uncertain. Teaching agents to keep searching when they're unsure is a promising next step.

Lessons for building hybrid agents

• Teach the bridge, not just the separate skills. Combining SQL and search data doesn't produce cross-source reasoning. The training data has to show one source's output feeding into the other.
• Check that both tools were actually needed. A correct answer isn't enough. Deterministic checks for membership, leakage and whether the bridge value matters are what keep shortcuts out of the data.
• For RL, data quality beats volume. With the same RL recipe, the curated 0.7K set reached 27.2% overall avg@8, compared with 21.0% for the full 21K pool. In the curated set, 71% of rollout groups produced a useful learning signal, compared with 38% in the full pool.
• Keep reward and tool use clean. Majority-vote judging raised avg@8 from 25.2% to 27.2%. Hard gating raised it from 25.6% to 27.2%. In evaluation, hard gating also cut average tool calls from 76 to 55 per question and repeated calls from 49% to 11%.

What's next

HybridResearcher shows that cross-source reasoning can be taught directly to a compact model. The recipe itself isn't tied to SQL and the web. It needs only a validated single-source task to start from and an entity that can connect it to another source. That makes it a blueprint for other combinations, such as internal documents, code repositories or domain-specific databases. For enterprises, this points toward smaller, more efficient agents that can connect governed data with outside context and produce answers backed by evidence.

Academic Collaborators: Soyoung Yoon, Peiran Xu, Han Wang, Ruofan Wu, Feng Yan, Mohit Bansal, Debiao Li, Seung-Won Hwang