馬 展, 王 巖, 王微微, 趙瑞蓮

(北京化工大學(xué) 信息科學(xué)與技術(shù)學(xué)院, 北京 100029)

1 引言

應(yīng)用程序接口(API)在軟件開發(fā)中起著十分重要的作用. 87%的開發(fā)人員經(jīng)常借助于API解決不同的編程問題[1], 但檢索查找合適的API非常困難. 為此, 為提高API檢索的效率和質(zhì)量, 研究人員從API參考文檔、IT問答網(wǎng)站等各類資源構(gòu)建了相應(yīng)的API推薦系統(tǒng), 以幫助開發(fā)人員解決與API相關(guān)的編程問題. 目前,已有的API推薦系統(tǒng)有: RASH[2]、BIKER[1]和RACK[3]等. RASH針對API參考文檔和Stack Overflow (SO)問答網(wǎng)站[4], 利用詞法相似度為查詢推薦API. 與RASH不同, BIKER[1]利用語義相似度, 結(jié)合API參考文檔和SO問答網(wǎng)站, 為查詢推薦API. RACK[3]則通過建立問答網(wǎng)站標(biāo)題中的關(guān)鍵字和API之間的關(guān)聯(lián), 為查詢推薦API. 這些方法通過尋找問答網(wǎng)站相似問答涉及的API, 為查詢推薦API. 然而, 與編程相關(guān)的API信息常以多種形式關(guān)聯(lián), 如解決同一問題的API之間可能存在功能相似的關(guān)聯(lián). 這種關(guān)聯(lián)可能有助于API檢索推薦[5].但上述方法均未考慮API信息之間的關(guān)聯(lián).

知識圖譜是一個能有效表示信息之間語義關(guān)聯(lián)的知識網(wǎng)絡(luò)[6], 可用于API的知識表示. 如, Liu等人[7]從API參考文檔和維基百科中提取相關(guān)知識, 構(gòu)建API知識圖譜； Li等人[8]從API參考文檔和API教程中提取警告語句, 構(gòu)建API警告知識圖譜； Ling等人[5]以開源項目中的API為實體, 以API之間的調(diào)用、返回、實現(xiàn)等為關(guān)系, 構(gòu)建基于開源項目的API知識圖譜. 但上述從API文檔、維基百科或開源項目等構(gòu)建的API知識圖譜, 缺少對API實際應(yīng)用場景描述方面的信息,不利于API實際應(yīng)用知識的融合利用.

SO是一個面向編程人員群體的IT技術(shù)問答網(wǎng)站.它以解決用戶實際問題為出發(fā)點, 提供了API使用目的和真實應(yīng)用場景相關(guān)信息[9], 可與API參考文檔相輔相成, 互為補充, 為API知識圖譜的構(gòu)建提供真實應(yīng)用場景的支持. PyTorch是一個以Python優(yōu)先的深度學(xué)習(xí)框架, 在SO中涉及大量與API相關(guān)的討論. 因此,本文提出一種結(jié)合API參考文檔和SO問答網(wǎng)站的API知識圖譜構(gòu)建方法(AKG-CMISF). 從API參考文檔提取API、領(lǐng)域概念作為實體, 建立他們之間的包含、繼承、重載等關(guān)系； 從SO問答網(wǎng)站中提取問答QA、API概念作為實體, 建立問答QA實體和API概念實體之間的關(guān)聯(lián)關(guān)系. 在此基礎(chǔ)上, 建立API參考文檔中的API、領(lǐng)域概念和SO問答網(wǎng)站中的問答QA、API概念之間的關(guān)聯(lián)關(guān)系, 將多源知識進(jìn)行融合, 構(gòu)建多源信息融合的API知識圖譜. 具體而言, 針對API參考文檔, 通過分析半結(jié)構(gòu)化文本提取API實體, 通過詞典匹配提取領(lǐng)域概念實體； 針對SO問答網(wǎng)站, 通過類型識別和摘要生成獲取問答QA實體, 通過數(shù)據(jù)驅(qū)動識別API概念； 然后, 基于語義相似度建立API概念和領(lǐng)域概念之間的關(guān)聯(lián), 利用詞共現(xiàn)方法構(gòu)建API和API概念之間的關(guān)聯(lián), 依據(jù)啟發(fā)式策略構(gòu)建API和問答QA之間的關(guān)聯(lián), 將多源信息進(jìn)行知識融合, 實現(xiàn)API知識圖譜的構(gòu)建.

