项目算法发现

OpenEvolve: Open-source implementation of AlphaEvolve

OpenEvolve:AlphaEvolve 的开源社区复现

Asankhaya Sharma (codelion) 及社区贡献者 · codelion(社区) · GitHub · 2025-05

一句话codelion(Asankhaya Sharma)对 DeepMind AlphaEvolve 的开源复现:LLM 驱动的进化式代码优化框架,在 n=26 圆填充上复现了 AlphaEvolve 结果的 99.97%(2.634292 vs 2.635);7289 stars、Apache-2.0、持续活跃,是目前上手门槛最低的算法自动发现框架——但首页宣传的 GPU kernel '2.8x 加速'被其自家示例文档否定(修正评测 bug 后实际比 baseline 慢 3.2%)。

这是什么

2025 年 5 月 DeepMind 发布 AlphaEvolve——用 LLM 做变异算子、进化算法做搜索框架的算法发现系统,声称改进了矩阵乘法算法和多个数学开放问题的下界,但没有开源。OpenEvolve 是发布仅数天后就出现的社区复现(2025-05-15 建仓),作者 Asankhaya Sharma 也是 OptiLLM 的作者,仓库后来从 codelion/openevolve 迁移到 algorithmicsuperintelligence/openevolve。

它本质上是一个通用的 evolutionary coding agent 框架:你提供一个初始程序、一个返回分数的 evaluator 和一份 YAML 配置,框架就用 LLM 反复改写代码、评测、把好的版本存入种群继续进化。支持任何 OpenAI 兼容 API(包括本地 Ollama/vLLM,以及直接用 Claude Code CLI 当后端),支持 Python/Rust/R/Metal 等多语言,pip install openevolve 即可用,也提供 run_evolution / evolve_function 的库接口。

对课题组的意义在于:AlphaEvolve 本体不可用,而 OpenEvolve 把'LLM + 进化搜索发现算法'这条路线变成了一个可以直接跑实验的开源基础设施,示例覆盖圆填充、GPU kernel、符号回归(LLM-SRBench)、prompt 优化等。

OpenEvolve 架构:Controller 居中调度四个组件构成异步进化循环——Program Database 存程序和指标并向 Prompt Sampler 提供历史程序,Prompt Sampler 拼出富上下文 prompt,LLM Ensemble 生成代码修改,Evaluator Pool 评测打分回写数据库。

机制与做法

核心循环:MAP-Elites + LLM 变异

架构上是五个组件构成的异步流水线:Controller 调度,Program Database 存程序和指标,Prompt Sampler 从库里抽'过去的程序'拼出富上下文 prompt,LLM Ensemble 生成代码修改,Evaluator Pool 打分回写。种群管理用 MAP-Elites 做 quality-diversity:按 complexity、diversity、performance 等特征维度分格子,每个格子只留精英,避免种群坍缩到单一解;再加 island model(默认多个岛、环形拓扑定期迁移)防止过早收敛。

Prompt 构造是关键设计:每次变异同时喂给 LLM 若干 top 程序(exploitation)和若干多样性程序(inspiration),即所谓 double selection——用于比较性能的程序和用于激发灵感的程序分开采样。还支持 template stochasticity(随机化 prompt 模板)增加变异多样性。

n=26 圆填充第 460 代的最终解,sum of radii = 2.634292,达到 AlphaEvolve 报告值 2.635 的 99.97%。从随机摆放进化到这个结果共约 470 代、两阶段配置。

Artifact side-channel:错误反馈回流

evaluator 除了返回 metrics,还可以返回 artifacts(stderr、profiling 数据、build warning、LLM 对代码质量的点评),这些会被自动拼进下一代的 prompt,形成'上一代哪里报错→这一代避开'的反馈闭环。配合 cascade evaluation(多级评测,先跑廉价测试过滤明显烂的程序)控制成本。

可复现性做得比较认真:LLM 采样、数据库、评测全部受统一 seed 控制(默认 42),声称跨机器可精确复现同一条进化轨迹。成本方面 README 给的参考:Gemini-2.5-Flash 约 $0.01-0.05/iteration,o3 约 $0.15-0.60/iteration,一次像样的实验通常几百到上千 iteration。

实际用法上的经验

README 用很大篇幅强调 system message 是进化成败的最大变量:好的做法是迭代式打磨——先跑 20-50 轮观察 LLM 在哪里卡住,再往 system message 里加领域知识、明确'不许改什么/可以改什么'的边界,甚至可以用 OpenEvolve 反过来进化自己的 prompt(meta-evolution,HotpotQA 示例声称 +23% 准确率)。

自带交互式可视化(scripts/visualizer.py):进化树、代际性能曲线、代码 diff、MAP-Elites 网格覆盖,对分析'进化到底在干什么'很有用。

关键结果

