MergeRepair 将多个代码任务适配器合并后，在 StarCoder2 上把自动程序修复的 pass@1 提升 2.38%、pass@10 提升 4.01%，且不额外训练

合并任务特定适配器可以在不额外训练的情况下提升自动程序修复的表现。 此前模型与适配器合并主要在自然语言处理和计算机视觉中验证，该工作首次把适配器合并用于自动程序修复任务，并公开了代码与复现包。 在 HumanEvalFix 基准上以 pass@1 和 pass@10 评估，覆盖 StarCoder2 与 Granite 两个 3B 模型、三种合并方法和多种适配器组合，并报告了配对 t 检验 p 值与 cliff's delta 效应量；例如 StarCoder2 上合并 APR 与 Improvement、Misc 适配器时 pass@1 提升 2.38%、pass@10 提升 4.01%。

合并效果更多取决于参与合并的具体任务适配器，而非适配器数量。 研究系统比较了 2 至 5 个适配器的各种组合，发现增加或减少适配器数量并不必然带来性能升降，这与“任务越多越好”的直觉不同。 在 RQ1 的 45 组实验中，StarCoder2 有 19 组、Granite 有 36 组的 pass@1 相比 APR 适配器提升；作者指出 T3（Misc）单独在 APR 基准上表现最高（StarCoder2 31.40%、Granite 18.63%），且出现在所有最佳合并组合中。

continual merging 中适配器的合并顺序显著影响最终表现，把最有效的适配器放在最后一步可提升效果。 作者提出 continual merging 这一新范式，按几何级数递减先前适配器的权重，使最后加入的适配器权重最高，从而模拟真实项目中任务按时间顺序出现的场景。 在 RQ3 中对 4 个任务的全部 24 种排列进行实验，覆盖三种合并方法与两个模型；结果显示最后加入低表现适配器（如 T5）会拉低表现，而最后加入高表现适配器（如 StarCoder2 的 T1、Granite 的 T4）表现更好，且多数结果统计显著。

即使合并模型中不包含 APR 适配器，合并后的适配器仍可在 APR 基准上达到相当甚至更好的表现。 这展示了合并方法的泛化能力：来自非 APR 任务的适配器只要各自在 APR 上表现较强，合并后仍能迁移到 APR。 RQ2 中排除 APR 适配器后构建 11 个合并适配器，StarCoder2 有 8/33、Granite 有 29/33 的 pass@1 结果超过 APR 专用适配器；例如 StarCoder2 上 T2-T3 合并的 pass@1 达 31.95%（+3.29%），Granite 上 T3-T4 达 19.30%（+3.14%）。

该工作面向希望在有限算力与数据下复用已有代码任务适配器的研究者与实践者，实验设定为 Python 语言、CommitPackFT 的五个任务（Development、Bug Fixes/APR、Misc、Test & QA、Improvement）以及 StarCoder2 与 Granite 两个 3B 模型，评估基准为 HumanEvalFix。它说明在真实项目中任务按时间顺序出现时，可以逐个合并适配器而无需同时保存全部适配器，从而节省内存；也说明在私有或保密代码库场景下，合并可在不暴露敏感数据的前提下迁移知识。

合并带来的提升幅度较小（pass@1 最高 2.38%、pass@10 最高 4.01%），且高度依赖基础模型与具体任务适配器；continual merging 的最优顺序在合并四个任务时并不总能用按个体表现排序的贪心策略得到；RobustPass@1 评估因算力限制只覆盖少数适配器，且 pass@k 与 RobustPass@k 的输入格式不同，直接比较需谨慎；任务标签由 GPT-4 单样本提示生成，可能存在噪声；结论限于 Python 与所测任务，向其他语言或软件工程任务推广仍需验证。