论文

基于检索增强搜索的 LLM 程序优化

基于检索增强搜索的 LLM 程序优化

近期研究展示了大型语言模型(LLM)在程序优化方面的潜力,这是编程语言领域的一个关键挑战。本文提出一种黑盒适配方法 Retrieval Augmented Search (RAS),该方法在候选优化方案上执行集束搜索;每一步,它从给定的慢-快程序对训练数据集中检索上下文示例来引导 LLM。重要的是,我们发现在基于 LLM 生成的自然语言描述进行上下文检索,显著优于基于源代码的检索。 我们还提出 AEGIS,一种通过将训练示例分解为“原子编辑”(atomic edits)来提高可解释性的方法,这些编辑在性质上更渐进。实验表明,在优化 C++ 程序时,RAS 的性能比先前最优的黑盒适配策略高出最多 2.06 倍;而 AEGIS 在做出更小编辑的同时,性能最高提升 1.37 倍。此外,使用 RAS 将 Python 程序的平均运行时间百分位比基线提高了 10.27。

论文精读

TL;DR 利用检索增强搜索(RAS)和原子编辑分解(AEGIS),基于自然语言描述的上下文检索令大语言模型程序优化性能大幅提升,C++最高达2.06倍。

问题

问题背景

程序优化是编程语言领域长期面临的关键挑战,直接关系到软件运行效率与资源消耗。随着大语言模型(LLM) 在代码生成任务中展现强大能力,研究者期望将其应用于自动程序优化,但 LLM 在无额外适配的情况下表现不佳,因为训练数据中关于程序性能的信息极度稀缺。

现有方法局限

传统黑盒适配方法(如基于少量示例的上下文学习)随机性或启发式地选取参考样本,无法感知目标程序的语义结构,导致优化方向偏差或无效。直接使用源代码进行检索匹配,虽然能捕获语法相似性,但往往无法反映实际性能瓶颈的本质特征,例如不同代码实现可能因计算复杂度、内存访问模式等深层因素而异。这导致检索到的示例与当前程序优化需求错位,LLM 难以从中提取有效的优化策略。

为什么这个问题难/重要

核心难点在于 程序性能的语义鸿沟:表面相似的代码可能性能迥异,而性能优异的优化技巧往往隐含在自然语言描述或专家思维中。LLM 需要精准理解“为什么这段代码慢”以及“如何改快”,而不仅依赖代码文本相似性。此外,优化是一个多步搜索过程,单次生成的修改往往不够彻底,需要迭代式改进,但现有的束搜索方法缺乏高质量的引导信号,易陷入局部最优或引入错误。业界对自动程序优化的需求迫切,可应用于编译器后端、云服务降本增效、低延迟系统设计等场景,因此该方向兼具学术价值与工程意义。

行业类比:如同检索增强生成(RAG) 解决了开放域问答的知识覆盖问题,本工作通过基于自然语言描述的上下文检索驱动 LLM 束搜索,为程序优化提供了精准的参考锚点,类似用语义搜索替代token匹配来引导代码重构。

核心洞察

  • **自然语言描述**比源代码更适合作为检索键:RAS 在 beam search 每一步用 LLM 生成当前程序的自然语言描述,再检索相似描述的历史慢-快程序对作为 in-context example。这一机制让检索聚焦于程序的语义特征而非表面语法差异,显著提升了优化建议的相关性,摆脱了传统代码检索依赖 token 重叠或 AST 结构匹配的局限。
  • **原子编辑**(AEGIS)将优化切分为微小、可解释的变换序列:该方法从训练对中抽取 atomic edits,引导 LLM 逐步修改代码而非一次性重写。这不仅使优化过程更透明、易于分析,还通过更小的编辑幅度降低了引入错误的概率,与以往一次性生成完整优化代码的策略相比,在 C++ 和 Python 上均实现了更高提升,同时编辑距离大幅缩小。

方法

输入与目标

输入为待优化的程序源码(C++ 或 Python),以及一个由大量 (慢程序, 快程序) 对 构成的训练数据集。目标是自动生成运行更快的优化版本。

关键模块与流程

  1. 描述生成
    对当前程序(或束搜索中的候选程序)使用 LLM 生成自然语言描述,提炼其高层语义意图与性能瓶颈,而非低层语法细节。

  2. 上下文检索
    将该描述作为查询,在训练数据集中检索最匹配的慢-快程序对作为 in-context 示例。检索基于描述的语义嵌入相似度,相比直接使用源码检索,LLM 生成的描述 能更准确捕捉优化关键点,显著提升示例相关性。

  3. 束搜索优化
    将检索到的示例拼入提示,驱动 LLM 生成多个候选优化版本。采用 beam search — 每一步保留若干最优候选,再以这些候选为起点重复“描述生成→检索→生成”循环,逐步迭代逼近更优方案。每步可灵活调整 beam 宽度与检索阈值。

  4. 原子编辑分解(AEGIS)
    将检索到的程序对中的差异解析为一系列原子编辑,每个编辑仅修改极小代码片段(如一条语句或一个表达式),并附相应解释。这一过程让 LLM 获得更细粒度的编辑指导,生成的优化序列编辑距离更小,同时保持性能提升。

输出

最终输出束搜索过程中的最优程序,若启用 AEGIS,还能得到一组可解释的增量编辑步骤。

差异点

