張睿峰,王鵬程,吳 鳴,徐 云

1(中國(guó)科學(xué)技術(shù)大學(xué) 計(jì)算機(jī)科學(xué)與技術(shù)學(xué)院,合肥 230026)

2(安徽省高性能計(jì)算重點(diǎn)實(shí)驗(yàn)室,合肥 230026)

如今的軟件工程都會(huì)依賴(lài)于大型標(biāo)準(zhǔn)庫(kù)例如：.NET 框架、Java SDK 或者Android 等等,這些庫(kù)會(huì)提供大量多樣的提前實(shí)現(xiàn)好的功能,例如匹配正則表達(dá)式、解析XML和發(fā)送電子郵件等等.對(duì)于不熟悉的庫(kù)或者軟件框架對(duì)于開(kāi)發(fā)者學(xué)習(xí)API 的使用是比較困難的[1].一個(gè)大型的軟件庫(kù)例如：.NET 框架或者JDK 可能包含成千上萬(wàn)個(gè)API,例如JDK8 的基礎(chǔ)庫(kù)中有超過(guò)14 000 個(gè)類(lèi)和方法,調(diào)查結(jié)果顯示如何選擇API 成為用戶編程系統(tǒng)中六個(gè)學(xué)習(xí)障礙之一[2].微軟2009年的一項(xiàng)調(diào)查中發(fā)現(xiàn),67.6%的受訪者反應(yīng)他們?cè)趯W(xué)習(xí)如何使用這些API 的時(shí)候沒(méi)有充足的示例以供參考[3].

當(dāng)面對(duì)一個(gè)API (Application Program Interface)相關(guān)的任務(wù)時(shí),開(kāi)發(fā)者往往會(huì)借助搜索引擎例如：Google 或者Bing 去查找已有的API.他們往往帶著兩個(gè)問(wèn)題去搜索答案：(1)對(duì)于他們的特定問(wèn)題使用哪些API,(2)如何調(diào)用這些API[4],即API 調(diào)用序列.如圖1所示,從著名的程序問(wèn)答網(wǎng)站Stack Overflow 上截取的開(kāi)發(fā)者和研究人員在軟件開(kāi)發(fā)過(guò)程中遇到的實(shí)際例子.他們想知道如何去調(diào)用已有的API 函數(shù)去解決自己的實(shí)際問(wèn)題.因此,研究如何從已有的資源中(例如：Github 或者Bitbucket)挖掘出用戶需要的API 以及相應(yīng)的API 調(diào)用序列已經(jīng)成為亟待解決的問(wèn)題并且有重要的實(shí)際意義.

圖1 Stack Overflow 網(wǎng)站上的問(wèn)答實(shí)例

1 問(wèn)題定義及相關(guān)工作

1.1 問(wèn)題定義

對(duì)于一個(gè)用戶查詢輸入Q,返回一個(gè)API 調(diào)用序列S.Q 是對(duì)需要解決問(wèn)題的英文描述,例如：“How to open a file?”.而S 是解決該問(wèn)題的API 調(diào)用序列.本文主要研究Java 語(yǔ)言相關(guān)的問(wèn)題,則相應(yīng)的S 序列為：File.new(),File.open(),File.close().

1.2 相關(guān)工作

按照代碼搜索方法的輸入類(lèi)型劃分,相關(guān)文獻(xiàn)可分為以自由文本作為輸入的研究、以API 作為輸入的研究、其它形式作為輸入的研究.而推薦的內(nèi)容要么是相關(guān)的代碼片段,要么是單個(gè)API,或API 的調(diào)用序列.這里,把推薦代碼的研究稱(chēng)為代碼搜索,把推薦API 及其序列的研究稱(chēng)為API 推薦[5].

1.2.1 代碼搜索的研究現(xiàn)狀

