[BidClub_]
Machine Learning Street Talk · · 74 min

Google AlphaEvolve - Discovering new science (exclusive interview)

Matej BalogAlexander Novikov

Podcast ↗
TL;DR

  • AlphaEvolve broke a 56-year benchmark by finding a 48-multiplication algorithm for general 4×4 matrix multiplication, beating the 49 obtained by recursively applying Strassen’s 1969 method. The team ran the case largely “for completeness” after AlphaTensor had failed to improve the general-number result; Matej Balog’s first response was disbelief: “Let’s triple-check it.” The algorithm uses complex numbers but also applies to real matrices, including the kind used in neural-network training.

  • The immediate economic evidence is inside Google: one evolved scheduling heuristic recovered an average 0.7% of fleet-wide compute that would otherwise have been stranded, while another change sped training of the next Gemini version by 1%. These gains came in already heavily optimized Google infrastructure. Yet Matej qualifies any dramatic shorthand of instant recursive self-improvement: the feedback cycle is currently “on the order of months.”

  • AlphaEvolve’s edge comes from compounding verified partial improvements, not merely sampling an LLM more times. Language models propose code—“some of them will be stupid, some of them will be amazing, some of them will be really weird”—while automated evaluators filter results and an evolutionary loop preserves diversity, selects promising programs, and asks the models to build on what worked. Paper ablations showed that removing evolution performed “much, much worse.”

  • The addressable domain is broad but bounded by the availability and cost of reliable evaluators. A program can be given a 10-minute evaluation budget, but Keith Duggar’s pushback is fundamental: terminating slow candidates may discard the “godly algorithm” or a temporarily inferior stepping stone to a breakthrough. Physical experiments add another bottleneck, so the proposed bridge is an evaluation cascade that filters many candidates cheaply before spending scarce laboratory or real-world trials on perhaps 10 finalists.

  • AlphaEvolve appears unusually portable across mathematical discovery and production software, although its 6×6 matrix result shows that generality does not erase domain knowledge. The system searched unrestricted algorithms and missed the best-known 6×6 method, whose symmetry imposes a valuable inductive bias and sharply reduces the search space. “General purpose” therefore means adaptable search machinery, not automatic dominance over specialized methods.

  • Better base models directly improve AlphaEvolve, creating leverage above the model layer rather than independence from it. Matej says adding Gemini 2.0 Pro to the ensemble improved results over Gemini 2.0 Flash alone, while the host’s question about 2.5 remained forward-looking. The larger opportunity is to distill discoveries made with evolutionary test-time compute back into future base models, though the team has not yet closed that reinforcement-learning loop.

  • The authors see human judgment—not full autonomy—as a central feature and a potential source of durable differentiation. Researchers choose questions, representations, seeds, evaluators, and follow-up experiments; the system then “squeezes all the juice out of the idea” and improves the human’s intuition for asking the next question. Alexander Novikov prefers this “back and forth between humans and machines,” while the discussion’s broader warning is that AI may flood the world with mediocrity even as it disproportionately raises expert productivity.

Digest · the substance, structured for research

1. AlphaEvolve turns LLM creativity into cumulative, verified search

  • Alexander Novikov’s architectural starting point is non-negotiable: AlphaEvolve tackles problems where any proposed code can be tested automatically and assigned a measure of quality. That evaluator restricts the eligible problem set, but also enables rapid iteration and filters an LLM’s wide distribution of ideas—“some of them will be stupid, some of them will be amazing, some of them will be really weird.”

  • The evolutionary pipeline repeatedly selects promising programs, preserves a diverse population, and returns evidence to the model: “Here’s what you tried before. This thing worked. This thing doesn’t work. Please try to propose a new thing.” Parallel execution supplies the final ingredient, scale, letting many candidate lineages advance simultaneously.

  • Matej Balog argues that evolutionary algorithms naturally fit scientific discovery because “a priori there is no way of knowing” the right approach. Diversity prevents the search from prematurely zooming in on a locally attractive but ultimately suboptimal family of solutions.

  • The episode frames AlphaEvolve as an expansion of FunSearch: instead of evolving one function, it can modify demarcated adaptable regions across a codebase and optimize their interactions. Alexander adds a practical preference: evolutionary algorithms are comparatively quick and “very fun to play with,” whereas setting up reinforcement learning can take considerably more time.

2. Evaluators create both the capability and its hardest boundary

  • Keith Duggar presses on the halting problem: code may compile and run for an hour without revealing whether it will terminate, yet stopping five minutes early could discard “the godly algorithm.” In theory, Matej concedes, no procedure can reveal what a longer run would have done.

  • Matej’s practical answer is to make time part of the task itself. If the goal is a search algorithm that makes progress in 10 minutes, every candidate receives exactly 10 minutes; this deliberately explores algorithms useful within that budget, while potentially missing ones that mature later.

  • Keith’s sharper objection is that fixed cutoffs constrain open-ended discovery: a currently slower program might be the stepping stone that eventually “hops you over to something more efficient.” The discussion notes that this restriction did not bite much on the paper’s well-chosen problems; Tim Scarfe calls the limitation “massive.”

  • Alexander turns the limitation back toward human research: “How do you know that you should stop working on your problem as a human?” Another month might solve it, but neither researchers nor machines can know that in advance.

3. Seeds determine whether the system exploits an idea or searches broadly

  • Matej distinguishes two operating modes. A detailed prompt or strong initial program causes AlphaEvolve to “squeeze out the juice of that idea” through local refinements; by default, the team instead provides nearly empty functions returning zero or false and lets the base models explore broadly.

  • For matrix multiplication, AlphaEvolve did not directly emit the final multiplication scheme. Starting from little more than “use gradients,” it evolved a gradient-based search algorithm with complex loss functions, update rules, penalties, and unexpected injections of randomness—“human-like,” Matej says, but not code a human would obviously choose to try.

  • An unpublished experiment varied the quality of human guidance: contributors studied a problem for either two minutes or 30 minutes, recorded their ideas, and passed those notes into the system. AlphaEvolve preserved the idea’s essence while optimizing numerous details—sometimes intelligently, sometimes by trying enough variants until one stuck.

4. Execution, meta-prompts, and reusable libraries expand the knowledge base

  • Keith initially identifies two knowledge sources: the pretrained model’s compressed corpus and the starting program. Matej adds a third: execution itself, because the system can choose an algorithm to run and thereby acquire the empirical fact of what that algorithm actually does.

  • AlphaEvolve already implements meta-prompting. Before solving a task, the model is told which prompt it will receive and asked to modify that prompt; the system then curates prompts that empirically generate stronger evolutionary runs.

  • Tim’s proposed “next trillion-dollar business” is a robust cross-domain program library—the “new oil”—whose modules transfer by analogy. Matej sees an early version in matrix experiments: independently discovered algorithms differ, and using them to initialize later runs provides useful inspiration.

  • Alexander says the human operators are becoming a library too: collaborating with many Google teams feels like a consultancy, accumulating intuition about what works and what to try next. Technically, Matej sees no barrier to programs optimized across broader task families; maintaining a shared AlphaEvolve repository is more an organizational question.

5. A 48-multiplication construction breaks the 4×4 benchmark

  • The schoolbook method for multiplying two 2×2 matrices computes four output entries with two scalar multiplications each, totaling eight. In 1969, Volker Strassen shocked mathematicians by arranging “magical cancellations” that require only seven; seven was subsequently proved optimal for that case.

  • Even 3×3 remains unresolved: the known lower bound is 19 multiplications, while the best available algorithm uses 23 rather than the schoolbook 27. The gap survives because the space of possible algorithms becomes immense long before the matrices look large.

  • For 4×4 matrices, the longstanding general algorithm recursively applied Strassen to 2×2 blocks, producing 7×7, or 49, multiplications. AlphaTensor had improved only the special Boolean, modulo-two case; after years without a general improvement, AlphaEvolve found 48 during a run performed largely “for completeness.” Matej recalls: “I just couldn’t believe it. Let’s triple-check it.”

  • The construction’s counterintuitive feature is its use of complex numbers. Searching over complex algorithms appears harder because they must work for both complex and real inputs, yet that enlarged formulation produced the breakthrough; real matrices, including those used in neural-network training, remain a valid special case.

6. Small constructions scale recursively, but search complexity explodes

  • These discoveries are not confined to tiny inputs. Just as Strassen can operate recursively on blocks of a large matrix, an algorithm discovered for 4×4 blocks can be recursively embedded into multiplication of much larger matrices.

  • The underlying tensor grows brutally: the 4×4 task requires decomposing a 16×16×16 tensor, while 5×5 becomes 25×25×25—growth Matej describes as “an exponential with a quadratic in the exponent.” AlphaEvolve scales farther than AlphaTensor, but no method escapes the eventual wall.

  • At 6×6, AlphaEvolve did not match the best-known result. The team intentionally supplied no matrix-specific tricks and searched unrestricted forms, whereas the leading method assumes a particular symmetry and regularity, shrinking the space dramatically. Matej calls that missing inductive bias the clearest explanation, not evidence that the evolutionary machinery had found the optimum.

