Source-linked AI summary
QiMeng-PRepair: Precise Code Repair via Edit-Aware Reward Optimization
Changxin Ke, Rui Zhang, Jiaming Guo, Yuanbo Wen, Li Ding, Shuo Wang, Xuyuan Zhu, Xiong Peng, Di Huang, Zidong Du, Xing Hu, Qi Guo, Yunji Chen
TL;DR
LLM repair systems often over-edit, overwriting correct code and weakening bug localization, while precise repair requires preserving correct program logic. PRepair addresses this with Self-Breaking data generation and Self-Repairing through EA-GRPO with edit-aware rewards. Experiments report improved repair precision and faster inference with speculative editing, with fix1@1 increasing by up to 34.24% while correctness remains stable.
Problem
Correctness-only repair training overlooks edit extent, causing over-editing and creating challenges in obtaining realistic localized-bug data and preserving correct code.
Method
PRepair combines self-breaking bug injection and min–max sampling with EA-GRPO, which uses edit-aware rewards to encourage minimal yet correct repairs.
Results
fix1@1 increases by up to 34.24% while correctness remains stable, and speculative editing increases decoding throughput by up to 15%.
Takeaways & Limitations
PRepair improves repair precision by reducing unnecessary edits while retaining correctness and offers practical inference acceleration with speculative editing.
Takeaways & Limitations
PRepair focuses on function-level repair; extending it to file-level and project-level scenarios remains future work.
Abstract
from arXiv · showhide
Large Language Models (LLMs) achieve strong program repair performance but often suffer from over-editing, where excessive modifications overwrite correct code and hinder bug localization. We systematically quantify its impact and introduce precise repair task, which maximizes reuse of correct code while fixing only buggy parts. Building on this insight, we propose PRepair, a framework that mitigates over-editing and improves repair accuracy. PRepair has two components: Self-Breaking, which generates diverse buggy programs via controlled bug injection and min-max sampling, and Self-Repairing, which trains models with Edit-Aware Group Relative Policy Optimization (EA-GRPO) using an edit-aware reward to encourage minimal yet correct edits. Experiments show that PRepair improves repair precision by up to 31.4% under $\mathrm{fix}_1@1$, a metric that jointly considers repair correctness and extent, and significantly increases decoding throughput when combined with speculative editing, demonstrating its potential for precise and practical code repair.
1 Introduction
LLM-based repair systems often over-edit code, harming localization, maintainability, and reviewability. PRepair addresses this with self-generated buggy data and edit-aware optimization, improving precise repair across Python and Verilog while supporting faster inference.
- Correctness-only training can cause models to rewrite large code regions instead of minimally fixing localized bugs.Over-editing can weaken error localization, reduce maintainability, and increase developers’ review burden.
- Precise repair is hindered by scarce realistic buggy programs and difficulty preserving correct code during training.The framework targets bugs embedded in programs that retain substantial correct logic.
- PRepair combines Self-Breaking data generation with Self-Repairing via EA-GRPO and an edit-aware reward for minimal, correct fixes.Self-Breaking injects bugs and uses min–max sampling; EA-GRPO penalizes edits after sufficient correctness is achieved.
- PRepair reduces unnecessary edits while improving repair correctness across Python and Verilog and different model sizes.The reported evaluation covers two models and two fundamentally different programming languages.
- Combining PRepair with speculative editing increases inference throughput, supporting practical code-assistance use.The paper reports faster inference when speculative editing is applied.
- fixp@k jointly evaluates repair correctness and the number of edits, specifically measuring precise repair.The metric is introduced to assess both whether a repair is correct and how extensively the code changes.
2 Methodology
This methodology identifies over-editing in correctness-only repair, introduces fixp@k to jointly measure correctness and edit cost, and presents PRepair’s Self-Breaking and Self-Repairing stages. EA-GRPO applies dynamic edit-aware rewards to encourage minimal correct edits, while speculative editing uses lower edit costs to improve throughput.
- Over-editing: Correctness-only GRPO improves repair accuracy but substantially increases edit cost, worsening over-editing in Python and Verilog.The observed trade-off motivates explicitly measuring and training for repair precision.
- Metric Design: fixp@k jointly evaluates repair correctness and edit cost using sampled candidates and a tolerance ratio for acceptable repair cost.The corresponding criterion checks correctness while accounting for the generated program’s edit cost relative to the theoretical minimum.
- Self-Breaking: Self-Breaking injects bugs into golden programs and uses min-max sampling to construct diverse buggy training inputs.The subset minimizes maximum pairwise similarity, with similarity defined from edit cost, encouraging diversity in edit distance.
- Self-Repairing: Self-Repairing trains repairs with EA-GRPO, whose dynamic edit-aware reward balances correctness against minimal edits.The edit penalty is activated only after group-level accuracy exceeds threshold α, limiting penalties that could harm correctness.
- Reward Design: The edit-aware reward requires only the edit cost between buggy inputs and generated samples, not the golden code.This design computes the penalty from generated repairs while preserving a correctness condition.
- Inference Efficiency: Speculative editing reuses unchanged code, and reducing edit cost significantly increases decoding throughput.Under prompt lookup decoding, smaller edit costs directly translate to larger speedups.
3 Experiment
Experiments evaluate PRepair across Python and Verilog, model scales, baselines, in-domain and cross-domain settings, and speculative decoding. EA-GRPO improves repair precision while preserving correctness and increasing throughput.
- Experimental Setup: The evaluation covers Python and Verilog repair, two Qwen2.5-Coder model sizes, prompt engineering, GRPO, and EA-GRPO.The study also reports pass@k and fixp@k across multiple k and p settings.
- Main Results: 20.95% and 31.41%: EA-GRPO increases fix1@1 on Python and Verilog, respectively, compared with the original model.The gains are reported under the fixp metric and are associated with reduced over-editing.
- Main Results: 1.37% and 0.29%: Qwen2.5-Coder-7B with EA-GRPO improves pass@1 over GRPO on Python and Verilog, respectively.Qwen2.5-Coder-3B also improves pass@1 by 4.74% on Verilog.
- Cross-domain Generalization: 26.50%: GRPO’s cross-domain fix1@1 drops when Python-trained models are evaluated on Verilog, while EA-GRPO maintains stable correctness and improves precision.In the same setting, GRPO pass@1 drops by 8.31%.
- Speculative Editing: 15%: EA-GRPO improves decoding throughput with speculative edits, whereas GRPO causes throughput degradation of up to 35%.Reduced edit cost raises draft-token acceptance and supports faster inference.
- Ablation Study: The ablation varies the group accuracy threshold α and penalty coefficient β to examine the balance between repair correctness and minimal edits.Increasing β may reduce pass@1, while α controls when the edit penalty is applied.
4 Related Work
Related work spans buggy-data construction and LLM-based repair systems. Existing benchmarks have coverage, realism, availability, or error-type limitations, while prior repair methods use multi-stage, tool-augmented, or end-to-end approaches.
- Buggy Data Construction: QuixBugs contains only 40 programs, limiting coverage, while HumanEval-Fix provides 164 tasks with human-injected bugs.The paper adopts HumanEval-Fix as its primary Python benchmark.
- LLMs for Code Repair: Prior LLM repair approaches use multi-stage pipelines, external tools, or end-to-end training focused primarily on correctness.The paper characterizes multi-stage and tool-augmented methods as effective but often slow and costly.
5 Conclusion
The paper identifies over-editing as a limitation of correctness-only repair training because it increases review burden, harms maintainability, weakens localization, and reduces inference efficiency. PRepair addresses this through self-breaking data generation and edit-aware EA-GRPO, improving precision while maintaining stable correctness and accelerating decoding.
- Conclusion: Correctness-only optimization causes over-editing that increases review burden, harms maintainability, weakens error localization, and degrades inference efficiency.The paper presents these effects as practical consequences of excessive modification.
- Conclusion: PRepair combines self-breaking data generation with EA-GRPO to encourage minimal yet sufficient edits.The framework targets precise repair without requiring labeled data.
- Conclusion: PRepair improves repair precision while maintaining stable correctness and reaches up to 15% higher decoding throughput with speculative edits.The conclusion reports the throughput gain in the context of real-world code assistance.
Limitations
The paper identifies two scope boundaries: EA-GRPO’s optimal hyperparameters vary with dataset difficulty, and PRepair has so far been evaluated for function-level rather than file- or project-level repair.
- Automatic Hyperparameter Tuning: Optimal EA-GRPO settings vary across datasets with different difficulty levels, motivating automatic tuning under limited computational budgets.The limitation concerns the accuracy threshold and penalty coefficient.
- Application Scope: PRepair focuses on function-level code repair, while extending it to file-level and project-level bugs remains future work.The broader settings also require high repair precision.
A.1 Repair Cases
The repair case contrasts correctness-only GRPO with EA-GRPO, showing that EA-GRPO preserves buggy-code logic, targets the faulty lines, and makes a minimal accurate fix. Attention analysis further compares how each model attends from generated output tokens to input tokens.
- Repair case: The buggy implementation mishandles positive and negative halfway values, rounding positive .5 down and negative .5 up instead of away from zero.
- Repair case: The correctness-only GRPO baseline rewrites the entire logic, introduces errors, and discards careful string-based handling.
- Repair case: EA-GRPO identifies the two rounding errors and fixes them by replacing only lines 12 and 14.The resulting repair is described as accurate and efficient.
- Attention analysis: The attention matrix maps output tokens to input tokens, with color intensity representing the relative attention magnitude.The word-level matrix is formed after grouping subword tokens into words; extreme values are clipped at the 98th percentile for visualization.
- Attention analysis: The heatmaps compare EA-GRPO and correctness-only GRPO, plotting output words vertically and input words horizontally.
B.2 Inference & Evaluation
The evaluation uses unbiased estimation with n = 20 to compute multiple pass-at-k-style metrics, while local-model inference uses vLLM and documented sampling parameters.
- Evaluation: n = 20 is used during evaluation to compute (·)@1, (·)@5, and (·)@10 with an unbiased estimation method.
- Inference: Local models perform inference using vLLM, with inference hyperparameters summarized in Table 4.
- Evaluation: Python and Verilog edit costs are computed after AST-based preprocessing removes comments, redundant whitespace, line breaks, or other non-semantic characters.The preprocessing is intended to reduce inflated and unstable edit-cost measurements.
B.3 Statistics of Benchmarks
The benchmarks summarize diverse bug categories and use shared RL settings for correctness-only rewards and PRepair, supporting a structured comparison across Python and Verilog repair tasks.
- Experimental control: The correctness-only reward setting and PRepair use the same RL hyperparameters to ensure a fair comparison.
- Benchmark statistics: The Python and Verilog benchmarks cover a wide range of bug categories and subtypes, including diverse logical errors observed in real-world programs.
C Token-Level vs. Line-Level Edit Distance
The paper uses line-level edit distance as its primary, semantically aligned measure while checking robustness with token-level costs. It also relates minimal edits to speculative-decoding acceptance under a line-level approximation.
- Metric choice: Line-level edit distance is chosen because token-level distance can underestimate semantically substantial changes.Changing one token in an assignment can completely alter its semantics while costing one token edit.
- Metric choice: Line-based edit cost also matches practical developer workflows, where diffs and code reviews inspect modifications line by line.
- Robustness: Token-level and line-level evaluations produce fully consistent method rankings on Verilog, with EA-GRPO best and vanilla GRPO weakest under the fix metric.The comparison reports fixp@1 for p ∈ {1, 1.5, 2} under both granularities.
- Speculative decoding: EA-GRPO minimizes normalized line edit cost DEC(X, Y), defined as the fraction of modified lines between buggy input X and repaired output Y.
- Speculative decoding: Under a conservative line-aligned approximation, speculative acceptance occurs only when a repaired line remains unchanged.The approximation treats token-level acceptance as the line-level acceptance ratio because edits disrupt token continuity within modified lines.
- Speculative decoding: Lower edit cost corresponds to higher speculative acceptance, allowing EA-GRPO to turn the buggy program into a high-fidelity implicit draft.
D.2 Throughput Derivation
The derivation models speculative decoding with a K-token draft window and relates token acceptance, edit cost, and throughput. It shows that lower edit cost increases expected token yield and aligns with observed throughput gains.
- Acceptance model: X counts the tokens accepted before the first mismatch during verification of a K-token speculative draft window.If the first i draft tokens are accepted and the next is rejected, X=i+1; accepting all K draft tokens is the exception.
- Acceptance model: Under independent acceptance probability R, the expected tokens produced per verification step is computed from the acceptance distribution.The derivation defines the probability mass function and aggregates accepted-token outcomes into the expectation.
- Throughput relation: Assuming negligible N-gram lookup latency, throughput scales proportionally with the expected tokens produced per target-model verification step.The baseline decoding scheme is defined with E=1, so the throughput improvement factor is expressed relative to that baseline.
- Throughput relation: As edit cost DEC decreases, expected token yield increases, and the resulting efficiency gain is nonlinear.The analysis establishes that the throughput function decreases with D, while empirical results report improved acceptance rate and end-to-end decoding throughput for EA-GRPO.