Page 238 - 《软件学报》2021年第7期

2156 Journal of Software 软件学报 Vol.32, No.7, July 2021

Table 1 Scores of each model under different vocabulary size
表 1 不同词库大小下各模型的得分
词库大小 评估方法 Hybrid-DeepCom CodePtr-PGN CodePtr
C-BLEU 37.14 36.68 40.11
5 000 S-BLEU 35.47 35.18 39.24
METEOR 48.06 48.01 50.86
C-BLEU 40.27 40.93 43.14
10 000 S-BLEU 38.98 39.49 42.41
METEOR 50.85 51.51 53.33
C-BLEU 41.73 44.30 47.94
30 000 S-BLEU 40.92 43.72 47.76
METEOR 52.21 54.30 57.00
C-BLEU 40.45 42.74 42.02
50 000 S-BLEU 39.49 42.27 41.50
METEOR 51.42 53.37 52.84

可以看到,在词库大小为 5 000~30 000 时,CodePtr 的得分明显高于前两个模型,在词库大小为 50 000 时与
CodePtr-PGN 接近,两者均高于 Hybrid-DeepCom.CodePtr-PGN 与 Hybrid-DeepCom 相比,两者在词库大小为
5 000 时得分相近,在 10 000~50 000 时前者高于后者.
Hybrid-DeepCom、无指针生成网络的 CodePtr 和 CodePtr 的参数数量分别为 25.64M、34.24M 和 39.37M.
在模型的运行开销方面,在词库大小为 30 000 的情况下,Hybrid-DeepCom 在第 18 轮由于达到了早停条件而终
止训练,总运行时长约为 23.5 小时;CodePtr-PGN 在第 17 轮终止了训练,总运行时长约为 27.5 小时;CodePtr 则在
第 17 轮终止了训练,总运行时长约为 26.5 小时.我们将在下面的小节中回答所提出的 3 个研究问题.
3.4.2 RQ1:加入 Source Encoder 是否可以提升模型的性能?
之前我们提出了 Hybrid-DeepCom 的缺点,就是 Code Encoder 的输入和 AST Encoder 的输入之间存在不一
致,我们认为这是 Code Encoder 在 Hybrid-DeepCom 中担任两个角色造成的.其两个角色中,第 1 个是提取代码
序列特征的角色,需要通过 RNN 提取出代码序列的语义信息;第 2 个是提供注意力的角色,Attention 机制需要通
过给 Code Encoder 的输入的不同权重来决定当前的输出.我们认为,Hybrid-DeepCom 通过分解标识符增强了其
作为第 1 个角色的作用,但却破坏了代码结构,削弱了其作为第 2 个角色的作用,这两个作用在这里是无法同时
提升的.因此我们在此基础上再增加一个输入,即分解标识符之前的代码序列,分担 Code Encoder 的第 2 个角色,
提出了 CodePtr-PGN,将 Hybrid-DeepCom 中 Code Encoder 的第 2 个任务由过新的编码器 Source Encoder 来承
担,我们认为这样可以使模型中的每个编码器只有一个角色,并专注于一个任务,从而在一定程度上提高了模型
的表现.
我们将 Code-PGN 与 Hybrid-DeepCom 在不同词库大小下的表现进行对比,分析不同词库大小下,加入
Source Encoder 是否会提升模型的表现,如果带来了提升,我们将进一步分析提升的原因.
表 1 中的实验结果表明,在词库大小为 5 000 时两者得分相近,在 10000~50000 时 CodePtr-PGN 高于
Hybrid-DeepCom.对于两者在词库大小为 5 000 时得分相近的原因,我们认为是上述 Source Encoder 为 CodePtr-
PGN 带来的优势在较小的词库大小下并没有产生作用,因为对于含有较多 OOV 词的分解前的源代码,在较小
的词库大小下,Source Encoder 的输入包含了大量的“UNK”标签,这些大比例的无意义信息使得 Source
Encoder 无法给模型带来实际的提升.这也是当词库大小为 30 000 和 50 000 时,CodePtr-PGN 与 Hybrid-
DeepCom 的分差比在 10 000 时要大的原因.
表 2 显示了在词库大小为 30 000 时 CodePtr-PGN 和 Hybrid-DeepCom 在所示样本上的输出,其中加粗的单
词表示 Source Encoder 和 Code Encoder 输入之间的差异.
从表中可以看出,Code Encoder 的输入将类名“NinePatchBorder”根据驼峰命名法分解为了“nine”“patch”和
“border”.而对于两个模型的预测输出,Hybrid-DeepCom 和 CodePtr 分别输出了“instantiates the nine setting.”和
“instantiates a new nine patch border.”.通过参考注释,我们可以看出,两个模型都正确地判断出了源代码的意图,
就是实例化(“instantiates”)一个类.而对于类的名称,在两个模型都没有指针生成网络的情况下,Hybrid-
DeepCom 生成的注释中仅有“nine”,而 CodePtr-PGN 则生成了该类名分解后的所有单词.图 5 显示了两个模型