7. Choosing the representation remains an unsolved research judgment

  • Matej’s candid starting point is, “We ourselves don’t have all the answers here.” AlphaEvolve may search directly for a solution, evolve a short constructor that generates it, discover a search algorithm that finds it, or co-evolve a sequence of algorithms that progressively refines it.

  • His concrete analogy is a fractal: representing it as a pixel grid wastes its regularity, while a short generating function captures the structure. Less regular targets may instead demand direct representation or a complex search procedure, and the correct abstraction is not knowable a priori.

  • Co-evolution offers another axis: multiple algorithms can gradually refine a candidate rather than one program producing a terminal answer. The practical consolation is cheap reformulation—teams can try several representations and observe which one works best.

  • Keith connects these modes to mathematical deduction, construction, and enumeration. Matej says constructive problems fit AlphaEvolve directly; some impossibility claims can be dualized into constructions, but proof search is harder because correctness is binary. LLM-generated “soft scores” might judge whether a partial proof appears to make progress, but that path was not demonstrated in this paper.

8. Evolution compounds nuggets that brute-force sampling leaves isolated

  • Matej says repeatedly questioning a chatbot gives “completely the wrong idea” about scaled capability. A billion independent samples might contain useful nuggets, but not the full solution; evolutionary selection identifies those nuggets and builds on them across subsequent generations.

  • The paper’s ablations support that distinction: removing evolution made performance “much, much worse.” AlphaEvolve is therefore not merely inference-volume arbitrage; its value comes from retaining discoveries, revisiting neighborhoods, and accumulating improvements.

  • Alexander’s CAPSET example from FunSearch used a small model without even explaining the mathematical problem. The target was roughly 50 lines of Python—far too specific to appear accidentally—so success was “completely essential to hill climb,” modifying partial programs and retaining whatever measurably worked.

  • Matrix search likewise required engineered intermediate signals. The system could run an algorithm 10 times and optimize how often it succeeded, first mastering 2×2 and then moving to 3×3; related matrix sizes also preserve ideas that may be useless initially on the target size but become transferable after refinement elsewhere.

9. Program synthesis can expose mechanisms, not just output scores

  • AlphaEvolve sometimes returns code simple enough for a human to verify across all inputs and deploy almost immediately. Matej contrasts that with neural networks requiring hosting, inference resources, retraining, and other operational considerations.

  • In the CAPSET work, researchers noticed repeated use of four: loop indices were taken modulo four, while array accesses used positions i, i+4, and i+8. Inspecting this pattern produced a mathematical hypothesis, which the team fed into the next run and used to achieve substantially better results.

  • The matrix-search code produced a stranger but still inspectable insight. Humans might tune the weight or schedule of a quantization loss that drives approximate solutions toward exactly verifiable integers or fractions; AlphaEvolve instead created an entire time-varying shape for that loss—too elaborate for researchers to be likely to try manually.

  • Alexander’s distinction is that many machine-learning ideas sound sensible after the fact: “Ideas are sort of cheap.” The difficult part is identifying which five plausible ideas actually work. For other tasks, the system can intentionally favor performance over legibility and evolve complex heuristics whose holistic mechanism remains unclear.

10. Production gains validate the system beyond benchmark mathematics

  • Google engineers supplied a candidate scheduling method for assigning jobs to machines, then evolved a remarkably simple heuristic. Fleet measurements after deployment showed it continuously recovered an average 0.7% of compute resources that otherwise would have remained stranded—a small percentage with large absolute value at Google’s scale.

  • Another AlphaEvolve result sped training of the next Gemini version by 1%. Matej emphasizes the specificity: this is not an autonomous intelligence redesigning itself instantly, but a concrete optimization to already heavily optimized infrastructure.

  • The breadth surprised Matej most. Research tools normally require an additional body of work before becoming operationally useful; AlphaEvolve could both advance mathematical constructions and generate algorithms deployed directly into Google’s critical compute stack “out of the box.”

  • That dual use depends on executable artifacts. The same machinery can emit a direct solution, or—as in matrix multiplication—“an algorithm that finds an algorithm,” allowing improvements to land at different layers of a production or research pipeline.

11. Expensive physical validation demands a cascade of evaluators

  • Alexander suggests translating fuzzy objectives into executable rewards. A desired final image or natural-language description could become Python scoring code, while a vision-language model verifies the binary outcome and evolved auxiliary rewards provide the smoother signal needed to train a robot.

  • Keith stresses the gulf between rejecting code that crashes immediately and testing a robot that may be damaged, a biological hypothesis in a laboratory, or a medical idea through clinical trials. Simulator success cannot make those later evaluations cheap or consequence-free.

  • Alexander’s answer is a ladder of increasingly expensive tests, with LLM feedback, Elo-style comparisons, or other prioritization deciding which candidates advance. He cites Google’s Co-Scientists as a related effort to rank ideas when hard feedback is difficult.

  • Matej says AlphaEvolve already supports evaluation cascades: score many programs quickly, inspect fewer for longer, then send perhaps 10 candidates into real-world experiments. This mirrors ordinary research under finite budgets—cheap filters first, scarce definitive trials last.

12. Better models, human collaboration, and elastic compute set the frontier

  • The system benefits directly from stronger base models. Tim describes an ensemble of Gemini 2.0 Flash and Gemini 2.0 Pro and asks what 2.5 might unlock; Matej’s ablation wording is that adding Gemini 2.0 Pro improved results over Gemini 2.0 Flash alone. He says AlphaEvolve is currently “riding the wave” of frontier-model improvement.

  • Evolutionary test-time compute can lift capability beyond a base model far enough to make a scientific discovery. Matej’s open question is whether that improvement can be distilled back into the model by closing a reinforcement-learning loop; “the possibility is clearly on the table,” but the team has not done it.

  • Alexander resists treating greater autonomy as the sole destination. He favors richer human intervention—commenting on candidates, injecting ideas, refining questions—and plans trusted testing with academics while the team explores interfaces for this “symbiosis space.”

  • Cost remains deliberately unresolved. Tim cites “on the order of 100 compute hours” from section 2.3, but Matej gives no universal figure: easy problems may resolve almost immediately, hard decades-old questions can absorb sustained scaling, and open problems are often impossible to price beforehand. AlphaEvolve’s claim is elasticity and continued improvement, not predictable discovery on a fixed budget.

Tim Scarfe

For 56 years, designing an algorithm with fewer than 49 multiplications was an open problem over any field, until today. We've had exclusive early access to the brand-new Google AlphaEvolve paper, which was released 1 minute ago. We did a technical interview with the authors before anyone else. The paper itself drops a bombshell, setting world records for many algorithmic and mathematical challenges.

1. The Matrix Multiplication Barrier

In the world of computer science, few problems are as fundamental as matrix multiplication. For over half a century, a specific efficiency benchmark in this domain, particularly for 4-by-4 matrices, seemed insurmountable. The search space for optimal algorithms is immense, making exhaustive exploration practically impossible, even for relatively small matrices.

In 1969, Volker Strassen revolutionized the field by discovering an algorithm to multiply two 2-by-2 matrices using only 7 scalar multiplications, down from the standard 8. The established best practice for larger matrices, like 4-by-4s, was to apply Strassen's 2-by-2 method recursively. For 4-by-4 matrices, this meant 7 times 7, resulting in 49 scalar multiplications. Today, AlphaEvolve beat this record.

Google DeepMind has a long history of building AI systems which actually invent new knowledge through experimentation and iteration, rather than just building a glorified database. We saw AlphaGo, which beat Lee Sedol, learning from human games and even surpassing champions through self-play. AlphaZero was purely self-play, and AlphaFold predicted millions of 3D protein structures that had never been measured experimentally. AlphaDev discovered faster sorting algorithms.

Google DeepMind recently has been focused on scientific discovery with AlphaTensor, which framed the problem of finding faster matrix multiplication algorithms as a game, achieving breakthroughs. FunSearch took us even further, using large language models to find new mathematical solutions by evolving code. And now, AlphaEvolve represents the next stage in this lineage.

Google AlphaEvolve

For the usual case of matrices that have arbitrary numbers in them, still nothing better was known than doing Strassen twice using 49 multiplications. So we were really excited when we used AlphaEvolve in this setting. We actually didn't even hope that it would find something better than 49 because we were trying for so long with AlphaTensor. We just ran it for completeness because we wanted to have this table in the paper, showing that we had tried on all the sizes up to 5 or 6. Remarkably, it found a faster algorithm which uses 48 instead of 49 multiplications.

2. The Evolutionary Coding Agent

Tim Scarfe

