sci3区代码生成 LLM-BRC: A large language model-based bug report classification framework

sci3区代码生成 LLM-BRC: A large language model-based bug report classification framework

全文总结

这篇论文提出了一种基于大型语言模型的深度学习框架漏洞报告分类框架,称为LLM-BRC。

研究背景

  1. 背景介绍: 这篇文章的研究背景是深度学习框架在构建强大深度学习系统中的重要性。然而,这些框架中的漏洞可能会带来严重的后果,影响各种应用。准确分类和理解这些漏洞对于确保框架的可靠性至关重要。
  2. 研究内容: 该问题的研究内容包括提出一种基于大型语言模型的漏洞报告分类框架LLM-BRC,并评估其在TensorFlow、MXNET和PaddlePaddle三个深度学习框架中的表现。
  3. 文献综述: 该问题的相关工作有:Jia等人分析了基于202个修复的TensorFlow漏洞;Islam等人研究了五个深度学习库中的常见漏洞类型;Du等人对TensorFlow、MXNET和PaddlePaddle的漏洞报告进行了分类。然而,现有的方法在性能上存在不足,难以在实际应用中推广。

研究方法

这篇论文提出了LLM-BRC框架。具体来说:

  • 数据准备: 从TensorFlow、MXNET和PaddlePaddle的GitHub仓库中爬取3,110个已标记的漏洞报告,包括标题、描述和评论。
  • LLM-based bug report representation: 使用OpenAI的text-embedding-ada-002模型将文本数据转换为密集的低维嵌入向量。该模型采用Transformer架构,通过96层解码器将输入转换为1,536维向量。
  • Bug report classification: 构建一个前馈神经网络(FFN)分类器,利用学习到的嵌入向量进行漏洞报告分类。FFN包含四个层:输入层、两个隐藏层和一个输出层,分别有256、128和目标类别数量的神经元。

实验设计

  • 数据集: 使用来自TensorFlow、MXNET和PaddlePaddle的1,978、1,777和355个漏洞报告,总共3,110个漏洞报告。
  • 比较方法: 选择DeepSIM作为基准方法进行比较。DeepSIM使用word2vec语义模型和卷积神经网络分类器进行漏洞报告分类。
  • 评估指标: 使用准确率、精确率、召回率和F值作为评估指标。通过K折交叉验证(K=5)进行实验。

结果与分析

  • 主要结果: LLM-BRC在所有三个深度学习框架中的分类准确率均超过92%。在TensorFlow框架中,bug/non-bug分类的准确率为92.56%,MAN/BOH分类的准确率为98.47%,ARB/NAM分类的准确率为98.75%。
  • 与DeepSIM的比较: LLM-BRC在所有四个评估指标上均优于DeepSIM。特别是在bug/non-bug分类任务中,LLM-BRC的准确率提高了69.15%,精确率提高了68.97%,召回率提高了68.15%,F值提高了69.12%。
  • 消融研究:
  • 不同组件的影响: 使用所有漏洞报告组件(标题、描述和评论)进行分类时,准确率最高。例如,在TensorFlow的bug/non-bug分类任务中,仅使用标题信息的准确率为55.59%,而使用所有组件的准确率为74.8%。
  • 分类器的影响: FFN分类器在所有三个框架中的表现最佳,特别是在PaddlePaddle框架中,其准确率比其他六个分类器高28.25%-48.97%。
  • 嵌入模型的影响: text-embedding-ada-002模型在所有三个分类任务中均优于BERT和word2vec模型。例如,在TensorFlow的ARB/NAM分类任务中,text-embedding-ada-002模型的准确率比BERT模型高44.30%。

结论

这篇论文提出了LLM-BRC框架,通过结合大型语言模型和深度学习分类器,实现了对深度学习框架漏洞报告的高效分类。实验结果表明,LLM-BRC在TensorFlow、MXNET和PaddlePaddle框架中的分类准确率分别为92.56%、94.74%和93.42%。此外,LLM-BRC在处理小样本和不平衡数据集方面表现出色。本文的研究为漏洞报告分类领域提供了新的思路和方法,具有重要的理论和实际意义。

