AlphaEvolve: A Coding Agent for Scientific and Algorithmic Discovery

一句话总结

这篇论文主要讨论如何用大模型生成代码变体，再通过自动评估和进化搜索，发现更优的算法实现。

更准确一点说，AlphaEvolve 不是让 LLM 一次性“想出答案”，而是把算法发现变成一个可以不断试错的闭环：LLM 负责提出代码变体，评估器负责运行和打分，进化循环负责保留更好的候选程序，并继续推动下一轮搜索。

我的理解是：

LLM 负责产生可能性
Evaluator 负责提供现实反馈
Evolution Loop 负责长期积累

这也是它和普通 coding agent 最大的区别。

核心方法

AlphaEvolve 的核心流程如顶部图所示。

流程包括三个核心步骤：

1. LLM Generate — 用大模型生成代码变体
2. Evaluate — 自动评估每个变体的质量
3. Evolve Loop — 选择优秀变体进入下一轮进化

如果用更工程化的话说，它其实是在做一件事：

已有程序
  → LLM 修改代码
  → 自动运行和评分
  → 保存结果
  → 选择更好的程序
  → 继续让 LLM 基于这些结果改进

它的关键不是某一次生成有多聪明，而是把 LLM 放进了一个可执行、可验证、可积累的搜索系统里。

系统/模型结构

AlphaEvolve 可以粗略拆成五个部分。

1. 问题定义与初始程序

用户需要先给出问题、初始代码，以及可以自动判断结果好坏的评估方式。

这说明 AlphaEvolve 不是凭空发明科学结论。它更像是在人类设定好的搜索空间里，自动寻找更优程序。

一个问题要适合 AlphaEvolve，通常需要满足几个条件：

• 可以写成代码；
• 可以自动运行；
• 可以自动验证正确性；
• 可以用某种指标打分；
• 可以允许程序被不断修改和比较。

2. Prompt Sampler

系统会从历史程序、分数、评估结果和任务描述中抽取信息，组装成新的 prompt。

这个模块的作用是让 LLM 不只是盲目生成代码，而是基于过去的成功和失败继续探索。

3. LLM Ensemble

AlphaEvolve 使用多个 Gemini 模型协同工作。

我的理解是：

• Gemini Flash：便宜、快，适合扩大搜索宽度；
• Gemini Pro：能力更强，适合做更深入的代码修改和推理。

这个设计很有启发：强模型不必负责所有事情。快模型负责多试，强模型负责深挖，评估器负责裁判。

4. Evaluator

Evaluator 是整个系统的地基。

它负责：

• 运行候选程序；
• 检查结果是否正确；
• 计算性能或质量指标；
• 给候选程序打分；
• 过滤错误、无效或退化的结果。

没有 evaluator，AlphaEvolve 就只是普通 LLM 代码生成。 有了 evaluator，LLM 的输出才真正进入了自动搜索闭环。

5. Programs Database

系统会保存所有候选程序、评估结果和历史变体。

这个数据库不是普通日志，而是进化搜索的“种群池”。下一轮 prompt 会参考这些历史结果，系统也会从中选择更有潜力的程序继续进化。

关键机制

1. 用代码表达候选解

AlphaEvolve 的一个核心洞察是：很多数学、算法和系统优化问题，都可以被表达成程序。

一旦问题能写成程序，就可以：

• 自动运行；
• 自动验证；
• 自动比较；
• 自动迭代。

这让“算法发现”从纯文本推理，变成了代码空间里的搜索问题。

2. 用评估器约束 LLM

LLM 很容易生成看起来合理但实际错误的答案。AlphaEvolve 没有让模型自己判断自己对不对，而是把候选代码交给外部 evaluator 验证。

这个机制非常重要：

模型可以胡思乱想
但结果必须接受现实测试

所以，AlphaEvolve 的智能不只来自 LLM，也来自评价系统。

3. 用进化搜索弥补单次生成的不稳定

普通 LLM 生成代码，常常是“一次成败”。 AlphaEvolve 不要求每一次生成都正确，它只需要不断生成候选程序，然后从大量变体中筛出少数更好的结果。

这更接近搜索，而不是问答。

它的优势在于：

• 可以大规模试错；
• 可以保留局部改进；
• 可以从历史结果中继续迭代；
• 可以把很多小改进慢慢累积成大改进。

4. 人类仍然负责定义问题

AlphaEvolve 没有替代人类专家。

人类仍然需要负责：

• 什么问题值得搜索；
• 哪些代码区域允许修改；
• 什么结果算正确；
• 什么指标值得优化；
• 搜索出来的结果是否真的有科学意义。

所以它不是“自动科学家”，更像是“专家驱动的自动化发现引擎”。

实验设计

论文和官方介绍主要从两类任务验证 AlphaEvolve。

1. 工程基础设施优化

AlphaEvolve 被用于 Google 内部的一些真实工程问题，包括：

• 数据中心调度；
• TPU 硬件电路设计；
• Gemini 训练过程中的矩阵乘法 kernel；
• Transformer 模型中的 FlashAttention kernel 优化。

