EvoDuet: Bilevel Co-Evolution of Web Searching and Task Solving for Scientific Discovery
Young-Jun Lee, Jinheon Baek, Soyeong Jeong, Minki Kang, Seungyeon Jwa, Jonghyun Choi, Seungho Han, Dongyeop Kang
University of Minnesota · KAIST · Seoul National University · Hanyang University
Published September 30, 2026 · on the feed October 1, 2026 · ▲ 106 · arXiv 2609.40340
The abstract
Evolutionary search with large language models (LLMs) can stall when progress requires external knowledge the model lacks. Supplying relevant documents helps, but simply adding web search tool can keep returning the same pages as solutions change. We introduce EvoDuet, a bi-level optimization method that co-evolves solutions and search queries with fixed model parameters. At each iteration, a retrieval gate lets the LLM assess its knowledge gap and choose to retrieve new documents, reuse stored ones, or proceed without them. An inner loop refines queries and ranks documents by the solution scores they are predicted to yield; an outer loop generates candidates in parallel from these documents and records the evaluated outcomes for later searches. Across 21 optimization tasks with one candidate per iteration, EvoDuet raises OpenEvolve's normalized discovery gain from 74.1% to 78.0% with GPT-5.6-Luna and from 61.3% to 82.3% with Gemini-3.8-Flash, whereas Qwen3.5-9B does not benefit. Our best runs surpass the previously reported best scores on eight tasks, including Swap Reduction on Q20 and Rosetta, and match them on three more. EvoDuet also improves with other scaffolds (e.g., Top-K, EvoX) on Sums/Diffs and Denoising, demonstrating its applicability across evolutionary search scaffolds.
The Brief
2:20A short podcast summary of the paper. Written and voiced by AI.
Transcript
EvoDuet. Bilevel Co-Evolution of Web Searching and Task Solving for Scientific Discovery. By Young-Jun Lee and seven others, from the University of Minnesota, KAIST, and two other institutions. Published on the thirtieth of September. Its code repository is worked out: about one thousand source files, with a readme and a licence.
Evolutionary search driven by a large language model can stall when the next step of progress needs knowledge the model simply does not have. Handing it relevant documents helps. But bolting on a web search tool is not enough on its own, because the search can keep returning the same pages even as the solutions it is meant to serve keep changing.
EvoDuet makes the search evolve too. It is a bi-level optimisation method that co-evolves two things side by side, the solutions and the search queries, while the model's parameters stay fixed.
Each iteration begins at a retrieval gate. There the model assesses its own knowledge gap and chooses one of three moves: retrieve new documents, reuse ones already stored, or carry on without any. Below the gate sit two loops. The inner loop refines the queries, and ranks documents by the solution scores they are predicted to lead to. The outer loop generates candidate solutions in parallel from those documents, then records how they scored, so that later searches can learn from the outcome.
The test is twenty-one optimisation tasks, with one candidate per iteration. EvoDuet lifts OpenEvolve's normalised discovery gain from seventy-four point one percent to seventy-eight percent with GPT five point six Luna. With Gemini three point eight Flash, the jump is from sixty-one point three percent to eighty-two point three percent. Qwen3.5 at nine billion parameters, on the other hand, does not benefit.
The best runs beat the previously reported best scores on eight tasks, including Swap Reduction on Q20 and Rosetta, and match them on three more. EvoDuet also helps other scaffolds, Top-K and EvoX, on Sums and Diffs and on Denoising, which the authors take as evidence it applies across evolutionary search scaffolds.
Search here is not a fixed utility the solver calls. It evolves alongside the solutions, ranked by the scores those solutions earn, so the pages it returns can move as the answers move. That pairing paid off for two of the three models tested, and the one that did not benefit is a reminder that the result depends on the model doing the searching.
Paper Quest · 7 chapters · about 40 min
Play this paper
Learn it by doing: make the calls the authors made, guess the result before you see it, and defend it in a viva graded on your own words. Chapter 1 is right here.
Chapter 1 🧩 · The problem
Every quest starts with a wall. Here it is a model that has run out of things it knows.
You use a language model to improve a solution over many rounds: it proposes candidates, an evaluator scores them, and the best seed the next round. The model's weights stay fixed.
The road ahead
- 1 · The problem ~6 min A language model improving solutions round after round gets stuck when the next step needs knowledge it lacks, and a plain search tool does not fix it.
- 2 · What came before ~3 min
- 3 · The key idea ~9 min Let search queries evolve together with solutions: a gate decides when to search, predicted scores pick documents, and recorded outcomes steer later searches.
- 4 · Choose your own research ~3 min
- 5 · Build the method ~8 min Each iteration runs gate, query refinement with predicted scores, parallel candidate generation, then records real outcomes for later searches.
- 6 · The experiment ~6 min You’ll guess: EvoDuet helped GPT-5.6-Luna and Gemini-3.8-Flash. Did it also help the smaller Qwen3.5-9B?
- 7 · The viva ~5 min Three questions from the examiners, answered in your own words. Win it for the paper’s trophy.
Free, with Google or an email address. Your stars and progress are kept.