这篇论文通过实证研究展示了LLM-BRC框架的有效性,并为未来的研究和应用提供了有价值的指导。

核心速览

研究背景

  1. 研究问题:这篇文章要解决的问题是如何准确分类和理解深度学习框架中的错误报告(bug reports),以确保框架的可靠性。这对于开发者及时采取适当措施以减轻特定bug类型的风险至关重要。
  2. 研究难点:现有的bug报告分类方法在性能上存在不足,难以在实际应用中发挥作用。主要难点包括如何有效捕捉bug报告中的语义信息和上下文信息。
  3. 相关工作:已有研究对深度学习框架中的bug进行了分类和分析,但大多采用手动分类方法。DeepSIM方法是现有最先进的基于语义信息的bug报告分类方法,但仍存在局限性。

研究方法

这篇论文提出了一个基于大型语言模型(LLM)的bug报告分类框架,称为LLM-BRC。具体来说,

数据准备:从TensorFlow、MXNET和PaddlePaddle的GitHub仓库中爬取bug报告,并使用自定义的网络爬虫工具提取标题、描述和评论等信息。

www.zeeklog.com  - sci3区代码生成 LLM-BRC: A large language model-based bug report classification framework

LLM-based bug报告表示:使用OpenAI的text-embedding-ada-002模型将自然语言文本转换为密集的低维嵌入向量。该模型采用Transformer架构,通过多头自注意力机制和前馈神经网络生成嵌入向量。公式如下:  headi=attention⁡(QWiQ,KWiK,VWiV) headi​=attention(QWiQ​,KWiK​,VWiV​)

其中,QQ、KK和VV分别表示查询向量、键向量和值向量。注意力机制的计算公式为:  Attention(Q,K,V)=softmax⁡(QKT(dk))V Attention(Q,K,V)=softmax((dk​)​QKT​)V

最终的多头注意力输出为:  MultiHead(Q,K,V)=concat⁡( head1,…, headh)WO

  1. MultiHead(Q,K,V)=concat( head1​,…, headh​)WO

解码器层的最终输出为:  DecoderLayer(y)=LN(y+MMHA(y)+MHA(y,x)+FFN(y))

  1. DecoderLayer(y)=LN(y+MMHA(y)​+MHA(y,x)+FFN(y))

bug报告分类:在三个层次上进行分类任务:首先将bug报告分为bug和非bug两类;其次将bug分为Bohrbug(BOH)和Mandelbug(MAN);最后在MAN类别中进一步区分aging-related bugs(ARB)和non-aging related Mandelbugs(NAM)。使用前馈神经网络(FFN)进行分类,网络结构包括输入层、两个隐藏层和一个输出层。

www.zeeklog.com  - sci3区代码生成 LLM-BRC: A large language model-based bug report classification framework

实验设计

  1. 数据集:从TensorFlow、MXNET和PaddlePaddle的GitHub仓库中收集了1,978个bug报告,提取了标题、描述和评论信息,共计3,110个bug报告。
  2. 比较方法:与现有的DeepSIM方法进行比较,DeepSIM是基于word2vec语义模型的bug报告分类方法。
  3. 评估指标:使用准确率、精确率、召回率和F-measure作为评估指标,通过混淆矩阵计算这些指标。

结果与分析

  1. 主要结果:LLM-BRC在所有三个深度学习框架上的分类准确率均超过92%。TensorFlow框架的分类结果最为显著,bug/非bug分类的准确率为92.56%,精确率为92.46%,召回率为93.02%,F-measure为92.73%。
  2. 消融研究

bug报告组件:所有bug报告组件的组合显著提高了分类性能,特别是在TensorFlow框架上,bug/非bug分类的准确率从单独使用标题信息的55.59%提高到74.8%。

