使用文本到文本的转换器学习修复编码错误

大家好，欢迎来到IT知识分享网。

TFix: Learning to Fix Coding Errors with a Text-to-Text Transformer

Berkay Berabi1 2, Jingxuan He1, Veselin Raychev1 2, Martin Vechev1

引用

Berabi, Berkay , et al. “TFix: Learning to Fix Coding Errors with a Text-to-Text Transformer.” International Conference on Machine Learning PMLR, 2021.

论文：https://files.sri.inf.ethz.ch/website/papers/icml21-tfix.pdf

仓库：https://github.com/eth-sri/TFix?tab=readme-ov-file

摘要

本文介绍了一个名为TFix的新型学习工具，它利用Transformer模型，先在自然语言上进行预训练，再在GitHub提交中获得的大规模高质量数据集上微调，生成代码修复。TFix不局限于某种编程语言或缺陷类别，通过同时在静态分析工具报告的52种不同错误类型上进行微调，提高了精度。在JavaScript程序的大规模数据集上评估显示，TFix有效性显著：在约67%的情况下能够生成修复错误的代码，并明显优于现有的基于学习的方法。

1 引言

现代代码库的高度复杂性和庞大规模导致了大量的编码错误，严重阻碍了程序员的工作效率。虽然强大的静态分析工具可以检测错误，但是仍然需要大量的人工工作来检查报告并试图正确地修复这些错误。这种情况表明，我们非常需要一种能够自动修复现实世界中的编码错误的工具。一个理想的工具应该覆盖大范围的错误，以使大多数开发人员受益，并具有较高的修复精度。然而，这很难实现，因为不同类型的编码错误，例如可变误用和整数类型错误，有不同的根本原因。为了正确解决这些问题，该工具必须能够捕获一系列不同的程序行为。事实上，现有的基于学习的模型要么只修复特定种类的错误，要么在处理更多样但仍然有限的一组错误时变得非常不准确。

为了应对这一挑战，我们提出了一个新的基于学习的工具，称为TFix，它可以精确地产生对最流行的JavaScript静态分析器ESLint覆盖的大范围错误的修复。TFix将修复编码错误的问题公式化为文本到文本的预测任务。也就是说，如果将错误编码为文本，TFix会预测一个新的文本来表示修复错误的代码。这种公式化在三个方面有利于TFix：(a)它允许TFix以相同的文本格式捕获各种错误类型，(b)将TFix从创建复杂的代码表示中解放出来，(c)使TFix能够利用一个强大的模型T5，也叫文本到文本转换转换器，它已经被证明可以概括文本到文本格式的各种自然语言问题，因此非常适合我们的任务。

TFix利用了两种不常用的知识转移。首先，我们的T5模型在自然语言上进行预训练，然后在代码修复的编程任务上进行微调。这使得自然语言和编程语言之间的能够进行知识转移。此外，不同于现有的为每个单独的错误类型训练模型的工作，我们一起微调各种错误类型，这使得错误类型之间的知识转移成为可能，并可以被视为一种多任务学习的形式(修复每种错误类型是一项单独的任务)。这两个特征是TFix学习程序语义的深刻理解，从而达到修复编码错误的高精度的关键因素。

为了微调T5这个具有数百万个参数的大型模型，我们提取了100k个对齐的编码错误对的大规模数据集以及来自550万GitHub提交的修复。我们还调用静态分析器，并通过贪婪二分匹配和差异算法的组合，使得数据集的质量明显高于通过注入人工错误或应用树变换规则产出的数据集。TFix的设计评估并不针对特定的编程语言或错误类型，因为它将代码表示为纯文本。我们在JavaScript程序的大规模数据集上对TFix进行了广泛的评估，以修复ESLint检测到的52种错误类型。结果表明，TFix生成的代码可以修复67%的错误。此外，我们还将TFix与SequenceR，CoCoNuT，以及Hoppity等用于代码错误修复的最先进机器学习工具进行了对比，TFix明显优于这些工具。我们的案例研究表明，TFix可以为复杂的编码错误生成正确的修复。

2 技术介绍

TFix的工作流程如图1所示。TFix首先将输入程序发送到ESLint,ESLint识别程序中的一组错误。对于图2中的例子，ESLint检测缺陷并产生以下信息：错误行、错误类型、错误消息。TFix修复的方式是首先提取由错误行和两个相邻行组成的错误上下文。接下来，TFix将关于错误的所有信息表示为一段文本：

然后TFix使用这个文本来请求一个称为T5的文本到文本的转换器，生成表示修复错误代码的新文本，如图3所示。输出文本与错误上下文相同，只是插入的if语句调用了hasOwnProperty，以绿色显示。实际上，在原始程序中的错误上下文被生成的代码替换后，错误就被修复了。

