SelRepair: Selective Program Repair
- SelRepair is an automated patch-synthesis framework that retrieves bug-fix pairs using combined code and AST similarity for enhanced repair accuracy.
- It employs a threshold-based selection gate to admit only sufficiently relevant examples, optimizing both context length and repair effectiveness.
- Evaluations on Tufano and VulRepair datasets demonstrate improved exact match scores, validating its superiority over conventional APR methods.
SelRepair is an automated program repair (APR) framework that combines a fully fine-tuned large code LLM with a dual retrieval-augmented module built over historical bug-fix pairs. Its defining idea is to retrieve relevant examples using both semantic similarity and syntactic/structural similarity, then admit only sufficiently relevant retrieved pairs through a threshold-based selection gate so that the repair model receives useful demonstrations without excessive prompt growth. The reported system uses a code-only prompt, assumes the buggy method is already given, and is evaluated on Tufano Subset 1, Tufano Subset 2, and VulRepair, where it achieves 26.29%, 17.64%, and 25.46% exact match (EM), respectively (Guo et al., 14 Jul 2025).
1. Scope, objectives, and methodological position
SelRepair is presented as a response to three recurring APR difficulties. The paper states that rule-based, heuristic-based, template-based, and semantics-driven APR methods are constrained by manual rule or template design, labor-intensive engineering, and limited bug-type coverage. It further argues that learning-based APR remains sensitive to training-data quality and model parameter size, while prompt-only use of generalized LLMs or code LLMs is hindered by limited APR specialization and by prompts that rely on natural-language bug descriptions or auxiliary metadata that may be redundant, unavailable, or too expensive in context length (Guo et al., 14 Jul 2025).
Within that diagnosis, SelRepair is explicitly a selective retrieval-augmented APR framework. Its selectivity lies in two linked choices. First, retrieval is code-aware rather than purely semantic or lexical: the method combines source-code similarity with AST-derived syntactic and structural similarity. Second, retrieval is gated: examples are ranked by similarity and only those above a threshold are inserted into the prompt, in descending similarity order, until the token budget is reached. This design is intended to improve effectiveness through higher-quality contextual demonstrations and improve efficiency through controlled prompt length (Guo et al., 14 Jul 2025).
The framework operates at method granularity. The paper is explicit that SelRepair does not provide bug localization; it assumes that the buggy method or snippet is already given. This places it in the class of method-level repair generators rather than end-to-end repository-level issue-resolution systems. A plausible implication is that SelRepair is best understood as a patch-synthesis architecture whose main novelty is the retrieval-and-selection layer rather than fault localization or workflow orchestration.
2. Dual retrieval over source code and AST structure
SelRepair constructs a retrieval codebase from method-level buggy code and corresponding fixed code. For a target buggy method, it parses source code into an AST using Tree-sitter, then flattens the AST into a sequence via AST_traversal. The traversal is preorder-based: a leaf contributes its node value, while an internal node contributes AST#<node_type>#Left, then its children, then AST#<node_type>#Right. This produces a sequence representation compatible with UniXcoder, which is the embedding model used for both source code and AST sequences (Guo et al., 14 Jul 2025).
The method computes two embeddings for the target buggy code: a source-code vector and an AST vector. It does the same for every candidate retrieved buggy code in the codebase. The target hybrid vector is defined as the average of the source-code and AST vectors, and the candidate hybrid vector is defined analogously. Relevance is then computed by cosine similarity between the candidate hybrid vector and the target hybrid vector. The appendix gives this procedure explicitly as hybrid_retriever(C,T,t), whose inputs are a bug-fix pair codebase , target buggy code , and threshold (Guo et al., 14 Jul 2025).
The paper interprets the two branches as a semantics retriever and a static structure and dependency retriever. In practice, the semantic component is carried by the source-code embedding and the structural component by the AST embedding. Their combination is simple but deliberate: rather than designing separate learned scoring functions, SelRepair averages the two representations before similarity computation. The paper argues that code-only similarity captures mostly superficial semantics, whereas AST information contributes syntax, static structure, and dependency information that is directly relevant to repair pattern matching.
The retrieval corpus sizes reported in the appendix are 1,000 examples for Tufano Subset 1, 1,000 for Tufano Subset 2, and 200 for VulRepair. The details also note a reporting discrepancy: the main text earlier says 2000 for VulRepair, while the appendix table reports 200 (Guo et al., 14 Jul 2025).
3. Selection gate, prompting, and full-parameter fine-tuning
The selection gate is the component that makes SelRepair selective in a narrow operational sense. Retrieved examples are first ranked by similarity score. The system then keeps only bug-fix pairs whose similarity exceeds a threshold, sorts them in descending similarity order, and adds them to the prompt until the context window would be exceeded. The inclusion condition is the threshold test
where is the hybrid vector of a candidate retrieved buggy code, is the hybrid vector of the target buggy code, and is the threshold (Guo et al., 14 Jul 2025).
The model prompt is code-only and uses special tokens [BUG] and [FIX]. The concatenated training input has the form
where and are the retrieved buggy and fixed codes from valid retrieved pairs, and 0 is the buggy code to be repaired. No natural-language bug description is required. The model is trained autoregressively to generate the corresponding fix: 1 This is standard next-token repair generation, but the input is shaped by gated retrieval rather than by natural-language instructions or free-form context (Guo et al., 14 Jul 2025).
The foundation model is StarCoder2-7B. SelRepair uses full-parameter fine-tuning rather than LoRA or other PEFT variants, and the paper explicitly argues that full-parameter tuning better unleashes the potential of the code LLM for APR. Training uses Adam with learning rate 2, for 3 epochs on the large-parameter LLM. The reported hardware is 4 × NVIDIA GeForce RTX 3090. At inference time, the main benchmark protocol generates one repair candidate per test sample, while real-world and Defects4J evaluations use beam search; the appendix states beam size 3 for Defects4J. The reported context windows are 512 tokens for Tufano Subset 1, 1,024 for Tufano Subset 2, and 1,500 for VulRepair (Guo et al., 14 Jul 2025).
4. Evaluation protocol and empirical results
The main evaluation uses Tufano’s two Java subsets and the VulRepair benchmark. Tufano Subset 1 contains code of length under 50 tokens, Tufano Subset 2 contains code of length 50–100 tokens, and VulRepair is a C/C++ dataset. The appendix reports train/validation/test splits of 45,880/5,735/5,735 for Tufano Subset 1, 51,565/6,447/6,447 for Tufano Subset 2, and 6,574/822/821 for VulRepair. The paper also reports an enterprise dataset of 200 Java semantic bug-fix pairs and appendix results on Defects4J v1.2 and v2.0 (Guo et al., 14 Jul 2025).
The primary metric is exact match, complemented by BLEU-4 and CodeBLEU. The paper reports that SelRepair achieves the best EM among the compared baselines on all three main datasets.
| Dataset | Best SelRepair EM | Selected threshold |
|---|---|---|
| Tufano Subset 1 | 26.29% | 0.9 |
| Tufano Subset 2 | 17.64% | 0.8 |
| VulRepair | 25.46% | 0.8 |
On Tufano Subset 1, SelRepair reports EM 26.29, BLEU-4 61.61, and CodeBLEU 74.35. On Tufano Subset 2, it reports EM 17.64, BLEU-4 73.88, and CodeBLEU 82.24. On VulRepair, it reports EM 25.46, BLEU-4 38.39, and CodeBLEU 50.84. The compared baselines include GPT-3.5, GPT-4o, DeepSeek-R1-Distill-Qwen-7B, RAP-Gen, a CodeLlama-based Llama variant, T5, and a LoRA version of the proposed setup. The paper notes that RAP-Gen can be slightly higher on BLEU-4 or CodeBLEU in some settings, but SelRepair remains higher on EM (Guo et al., 14 Jul 2025).
The ablation study attributes the overall gain to four components: fine-tuning, retrieval augmentation, semantic retrieval, and structural retrieval. w/o [RAG](https://www.emergentmind.com/topics/adaptive-agentic-retrieval-augmented-generation-rag) & Ft and w/o Ft both yield 0.00 EM on all three datasets. w/o RAG falls to 15.02, 6.52, and 19.24 EM on Tufano Subset 1, Tufano Subset 2, and VulRepair. Removing semantic retrieval yields 25.57, 10.83, and 21.92 EM; removing the static structure and dependency retriever yields 22.28, 17.41, and 22.68 EM. The full system rises to 26.29, 17.64, and 25.46, which the paper interprets as evidence that both semantic retrieval and structural retrieval contribute materially, with the relative contribution depending on code length and dataset characteristics (Guo et al., 14 Jul 2025).
Threshold sensitivity is a second central result. The no-threshold setting yields EM 21.83 on Tufano Subset 1, 15.95 on Tufano Subset 2, and 21.32 on VulRepair, with average input lengths 604.10, 886.43, and 1175.09 tokens, respectively. The selected thresholds improve both accuracy and efficiency: threshold 0.9 on Tufano Subset 1 reduces average input length to 60.53 and reduces inference time by 6.42%; threshold 0.8 on Tufano Subset 2 reduces average input length to 133.16 and reduces inference time by 13.77%; threshold 0.8 on VulRepair reduces average input length to 992.25 and reduces inference time by 9.95%. The enterprise evaluation reports that SelRepair can generate 59 correct patches on 200 Java semantic bug-fix pairs. The Defects4J appendix reports 35 repaired bugs on Defects4J v1.2 and 11 on Defects4J v2.0 (Guo et al., 14 Jul 2025).
5. Relation to adjacent repair paradigms
SelRepair occupies a distinct position relative to several neighboring APR lines. It is method-level and assumes the buggy method is already given, whereas SHERLOC is a repository-level fault localization framework that treats localization as structured, actionable diagnosis and stops at likely edit sites rather than patch synthesis (Tamoyan et al., 23 Jun 2026). SemAgent, by contrast, is a workflow-based repository-level system for SWE-Bench-style issue resolution that combines execution semantics, issue semantics, code semantics, and a repair-and-review architecture to produce complete fixes rather than hyper-localized edits (Pabba et al., 19 Jun 2025). SelRepair does not attempt that repository-level decomposition; its contribution is narrower and centered on selective retrieval and context control.
Relative to training objectives, SelRepair differs from systems that explicitly optimize repair precision or reasoning structure. PRepair reframes repair as a precise repair task, defines normalized edit extent, and trains with Edit-Aware GRPO to discourage over-editing once correctness has emerged (Ke et al., 7 Apr 2026). SeCuRepair, in automated vulnerability repair, adopts a reason-then-edit paradigm, semantics-aware reinforcement learning using BLEU, AST, and DFG signals, and a hunk-count curriculum (Yang et al., 1 Oct 2025). A plausible implication is that SelRepair and these systems attack different bottlenecks: SelRepair improves what is retrieved and injected into the model context, whereas PRepair and SeCuRepair change what the model is rewarded for producing.
This positioning clarifies SelRepair’s specific novelty. It is neither a repository-level localization front-end nor an edit-aware reinforcement-learning framework. Its selective mechanism is retrieval-side: retrieve from a bug-fix corpus with dual code/AST signals, then admit only sufficiently relevant demonstrations into the prompt. That design is particularly suited to settings where historical bug-fix pairs exist, localization is external or assumed, and prompt budget is itself an optimization target (Guo et al., 14 Jul 2025).
6. Limitations, validity considerations, and future directions
The paper explicitly acknowledges several limitations. First, SelRepair is confined to individual methods, which excludes cross-method and cross-component bugs. Second, the use of full-parameter fine-tuning on a 7B model imposes nontrivial compute cost and may be difficult to deploy in cost- or latency-constrained DevOps environments. Third, although the evaluation spans Java and C/C++, the paper does not yet establish generality to languages such as Python or JavaScript. Fourth, the selection thresholds are coarse and manually tuned per dataset and code-length regime, and the paper identifies automated threshold customization as future work (Guo et al., 14 Jul 2025).
Threats to validity are grouped into internal, external, and construct validity. Internal validity includes possible noise in bug-fix datasets, potential overfitting during fine-tuning, and coarse threshold settings for the selection gate. External validity concerns language coverage and the possibility that the reported results do not transfer directly beyond Java and C/C++. Construct validity concerns the limitations of EM, BLEU, and CodeBLEU as proxies for practical repair usefulness. The future-work agenda follows directly from these constraints: broader language coverage, support for cross-method and cross-component repair, more efficient tuning strategies such as meta-learning, modularization and caching for deployment, real-time feedback mechanisms, and automated threshold selection for different code lengths (Guo et al., 14 Jul 2025).
Taken together, these limitations show that SelRepair is best viewed as a focused architecture for selective retrieval-augmented patch generation rather than a complete repository-level repair agent. Its principal technical claim is that retrieval quality and retrieval restraint matter simultaneously: the model benefits not only from seeing similar bug-fix demonstrations, but from seeing only the ones whose code and AST structure are sufficiently aligned with the target repair problem (Guo et al., 14 Jul 2025).