🤖 AI

LEVI: Stronger Search Architectures Can Substitute for Larger LLMs in Evolutionary Search

The paper introduces LEVI, an open-source evolutionary search framework that leverages improved solution diversity, intelligent mutation routing, and efficient proxy benchmarks to achieve state-of-the-art results in systems research and prompt optimization at a significantly lower computational cost than existing methods relying on larger LLMs.

Original authors: Temoor Tanveer

Published 2026-05-12

📖 4 min read☕ Coffee break read

CC BY 4.0

Original authors: Temoor Tanveer

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine you are trying to find the absolute best recipe for a complex dish, like a perfect soufflé. In the past, researchers tried to solve this by hiring a world-famous, ultra-expensive celebrity chef (a "frontier" Large Language Model) to taste every single variation and suggest tiny tweaks. While this worked, it was incredibly expensive, like paying a celebrity chef to taste a spoonful of soup every time you added a pinch of salt.

The paper introduces LEVI, a new approach that argues: "You don't need a celebrity chef for every step if you have a better kitchen organization system."

Here is how LEVI works, broken down into three simple ideas:

1. The "Diverse Seed Garden" (Instead of a Single Seed)

The Old Way: Most systems start with just one idea (one seed recipe) and try to improve it. If that one idea is stuck in a "bad neighborhood" (a local trap), the system wastes a lot of money trying to dig its way out, often hiring the expensive celebrity chef to force a change.

The LEVI Way: LEVI starts by planting a whole garden of very different seeds at the beginning. Some might be terrible recipes, but they are different from each other.

The Analogy: Imagine you are looking for the best path through a forest. Instead of starting at one spot and hoping to find the exit, LEVI drops 50 different hikers at 50 different clearings immediately.
The Benefit: Because the garden is so diverse, the system doesn't get stuck. It keeps a map (called a "CVT-MAP-Elites archive") that ensures every new idea is placed in a unique spot, preventing the whole group from clumping together and repeating the same mistakes.

2. The "Smart Kitchen Staff" (Small vs. Big Chefs)

The Old Way: Every time a change is needed, the system calls the expensive celebrity chef, even for tiny tasks like "swap the sugar for honey" or "add a pinch of salt." This is like hiring a Michelin-star chef to chop an onion.

The LEVI Way: LEVI uses a "Role-Aware Router." It acts like a smart kitchen manager:

The Small Chefs (Cheap Models): For 90% of the work—tweaking ingredients, fixing small errors, or making minor adjustments—LEVI uses a fast, cheap, local cook (a smaller AI model). They are great at routine tasks.
The Celebrity Chef (Expensive Model): The expensive chef is only called in rarely, perhaps once every 10 steps, for a "Paradigm Shift." This is when the manager asks the celebrity chef: "Look at all these different recipes we have. Can you invent a completely new style of cooking that none of us have thought of yet?"
The Benefit: You get the creativity of the big chef without paying for them to do the chopping.

3. The "Taste-Test Sample" (Proxy Benchmarks)

The Old Way: To see if a new recipe is good, some systems taste-test it on every single customer in a city (thousands of people). This takes forever and costs a fortune.

The LEVI Way: LEVI realizes that to know if a recipe is getting better, you don't need to ask everyone. You just need a small, carefully selected group of tasters who represent the whole city.

The Analogy: Instead of asking 1,000 people if the soup is good, LEVI picks a "proxy" group of 30 people. If the soup tastes good to this specific group, it's likely good for everyone.
The Benefit: This cuts the number of "taste tests" (evaluations) in half or more, saving massive amounts of time and money while still finding the best recipe.

The Results: Doing More with Less

The paper tested LEVI on real-world problems, like optimizing computer code for data centers and improving how AI answers questions.

The Cost: LEVI achieved the same (or better) results as other systems while spending 3 to 6 times less money. In one specific case, it matched the best results at 35 times less cost.
The Speed: Because it uses a better "kitchen organization," LEVI found the best solutions much faster, often reaching top scores in the first few dozen tries, while other systems were still struggling after hundreds of tries.

The Bottom Line

The paper's main bet is that better organization beats bigger brains. By building a smarter system that manages diversity, uses the right tool for the job, and tests efficiently, you can solve hard problems without needing the most expensive AI models available. It's about working smarter, not just spending more.

Technical Summary: LEVI – Stronger Search Architectures Can Substitute for Larger LLMs in Evolutionary Search

1. Problem Statement

LLM-guided evolutionary methods (e.g., AlphaEvolve, FunSearch) have demonstrated efficacy in domains such as mathematical discovery, code optimization, and prompt engineering. However, these frameworks currently rely heavily on expensive frontier Large Language Models (LLMs) for every mutation and evaluation step. This reliance creates a high barrier to entry, with individual runs costing up to $30 and requiring thousands of calls to models like Claude Opus or Gemini Pro.

The authors argue that this cost is not an inherent requirement of LLM-guided evolution but rather an artifact of inefficient search architectures. Existing frameworks often fail to preserve solution diversity, forcing reliance on larger models to escape local optima. They also treat all mutation calls uniformly, spending frontier-model budgets on local edits that smaller models could handle, and waste resources on redundant evaluations in rollout-heavy settings.

2. Methodology: The LEVI Framework

LEVI (Harness-First Evolutionary Framework) is designed to decouple search performance from model scale by optimizing three specific cost axes: the solution database, mutation routing, and evaluation strategy.