图1：TFix的工作流程

图2：有错误的实例代码片段

图3：TFix修复错误后的输出

2.1 应用外部错误检测器

TFix的输入是一组由代码分析工具发现的编码错误，我们称之为检测器。在我们的例子中，检测器将输入程序解析为抽象语法树（AST），然后执行程序分析技术来检测和报告编码错误，而检测不同的错误需要各种程序分析。举个简单的例子，寻找未使用的变量需要

计算AST中变量的范围。TFix是模块化的，因为它不依赖于检测器复杂的内部逻辑，并且可以直接受益于缺陷发现的进步。TFix的输入是检测器生成的错误报告。每个报告由一个错误类型、一条错误消息和一个位置组成。

更正式地说，给定一个具有N行的程序，检测器识别出p中包含M个错误的列表。代码分析器检测器通常支持由集合T表示的多种错误类型。每个错误类型用一个元组（ ,L,t,m）表示。其中是检测器报告的引入错误的程序p中的第k行。是错误上下文，由和窗口大小为w的周围行组成。是错误类别，m是错误消息。TFix的输入是错误集，TFix会处理在中的每个错误。

在我们的工作中，我们使用JavaScript静态分析器ESLint作为检测器，涵盖了各种错误。由于其受欢迎程度，我们专注于ESLint：它被主要公司采用，并有1600万次每周下载。ESLint允许配置返回的错误类型集合。我们使用其默认配置，该配置报告编码错误和最佳实践，但不报告格式问题。ESLint内部包含一个功能，用于修复与代码中的空白区域相关的有限的风格问题。这些空白格式问题在默认的ESLint配置中被禁用，并且不包含在TFix中。其他语言也有ESLint之类的工具，比如Python的Pylint，在将TFix扩展到其他语言时可以使用。

2.2 使用T5生成代码修复

TFix的目标是为检测到的错误生成一个修复程序。我们将此任务公式化为文本到文本的预测，即给定文本形式的代码错误，TFix生成表示新代码的文本，该新代码已修复特定错误。更正式地说，给定一个错误，TFix通过填充以下模板将其表示为一段文本：

其中“fix”和“:”是原始字符串，⎵是一个空格。然后，TFix请求文本到文本编码器-解码器模型，该模型将输出为文本。被用于替换代码中的L，以便修复错误e。注意通过多次从模型中采样，直到修复通过检测器的检查，可以进一步改善TFix。我们把它作为未来的工作。

我们使用文本到文本转换转换器（T5）作为我们的文本到文本转换的模型，因为我们的公式符合其设计。T5是一个通用模型，它将不同的任务统一为文本到文本的格式，并在NLP任务上进行了预训练。我们将在3.3节讨论如何针对为代码错误生成修复的编程任务对T5进行微调。

为了处理大词汇量和词汇标记不足（OOV）的问题，我们的工作对输入和输出的代码采用字节对编码（BPE），这和T5模型的思想一致。BPE算法由单个字符初始化，通过迭代合并最频繁出现的子词来构建关于子词标记的词汇表。BPE算法非常适合文本到文本的任务，并且可以比复制机制和和基于通用命名风格的名称拆分更好地概括训练时未见过的新单词。我们注意到我们的公式允许TFix比现有的工作捕获更多的错误。生成新的代码行来替换原有代码行，并不足以修复许多错误。这是因为正确的修复通常涉及修改该行的上下文。Hoppity饱受经典的词汇量有限的困扰。当词汇表中不存在所需的节点值时，Hoppity既不能表达也不能生成所需的定位。

2.3 微调T5以合成代码修复

我们假设一个微调数据集，由d对错误及其对应的由开发人员给出的组成。微调的目标是最小化交叉熵损失：

注意，我们在等式中的损失函数对中的所有错误类型求和，即我们一起微调所有错误类型，这也可以被视为一种多任务学习的形式，它显著扩大了数据集并利用了错误类型之间的知识转移，这项技术大大提高了TFix的准确性。未来的工作项目可以一起微调多种语言，以获得多语言代码修复模型，并受益于多语言之间的知识转移。

2.4 获取微调数据集

为了获得数据集D，我们分析了来自GitHub的大量提交，其中p和p’是提交之前和之后的程序的两个版本。获取高质量数据集的一个挑战是将错误修复提交与通过完全删除代码或其他手段来移除错误的许多不相关的提交分开，并提取与错误修复提交中的错误和修复相对应的代码部分。Algorithm 1给出了TFix的数据提取和清洗流程。

该算法从空集D开始，在Github提交C上迭代，并运行检测器以在每次提交时从文件对p和p’中获取和。然后，它检查中的错误数是否大于中的错误数。如果大于，很可能是p’修复了p中的一些错误。因此，考虑提交中包含错误修复。我们注意到，我们发现用于确定错误修正提交的这一标准在实践中比先前基于提交消息中的关键字或树编辑的数量的方法要精确得多，因为它在决策过程中利用了错误检测器。

