这是一篇来自新加坡管理大学的文章，题目为："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.