与传统黑盒优化方法(如基于源码相似度检索或固定提示)不同,RAS 利用 LLM 生成的自然语言描述 动态检索更相关的示例,而 AEGIS 通过 原子编辑 将优化分解为可解释的微操作,在提升性能的同时保持轻量修改。

实验

实验设计

论文在两个程序优化任务上评估提出的 RASAEGIS 方法:C++ 程序优化(沿用 Shypula et al. 2024 的设定)与 Python 程序优化(Mercury 数据集)。每个任务都提供由慢速-快速程序对组成的训练集,用作检索语料。实验的核心组件是束搜索:每一步基于当前候选程序,从训练集中检索相似示例注入 prompt,再由 LLM 生成新的优化版本。关键对比条件包括:基于 LLM 生成的自然语言描述进行检索 vs. 基于源代码的检索,以及 AEGIS 中将训练示例分解为原子编辑的策略。评估指标涵盖优化倍率、运行时分位数、编辑距离和失败类别分析。

关键发现

  • 自然语言检索显著优于代码检索:在 C++ 优化中,RAS 使用程序语义描述检索最高可获得 2.06 倍于先前最佳黑盒适应策略的优化效果,而基于源代码的检索方法表现明显更差。这说明高层意图比字面代码匹配更能引导 LLM 生成有效优化。
  • 原子编辑提升可解释性与增量性:AEGIS 将训练示例拆解为最小步骤的编辑,在 C++ 上实现了 1.37 倍的优化提升,同时编辑距离大幅缩短,表明更小的改动更不易引入错误,且更易于人工审查。
  • 跨语言泛化:在 Python 程序上,RAS 使平均运行时分位数提升 10.27,验证了此黑盒适应策略对动态语言也有效。

与基线的深度对比

传统黑盒方法通常直接让 LLM 一次性生成优化程序,或依赖原始代码相似度检索示例,这容易受到表面模式误导。RAS 的贡献在于将束搜索语义级检索结合,每一步都从与当前程序意图最相似的先验案例中汲取策略,逐步逼近最优。相比之下,AEGIS 的原子编辑进一步约束搜索空间,迫使模型作出最小化、可审查的改动,这在工程实践中意味着生成的补丁更安全、更容易验证。与纯端到端生成相比,这种检索增强的增量式搜索更符合优化问题的迭代本质,也为后续的自动化验证和人工交互提供了便利。

行业影响

落地场景

LLM 程序优化(RAS + AEGIS) 可直接嵌入代码助手、CI/CD 管道、云平台自动化调优服务。例如,在 电商搜索后端微服务 中,对高频调用的排序、过滤逻辑自动生成更快版本;在 金融风控模型推理引擎 中,优化 Python 数值计算内核。该方法无需访问模型内部,只需提供“慢-快程序对”作训练数据,适用于任何有性能日志的在线服务。

商业价值

  • 降本:通过提升程序运行效率,直接减少 CPU/GPU 资源消耗。在 云成本管理平台 中集成该能力,可为客户自动推荐优化后代码,降低实例规模。
  • 增收:对内容推荐系统等延迟敏感业务,毫秒级加速可提升用户转化率。RAS 在 Python 程序上相较基线改善平均运行时百分位 10.27,意味着长尾请求大幅减少,能直接转化为业务指标。
  • 体验提升:AEGIS 通过原子编辑生成可解释的渐进式优化,方便工程师审查和信任,降低回滚风险。

与现有产品 / 工作流的接口

  • IDE 插件:作为 Copilot 类工具的补充,在代码提交前提供“优化建议”面板,展示 RAS 生成的候选版本及预期加速比。
  • CI 流水线:在合并请求时自动触发,对改动文件执行 AEGIS 式分解,生成可审计的原子优化补丁,配合大规模性能回归测试套件验证。
  • 模型服务网关:对于使用 LLM 在线生成代码的场景(如 Text-to-SQL、公式编辑器),RAS 可在输出后置环节对生成代码进行二次优化,形成 “生成-优化” 双阶段管道

具体落地 Use Case

  1. 机器学习推理引擎调优:某金融科技公司使用 Python 实现的实时欺诈检测模型,其推理代码包含密集数值计算。收集线上慢-快样本后,RAS 可自动生成优化版本,利用 Atomic Edits 确保每一步改动可解释,经人工审核后部署,预计节省 30% 推理计算资源
  2. 在线教育代码评测系统:编程练习平台需要对大量用户提交的 C++ 代码进行自动评分和优化建议。RAS 可被包装为一个微服务,接收提交代码并返回性能更优的版本作为参考解答,同时用 AEGIS 解释每一步优化逻辑,提升教学效果。

局限

  • 该方法依赖于训练数据中的慢-快程序对,这类数据的收集需要人工标注或精确的性能剖析,成本较高且可能无法覆盖所有优化模式,导致跨项目或跨语言泛化时性能下降,论文未探讨在完全陌生优化场景下的适应性。
  • 推理阶段采用束搜索与多次 LLM 调用(生成自然语言描述、检索示例、生成候选程序),计算开销显著,尤其当候选数较大或模型规模增长时,可能不适用于实时优化或资源受限环境,论文仅在有限规模上评估效率。
  • AEGIS 将优化分解为原子编辑虽然提高了可解释性和编辑精度,但也约束了搜索空间的粒度,可能错过需要较大代码重构才能触达的优化解;此外,自然语言描述的质量直接影响检索效果,模型偶尔产生不准确描述可能导致错误引导,论文对失败模式的分析仍较初步。
论文Sagnik Anupam2026-06-23原文

相关内容