这个神器你知道吗？能自动修复Python中的BUG！谁还去改BUG啊？

在 QuixBugs 基准上，研究者将 bug 的修补总数增加了 50％以上，同时将误报率从 35％降至 5％，并将超时（timeout）从 6 小时减少到 1 分钟。根据微软自己的可执行测试基准，此模型在不使用跟踪的情况下首次修复了 68％的 bug；而在添加跟踪之后，第一次尝试即可修复 75％的错误。为评估可执行的测试，作者接下来还将开源框架和验证集。

论文链接：https://arxiv.org/pdf/2105.09352.pdf

引言

自动程序修复中的主要范例是「生成和验证」方法。研究者遵循该方法，假设存在可以识别 bug 存在的一组测试函数，然后本地化 bug 并考虑候选的修补程序，直到找到满足测试的补丁程序为止。

在整个实验过程中，研究者使用了错误已被本地化为单个 buggy 方法的合成 bug，将其与其他上下文（例如函数文件中的上下文以及暴露 buggy 函数的栈追踪）作为输入，并将该输入提供给尝试生成修复好的函数的序列到序列 transformer。

研究者在部署方案中还尝试使用了栈追踪来本地化 bug。目前，研究者基于来自开发人员自己的代码行的栈追踪来应用一种简单的启发法，因为最近调用的行是最可疑的。在未来，作者还有兴趣使用可以对给定栈追踪的方法进行重新排序的编码器 transformer 来改进启发法。

如下图所示，利用了经过广泛预训练的 transformer，研究者使用了用于微调 PyMT5 的相同的 DeepDev-py 序列到序列模型。他们首先使用 commit 数据来训练基线 bug 修补程序模型和 bug 创建模型。Bug 创建（bug-creator）模型向 DeepDebug（反向翻译）提供的数据量是原来的 20 倍。最后，研究者针对具有可执行测试并产生追踪的函数中的神经错误微调了此模型，从而获得其最终的 DeepDebug（追踪）。

训练 pipeline。

模型

研究者重复使用了具有 12 个编码器层和 12 个解码器层的 4.06 亿参数的序列到序列 transformer。在实验栈追踪时，他们为代码框架分配了 1024 个 token，为追踪分配多达 896 个 token，并且为了适应这个规