為驗證本文提出的方法, 分別從知識抽取的準(zhǔn)確度和推薦應(yīng)用兩個角度, 對本文構(gòu)建API知識圖譜的有效性進(jìn)行評估. 實驗結(jié)果表明, 和現(xiàn)有API推薦系統(tǒng)相比, 本文構(gòu)建的知識圖譜的API推薦效果和效率均有提升, 表明了API知識圖譜的有效性以及多源信息融合對API推薦效果的支撐.

2 基于多源信息的API知識圖譜構(gòu)建

本文從API參考文檔和SO問答網(wǎng)站提取API相關(guān)知識, 通過兩類API知識的融合, 構(gòu)建API知識圖譜, 其框架如圖1所示.

圖1 基于多源信息的API知識圖譜構(gòu)建框架

2.1 面向API參考文檔的知識獲取

API參考文檔提供所有API的功能描述及其相關(guān)屬性信息(如參數(shù)、返回值等). 本文主要選用PyTorch框架的API參考文檔, 進(jìn)行知識表示及獲取.

2.1.1 API參考文檔的知識表示

本文以API參考文檔涉及的API、領(lǐng)域概念以及它們之間的關(guān)系作為其知識表示. API參考文檔的功能描述中蘊含API的應(yīng)用領(lǐng)域, 該信息可間接反映API和領(lǐng)域概念之間的關(guān)聯(lián)關(guān)系. 本文API是指模塊、類、方法/函數(shù)等, 它們之間存在包含、繼承和重載等關(guān)系. 領(lǐng)域概念是對API應(yīng)用領(lǐng)域的抽象概括. API和領(lǐng)域概念之間可通過“提及”關(guān)聯(lián)起來. 因此, 本文將API和領(lǐng)域概念作為API參考文檔的實體, 并將它們之間的“提及”作為實體間的關(guān)系.

2.1.2 API參考文檔的知識提取

API參考文檔屬于半結(jié)構(gòu)化數(shù)據(jù), 不同的HTML標(biāo)簽表示不同類型的API實體, API標(biāo)簽下含有API實體的屬性信息, 如功能描述、參數(shù)、返回值和返回值類型等. 因此, 本文開發(fā)了一個API實體及屬性分析模塊, 分析并識別API實體之間的關(guān)系. 具體而言, 通過靜態(tài)分析并識別API類或方法/函數(shù)及其它們之間的關(guān)系； 根據(jù)類的聲明規(guī)則, 采用正則表達(dá)式提取類和基類之間的繼承關(guān)系, 實現(xiàn)API實體及關(guān)系的識別和提取.

針對API功能描述中隱含的領(lǐng)域概念, 可通過目前已有的領(lǐng)域概念詞典進(jìn)行識別. 由于本文關(guān)注的是PyTorch框架, 因此, 采用文獻(xiàn)[10]提供的領(lǐng)域概念開源詞典[11], 匹配并識別API功能描述中的領(lǐng)域概念. 即將領(lǐng)域概念詞典加入工具的自定義命名實體識別列表中, 根據(jù)API功能描述, 利用自然語言處理spacy匹配并識別API功能描述中的領(lǐng)域概念.

