Learning Adaptive Parallel Execution for Efficient Code Localization

AI summary

Overview

• Research area: AI for software engineering — specifically LLM-based agents that locate which files and functions in a codebase must be changed to resolve a reported issue.
• Technical level: Intermediate. The paper assumes familiarity with reinforcement learning from human feedback/policy optimization (SFT, GRPO, rewards) and with repository-level code benchmarks, but the core idea is explainable without deep math.
• Scope: The paper introduces FuseSearch, a compact code-localization agent trained to decide which read-only search tools to run and how many to run in parallel per turn, jointly optimizing localization accuracy and search efficiency on SWE-bench Verified.

What This Paper Is About

Locating the right code for a bug or feature request is a major cost in automated software pipelines — the paper states that state-of-the-art agents spend more than 50% of their compute on this step. Agents usually search one tool at a time over many turns, and under tight turn budgets they run out of interactions before gathering enough evidence, a problem the authors call information starvation. Parallel tool calls help, but the authors report that naive fixed-breadth parallelism wastes effort: 34.9% of enforced parallel tool invocations are redundant. FuseSearch's goal is to learn when and how much to parallelize so that searches are both comprehensive and non-redundant.

Key Contributions

1. A "tool efficiency" metric. The authors define information gain for each tool call as the fraction of returned code entities not already seen in the search history, and define tool efficiency e as the mean information gain across all tool invocations. This directly penalizes redundancy rather than merely penalizing trajectory length.
2. An efficiency-aware two-stage training framework. FuseSearch uses supervised fine-tuning (SFT) on trajectories filtered by both F1 and efficiency, followed by reinforcement learning with GRPO using a joint reward that combines a base F1 term with a multiplicative F1 × efficiency bonus.
3. A minimalist agent design. FuseSearch uses only three language-agnostic, read-only tools — grep, glob, and read_file — with no code graphs, ASTs, parsers, or language-specific infrastructure, yet the paper reports it matches or exceeds more complex systems.
4. Demonstrated downstream acceleration. The trained 4B localization model is evaluated as a preprocessing step or sub-agent for Kimi-K2-Instruct on issue resolution, reducing interaction turns by 23.1% and end-to-end task time by 28.5% without sacrificing pass rates.

Main Findings

• Redundancy is the core bottleneck of parallelism: The paper reports a 34.9% redundant invocation rate in enforced parallel execution, meaning over a third of parallel tool calls add no incremental information.
• Large accuracy gains over a comparable baseline: Under the same Qwen3-4B backbone, FuseSearch improves file-level F1 from 38.1% (RepoSearcher) to 84.7%, and function-level F1 from 21.7% to 56.4%.
• Large efficiency gains: The trained model uses 67.7% fewer interaction turns, 68.9% fewer tokens, and achieves a 93.6% speedup relative to that baseline. In absolute terms on SWE-bench Verified, FuseSearch (train) with Qwen3-4B records 4.78 turns, 5.43 seconds, and 30.9K tokens per instance versus 14.8 turns, 85.3 seconds, and 99.2K tokens.
• Training stages are complementary: SFT establishes parallel tool use and raises F1 (Qwen3-4B file F1 from 64.50 to 78.86) but introduces redundancy that degrades efficiency; RL then raises F1 further (to 84.65) while recovering efficiency (e from 68.46 to 69.00 in the SFT+RL row) and cutting time from 9.17 s to 5.43 s.
• RL learns adaptive rather than fixed breadth: Base models use minimal parallelism, SFT shifts to uniformly aggressive parallelism, and RL produces a breadth-first-to-depth-first pattern — broad early exploration that quickly narrows to focused refinement.
• Joint reward design matters: Among the reward variants tested on Qwen3-4B, the multiplicative F1 + F1 · e reward achieves the best file F1 (84.65), function F1 (56.45), efficiency (69.00), lowest time (5.43 s), and lowest tokens (30.9K). F1-only reached 81.84 file F1, and the additive F1 + e variant reached the highest reported efficiency (66.62) but with lower F1 (79.22) and higher cost.
• Dual-metric SFT filtering matters: Of four filtering strategies (none, F1-only, efficiency-only, joint), joint filtering gives the best SFT starting point at 78.86 file F1 / 47.94 function F1 with efficiency 62.03.
• Parallel beats sequential under matched training: With identical configurations, parallel SFT+RL reaches 84.65 file F1 in 5.60 turns and 30.9K tokens, while sequential reaches 78.82 file F1 in 7.52 turns and 59.4K tokens.
• Minimalist tools remain competitive even sequentially: FuseSearch* (the FuseSearch framework with sequential prompts) reaches 72.48 file F1 on Haiku 4.5 versus 72.30 for LocAgent, while using far fewer turns (23.9 vs 17.3 — noting LocAgent actually uses fewer turns here) and much less time (90.3 s vs 318 s) and tokens (270K vs 567K).
• Downstream benefit is consistent: Assisting Kimi-K2-Instruct on SWE-bench Verified, pre-search yields a 68.1% pass rate versus 68.4% with no localization, while cutting turns from 41.1 to 31.6, time from 312 s to 223 s, and tokens from 1053K to 562K.
• LocBench evaluation is referenced but not fully reported: The authors state they retained 456 of 560 examples from LocBench and that Table 9 presents the performance, but the truncated content does not include those numbers.

Methodology in Plain English

Task setup. The agent is given an issue description and interacts with a repository over discrete turns. Each turn it can emit several tool calls as JSON objects, all of which execute concurrently because they are read-only, and the combined results are fed back before the next model response.

