代碼定位太慢？螞蟻ACL2026新作：讓模型自己學會「該搜多少」

新智元報道

【新智元導讀】FuseSearch：學習型自適應并行執(zhí)行 —— 一個40億參數(shù)的模型，憑什么在代碼定位上干過了商用閉源大模型？答案只有四個字：搜得更聰明。

在AI編程狂飆突進的今天，一個尷尬的事實正在浮出水面：

你花在「讓 AI 改代碼」上的錢，超過一半其實燒在了「找代碼」上。

研究表明，當前最先進的AI編程Agent，超過50%的計算資源消耗在代碼搜索與定位環(huán)節(jié)——Agent翻來覆去地搜文件、讀代碼、定位函數(shù)，輪次消耗驚人，Token賬單飛漲。

當所有人都在卷「模型多大、能寫多長的代碼」時，螞蟻集團的一篇ACL 2026 Findings論文把目光轉(zhuǎn)向了一個更底層的問題：能不能讓搜索本身變得更聰明？

答案是可以。而且效果堪稱驚艷——

FuseSearch-4B，一個僅40億參數(shù)的開源模型，在SWE-bench Verified上達到84.7%文件級F1，匹配Claude Haiku 4.5的定位能力，同時速度快93.6%，Token消耗降低68.9%。

怎么做到的？一句話：讓模型自己學會該并行多少。

代碼定位

AI編程最燒錢的「卡脖子」環(huán)節(jié)

設(shè)想這樣一個場景：你讓AI幫你修一個Bug，它需要在一個幾十萬行代碼的大型項目中，精準找到該改哪個文件、哪個函數(shù)。

這就是代碼定位（Code Localization）——自動軟件修復中最關(guān)鍵、也最昂貴的瓶頸。

現(xiàn)有方案分為兩大流派，各有各的痛點：

但這兩派有一個共同的致命缺陷：一次只能做一件事。

每一輪交互只能調(diào)用一個工具，逐步縮小范圍。就像你在圖書館找一本書，規(guī)定每次只能翻開一個書架看一眼——輪次用完了，信息還沒收集夠。

論文把這種現(xiàn)象稱為信息匱乏（Information Starvation）。

并行 ≠ 萬能解藥

那解決方案似乎很簡單——一次多調(diào)幾個工具不就行了？

沒那么容易。論文實驗揭示了一個反直覺的發(fā)現(xiàn)：無腦并行反而更糟。

如果固定每輪調(diào)用8個工具（樸素的并行策略），會產(chǎn)生超過34.9%的冗余調(diào)用——重復搜索已經(jīng)看過的代碼區(qū)域，不僅浪費Token，還會引入噪聲信號干擾判斷。

核心矛盾就此浮出水面：

并行少了→信息不夠用，定位精度下降。并行多了→大量冗余，浪費計算資源。

FuseSearch的核心洞察是：搜索效率和搜索質(zhì)量并非對立關(guān)系。關(guān)鍵不在于并行多少，而在于——什么時候該多并行，什么時候該少并行。

FuseSearch

極簡工具箱 + 自適應智能

FuseSearch的設(shè)計哲學出奇地優(yōu)雅：不給模型定死規(guī)則，讓它自己學會動態(tài)調(diào)整并行度。

3.1 三把「瑞士軍刀」

零成本部署

FuseSearch只用三個只讀工具，極其克制：

就這三個。不需要代碼知識圖譜，不需要語法解析器，不需要任何重型基礎(chǔ)設(shè)施。零依賴，拿來就能用，可即時部署到任意代碼倉庫。語言無關(guān)，Python 倉庫能用，Java倉庫也能用。

工具雖少，能力完備——glob找文件、grep 搜內(nèi)容、read_file讀細節(jié)，三者組合可以遍歷整個代碼庫。

關(guān)鍵創(chuàng)新

用「信息增益」量化搜索質(zhì)量

論文首次提出工具效率（Tool Efficiency）指標，衡量每次工具調(diào)用的信息新穎性：