每個API都對應(yīng)一個功能描述, 功能描述隱含領(lǐng)域概念, 因此, 從這種對應(yīng)結(jié)構(gòu)中可提取API和領(lǐng)域概念之間的“提及”關(guān)系. 如API “torch.normal”的功能描述中包含領(lǐng)域概念“standard deviation”. 當(dāng)領(lǐng)域概念“standard deviation”被識別后, 則可在API“torch.normal”和領(lǐng)域概念“standard deviation”之間建立“提及”關(guān)系.

2.2 面向SO問答網(wǎng)站的知識獲取

SO問答網(wǎng)站含有API的具體應(yīng)用場景信息, 可與API參考文檔互為補充. 本文主要對SO問答網(wǎng)站標(biāo)簽為“PyTorch”的問答進(jìn)行知識的表示及獲取.

2.2.1 SO問答網(wǎng)站的知識表示

SO問答網(wǎng)站的文本描述中包含了與API相關(guān)的術(shù)語, 如“download”“update”等. 這些術(shù)語可能只與軟件開發(fā)相關(guān), 不限于某領(lǐng)域, 但往往和API出現(xiàn)在同一句話, 同一段落或者同一篇問答中. 由于段落是問答描述的基本邏輯單元, 故本文將與API處于同一段落的相關(guān)術(shù)語稱為API概念實體.

SO問答存在目的不明確和信息過載等問題. 目的不明確是指, SO問答因未考慮用戶提問的目的, 使得SO問答網(wǎng)站很難把握用戶提問的原因, 從而找出相應(yīng)答案[12,13]； 信息過載是指, SO問答的一個提問可能有多個回答. 有統(tǒng)計表明, 超過37%的SO問答包含一個以上的回答, 每個回答的平均字?jǐn)?shù)超過789個單詞[14],這增加了SO問答網(wǎng)站獲取關(guān)鍵信息的難度. 本文依據(jù)提問目的對SO問答自動分類, 以識別目的類型, 明確提問目的； 并依據(jù)SO問答特征生成回答的摘要, 從而減少信息過載. 本文將包含目的類型和摘要的SO問答稱為問答QA實體. 繼而可建立問答QA實體和API概念實體之間的“提及”關(guān)系. 并將API概念、問答QA,以及它們之間的關(guān)系作為SO問答網(wǎng)站知識表示.

2.2.2 SO問答網(wǎng)站的知識提取

為從SO問答網(wǎng)站提取API概念實體, 首先需識別SO問答網(wǎng)站中涉及的API. SO問答網(wǎng)站中的API通常由＜code＞標(biāo)簽標(biāo)注, 當(dāng)＜code＞標(biāo)簽標(biāo)注的元素部分匹配或完全匹配API參考文檔中的API全限定名時, 可識別該元素為SO問答中的API. API概念與API處于同一段落, 它可能是由多單詞組成的概念, 如“convolutional layer”等. 為識別多單詞API概念, 本文采用一種基于數(shù)據(jù)驅(qū)動的API概念識別方法, 即在SO問答網(wǎng)站中尋找經(jīng)常連續(xù)出現(xiàn)但不常單獨出現(xiàn)的單詞,將其作為API概念. 為此, 可通過自然語言處理技術(shù),對SO問答進(jìn)行分詞及去停用詞, 形成單字符概念. 根據(jù)連續(xù)單詞出現(xiàn)的頻率, 計算詞組得分 (score), 提取API概念. 詞組得分如式(1)所示:

其中,count(wiwj)表示兩個連續(xù)的單詞wi和wj在全文檔中出現(xiàn)的次數(shù),count(wi)和count(wj)分別表示單詞wi和wj出現(xiàn)的次數(shù),δ是一個閾值. 當(dāng)兩個連續(xù)出現(xiàn)的單詞wi和wj的頻率小于δ時,wi和wj不能構(gòu)成雙詞短語. 當(dāng)形成雙詞概念時, 重復(fù)式(1)可檢測三單詞短語. 由于3個以上單詞構(gòu)成的API概念不常見, 故本文僅識別三單詞以內(nèi)的短語作為API概念.