www.zeeklog.com  - sci3区代码生成 LLM-BRC: A large language model-based bug report classification framework

分类器:FFN分类器在所有框架上的表现均优于其他六种传统机器学习分类器,特别是在PaddlePaddle框架上,bug/非bug分类的准确率提高了28.25%-48.97%。

www.zeeklog.com  - sci3区代码生成 LLM-BRC: A large language model-based bug report classification framework

嵌入模型:text-embedding-ada-002模型在所有分类任务中均优于word2vec和BERT模型,特别是在ARB/NAM分类任务中,准确率提高了44.30%。

www.zeeklog.com  - sci3区代码生成 LLM-BRC: A large language model-based bug report classification framework

总体结论

本文提出了LLM-BRC,一个基于大型语言模型的bug报告分类框架。通过使用OpenAI的text-embedding-ada-002模型捕捉bug报告的语义信息,并结合前馈神经网络进行分类,LLM-BRC在bug报告分类任务中取得了显著的高准确率(92%到98.75%)。研究还探讨了影响分类性能的各种因素,为改进bug报告分类提供了有价值的指导。

论文评价

优点与创新

  1. 提出了一个新的分类框架:LLM-BRC利用OpenAI的最新嵌入模型text-embedding-ada-002,提出了一个基于大型语言模型的bug报告分类框架,显著提高了bug报告的分类准确率。
  2. 高准确率:在TensorFlow、MXNET和PaddlePaddle三种深度学习框架的bug报告分类任务中,LLM-BRC实现了92%到98.75%的准确率,相比现有方法有显著提升。
  3. 全面的影响分析:研究了不同bug报告组件和不同模型对分类结果的影响,进一步推动了该方法的实际应用。
  4. 开源数据和方法:为了促进bug报告分类研究,作者将数据和开源方法发布在GitHub上,供其他人访问和使用。
  5. 详细的实验设置:介绍了实验的具体设置,包括数据集、比较方法和评估指标,确保了实验的可重复性和可比性。

不足与反思

  1. 数据集的限制:尽管使用了TensorFlow、MXNET和PaddlePaddle的bug报告数据,但这些数据集的规模和多样性可能限制了模型的泛化能力。未来的研究可以考虑收集更多来自不同框架和领域的bug报告数据。
  2. 模型的解释性:深度学习分类器的黑箱特性使得解释其决策过程变得困难,这可能影响分类结果的可信度。未来可以研究一些方法来解释深度学习模型的分类过程。

关键问题及回答

问题1:LLM-BRC框架在处理bug报告时,如何利用OpenAI的text-embedding-ada-002模型捕捉语义信息?

LLM-BRC框架通过使用OpenAI的text-embedding-ada-002模型将自然语言文本转换为密集的低维嵌入向量来捕捉语义信息。具体步骤如下:

  1. 文本预处理:首先,从GitHub仓库中爬取bug报告,并提取标题、描述和评论等信息。
  2. 嵌入生成:使用text-embedding-ada-002模型对预处理后的文本进行处理。该模型采用Transformer架构,通过多头自注意力机制和前馈神经网络生成嵌入向量。每个输入bug报告被分割成tokens,然后通过多个解码器层进行处理。
  3. 嵌入向量表示:经过解码器层处理后,生成一个1,536维的嵌入向量。这个嵌入向量包含了bug报告的语义信息和上下文信息,可以作为后续分类任务的输入。

问题2:在LLM-BRC框架中,如何进行bug报告的层次化分类?

LLM-BRC框架在三个层次上进行bug报告的层次化分类:

  1. 第一层分类:将bug报告分为bug和非bug两类。这一分类的目的是过滤掉与bug无关的报告,如新功能请求、文档问题和编译时错误等。
  2. 第二层分类:将bug分为Bohrbug(BOH)和Mandelbug(MAN)。BOH是指在规定条件下一致出现的bug,而MAN是指即使在精确条件下也不一定能重现的bug。
  3. 第三层分类:在MAN类别中进一步区分aging-related bugs(ARB)和non-aging related Mandelbugs(NAM)。ARB是指导致应用程序或其系统环境内错误累积的bug,从而导致失败率增加或性能下降;NAM则是指不属于ARB的MAN类别bug。

