基于多源信息融合的API知識圖譜構建①

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

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

1 引言

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

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

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

為驗證本文提出的方法, 分別從知識抽取的準確度和推薦應用兩個角度, 對本文構建API知識圖譜的有效性進行評估. 實驗結果表明, 和現有API推薦系統相比, 本文構建的知識圖譜的API推薦效果和效率均有提升, 表明了API知識圖譜的有效性以及多源信息融合對API推薦效果的支撐.

2 基于多源信息的API知識圖譜構建

本文從API參考文檔和SO問答網站提取API相關知識, 通過兩類API知識的融合, 構建API知識圖譜, 其框架如圖1所示.

圖1 基于多源信息的API知識圖譜構建框架

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

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

2.1.1 API參考文檔的知識表示

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

2.1.2 API參考文檔的知識提取

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

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

每個API都對應一個功能描述, 功能描述隱含領域概念, 因此, 從這種對應結構中可提取API和領域概念之間的“提及”關系. 如API “torch.normal”的功能描述中包含領域概念“standard deviation”. 當領域概念“standard deviation”被識別后, 則可在API“torch.normal”和領域概念“standard deviation”之間建立“提及”關系.

2.2 面向SO問答網站的知識獲取

SO問答網站含有API的具體應用場景信息, 可與API參考文檔互為補充. 本文主要對SO問答網站標簽為“PyTorch”的問答進行知識的表示及獲取.

2.2.1 SO問答網站的知識表示

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

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

2.2.2 SO問答網站的知識提取

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

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

為提取SO網站的問答QA實體, 本文通過機器學習算法對提問的目的進行分類, 獲得目的類型, 在此基礎上, 進行基于特征提取的回答摘要生成, 實現問答QA實體的提取.

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

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

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

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

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

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

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

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

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

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

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

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

2.3 知識融合

為對API參考文檔和SO問答網站的API知識進行融合, 構建完整的API知識圖譜, 本文分別從API實體和API概念實體、API概念實體和領域概念實體以及API實體和問答QA實體之間, 進行知識融合.

2.3.1 基于詞共現的API實體和API概念實體之間的融合

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

如式(3)所示,freq(Ai→Acj) 表示APIAi和API概念Acj的共現頻率,α為其閾值. 當共現頻率不低于閾值α時, APIAi和API概念Acj之間可建立“提及”的關系.

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

API概念和領域概念的融合是指建立API概念和領域概念之間的關聯關系, 這種關聯關系有助于建立API之間的間接關聯, 以提高檢索到相關API的可能.

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

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

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

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

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

3 實驗設計及結果分析

3.1 實驗設計

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

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

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

3.2 實驗結果與分析

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

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

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

表2 10個查詢問題以及相關API個數

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4 結論

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

下一步工作將基于該方法研發API知識圖譜構建工具, 并將其應用在多個項目的API推薦.