Transparency in Software Defect Prediction: A Dual Approach using Explainability and Tradeoff Analysis

想象一下，你是一名侦探，试图在一千名无辜公民的人群中寻找一名隐藏的叛徒。你的任务是在他们造成任何麻烦之前指出谁是那个叛徒。这正是软件工程师的日常现实，他们扮演着数字侦探的角色，搜寻代码中的“漏洞（bugs）”或缺陷。在软件工程领域，这种搜寻被称为软件缺陷预测（Software Defect Prediction）。这是一场高风险的游戏，目标是在代码崩溃之前发现坏代码。

为了玩这场游戏，工程师们使用被称为**机器学习模型（Machine Learning models）**的计算机程序。可以将这些模型想象成超级聪明的助手，它们已经阅读过过去数百万行的代码。它们观察一段新的代码，并给出一个 0 到 1 之间的“怀疑分数”。分数为 0 意味着“完全清白”，分数为 1 则意味着“罪名成立”。难点在于决定在哪里划定界限。如果你把线设得太低，可能会冤枉无辜的人（误报），从而浪费大家的时间。如果你把线设得太高，可能会让真正的叛徒溜走（漏掉缺陷），这可能是灾难性的。长期以来，大多数侦探只是使用一个标准规则：“如果分数高于 0.5，则判定有罪。”但这项新研究表明，这个标准规则可能并不准确。

---

这篇论文的核心思想：寻找完美的界限

在他们的论文**《软件缺陷预测中的透明度：一种结合可解释性与权衡分析的双重方法》**中，Nitin Sai Bommi、Umamaheswara Sharma Bhutamapuram 和 Atul Negi 指出，旧有的“0.5 规则”就像是用一顶尺寸统一的帽子去应对一群头围各异的人群。它并不适合所有人。

作者们提出了另一种玩游戏的方法。他们建议不要盲目信任默认界限，而是通过两个聪明的技巧来找到针对每种特定情况的“完美界限”。他们的目标是最大化“抓获坏人（检测概率）”与“避免错误指控（误报概率）”之间的差异。他们希望在不浪费时间在无辜旁观者身上的同时，抓住叛徒。

技巧 #1：移动球门（最优阈值）

第一个技巧是关于调整“怀疑线”的。研究人员测试了三种不同类型的侦探助手：逻辑回归（Logistic Regression）、朴素贝叶斯（Naïve Bayes）和神经网络（Neural Networks）。他们发现，对于这些模型来说，神奇数字并不是 0.5。

• 对于逻辑回归助手，最佳切入点大约在 0.35。
• 对于朴素贝叶斯，它甚至更低，在 0.3。
• 对于神经网络，则是 0.38。

把它想象成调收音机。如果你把旋钮留在中间，可能会听到杂音。但如果你将其向左或向右轻微移动，音乐就会突然变得清晰悦耳。通过将阈值下调（到 0.3 或 0.4 左右），这些模型在识别真实缺陷的同时，能更好地控制误报的数量。在对 10 个软件项目的 36 个不同版本的测试中，这种简单的调整始终优于标准方法。

技巧 #2：“如果……会怎样”的游戏（反事实解释）

第二个技巧更具魔力。作者使用了被称为**反事实解释（Counterfactual Explanations）**的技术。想象你有一张“有罪”嫌疑人（有缺陷的代码模块）的照片。模型说：“这是坏的。”现在，想象你可以问模型：“如果我改变这一个微小的细节，它会变成清白的吗？”

研究人员正是这样做的。他们提取了模型已经知道是好或坏的代码，然后问道：“什么样的微小变化会使它从好变坏，或者从坏变好？”他们利用这些“如果……会怎样”的情景创建了新的、合成的示例代码。然后，他们将这些新示例反馈给模型，以进行额外的训练。

这就像教练向球员展示一段完美的比赛视频，然后问道：“如果你差之毫厘就会错过球会怎样？”并利用这一点来教导球员如何调整。论文发现，这种方法帮助模型更好地理解数据，尽管它并不总是能击败简单的“移动球门”技巧。

他们的发现（以及没能做到的）

结果是令人期待的，但具有特定性。作者使用两个主要工具来衡量成功：

1. 漏报率（False Omission Rate, FOR）： 他们漏掉了多少真实的缺陷？（他们希望这个数值尽可能低）。
2. 节省预算百分比（Percent of Saved Budget, PSB）： 通过不对干净的代码进行测试，他们节省了多少时间和金钱？

当他们使用新的“移动球门”方法时，模型的表现优于旧方法。例如，在使用逻辑回归模型时，平均最优阈值为 0.35，并且与标准的 0.5 阈值相比，显著降低了漏掉缺陷的概率。

然而，作者谨慎地指出，这并非万能灵药。他们明确表示，虽然这些方法改善了捕捉漏洞与避免误报之间的平衡，但它们并不能解决所有问题。反事实方法（“如果……会怎样”的游戏）确实有所帮助，但它并不总是能给出最佳结果，因为模型本身在生成那些虚构示例时并不总是完美的。

他们还指出，他们的发现是基于特定的数据集（PROMISE 仓库），如果应用于完全不同类型的软件项目，结果可能会有所不同。他们并没有证明这适用于宇宙中的每一份软件，但他们确实展示了，对于他们测试的项目而言，摒弃默认的 0.5 规则是一个明智之举。

为什么这很重要

这篇论文提醒我们，在软件世界中，“一刀切”往往是一个陷阱。决定什么是漏洞、什么不是漏洞的标准方式可能过于僵化。通过简单地询问计算机：“对于这项特定工作，最好的界限在哪里？”以及通过使用“如果……会怎样”的问题来学习更多，我们可以构建出更安全、维护成本更低的软件。这是一种视角的微调，但对于在数字黑暗中搜寻漏洞的侦探们来说，这可能正是他们需要的探照灯。