然后，TFix调用findFixedErrors函数，通过比较和来确定一组已修复的错误,我们在这里使用了二分匹配算法。对于中每个已被修复的错误e，TFix调用computeFix函数来提取p’中的L’，并获取要添加到数据集D中的样本(e,L’)。最后，clean函数移除包含未对齐错误修复的高噪声样本。

findFixedErrors函数首先调用和之间的贪婪二分匹配过程，以识别一组在提交后仍未修复的错误。为了计算二分匹配，我们迭代所有错误对和，如果，，并且和处的代码行之间的归一化Levenstein编辑距离很小，我们使用阈值0.3，我们就接受(e,e’)作为匹配。直觉上来说，这意味着e和e’很可能是同一个错误，所以e在提交后仍未被修复。迭代结束后，ε中所有匹配的错误形成集合。最后，被修复错误的集合可以通过得到。

为了使用computeFix函数计算L’，我们利用了Myers的差异算法来计算一系列的编辑操作，每次编辑操作插入或删除程序中的一段文本，这些操作可以将p转化为p’。我们在进行编辑操作的同时跟踪在程序中是如何变换的。在编辑操作结束后，我们在的最终位置定位。最后，L’是通过取的上下文得到的。注意，可能包含新添加的行，并且由于固定的窗口大小而变得无法与对齐。对于这些情况，我们在和附近应用基于代码行的启发式搜索方法。因此，和可能会延伸几行。

为了获得T5模型的高质量数据集，我们还进行了清洗步骤，从数据集D中移除潜在的噪声样本。我们只保存从p到p’所需的编辑操作少于6次的样本。注意，由于每次编辑操作可以改变一整行代码，D中的样本仍然非常复杂。原因在于，在过滤后的样本中，错误虽然已经被提交修复，但是不能保证是无噪声的训练样本。

3 实验评估

3.1 实验设置

研究问题。在本文中，我们研究以下研究问题：

RQ1：TFix修复编码错误的准确性如何？

RQ2：与最先进的方法对比时，TFix的表现如何？

评估数据集。我们根据星数，对来自排名前50万的GitHub公共存储库的550万次提交运行了Algorithm 1，并提取了ESLint检测到的52种错误类型的修复数据集。我们发现某些错误类型的样本太多，这会使我们的数据集严重偏斜。因此，我们对这些错误类型执行了随机下采样。我们的最终数据集由个样本组成。详细统计数据如表1所示。

表1：每种错误类型的样本数量与精确匹配准确度

为了分割训练集和测试集，我们为每种错误类型随机选择10%的样本作为测试集，剩余部分进一步划分为90%用于微调，10%用于验证。为了测量数据集的质量，我们手动检查了从整个数据集中随机抽取的100个样本，并检查它们是否确实是错误的修复。我们发现其中96个是真正的错误修复，错误率位于区间[90.1，98.9]，置信水平为95%，这意味着我们的数据构建过程产生了一个具有少量噪声的高质量数据集。

此外，我们还测试了TFix在推广到修复复杂或有噪声错误的数据上的表现。为此，我们组装了另一个名为随机测试的测试集，该测试集由GitHub提交中的所有可修复错误组成，但不包含用于微调和验证的错误。

我们努力消除数据集中的重复项。对于GitHub存储库，我们删除具有相同抽象语法树的重复文件，并在提交级别上进一步应用了重复数据消除过程：对于每个文件，我们检测并丢弃了与其他提交中的更改完全重复的提交。例如，对于提交A、B和C，其中C同时执行了A和B的更改，我们将删除C，即使它可能包含其他文件中的更改。我们还确保在最终数据集中没有相同的样本。

对比方法。为了研究我们设计选择的有效性，我们研究了三个T5基线：无预训练大型T5：我们初始化了一个没有自然语言预训练的T5大型模型，并用我们的数据集从头开始训练它。每种错误类型大型T5：我们分别对每种错误类型进行了微调和测试。基础T5和小型T5：我们微调了两个较小的T5型号，基础T5和小型T5分别有2.2亿和6000万个参数。其他重要条件（例如，数据集、优化器等）对这些模型保持不变。

评估指标。我们提出了两个度量TFix准确性的指标。当且仅当修复与提交中完成的人工修复完全匹配时，精确匹配指标才认为预测是正确的。请注意，该指标提供了TFix精度的下限，因为错误可以通过多种方式修复，并且TFix可以提出不同于人工修复的正确修复。如果错误被去除并且在错误代码被预测替换之后没有引入新的错误，则错误删除指标将该预测计数为正确。我们通过对每个错误类型的修复准确率求平均值来计算平均准确率。精确匹配是一个比错误删除更严格的指标，因为它不仅要求删除错误，而且要求修复与实际提交中的修复相同。