问题3:LLM-BRC框架在实验中的评估指标有哪些?这些指标如何反映分类器的性能?

LLM-BRC框架在实验中使用了以下评估指标:

  1. 准确率(Accuracy):正确预测的实例占总实例的比例。它反映了分类器整体的准确性。
  2. 精确率(Precision):在所有被分类为某一类的实例中,真正属于该类的实例所占的比例。它反映了分类器在预测正类时的准确性。
  3. 召回率(Recall):在所有实际属于某一类的实例中,被正确预测为该类的实例所占的比例。它反映了分类器在识别正类时的全面性。
  4. F-measure:综合精确率和召回率的指标,通过调和二者的平均值来评估分类器的性能。它提供了一个平衡的评估结果,考虑了精确率和召回率之间的权衡。

这些指标通过混淆矩阵计算得出,能够全面反映分类器的性能。高准确率表明分类器在整体上能够准确分类bug报告;高精确率表明分类器在预测正类时具有较高的准确性;高召回率表明分类器在识别正类时能够覆盖大部分实际正类实例;高F-measure值则表明分类器在精确率和召回率之间达到了较好的平衡。

www.zeeklog.com  - sci3区代码生成 LLM-BRC: A large language model-based bug report classification framework




期刊名综合评分中国科学院分区学科领域SCI收录是否OA录用比例审稿周期近期
文章0963-9314

SOFTWARE QUAL J5.1

h-index:37

CiteScore:4.90

3区大类:计算机科学

小类:计算机:软件工程

SCIENo容易>12周,或约稿15461                  (去

/1页)

www.zeeklog.com  - sci3区代码生成 LLM-BRC: A large language model-based bug report classification framework

Read more

敏捷开发系列学习总结(18)——Scrum Master的情景领导力模型

敏捷开发系列学习总结(18)——Scrum Master的情景领导力模型

几年前,我把几个高尔夫球打到湖里了,一起打球的朋友给了我一些建议。现在那位朋友打高尔夫球已经不比我强了,但他仍在没完没了地建议。他说,“问题是,你得把球打得更远。”他这样说还不如告诉我,“问题是,你打了很多次才把球打进球洞”。我当然需要打得更远。但怎么做到呢?类似的,你们可能也被告诫过——ScrumMaster、敏捷教练或敏捷项目经理都可能告诫你——敏捷项目管理是要领导团队而非管理团队。然而,指导ScrumMaster“要领导而非管理”,并不是什么有信息含量的指导。这相当于告诉高尔夫球手要把球打得更远。这是正确然而没有可操作性的指导。如何才能最好地领导那些想变得敏捷的团队,ScrumMaster们想理解这一点,首先要理解团队需要什么样的领导力,然后看看提供领导力的四种不同方法。这源于保罗·赫塞(Paul Hersey)的情景领导力模型。赫塞的模型为要采用新工作方式的团队,描述了四个就绪级别,如图1所示: 根据赫塞的理论,领导者们需要调整其行为以匹配团队的就绪级别。换句话说,ScrumMaster在与有能力和有意愿的团队合作时采用的团队领导方式,跟其与无能力、无意愿的团队合作时是不同的

By Ne0inhk
项目管理学习总结(19)——一百人研发团队的难题:研发管理、绩效考核、组织文化和OKR

项目管理学习总结(19)——一百人研发团队的难题:研发管理、绩效考核、组织文化和OKR