在代碼搜索研究中,主要是基于基于信息檢索技術(shù),Zhong 等人[6]提出為開(kāi)發(fā)者的查詢推薦API 使用模式及對(duì)應(yīng)的代碼片段.Bajracharya[7]等人基于開(kāi)源代碼的結(jié)構(gòu)化信息編寫(xiě)的Sourcer 是代碼推薦的典型應(yīng)用.McMillan[8]等人提出一個(gè)基于PageRank和SAN 對(duì)復(fù)雜任務(wù)檢索和可視化相關(guān)的代碼片段的工具Portfolio.Bajracharya 等人[9]在Lucene 的多域搜索平臺(tái)上,綜合API 使用模式的相似性等一系列特征進(jìn)行代碼片段的推薦.Keivanloo 等人[10]利用向量空間模型、頻繁項(xiàng)挖掘等技術(shù)為自由文本的查詢進(jìn)行代碼推薦.Raghothaman等人[4]提出了一種新的方法SWIM,該方法首先從用戶點(diǎn)擊數(shù)據(jù)中找到與用戶輸入的自由文本查詢相關(guān)的APIs,同時(shí)從Github 的代碼中抽取出結(jié)構(gòu)化的API 調(diào)用序列,通過(guò)匹配找到APIs 相應(yīng)的調(diào)用序列,進(jìn)而產(chǎn)生合成的代碼片段.Jiang 等人[11]嘗試將信息檢索和監(jiān)督學(xué)習(xí)的方法結(jié)合為自由查詢提供Top-K 個(gè)相關(guān)的代碼片段.

1.2.2 API 序列推薦的研究現(xiàn)狀

然而傳統(tǒng)的代碼搜索引擎由于大部分使用了關(guān)鍵字匹配的技術(shù),導(dǎo)致在處理自然語(yǔ)言查詢方面不能有良好的表現(xiàn)[12].在APIs 序列推薦研究中,近幾年也有了較大的發(fā)展.Thung 等人[13]整合了用戶對(duì)于搜索引擎結(jié)果的反饋并利用其重新排序返回結(jié)果列表使得真正相關(guān)的條目排在列表中的較前位置.Niu 等人[14]提出了使用監(jiān)督學(xué)習(xí)的方法,在兩階段的基礎(chǔ)上,借助于多種特征進(jìn)行API 的推薦.Rahman 等人[12]嘗試從Stack Overflow 的問(wèn)答對(duì)中抽取出與開(kāi)發(fā)者的自由文本的查詢相關(guān)的API.Gu 等人[15]提出了一種基于深度學(xué)習(xí)的API 序列推薦方法DeepAPI,該方法受機(jī)器翻譯的啟發(fā),使用經(jīng)典的seq2seq 的RNN 模型,將“查詢-推薦”任務(wù)視作一種語(yǔ)言翻譯的過(guò)程,并取得了較好的效果.

1.3 目前API 序列推薦方法存在的問(wèn)題

SWIM[4]訓(xùn)練的統(tǒng)計(jì)詞對(duì)齊模型是基于詞袋模型的,而沒(méi)有考慮到API 的單詞序列以及位置關(guān)系,例如：它很難區(qū)分查詢語(yǔ)句“convert date to string”與“convert string to date”.而之后Gu 等人[15]提出的DeepAPI 使用RNN 模型更好的學(xué)習(xí)到了句子的語(yǔ)義信息.經(jīng)測(cè)試BLEU (BiLingual Evaluation Understudy)[16]值比基于傳統(tǒng)模型的SWIM 提高了約173%.

但是,DeepAPI 采用的基于RNN 的模型并沒(méi)有充分考慮到每個(gè)單詞的重要程度,以及詞與詞之間的相互依賴(lài)關(guān)系,在句子過(guò)長(zhǎng)的情況下會(huì)丟失之前的依賴(lài)信息,所以本文使用了完全基于注意力機(jī)制的模型,充分考慮了每個(gè)詞的重要程度和相互依賴(lài)關(guān)系,經(jīng)實(shí)驗(yàn)結(jié)果可得BLEU 值在Top1 上比DeepAPI 提高了約28.5%.

2 基于Attention 機(jī)制模型的設(shè)計(jì)和實(shí)現(xiàn)