為提取SO網(wǎng)站的問答QA實體, 本文通過機(jī)器學(xué)習(xí)算法對提問的目的進(jìn)行分類, 獲得目的類型, 在此基礎(chǔ)上, 進(jìn)行基于特征提取的回答摘要生成, 實現(xiàn)問答QA實體的提取.

本文針對提問目的, 在Beyer等人[15]對SO問答歸類的基礎(chǔ)上, 將SO問答分為如下7類: “API USAGE”類的提問目的為: 尋求實現(xiàn)某功能或API的使用建議； “DISCREPANCY”類的提問目的為: 請求解決非預(yù)期結(jié)果的代碼段； “ERRORS”類的提問目的為:請求修復(fù)錯誤或處理異常； “REVIEW”類的提問目的為: 請求最佳解決方案； “CONCEPTUAL”類的提問目的為: 詢問API的原理或背景； “API CHANGE”類的提問目的為: 尋求解決因API版本變化所產(chǎn)生的問題的方法； “LEARNING”類的提問目的為: 詢問文檔或教程來學(xué)習(xí)工具或語言.

XGBoost (eXtreme Gradient Boosting)機(jī)器學(xué)習(xí)算法具有快速學(xué)習(xí)和預(yù)測的功能[16]. 它基于決策樹, 采用殘差擬合的方式對殘差進(jìn)行順序?qū)W習(xí), 具有較高的分類準(zhǔn)確性, 因此本文采用XGBoost算法訓(xùn)練分類器對SO問答分類. 主要步驟如下:

(1) 將SO問答標(biāo)注為7種類型中的一種；

(2) 通過自然語言處理過程(分詞、刪除停用詞、詞形還原等), 將提問轉(zhuǎn)換成相應(yīng)的單詞列表；

(3) TF-IDF通過字詞出現(xiàn)的頻率反映了其重要性,本文以提問的TF-IDF作為其文本特征. 在此基礎(chǔ)上,利用XGBoost算法識別所有SO問答的提問類型.

針對SO問答信息過載, 本文以回答中的重要段落為依據(jù), 生成其摘要. 即根據(jù)SO問答網(wǎng)站的特點, 通過問題相關(guān)特征、內(nèi)容相關(guān)特征和用戶特征, 綜合為各段落計算其特征值, 取前M(10)個段落作為其摘要. 具體特征分析如下:

(1) 問題相關(guān)特征: 若段落中包含提問中的關(guān)鍵詞,該段落被認(rèn)為是與提問相關(guān)的段落. 段落包含的關(guān)鍵詞越多, 則相關(guān)度越大. SO的Tag標(biāo)簽作為關(guān)鍵詞集,以回答段落涉及的關(guān)鍵詞占提問與回答共同涉及的關(guān)鍵詞的比例, 計算每個回答段落和提問的相關(guān)度. 當(dāng)提問和回答中沒有共同的關(guān)鍵詞時, 則該段特征值置為0.

(2) 內(nèi)容相關(guān)特征: 該特征從是否包含API、信息熵、語義模板3個子特征評估段落內(nèi)容的重要性. ① 若段落中至少出現(xiàn)一個API, 則子特征值置為1, 否則置為0. ② 單詞的逆文本頻率指數(shù)IDF值可用來衡量其信息熵, 可通過式(2)計算. 其中p表示段落總數(shù),p′表示包含某個單詞的段落數(shù).IDF值越高, 表明單詞出現(xiàn)的頻率越低, 則重要程度越高. 段落的熵值可用其單詞的IDF值之和表示, 并將熵值歸一化為(0,1], 作為子特征值. ③ 本文結(jié)合API推薦的句式特征和帶有總結(jié)性的句式特征對Xu等人[17]的段落語義模板進(jìn)行擴(kuò)充,結(jié)果如表1所示. 若段落中至少包含一個句式, 子特征的值置為1, 否則置為0. 內(nèi)容特征值為3個子特征值之和.

