EvoDuet: Bilevel Co-Evolution of Web Searching and Task Solving for Scientific Discovery

What it claims

EvoDuet wraps a web-search loop around an LLM evolutionary-search scaffold such as OpenEvolve. The paper's key argument is that giving the model a search tool is not enough: the queries must evolve alongside the solution. When a search tool sits inside the solution loop (the authors call this "joint-level"), it keeps returning pages it has already seen and the run stalls.

The method needs a strong model. Qwen3.5-9B gains nothing from EvoDuet even though oracle documents do help it. In sampled revisions, the model left retrieved methods unused or implemented them wrongly 26% of the time.

How it works

• Retrieval gate. Each iteration, the LLM writes out its "knowledge gap" for the current parent solution. It then picks one of three actions:
• RETRIEVE: fetch new documents.
• LOOK-UP: reuse documents already stored in the search database.
• NO-OP: proceed with no documents.
• Inner loop: hypothetical evidence scoring. This loop runs over several rounds (R1–R3 in the example). Each round: 1. Build queries aimed at the gap. 2. Search the web (the baseline uses Tavily). 3. Have the LLM predict the evaluator score a candidate built on each document would get. 4. Keep the top-K documents and update a "knowledge state".

The predicted scores steer the next round of queries. No candidate is actually evaluated during this loop.

• Outer loop. Given the documents, the LLM generates N candidates in parallel (×8 in the example) and the best valid child is kept. The documents are stored together with the measured outcome, which guides later searches.
• Model weights. The LLM's weights stay frozen throughout.

flowchart TD
  P[Parent + history] --> G{Knowledge-gap gate}
  G -->|Retrieve| Q[Construct queries]
  Q --> W[Web search]
  W --> S[Predict score per doc]
  S -->|next round| Q
  S --> D[Top-K docs]
  G -->|Look-Up| DB[(Stored docs)] --> D
  G -->|No-Op| N[No docs]
  D --> C[Generate N candidates]
  N --> C
  C --> E[Evaluator]
  E -->|outcome logged with docs| DB
  E --> P

Evidence

Oracle-document study (31 tasks, 4 seeds). Hand-supplied relevant documents raise average NDG by +10.3% for Qwen3.5-9B and by +4.0% for GPT-5.6-Luna. Luna already reaches ≥95% NDG on 16 tasks, which leaves little headroom. The effect varies by task:

Oracle documents hurt NDG by more than 1% on 8 tasks for Qwen and on 4 tasks for Luna.

Parallel generation (Sums/Diffs). Oracle documents do nothing at N=1 (14.8% NDG with them vs 15.4% without). At N=8 they raise NDG from 25.8% to 40.7%.

Joint-level search vs EvoDuet (Denoising, GPT-5.6-Luna, 100 iterations):

Joint-level search stops improving after iteration 50.

Main results (21 tasks, OpenEvolve, 1 candidate per iteration). NDG rises from 74.1% to 78.0% with Luna and from 61.3% to 82.3% with Gemini-3.8-Flash. Parallel generation improves it further.

Records. The best runs beat the prior best on 8 tasks and tie on 3. On Swap Reduction, the router needs 14,835 Q20 SWAPs vs 15,186 for the released SimpleTES program, 2.31% fewer under the same evaluator. On Denoising, EvoDuet beats SimpleTES at an estimated 6.9× lower cost.

Other scaffolds. EvoDuet also improves Top-K and EvoX, but only on Sums/Diffs and Denoising.

Document use. A candidate beats its parent in 67.1% of iterations that retrieved a document predicted to beat the parent, vs 52.1% of iterations with no documents. Across 82 runs:

• 55 used method transfer, applying a retrieved method to the solution.
• 29 included cases where a document predicted to help produced a much worse candidate.

Limits

• Requires a model that can both find and apply evidence. The 9B open model did not benefit.
• Predicted document scores are unreliable. In 29 of 82 runs, a "helpful" document yielded a much worse candidate, so the evaluator must still validate every gain.
• External knowledge can hurt. Rosetta degraded for both models even with oracle documents.
• Gains are small where the baseline already nears SOTA (Luna: +3.9 NDG).
• Cross-scaffold evidence covers only two tasks.
• "Beats SOTA" refers to the best run, not the seed average.
• The 6.9× cost figure is an estimate and is given only for Denoising.
• The fetched text ends partway through the method section. It gives no code, install steps or licence; it mentions a project page but does not show its URL.