Learning Adaptive Parallel Execution for Efficient Code Localization¶

会议: ACL2026
arXiv: 2601.19568
代码: 未在缓存中看到公开代码链接
领域: 代码智能 / LLM Agent
关键词: 代码定位、并行工具调用、GRPO、工具效率、SWE-bench Verified

一句话总结¶

FuseSearch 把代码定位中的并行工具调用建模为质量-效率联合优化问题，用 SFT+RL 学会按任务阶段自适应调节搜索宽度，在 SWE-bench Verified 上用紧凑模型取得高 F1 和显著更低的时间/Token 成本。

研究背景与动机¶

领域现状：自动软件开发 agent 往往要先定位需要修改的文件、函数或代码片段，再进入补丁生成。代码定位已经成为整条流水线的主要瓶颈，论文引用的近期结果显示 SOTA agent 超过 50% 的计算资源花在定位上。

现有痛点：传统 agent 多按顺序调用工具，紧 turn budget 下容易信息饥饿；如果强行每轮并行调用固定数量工具，又会产生大量重复或无用检索。论文观察到 enforced parallel tools 有 34.9% 是冗余调用，抵消了并行带来的收益。

核心矛盾：代码定位需要在有限交互轮次内尽快覆盖足够上下文，但覆盖面越大，越容易重复搜索或引入无关噪声；只追求低成本会漏掉关键文件，只追求高召回又会让搜索成本和上下文噪声爆炸。

本文目标：作者希望训练一个能自己决定“何时并行、并行多少、查哪里”的定位 agent，使其同时最大化定位 F1 和每次工具调用的信息增益。

切入角度：论文没有构建复杂代码图或语言特定 AST，而是只保留 grep、glob、read_file 三个语言无关只读工具，然后把工具调用是否带来新代码实体作为显式效率信号。

核心 idea：用 tool efficiency 衡量工具调用的新信息比例，并把它与 file/function F1 一起纳入 SFT 过滤和 GRPO reward，让模型学到从广泛探索到聚焦精修的自适应并行策略。

方法详解¶

FuseSearch 的设计很克制：推理时只有三种工具，训练时才引入轨迹质量和效率指标。它先用强 teacher 生成候选搜索轨迹，再筛选出既定位准确又工具效率高的轨迹做 SFT，最后用 GRPO 进一步优化一个把 F1 和效率相乘的 reward。

整体框架¶

输入是一个 issue description \(q\)，agent 在 \(T\) 个离散轮次中产生一组工具调用 \(a_t\)，观察返回结果 \(o_t\)，最后输出需要修改的代码实体集合 \(\mathcal{A}\)。与顺序 agent 一次只调用一个工具不同，FuseSearch 每轮可以并行发出多个 grep/glob/read_file 调用；这些只读工具没有同步副作用，返回结果会在下一轮前聚合进上下文。

训练流程分两阶段。SFT 阶段用 Kimi-K2-Instruct 为 6K 个训练 query 生成约 24K 条候选轨迹，并用 file/function F1 与 tool efficiency 双指标筛选出约 6K 条高质量轨迹。RL 阶段以 SFT 模型为初始策略，用 GRPO 采样多条轨迹，根据定位质量和工具效率计算奖励，鼓励模型减少重复探索但不牺牲最终定位准确率。

关键设计¶

三工具极简定位接口:
- 功能：提供跨语言、低基础设施成本的代码定位能力。
- 核心思路：grep 做正则内容搜索，glob 做文件路径匹配，read_file 读取指定文件或行段。所有工具都是只读，因此可安全并行执行。
- 设计动机：图构建、AST 解析和语言服务器会带来语言依赖与预处理开销；极简工具让模型把学习能力集中在搜索策略上。
tool efficiency 指标:
- 功能：度量每个工具调用是否真的带来新信息，而不是只看工具数量或轨迹长度。
- 核心思路：维护已发现实体历史 \(\mathcal{H}\)，对第 \(i\) 个工具返回实体集合 \(\mathcal{E}_i\)，信息增益为 \(g_i=|\mathcal{E}_i\setminus\mathcal{H}|/|\mathcal{E}_i|\)；整条轨迹效率为 \(e=\frac{1}{k}\sum_i g_i\)。
- 设计动机：只惩罚长轨迹无法区分“查了新区域”和“重复查旧区域”；tool efficiency 直接对冗余调用给低分。
SFT+RL 联合质量-效率训练:
- 功能：先让模型学会并行工具调用，再用 RL 调整并行宽度和搜索节奏。
- 核心思路：SFT 只保留满足 \(F_1\geq\rho_F\) 且 \(e\geq\rho_e\) 的轨迹；GRPO reward 采用 \(R(\tau)=\alpha F_1(\tau)+\gamma(F_1(\tau)\cdot e(\tau))\)，其中 \(F_1\) 是 file-level 与 function-level F1 的加权和。
- 设计动机：如果 \(F_1=0\)，再高效率也没有实际价值；乘积项让效率 bonus 只在定位质量成立时放大收益，避免模型为了高效率而少查或乱查。