Tool efficiency. The system keeps a history of every file and code region already examined. For each tool call, it computes what fraction of the returned entities is new. The average of those fractions across all calls is the efficiency score e. Calling the same region twice, or getting empty results, drives the score down.

Two-stage training. First, a strong teacher model (Kimi-K2-Instruct) generates candidate trajectories over 6K randomly sampled training queries, each prompted to use 2–8 tools per turn, producing roughly 24K candidates. Only trajectories that clear both an F1 threshold and an efficiency threshold survive, leaving about 6K demonstrations used to fine-tune Qwen3-4B-Instruct and Qwen3-30B-A3B-Instruct. This teaches the base models to actually emit parallel calls and gives a strong initialization.

Second, GRPO reinforcement learning refines the policy. The reward is α · F1 + γ · (F1 · e) with β set to zero, on the reasoning that a trajectory that finds nothing relevant provides no utility no matter how "efficient" it was. The linear F1 term guarantees a baseline reward, while the product term acts as a soft gate that amplifies reward only when high quality and high efficiency coincide. In practice α = 0.8, γ = 0.2, and F1 is the weighted combination 0.7 · file-level F1 + 0.3 · function-level F1.

Training scale. The repository-level dataset comes from 233 high-quality GitHub repositories with no overlap with evaluation benchmarks; about 21K filtered issue–patch pairs are split into 6K for SFT and 15K for RL. SFT runs for 1 epoch with batch size 32, learning rate 2e-5, and 32768-token max sequence length on 8 NVIDIA H20 GPUs. RL uses vLLM for rollout sampling, RLLM/veRL for distributed training, temperature 0.7, 8 rollouts per instance, global batch size 256 across 32 H20 GPUs, learning rate 1e-6, and KL coefficient 0.01.

Evaluation. Localization is scored by precision, recall, and F1 at file and function granularity on SWE-bench Verified, using the 386 of 500 examples retained after excluding patches that introduce entirely new files or functions. Cost is measured by wall-clock time, interaction turns, and token consumption, averaged over three runs.

Why This Matters

Impact on research. The paper reframes parallel tool use from a fixed engineering setting (call N tools per turn) into a learned policy problem with an explicit efficiency objective. Its central claim — that efficiency-aware training improves quality by removing noisy redundant context — suggests redundancy is not just a cost problem but an accuracy problem, which is a useful framing for future agent training work. It also argues that a three-tool language-agnostic toolset is sufficient, challenging the assumption that code graphs or AST infrastructure is necessary for strong localization.

Real-world applications:

• Automated issue resolution pipelines: A fast localizer can be inserted before a repair agent so the repair model starts with the right files, cutting cost per resolved issue (the paper reports 68.1% pass rate at 223 s and 562K tokens for pre-search versus 68.4% at 312 s and 1053K tokens without localization).
• IDE and developer-assistant search: Adaptive parallel grep/glob/read is directly applicable to "where is this handled in my repo" style queries.
• CI and code-review triage: Rapidly mapping a bug report or alert to candidate files and functions before a human or agent inspects them.
• Repository question answering and code comprehension: The same efficiency-aware search policy applies to navigation tasks beyond bug fixing, though the authors note they have not evaluated these.

Industry relevance. The work targets the cost side of deploying agents — turn budgets, latency, and token spend — which the authors tie to production-grade agent benchmarks. Its models are compact (4B and 30B-A3B) and the authors note that strong performance is achieved without specialized hardware, in contrast to commercial retrieval systems that need expensive inference infrastructure.

Future Directions

1. Language coverage beyond Python. The authors state that available benchmarks predominantly cover Python repositories and that validating effectiveness on statically-typed languages like Java or C++ would require more diverse benchmarks and training data.
2. Ground-truth quality. Localization targets come from golden patches, which represent only one valid solution and may miss alternative correct localizations; better evaluation of alternative correct answers is an open problem.
3. Broader search tasks. The paper notes that code search underpins repository question answering, code comprehension, and documentation generation, contexts the approach has not been evaluated on.
4. Scaling and generalization of the efficiency signal. The joint reward and dual-metric filtering are validated on Qwen3-4B and Qwen3-30B-A3B; how the recipe behaves at other scales, and how adaptive breadth generalizes across repositories and task difficulty, remains to be tested.

Target Audience

Researchers and engineers building LLM agents for software engineering will benefit most, particularly those working on repository-level code search, tool-use policies, or RL-based agent training. It is also relevant to practitioners who need cost-efficient localization components inside repair pipelines or IDE tooling, and to readers interested in reward design for agents, since the ablation on reward formulations (F1-only vs additive vs multiplicative) is one of the paper's more transferable lessons. Readers without a background in reinforcement learning will find the metrics and motivation accessible, though the training section will require familiarity with SFT and GRPO.

Authors’ abstract

Code localization constitutes a key bottleneck in automated software development pipelines. While concurrent tool execution can enhance discovery speed, current agents demonstrate a 34.9% redundant invocation rate, which negates parallelism benefits. We propose FuseSearch, reformulating parallel code localization as a joint quality-efficiency optimization} task. Through defining tool efficiency -- the ratio of unique information gain to invocation count -- we utilize a two-phase SFT and RL training approach for learning adaptive parallel strategies. Different from fixed-breadth approaches, FuseSearch dynamically modulates search breadth according to task context, evolving from exploration phases to refinement stages. Evaluated on SWE-bench Verified, FuseSearch-4B achieves SOTA-level performance (84.7% file-level and 56.4% function-level F1 scores) with 93.6% speedup, utilizing 67.7% fewer turns and 68.9% fewer tokens. Results indicate that efficiency-aware training naturally improves quality through eliminating noisy redundant signals, enabling high-performance cost-effective localization agents.