表1 表明突出段落的語義模板

(3) 用戶特征: SO中每個回答都有相應(yīng)的投票, 投票越高, 表明該回答的質(zhì)量越高. 因此, 采用回答的票數(shù)作為當(dāng)前回答中段落的票數(shù).

對于上述3種特征, 為了避免特征得分為0, 通過添加平滑因子0.0001, 將所有特征歸一化為(0,1]. 將每個特征的歸一化值相乘, 作為每個段落的總分. 最終取前M(10)個段落作為問答QA的摘要.

通過對SO問答進(jìn)行提問的類型識別以及回答的摘要生成, 最終獲得有效的問答QA實體. SO問答通常會提及多個API概念, 當(dāng)識別了API概念后, 可分別在API概念和當(dāng)前問答QA之間建立“提及”關(guān)系.

2.3 知識融合

為對API參考文檔和SO問答網(wǎng)站的API知識進(jìn)行融合, 構(gòu)建完整的API知識圖譜, 本文分別從API實體和API概念實體、API概念實體和領(lǐng)域概念實體以及API實體和問答QA實體之間, 進(jìn)行知識融合.

2.3.1 基于詞共現(xiàn)的API實體和API概念實體之間的融合

詞共現(xiàn)是指API和API概念具有相同的上下文,即出現(xiàn)在同一段落. API概念對API的功能作用進(jìn)行抽象概括, 這是建立兩者之間語義關(guān)聯(lián)的關(guān)鍵. 共現(xiàn)頻率是指API和API概念出現(xiàn)在同一段落的次數(shù). 因此本文通過計算API和API概念的共現(xiàn)頻率, 捕獲具有語義關(guān)聯(lián)的API和API概念.

如式(3)所示,freq(Ai→Acj) 表示APIAi和API概念A(yù)cj的共現(xiàn)頻率,α為其閾值. 當(dāng)共現(xiàn)頻率不低于閾值α?xí)r, APIAi和API概念A(yù)cj之間可建立“提及”的關(guān)系.

2.3.2 基于語義相似度的API概念實體和領(lǐng)域概念實體之間的融合

API概念和領(lǐng)域概念的融合是指建立API概念和領(lǐng)域概念之間的關(guān)聯(lián)關(guān)系, 這種關(guān)聯(lián)關(guān)系有助于建立API之間的間接關(guān)聯(lián), 以提高檢索到相關(guān)API的可能.

由于API概念和領(lǐng)域概念由詞組構(gòu)成, 因此, 可通過結(jié)合詞法和語義相似度來確定兩者之間的關(guān)系. 當(dāng)二者的相似度高于給定閾值時, 可建立它們的“相關(guān)”關(guān)系. 相似度計算公式如式(4)所示:

式(4)從詞法和語義兩個方面度量領(lǐng)域概念和API概念的相似度,n1和n2代表候選的領(lǐng)域概念和API概念. 詞法相似度simlex通過Jaccard相似度進(jìn)行計算, 如式(5)所示, 其中Token(n)代表組成概念的單詞. 在SO問答和API參考文檔兩類語料庫的基礎(chǔ)上,本文利用Word2Vec[18]訓(xùn)練詞嵌入模型, 將概念轉(zhuǎn)換為詞向量. 通過式(6)計算n1和n2之間的語義相似度.Vp(n)表示概念實體向量,simcos表示兩個向量的余弦相似度. 一般來說, 語義相似度的重要性大于詞法相似度, 因此, 設(shè)置w1＜w2.

2.3.3 基于啟發(fā)式的API實體和問答QA實體之間的融合

API實體和問答QA實體之間的融合是指建立API實體和問答QA之間的關(guān)聯(lián)關(guān)系. 這種關(guān)聯(lián)關(guān)系的建立使得API參考文檔中API的通用知識(功能描述、參數(shù)、返回值等)可以和API在具體場景下的具體知識(如何解決具體問題)聯(lián)系在一起, 可為開發(fā)人員提供更全面的API信息.