It's a bit like Cursor on steroids. It iteratively refines algorithms, drawing on the creative power of LLMs using meta-learning, library learning, automated evaluation, and evolutionary search. The AlphaEvolve paper describes it as an evolutionary coding agent which substantially enhances the capabilities of pre-trained large language models on difficult tasks.

Of course, their first paper was FunSearch, which was very similar. The main difference, I think, was that it was just searching for a single function, rather than AlphaEvolve, which can essentially work over an entire codebase. You just demarcate adaptable regions in a codebase, and it can search for those. Of course, it's even optimizing for interactions between those functions in different parts of your codebase. One potential issue, as Keith Duggar pointed out, is the classic halting problem in computer science.

3. The Halting Problem Persists

Speaker 2

But there's also a really subtle limitation here I want to explore with you guys a bit, which is running the programs themselves. We face issues, right? You face issues with the halting problem, for one thing. You start running some code; the code compiles fine—

Tim Scarfe

Mm-hmm.

Speaker 2

—or it doesn't crash immediately and it starts running, but maybe some time goes by, like an hour, and you're like, “Well, jeez, is this thing ever going to terminate?”

Google AlphaEvolve

In theory, you're of course right. You can never tell what an algorithm would have done if you ran it for longer. But in practice, it actually hasn't been any sort of issue for us in the applications that we looked at.

Tim Scarfe

Alexander Novikov added that this challenge is very much like a fundamental aspect of human research too.

Speaker 3

How do you know that you should stop working on your problem as a human? Or maybe you spend 1 month more and then you solve it, right? It's hard.

Speaker 2

Of course, there are still limitations. They didn't bite much on my halting-problem limitations. In practice, it was okay for them, but they had these very well-chosen problems, right? With matrix multiplication, you know if it's any slower than Strassen's algorithm, maybe you can turn it off. But the problem is that that restricts your open-ended search capabilities, right?

Tim Scarfe

Massively.

Speaker 2

You can't go down the path of a potentially slower algorithm for now, one that may get you to a stepping stone that hops you over to something more efficient, right?

Tim Scarfe

It is interesting, isn't it, that so many breakthroughs in science are unknown unknowns? We might have a nose for what is interesting, but we never really know where to find the answers. So often, we find them through sheer luck. But there must be at least 1 step we can take in the direction of mechanizing and accelerating this process.

In the case of matrix multiplication and several other scientific problems which had a clear evaluation function, this new evolutionary approach achieved much that decades of human research could not.

Google AlphaEvolve

We just ran it for completeness because we wanted to have this table in the paper, showing that we had tried on all the sizes up to 5 or 6. Remarkably, it found a faster algorithm which uses 48 instead of 49 multiplications. When 1 of my teammates messaged on the channel, “Oh, it seems like we have this result,” I just couldn't believe it. Let's triple-check it.

Tim Scarfe

AI's growing ability to generate entirely new, provably correct algorithms can advance the frontier of science. And the really cool thing is that AlphaEvolve has already been applied to optimize mission-critical real-world systems within Google.

Google AlphaEvolve

They're able to speed up really heavily optimized pieces of important computational infrastructure within Google.

4. Google Reclaims Compute

Tim Scarfe

For instance, take Google's massive data centers. Efficiently scheduling computing jobs is a really complex operation. If done suboptimally, expensive servers will sit around idling. The Google engineers placed a candidate solution into AlphaEvolve and then evolved a smarter heuristic which assigned jobs to machines much more efficiently.

They said, “Post-deployment measurements across Google's fleet confirmed the simulator's results, revealing that this remarkably simple yet effective function continuously recovers, on average, 0.7% of Google's fleet-wide compute resources, which would've otherwise been stranded.” Now, that's a huge saving on Google's scale, right? In another instance of self-improvement, it even found ways to accelerate the training of the very Gemini models which power AlphaEvolve itself.

Google AlphaEvolve

We have found a way to speed up the training of the next version of Gemini by 1%, and we've been able to unstrand resources in the bold data center.

Tim Scarfe

This instance was also interesting because it generated not only the solutions, but also the programs which generated them.

Google AlphaEvolve

Whenever you look at the index in the for loop, you just look at the index modulo 4. And when you index into the array, you're indexing at position i, i + 4, and i + 8. Like, okay, what's going on?

Just by inspecting the code, we were actually able to develop what you can think of as a mathematical insight or a mathematical hypothesis. That hypothesis turned out to be really crucial for then improving the result.

5. Humans Guide The Search

Tim Scarfe

A key aspect of AlphaEvolve's sophistication lies in its flexible approach to representing the search problem.

Google AlphaEvolve

The LLMs will propose a broad range of things, and some of them will be stupid, some of them will be amazing, and some of them will be really weird. Then, by having the evaluator, you can filter through those and identify the ones that are actually important and improving things.

Tim Scarfe

Isn't it really cool that rather than trying to generate the solution itself, AlphaEvolve can, just like Inception, generate the thing which generates the solution? We should play some Inception music in the background.

The thing we found really interesting about AlphaEvolve is that it's still very much a humans-in-the-loop thing. Humans identify what's interesting. They find problems that have clear evaluators. They place candidate solutions in the loop, and then AlphaEvolve will traverse this cone of possibilities and make jumps along the way. Then the cycle continues.

So this is very much sketching a future of AI where there is a strong collaborative loop between humans and AIs. We should just bring in how you modeled this representation. You had these different approaches: you could directly model the solution; you could model a constructor function, where you're actually learning a function which itself constructs the solution; you could be learning a search algorithm, which is what you did with the matrix multiplication; and you also spoke about co-evolution as a possibility.

So many people are talking about this vision of AIs that can autonomously drive cars or do anything, generating content without any supervision from humans, and that hasn't really panned out, to be honest. Certainly, a lot of the content on the internet is slop. Do you remember the dead internet theory by IlluminatiPirate, this guy on an internet forum a couple of years ago? He said that by now, most content on the internet would be generated by AI, and it would have a kind of superficiality to it, and he was right.

But it doesn't necessarily mean that AI is bad, right? What's missing is that we need to have this exchange. We need to use AIs as tools, and we need to guide them, refine the results, and do the process iteratively. That's kind of what AlphaEvolve does. It mechanizes the correct way of using AI.

Speaker 1

The thing that makes AlphaEvolve so cool and powerful is this back-and-forth between humans and machines, right? The humans ask questions, the system gives you some form of the answer, and then you improve your intuition. You improve your question-asking ability, right? And you ask more questions.

Speaker 2

I gave this talk a few times about generative AI, and the big warning I gave is just the rise of mediocrity. We're going to be inundated and flooded with mediocrity, and the best content will still be produced by the most skilled people. All that's going to happen is that, as this tide of mediocrity grows larger and larger, people will get hungrier and hungrier for the cream—for the things that are rising to the top, right?

I think all that's going to happen in the end is that skilled people's productivity is just going to rise. They'll continue to be differentiated from the mediocre hordes whose productivity is also enabled. The hordes become more productive, experts become more productive, and, as a whole, we all become more productive.

Tim Scarfe

And while we're on the subject of amazing, innovative architectures for discrete program synthesis and reasoning and whatnot, why don't you consider applying to work at Tufa AI Labs? That's if you're an ML research scientist or ML engineer. Benjamin Cruzie is running the lab. It's in Zurich at the moment, and they're thinking about opening an office in San Francisco as well. They would love for you to get in contact with them and apply if you're interested in working for them. So give Benjamin a shout. Guys, welcome to MLST. It's an honor to have you both here.

So we have had privileged access to read your AlphaEvolve paper. It's really exciting because this is very much up our street. We love program synthesis, and we love evolutionary methods. We've had Kenneth Stanley on, and Jeff Clune—I was speaking to him at NeurIPS—and, of course, he wrote the MAP-Elites paper, which influenced some of the work that you guys have done.

But, from a thousand miles away, could you describe the work that you've done?

Speaker 1

We are presenting a coding agent called AlphaEvolve. What this agent is able to do is design quite advanced algorithms. When I say advanced, I mean algorithms that are able to make new discoveries in the sciences, and we have quite a few examples in mathematics and computer science in this paper. On the practical side of things, they're able to speed up already heavily optimized pieces of important computational infrastructure within Google.

Speaker 2

I'm curious: what made you guys think, “This is a component that we need in a hybrid system, along with verifiers and LLMs and whatnot, to take us a step forward”?

Speaker 1

If you consider the process of scientific discovery, then it's a very natural choice. You mentioned that you spoke to Kenneth. On a high level, evolutionary algorithms give you diversity in the exploration process, making sure that you don't, early on in the process, just zoom in on a particular approach, which might be suboptimal in the end. You keep exploring the vast array of possibilities that you have.

Especially when you think about trying to solve really difficult problems and make new scientific discoveries, a priori there is no way of knowing what is going to be the right approach. So you do need to make sure that you keep exploring different possibilities. Evolutionary algorithms are just a good technical tool that fit the bill really well for this purpose.

Speaker 3

