我们如何使用 AlphaEvolve 加速复杂 IDE 算法
TL;DR · AI 摘要
JetBrains 使用 Google DeepMind 的 AlphaEvolve 系统对 IntelliJ IDE 中已深度优化的 B-tree 索引算法进行自动化优化，在合成基准中实现 15–20% 性能提升，并在真实 IDE 集成测试中验证出两个候选方案将端到端索引时间从 17.4 秒降至 16.8 秒以下。
核心要点
- AlphaEvolve 在 50+ 次迭代后，对 B-tree 索引的合成性能评分平均提升 15–20%
- 5 个生成候选中，2 个在 Kotlin Spring Petclinic + IDEA 2026.2 夜间版中实现统计显著加速（<16.8s vs 基线 17
- 实验未替代人工工程流程，而是作为补充搜索方法，聚焦于已多年优化、人工探索成本高的核心基础设施代码
结构提纲
按章节快速跳转。
JetBrains 将 AlphaEvolve 应用于 IntelliJ 索引模块中已高度优化的 B-tree 实现，旨在探索 AI 辅助算法发现能否突破人工优化瓶颈。
B-tree 是索引栈底层核心组件，其代码经过多年手工调优，变更成本高且易引入隐蔽错误，符合 AlphaEvolve 适用场景：有明确评分、可测试、可修改的算法问题。
使用内部合成性能测试套件作为评估器，结合单元测试保障正确性；多数 50+ 迭代会话达成 15–20% 合成性能提升。
在 Kotlin Spring Petclinic 项目与 IDEA 2026.2 夜间版中，5 个候选中有 2 个实现统计显著加速，端到端索引时间稳定低于 16.8 秒（基线 17.4±0.5 秒）。
AlphaEvolve 是对传统工程流程的有效补充而非替代，其价值体现在高成本、低边际收益的算法微调阶段，而非通用开发场景。
思维导图
用一张图看清主题之间的关系。
查看大纲文本（无障碍 / 无 JS 友好）
- AlphaEvolve 优化 IntelliJ B-tree 索引
- 目标系统
- IntelliJ 索引栈底层 B-tree
- 已多年手工优化，变更成本高
- AlphaEvolve 方法
- Gemini 驱动生成候选代码
- 合成性能测试套件评分
- 单元测试保障正确性
- 实验结果
- 合成基准：+15–20%（50+迭代）
- 真实 IDE：2/5 候选显著加速（<16.8s vs 17.4s）
- 工程定位
- 补充而非替代人工流程
- 适用于高成本微调场景
金句 / Highlights
值得收藏与分享的关键句。
多数 50+ 次迭代会话使合成性能评分提升 15–20%，这是关于自主优化闭环最强有力的结论，因该基准本身就是优化目标。
5 个生成候选中，2 个在完整 IDE 集成测试中表现出统计显著改进，端到端结果稳定低于 16.8 秒——相较基线 17.4 ± 0.5 秒明显缩短。
该实验并非取代工程判断、性能分析、代码评审或产品验证，而是测试一种额外的搜索方法，用于在长期优化过的代码中发掘潜在优化点。
AlphaEvolve 利用 Gemini 生成、测试并精炼算法改进——其目的不是回答问题，而是寻找解决复杂算法问题的更快路径。
用 AI 驱动的功能为许多 JetBrains 产品中的工具注入强大动力
我们如何使用 AlphaEvolve 提升复杂 IDE 算法的速度
IDE 人工智能负责人
2026年5月29日
Anant Nawalgaria，Google AI
人工智能产品管理与工程总监
AlphaEvolve 是 Google DeepMind 的一种算法发现系统，它利用 Gemini 生成、测试和优化可能的算法改进。它的任务不是回答问题，而是寻找解决复杂算法问题的更快方法。我们尝试将其应用于 IntelliJ 基础 IDE 的一个狭窄但重要的部分：索引。索引是后台工作，它在项目打开后提供导航、搜索、补全、重构、检查和其他代码洞察功能。
这使得索引速度成为一个简单但难以提升的指标。它依赖于语言、框架、项目的结构、后台 IDE 工作以及索引底层的存储层。小的改动可能会在噪声中消失。有些优化在微基准测试中表现良好，但在完整的 IDE 运行中却不可见。
我们已经在这一领域投入了大量工程资源，这种手动性能优化工作仍在继续。本文描述的实验并不是为了替代工程判断、性能分析、代码审查或产品验证。它是一种额外搜索方法的测试：Google DeepMind 的 AlphaEvolve 是否能帮助我们在已经经过多年优化的代码中找到有用的优化候选方案？
Google DeepMind 在其 AlphaEvolve 预览博客 中将 AlphaEvolve 描述为一种由 Gemini 驱动的编码代理，用于通过结合 LLM 生成的代码与自动化评估器设计算法。在本次实验中，该评估器是我们的性能和正确性测试环境。
目标：索引堆栈中的 B 树
我们选择了 B 树 作为索引实现的基础。起点并非一个简单的原型，而是一个经过深度优化的基础设施，手动探索已经变得昂贵。即使是一个看似合理的改动也需要时间编写、审查和验证，而错误的改动可能会因错误原因而变快。
工程描述是有意简化的：原始算法本质上是一个经典的 B 树，而提出的候选方案大多是针对边缘情况进行了优化的改进版 B 树。这类问题正是 AlphaEvolve 所擅长的。有代码需要修改，有明确的评分标准，还有测试来排除错误的想法。
循环：生成、评分、验证
AlphaEvolve 优化 一个 "Tammes 问题" 的实例。
我们为 AlphaEvolve 提供了一个内部存储层性能测试套件。该套件是合成的，不使用真实的客户项目。它写入和读取合成数据，以便快速且重复地测试候选改动。
评分基于我们在中等规模基准测试中的中位数结果总和。单元测试充当正确性检查。在这种设置下，大多数超过 50 次迭代的 AlphaEvolve 会话都能将合成性能评分提升 15-20%。
这令人鼓舞，但还不够。合成基准测试是有用的，因为它们是可控的。用户不会运行受控基准测试。他们会运行完整的 IDE，同时运行后台进程、语言服务和特定项目的操作。因此，我们将最佳生成候选方案引入集成测试。
在完整的 IDE 测试中，团队使用了 Kotlin Spring Petclinic，并修改了 IntelliJ IDEA 2026.2 的夜间构建版本。报告的端到端索引总时间基线为 17.4 ± 0.5 秒。在生成的五个候选方案中，有两个显示出统计显著的改进，结果可重复低于 16.8 秒。
声明范围
大多数超过 50 次迭代的会话将合成性能评分提升了 15-20%。这是关于自主优化循环的最强声明，因为基准测试是优化目标。
数据的变化
我们的端到端运行表包含两个测量的候选方案。解决方案 1 的平均结果为 16.6 秒，报告为 ±0.2 秒。与 17.4 秒的基线相比，这大约快了 0.8 秒，或在该集成场景中减少了约 4.6% 的时间。
解决方案 2 在故事中也很有用，尽管它没有通过完整的 IDE 测试。它的测量结果为 17.5 ± 0.4 秒，在此场景中基本与基线持平。两个候选方案都改进了快速合成基准测试，但只有这两个中的一个在集成测量中显示出用户可感知的端到端改进。
这种区别很重要。一个只庆祝合成基准胜利的性能工作流程最终可能会产生误导性的声明。一个将自主搜索与完整 IDE 验证相结合的工作流程更有机会找到用户可以感知的变化。
AlphaEvolve 可以改变我们处理复杂性能工作的方法。它将曾经耗时过多而无法探索的优化转变为我们可以常规测试的候选方案。工程师仍然负责基准测试、评审和发布决策。缩小的是搜索空间。
Dmitrii Batkovich，IntelliJ 平台工程总监
我们接下来的测量目标
下一步是产品验证。团队计划检查改进是否会在 Mega Index 指标中体现，这是一个用于跟踪索引性能和用户体验的内部 KPI，特别是用户对索引过程的满意度是否提高。这是正确的衡量标准。更快的内部基准测试是有用的，完整的 IDE 测试更快则更好，但最终重要的是用户体验的提升。
对我们来说，重要的教训并不是 AlphaEvolve 魔法般地让索引变快了。它做了更实际的事情：在手动探索效率低下的领域中，帮助生成和排名低级别的优化想法。JetBrains 工程师提供了问题、测试、测量规范和判断力，而 AlphaEvolve 扩展了搜索范围。
致谢
这个项目是 JetBrains 团队（包括 Denis Shiryaev 和 Dmitrii Batkovich）与 Google Cloud 的 AI for Science 和账户团队（包括 Anant Nawalgaria、Skander Hannachi、Kartik San、Laurynas Tamulevičius、Nicolas Stroppa 和 Artemiy Yashin）之间的合作成果。
[](https://blog.jetbrains.com/ai/2026/05/how-we-use-alphaevolve-to-make-complex-ide-algorithms-faster/#)