新智元报道

【新智元导读】FuseSearch：学习型自适应并行执行 —— 一个 40 亿参数的模型，凭什么在代码定位上干过了商用闭源大模型？答案只有四个字：搜得更聪明。

在 AI 编程狂飙突进的今天，一个尴尬的事实正在浮出水面：

你花在「让 AI 改代码」上的钱，超过一半其实烧在了「找代码」上。

研究表明，当前最先进的 AI 编程 Agent，超过50% 的计算资源消耗在代码搜索与定位环节—— Agent 翻来覆去地搜文件、读代码、定位函数，轮次消耗惊人，Token 账单飞涨。

当所有人都在卷「模型多大、能写多长的代码」时，蚂蚁集团的一篇 ACL 2026 Findings 论文把目光转向了一个更底层的问题：能不能让搜索本身变得更聪明？

答案是可以。而且效果堪称惊艳——

FuseSearch-4B，一个仅 40 亿参数的开源模型，在 SWE-bench Verified 上达到84.7% 文件级 F1，匹配 Claude Haiku 4.5 的定位能力，同时速度快93.6%，Token 消耗降低68.9%。

怎么做到的？一句话：让模型自己学会该并行多少。

代码定位

AI 编程最烧钱的「卡脖子」环节

设想这样一个场景：你让 AI 帮你修一个 Bug，它需要在一个几十万行代码的大型项目中，精准找到该改哪个文件、哪个函数。

这就是代码定位（Code Localization）——自动软件修复中最关键、也最昂贵的瓶颈。

现有方案分为两大流派，各有各的痛点：

但这两派有一个共同的致命缺陷：一次只能做一件事。

每一轮交互只能调用一个工具，逐步缩小范围。就像你在图书馆找一本书，规定每次只能翻开一个书架看一眼——轮次用完了，信息还没收集够。

论文把这种现象称为信息匮乏（Information Starvation）。

并行 ≠ 万能解药

那解决方案似乎很简单——一次多调几个工具不就行了？

没那么容易。论文实验揭示了一个反直觉的发现：无脑并行反而更糟。

如果固定每轮调用 8 个工具（朴素的并行策略），会产生超过34.9% 的冗余调用——重复搜索已经看过的代码区域，不仅浪费 Token，还会引入噪声信号干扰判断。

核心矛盾就此浮出水面：

并行少了→信息不够用，定位精度下降。并行多了→大量冗余，浪费计算资源。

FuseSearch 的核心洞察是：搜索效率和搜索质量并非对立关系。关键不在于并行多少，而在于——什么时候该多并行，什么时候该少并行。

FuseSearch

极简工具箱 + 自适应智能

FuseSearch 的设计哲学出奇地优雅：不给模型定死规则，让它自己学会动态调整并行度。

3.1 三把「瑞士军刀」

零成本部署

FuseSearch 只用三个只读工具，极其克制：

就这三个。不需要代码知识图谱，不需要语法解析器，不需要任何重型基础设施。零依赖，拿来就能用，可即时部署到任意代码仓库。语言无关，Python 仓库能用，Java 仓库也能用。

工具虽少，能力完备—— glob 找文件、grep 搜内容、read_file 读细节，三者组合可以遍历整个代码库。

关键创新

用「信息增益」量化搜索质量

论文首次提出工具效率（Tool Efficiency）指标，衡量每次工具调用的信息新颖性：

信息增益 = 新发现的代码实体数 ÷ 总返回的代码实体数

打个比方：你派了 5 个侦察兵去探路。如果 5 个人报告的都是同一条路，那 4 个人就白跑了。工具效率衡量的，就是「每个侦察兵带回了多少独家情报」。

效率越高 → 每次搜索都在探索新区域。效率越低 → 在做重复劳动。

两阶段训练

先学会并行，再学会聪明地并行

FuseSearch 的训练策略分两步走：

阶段一：监督微调（SFT）——建立并行能力

从233 个高质量 GitHub 仓库中提取约21,000 个 issue-patch 对，用强大的教师模型（Kimi-K2-Instruct）生成搜索轨迹。然后用双重标准严格筛选：

定位准确率 ≥ 0.8

工具效率 ≥ 0.5

从约 24,000 条候选轨迹中，精选出约 6,000 条「又准又不浪费」的高质量数据，教会小模型「每轮可以同时调 2-8 个工具」。

阶段二：强化学习（RL）——学会自适应

SFT 之后，模型会并行了，但还不知道什么时候该多并行、什么时候该少并行。

RL 阶段的奖励函数设计得极为精妙：

text{ 奖励 } = 0.8 times text{ 定位准确率 } + 0.2 times ( text{ 定位准确率 } times text{ 工具效率 } )

注意那个乘积项：

只有「找得准」且「搜得不浪费」同时满足，才能拿到额外奖励

如果定位完全错误（准确率 =0），无论效率多高，奖励都是零——模型不能「高效地犯错」

这个设计迫使模型在搜索的每个阶段都做权衡：当前是广撒网收益大，还是精准验证收益大？

训练结果：一种「先撒网、再收网」的搜索策略

经过 RL 训练，模型自动学会了一种「老司机」式的自适应搜索模式：

这种「先广度、后深度」的模式，完全是模型自己从奖励信号中学出来的，没有任何人工规则。

实验结果：小模型大翻身

5.1 核心数据（SWE-bench Verified，386 个实例）

在 Qwen3-4B 上对比之前的方法 RepoSearcher，FuseSearch 的提升堪称碾压：

一句话总结：准确率翻倍，速度快 16 倍，Token 省了近 70%。

5.2 40 亿参数 vs. 商用闭源大模型

一个可以本地部署的 4B 开源小模型，定位能力与商用闭源大模型持平，同时更快、更省。

5.3 接入下游 Agent：不掉精度，省一半成本

把 FuseSearch-4B 作为 Kimi-K2-Instruct 的「前置搜索引擎」：

不影响修复效果，直接把成本砍掉近一半。

为什么这项工作值得关注？

FuseSearch 带来了三个层面的贡献：

学术层面

首次将「搜索效率」变成一个可训练的目标。不是简单地让模型多搜或少搜，而是通过精巧的奖励函数设计，让模型自己学会「什么时候该搜多少」。这为 Agent 工具调用策略的优化提供了一个新范式。

工程层面

极简设计，零部署成本。三个只读工具，语言无关，不依赖任何重型基础设施。论文作者已将代码开源，可即时部署到任意代码仓库。

产业层面

小模型逆袭大模型。40 亿参数匹配 Claude 级别的定位表现，证明了「聪明的策略」比「堆参数」更重要。对于对延迟和成本敏感的工业级 AI 编程场景，这条路线极具落地价值。

论文信息

论文标题：FuseSearch: Learning Adaptive Parallel Execution for Efficient Code Localization

收录会议：ACL 2026 Findings

作者单位：蚂蚁集团（Ant Group）

论文链接：https://github.com/sxthunder/FuseSearch