这是一篇来自新加坡管理大学的文章,题目为:"Cupid: Leveraging ChatGPT for More Accurate Duplicate Bug Report Detection"。
Bug报告是用户向开发者报告bug的主要渠道。大多数软件项目使用问题跟踪系统(Issue Tracking System),如:Bugzilla、Jira和Github,来管理bug报告、跟踪bug修复的进度。当用户发现bug时,他们可以向问题跟踪系统提交bug报告。然后,开发人员会根据bug报告中的描述修复bug。然而,许多bug报告与现有bug报告重复。例如,在Lazar等人[1]构建的数据集中,重复的bug报告占系统中所有bug报告的12.67% - 23%。尽快识别重复的错误报告是至关重要的,以避免浪费开发人员的时间和精力在多次修复相同的bug上。
目前已经提出了各种重复bug报告检测(DBRD,Duplicate Bug Report Detection,目标是正确地将一个重复的bug报告链接到它的主bug报告,也就是第一个提交的关于特定bug的报告)方法。随着深度学习的快速发展,近年来提出了许多基于深度学习的方法。当bug库大到足以训练深度学习模型时,它们已经表现出了优异的性能。这些方法的训练数据集数据集的一个共同特点是:它们都在训练数据中包含超过80k的错误报告和超过10k的重复错误报告。然而,许多项目的bug库还不够大,不足以支持训练一个深度学习模型。Zhang等人[2]最近关于DBRD的基准研究也证实,当bug库仅包含较少的重复bug报告时,基于深度学习的方法的性能不及基于信息检索的方法。
最近,大语言模型,如Vicuna,LLama 2和ChatGPT,在许多自然语言处理任务中取得了出色的性能。然而,利用LLM来提高DBRD的表现并不容易。最直接的方法是直接向LLM查询两个错误报告是否重复;然而,这是不切实际的:
**(1)耗时且成本高昂。**为了获得潜在的主bug报告,我们必须将它与存储库中所有可用的bug报告进行匹配。当提交新的错误报告时,所有以前提交的错误报告都被认为是重复的候选报告。查询LLM来比较给定的bug报告和存储库中的所有bug报告是不可行的,因为LLM的响应不是即时的。虽然可以加速(例如:通过一次运行许多查询),但是对于像ChatGPT这样的LLM来说,它是基于对其API的使用进行付费的(查询越多,花钱就越多)。
**(2)忽略了库中的其他bug报告。**如果一个方法一次只比较两个错误报告,它就没有考虑存储在库中的其他bug报告的信息。因此,很难决定所有重复候选项的相对顺序,以便给出top-k结果(举个例子:一次只比较两个bug报告,就能获得比较者之间的相似性得分,而没法同时计算目标bug报告和其他bug报告之间的相似性得分,所以很难根据相似性得分返回top-k结果)。尽管除了查询ChatGPT bug报告对是否重复(分类任务)之外,还可以要求ChatGPT提供对其答案的置信度的度量(排名任务),表示为相似性得分或置信度得分。然而,如果不考虑来自其他bug报告的信息,相似性得分将会不太可靠。
**(3)LLM是用于生成内容的人工智能技术。**尽管LLM在许多NLP任务中取得了令人印象深刻的表现,但许多研究人员认为LLM只擅长语言能力,而不擅长实际推理[3,4]。因此,由于DBRD需要进行关于两个错误报告如何相互重复的推理,所以直接查询LLM是不合适的。
这篇文章的Contribution格式还蛮新颖的,值得学习:
Cupid方法的框架如图2所示,分为三个部分:(1)应用选择规则来选择需要ChatGPT处理的bug报告,(2)运行带有提示(prompt)模板的ChatGPT来获取所选bug报告的必要关键字和(3)应用REP来检索潜在的主bug报告。
(1)应用选择规则
考虑到ChatGPT的计算成本,作者并没有对测试数据集中的所有bug报告运行ChatGPT。类似地,在实践中从业者不需要对每个新提交的bug报告运行ChatGPT。为了在保持准确性的同时进一步提高效率,作者探索并提出了选择规则。这些规则基于bug报告的长度和内容,目标是优先处理REP [5]难以处理的bug报告,同时减少提供给ChatGPT的bug报告的数量。选择标准如下:
把描述长度超过n个字的bug报告视为长bug报告。通过计算训练集中描述长度的3/4分位数来获得n。之所以选择长的bug报告,是因为长的bug报告通常不简洁,包含很长的堆栈跟踪和代码片段。这些冗长的bug报告会使REP很难检索潜在的主bug报告。
使用正则表达式来匹配和选择这些错误报告。请注意,在保留了很长的bug报告之后,仍然有包含代码片段或URL的bug报告(这里不太理解,讲道理长报告集合中就应该包含存在代码片段或URL的报告)。这些bug报告中有许多是非常简短的,大部分内容是代码片段或URL。对于开发人员来说,这些信息很有用。然而,对于DBRD方法,该信息可能难以处理。之所以选择这些bug报告,是因为并非所有代码片段和URL都对REP检索潜在的主bug报告有用。Cupid也不直接删除代码片段或URL,因为需要保留bug报告的原始结构,以便ChatGPT更好地理解这种语言。然后,利用ChatGPT从这些bug报告中识别关键字。
这部分最终得到的结果是:(1)长bug报告或(2)包含代码片段或URL的bug报告。
(2) 运行带提示模板的ChatGPT
ChatGPT对提示很敏感[3],为此作者特别设置了如下提示模板以更好地发挥其能力:
该模板是为单轮对话设计的。对于每个bug报告,Cupid都会打开一个与ChatGPT的新对话。在从ChatGPT得到响应后,用返回的已识别的Summary和Description关键字替换bug报告中原来的Summary和Description,并保持bug报告的其余部分不变。
作者设计该提示模板的直觉是:bug报告者可能比ChatGPT拥有更多的专业知识和领域知识。因此,他们在报告bug时使用的语言和术语可能彼此相似,这种相似性可以被DBRD方法利用。不替换整个表达,而是选择并保留DBRD方法要处理的基本信息会更有好处。
(3)检索潜在主bug报告
考虑到在最近的一项研究[2]中显示的REP在DBRD任务中的优越性,特别是在具有典型数量问题的项目上,本文使用REP作为Cupid中的DBRD方法。
REP是7个线性特征的组合,包含:文本特征和类别(categorical)特征,如公式1所示。
其中,d是库R中的bug报告,q是查询(即,新的bug报告),是第i个特征的权重,是第i个特征。前两个特征都是文本特征,其余五个特征是类别特征。公式2显示了如何获得每个特征。
前两个特性是关于两个bug报告在Summary和Description字段上的文本相似性。这两个文本特征由在bug报告d和查询bug报告q之间计算BM25F是一个有效的文本相似性函数,用于检索有结构文档。REP的作者通过考虑查询中的词频扩展了BM25F,并提出了。
在中,Summary和Description用uni-gram表示,而在中,Summary和Description用bi-gram表示。因此,BM25F的输入由两个特征中的一元词和二元词组成。对于,它们分别是Product、Component和type的类别特征。如果d和q的相应字段值相同,则该特征的值为1,否则为0。对于,它们分别是优先级(priority)和版本的类别特征。它们通过d和q的相应字段值之间距离倒数来计算。总体而言,REP方法包含19个具有不同初始值的自由参数。这些参数通过梯度下降来调整。
至于实验数据集嘛,在这里:https://github.com/soarsmu/TOSEM-DBRD
参考文献
[1] Lazar A, Ritchey S, Sharif B. Generating duplicate bug datasets[C] //Proceedings of the 11th working conference on mining software repositories. 2014: 392-395.
[2] Zhang T, Han D G, Vinayakarao V, et al. Duplicate bug report detection: How far are we?[J]. ACM Transactions on Software Engineering and Methodology, 2023, 32(4): 1-32.
[3] Bang Y, Cahyawijaya S, Lee N, et al. A multitask, multilingual, multimodal evaluation of chatgpt on reasoning, hallucination, and interactivity[J]. arXiv preprint arXiv:2302.04023, 2023.
[4] Mahowald K, Ivanova A A, Blank I A, et al. Dissociating language and thought in large language models: a cognitive perspective[J]. arXiv preprint arXiv:2301.06627, 2023.
[5] Sun C, Lo D, Khoo S C, et al. Towards more accurate retrieval of duplicate bug reports[C]//2011 26th IEEE/ACM International Conference on Automated Software Engineering (ASE 2011). IEEE, 2011: 253-262.