Also, I think they're very fun to play with, right? If you want to set up an RL algorithm, it's going to take you some time, depending on the algorithm, I guess. With EA algorithms, you can just do it, right? You have LLM ideas, you just call things, you try things. It's fun.

Tim Scarfe

Alex, can you sketch out the architecture? Many folks at home will be familiar with FunSearch, for example, and I guess this is an evolution of that—pun intended. Can you sketch out how the whole thing works?

Speaker 3

Of course. Should I assume that people are aware, or should I start from scratch with the FunSearch bits?

Tim Scarfe

Let's keep this bit really simple. We'll have a progressive disclosure of complexity. We'll have a hook, and it'll be super broad, and then we'll progressively get more detail. But in this bit, just do it at a super high level. How does the whole thing work?

Speaker 3

Yeah, makes sense.

6. The Evaluator Drives Evolution

The high-level architecture of AlphaEvolve is an evolutionary method where you basically pair the two. We only focus on problems where you have a way of evaluating progress, right? For any given piece of code that the system gives you, you can automatically test whether it's good or not and how good it is.

I think this is maybe the key aspect of the results we got. Having this evaluator, on the one hand, restricts you to the set of problems where you can have one, but on the other hand, it's quite a broad range of problems. Then it gives you a lot: you can quickly iterate and get feedback.

What it gives you in particular is the ability to pair the creativity of LLMs with this evaluator. The LLMs will propose a broad range of things, and some of them will be stupid, some of them will be amazing, and some of them will be really weird. By having the evaluator, you can filter through those and identify the ones that are actually important and improving things.

This pairing of LLMs with evaluators is wrapped in an evolutionary pipeline that tries to iteratively identify the most promising pieces of code, focus on improving those, and expose them to the LLM: “Here's what you tried before. This thing worked. This thing doesn't work. Please try to propose a new thing.” The final ingredient is scale—making those things run in parallel.

Speaker 2

You mentioned that needing the evaluator limits the class of problems. But there's also a really subtle limitation here that I wanted to explore with you guys, which is running the programs themselves. We face issues, right? You face the halting problem, for one thing.

You start running some code; the code compiles fine or doesn't crash immediately, and it starts running. But maybe some time goes by—an hour—and you're thinking, “Is this thing ever going to terminate? Is this going to contribute to my gradient or not? I don't know.” So maybe you have to terminate it after some resources are consumed.

But if you waited just 5 more minutes, you would have gotten an answer that was the godly algorithm, right? This is a fundamental problem. How do you deal with it now? How do you think we're ever going to get around issues like that? What do you envision for overcoming that limitation?

Speaker 1

In theory, you're of course right. You can never tell what an algorithm would have done if you ran it for longer. But in practice, it actually hasn't been any sort of issue for us in the applications that we looked at.

Speaker 2

Okay.

Speaker 1

One concrete thing I can say is that often you might frame the problem in a way where the time constraint is built into the problem definition. Let's say you could say, “I'm trying to solve this open problem in mathematics, and I'm looking for a search algorithm that is able to make progress on this open problem. But I want a search algorithm that is able to make progress in 10 minutes.” So that is part of my problem definition.

When I'm evaluating the proposals that the language models make, I only run them for 10 minutes.

And so I only explore the space of algorithms that are able to make something happen within those 10 minutes. Sure, I might miss out on algorithms that would have done even better when run for longer, so that is indeed a principled thing that you can never eliminate. But in practice, it actually hasn't been an issue for us.

Speaker 3

And I guess this question is also fundamental to internal research, right? How do you know that you should stop working on your problem as a human? Or maybe you spend another month and then you solve it, right? It's hard. I don't know.

Tim Scarfe

Yeah. It's like the secretary problem. One thing I'm fascinated by, interviewing so many people in the space, is that we speak about diversity preservation, novelty, serendipity, open-endedness, and creativity, and we really want to design algorithms that can break free, that can make creative jumps. Demis spoke about this ladder of creativity, where you have inventive creativity. That's the thing that we really need.

As I understand it now, in your system, it's a little bit like an automated version of Cursor, where you have these code gates and you put an initial solution in there. So there's a little bit of domain knowledge. There was one example where I think you decided to use a bin-packing algorithm for doing the scheduling on the hardware at Google. And I guess the question is: depending on the starting solution, there's a kind of cone of things, of leaps that we can make. Can you speak to any examples where the system made really imaginative leaps?

Speaker 1

Yes. I can talk to that. And indeed, you identified one interesting feature of the system, which is that depending on what you tell it at the beginning, you can guide the process. So if you give it fairly specific instructions or you ask the system to start from a specific type of solution, then what it will usually do is squeeze out the juice of that idea that you gave it, or squeeze out the juice of that initial solution, see how it can tweak it, and bring it to its maximal potential.

Sometimes this is the right approach to take, maybe when the problem is particularly difficult or has some specific features. But by default, you would start with a solution that's really, really empty. So you give AlphaEvolve a code skeleton where all the functions have almost an empty implementation. You just return zero or return false and so on. And you just let it be completely creative.

It just has to rely on the background knowledge of the base LLMs, and it can explore in all possible directions. And with the evolutionary algorithm, it makes sense to preserve the diversity as you keep doing the exploration. One particular example I can talk about is that we applied AlphaEvolve to discovering algorithms for matrix multiplication, and we did it by asking it to actually design a kind of search algorithm—a gradient-based search algorithm—that looks for matrix multiplication algorithms in turn. So it's a bit of a meta thing: you look for an algorithm that finds an algorithm.

But within that first algorithm, the search algorithm, we started from a really simple code skeleton, giving it basically nothing. We just told it, "Use gradients," basically. And then it was able to write these complex loss functions and update functions, which had all sorts of tricks about penalizing various behaviors and introducing randomness in completely unexpected ways. We were like, "Okay, wow. This is the type of code that maybe a human could plausibly write, but would they have actually thought of writing this particular piece of code?" That was really an aha moment, at least for me: wow, this is doing something kind of human-like, but not something that obviously a human would try.

Speaker 3

And maybe another cool story about this is that I don't think we added it to the paper because maybe a paper is not the right format for this. But Adam on our team did a cool experiment on trying to give advice from humans to the system. He asked a few people, "Please think about this problem for 2 minutes. Please think about the problem for 30 minutes, and then compare it, write down the notes, and give them to the system to guide it through the process." Then he compared what the outcome of that would be.

And you can see that, as Matej was saying, it's kind of squeezing all the juice out of the idea. So it will preserve the essence of the idea because it guides the LLM toward things like that, but it will optimize a lot of small things. In a lot of cases, it will be in intelligent ways. In a lot of cases, it will be kind of, "I'll try a bunch of things, and one of them will stick." But it's kind of cool to watch.

Speaker 2

Yeah. And so at the moment, the architecture has, let's say, maybe 2 sources of base knowledge. It has the base model itself, which is obviously a compressed version of all the corpus it's been trained on, including tons of code and algorithms and numerical recipes and whatever. And then it has the starting program that you put in, the sort of gated bits of logic and whatnot. Is there any room for an augmentation that's almost a middle ground where there's, say, a secondary database that contains modules or pieces of code that are known to be very effective in other problems, that it can somehow simultaneously draw on?

Speaker 1

Yes. A few points on this. One is that you mentioned there are 2 sources of knowledge in the system, and debatably, I would say that there is a third source, which is that the system can decide to augment its own knowledge. What I mean specifically is that the system proposes an algorithm, and then that algorithm is going to be executed on a machine, and you will see the results of having run that algorithm. So, on a sufficiently high level, you can think of it as the system can decide, "Okay, I want to gain a piece of knowledge: what does this algorithm do when you actually run it?" So that is an important component.

But maybe going closer to the essence of your question, indeed, there could be a separate, human-curated database of useful modules or anything of that sort. But even more excitingly, this database can be curated by the system itself. This is an idea that we are thinking about for AlphaEvolve, but there is a related idea that is already implemented and mentioned in the paper, which is not building a curated set of modules that are generally useful, but a curated set of prompts that tend to work well. So there is this idea called meta-prompting described in the paper—

Tim Scarfe

Mm.

Speaker 1

—we actually ask our language models to propose their own prompts. We just tell them what we are trying to do: we are trying to do this evolutionary algorithm for improving on this particular problem, and we are going to prompt you with this particular prompt. But before we do that, please propose a modification to this prompt itself. And then we curate a set of prompts that actually work well for this purpose. In spirit, that's a similar idea, although it's curating prompts rather than programs, but both make sense to me.

Tim Scarfe

Yeah. I think if I understand the direction Keith was going in, everything you've just described is fascinating. It's various forms of meta-learning to basically create diversity and divergence. But I feel that the next trillion-dollar business could be this: in program learning, we want to construct a library, and right now we're kind of expanding this library of functions for a particular purpose.

But what if the library itself was the new oil? What if there was strong robustness between these programs that we've learned for this thing, and they generalize through some analogical relation to other programs and other domains? What if the new language model paradigm was actually a kind of program database? Do you think that could work?