什么是研发团队?简单的说,你熟悉的那帮穿格子衬衫,以程序员为核心组成的团队,就是研发团队。本来,你以为格子男们是很乖很闷骚的那种,管理和协作起来比销售和业务简单很多,而实际情况是.......格子男们并不那么容易管理,面向代码世界的复杂度,可能远比面向财物世界的复杂度还要高。作为致力于团队协作的公司,我们研究了很多国内和海外牛逼公司的研发模式和研发管理,例如OKR在谷歌、Facebook的应用,Uber的高效会议制度,阿里的绩效体系,腾讯的产品流程。除了在自身团队做了N次不同的试验和反思,我们也想将很多不错的经验分享给用户。而要谈清楚方法,就先了解清楚问题,研发管理之所以令人头疼,核心的问题无外乎以下一些方面。 研发管理的典型问题 1. 难以KPI化和考核 任正非有句名言:钱分好了,管理的大部分问题就解决了。我对此深表同意,可问题是,怎么能分好钱确实非常考验能力、经验和智力的。研发之难,恰恰难在工作本身无法KPI化,所有那些试图KPI化工程师和码农的做法,最终结果都啼笑皆非、面目可憎、吃力不讨好。 在我过去经历,还有客户实际的研发管理里,试图KPI化研发工作一直是不同团队努力的

By Ne0inhk
科普文:微服务之服务网格Service Mesh

科普文:微服务之服务网格Service Mesh

一、ServiceMesh概念 背景 随着业务的发展,传统单体应用的问题越来越严重: * 单体应用代码库庞大,不易于理解和修改 * 持续部署困难,由于单体应用各组件间依赖性强,只要其中任何一个组件发生更改,将重新部署整个应用,而频繁的部署将增加服务宕机的风险,因此频繁地进行部署几乎不可能 * 扩展应用困难,单体应用只能从一个维度进行扩展,即很容易通过增加实例副本提供处理能力。另一方面,单体应用各个组件对资源的使用情况需求不同,一些是CPU密集型,另一些是内存密集型,但是不能独立地扩展单个组件 * 阻碍快速开发,随着公司业务的发展,单体服务框架变得更加庞大,更多的部门将会参与系统的开发,但是各个部门又不能独立开发、维护相应的模块,即使其中一个部门完成相应的更新,仍然不能上线,因此需要花费更多时间在部门间协调和统一。还有,需要增加新的功能时,单体应用最初的设计限制开发人员灵活选择开发语言、工具等,导致新功能上线慢 * 迫使开发人员长期专注于一种技术栈,由于单体应用本身设计的原因,后期引入新的技术栈需要遵循最开始的设计,因此存在非常大的局限性、挑战性,否则可能需要重写整个框架

By Ne0inhk
分库分表学习总结(6)——分库分表?选型和流程要慎重,否则流程会失控!

分库分表学习总结(6)——分库分表?选型和流程要慎重,否则流程会失控!

数据库中间件之分库分表 恭喜你,贵公司终于成长到一定规模,需要考虑高可用,甚至分库分表了。但你是否知道分库分表需要哪些要素?拆分过程是复杂的,提前计划,不要等真正开工,各种意外的工作接踵而至,以至失控。 本文意图打开数据库中间件的广度,而不考虑实现深度,至于库表垂直和水平分的概念和缘由,不做过多解释。所以此文面向的是有一定研发经验,正在寻找选型和拆分流程的专业人士。 切入层次 以下,范围界定在JAVA和MySQL中。我们首先来看一下分库分表切入的层次。 ① 编码层 在同一个项目中创建多个数据源,采用if else的方式,直接根据条件在代码中路由。Spring中有动态切换数据源的抽象类,具体参见 AbstractRoutingDataSource。 如果项目不是很庞大,使用这种方式能够快速的进行分库。但缺点也是显而易见的,需要编写大量的代码,照顾到每个分支。当涉及跨库查询、聚合,需要循环计算结果并合并的场景,工作量巨大。 如果项目裂变,此类代码大多不能共用,大多通过拷贝共享。长此以往,码将不码。 ② 框架层 这种情况适合公司ORM框架统一的情况,但在很多情况下不

By Ne0inhk