信息增益=新發(fā)現(xiàn)的代碼實體數(shù)÷總返回的代碼實體數(shù)

打個比方：你派了5個偵察兵去探路。如果5個人報告的都是同一條路，那4 個人就白跑了。工具效率衡量的，就是「每個偵察兵帶回了多少獨家情報」。

效率越高 → 每次搜索都在探索新區(qū)域。效率越低 → 在做重復勞動。

兩階段訓練

先學會并行，再學會聰明地并行

FuseSearch的訓練策略分兩步走：

階段一：監(jiān)督微調(diào)（SFT）——建立并行能力

從233個高質(zhì)量GitHub倉庫中提取約21,000個issue-patch對，用強大的教師模型（Kimi-K2-Instruct）生成搜索軌跡。然后用雙重標準嚴格篩選：

• 定位準確率 ≥ 0.8

• 工具效率 ≥ 0.5

從約24,000條候選軌跡中，精選出約 6,000 條「又準又不浪費」的高質(zhì)量數(shù)據(jù)，教會小模型「每輪可以同時調(diào) 2-8 個工具」。

階段二：強化學習（RL）——學會自適應

SFT之后，模型會并行了，但還不知道什么時候該多并行、什么時候該少并行。

RL階段的獎勵函數(shù)設(shè)計得極為精妙：

\text{獎勵} = 0.8 \times \text{定位準確率} + 0.2 \times (\text{定位準確率} \times \text{工具效率})

注意那個乘積項：

• 只有「找得準」且「搜得不浪費」同時滿足，才能拿到額外獎勵

• 如果定位完全錯誤（準確率=0），無論效率多高，獎勵都是零——模型不能「高效地犯錯」

這個設(shè)計迫使模型在搜索的每個階段都做權(quán)衡：當前是廣撒網(wǎng)收益大，還是精準驗證收益大？

訓練結(jié)果：一種「先撒網(wǎng)、再收網(wǎng)」的搜索策略

經(jīng)過RL訓練，模型自動學會了一種「老司機」式的自適應搜索模式：

這種「先廣度、后深度」的模式，完全是模型自己從獎勵信號中學出來的，沒有任何人工規(guī)則。

實驗結(jié)果：小模型大翻身

5.1 核心數(shù)據(jù)（SWE-bench Verified，386 個實例）

在Qwen3-4B上對比之前的方法RepoSearcher，F(xiàn)useSearch的提升堪稱碾壓：

一句話總結(jié)：準確率翻倍，速度快16倍，Token省了近70%。

5.2 40億參數(shù) vs.商用閉源大模型

一個可以本地部署的4B開源小模型，定位能力與商用閉源大模型持平，同時更快、更省。

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

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

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

為什么這項工作值得關(guān)注？

FuseSearch帶來了三個層面的貢獻：

學術(shù)層面

首次將「搜索效率」變成一個可訓練的目標。不是簡單地讓模型多搜或少搜，而是通過精巧的獎勵函數(shù)設(shè)計，讓模型自己學會「什么時候該搜多少」。這為 Agent 工具調(diào)用策略的優(yōu)化提供了一個新范式。

工程層面

極簡設(shè)計，零部署成本。三個只讀工具，語言無關(guān)，不依賴任何重型基礎(chǔ)設(shè)施。論文作者已將代碼開源，可即時部署到任意代碼倉庫。

產(chǎn)業(yè)層面

小模型逆襲大模型。40億參數(shù)匹配Claude級別的定位表現(xiàn)，證明了「聰明的策略」比「堆參數(shù)」更重要。對于對延遲和成本敏感的工業(yè)級AI編程場景，這條路線極具落地價值。

論文信息

• 論文標題：FuseSearch: Learning Adaptive Parallel Execution for Efficient Code Localization

• 收錄會議：ACL 2026 Findings

• 作者單位：螞蟻集團（Ant Group）

• 論文鏈接：https://github.com/sxthunder/FuseSearch