这类任务的特点是目标比较明确，评估方式也比较稳定，例如资源利用率、运行时间、硬件功能等价性、训练时间变化等。

2. 数学与算法发现

AlphaEvolve 也被用于数学和计算机科学问题，例如：

• 矩阵乘法算法；
• 几何构造问题；
• kissing number 问题；
• 组合数学、数论、数学分析等开放问题。

这类任务更接近“科学发现”，但前提仍然是结果需要能被程序验证，或者能被进一步形式化证明。

主要结果

1. 数据中心调度

AlphaEvolve 找到了一个用于 Google Borg 数据中心调度的启发式规则，使 Google 全球计算资源平均持续回收约 0.7%。

这个数字看起来不大，但放在 Google 的基础设施规模下，0.7% 的持续算力回收已经是非常大的工程收益。

2. 硬件电路优化

AlphaEvolve 提出了一个 Verilog 重写方案，去掉了矩阵乘法相关算术电路中的冗余部分，并通过功能正确性验证，进入后续 TPU 设计流程。

这说明它不仅能写 Python 算法，也能在硬件描述语言层面做搜索。

3. AI 训练与推理优化

AlphaEvolve 优化了 Gemini 架构中的一个矩阵乘法 kernel，使该 kernel 加速约 23%，并带来约 1% 的 Gemini 训练时间下降。

它还在 FlashAttention kernel 的底层 GPU 指令优化上取得了最高约 32.5% 的速度提升。

这点很有意思：AlphaEvolve 不只是优化外部问题，它还可以优化支撑大模型自身运行的基础设施。

4. 矩阵乘法算法发现

AlphaEvolve 找到了一个用于 4×4 复数矩阵乘法 的算法，只需要 48 次标量乘法。

这个结果很重要，因为它改进了该设定下长期以来的已知最好结果，不只是普通工程调参。

5. 开放数学问题

在 50 多个数学开放问题中，AlphaEvolve 大约在 75% 的问题上重新发现了已知最佳结果，并在约 20% 的问题上改进了此前最好结果。

例如，在 11 维 kissing number 问题上，它找到了包含 593 个外球的构造，推进了已知下界。

贡献

1. 把 LLM 代码生成变成可验证搜索

AlphaEvolve 的重要贡献不是证明“LLM 会写代码”，而是证明 LLM 可以作为搜索系统中的变异生成器。

它把一次性代码生成，改造成了：

生成
→ 验证
→ 选择
→ 继续生成

这比单轮 prompt 更接近真实科研和工程优化。

2. 强调 evaluator 的核心地位

这篇工作给我的一个最大启发是：未来很多 AI scientific discovery 系统，核心可能不是模型本身，而是 evaluator。

谁能把问题变成可验证、可打分、可自动运行的形式，谁就能把 LLM 的生成能力转化成搜索能力。

3. 提供了 Flash + Pro 的模型分工范式

AlphaEvolve 的模型使用方式很实用：

快模型负责探索宽度
强模型负责复杂修改
评估器负责裁判
搜索系统负责积累

这对后续 coding agent 系统设计也有启发。不是所有步骤都要用最强模型，模型可以按任务角色拆开使用。

4. 打通算法发现和工程优化

它同时覆盖数学问题和 Google 内部基础设施优化。

这说明“算法发现”不是只能停留在论文玩具任务里，也可以进入数据中心、芯片设计、训练 kernel、推理性能优化这些真实工程场景。

局限性

1. 强依赖自动评估器

AlphaEvolve 最适合那些可以自动运行、自动验证、自动打分的问题。

如果一个问题很难写 evaluator，它就很难发挥作用。

例如：

• 用户体验是否更好；
• 代码架构是否更可维护；
• 安全策略是否真的稳健；
• 研究结论是否有因果意义；
• 一个系统设计是否长期合理。

这些问题不容易只靠自动分数判断。

2. 可能过拟合 evaluator

只要系统在优化一个分数，就可能出现钻评价器空子的情况。

如果 evaluator 漏掉某些约束，AlphaEvolve 可能找到高分但不可用、不安全或不可维护的解。

这对 AI coding agent 很重要： 能通过测试，不等于真的正确。

3. 复现门槛较高

DeepMind 公开了部分数学结果和验证 notebook，但没有开源完整 AlphaEvolve 系统本体。

所以外部研究者很难完整复现它的搜索策略、模型调用方式、资源消耗和工程细节。

4. 计算成本可能很高

进化搜索需要生成大量候选程序，反复运行 evaluator，并长期保存和筛选结果。

这类方法天然适合有充足算力和自动化基础设施的组织。对个人开发者或小团队来说，更现实的是做一个轻量版：

小模型 / API 模型
  + 本地 benchmark
  + 单一 evaluator
  + 少量候选程序
  + 人工 review

5. 人类仍然要负责问题设定

AlphaEvolve 能搜索，但不能替人类决定什么问题重要。

真正困难的地方仍然包括：

• 如何定义问题；
• 如何缩小搜索空间；
• 如何设计 evaluator；
• 如何解释搜索结果；
• 如何判断结果是否值得部署或发表。