Speaker 1

Yeah. I think that's a fascinating idea, and we see maybe some first glimpses of that. So it is true that for now we are going in the depth direction. We just focus deeply on a problem and try to solve that problem. But even within that path, let's say when we worked on matrix multiplication, we saw that when we run AlphaEvolve different times, we discover slightly different algorithms.

And then it's actually a useful technique to take those algorithms and use them to initialize future experiments. So that's kind of a first step toward building this database of things that were useful in the past to act as inspiration for solving future problems. So, yeah, but maybe Alex has more thoughts.

Speaker 3

Maybe another similar thing that I feel is happening is not that we store or necessarily use the database of programs we produced over all the experiments we did, but that our own human intuition as users of the system is definitely evolving. I kind of feel like a consultant, right? Like, a person.

We collaborate with a lot of teams at Google, trying to help them run things with AlphaEvolve, and through that process, we gain a lot of knowledge of what works, what doesn't, and what we should try next. This kind of thing is somewhat similar to what you're describing, right?

Speaker 2

I can almost imagine AlphaEvolve having its own repo, whether it’s internal or maybe nice enough to put up on GitHub for us. It would just be constantly evolving, contributing to its own repo, maintaining it, and categorizing it, and people could go take a look. “I wonder if AlphaEvolve has come up with a better search algorithm. Go check the search area and see if it’s got anything new there.”

Google AlphaEvolve

Yeah. Technologically, I don’t see hurdles for this. It’s maybe the organizational question of how exactly to make it happen. One particular technological piece that’s already there is that we already look for programs that work well across a range of tasks.

Right now, maybe this range is fairly constrained because we care about the constrained range, but there is nothing blocking us from expanding it. Concretely, we would be looking for AI search algorithms that are able to find, let’s say, matrix multiplication algorithms for different sizes simultaneously. So there is this sort of generality, but there is nothing preventing us from saying, “Let’s look for search algorithms that actually work well across a much broader range of tasks that’s not just matrix multiplication, but also other search problems.”

Tim Scarfe

Can we meditate on the matrix multiplication thing? Only because that’s the headline hook of this video. I think we’re going to start the video by saying, “There’s this amazing result. There was this Strassen guy 56 years ago. He had this big result. Now AlphaEvolve has just defeated it.”

There are quite a few things to explore here. Obviously, please just explain the whole thing, but there’s also some interesting stuff around the fact that we went up to, I think, a maximum of—this is complex 2D matrix multiplication—you went up to rank six, and even that was a bit of an overshoot. There were some interesting properties where, as the rank went up, it started to get a little bit sketchy, but it did improve more. Can you just talk through that whole story?

Google AlphaEvolve

Let me start with the high-level picture first. Multiplying matrices is a very basic operation, and some of us get taught this operation in high school. There is a very specific way you multiply matrices when you’re taught to do this in high school: at every step, you need to take 1 row of 1 matrix and 1 column from the other matrix. You compute the scalar dot product of these 2 things, and that gives you 1 entry in the output.

This is 1 specific algorithm, which is the basic algorithm for multiplying matrices. For every element in the output matrix, you need to do 1 dot product. For a long, long time, people thought this was obviously the only way to multiply matrices. How could there even be something better?

Then you mentioned Volker Strassen in 1969. It was really a shock to the mathematical community. He wrote this paper saying that there is actually a faster way of doing it. Already for multiplying 2-by-2 matrices, which is the smallest nontrivial case, if you do it the high school way, you need to do 8 multiplications because there are 4 entries in the output matrix. It’s a 2-by-2 matrix, and each scalar inner product requires 2 multiplications, so 4 times 2 is 8.

Strassen came up with this ingenious procedure that only requires 7 multiplications. It’s kind of a magical procedure where you build some combinations of entries from the 1st matrix and the 2nd matrix, multiply them, and then combine the 7 products in such a way that you get these magical cancellations and the result is correct. This was a big surprise in 1969, and it opened up an entirely new area of research: for 2-by-2 matrices, you can do 7 multiplications instead of 8.

People quickly proved that 7 is actually optimal for that small case. But already for 3-by-3 matrices, which you might think is laughably small—surely people must have figured out the best way to do that—we still don’t know. Even today, we know that you need at least 19 multiplications to multiply 2 3-by-3 matrices, but the best algorithm we have uses 23. There’s this gap between 19 and 23 that people just haven’t been able to close for years.

The reason is that even though the matrices are very small, the space of possible algorithms for how you could multiply them is just completely immense. Computationally, there is no hope at all of doing this exhaustively. So already for 3-by-3 matrices, it’s an open problem, which is crazy.

For 3-by-3 matrices, the best algorithm uses 23 multiplications. That’s at least better than the algorithm you get taught in high school, which would be 27, so there is at least some progress on making it better. But for 4-by-4 matrices, which is the next size, the best algorithm that had been known was just to apply Strassen’s algorithm recursively twice.

Because Strassen’s algorithm is for 2-by-2 matrices, if you have a 4-by-4 matrix, you can consider it as a block matrix of 2-by-2 blocks, where each block itself is a 2-by-2 matrix. You can do Strassen twice, and because Strassen requires 7 multiplications, doing it twice gives you 7 times 7, or 49 multiplications.

This was the only known way to multiply 4-by-4 matrices quickly: using 49 multiplications by applying Strassen twice. That had been the situation since 1969. This is where our work comes in.

2 years ago, we built AlphaTensor, which was a specialized reinforcement learning agent for discovering matrix multiplication algorithms. That agent did find something faster, but only for matrices over GF(2). This is a very special case where you want to multiply matrices in which every entry is 0 or 1, and when you do the multiplication, you do everything modulo 2.

For that case, AlphaTensor found something faster. But apart from that, for the usual case of matrices that have arbitrary numbers in them, nothing better was known than applying Strassen twice, using 49 multiplications.

We were really excited when we used AlphaEvolve in this setting. We didn’t even hope that it would find something better than 49 because we had been trying for so long with AlphaTensor. We ran it for completeness because we wanted to have this table in the paper showing that we had tried all the sizes up to 5 or 6.

Remarkably, it found a faster algorithm that uses 48 instead of 49 multiplications. When 1 of my teammates messaged in the channel, “It seems like we have this result,” I just couldn’t believe it. We had to triple-check it, but it was indeed correct.

It also has 1 really appealing feature. Usually, when you think about multiplying matrices, you want to multiply matrices where the entries are real numbers or maybe integers. Multiplying matrices where the numbers are complex is perhaps a bit less common. But real matrices are just a special case of complex matrices, so if you find an algorithm that can multiply complex matrices, you can also apply it to real matrices. It’s just a generalization.

What’s cool here is that, let’s say you care about multiplying real matrices, which is what you care about when you train neural networks—a very common use case. A priori, you might just look for an algorithm that uses real numbers. But you can say, “Actually, what if we look for a complex algorithm?”

A priori, you would think that’s a more difficult task because that algorithm would apply not only to real matrices, but also to complex matrices. But by making the task more difficult, AlphaEvolve was actually able to find an algorithm that uses complex numbers and therefore applies to both complex matrices and real matrices. That’s the result we were most excited to get.

As you were asking in your question, we also applied AlphaEvolve to other matrix sizes. As you go to bigger and bigger cases, like 5-by-5 and 6-by-6, the problem becomes much, much harder very quickly. It’s kind of an exponential with a quadratic in the exponent because the tensor—this cube that we sometimes show in the visualizations, which you have to decompose—grows quadratically with the size of the matrices that you multiply.

For 4-by-4 matrices, you have to deal with a tensor of size 16 by 16 by 16. For 5-by-5 matrices, it’s 25 by 25 by 25, so it’s exploding very quickly. Of course, as you go higher, at some point your method will not scale. But what we show is that AlphaEvolve scales further than AlphaTensor, so there is some progress in the scaling direction.

One important point to clarify is that, in all these cases, we look at small cases of matrix multiplication—2-by-2, 3-by-3, and 4-by-4 matrices—but that doesn’t mean you can only apply these algorithms to matrices that are this small. As I already alluded to with Strassen’s algorithm, you can apply them recursively.

If you have a big matrix, you treat it as a block matrix and apply these algorithms for smaller matrices recursively.

Tim Scarfe

Yeah, it’s fascinating, and it’s such a fun domain to work in. It’s almost magical that even when you get to 3-by-3, it becomes intractable. I’m always fascinated by cases like that in mathematics. It’s like, we can do it for dimensions 1, 2, and 3, but then when we get to 4, it’s just totally different. It completely falls apart.

But as you went higher, you also had cases where AlphaEvolve couldn’t match the current performance and actually found worse algorithms. What do you attribute that to? Why was it—

Google AlphaEvolve

Yeah.

Tim Scarfe

Yeah.

Google AlphaEvolve

