基于BERT的GitHub问题报告分类
ABSTRACT
在开源项目中问题跟踪是软件开发中不可或缺的一部分。GitHub是一个常用的软件管理工具，它提供了自己的问题跟踪系统。每个问题都可以有各种标签，这些标签由项目的开发者手动分配。然而，手动标注软件报告是一项耗时且容易出错的工作。在本文中，我们描述了一种基于BERT的分类技术，将问题自动标记为问题、错误或改进。我们使用一个数据集来评估我们的方法，该数据集包含来自GitHub上的真实开源项目的800,000多个标记的问题。我们的方法对报告的问题进行分类，平均F1分数为0.8571。我们的技术优于之前基于FastText的机器学习技术。
1 INTRODUCTION
软件维护是软件开发生命周期中的一个重要组成部分，以减轻漏洞，修复错误，并根据用户的需求来发展软件[5, 16]。在软件开发过程中，问题跟踪系统（ISTs）经常被用来帮助软件维护和进化。这些系统允许用户创建新的条目，报告一个错误，要求一个新的功能，或提出关于项目的问题。软件工程师利用这些条目中提供的信息来了解报告的性质，如果是实际的bug，则缩小需要修改的文件列表来修复问题[19]。开发人员也使用IST来跟踪开放的问题以从报告者那里获得更多的信息，并讨论潜在的错误修复方案（包括确定要开发的问题/功能的优先次序）。GitHub是一个广泛使用的项目管理软件，提供了一个内置的问题跟踪系统，在GitHub上用户可以提出问题，建议新功能，并指出可能的错误。由于这些IST可以对公众开放，开发者需要对新条目进行分流，以了解报告的性质（是否是一个实际有效的bug，一个功能，或者仅仅是一个问题），从而分配一个自定义标签[3]。然而，开发人员会发现，特别是对于一个受欢迎的项目来说，手动标注问题是很困难的。这个手动过程可能是容易出错的而且很耗时[6]。在本文中，我们描述了一个基于BERT的模型来预测一个问题的类型。我们使用了一个训练集，包括从真实的开源项目中提取的超过700,000个标记的问题报告，以及一个包含80,518个问题的测试集来评估我们的解决方案。这个数据集是由NLBSE'22工具竞赛的组织者提供的[7]。我们的方法取得的最高F1分数是0.8586，超过了基线模型的F1分数（0.8162）。我们的实现可以在GitHub上找到：https://github.com/s2e-lab/BERTBased-GitHub-Issue-Classification。本文的组织结构如下。第2节描述了GitHub问题报告的分类方法。第3节介绍结果。第4节描述了当前预测GitHub问题报告的最新进展。最后，第5节总结了本文的未来方向。
2 BERT-BASED ISSUE TYPE CLASSIFICATION
我们训练并调整了一个多类分类器来自动标记GitHub问题。图1展示了我们的方法的概况。下面几个小节讨论了数据集、预处理和调整步骤，以及训练和评估程序。
图1该方法的概述
2.1 Dataset
该数据集包含803,417份从真实的GitHub项目中收集的有标签的问题报告。每个条目都包含以下元数据：
标签：它表示报告的性质，可以是下列之一：错误、改进和问题。
问题标题：一个简短的描述性句子，一目了然地指出该问题的内容。
问题正文：每个报告都必须包含一个问题主体，其中包括解释问题目的的描述。这可以包括任何可能有助于解决问题的细节。
问题URL：在GitHub上访问该报告的URL。
存储库URL：每个问题都与一个GitHub仓库相关联。这个元数据存储了远程GitHub仓库的链接。
创建时间戳：报告创建时的时间戳。
作者关联：它描述了问题创建者与仓库的关系。有五种类型的作者关联。所有者、合作者、贡献者、成员、无。
该数据集被NLBSE'22工具竞赛的组织者分成训练集和测试集[7]。训练集包含722,899份（90%），测试集包含80,518份（10%）总标签的问题报告。我们把训练集分成新的训练集和验证集。新的训练集包含之前训练集的85%，15%的数据在验证集中。我们使用scikit-learn[14]中的train_test_split函数，我们重新洗牌数据，并以分层的方式进行分割，因为我们的数据集是不平衡的，所以使用类标签。表1中给出了数据集的分布。
表1 数据集分布
2.2 Preprocessing
在训练模型之前，我们对数据进行了预处理并固定了模型的超参数。本节讨论了数据预处理步骤和超参数的细节（即预训练模型、优化器和调度器）。
2.2.1 文本清理和特征提取
一个GitHub问题包含一个标题和一个详细的描述。一个问题的描述可能包含代码段或输出的屏幕截图。例如，图2显示了一个来自Facebook的Flow仓库的GitHub问题，其中包含代码段。因此，我们需要在编码前对数据进行清理。正如之前在第2.1节所解释的，每个问题有七个元数据，其中一个是标签。我们认为问题标题和问题正文是六个特征中的主要特征。首先，我们将这两个特征（标题和正文）串联成一个新的元数据，我们称其为问题数据。然后，我们使用Gensim库来删除问题数据中的重复空白字符（即空格、制表符和换行符）。此外，我们用空格替换了制表符和换行符。这个经过处理的问题数据被用作我们模型的特征。
图2 GitHub问题与来自Facebook/flow的bug标签 1.仓库名称，2.问题标题，3.作者手柄和头像，4.问题正文，5.标签
2.2.2 编码
为了使用预训练的BERT模型，必须将特征数据划分为标记，然后将其映射到标记器词汇中的各自索引。我们使用了BertTokenizer的实现，它可以在Hugging Face的转化器[18]包中找到。我们使用'bert-base-uncased'预训练模型[4]对我们的问题数据进行标记。bert-base-uncased "模型是使用掩蔽语言建模（MLM）目标在英语中训练的。这个模型是不分大小写的（也就是说，它对大小写不敏感）。例如，它不区分 "issue "和 "Issue"。BERT是一个预训练的模型，需要特定格式的输入数据。因此，我们需要以下项目[11]。
[SEP]：这个标记标志着一个句子的结束或两个句子之间的分离
[CLS]：这个标记用在我们文本的开头，用于分类任务，但无论你的应用是什么，BERT都期望它。
标记：它符合BERT中使用的固定词汇。
Token ID：它是为BERT的标记器所产生的标记。
掩码ID：它表明序列中哪些元素是令牌，哪些是填充元素。
段落ID：它区分了不同的句子。
位置嵌入：它显示序列中的标记位置。
我们使用BertTokenizer的batch_encode_plus方法来处理之前描述的特定格式。我们用这个方法来提取注意力掩码，参数如下：
add_special_token被设置为true，以编码特殊标记；
return_attention_mask被设置为true，以获得注意力掩码；
padding被设置为'longest'，以填充到批次中最长的序列；
truncation被设置为true，以截断到模型可接受的最大输入长度；
return_tensors被设置为'pt'，以获得PyTorch tensors作为回报值。
我们使用token ids（input_ids）和attention mask来创建一个TensorDataset，随后将其输入DataLoader来训练和评估模型。数据加载器被配置为随机抽样，批次大小等于四。虽然BERT论文的作者建议使用等于16或32的批处理大小[4]，但我们的GPU有内存限制，在使用推荐的大小时造成内存不足的错误。因此，我们使用较短的批次大小来解决这个内存限制，代价是增加训练时间。
2.2.3 预训练模型
我们使用了谷歌AI[4]的BERT预训练模型。使用Transformer[17]的双向训练进行语言建模是BERT的基本技术突破，这与以前的努力形成了鲜明的对比，以前的努力是从左到右看一个文本序列，或者从左到右和从右到左的组合训练。[12]. 研究结果表明，与单一方向的语言模型相比，双向训练的语言模型可以更好地理解语言环境。在我们的工作中，我们首先改变预训练的BERT模型来提供分类输出。然后，我们在我们的数据集上不断训练模型，直到完整的端到端模型适合我们的目标。我们使用了来自Hugging Face的BertForSequenceClassification，这是标准的BERT模型，上面放置了一个单一的分类层，我们采用它作为文档分类器。预训练的BERT模型和额外的未训练的分类层在我们的数据集上得到训练。我们利用预训练的模型 "bert-base-uncased"，这是指只有小写字母的版本（"uncased"）。因为我们不希望模型返回注意力权重和所有隐藏状态，所有我们在初始化预训练模型时禁用了这些标志。在初始化模型后，我们固定了我们的优化器和调度器。
2.2.4 优化器
我们使用AdamW[10]优化器进行训练。我们使用了HuggingFace中带有权重衰减修复的Adam算法的实现。我们使用1e-5作为学习率（lr），1e-8作为eps参数，这是一个非常小的数字，以防止执行中出现除以0的情况。
2.2.5 学习率表
学习率计划是一个超参数，它在历时或迭代之间改变学习率，以最小化模型的损失。我们使用了HuggingFace的线性计划与预训练实现。它创建了一个学习率的时间表，从优化器中设置的初始lr线性下降到0，在一个热身期之后，它从0线性增加到优化器中固定的初始lr。
2.3 Training
在训练阶段，我们使用先前创建的数据加载器来解压这批数据，每个张量被复制到GPU上。在清除任何先前计算的梯度后，我们进行了一次前向传递。在这个步骤中，模型在激活前提供了损失和对数作为输出。然后，我们进行后向传递来计算梯度。我们还将梯度的标准值减小为1.0。这是为了帮助防止 "梯度爆炸 "问题[15]。然后，我们执行优化器的步骤，根据梯度和学习率等来决定如何修改参数。最后，我们执行调度器的步骤来更新学习率。每次迭代后，我们通过计算验证损失来计算平均训练损失和模型在验证集中的表现。我们保存了模型状态，以便在训练集上评估模型。由于BERT的作者建议有2-4次迭代，我们有4次迭代进行训练。
2.4 Evaluation
我们用以下指标来评估我们的模型：
Precision（P）：它的计算方法是用正确预测标签的记录数除以该类中预测的观察值总数。计算方式为：
其中TP（真阳性）是指标签被正确预测的记录数量。相反，FP（假阳性）表示标签被错误预测的记录数。
Recall（R）：它是通过将A中成功预测的观察值的数量除以相应类别的观察值的总数来计算每个组A。计算方式为：
其中FN（假阴性）是指A类中被错误地预测为其他标签的观察值的数量。
F1-Score（F1）：F1分数通过取其平均值将分类器的Precision和Recall合并为一个指标。计算方式为：
我们计算了每个类别的精确度、召回率和F1分数。由于数据中存在阶级不平衡，我们使用微平均法作为跨阶级的聚合方法来计算全局分数。
2.5 Implementation Details
我们在一个由双十二核2.2GHz英特尔至强处理器组成的计算节点上运行我们的训练工作--共24个核心，128GB内存，以及4个NVIDIA GeForce GTX 1080 Ti GPU加速器。我们使用单核和一个GPU来训练我们的模型。训练一次迭代大约需要18个小时。我们使用PyTorch[13]作为深度学习框架，以及HuggingFace的标记器、预训练模型、优化器和调度器。我们使用了Scikit-learn[14]的评估矩阵实现。
3 RESULTS
我们使用BERT预训练的模型来调整我们的数据集，将GitHub问题报告分为三类。我们将我们的结果与使用FastText[2]的基线方法进行比较。表2总结了我们的结果。我们使用微平均法作为跨类聚合方法来计算全局分数。为此，精确度（P）、召回率（R）和F1分数（F1）的数值相同，其中最高值为0.8586，平均值为0.8571。我们的模型一直优于使用FastText的基线模型。就F1得分而言，它在每个类别都取得了更好的结果。在对被标记为问题的问题进行分类方面，它的表现尤其优于基线方法。
表2 FastText与我们的基于BERT的模型之间的结果比较
4 RELATED WORK
Kallis等人[9]使用FastText[2]通过使用问题标题和描述作为特征来预测GitHub问题的类型。他们建立了Ticket Tagger，这是一个帮助开发人员分配问题类型[8的]GitHub应用程序。他们通过对平衡集的训练和对非平衡集的测试，对错误、改进和问题的F1得分分别达到0.75、0.74和0.48。Artmann等人[1]研究了使用线性回归（LR）、卷积神经网络（CNN）、循环神经网络（RNN）、随机森林（RF）和k-近邻（KNN）算法对GitHub问题报告进行多标签文本分类。他们使用了38,000个训练行数据集，以及一个包含约12,000个行的测试集。他们将他们的数据集分成三个具有不同标签的小数据集。CNN算法在每个数据集都取得了最高的F1分数。
Fan等人[6]在GitHub问题报告的大规模数据集中研究了基于文本的分类方法。四种不同的机器学习分类器（即支持向量机-SVM、Naive Bayes、Logistic Regression和Random Forest）使用GitHub中的80个流行项目进行了评估，这些项目包括大约252,000个问题。他们将这些问题标记为两类：错误和非错误。他们引入了一个基于F1分数的新矩阵，平均F值为favg，错误（非错误）的F值为fbug（fnonbug），而错误（非错误）的数量为nbug（nnonbug）。
他们观察到，基于文本的分类方法可以达到69. 7%到98.9%的平均F-measure（按上面公式计算）在他们的数据集上。他们还发现，与其他典型的分类器相比，SVM分类器是最有效的方法。
5 CONCLUSION
在软件维护过程中，自动的问题类型分类是非常有帮助的，特别是在许多用户可以打开问题的开源项目中。本文讨论了一种基于BERT的方法，将问题自动标记为问题、错误或改进。
我们的模型达到了0.8586的F1分数（平均），表明它可以用来预测问题报告的类别，以减少人工工作。在未来，我们的目标是用更大的数据集来改进我们的方法，特别是对带有问题标签的问题报告。这种方法可以作为GitHub的一个扩展被整合。
REFERENCES
[1] Daniel Artmann. 2020. Applying machine learning algorithms to multi-label text classification on GitHub issues.
[2] Piotr Bojanowski, Edouard Grave, Armand Joulin, and Tomas Mikolov. 2017. Enriching Word Vectors with Subword Information. arXiv:1607.04606 [cs.CL]
[3] Javier Luis Cánovas Izquierdo, Valerio Cosentino, Belén Rolandi, Alexandre Bergel, and Jordi Cabot. 2015. GiLA: GitHub label analyzer. In 2015 IEEE 22nd International Conference on Software Analysis, Evolution, and Reengineering (SANER). 479–483. https://doi.org/10.1109/SANER.2015.7081860
[4] Jacob Devlin, Ming-Wei Chang, Kenton Lee, and Kristina Toutanova. 2018. BERT: Pre-training of Deep Bidirectional Transformers for Language Understanding. CoRR abs/1810.04805 (2018). arXiv:1810.04805 http://arxiv.org/abs/1810.04805
[5] Andrea Di Sorbo, Giovanni Grano, Corrado Aaron Visaggio, and Sebastiano Panichella. 2021. Investigating the criticality of user-reported issues through their relations with app rating. Journal of Software: Evolution and Process 33, 3 (2021), e2316.
[6] Qiang Fan, Yue Yu, Gang Yin, Tao Wang, and Huaimin Wang. 2017. Where Is the Road for Issue Reports Classification Based on Text Mining?. In 2017 ACM/IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM). 121–130. https://doi.org/10.1109/ESEM.2017.19
[7] Rafael Kallis, Oscar Chaparro, Andrea Di Sorbo, and Sebastiano Panichella. 2022. NLBSE’22 Tool Competition. In Proceedings of The 1st International Workshop on Natural Language-based Software Engineering (NLBSE’22).
[8] Rafael Kallis, Andrea Di Sorbo, Gerardo Canfora, and Sebastiano Panichella. 2019. Ticket Tagger: Machine Learning Driven Issue Classification. In 2019 IEEE International Conference on Software Maintenance and Evolution (ICSME). 406–409. https://doi.org/10.1109/ICSME.2019.00070
[9] Rafael Kallis, Andrea Di Sorbo, Gerardo Canfora, and Sebastiano Panichella. 2021. Predicting issue types on GitHub. Science of Computer Programming 205 (2021), 102598. https://doi.org/10.1016/j.scico.2020.102598
[10] Ilya Loshchilov and Frank Hutter. 2019. Decoupled Weight Decay Regularization. arXiv:1711.05101 [cs.LG]
[11] Chris McCormick and Nick Ryan. 2019. Bert word embeddings tutorial. https://mccormickml.com/2019/05/14/BERT-word-embeddings-tutorial/#2- input-formatting
[12] Oren Melamud, Jacob Goldberger, and Ido Dagan. 2016. context2vec: Learning Generic Context Embedding with Bidirectional LSTM. In Proceedings of The 20th SIGNLL Conference on Computational Natural Language Learning. Association for Computational Linguistics, Berlin, Germany, 51–61. https://doi.org/10.18653/ v1/K16-1006
[13] Adam Paszke, Sam Gross, Francisco Massa, et al. 2019. PyTorch: An Imperative Style, High-Performance Deep Learning Library. In Advances in Neural Information Processing Systems 32, H. Wallach, H. Larochelle, A. Beygelzimer, F. d'Alché-Buc, E. Fox, and R. Garnett (Eds.). Curran Associates, Inc., 8024– 8035. http://papers.neurips.cc/paper/9015-pytorch-an-imperative-style-highperformance-deep-learning-library.pdf
[14] Fabian Pedregosa, Gaël Varoquaux, Alexandre Gramfort, et al. 2018. Scikit-learn: Machine Learning in Python. arXiv:1201.0490 [cs.LG]
[15] George Philipp, Dawn Song, and Jaime G. Carbonell. 2018. The exploding gradient problem demystified - definition, prevalence, impact, origin, tradeoffs, and solutions. arXiv:1712.05577 [cs.LG]
[16] S Shylesh. 2017. A study of software development life cycle process models. In National Conference on Reinventing Opportunities in Management, IT, and Social Sciences. 534–541.
[17] Ashish Vaswani, Noam Shazeer, Niki Parmar, Jakob Uszkoreit, Llion Jones, Aidan N. Gomez, Lukasz Kaiser, and Illia Polosukhin. 2017. Attention Is All You Need. arXiv:1706.03762 [cs.CL]
[18] Thomas Wolf, Lysandre Debut, Victor Sanh, Julien Chaumond, et al. 2020. Transformers: State-of-the-Art Natural Language Processing. In Proceedings of the 2020 Conference on Empirical Methods in Natural Language Processing: System Demonstrations. Association for Computational Linguistics, Online, 38–45. https://www.aclweb.org/anthology/2020.emnlp-demos.6
[19] Thomas Zimmermann, R. Premraj, Jonathan Sillito, and Silvia Breu. 2009. Improving Bug Tracking Systems. 247 – 250. https://doi.org/10.1109/ICSE-COMPANION. 2009.5070993