一般而言, SO問答中的API并不總是以全限定名的形式存在, 例如SO問答“What does model.train() do in PyTorch”中提及API“forward()”. 然而“forward()”可以與多個API關(guān)聯(lián). 為了將問答QA實體無歧義地和相應(yīng)的API實體進(jìn)行關(guān)聯(lián), 本文設(shè)計了啟發(fā)式策略: SO問答中代碼元素的出現(xiàn)有局部性[19], 即同一問答出現(xiàn)的API通常屬于同一模塊或類. 通過解析HTML的＜code＞標(biāo)簽, 識別問答QA提及API的模塊或類. 通過制定正則表達(dá)式識別代碼塊中的模塊或類確定其API. 當(dāng)識別了無歧義的API后, 便可在問答QA和API之間建立“提及”的關(guān)聯(lián)關(guān)系.

3 實驗設(shè)計及結(jié)果分析

3.1 實驗設(shè)計

本文從SO官方數(shù)據(jù)(截至2020年6月發(fā)布的數(shù)據(jù))[20]中提取標(biāo)注為“pytorch”的問答, 通過剔除其沒有回答和回答中評分小于1的問答, 共收集了3361個SO問答作為研究對象. 從PyTorch的API參考文檔中獲取27個模塊, 314個類, 1570個函數(shù)或方法, 以及它們對應(yīng)的功能描述和屬性作為研究對象, 進(jìn)行API知識圖譜的構(gòu)建. API概念提取時, 實驗中設(shè)置閾值δ 為5, 以避免不常見短語的識別. API和API概念之間融合時, 實驗中將共現(xiàn)頻率閾值 α設(shè)置為3, 來捕獲API實體和API概念實體之間的語義關(guān)聯(lián). 融合API概念和領(lǐng)域概念時, 考慮到語義相似度的重要性大于詞法相似度, 因此實驗中設(shè)置權(quán)重w1和w2分別為0.3和0.5.最終構(gòu)建的API知識圖譜含28 730個實體, 142 578個關(guān)系. 其中API實體1912個, API概念實體16 216個, 領(lǐng)域概念實體7116個, 問答QA實體3361個. 圖2是構(gòu)建API知識圖譜的部分抽象表示.

圖2 基于多源信息融合的API知識圖譜

本文構(gòu)建的API知識圖譜以Neo4j圖數(shù)據(jù)庫存儲,以便利用Stanford CoreNLP[21]自然語言處理工具, 通過語法分析提取查詢中的關(guān)鍵詞. 對于每個關(guān)鍵詞, 在API知識圖譜中搜索查找一個與之語義相近的概念實體. 與概念實體具有“提及”關(guān)系的API實體作為候選API, 與候選API關(guān)聯(lián)的問答QA為該候選API在具體使用場景下的信息. 由于候選API可能存在多個, 因此依據(jù)候選API和查詢的語義相關(guān)性對候選API進(jìn)行排序. 即通過計算查詢和每個候選API功能描述的語義相似度(見式(6))對API進(jìn)行排序, 取前K個API推薦給用戶. 本文從SO問答網(wǎng)站中隨機(jī)抽取10個至少有一次投票且回答中含有明確API的問題作為實驗對象, 通過搜索API知識圖譜, 獲得與其相關(guān)的API, 以此驗證基于知識圖譜的API推薦的有效性.

3.2 實驗結(jié)果與分析

本文從知識提取以及API推薦效果兩個角度評估API知識圖譜的質(zhì)量.

3.2.1 API知識提取的有效性分析