RQ1 修复准确性

结果。我们在表2中给出了准确度结果。对于高质量数据集，TFix在精确匹配方面实现了49.3%的准确度，在消除错误方面实现了67.8%的准确度。对于随机测试集，TFix在52.5%的情况下移除了错误。接下来，我们提供每种模型变体的TFix消融研究。

表2：T5模型在高质量数据集和随机测试集上的准确率

消融研究。T5-no-pre-train的精度落后于预训练模型。这个实验有趣的结果是，在精确匹配上6.7%的结果明显更差。这表明，自然语言预训练是TFix生成正确修复程序的关键，但也表明，仅依靠代码提交可能会导致模型学习如何以人类无法做到的方式移除错误。

我们比较TFix和T5在每个错误类型的表现，以量化将所有错误类别一起微调的影响。从表2可以看出，在所有指标上，TFix的准确率都显著高于T5（>13%）。表1显示，对于几乎所有的错误类型，TFix对比T5-large-per-type在每种错误类型上表现都显著提高。这些结果证实了将所有错误类型微调在一起的重要性，以及不同类型的错误之间存在知识转移。将所有错误类型在一起微调可以增加包含目标语句的样本的大小，帮助模型更好地学习这些语句的语义，从而获得更高的准确性。

我们将TFix与T5-base和T5-small进行比较，以研究模型大小的影响。对于高质量数据集的精确匹配，TFix的准确度比T5-base高0.8%，比T5-small高10.1%。因此，从T5-small到T5-base，模型大小是一个重要因素，但从T5-base到T5-large，模型大小变得微不足道。就误差消除指标而言，三个模型中没有一个明显优于其他模型。我们选择T5-large作为TFix的模型，主要是因为T5-Large在精确匹配方面实现了最高的精度，这意味着它最擅长生成类人修复。

RQ2 对比最先进方法

结果。结果如表3所示，TFix显著优于SequenceR和CoCoNuT。SequenceR的性能比TFix差得多，因为LSTM编码器-解码器模型很小，只能覆盖有限错误集的行为。CoCoNuT的性能甚至比SequenceR还要差。CoCoNuT的原始论文学习了系综，并使用1k的波束大小为每个错误生成20k个修复。只要20k个修复中的任何一个通过了错误检查，该错误就被视为已修复。我们认为，为了使CoCoNuT有效，如此大的候选集比模型的可学习性更重要。

表3：与最先进方法的准确率对比

我们将TFix与Hoppity进行了比较，结果表明TFix在数据集质量、表现力和准确性方面显著优于Hoppity。我们首先测量了Hoppity数据集的噪声水平，我们手动检查了从Hoppity的OneDiff数据集中随机抽取的100个样本。我们选择OneDiff数据集，因为它是Hoppity使用的主要数据集。我们发现，34个样本不是错误修复，包括版本更改、名称更改、字符串更改等。OneDiff数据集的真正错误修复率位于区间[55.8，75.2]，置信水平为95%，明显低于我们的数据集。

我们还检查了我们的数据集是否考虑了比Hoppity更复杂的错误修复，即是否需要更多的编辑操作次数来表示我们数据集中的样本。为了实现这一点，我们将我们的数据集转换为Hoppity的格式。在转换过程中，我们在原始数据集中保留了相关信息：我们通过提取包含错误上下文的最小AST子树来保持错误定位，并添加错误类型作为提取子树的根。平均而言，需要大于8次编辑来表示我们的错误修复，而Hoppity的数据集最多只包含3次编辑。此外，10504个测试样本中有1300个使用UNK进行了编辑。TFix为其中393个输出了正确的修复，而Hoppity输出了61个正确的修复。我们还注意到，在Hoppity中使用BPE算法需要对其学习框架进行重大更改。

我们用他们的论文和代码中提供的超参数在转换后的数据集上训练和测试了Hoppity。Hoppity的精确匹配准确率仅为7.9%，显著低于TFix的49.3%。这并不奇怪，因为即使对于简单得多的OneDiff数据集，Hoppity也只有14.2%的Top-1准确率。如果我们考虑让Hoppity生成完整的修复程序，其准确性将更低。此外，由于正确编辑序列的搜索空间较大，Hoppity的准确率随着所需图形编辑次数的增加而显著下降：对于1到10次编辑，其准确率分别为47.2%、26.1%、7.6%、9.7%、15.6%、4.8%、10.6%、0.7%、1.4%、0.3%。对于大于10次编辑错误，其准确率为0%。TFix因为使用文本到文本转换，因此没有这样的限制。

转述：叶恒杰