2.1. Solution Database: CVT-MAP-Elites with Bootstrapped Seeding

LEVI replaces standard archives with a CVT-MAP-Elites (Centroidal Voronoi Tessellation MAP-Elites) archive.

Diversity Preservation: Unlike regular-grid MAP-Elites, CVT-MAP-Elites scales gracefully to high-dimensional descriptor spaces without exponential cell growth. It maps candidates to behavioral cells based on a tuple of input-side (e.g., AST features like cyclomatic complexity) and output-side (e.g., runtime profiles) descriptors.
Bootstrapped Initialization: Instead of starting from a single seed, LEVI performs an upfront "seed pass" where an LLM generates a sequence of structurally diverse solutions. These seeds, even if low-scoring, are used to calibrate the archive's descriptor bounds (via z-score normalization and sigmoid transforms) and populate the initial cells.
Behavioral Dimensions: The archive maintains diversity by ensuring that distinct algorithmic identities occupy different cells, preventing the search from collapsing into a single basin of attraction.

2.2. Role-Aware Mutation Routing

LEVI introduces a router that assigns mutation tasks to models based on the specific "role" of the mutation, rather than using a single large model for all steps.

Refinement Route (~90% of calls): Local edits (tweaking constants, swapping data structures) are routed to smaller, cheaper models (e.g., Qwen3-30B-A3B). The robust diversity of the archive absorbs the noise and redundancy typical of smaller models, preventing archive drift.
Paradigm Shift Route (~10% of calls): Periodically, or upon stagnation, a larger model (e.g., Gemini Flash 3) is triggered. Instead of mutating a single parent, the large model receives representatives from distinct, well-separated archive cells and is tasked with proposing a candidate that belongs to a new algorithmic family. This targets structural rewrites rather than local refinements.

2.3. Proxy Benchmark Selection

For settings where evaluation is dominated by rollouts (e.g., prompt optimization), LEVI constructs a proxy benchmark ( $D_{proxy}$ ) from the full validation set.

Rank Preservation: The proxy is selected via greedy forward selection to maximize the correlation between the ranking of candidates on the proxy set and the full set.
Objective Function: The selection optimizes for rank faithfulness (agreement in candidate ordering), separation (discriminative power of examples), and redundancy minimization. This allows the evolutionary loop to run with significantly fewer rollouts per iteration while maintaining the selection signal required for evolution.

3. Key Contributions

Architectural Efficiency: LEVI demonstrates that investing in search architecture (diversity maintenance, role-aware routing, and proxy selection) can substitute for or outperform the use of larger LLMs.
Cost Reduction: The framework achieves state-of-the-art or competitive results at a fraction of the cost of existing frontier-model baselines.
Open-Source Implementation: LEVI is released as an open-source framework, providing a reproducible harness for harness-first evolutionary search.

4. Experimental Results

The authors evaluated LEVI across seven systems-research benchmarks and four prompt-optimization benchmarks.

4.1. Systems Research Benchmarks

Performance vs. Cost: On six of seven problems (Cloudcast, EPLB, LLM-SQL, Prism, Txn Sched, Spot-M, Spot-S), LEVI achieved the best scores using a budget 3.3–6.7× smaller than published frontier-model runs of frameworks like GEPA, OpenEvolve, ShinkaEvolve, and AdaEvolve.
Specific Gains: On the LLM-SQL problem, LEVI outperformed the leading framework using only $0.50, a 35× cost reduction.
Sample Efficiency: In controlled comparisons using the same model (Qwen3-30B-A3B) and budget, LEVI reached high performance 15× faster (in terms of evaluations) than baselines, continuing to improve where others stagnated.

4.2. Prompt Optimization

Rollout Efficiency: On four benchmarks (HotpotQA, IFBench, Hover, PUPA), LEVI matched or exceeded the performance of GEPA while using less than half the rollout budget (2,191 vs. 4,985 rollouts on aggregate).
Proxy Effectiveness: The proxy benchmark selection successfully preserved the ranking signal, allowing the evolutionary loop to converge with fewer full-set evaluations.

4.3. Ablation Studies

Seeding: Removing bootstrapped initialization caused significant performance drops (e.g., a 5-point drop on Spot Scheduling), confirming the necessity of early diversity.
Diversity Dimensions: Richer descriptors were critical for problems requiring multiple algorithmic families (Spot Scheduling) but less critical for problems dominated by a single family (Transaction Scheduling).
Model Routing: The "Paradigm Shift" route was decisive for problems requiring structural jumps (EPLB), where removing large models caused stagnation. Conversely, for local-refinement-heavy tasks (Transaction Scheduling), the large-model route was sometimes overhead.

5. Significance and Claims

The paper claims that the high cost of LLM-guided evolutionary search is largely a solvable engineering problem rather than a fundamental limitation of the paradigm. By shifting focus from "bigger models" to "stronger search architectures," LEVI lowers the barrier to entry for evolutionary discovery.

The authors position LEVI as a proof-of-concept that stronger search architectures can substitute for larger LLMs. They note that while their approach reduces dollar costs by shifting work to cheaper models and stronger architectures, it may require more evaluations, a trade-off that is favorable when evaluations are cheap (e.g., code execution) but less so when they are expensive (e.g., model training). The work suggests a future direction where evolutionary search relies entirely on cheap, open-weight models, provided the search harness is sufficiently robust.