这项由宾夕法尼亚大学University of Pennsylvania开展的研究以预印本形式发布于arXiv平台编号为arXiv:2501.18916v2最新版本更新于2026年6月23日。感兴趣的读者可通过该编号在arXiv数据库中检索完整论文。程序员们有一个共同的烦恼写出来的代码能跑但跑得慢。就像一道菜做出来能吃但味道和效率都还不够好。专业的大厨会用多年积累的经验和技巧一步步把菜肴打磨到极致。那么能不能让AI也学会这种精益求精的本领把一段普通代码反复打磨成高效程序这正是这项研究要解决的核心问题。研究团队发现现有的大型语言模型就是ChatGPT这类AI其实并不擅长优化程序——因为训练数据中几乎没有程序跑得快慢这类信息AI从来没学过这个。所以光靠AI直接改代码效果非常有限。为了突破这个瓶颈研究团队提出了两套新方法一套叫做检索增强搜索RAS另一套叫做原子编辑引导搜索AEGIS。这两套方法配合使用让AI在优化代码时的平均速度提升幅度达到了人类程序员水平的两倍多甚至在某些测试中超越了人类选手的优化成果。一、问题出在哪里AI改代码为何总差点意思要理解这项研究的价值得先搞清楚程序优化到底是怎么回事。假设你写了一段代码功能正确但运行起来很慢——就像你找到了正确的路但走的是羊肠小道而不是高速公路。程序优化的任务就是在不改变代码功能的前提下帮它找到那条高速公路。现代编译器把人写的代码翻译成机器能执行的语言的工具会做一些自动优化但这些优化都是低层次的就像帮你把鞋带系得更紧却没办法告诉你换一双跑鞋。真正高水平的优化往往需要改变算法本身——比如把一个每次都从头搜索的笨方法换成一个能记住中间结果的聪明方法。这种级别的优化需要深刻理解程序在做什么。此前宾夕法尼亚大学的团队已经建立了一个名为PIEPerformance Improving Edits性能提升编辑的基准测试集专门用来衡量各种AI方法在C程序优化上的表现。他们发现当时效果最好的黑盒方法不调整AI权重、只靠提示词驱动的方法叫做动态代码检索——它的做法是在一个由慢程序-快程序配对组成的训练数据库中根据代码相似度找几个相关案例然后把这些案例喂给AI让AI学着照葫芦画瓢地改写当前程序。这个方法已经比什么都不做强很多但研究团队觉得还不够好。问题在于仅仅找代码长得像的例子并不能保证找到的例子真的用了相同的算法思路。两段代码可能都用了大量的循环和数组操作表面上看很像但一个在解决最短路径问题另一个在处理字符串匹配——优化策略完全不同找这种形似神不似的例子帮不上什么忙。此外原来的方法是一锤子买卖——给AI一组例子让它一次性生成改好的代码不管结果好不好都不再继续打磨。这就像请一个厨师来改良菜谱但只让他尝一口就提交最终版本不给他反复试验的机会。二、RAS的核心创意先描述算法再按算法找例子新方法RAS的第一个关键改进是改变了找相似案例的方式——从看代码长什么样变成看代码在做什么。具体做法是这样的当AI拿到一段待优化的程序时先不急着去翻数据库找类似代码而是让AI先读懂这段程序用一句自然语言描述它的核心算法。比如一段代码可能被描述为使用带记忆化的动态规划寻找从第一个元素到最后一个元素的最小跳跃代价代价定义为相邻元素的绝对差值之和。有了这段文字描述之后再把这段描述转换成一个数学向量可以理解为一串数字代表这段话的语义然后去数据库里找语义最相近的案例——也就是那些同样使用了类似算法思路的慢程序-快程序配对。这种方式的妙处在于两段写法完全不同的程序只要它们用的是同一种算法就能被正确地匹配在一起。反过来两段看起来很像的程序如果算法本质不同也不会被错误地匹配。这就像在图书馆找书与其按封面设计找不如按内容主题找找到的书才真正有参考价值。为了实现这个先描述后检索的过程研究团队预先对训练数据库里的每一对慢-快程序都生成了自然语言描述并存储好对应的语义向量。这样在实际使用时只需要给当前待优化程序生成一次描述就可以快速检索到最相关的案例不会产生太大的额外计算开销。三、RAS的第二个创意反复打磨而不是一次了事RAS的第二个改进是引入了束搜索beam search机制。这个名字听起来很学术但背后的道理非常直观。回到厨师改良菜谱的比喻与其让厨师尝一口就定稿不如让他做出几个改良版本挑出其中最好的一个然后以这个版本为基础再做新一轮改良如此往复几轮最终得到一道真正经过反复打磨的菜。RAS的工作流程正是如此。从原始的慢程序出发第一步检索相关案例让AI生成若干个优化版本从中挑出跑得最快且结果正确的那一个。第二步把上一步选出的最优程序作为新起点再次检索相关案例注意这次检索的是基于已经优化了一轮的新程序的描述所以找到的案例也会更相关再生成若干个新版本再挑最优。如此循环论文中默认进行四轮。每一轮中AI只使用一个检索到的案例一对慢-快程序作为参考而不是像之前的方法那样把多个案例一股脑全塞进提示词。这样做的好处是每一步的优化方向更清晰、更聚焦不会让AI陷入同时学太多技巧、反而不知所措的困境。在整个搜索过程中有一个重要的细节保证了效率每一轮检索时算法会刻意避免使用之前已经用过的案例确保每一步都能引入新的优化思路而不是原地踏步。四、实验数据RAS到底比之前好多少研究团队在两个基准测试集上验证了RAS的效果。在C程序优化方面使用了PIE基准测试集包含973个待优化的测试程序。衡量指标是平均最佳加速比——也就是经过优化后程序平均能跑得多快。使用GPT-4o作为底层AI时RAS达到了8.03倍的平均加速比而原来最好的动态代码检索方法只有4.43倍。使用更新的Qwen3-Coder模型时RAS达到8.70倍动态检索只有4.23倍。使用DeepSeek 3.2时RAS达到9.18倍动态检索为7.03倍。另外还有一个优化成功率指标% Optimized衡量有多少比例的程序被成功提速超过10%。RAS在GPT-4o下达到96.92%在Qwen3-Coder下达到98.56%在DeepSeek 3.2下达到99.08%而人类程序员的成功率是98.87%。也就是说RAS在优化成功率上已经与人类程序员不相上下甚至在某些模型下小幅超越。研究团队还设计了一个去掉上下文检索、只保留迭代搜索的对照实验称为No Contextual结果显示它的性能明显低于完整的RAS介于动态检索和RAS之间。这说明基于算法描述的检索和迭代搜索这两个创新各自都贡献了显著的性能提升缺一不可。在Python程序优化方面研究团队使用了Mercury基准测试集包含256个LeetCode题目的Python解法。核心指标是Beyond1代表程序在所有提交中的运行时间百分位。使用Qwen2.5-7B-Instruct这个相对较小的模型原始未优化程序的均值是58.66而RAS将其提升到87.85提升幅度超过10个百分点显著缩小了小模型与大模型之间的性能差距。五、AEGIS像编译器一样把大改动拆成小步骤RAS虽然效果很好但它每一步的改动幅度往往很大——就像一个厨师直接把菜谱改得面目全非你很难搞清楚哪一步改动起了关键作用。这对于需要理解和审查优化过程的程序员来说不够透明。受现代编译器设计思路的启发研究团队提出了AEGIS原子编辑引导搜索。现代编译器做优化时不是一次性大改而是经过一系列编译器趟次compiler passes每一趟只做一种特定类型的微小改动比如消除重复计算、把递归改成循环、优化内存访问顺序等。AEGIS就是要让AI也学会这种小步快跑的优化方式。AEGIS的核心是一个预处理步骤在正式优化任何程序之前先对训练数据库里的每一对慢-快程序进行拆解。具体过程可以分为三个阶段。第一阶段是分解让AI看一对慢程序和快程序然后用自然语言描述出这两者之间的差异把它们拆解成一个有序的改动列表。比如第一步把cin/cout替换成scanf/printf以加快输入输出第二步把不必要的变量声明移到循环外面第三步把递归改成迭代等。第二阶段是重建按照这个改动列表从原始慢程序出发一步一步地应用每个改动生成一系列中间程序。比如第一步改动之后得到程序1第二步改动之后得到程序2以此类推。这样就把一对慢-快程序变成了一条程序演化链链上的每一步只有一个微小改动。第三阶段是泛化每一个微小改动都有对应的自然语言描述但这些描述是针对特定训练程序的比如把这个函数里的递归改成循环。为了让AI能把这个改动应用到其他程序上需要让AI把描述改写成更通用的表达比如对于使用递归且存在重叠子问题的动态规划算法将其改写为自底向上的迭代实现以消除函数调用开销。这种更通用的描述就是原子编辑。经过这个预处理步骤原来的训练数据库从慢-快程序对变成了原子编辑程序示例对的数据库里面包含了大量细粒度的、可泛化的优化技巧。在实际优化一个新程序时AEGIS仍然使用RAS的迭代搜索框架但每次检索的不再是整体的慢-快程序对而是最相关的原子编辑。找到相关的原子编辑后AI被要求把这个具体的优化技巧应用到当前程序上同时参考数据库中该原子编辑对应的程序示例。六、AEGIS的实验结果更小的步子更容易理解的过程AEGIS在性能上略低于RAS但仍然显著优于所有基线方法。使用GPT-4o时AEGIS达到6.08倍平均加速比使用Qwen3-Coder时为5.37倍使用DeepSeek 3.2时为6.48倍。这些数字都远高于动态代码检索的4.43倍/4.23倍/7.03倍也超过了无上下文对照实验的3.86倍/2.76倍/5.87倍。研究团队分析了AEGIS性能略低于RAS的两个可能原因一是AI分解生成的中间程序不能保证每一步都有实质性的性能提升可能有些原子编辑其实没什么用二是同一对原始训练数据可能产生多个原子编辑在检索时这些相关编辑可能被重复选取降低了搜索过程的多样性。但AEGIS真正的优势体现在可解释性上。研究团队用字符级编辑距离来衡量每一步改动的幅度编辑距离越小说明改动越小、越容易理解。结果显示AEGIS的平均编辑距离明显低于RAS使用GPT-4o时AEGIS为213.05RAS为257.77使用Qwen3-Coder时AEGIS为194.05RAS为259.87使用DeepSeek 3.2时AEGIS为263.24RAS为296.41。更值得关注的是第一步的改动幅度对比RAS在第一步往往会做出极大的改动编辑距离约500-600之后的步骤改动相对较小而AEGIS第一步的改动就已经被控制在250-400的范围内全程改动更为均匀分散。这对于需要理解和审查优化过程的程序员来说更加友好。七、AI改的代码准确率有多高任何代码优化方法都必须回答一个关键问题改完之后代码还是正确的吗功能被改坏的优化不是优化而是引入了新bug。研究团队对这个问题做了仔细检验。在GPT-4o实验中他们模拟了如果只追求速度、不管正确性的场景看看AI是否会选择错误的程序。结果是RAS在全部973个测试案例中只有5个会选到错误程序准确率99.5%AEGIS则完全没有选到错误程序准确率100%。为了更严格地验证研究团队还用了一个叫做CBMCC语言有界模型检查器的专业工具对DeepSeek 3.2生成的10个程序对进行形式化的等价性验证——也就是用数学方法证明优化前后的程序在所有可能的输入下都会产生相同的输出。结果是10个程序对中有8个被证明完全等价剩余2个存在微小差异一个程序多输出了几个换行符核心逻辑完全正确。八、失败案例分析哪类问题让AI犯难研究团队还仔细分析了哪些程序没能被成功优化从中发现了一些规律。对于AEGIS未优化程序集合中有12.09%涉及二分搜索而整个测试集中只有4.32%的程序涉及二分搜索——说明AEGIS对二分搜索类程序的优化能力相对薄弱失败率比平均水平高出接近三倍。此外AEGIS未优化集合中有45.05%是动态规划问题整体比例为51.59%这个差距不算特别显著。对于RAS整体失败率更低只有3.08%的程序未被成功优化。但有意思的是涉及Kruskal算法一种用于求解最小生成树的图论算法的程序在全体测试集中只占1.03%却在RAS的失败案例中占到了20%是个明显的薄弱点。相比之下AEGIS在Kruskal算法上的失败率反而更低一些。这种分析有很实际的价值通过识别两种方法各自的弱点可以有针对性地在训练数据库中补充相关类型的优化案例从而进一步提升性能。九、代码嵌入模型的对比实验研究团队还专门检验了用专门针对代码训练的嵌入模型能不能缩小代码检索与上下文检索的差距这个问题。他们用Codestral-Embed-2505一个专为代码设计的语义向量模型替换了默认的通用文本嵌入模型在DeepSeek 3.2的第一轮搜索中进行对比。结果显示RAS上下文检索在第一轮达到8.03倍加速、96.30%优化成功率代码嵌入Codestral达到6.57倍、88.39%通用文本嵌入无上下文达到5.92倍、87.26%。专用代码嵌入模型确实比通用文本嵌入略好一些但与上下文检索的差距仍然很明显。研究团队解释了这个现象背后的原因竞赛程序员写代码时常常使用相似的变量名和操作模式导致表面上很像的代码实际上在解决完全不同的问题代码嵌入会被这些表面相似性误导。而上下文检索通过算法描述抽象掉了这些表面差异找到的是真正在算法层面相似的案例自然效果更好。十、研究的局限性与未来方向研究团队坦诚地讨论了两个主要局限性。第一RAS和AEGIS都需要对每个程序进行多轮优化-评估循环计算开销比一次性生成要大在实际大规模部署时需要考虑成本。AEGIS还有额外的预处理开销需要提前对整个训练数据库进行拆解和重建。第二这套方法目前主要在相对简单、独立的程序如竞赛编程题目的解法上验证对于由多个模块组成的大型工业代码库可能需要先解决找到哪些代码片段值得优化的问题才能套用这套框架。尽管如此研究团队认为这套方法为将AI应用于实际代码优化提供了一条可行的路径。事实上相关技术已经开始在工业界落地宾夕法尼亚大学的相关研究人员此前发表的研究中提到了将高层代码优化应用于仓储系统性能提升的实践。归根结底这项研究做了一件很有趣的事它教会AI先理解程序在做什么再去找相似的优化案例同时让AI养成了反复打磨、每次只做一个改动的好习惯。这两个改变加在一起让AI的代码优化能力产生了质的飞跃。对普通人来说这意味着未来我们使用的各种软件、APP、在线服务有可能在不改变功能的前提下跑得更快、耗电更少——因为背后的代码经过了AI的精心打磨。对程序员来说这套方法提供了一个有力的辅助工具尤其是AEGIS的小步改动模式让程序员能清楚地看到每一步优化在做什么、为什么要这样做而不是面对一段突然变成另一段的神秘代码。当然正如研究团队自己指出的AI优化的结果仍然需要程序员来验证正确性。这套工具还没有强大到完全自主运作的程度更像是一个博学的助手帮你提出优化建议最终决定权仍在人的手中。有兴趣进一步了解技术细节的读者可以在arXiv上通过编号arXiv:2501.18916查阅完整论文。QAQ1RAS检索增强搜索和普通的AI代码优化有什么区别A普通AI代码优化通常是一次性的直接让AI改写程序。RAS的不同之处有两点一是检索时先让AI用自然语言描述程序用的算法再找算法相似的参考案例而不是找代码写法相似的二是会反复迭代多轮每轮选出最优结果再继续改进而不是生成一次就结束。这两个改进使平均加速效果比此前最好的方法高出约两倍。Q2AEGIS生成的原子编辑数据库是怎么来的AAEGIS通过三个步骤构建原子编辑数据库。首先让AI对训练集中每对慢-快程序进行差异分解用自然语言描述出若干个具体的改动步骤。然后按步骤逐一应用这些改动生成一系列中间程序。最后让AI把每个改动的描述从针对特定程序改写成适用于更多程序的通用表达。这样训练集中的每对程序都会产生多个原子编辑示例程序对汇总形成数据库。Q3RAS优化后的程序准确率怎么保证ARAS在每一步搜索中只保留通过所有测试用例的程序不正确的直接排除。实验中GPT-4o版RAS在973个测试案例上的准确率为99.5%AEGIS为100%。此外研究团队还用形式化验证工具CBMC对10个DeepSeek生成的程序进行了数学等价性证明8个完全等价另2个只有输出格式的微小差异核心逻辑完全正确。