损失函数 / 训练策略¶

训练数据来自 233 个高质量 GitHub 仓库，去除会新增文件/函数、issue 描述过短或没有代码变化的样本，从约 21K 个过滤样本中抽取 ground truth 文件、函数/方法和行范围。SFT 模型需要生成每轮 2-8 个工具调用。RL 使用 GRPO，多输出采样并根据 file/function F1 和 efficiency 计算 reward；论文比较了 F1-only、\(F_1+e\) 与 \(F_1+F_1\cdot e\)，最终选择乘法交互项。

实验关键数据¶

主实验¶

评测使用 SWE-bench Verified，按前人设置排除 patch 引入全新文件或函数的样本，保留 386/500 个 example。主结果表明，训练后的 FuseSearch-4B 同时提升定位质量和效率。

方法 / 配置	File F1	Func F1	效率 / 成本结果	说明
RepoSearcher, Qwen3-4B backbone	38.1	21.7	作为摘要中对比基线	专门定位 agent
FuseSearch-4B trained	84.7	56.4	时间加速 93.6%，turn 减少 67.7%，token 减少 68.9%	摘要报告的核心结果
Qwen3-4B Base	64.50	38.91	e=59.50, T=6.12s, Tok=47.9k	未经两阶段训练
Qwen3-4B SFT+RL	84.65	56.43	e=69.00, T=5.43s, Tok=30.9k	两阶段训练后
Qwen3-30B-A3B SFT+RL	83.01	58.62	e=64.53, T=10.6s, Tok=43.2k	大模型同样受益

消融实验¶

配置	File F1	Func F1	#Turn	T(s)	Tok.(k)	说明
Seq SFT+RL	78.82	50.21	7.52	8.03	59.4	每轮 1 个工具
Par SFT+RL	84.65	56.45	5.60	5.43	30.9	并行执行明显更优
SFT only	78.86	47.94	4.96	9.17	54.8	会学到并行但仍有冗余
RL reward: F1 only	81.84	54.90	未在表中列出	7.28	39.4	提升质量但效率不是最优
RL reward: \(F_1+e\)	79.22	51.98	未在表中列出	9.40	45.7	效率高但质量下降
RL reward: \(F_1+F_1\cdot e\)	84.65	56.45	未在表中列出	5.43	30.9	质量、效率和成本同时最好

关键发现¶

SFT 让模型学会更积极并行，提升 F1，但也会引入冗余；RL 后模型学到“先宽后窄”的策略，早期广泛探索，后期聚焦精修。
joint filtering 比只按 F1 或只按 efficiency 过滤更稳。无过滤 SFT 的 File F1/Func F1/e 为 75.44/43.52/55.77，joint filtering 提升到 78.86/47.94/62.03。
FuseSearch 能加速下游修复 agent。Kimi-K2 无定位时 pass rate 68.4、41.1 turns、312s、1053k tokens；Pre-Search 后 pass rate 68.1、31.6 turns、223s、562k tokens。
极简工具集在顺序模式下也有竞争力，说明代码定位不一定必须依赖语言特定图结构；但真正的收益来自模型学会有效并行。

亮点与洞察¶

tool efficiency 是这篇论文最可复用的概念。它不是粗暴惩罚“工具调用多”，而是惩罚“没有新信息的调用”，这更贴近真实 agent 搜索质量。
乘法 reward 设计很合理：定位失败时效率没有意义，定位成功时效率才是 bonus。这避免了 agent 学成“少查所以高效”。
论文把并行工具调用从工程能力变成学习目标。很多 agent 框架支持 parallel call，但模型不会自然知道何时并行；FuseSearch 明确训练这个决策。
结果对小模型 agent 很有启发：4B 模型通过任务专门训练和工具效率奖励，可以在定位阶段接近甚至替代昂贵大模型的一部分工作。

局限与展望¶

作者指出 golden patch 只代表一种可行修复路径，可能漏掉其他正确定位，因此 F1 ground truth 本身有偏。
SWE-bench Verified 主要覆盖 Python 仓库；虽然工具语言无关，但 Java/C++ 等静态语言上的有效性还需要更多训练和评测数据验证。
当前基准聚焦 issue-driven localization，没有评估 repository QA、代码理解、文档生成等更广义代码搜索任务。
tool efficiency 依赖“代码实体是否新”的定义，未来可以把语义新颖性、调用成本、文件重要性也纳入效率度量。

评分¶

新颖性: ⭐⭐⭐⭐☆ 工具效率指标和质量-效率乘法奖励很实用，方向清晰。
实验充分度: ⭐⭐⭐⭐☆ SWE-bench Verified、训练阶段、并行模式、过滤策略、reward 和下游修复都有覆盖；跨语言仓库还不足。
写作质量: ⭐⭐⭐⭐☆ 方法定义和消融逻辑清楚，个别表格因信息多稍难读。
价值: ⭐⭐⭐⭐⭐ 对代码 agent 降本提速很有实际价值，尤其适合定位作为下游修复前处理。