由于沒(méi)有公開(kāi)的可供訓(xùn)練的數(shù)據(jù)集,需要我們自己生成可供訓(xùn)練測(cè)試的數(shù)據(jù).我們首先通過(guò)網(wǎng)絡(luò)爬蟲(chóng)從Github 上爬取關(guān)注度比較高的(即星標(biāo)數(shù)的倒序排列)Java 語(yǔ)言的開(kāi)源項(xiàng)目.如圖2所示,首先使用GrouMiner[17]將這些工程文件解析為程序依賴(lài)圖,再以方法級(jí)為粒度提取出我們需要的API 序列和注解對(duì),接下來(lái)使用我們?cè)O(shè)計(jì)的基于注意力機(jī)制的模型對(duì)這些序列對(duì)進(jìn)行訓(xùn)練得到訓(xùn)練模型,接下來(lái)針對(duì)每個(gè)查詢語(yǔ)句使用beam search 算法給出推薦的序列列表.具體設(shè)計(jì)分以下幾個(gè)方面：

圖2 從Java 代碼提取API 序列對(duì)流程圖

2.1 使用GrouMiner 提取需要的API 序列

如圖3所示,需要將main 方法上的注釋“This method demonstrates square()”提取出來(lái),而main 方法中的API 調(diào)用序列為每個(gè)對(duì)象生成以及調(diào)用的方法序列依次追加.對(duì)于條件控制語(yǔ)句例如：if和else 語(yǔ)句,分別將if和else 語(yǔ)句塊中的調(diào)用序列依次追加,其他條件控制語(yǔ)句例如switch和while 等同理.對(duì)于提取API 序列我們使用GrouMiner,它是一個(gè)基于圖方法用來(lái)挖掘程序中出現(xiàn)的使用慣例.如圖4所示,通過(guò)GrouMiner 可以將源代碼轉(zhuǎn)換為對(duì)象依賴(lài)圖.對(duì)于每個(gè)需要解析的方法,依次生成調(diào)用序列以及方法上面的注釋對(duì),以供后面訓(xùn)練使用.

圖3 代碼注釋示例圖

圖4 通過(guò)GrouMiner 將源代碼轉(zhuǎn)換為程序依賴(lài)圖

2.2 注意力機(jī)制的Encoder-Decoder 模型

2.2.1 基于RNN 的Encoder-Decoder 模型的缺點(diǎn)

如圖5所示,對(duì)于編碼器Encoder 就是對(duì)輸入句子x1,…,xTi進(jìn)行編碼,通過(guò)非線性變換f將上一時(shí)刻的隱藏層ht-1與 當(dāng)前時(shí)刻的輸入xt轉(zhuǎn)化為當(dāng)前時(shí)刻的隱藏層ht,結(jié)束時(shí)刻的hTx即為c(c為固定長(zhǎng)度的向量).

由此可見(jiàn)：(1)輸入語(yǔ)句序列xTi(在訓(xùn)練模型的時(shí)候即注釋語(yǔ)句)中每一個(gè)英文單詞對(duì)推薦的API 序列中每一個(gè)單詞的貢獻(xiàn)都是一樣的,但實(shí)際上每個(gè)單詞的貢獻(xiàn)是有區(qū)別的.(2)由于輸入語(yǔ)句映射在固定長(zhǎng)度的向量中,因此對(duì)于較長(zhǎng)輸入語(yǔ)句,特別是輸入語(yǔ)句長(zhǎng)度大于向量長(zhǎng)度或者是訓(xùn)練集中沒(méi)有的長(zhǎng)語(yǔ)句時(shí),會(huì)損失上下文特征的很多信息.所以對(duì)于較長(zhǎng)語(yǔ)句的處理上,基于RNN 的Encoder-Decoder 模型表現(xiàn)的不好.

圖5 基于RNN 的Encoder-Decoder 模型

2.2.2 使用注意力機(jī)制的Encoder-Decoder 模型

