在让AI去进行代码修改这件事情上所花费的钱, 其中超过一半实际上是耗费在了代码寻找这一环节上。揭示出这个令人尴尬的事实的是蚂蚁集团的ACL 2026论文, 并且给出了一个与直觉相悖的解决办法: 问题并非存在于模型的大小方面, 而是在于搜索策略究竟有多明智。

最烧钱的卡脖子环节

在你促使AI去修复一个Bug之际, 那AI必须于充斥几十万行代码的项目范围之内, 精确寻觅到所要修改的是哪一个文件, 具体又是哪一个函数。这样的流程就被称作代码定位, 而它属于自动软件修复里面最为关键。同时也是最为昂贵的瓶颈。

现有方案被划分成两大流派, 它们各自存在着痛点, 一种是依靠规则匹配的方式, 其效率较为低下, 并且极易遗漏关键信息, 另一种是借助模型推理, 然而轮次消耗数量惊人, Token账单数额飞快攀升。

一次只能做一件事的陷阱

这两派存在着一个共有的致使缺陷, 即每一轮交互仅能够调用一个工具, 进而逐步地缩小范围 , 这类似比如于假设像你像在图书馆那样寻找书籍时, 规定其每次只能够翻开一个书架去看上一眼, 当轮次全部用完了之后信息却依旧还没有收集齐全。

论文将这种现象称作信息匮乏, 轮次越多, 等待的时间就越漫长, 成本也就越高, 然而定位精度不一定会得到提升, 因为你始终在像盲人摸象那样摸索。

无脑并行反而更糟

那个解决方案看上去好像挺简单的, 一次多调用几个工具不就成了。然而, 论文实验却揭示出了一个违背常情的发现, 什么发现呢: 假使每一轮调用的工具数量固定为8个, 那么就会出现超过34.9%的冗余调用。

再次搜索已然看过的代码区域, 不但耗费Token, 而且会致使噪声信号介入从而干扰判断。并行数量少则信息不足难以胜任, 并行数量多却存在大量冗余, 这般便构成了两难的困境。

自适应并行的设计哲学

居于核心位置的洞察是, 搜索效率跟搜索质量不存在对立的那种关系, 重点并非在于并行多少的数量, 而是在于何时应当多进行并行, 以及何时应当少进行并行。其设计哲学有着超乎寻常的优雅之处: 并非给模型设定固定死的规则, 而是让模型凭借自身去学会进行动态的调整。

仅凭简简单单的三个只读工具, 着实是极其克制的, 分别是: 借助glob去查找文件, 利用grep来搜索内容, 以及读取细节, 这三者相互组合起来能够对整个代码库进行遍历。并不需要代码知识图谱, 也无需语法解析器, 仅仅凭借零依赖的状态就能够使用。

训练策略分两步走

先来看第一阶段的监督微调, 要从大概21,000个issue – patch对里头, 精心挑选出大约6,000条高品质数据, 以此教会小模型, 使其每一轮能够同时调试2到8个工具。再说说第二阶段的强化学习, 其奖励函数的设计极其精巧。

奖励等同于0.8与定位准确率相乘, 再加上0.2与定位准确率和工具效率相乘所得数值的和。这样的设计促使模型于搜索的每一个阶段付诸抉择, 究竟是广泛撒网收获的利益更大一些, 还是精心仔细校验获得的益处更多一些。

小模型大翻身的结果

以SWE-bench为准拿来跟前法作比, 提升效果可谓是呈碾压态势。准确率实现成倍增长, 速度加快至十六倍之多, Token的使用减少将近七成。有个具备四十亿参数的开源小模型, 其定位能力与商用闭源大模型是等同的。

在接入下游Agent之后, 其并不会对修复效果造成影响, 并且能够直接将成本砍掉将近一半以上。这样的一种先进行广度搜索而后再开展深度搜索的模式, 完全是模型凭借自身从奖励信号中学习而得出的, 不存在任何人工制定的规则。 句号。

交由你来思考的问题出现了: 要是此刻你的AI编程工具向你表明, 它存在大约一半的Token皆是在重复性搜索方面耗用掉的, 那么你究竟会抉择将策略予以升级, 或者是依旧持续性地投入资金? 诚挚欢迎诸位在评论区域把你的见解分享出来, 通过点赞以及转发的操作, 使得更多的人能够瞧见这个具备节省钱财功效的诀窍信息, 从而达成分享的目的。