本實驗主要從實體和關(guān)系提取的有效性說明知識提取的有效性. API實體以及它們之間的關(guān)系來自半結(jié)構(gòu)化API參考文檔, 根據(jù)特定HTML標(biāo)簽和聲明,一般都會提取與之相關(guān)的實體和關(guān)系. 因此本文主要評估從非結(jié)構(gòu)化文本中提取實體的有效性, 即概念實體和問答QA實體, 以及API概念和領(lǐng)域概念之間關(guān)系提取的有效性. 概念實體以及關(guān)系的數(shù)量超過上萬個, 檢查所有實體和關(guān)系需要大量時間, 因此采用隨機(jī)采樣. 在確保95%置信度下, 從構(gòu)建API知識圖譜的實體或關(guān)系中隨機(jī)抽取5%的樣本, 樣本估計精度具有0.05的誤差幅度. 問答QA實體通過提問目的類型識別和回答摘要生成獲得, 因此通過分析分類對類型識別的準(zhǔn)確性以及摘要生成的質(zhì)量, 評估問答QA實體的有效性. 查詢問題及相關(guān)API個數(shù)如表2所示.

表2 10個查詢問題以及相關(guān)API個數(shù)

(1) 針對API概念和領(lǐng)域概念有效性的評估, 通過人工識別抽樣結(jié)果的準(zhǔn)確與否. 準(zhǔn)確是指提取的概念是正確且有意義的. 經(jīng)過隨機(jī)采樣, 從領(lǐng)域概念實體中獲得的356個領(lǐng)域概念的準(zhǔn)確度可達(dá)95.6%, 誤差主要來源于領(lǐng)域概念詞典自身； 從API概念實體采樣的800個API概念的準(zhǔn)確度為97.8%, 影響其準(zhǔn)確度的原因主要是SO問答中常提到一些數(shù)字指標(biāo), 如“200k images”, 這些術(shù)語不應(yīng)被識別為API概念. 針對API概念和領(lǐng)域概念關(guān)系提取的有效性評估, 人工識別抽樣結(jié)果的準(zhǔn)確性, 即API概念和領(lǐng)域概念之間的語義相關(guān)性是否準(zhǔn)確. 經(jīng)過隨機(jī)采樣, 從API知識圖譜中獲得4000個關(guān)系, 其中94.3%的API概念和領(lǐng)域概念語義被識別為是相關(guān)的, 未被正確識別的API概念或領(lǐng)域概念影響關(guān)系提取的有效性.

(2) 針對問答QA實體有效性的評估, 主要通過分析SO問答提問的分類效果和回答摘要生成的質(zhì)量加以說明.

① 問答分類效果評估: 本文采用10折交叉驗證的方法, 驗證SO 問答分類的有效性. 即用精度(precision)、召回率(recall)、F1值和準(zhǔn)確度(accuracy)對分類效果進(jìn)行評估. 為了驗證基于XGBoost的提問分類效果, 以常用的SVM(支持向量機(jī))和RF(隨機(jī)森林)作為對比. 結(jié)果如表3所示, XGBoost的精度相比SVM和RF分別提高了14.6%和5.7%, 準(zhǔn)確度分別提高了5.9%和4.6%. 因此, 可以看出, 采用XGBoost算法的分類效果優(yōu)于其它方法.

表3 不同分類算法的分類對比

② 摘要生成質(zhì)量評估: 本文從相關(guān)性、有用性和多樣性[17]衡量摘要的質(zhì)量. 相關(guān)性表示摘要是否與問題相關(guān), 有用性表示摘要內(nèi)容能否解決問題, 多樣性表示能否從多個角度回答問題. 本文設(shè)定每個指標(biāo)最高分為5分(分別代表高度相關(guān)、有用和多樣), 最低分為1分(分別代表不相關(guān)、無用和單一). 為了評估摘要質(zhì)量, 邀請具有兩年P(guān)yTorch使用經(jīng)驗的研究生參與評估. 表4表示評估者對表2的10個SO問答回答摘要的評價情況, 其中每個查詢的3個評價指標(biāo)均在3分到5分之間, 10個問題的平均結(jié)果分別為3.6、3.4和3.7, 表明基于特征提取的摘要生成方法是有效的.