In the case that’s the biggest one we show in the paper, 6-by-6 matrices, there’s a very clear reason for that. We tried to apply AlphaEvolve without giving it domain knowledge about the problem. We just wanted to see how good AlphaEvolve is as a general-purpose tool, so we started from scratch and didn’t tell it about any tricks for developing matrix multiplication algorithms.

The best-known algorithm for 6-by-6 matrix multiplication uses a very specific inductive bias, which means that it’s looking for algorithms that have a specific symmetry in them. It only looks for algorithms that have a regularity in the algorithm. If you only look for algorithms that have this regularity, it’s a much smaller search space. In that search space, you’re able to scale to much larger sizes.

But we just didn’t try to incorporate this symmetry into our search. We looked for algorithms of unrestricted form, and that is, at least to me, the clearest reason why we didn’t match the best-known solution in that case.

Tim Scarfe

Mm-hmm.

7. Representation Unlocks Creativity

One of the things that fascinated me most about the paper is that we’re obviously very interested in abstraction and representation. Even in the example that you just gave, Strassen was learned to be used as a sort of dynamic programming formulation, so it was used recursively.

I’m thinking to myself: Is that a demonstration of deep abstraction, or is it a kind of superficial, one-step abstraction where the knowledge of Strassen was in its local neighborhood and it was composing that? In an ideal world, what we want algorithms to do is compose abstract basis knowledge—knowledge that is as far down the stack as possible—to increase our flexibility.

We should also bring in how you modeled this representation. You had these different approaches. You could directly model the solution. You could model a constructor function, so you’re actually learning a function that itself constructs the solution. You could be learning a search algorithm, which is what you did with matrix multiplication. You also spoke about co-evolution as a possibility.

This is mind-blowing in the sense that there’s some human design and intuition in how you design the optimization target. But there’s this ambiguity in the ways that you can represent so many of these problems and how they relate to each other. Can you talk me through that?

Google AlphaEvolve

Yeah. First of all, I want to be upfront about the fact that we ourselves don’t have all the answers here. We have this tool, AlphaEvolve, and we see that—

Tim Scarfe

Oh, wow.

Google AlphaEvolve

Okay, it’s general. It’s like—yeah, not even about AlphaEvolve. We have this general tool that we can apply here and here and here, and for every problem, there are different ways we can apply this tool. But a priori, we only have some intuition about the right level of abstraction at which to apply it.

As you were mentioning, Tim, sometimes the best thing you can do is directly search for the solution. Sometimes you search for a simple constructor that constructs the solution. As an illustrated example, let’s say you’re looking for a solution and you think it’s going to be very regular. Maybe it’s going to look like a fractal—that’s the typical example. To describe a fractal, you can use a very short piece of code. In that case, it makes sense to look for a description of the fractal not as a grid of pixels, but instead as a short piece of code that generates the fractal.

In other applications, maybe the solution is very different and not so regular. Maybe you want to look for the solution directly, or you want to look for a complex search algorithm that finds the solution. Sometimes you want to have a sequence of algorithms that gradually refine the solution, which is the co-evolution approach.

A priori, it’s not clear at all which one is going to work best in which situation. That is definitely in the future-work category, to build up that understanding. But one positive side of things is that AlphaEvolve is easy to set up in all the different formulations. Often in practice, you just try different things and see what works best.

Tim Scarfe

I can’t believe you guys don’t have all the answers. I don’t know why I’m here now. But in all seriousness, Tim mentioned these 3 modes that AlphaEvolve currently runs in, and it really reminded me of mathematicians. Mathematicians—or there are at least 3 main ways in which proofs are done, right? They’re either done by deduction, construction, or enumeration. Those almost seem to be very parallel to these 3 methods.

I feel like there’s probably some deep connection there that I’m missing. I’m curious if either of you have any thoughts on that. Alex, any thoughts on that deep connection there, or not?

Speaker 3

Not sure. Yeah, it’s an interesting observation. Matej, did you want to say something?

Speaker 1

One thing is that when you think about constructions, that is where AlphaEvolve is most obviously applicable. The examples that we show in the paper are cases where you have open problems and make progress on those open problems by finding better constructions.

That’s where it’s applicable out of the box. But if you think about other approaches to making progress on other types of mathematical problems, let’s say the problem isn’t obviously about a construction—for example, if you want to prove impossibility results, like lower bounds—then there are perhaps 2 approaches you can take at a high level.

One is that problems that don’t look like a construction often become a construction if you frame them in the right way. For example, you have the duality theorems for linear programming between the primal and the dual, so you can often switch the side that you’re actually trying to prove and turn something that isn’t a constructive problem into a constructive one. That’s kind of a glib answer, but it’s something you can often do.

The more difficult and general answer is that sometimes you’re actually looking for a proof rather than a construction. You can think of a proof as an algorithm. It’s a sequence of steps that you need to execute to prove a statement. This is still within the space of algorithm discovery and something that we can be thinking about doing.

But there’s one technical hurdle that we have some initial signs of overcoming, although it’s not something that we have done in this paper. If you’re looking for an algorithm that is a proof, then the proof is, at the end of the day, either correct or not. The reward is binary; it’s 0 or 1.

For now, we have focused on problems where you can make gradual progress, where you can gradually improve the score—not just switch from 0 to 1 in a single step, but gradually become better and better until you improve on the best-known construction.

Of course, even as humans, when we write proofs, we face the same issue. The proof is only correct once it’s actually done. But as we’re working on the proof, we have intuitions about whether we’ve actually made progress—whether we’ve built some understanding about the problem. If so, it seems likely that this will be a part of the eventual proof.

We’ve been exploring the possibility of using scores that are not hard scores, but soft scores. Maybe a language model can itself provide feedback: Does it look like we’ve made progress toward solving the problem? We do see a path toward attacking these binary problems, such as searching for proofs. But it’s not something that we’ve already done; it’s just something we see as a possibility for the future with this type of technique.

Speaker 2

There are so many surprising things in this paper, and I know Tim and I want to ask about more of them.

But I’m curious what each of you saw as most surprising to you. After you did this work and had the paper—or at least the research—done, what did you walk away from this work thinking, “Wow, I wasn’t actually expecting that”? I’ll start with Alex.

Speaker 3

I think it keeps amazing me how much progress you can make with these sorts of systems. When we started with FunSearch a few years ago, you would go to a chatbot interface somewhere and ask it to solve an open problem, and it would basically give you nothing.

Even today, you can try the same thing, and it will probably make much more sense to think for a few minutes and give you a lot of reasonable approaches.

But generally, it's not the experience of people that you ask a chatbot to solve an open problem and it will just do that, right? And then it's kind of amazing that, by using the same tools—the same LLMs in these iterative evolution loops—you can get so much more out of them. Yeah, I think every time we solve something new, it's really kind of exciting and surprising in a sense.

Speaker 2

And what most surprised you?

Speaker 1

I think what is really new to me is the generality of the approach. I don't just mean generality across scientific open problems. It's not my experience from my admittedly short research career that you build some tool for scientific purposes and then, out of the box, you can apply it to real-world challenges and have so much impact.

Usually, there's an entire body of research work that needs to happen to translate a scientific technology into something that's actually useful in the real world. Usually, there are so many challenges you have to tackle. Here, there is a tool which, out of the box, is able at the same time to make new discoveries on mathematical and scientific problems and to discover algorithms that you can directly deploy into Google's critical compute stack. That's something I certainly hadn't experienced before and maybe wasn't expecting, to be honest.

Tim Scarfe

Yeah. I don't know if you're familiar with the ARC Challenge and a guy called Ryan Greenblatt. He did this famous approach where he just sampled a language model 30,000 times to generate programs. We're in this really interesting space, as you spoke about in the paper, where we have an evaluator, which means we can sidestep hallucinations, right?

Isn't it fascinating that these nuggets of gold are in there in the search space? Of course, most of us just use language models in a single shot, doing greedy sampling. Now we can do these very sophisticated search routines.

But to get to that—well, actually, maybe a quick sub-question is: what you've done is mix so many interesting paradigms together. We're talking about meta-learning, evolution, diversity preservation, program learning, library learning, and whatnot. If you could explain simply, how is that different from just sampling a language model? Let's say you could sample a language model 1 billion times. Is AlphaEvolve in a different category from that?

Speaker 1

Yeah, for sure. Maybe just one personal observation on what you just said: that is indeed the right way of thinking about it. If you just keep asking a language model the same question repeatedly in a chat window, you'll get a completely wrong idea about its capabilities if you actually scale things up.

When we started working on this type of evolutionary approach, initially we were pretty skeptical about what it was going to be able to do. We were just trying it in a chat window and asking it to write some simple algorithms, and it wasn't doing that well initially. The magic really happens when you scale things up.

But there are different ways in which you can scale things up. One is that you just keep asking repeatedly the same question. Sure, there will be some nuggets, but they'll be nuggets. They will not be the full solution. So it is really important that you find those good nuggets and then iteratively build on top of them in subsequent iterations, and that's what you get through these evolutionary algorithms.