圆填充 n=26:两阶段进化(先探索 100 轮 + 后加大多样性 100 轮配置,共约 470 代)从简单同心圆构造进化出 SLSQP 数值优化方案,sum of radii = 2.634292,达到 AlphaEvolve 报告值 2.635 的 99.97%
GPU kernel(MLX/Metal, Qwen3-0.6B GQA attention):修正评测有效性 bug 后跑 25 轮,最好的进化 kernel 比 MLX baseline 慢 3.2%(从初始 -11.5% 改善到 -3.2%,始终没超过 baseline),且 32% 的 bf16 编译失败率
函数最小化示例:从随机搜索进化出带自适应降温的模拟退火;prompt 进化示例在 HotpotQA 上声称 +23% 准确率
工程规模:7289 stars,2025-05 建仓,2026-07 仍在活跃提交;Apache-2.0;PyPI 可装;支持任意 OpenAI 兼容 API、本地模型和 Claude Code CLI 后端
全组件统一 seed(默认 42),声称跨机器精确复现进化轨迹

实证核查

有水分框架本身是真实、活跃、可用的,圆填充确实复现到 AlphaEvolve 的 99.97%;但首页营销文案明显超前于事实——'2-3x GPU 加速'被自家示例文档直接否定,'state-of-the-art'实为'接近复现',issue 里也躺着几个影响核心机制的 bug。当框架用没问题,引用其战绩需逐条核对。

README 首页:'Proven Results: 2-3x speedups on real hardware',GPU kernel 示例展示 '2.8x faster on Apple M1 Pro'

examples/mlx_metal_kernel_opt/README.md 自己写明:此前的评测结果无效(进化出的 kernel 根本没在 benchmark 子进程里生效、correctness 测试 dtype 不对、GQA head 比例配错成 40:8 而实际是 16:8);修正后跑 25 轮,'The best evolved kernel is 3.2% SLOWER than MLX's baseline',且 bf16 编译失败率 32%。首页的 2.8x 数字来自被作废的旧评测,但至今没从主 README 撤下

README:'State-of-the-art circle packing (n=26)'

示例自己的 README 写的是 sum=2.634292,为 AlphaEvolve 报告值 2.635 的 99.97%('matching to within 0.04%')——是高质量复现而非超越,称 SOTA 不准确。复现本身可信:代码、配置、470 代的 checkpoint 可视化都在 examples/circle_packing/ 下公开

核心机制:MAP-Elites quality-diversity + novelty 过滤 + island migration

issue tracker 显示这些机制有过/仍有实现 bug:#454 MAP-Elites 格子精英在种群淘汰时不受保护(已修,属回归 bug);#483 novelty judge 因 prompt 要求输出 NOT_NOVEL 而 parser 匹配 'NOT NOVEL',导致永远不会拒绝任何程序(open);#471/#456 island 采样不一致(部分已修)。维护是积极的(大量 issue 快速修复、2026-07 仍在推进),但用旧版本跑实验需注意这些机制可能没按文档描述工作

'Fully deterministic / 完美复现'

seed 机制在代码里确实全组件覆盖(LLM 采样参数、database、evaluator),但前提是 LLM API 本身确定性——商业 API 即使 temperature=0 也不保证跨时间一致,所以'跨机器精确复现'只在本地模型或缓存命中时严格成立;这点 README 未提醒

与我们方向的关系

对 ai4ai/算法发现方向,这是当前最合适的起步框架:AlphaEvolve 闭源、FunSearch 官方代码是精简演示版,而 OpenEvolve 提供了完整的 MAP-Elites + islands + artifact 反馈的工程实现,pip 装上配好 evaluator 就能在自己的问题上跑。evaluator 接口(返回 metrics + artifacts 的字典)设计得足够通用,适合把组里的优化问题(kernel、调度、数值方法等)包一层直接接入。

MLX kernel 示例的失败经验反而最有借鉴价值:它暴露了这类系统最常见的坑——评测通道有 bug 时,进化会'优化'出虚假的提升(旧版声称 2.8x,实际 kernel 根本没被用上)。做这个方向的实验必须先做 evaluator 的有效性验证(该示例修正后加的 subprocess hook、correctness gate、早退机制都值得抄)。另外其分析指出的局限——LLM 上下文利用不足(每轮只喂 1 个 parent + 5 个样本)、缺 profiling 引导——正是可以做研究改进的切入点。

阅读笔记

仓库已从 codelion/openevolve 迁移到 algorithmicsuperintelligence/openevolve(旧地址 301 跳转,raw 文件要用新 org 路径才能下载)。用 Gemini 也走 OPENAI_API_KEY 环境变量,容易踩坑。issue #481 提到 evaluator 在进程内 exec 被评测代码、visualizer 无鉴权——跑不可信代码或对外暴露端口时注意。