Explainable AI for Software Engineering 论文阅读

摘要

软工项目的成功很大程度上依赖于一些复杂的决策，比如开发者该先做什么，谁该来做这个任务，这个软件系统是否足够可靠等。而这些决策的失误的代价是极大的。于是，AI技术被广泛地应用于软件分析工具以及用来改善决策，提高生产力和软件质量的技术。但是，这些AI模型的预测仍然不够有效和可行。而大部分人都在努力提高AI的准确性，却很少有人关注其可解释性。

Part 1 用于SE的AI

AI4SE关注于使用AI和数据分析技术来从前所未有的大量软件数据中获取有用的信息。很多软件公司现在使用很强大的AI技术来做数据驱动的工程决策并支撑软工任务，像是软件缺陷预测、工作量估算、任务优先排序等。
我们需要可解释的AI的原因有三点

• 首先，软件相关工作人员并不理解软件分析系统做出某个预测的理由，从而导致其不信任预测结果，进而阻碍了这些系统的使用。
• 其次，软件相关工作人员很容易被这些软件分析系统做出的预测影响，比如某位员工是否会因为这些系统发现他引入了一个缺陷而被解雇？这与隐私保护的相关法律相冲突。因此软件分析系统给出的非公正决策将可能导致灾难性的后果。
• 最后，在有关缺陷预测的相关研究中，只有5%的研究使用可解释的AI技术生成了局部解释（local explanations）。由此可见，最近可解释的AI已经开始在SE中应用了，但是还处于研究阶段。
  为了解决这些挑战，我们需要将可解释的AI应用于SE中。

Part 2 可解释的缺陷预测模型

该模型有如下目标：

• 生成详细的预测来帮助开发者定位到哪几行代码风险最高，从而帮助开发者高效地进行软件质量保证工作。
• 为每一个预测生成解释，从而帮助开发者理解为什么一个文件被预测为有缺陷的。
• 生成可行的指导来帮助管理者指定合适的改进计划。

帮助开发者定位哪些代码行的风险最高

• 动机
  传统的软件缺陷预测被用来预测哪些文件可能在未来产生缺陷。但是，文件中的缺陷代码的比例是非常低的，只有1%-3%。所以，传统的缺陷预测还不够实用。但是，在行这个级别上是没有特征的，所以行级缺陷检测挑战性极高。
• 方法
  为了解决以上问题，作者首先使用了LIME的不可知模型技术来解释文件级缺陷预测。并且在这个过程中，作者通过随机森林分类的文本特征构建了文件级的缺陷预测模型，然后对于每个预测结果，使用LIME来解释这个预测。如此这般，得出了哪些token和哪些行使得这个文件被预测为有缺陷的，从而将其用于帮助开发者定位有风险的代码行。
• 结果
  结果显示这个方法能够正确地识别出一个文件中实际有缺陷的代码中的61%，表明这个方法能够帮助开发者在保证软件质量保证工作中减少52%的花费在没问题代码上的时间，同时能够准确地识别出61%的有缺陷代码行。

帮助开发者理解为什么一个文件被预测为有缺陷的

• 动机
  传统的缺陷预测模型能够帮助开发者预测哪个文件是有缺陷的，但是缺少对该预测的解释，从而导致了开发者对这些预测的不信任，进而妨碍了预测模型的应用。
• 方法
  与上一个方法类似，作者使用了LIME来解释文件级的缺陷预测。其中，作者构建了一个使用随机森林分类的传统软件特征（文件行数、代码复杂度、编辑该文件的人员数）训练的文件级缺陷预测模型。对于每个预测，应用LIME来进行解释。这个方法帮助我们了解了哪些特征使得预测成立，并且帮助开发者理解了为什么一个文件被预测为有缺陷的。
• 结论
  预测结果显示文件有70%的风险评级，并且给出了三条权重最高的具体的风险原因。

帮助管理者构建软件质量改进计划

• 动机
  传统的软件缺陷预测只能生成预测并通过ANOVA分析或者随机森林的特征权重来提供全局的理解（understanding at the global level）。然而，这些预测不够有效，开发者并不知道该如何做或不该如何做来提高软件的质量。
• 方法
  类似上一个方法，作者使用了一个基于规则的不可知模型技术来为每个预测生成一个基于规则的解释。其中，作者构建了一个文件级的缺陷检测模型，这个模型使用了通过随机森林分类的传统软件特征（代码行数，代码复杂度，参与编辑文件人数）进行训练。对于每一个预测，作者使用了要给叫做LoRMikA的不可知模型技术来生成两种可行的指导（开发者该做什么以及不该做什么）。
• 结果
  模型成功对降低风险分别给出了具体的两类建议。

总结

• 可解释的AI对于软件工程十分重要，但是仍处于研究阶段。
• 通过以上三个成功的案例，证实了可解释的AI能够在软件工程中为预测提供解释，也能为开发任务提供可行的指导。