如圖6所示,使用注意機(jī)制,我們不再?lài)L試將完整的源序列編碼為固定長(zhǎng)度的向量.而是通過(guò)Scaled Dot-Product Attention[18]對(duì)輸入語(yǔ)句的每個(gè)單詞進(jìn)行計(jì)算,得到單詞的權(quán)重矩陣Attention(Q,K,V),每一行為一個(gè)單詞的權(quán)重向量.式(3)中,Q、K和V均為矩陣,每一行為一個(gè)向量,dk為矩陣維度的大小,模型的實(shí)現(xiàn)如圖7所示.其中Attention(Q,K,V)就是注意力值,代表對(duì)于輸出序列的不同部分需要關(guān)注輸入序列的哪些部分.所以,使用注意力機(jī)制的Encoder-Decoder 模型不會(huì)受到長(zhǎng)距離依賴(lài)的影響.

圖6 基于注意力機(jī)制的Encoder-Decoder 模型

圖7 Scaled Dot-Product Attention 結(jié)構(gòu)

圖6中,編碼器網(wǎng)絡(luò)由多個(gè)相同的層堆疊而成,每層有2 個(gè)子層,第一層是一個(gè)Scaled Dot-Product Attention的注意力層,第二層是一個(gè)全連接的feed-forward 層,每層都由一個(gè)殘差網(wǎng)絡(luò)連接,解碼器同編碼器一樣也是由多個(gè)相同層堆疊而成,不同的是插入了一個(gè)子層,如圖7所示,Mask 為可選部分,這個(gè)掩碼確保了位置i的輸出序列只能依賴(lài)比i小的已知輸出,即通過(guò)將其后位置的數(shù)據(jù)設(shè)置為- ∞.

3 實(shí)驗(yàn)分析

實(shí)驗(yàn)總共收集了649 個(gè)關(guān)注度較高的Java 語(yǔ)言的Github 開(kāi)源項(xiàng)目,約20 GB 的數(shù)據(jù)量,共加工處理得到了114 364 個(gè)＜annotation,API sequence＞對(duì).為節(jié)約我們訓(xùn)練的時(shí)間以及方便測(cè)試,我們只隨機(jī)取50 000個(gè)序列對(duì)用于訓(xùn)練,并隨機(jī)取500 條序列對(duì)用于測(cè)試.實(shí)驗(yàn)機(jī)器配置如表1所示,Encoder -Decoder 模型主要的參數(shù)有：詞向量的最大長(zhǎng)度設(shè)置為100,最小出現(xiàn)閾值為5 次,隱藏單元為512 個(gè),迭代20 萬(wàn)次.

表1 實(shí)驗(yàn)機(jī)器配置

3.1 BLEU 測(cè)試結(jié)果

BLEU[16]是一種用于在機(jī)器翻譯領(lǐng)域評(píng)估從一種自然語(yǔ)言翻譯到另一種自然語(yǔ)言的文本質(zhì)量的算法.我們通過(guò)BLEU 計(jì)算我們輸出的API 調(diào)用序列與標(biāo)準(zhǔn)參考的API 序列相似度得分可以評(píng)判結(jié)果的好壞.如圖8所示,我們分別取查詢結(jié)果的第一個(gè),前五個(gè)以及前十個(gè)進(jìn)行對(duì)比得出,在返回一個(gè)查詢結(jié)果的時(shí)候我們的方法高出DeepAPI 約28.5%.

圖8 模型的BLEU 得分圖

4 結(jié)論與展望

本文首先使用了GrouMiner[17]開(kāi)發(fā)了一個(gè)可以用來(lái)從Java 代碼中提取API 序列以及注釋對(duì)的工具.其次,針對(duì)RNN(1)不能充分考慮每個(gè)單詞的權(quán)重,(2)以及將輸入序列壓縮為一個(gè)固定長(zhǎng)度的向量,損失了很多可用信息,(3)對(duì)于句子過(guò)長(zhǎng)產(chǎn)生的依賴(lài)信息丟失等缺點(diǎn),使用了完全基于注意力機(jī)制的模型取得了比目前所知最好結(jié)果的DeepAPI 在BLEU 的Top1 得分上高出28.5%的結(jié)果.我們下一步的工作計(jì)劃是將該工具可視化以及開(kāi)源,供其他科研工作者以及軟件開(kāi)發(fā)人員使用.