李传艺-一种基于修复偏好的自动程序修复工具集成策略

APR研究现状及集成方法

• APR (Automated Program Repair) 旨在自动修复软件系统中的缺陷，目前已有超过40种APR工具，包括：
  • 传统基于规则的工具：如GenProg（采用遗传算法）、Nopol（基于语义约束）、TBar（基于修复模板）。
  • 基于神经机器翻译 (NPR) 的工具：如CoCoNut（结合上下文感知的NMT架构和CNN模型）、SequenceR、DLFix、Cure、Circle、RewardRepair、Codit、SelfAPR、Recoder、Tare。
  • 基于大语言模型 (LLM) 的工具：如AlphaRepair、PLBART、CodeT5、CodeGen、InCoder、GPT-Neo、GPT-J、GPT-NeoX、Codex、GPT(3.5/4)、ChatRepair、RTTAPR、Srepair、ThinkRepair、FixAgent、RepairAgent。

本工作动机

• 现有基于学习的APR工具集成方法存在训练数据构造成本高、特征选取随机性大、增加新的APR工具代价大等问题。
• 提出非基于训练的集成方案，无需构建专门的训练数据，随着修复经验积累性能增强。
• 通过待修复Bug和APR工具能修复、不能修复的Bug之间的关系度量，直接度量一个APR工具是否能够修复一个Bug。

基于修复偏好的集成方案

• P-EPR (Preference-based Ensemble Program Repair)：根据APR工具对各类特征（共4类）的Bug的修复能力（能/不能）进行分类，并建立修复能力与Bug特征之间的映射关系。
• 集成框架：
  1. 为3类传统APR工具整理其修复能力与Bug特征之间的映射关系。
  2. 根据修复历史数据为所有工具初始化/更新Bug特征与修复能力的映射。
  3. 抽取待修复Bug的特征。
  4. 为所有工具计算成功修复输入Bug的得分并排序。
  5. 按序执行工具并记录结果。
• 评分机制：
  • BaseScore：根据修复历史中记录的修复能力和Bug特征之间的关系计算基础得分。
  • PatternFactor：如果Bug特征符合传统工具的修复偏好，则通过提升影响因子的方式为传统工具加分。
  • Final Score = Base Score * (1+Pattern Factor)：优先选择传统APR工具，可解释、更可信。
• 更新机制：
  • 添加新的工具：直接更新Repair Patterns、Repair History，不影响其他工具。
  • 持续更新修复历史：所有工具的修复历史都会持续更新；不强制新工具有历史数据，冷启动问题：得分低，难以被选中。

实验和结果讨论

• 实验设置：
  • 包括21个APR工具的仿真模拟实验和4个APR工具的真实场景下的执行与验证实验。
  • 集成框架仅为测试集中的Bug推荐APR工具的执行顺序，实际修复与否、修复代价则直接复用已公开数据。
  • 数据集为Defects4J；Repair History设置为空；输入顺序Random，修复偏好影响因子0.5。
• 评估指标：
  • Baselinel：评估指标包括被正确修复的Bug数量、找到Plausible补丁的Bug数量、APR工具调用次数、人工检验Plausible补丁的次数、相比执行所有工具而节约的工具调用次数、人工检验似真补丁的次数。
  • RQ1. 总体性能：与Invoking All、Optimal Selection对比，取得接近性能时大幅度降低工具执行、人工检查的开销；与E-APR、E-APR(enhanced)对比，Pattern对P-EPR的贡献。
  • RQ2. 组件消融：所有组件都有影响，影响较大的初始修复历史数据、是否动态更新修复历史、Pattern影响因子取值取影响不大。
  • RQ3. 实用性能：4个NPR工具在Bears数据集中的83个Single-hunk的Bug上真实执行，P-EPR集成策略超越了所有单个NPR工具的修复性能：正确修复数量、精准率；单位修复正确的Bug节约的工具执行开销、人工验证开销都比单个工具要高很多，相比单独使用任何一个模型更加实用！

总结、展望与补充讨论

• P-EPR 总结了一种实用的APR集成方案：充分发挥各APR工具的优势，在降低时间、计算资源开销的基础上提升修复性能；容易加入新的APR工具；随着历史数据积累的越多，效果越好。
• 展望1：集成方案的优化。但是，该集成思路能正确修复的Bug数量，无法超越所有单个模型能修复的Bug并集能力更强的APR工具；在生成补丁程序Token时集成不同的修复工具。
• 展望2：集成LLM-based Self-enhancing APR。将其放在固定的位次作为候选，例如尝试Top 3都不行，则尝试这类方法。基于LLM使用Chain-of-Thought、Agents、Additional Generation、Self-correction等技术。仅使用Bug内部信息：上下文代码、错误代码的位置；另使用Bug外部信息：测试用例、报错信息、调试信息等。
• 补充：LLM-based Self-enhancing APR泛化性。
  • SRepair修复Defects4J数据集上近300个Bug(共500+)；非LLM方案最多能修复不到100个。
  • 使用的额外信息：缺陷报错信息、触发缺陷的测试用例、开发者或用户对缺陷的评论。
  • LLM的自增强APR方法表现出非常突出的性能，但不是所有缺陷修复场景下这都很容易获取，Magicoder对不同场景的泛化性受到影响。
  • SRepair在更多其他数据集上都能表现很好吗？测试了Defects4J、QuixBugs、HumanEval-Java、BugsInPy。
  • 如果LLM对不同数据集的记忆程度不同，且记忆多效果好，记忆少效果差，如何度量LLM对数据集的掌握情况——记忆程度？LLM补全的代码和真实代码之间的Type-1克隆：数量 和 密度。
  • 增大记忆会提升效果吗？+ 降低记忆会降低效果吗？构造包含BugsInPy general-level和bug-level知识的数据集，并微调Base LLM；对Srepair第二个LLM也使用微调后的LLM。
  • Base LLM对评测数据集的记忆程度会影响对自增强方法性能提升的评测结果，评测时使用多种不同的评测数据集合、尽可能使用包含新收集数据的评测数据集，使用新的Bug数据持续更新APR的评测数据集。