Just to speak very quantitatively, we do have a comparison in the ablations in the paper where we try to get rid of evolution. As you might expect, that works much, much worse.

Speaker 3

I think maybe a good test case for building intuitions about that is the cap set example from the original FunSearch paper. There, we used a very simple and small language model, and we didn't even provide context about the problem because we wouldn't expect the language model to actually think through the problem and solve it by thinking hard or being very smart about it.

What we were hoping to get from the language model was just trying a few things—a lot of things, right? But the problem is that the final solution is not that long. It's maybe 50 lines of Python, but it's very, very unlikely that you'll stumble upon it by accident if you don't even know the problem. You're just trying Python things, so how would you generate the particular kind of 50-line Python program that works?

So there, it was completely essential to hill climb. You have to improve gradually, see what works, and try to modify it a little bit in the neighborhood.

Speaker 2

Yeah. Can you talk a little bit more about hill climbing? You've found clever ways to build hill climbing into problems that, at least on their face, seem so discrete that hill climbing would not be possible. I'm curious if you could expand a bit on the general idea behind how one takes a discrete problem, like looking at different programs, which are fragile and digital, and somehow incorporates hill climbing into that process.

Speaker 3

Yeah. I guess for many problems, you do have a natural kind of hill-climbing reward. For example, when we do this gradient-based method for finding matrix multiplication algorithms, the natural reward would be the loss, right? How close you are to the solution.

Unfortunately, that doesn't necessarily work very well. What we've found again and again is that you have to be somewhat creative about what kind of auxiliary rewards or auxiliary signals you can come up with. In particular, for the matrix multiplication case, what was very useful for us was realizing that if you have a curriculum of matrix sizes, then it's probably going to be somewhat easier to solve the small ones, even with simple gradient-based methods.

Then you can hill climb on this probability of solving. Let's say you run your thing 10 times, and then how many times do you actually get the thing you're looking for? That can be your signal.

Speaker 2

Mm-hmm.

Speaker 3

Because you have a curriculum, you can say, “Okay, first I want to solve 2 by 2. Then, once I'm solid on that, I want to continue evolving by trying to solve 3 by 3.” That was really helpful in that particular case.

In general, you just try things and build intuitions about how to approach coming up with these auxiliary rewards. It's very problem-specific.

Speaker 1

Maybe just to add one orthogonal point: often you're trying to solve one particular problem, and then maybe it comes with an associated reward or maybe it doesn't. Nevertheless, it's useful to also optimize other things simultaneously.

Let's say you want to find a matrix multiplication algorithm of a particular size. You also want to find algorithms for other sizes, because if you do that, it allows you to explore the space of algorithms in a broader way. Often, you can translate ideas that you develop for one matrix size later on to the matrix size that you actually care about.

But if you only optimize for the size you care about from the start, maybe that idea wouldn't have been useful initially. You first had to develop it and refine it a bit further for a related problem. The overall point I'm trying to make is that it often makes sense to introduce similar, related tasks and try to improve on them, even if you don't intrinsically care about them.

Tim Scarfe

Could we touch on the benefits of program synthesis in general? We interviewed Kevin Ellis recently. He's the guy who invented DreamCoder. Fascinating guy. He used to work under Josh Tenenbaum.

The way he described it, coming from a cognitive science point of view, is that a lot of program induction is about explanation, intelligibility, and legibility. There was this incredible example when you were talking about scheduling jobs in Google's data center, and you've got this kind of matching problem and whatnot.

I think you said there were some previous experiments where you'd used an inscrutable reinforcement learning model or something like that, and it wasn't debuggable or intelligible. Now you've got these beautiful 3 lines. But even then, there's the question of whether it's legible.

Remember move 37 in AlphaGo? That was a famous example of a discovery that was a little bit weird. Perhaps we wouldn't have discovered it, but maybe we understood it, and maybe we could build a theory around it.

When you look at some of these discoveries as well, are you finding deep abstract principles that you can derive from those discoveries? Talk me through all of that.

Speaker 1

Yeah.

Google AlphaEvolve

You can span the broad spectrum, actually. With AlphaEvolve, you sometimes discover algorithms that are really simple—so simple that a human can verify they’re actually going to be correct on all inputs. Indeed, as you alluded to, they’re so simple that you’re just happy to submit them to production almost immediately, with no further checks needed. It’s in a completely different league compared to trying to deploy a neural network, where you have to think about retraining it, hosting it, the resources required to run inference, and all those kinds of things. So indeed, you can be in this very simple regime.

For scientific discovery, you can also be in the regime where you explicitly look for programs that are interpretable. You can do this by setting up the skeleton that you ask AlphaEvolve to fill in in such a way that, by design, you expect it to be fairly simple. The clearest example is perhaps already in the FunSearch paper, where we looked for these big cap sets, a specific mathematical object, and it found a function that we could inspect. We noticed that the function was using the number 4 in an interesting way: whenever you look at the index in the for loop, you look at the index modulo 4.

When you index into the array, you’re indexing at positions i, i + 4, and i + 8. Just by inspecting the code, we were able to develop what you might think of as a mathematical insight or hypothesis, and that hypothesis turned out to be crucial for improving the results. We took that insight from the code, incorporated it into the next run, and got much better results. So indeed, this can happen.

In some applications, maybe you don’t care as much about interpretability. In that case, AlphaEvolve can develop very complex algorithms, or a sequence of algorithms, where you perhaps won’t have a holistic understanding of exactly how this complex search heuristic works. What you care about is the final result—that the final result is as good as possible. So you can span this whole spectrum. Maybe Alex would also mention the work that isn’t from our group, but where another team applied FunSearch to cognitive science to discover interpretable programs of behavior. That’s actually a pretty cool application.

Speaker 3

Yeah. If you go back to the matrix multiplication example, we built this gradient-based machine learning pipeline for looking for those algorithms. If you look at the code changes proposed by AlphaEvolve, you would see maybe 2 types of changes, or 2 types of reactions to the changes. One is, “Yeah, that makes sense,” right? That’s usually the case with machine learning: when you read machine learning papers, you’re like, “Oh, yeah, this makes sense. That’s a good idea. I would maybe have done it myself.”

Usually, the problem isn’t coming up with the ideas. Ideas are sort of cheap. The problem is coming up with an idea that actually works. There are so many things that make sense, and then only 5 of them actually work. It gives you ideas that you understand and can relate to, but it’s hard to know a priori which of those will actually work.

The other type of idea, or code change, is something you probably wouldn’t even have tried because it’s so complicated. Sometimes that’s for a good reason, and sometimes it’s for a bad reason. For example, in the matrix multiplication case, we have this quantization loss because we want the solutions to be integers, or maybe fractionals, but specified in a range such that we can verify exactly, using exact arithmetic, that they’re correct. We have this quantization loss, which drives the solution toward that set of integers, for example.

Normally, as humans, we would only try tuning the weight of that quantization term, or maybe, in the worst case, the schedule of the weight. Maybe you would have less of it in the beginning and more of it toward the end. What AlphaEvolve did was produce a whole kind of time-evolving shape for the quantization loss. That makes sense, right? You wouldn’t say that it’s not going to work, but you also wouldn’t look at it and say, “This is amazing. This is definitely going to work.” You wouldn’t even try it as a human because it’s so complicated that you would never think about tuning such a complicated function that changes shape over time with iterations.

Tim Scarfe

That’s pretty fascinating. It’s kind of like how human players are able to glean new insights from chess, from AlphaZero and whatnot. Alex, you also mentioned how surprised you were at the general, or broad, application of the technique. I know you have some prior work in robotics, so I’m curious about cases where it’s more difficult to assess the code.

8. Beyond Automatic Evaluation

For robots, you might be able to do some training in virtual reality or something, but at some point you have to throw it out in the woods and see whether it’s able to navigate to the other side or something like that. How do you see bridging the gap between easily automated validation and more complex real-world scenarios, while still being able to apply AlphaEvolve?

Speaker 3

Yeah. One direction that might make sense—and I’ve seen people doing this—is trying to convert fuzzy reward functions into code. For example, maybe you have a reward function defined by the image of the final state you want to achieve, or perhaps you want a reward function defined by a natural-language description of what you want to do. The task is to convert that into a Python function that actually scores it.

Maybe it’s not that hard to have a binary reward for the reinforcement learning system to train the robot, because you can ask a vision-language model to verify it. But it’s very hard to train against binary rewards. I’ve seen people trying to use systems like AlphaEvolve to find a piece of Python code that would provide an auxiliary reward—a shaping reward, basically—to drive you toward that binary reward and make the learning faster. I think that makes a lot of sense as a direction. I don’t know if that answers your question.

Tim Scarfe

