![]()
新智元報道
![]()
【新智元導讀】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
特別聲明:以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布,本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.