表4 SO問答摘要得分的分布情況

3.2.2 本文AKG-CMISF對API的推薦效果分析

本實驗選擇信息檢索常用的3個評價指標(biāo), HR (Hit Ratio)值、MRR (Mean Reciprocal Rank)和MAP(Mean Average Precision)對API推薦效果進(jìn)行評估.HR評價的是在前K個搜索結(jié)果中, 正確結(jié)果占所有正確結(jié)果的百分比； MRR是指出現(xiàn)第一個正確結(jié)果的位置； MAP為所有正確結(jié)果的排名. 由于與查詢相關(guān)的API個數(shù)在10以內(nèi), 因此本文設(shè)置K=10. 以最新API推薦系統(tǒng)——BIKER[1]作為基線, 進(jìn)行API推薦效果的對比, 結(jié)果如表4所示.

由表5可知, 本文AKG-CMISF的HR比BIKER提高了49%, MRR提高了22%. 表明在搜索的前10個結(jié)果中, AKG-CMISF能夠搜索到更多與查詢相關(guān)的API, 并且比BIKER更早找到第一個正確API. 由此可見, AKG-CMISF相比于BIKER, 檢索效率有所提高.表6表示在時間成本方面, AKG-CMISF的構(gòu)建時間較長, 主要集中在分類器的訓(xùn)練和摘要生成, BIKER的構(gòu)建時間較短, 主要集中在詞嵌入模型的訓(xùn)練. 雖然本文方法構(gòu)建的時間成本高于BIKER, 但查詢時間縮短了一倍, 提高了API的檢索效率.

表5 和基線API推薦方法對比

表6 和基線方法在時間成本方面的對比

3.2.3 多源信息融合對API推薦的有效性分析

本實驗對比多信息源融合的API知識圖譜和單信息源的API知識圖譜對API的推薦效果, 以此驗證多源信息融合對API推薦的有效性. 單信息源的API知識圖譜構(gòu)建分別從API參考文檔和SO問答網(wǎng)站中提取API相關(guān)知識. 從API參考文檔提取的知識包括API實體、領(lǐng)域概念實體以及它們之間的關(guān)系； 從SO問答網(wǎng)站提取的知識包括API實體、API概念實體、問答QA實體以及它們之間的關(guān)系體.

由表7可知, 多信息融合的推薦效果優(yōu)于單信息源. 信息融合將與問題相關(guān)的API通過提及的概念間接關(guān)聯(lián)起來, 提高了推薦效果. 值得注意的是, 基于API參考文檔和基于SO問答網(wǎng)站的推薦效果相比差距較大. 分析原因可能是: API參考文檔提供的功能描述不涉及具體應(yīng)用場景, 因此它包含的領(lǐng)域概念很難和具體問題中的關(guān)鍵詞對應(yīng)起來, 導(dǎo)致僅使用API參考文檔的推薦效果不盡人意.

表7 多源信息融合和單信息源推薦結(jié)果對比

4 結(jié)論

本文提出了一種基于多源信息融合的API知識圖譜構(gòu)建方法(AKG-CMISF). 該方法融合了API的功能和結(jié)構(gòu)信息以及SO問答網(wǎng)站中API在具體場景下的使用信息, 提高了API檢索的準(zhǔn)確性. 實驗從信息提取和API推薦效果兩個方面驗證了API知識圖譜的有效性. 與現(xiàn)有API推薦系統(tǒng)相比, 本文基于API知識圖譜的推薦方法在常見指標(biāo)上均有提升. 同時通過實驗驗證了基于多信息源的API推薦效果相較于單信息源有明顯提升.

下一步工作將基于該方法研發(fā)API知識圖譜構(gòu)建工具, 并將其應(yīng)用在多個項目的API推薦.