Yeah, it does. But I’m also thinking in terms of the efficiency of the procedure. You mentioned in the paper that many of the programs it generates fail immediately: they crash or they’re not valid programs. Those are relatively easy to filter out if you have an evaluator.

At the opposite extreme, even once you have those programs running, a real-world test case might involve performing experiments and clinical trials, or a robot trying to navigate a complex field that may end up with it getting damaged or something like that. There’s this huge gap between automatic verification and expensive real-world evaluation. How can we bridge that in some sensible way for systems like AlphaEvolve? I’m just curious if you have any thoughts on that.

Speaker 3

Yeah. We are thinking about those things. One thing that Matej alluded to before was finding proofs, which involves binary rewards, and then asking language models for feedback to get some sort of shaping reward to drive you toward the solution. I think that’s a direction we’re also thinking about.

In many cases, you do have this kind of ladder of increasingly expensive evaluation. For example, if you want to do some sort of simulation-based evaluation—maybe for robotics, biology, physics, or whatever—you can use a simulation-based reward, and ultimately you want to try it in the real world. Maybe that means trying it on the robot, or going to the lab, or whatever.

For every stage of this evaluation ladder, which gets more and more expensive, you want to do more than simply try everything that worked at the previous stage. You want to have some sort of prioritization mechanism, which could be a language model, something else, or an Elo score. Those are the things we’re thinking about.

One project that recently came out of Google and is very good at this is Co-Scientists. They essentially attack the same problem: how do you score ideas that are very hard to evaluate and may not have hard feedback? I think they’re doing a really good job at that.

Tim Scarfe

Makes sense.

Speaker 1

Maybe just one thing to add is that, technologically, I think AlphaEvolve is already well set up for this. We have this idea of evaluation cascades, where you evaluate a large number of programs very quickly, and then a smaller number of programs for longer. So you can expand this cascade all the way to the regime where maybe you can only afford to evaluate 10 things, and you actually have to go into the real world and run some real-world experiments.

Speaker 3

Mm-hmm.

Speaker 1

In principle, the mechanism is there. This is what you have to do even if you try to solve the problems manually or do what actual researchers do. You have a finite budget, so first you try to filter the ideas using cheaper methods, and then you only have the budget to try the most promising ideas on the most expensive evaluation.

Speaker 2

Sure.

Speaker 1

We can mimic that.

Speaker 2

Yeah.

Speaker 1

Yeah, exactly.

Speaker 2

Yeah, the same way those are done.

Tim Scarfe

So, I’m curious about LLMs. First of all, let me give you my heartfelt congratulations on Gemini Pro. It is ridiculous. It’s so good. Honestly, it’s just absolutely—I have no words to describe how good it is.

But we’re in an interesting time, right? In AlphaEvolve, you had an ensemble of Gemini 2.0 Flash, I think, and Gemini 2.0 Pro, and it raises so many questions for me. What would happen if you did it with 2.5? Presumably, internally, you have even better models that we don’t know about yet. How much uplift is there?

If you think about it, there’s this Pareto curve of models, and Google’s models are on the Pareto curve. We’re trading off cost, latency, performance, and whatnot. If you were just using one model, there might be some optimal place on that Pareto curve in AlphaEvolve. Maybe we should have a small model but sample it loads of times, or maybe we should have a big, powerful model but not sample it as many times. With an ensemble, maybe there’s some perfect distribution of those models.

We seem to have unlocked something, especially with the reasoning versions of the models, which maybe wasn’t there until relatively recently. Could you talk about that?

Speaker 1

One thing I can say specifically that is particularly exciting to me about AlphaEvolve is that it does get this uplift from improving the base language model. This was not necessarily the case in FunSearch, but in AlphaEvolve we do see this. We actually have a quantitative confirmation in the ablations that if you also include Gemini 2.0 Pro in the ensemble, then you get better results compared to just using the Flash model.

It’s very clear that we are leveraging the frontier capabilities of these models. Of course, we cannot guarantee what will happen in the future, but at least for now, we are definitely riding the wave. We’re very keen to see how the base models improve and what kind of uplift the method is going to get with this.

The other related point I would quickly mention is that AlphaEvolve also offers an opportunity that we haven’t taken yet, but looking forward, it’s a system that is able to enhance the capability of the base model. The capability of the base model is somewhere, but then this system makes it even better through orchestrating this test-time compute pipeline—actually so much better that you can make a new scientific discovery.

So it raises the natural question: Can we somehow distill this improved capability back into the base model? That’s something you would get if you were to close the reinforcement-learning loop. It’s not something we have done with AlphaEvolve, but that possibility is clearly on the table.

Speaker 2

You just mentioned improving the base model, and you also mentioned in the paper using AlphaEvolve to improve the infrastructure of AlphaEvolve and the base model itself. So you’ve finally managed to close the recursive self-improvement loop. I don’t know, that’s going to trigger some folks. Any thoughts on that?

Tim Scarfe

What would Schmidhuber say?

Speaker 1

At this point, we want to be very specific about what we have done. We have found a way to speed up the training of the next version of Gemini by 1%, and we have been able to unstrand resources in the bold data center.

Currently, if you think about the feedback loop, it’s maybe on the order of months. When you speed up the training of the next version of Gemini, it will take some time to actually arrive. But indeed, we do see the steps in the direction that you describe.

Speaker 2

Alex, any thoughts on the recursive self-improvement of AlphaEvolve?

Speaker 3

I don’t think I have anything to add. As Mate said, it’s interesting to see how it pans out, and we are seeing some signs of helping the Gemini training run. So, yeah, that’s exciting.

Tim Scarfe

On that thread, though, we want to have more autonomy. Right now, this is very much a didactic exchange between the human supervisor and the system. We select the problems, design the evaluation functions, seed the solutions, and so on.

I wonder what the next step of autonomy would look like. Maybe we could actually have the thing imagine what its own evaluation function is, and maybe it could go several steps further. What would that look like?

Speaker 3

To be honest, from my perspective, automating some things is cool and exciting, but at the same time, I would even lean toward less automation. I like that what makes AlphaEvolve so cool and powerful is this back-and-forth between humans and machines.

Humans ask questions, the system gives you some form of the answer, and then you improve your intuition and your question-asking ability. Then you ask more questions. We’re thinking a lot about providing access to AlphaEvolve to academics as trusted testers, to see what they can do with it.

While trying to build that and build the UI, we’re thinking a lot about not just implementing the thing we have as a website, but about what the next level of human-AI interaction would be. What can the humans do in the process? Maybe they want to supervise the process, comment on ideas, inject more ideas, and things like that.

We’re exploring that a lot, and I think it’s very exciting to see what can be done in this kind of symbiosis space.

Tim Scarfe

So, final question. You said in the paper that—I think you mentioned—on the order of 100 compute hours to evaluate a new solution. That was in Section 2.3. But just before everyone at home rushes to reimplement AlphaEvolve, could you give us some examples, maybe on the matrix multiplication problem?

How many compute hours did it run for? How much is it realistically costing to do this?

Speaker 1

One nice feature of AlphaEvolve is that it’s really elastic, so it can match the difficulty of your problem. If you ask it to solve a problem that’s not actually that difficult—maybe it’s still an open problem, but no one has really worked on it—then maybe even if you ask a chatbot, it would almost solve it or solve it.

In that case, AlphaEvolve will also give you the answer basically immediately, and it won’t cost a lot at all. But if you ask for a very difficult problem, maybe a decades-long open scientific problem, then you do expect that it’s difficult. You’ll need to spend more time playing with different ideas and iteratively building on top of them.

The nice feature of AlphaEvolve is that it’s able to sustain the scaling. As you keep running it for longer, it finds better and better ideas. I know it maybe sounds trivial, but I don’t think it’s actually easy to build systems that are able to sustain this continual improvement without plateauing at some point.

With AlphaEvolve, you see this elasticity stretching all the way to making new scientific discoveries. I think that’s a nice feature of the system.

To answer your question concretely, it depends on the difficulty of the problem. If the problem is difficult, then you expect that you’ll need to investigate more ideas and spend more compute. If it’s easier, then you can have the answer very quickly.

If you think about the problems that we actually presented in the paper, even within matrix multiplication, some matrix sizes are much easier than others, so the compute would be vastly different. The same goes for the open problems in math: some of them are fairly easy, and some of them are very difficult.

There is no single answer that would position you on this spectrum without knowing the problem.

Google AlphaEvolve

Unfortunately, as is often the case with open problems, you don't actually know a priori how difficult they are. So you can't even predict ahead of time and, sometimes, you try and don't find anything better. That can also happen.

Tim Scarfe

Awesome. Well, guys, it's been such an honor having you both on MLST. Thank you so much for joining us today.

Speaker 2

Yeah.

Tim Scarfe

Thank you.

Speaker 3

Thank you for inviting us.

Speaker 1

Thank you for having us.

Speaker 3

Yeah. This is awesome.

Google AlphaEvolve - Discovering new science (exclusive interview) | BidClub