基于上下文感知并面向多樣性的API 推薦

賴寶強 李 征 趙瑞蓮 郭俊霞

（北京化工大學信息科學與技術學院 北京 100029）

基于軟件復用和模塊化開發的原則，現代軟件系統的開發通常需要使用外部庫.開發者基于一些基礎庫、第三方庫或者一些常用框架，能夠快速地構建編程環境、實現編程任務、提高開發效率.有研究表明[1]，在超過5 000 個軟件項目的研究中，45%的應用程序編程接口（application programming interface，API）是直接從第三方庫導入的.

因此，在軟件開發過程中，開發者常常面臨API使用問題.在不熟悉的編程任務面前，開發者可能不知道使用哪些API 能對編程任務更有幫助.除此之外，如果缺乏相關的編程經驗，開發者也可能不了解一些API 的具體使用方法.在這些情況下，開發者可能會查閱官方幫助文檔，或者通過代碼開源平臺和相關論壇查詢、搜索代碼示例，從而學習API 的使用.然而當前很多官方文檔存在質量問題[2-3]，且通常只提供API 的描述信息而不提供代碼示例[4].利用一些非正式的平臺或者論壇進行檢索和學習也會面臨許多障礙[5]，并且這些返回的搜索結果可能是錯誤的、不完整的[6].開發者需要花大量時間去篩選和測試才能找到自己需要的API 及其使用示例.

近年來，研究者們提出了各種方法為開發者推薦合適的API 及其使用模式，從而促進開發者對API的學習和使用.API 使用的模式推薦方法通常是從大型代碼庫中挖掘API 的使用模式，然后通過有顯式或者無顯式的查詢匹配這些使用模式[7]，最終推薦符合條件的API 元素或者代碼片段.

API 使用模式推薦的關鍵是API 的預測與推薦.主要有基于序列模式挖掘的方法、基于自然語言處理的方法以及基于機器學習的方法.基于序列模式挖掘的方法主要是利用序列模式挖掘算法挖掘API調用序列[8-10]，根據API 使用頻率進行預測，但是得到的模式通常包含很多重復子序列和無關子項，造成結果的冗余，即存在模式爆炸問題[11].此后有研究人員提出使用圖結構來表示API 調用序列[12]，并利用NGram 語言模型思想計算子圖的生成概率，從而預測對應的API.但是當上下文信息變得復雜時，子圖的生成效率變低，也容易出現長距離依賴問題.有研究人員提出基于神經網絡的方法來解決自然語言處理的長依賴問題.例如利用深度學習模型RNN 學習API 調用序列[13-14]，從而預測下一步API 出現的概率.也有利用圖深度學習模型GCN 融合拓撲信息和API文本屬性[15]學習圖結構的表示，從而預測潛在的API.這些方法主要利用API 上下文結構信息學習API 的特征表示，然而API 之間細粒度的關系表示還不夠充分，導致難以區分API 之間的差異性.

文獻[8-15]方法在基于上下文的API 推薦場景中，以當前正在編寫程序的項目或者方法中的API調用信息作為上下文，然后利用上下文的結構信息或語義信息對API 進行預測.利用結構信息的方法通常結合API 調用序列或者上下文結構進行分析，然后基于API 使用頻率對候選API 進行預測.利用語義信息的方法主要對上下文的語義特征進行分析，然后根據候選API 與上下文的語義相似性進行預測，最后根據候選API 預測值大小進行排序推薦.然而這些方法形成的推薦列表，由于上下文信息考慮不充分，會導致推薦列表中冗余項和同質化內容的出現，影響推薦性能.主要有3 種情況出現：

1）基于API 序列結構的方法通常只考慮API 之間的調用關系，導致一些與上下文語義不相關的API也被預測和推薦.例如，假定API 元素A，B，C能夠組成2 組序列模式L1=（A,B）和L2=（A,C），結合上下文的API 調用序列進行預測，當推薦A時，根據使用頻率，B，C也將被預測成為候選API.如果L1與上下文語義相關，那么C為冗余項.當冗余項變得越來越多時，一些使用頻率較高但與上下文語義無關的API因為預測值大而排在推薦列表前面，推薦性能受到影響.

2）基于上下文結構的方法通常會考慮上下文的語義關系而不考慮API 之間的調用關系，導致推薦結果容易出現模式冗余.例如，由1）中2 組序列模式L1=（A,B）和L2=（A,C）可知，如果L1和L2都與上下文語義相關，那么將同時推薦L1和L2組成的API 使用模式.由于B，C不是有效的使用關系，同時推薦B，C容易造成模式冗余，其中，C為模式L1的冗余項，B為模式L2的冗余項.這種情況造成一些不存在使用關系的API 作為使用模式被推薦在列表中也會影響推薦性能.

3）當前基于語義信息的推薦方法通常考慮的是項目與API 或者方法與API 的語義關系，缺乏API 之間細粒度關系的考量.當推薦列表中存在能夠實現相同功能的API 時，且這些API 之間具有類似的屬性，那么API 之間差異性小，由于不區分API 之間的差異性，容易造成部分結果同質化.當一些具有類似屬性的同質化API 也被推薦系統考慮而占用了推薦列表位置時，會影響推薦性能.

針對這3 種情況，本文從不同粒度考慮API 的使用關系，充分利用上下文結構和語義信息，對現有不同粒度的研究方法進行改進，使它們能夠利用更多的特征信息，得到更好的推薦結果；然后再對這些方法推薦的相關結果配以關聯性分析結果后進行重排，減少推薦列表中前排冗余項和同質項，從而增加推薦列表中有效API 的比例，提高推薦準確率和平均精度.本文以圖模型為對象，提出一種基于上下文感知并面向多樣性的API 推薦方法，（context-aware based API recommendation with diversity,CAPIRD）.

本文的主要貢獻有4 點：

1）提出一種名為AHC (GAPI hierarchy call graph)的API 層次調用圖模型，從不同粒度上表示API 的上下文關系，為相關性和關聯性的分析服務；

2）基于AHCG 模型分別構造項目上下文和方法上下文的協同信號，進而感知相似的API 上下文，縮小候選API 的范圍，減少上下文冗余項的出現，并度量相關性；

3）基于AHCG 模型構建API 關聯圖，考慮細粒度的API 結構關系，挖掘已選API 的關聯模式，減少模式冗余項的產生，并度量關聯性；

4）提出一種相關性與關聯性的線性組合算法，并從標準模式中學習最佳權重組合，對候選API 進行重排推薦，降低推薦列表中同質化API 出現的可能性，提高推薦結果的準確率.

1 相關工作

研究人員提出了許多API 推薦方法和工具，來幫助開發者搜索和學習API 的使用.根據API 推薦場景，目前主要有2 類方式，即有顯式查詢推薦和無顯式查詢的推薦[7].

1.1 有顯式查詢的API 推薦

有顯式查詢方法主要是根據關鍵字或者自然語言顯式地表達開發者的意圖，然后進行代碼或API的搜索，最終推薦相關的API 使用模式.例如，RACK[16]，NLP2API[17]通過自然語言查詢Stack Overflow 上Q&A中的API 使用知識.DeepAPI[14]將用戶查詢作為源語言，API 調用序列作為目標語言，利用RNN 編碼-解碼器模型解決問題.CODEnn[18]將自然語言描述和代碼片段嵌入到高維的向量空間，使用戶可以通過自然語言查詢相關的代碼片段.BIKER[19]融合Stack Overflow 上的Q&A 和API 文檔來彌補自然語言和代碼之間的詞法和知識代溝.SSAPIR[20]將API 描述信息和查詢信息構建為同一向量空間模型，利用TF-IDF算法計算向量空間中每個詞袋的語義特征，然后基于語義相似度匹配API 使用模式.GeAPI[21]使用圖嵌入技術學習API 圖的語義表示，根據用戶查詢返回相似的子圖.PreMA[22]提取了API 文檔中的功能性詞匯用于計算用戶查詢和功能語句的相似性.BRAID[23]利用開發者的反饋信息，通過主動學習和學習排序（LTR）技術，使得推薦結果更穩定.

1.2 無顯式查詢的API 推薦

無顯式查詢方法主要是從API 上下文中研究開發者的編程意圖，從而挖掘或者預測相關的API 信息.一些經典的工具如MAPO[8]，UPMiner[9]，PAM[10]，分別通過序列挖掘算法、聚類算法和EM 算法挖掘API 調用序列并用于API 推薦.文獻[24]通過將API使用對象和共現關系構建為關系網，將網絡中相似對象的使用作為相似API 使用模式.SALAD[25]使用隱馬爾可夫模型學習API 調用序列，從而根據上下文中的API 調用序列預測下一步候選API 被使用的概率.FOCUS[26]將客戶端方法視為用戶，將API 調用視為物品，利用協同過濾算法推薦相似的API 使用模式.HiRec[27]通過分析API 調用之間的層次結構，利用層次推理模型預測可能匹配的API.APIRec-CST[28]利用門控圖神經網絡（GG-NNs）學習結構信息的向量表示，利用序列神經網絡（如LSTM）學習文本信息的向量表示，連接GG-NNs 和LSTM，然后對目標Hole 位置的API 進行預測.GAPI[15]融合API 調用的結構信息和API 的文本屬性，利用圖學習技術從API的調用關系中捕捉高階協同信號，從而發現與API上下文相似的候選API.

2 相關定義

API 使用模式推薦示意如圖1 所示，假設開發者編寫到光標處時遇到API 使用問題，不知道調用哪些API 或者怎么使用這些API 才能完成當前客戶端方法myWork 中的剩余編程任務.記開發者編程現場的上下文信息為Q.相關定義為：

Fig.1 Illustration of API usage patterns recommendation圖1 API 使用模式推薦示意圖

定義1.實體.表示遇到API 使用問題時所涉及的研究對象，有3 種，即項目實體、方法實體和API 實體.

開發人員在編程環境中正在編寫的項目稱為活動項目，正在編寫的客戶端方法稱為活動方法，活動方法所在項目即為活動項目.

定義2.上下文信息.用來刻畫某狀態下的實體關系和屬性信息，用四元組Q=（E，V，R，T）來表示.其中，E表示上下文中所研究的實體；V表示上下文中實體的屬性；R表示實體間的關系；T表示時間，反映某一時刻編程現場的上下文信息.

定義3.上下文相關性.表示上下文信息與API存在邏輯關系，定義為R1={（Q,i）｜sim1（Q,i）≥λ1，i∈Ei}.其中，Q表示上下文信息，i表示API 實體，Ei表示API實體集合，λ1表示閾值，sim1表示邏輯推斷函數.

定義4.API 關聯性.表示API 之間的邏輯聯系，通過API 實體之間的共同使用關系或屬性信息標識，其定義為R2={（mi,mj）｜sim2（mi,mj）≥λ2，mi,mj∈Ei}，R2表示API 實體mi和mj具有相似的使用關系或語義信息，mi和mj存在關聯性.其中，Ei表示API 實體集合，λ2表示閾值，sim2表示相似性函數.

定義5.API 層次調用圖（API hierarchy call graph，AHCG）.定義GAHCG={V,E}，其中節點集合V有3 種類型的節點，包括項目、方法和API；邊集合E表示項目和方法，以及方法和API 之間的層次關系.項目節點包括語料庫項目和客戶端項目；方法節點表示項目中定義的方法聲明；API 節點表示方法中的API 調用，其包括內置API 調用、第三方API 調用和本地方法調用.

3 面向多樣性的API 推薦框架

基于開發者活動項目的上下文信息，本文提出CAPIRD，整體框架如圖2 所示.CAPIRD 模型主要由4 個模塊組成：元數據結構提取模塊、相關性分析模塊、關聯性分析模塊和重排推薦模塊.元數據結構提取模塊主要是從項目源碼庫中提取項目、方法與API 的層次結構，并基于這些信息構建AHCG 圖；相關性分析模塊主要從項目和方法粒度上，計算上下文的特征表示，然后基于特征相似性感知相似的上下文，進而推斷與上下文相關API，并度量相關性；關聯性分析模塊從API 的粒度上，構建API 之間的細粒度使用關系，然后從中挖掘頻繁使用模式作為API關聯圖以獲得更充分的API 結構關系，并從圖中度量關聯性；API 多樣性重排從多樣性角度將相關性和關聯性進行線性組合，提升推薦性能.

Fig.2 The overall framework of CAPIRD圖2 CAPIRD 的整體框架

3.1 AHCG 圖模型構建

AHCG 圖用來表達API 與項目和方法之間的層次關系，從而能夠更好地利用元數據集中API 的結構信息對客戶端項目進行建模，并從不同粒度上表達API 在項目中的結構特性.

利用靜態分析工具解析每個項目的類文件信息，將提取的方法名稱、方法參數、方法體、API 名稱、API 參數作為元數據集.對于給定項目元數據集，AHCG 圖的構建過程為：

1）確定圖的項目節點集合P.確定元數據集中涉及的項目文件，并對不同項目進行編號，添加到P中.

2）確定方法節點集合U，以及項目和方法的關系邊E1.從項目起始編號開始，獲取項目所有類中定義的方法聲明，然后對這些方法進行編號，添加到U中，最后再建立該項目和方法的關系邊.例如，項目p解析后提取了方法u，那么p和u存在一條邊，即e1=（p,u），e1∈E1.

3）確定API 節點集合I，以及方法和API 的關系邊E2.從方法起始編號開始，依次提取方法中涉及的API 調用.然后判斷該API 是否存在，不存在，則添加新的API 節點編號到I中；否則從I中取出已存在的API 節點編號.最后建立方法和API 的關系邊.例如方法u中提取了API 節點i，那么u和i存在一條邊，即e2=（u,i），e2∈E2.

根據1）～3）步驟構建的結果示例如圖3 所示，節點Pi（i=0,1,2,3）表示項目節點，節點Uj（j=0,1,…,4）表示方法節點，節點Ik（k=1,2,…,7）表示API 節點，關系邊E1和E2都表示層次關系.E1表示P到U這一類邊的集合，E2表示U到I這一類邊的集合.

Fig.3 Illustration of AHCG model construction圖3 AHCG 模型構建示意

3.2 相關性分析

相關性分析模塊主要是基于上下文相似性對API進行預測，并盡可能減少冗余項的出現.上下文信息的分析包括活動項目上下文和活動方法上下文的分析.

2 個項目的相似性可由項目特征項的集合進行計算[29]，因此可以根據活動項目上下文的特征集合感知相似的項目集合，從而縮小候選API 搜索范圍.此外，為了給活動方法提供相關的API 使用建議，還需要研究活動方法上下文的API 使用信息.

基于AHCG 的圖模型可知，項目節點和方法節點這2 類節點包含的API 使用信息規模不同，因此針對這2 類節點的上下文信息，分別使用不同的特征提取方法提取特征.然后從相似項目集合中計算活動方法與目標API 的相似性.

3.2.1 基于項目上下文的特征提取

項目上下文反映項目中的API 使用情況，本文通過評估不同項目中API 的被使用情況反映項目上下文的特征，利用TF-IDF 算法進行計算.其中，特征TF表示API 在當前項目中的使用頻率，特征IDF反映API 在整個項目源碼庫中的普遍性.

從AHCG 中的項目節點開始，通過層次遍歷能夠得到API 節點集合.給定項目的API 節點集合p={i1,i2,…,in}，API 節點ik的特征TF計算如式（1）所示：

其中n表示集合p中API 節點的數量，表示API 節點ik的出現次數.

API 節點ik的特征IDF計算如式（2）所示：

其中|P|表示AHCG中項目節點的數量，表示AHCG中使用了ik的項目節點數量.

在整個項目源碼庫的體系下，API 節點ik在項目p中的被使用情況的計算公式為

給定項目集合p，那么p的特征可以用API 被使用情況的向量表示，即?p=

3.2.2 基于方法上下文的特征提取

方法上下文反映了方法中的API 使用情況，同時以方法為單位的程序在一定程度上隱含了代碼的語義信息，因此考慮方法和API 的文本屬性應該能夠增強上下文的語義表示.圖卷積神經網絡（GCN）[30]利用圖結構信息和節點屬性信息，能夠學習圖的特征表示.本文利用GCN 進行方法上下文的特征提取，其網絡結構主要由3 部分組成：輸入層、圖卷積層和輸出層.

1）輸入層.AHCG 圖的結構信息、節點初始化特征表示為e0，如式（4）所示.

其中x代表節點文本屬性信息，Θin是編碼函數Encode(·)待學習的參數，e0是編碼后的節點向量表示，分為方法u節點表示和APIi節點表示.

2）圖卷積層.其主要目的是聚合鄰居節點的協同信號，從而實現消息傳遞.主要任務是協同信號的獲取和節點向量的更新.

協同信號的獲取公式為

根據聚合函數的消息傳遞機制，AHCG 中節點最新的特征表示通過與鄰居節點的聚合更新得到，如式（6）所示：

其中聚合函數f(·)使用ReLU 函數實現.

3）輸出層.其獲得方法節點u和API 節點i的最終特征表示如式（7）所示.通過線性轉換層輸出k層卷積層的節點表示，然后對API 節點進行預測.

其中連接函數concat(·)將每一層節點的特征表示順序連接.

3.2.3 相關性度量

相關性度量的主要目的是根據上下文提取的不同粒度特征對目標API 進行預測，預測值越大，則API 與上下文越相關.因此，定義函數context（·）作為相似性度量的計算方法，從而適應不同粒度的研究方法.輸入是上下文信息Q和目標APIi，返回值是Q與i的相關性，如式（8）所示：

若Q是項目上下文信息，context（·）采用缺失評分算法[31]實現API 的預測并返回預測結果；若Q是方法上下文信息，根據式（7）中方法節點u和API 節點i的向量內積進行預測，即

3.3 關聯性分析

關聯性分析模塊的主要目的是從相似上下文中獲取API 關聯信息，并分別從結構和語義上分析API之間的相似性.從另一個角度看，相似API 可以反映相似的上下文[32]，因此相似的上下文中有可能隱含相似API.本文基于活動方法上下文和AHCG 圖模型構建API 關聯圖，增強細粒度的API 結構表征，并從中挖掘API 的關聯模式；再基于關聯模式，分別從結構關系和語義信息上度量API 之間的關聯強度.

基于AHCG 圖模型，API 關聯性分析模塊的分析對象是方法節點和API 節點.

3.3.1 關系構建

基于方法特征的向量表示，利用余弦相似性計算活動方法與其他方法的相似性，將相似性值大于0 的方法作為相似方法.將這些相似方法中使用的API 作為節點、共現關系作為邊，構建API 關聯圖.如圖4 左圖所示，節點I 表示API，邊表示2 個API 在方法中具有共同使用關系，邊權重表示2 個API 在方法中的共現次數.為了挖掘目標API 在相似上下文中的關聯程度，本文基于AHCG 圖模型將關聯關系保存在圖數據庫中，如式（9）所示：

Fig.4 Illustration of subgraph mining for associated target nodes圖4 關聯目標節點的子圖挖掘示意圖

其中Ui為AHCG 中第i個相似的方法節點，表示節點Ui構建的API 關聯圖，和分別表示Ui中的API 節點和共現關系構成的邊.

3.3.2 關聯模式挖掘

基于AHCG 圖模型，本文將API 之間關聯關系的發現轉化為頻繁子圖的挖掘.為了避免圖匹配過程的子圖同構問題[33]和挖掘的模式出現冗余問題，本文鎖定目標節點避免子圖任意擴展，將挖掘的關聯模式覆蓋在目標節點關聯的子圖上避免冗余輸出，進而提出關聯目標節點的子圖挖掘方法.首先將目標節點作為初始節點，基于AGM 算法[34]思想，通過添加新節點產生候選子圖，為防止候選子圖任意擴展，對目標節點的高階鄰居節點進行剪枝，使挖掘的子圖作為目標節點關聯的子圖.記錄目標節點關聯新節點的2 階子圖的支持度，丟棄支持度不符合條件的候選2 階子圖，針對圖4（a）關聯圖的挖掘結果如圖4 右圖所示.

具體的關聯目標節點的子圖挖掘算法如算法1所示，主要有4 個步驟：

1）首先設定支持度閾值，然后從相似的數據集合中構建關聯圖數據庫，將不同的API 節點進行編號；

2）在目標節點上添加新節點進行子圖擴展，對目標節點的高階鄰居進行剪枝，只保留與目標節點有直接關聯關系的目標子圖；

3）計算目標節點與新節點構成的2 階子圖的支持度，將未達到閾值的子圖丟棄；

4）將滿足條件的2 階子圖添加到目標子圖上，當所有節點都被訪問時，生成最終的關聯目標節點的子圖d(i)，其中i表示目標API 節點.

最終，API 關聯子圖d中包含了API 之間各種可能的使用模式，可以為開發者展示更多可能性.

算法1.關聯目標節點的子圖挖掘算法.

輸入：上下文信息Q，API 節點i，支持度minsup；

輸出：節點i關聯的子圖Gi.

3.3.3 關聯性度量

關聯性度量的主要目的是度量2 個API 之間的相似性，分別從結構關系和語義關系上進行度量.關聯性越強，說明2 個API 相似的可能性越大.本文定義函數correlation（·）作為關聯性度量的計算方法，從而融合不同類型關系表示的研究方法.輸入是2 個API 節點i和j，返回值是i和j的關聯性，如式（10）所示：

若度量API 的結構關系，correlation（·）計算節點i與j的權重系數，由節點i和j的2 階子圖的支持度與圖數據庫數量的比值得出；若度量API 的語義關系，利用圖嵌入技術[15]將圖d中i節點的特征表示zi和節點j的特征表示zj進行內積，從而計算2 個節點的語義相似性，即

3.4 API 多樣性重排推薦

API 多樣性重排推薦的目的是優化有效API 在推薦列表中的排名，減少冗余項和同質化內容的產生，使得推薦結果在保障推薦性能的前提下具有更好的多樣性.

根據最大邊緣相關（MMR）算法[35]的思想，通過結合查詢內容的相關性和推薦內容的新穎性能夠增加推薦結果的多樣性.新穎性反映了推薦內容之間的差異性程度，若推薦內容之間差異性小容易造成內容同質化，即相同結構關系或功能屬性的API 同時被推薦.適當調整一些同質化內容在推薦列表中的排名，能夠改變推薦內容的多樣性.

本文在保持上下文相關性的同時，協調推薦內容之間的差異性來增加推薦結果的多樣性.推薦內容之間的差異性可以通過API 之間的關聯性進行度量，調整相關性和關聯性權重能夠使推薦列表展示更多可能的情況.因此，重排推薦的目標是找到合適的平衡參數，從而降低推薦列表中同質化內容出現的可能性，提升有效API 被推薦的可能性.相關性分析模塊和關聯性分析模塊分別度量了上下文與API之間的相關性和與API 的關聯性.利用式（11）之間將相關性和關聯性進行線性組合來度量每個API 被推薦的可能性：

其中Q表示上下文信息，R表示候選API 集合，S表示R中已被選擇的API 集合，RS表示R中未被選擇的API 集合；1用于上下文信息和API 之間相關性的度量，用于API 之間關聯性的度量，參數 λ用來度量sim1和sim2的權重.

根據式（11），當參數 λ=1 時，MMR表示標準的相關性API 推薦結果；當參數 λ=0 時，MMR表示最大的多樣性推薦結果.這些API 推薦結果是一種線性組合，本文利用算法2 所示方法從標準模式的訓練數據集中獲取能夠平衡相關性和關聯性的最佳參數.

算法2.Top-N參數優化算法.

輸入：上下文信息Q，API 候選集合R；

輸出：Top-N（N=1,5,10,15,20）的最佳參數topNLambdas.

給定訓練數據集，首先計算相關性條件下的性能指標，并以該指標作為該訓練集的基準.然后結合API 多樣性重排算法計算不同參數下Top-N的評價指標，迭代計算每一次參數采樣的評分，選擇評分最優時Top-N取得的參數作為該數據集的最佳參數.

4 實驗與結果

為了驗證所提API 推薦方法的有效性，本文使用真實的軟件項目模擬開發者的編程場景，并在3個不同的數據集上進行實驗驗證，且與方法FOCUS和GAPI 進行對比實驗.

本文實驗的硬件和系統環境為Intel Xeon Gold 6148 處理器、256.0 GB RAM、Nvidia V100 GPU 的Linux 64 位服務器；Intel?CoreTMi7-10700 2.90 GHz 處理器、16.0 GB RAM 的Windows 10 64 位操作系統；使用的軟件環境有JDK 1.8，Python3，PyTorch 等.

4.1 數據集

本文采用文獻[26]中所使用的開源數據集，其中數據集SHL 是從Github 軟件遺產存儲庫中任意提取的610 個Java 項目；數據集SHS 是在SHL 中篩選出的200 個最小項目；數據集MV 是從Maven 中央倉庫中提取的1 600 個JAR 項目，且不同版本的同一JAR 項目只保留其中一個版本.

基于原始數據集，首先解析項目源碼庫構建元數據集，并從中構建AHCG 模型，提取初始特征.表1詳細統計了上述3 個數據集的相關信息，包括用于上下文模型輸入的項目特征和方法特征.其中項目特征指每個項目中API 的TF-IDF 特征，由于每個項目的API 不同，本文統計了每個項目平均調用的API數作為該數據集的平均項目特征數.方法特征采用文獻[15]的方法，利用駝峰式拆分法將方法名稱和API 名稱拆分為單詞序列并作為節點的文本屬性，這些單詞在相同的向量空間中進行編碼和對齊，方法節點的特征維度與單詞數有關，因此統計數據集中不同單詞數作為方法特征數.

Table 1 Meta Datasets Statistics for Experiments表1 實驗元數據集統計數據

4.2 實驗設置

為了評價本文方法的有效性并與其他方法形成對比，遵循前人的研究方法對實驗進行離線評估.實驗將軟件項目中的部分代碼抽取出來，從而模擬開發者編程現場及API 上下文的使用情況.具體規則是：將項目節點P下的方法節點U按照編號順序排成數組，然后按照不同比例劃分為訓練集和測試集.測試集中每個方法節點下的API 節點按照編號順序排成數組，然后保留前4 個API 節點來模擬開發者已完成的代碼，剩余的API 節點作為該測試方法的標準數據，用以驗證在當前開發情景下的推薦性能.本文使用10 折交叉驗證法，將數據集劃分成10 份.每一份進行1 輪訓練與驗證，并且每一輪驗證的時候，將其中9 份數據作為訓練集，1 份作為測試集.最后取這10 輪測試結果的平均值作為該數據集的最終實驗結果.

4.3 評價指標

API 使用模式推薦場景中，一般通過Top-N的API排名情況評價推薦結果的有效性.本文使用成功率（S@k），精確度（P@k），召回率（R@k）和平均精度（MAP）來評價方法在Top-N上的推薦性能.給定測試集合M，其中的測試項表示方法節點，用來模擬當開發者遇到API 使用問題時，給該方法節點對應的方法聲明提供API 使用建議，推薦列表中將包含開發者接下來可能調用的API.設RECk（q）表示本文CAPIRD模型在一個測試項q中輸出Top-N的API 推薦結果集合，GT（q）表示一個測試項q的標準API 集合.

S@k反映測試集預測成功的比例.

其中count表示滿足條件的測試項數量.

P@k反映在推薦列表中有效API 的占有比例.

R@k反映推薦列表中有效API 的數量在標準列表中的比例.

MAP的計算公式為

4.4 基線方法

為了更好地評價本文方法，設計了2 個對比實驗，分別與相同場景下的2 個基線方法進行比較.

1）FOCUS.FOCUS 發表于2019 年，是近3 年高被引用的方法.FOCUS 基于項目上下文，使用協同過濾技術挖掘并推薦API 使用模式.它將方法聲明視為用戶，將API 調用視為物品.因此，FOCUS 能夠推薦相似項目中類似的API 使用模式，從而縮小搜索范圍，減少冗余.

2）GAPI.GAPI 發表于2021 年，是目前公開文獻中在相同實驗數據集下實驗效果最好的方法.GAPI是一種基于方法上下文和GNN 技術的API 使用模式推薦方法.它利用項目中方法與API 的交互關系，融合API 文本屬性，從拓撲網絡上學習API 的Embedding 表示，從而給相似的方法推薦相似的API使用模式.

4.5 實驗結果分析

從推薦性能和多樣性表現2 個方面進行實驗設計，針對提出的2 個研究問題，依次進行實驗驗證與分析.

問題1：本文CAPIRD 模型在API 推薦性能上表現如何.

為了檢驗CAPIRD 在API 推薦上的效果，本文在3 個數據集上分別比較Top-N推薦結果在不同指標上的性能表現.實驗前，對比實驗設置了相同的實驗環境；實驗時，針對不同類型上下文的基線方法FOCUS 和GAPI，在CAPIRD 相關性分析中實現不同類型基線方法的相關性計算，計算結果作為基線各自的相關性分析結果，并將該結果作為后續重排模塊的參數優化基準.然后再融合CAPIRD 方法的關聯性推薦和重排推薦，最終將推薦結果分別記為CAPIRD-FOCUS 和CAPIRD-GAPI.根據最終結果驗證CAPIRD 融合基線方法在API 多樣性推薦上的有效性.在3 個數據集上S@k和MAP的實驗結果分別如表2～4 所示.

Table 2 Comparison Result of S@k and MAP on SHS Data Set表2 SHS 數據集上S@k 和MAP 對比結果

Table 3 Comparison Results of S@k and MAP on SHL Data Set表3 SHL 數據集上S@k 和MAP 對比結果

Table 4 Comparison Results of S@k and MAP on MV Data Set表4 MV 數據集上S@k 和MAP 對比結果

由表2～4 結果中的MAP指標可以看出，CAPIRD 在MAP的表現明顯優于基線方法.尤其是在SHS 數據集上，在GAPI 方法的基礎上融合本文方法后，MAP由0.292 4 提升至0.370 9，其推薦的平均精度提升約27%，在S@1 上由0.377 提升至0.577，提升了約53%.而在數據集MV 上相對來說并不太顯著，尤其是在以圖學習模型為基礎的GAPI 上MAP及S@k 上提升相對較小.這是因為隨著數據量的增加，圖學習機制作用顯著，能夠捕捉更多高階協同信號，使得API 推薦的多樣性也增加.而融合本文方法依然有小幅度提升，說明CAPIRD 依然能夠在保持原有多樣性推薦結果的基礎上，通過增加候選結果的差異性，使得推薦性能較原推薦性能有所提升.在以傳統協同過濾算法為基礎的FOCUS 上融合CAPIRD 后的MAP提升在3%～15%，在大數據集上相對穩定.因此，在3 類不同的數據集上，本文CAPIRD 模型在MAP指標上都得到了有效提升.

在實際的開發場景中，假設開發人員遇到API使用問題，當系統為其提供合適的API 推薦列表時，那么開發人員更希望列表中靠前的API 是對其有幫助的.為了體現CAPIRD 模型在這種場景中的推薦性能優勢，需要分析S@1 和S@5，同時結合S@20 的成功率和MAP，分析模型的有效性.

由表2～4 所示，CAPIRD 模型在S@1 和S@5 相比S@20 具有顯著效果.在S@1 上，CAPIRD 模型在所有數據集上平均提升約13%，說明第1 個推薦的API 與上下文最相關且又能夠區別于其他已使用的API，因此也更可能是開發者在當前編程場景下想使用的API.S@5 在所有數據集上平均提升約6%，其中CAPIRD 在SHS 數據集和基線方法GAPI 比，S@5 由0.692 提升到0.813，提升約17.5%.

在S@20 上，所有數據集相差不大，平均提升僅約2%，說明在Top-20 推薦列表中，CAPIRD 模型推薦的API 與基線方法推薦的API 差異不大，而結合CAPIRD 改變了原有推薦結果的排序，在所有數據集的MAP指標上平均提升約9%.說明Top-20 推薦列表中有效API 的排名得到提升，達到本文多樣性重排推薦的預期.因此，CAPIRD 模型在API 使用模式推薦場景中能夠有效提高S@k，同時提高有效API在推薦列表中的排名.

問題2：CAPIRD 模型中決定相關性和關聯性推薦所占比重的參數對結果的影響如何.

在API 多樣性重排模塊，本文利用MMR 算法將相關性和關聯性進行線性組合.以方法CAPIRD-FOCUS為例，當參數λ=1時，方法CAPIRD-FOCUS 與基線方法FOCUS 的結果是一樣的，因為此時關聯性度量的權重為0.實驗通過調整參數 λ，使得關聯度的權重發生變化，觀察在不同參數 λ下模型的表現能力.采用等間距的控制重排采樣樣本調節參數 λ，觀察MAP在不同參數 λ下的影響.MAP在不同數據集上的變化趨勢如圖5～7 所示.

Fig.5 The changes of MAP on SHS data set圖5 MAP 在SHS 數據集上的變化

Fig.6 The changes of MAP on SHL data set圖6 MAP 在SHL 數據集上的變化

Fig.7 The changes of MAP on MV data set圖7 MAP 在MV 數據集上的變化

圖5～7 中，橫軸表示參數 λ的取值，縱軸表示該數據集上的MAP.實線表示基線方法，由于不需要進行重排，因此基線的曲線不發生變化.虛線表示增加重排后的結果，在3 個不同數據集上其對應曲線都發生了變化.

圖5～7 中，虛線對應曲線整體上都表現出了類似的變化趨勢，即隨著 λ的增大，對應的MAP值整體呈現先增后減的趨勢.虛線對應曲線位于實線對應曲線上方的部分表示增加重排后的MAP優于基線方法的MAP.由圖5～7 中的6 個曲線圖可以看出，MAP在這個部分能夠達到某個峰值，該峰值對應λ的值為該樣本空間內的最佳參數.例如在圖5(b)的曲線圖中，λ取值在0.7～0.8 之間時，MAP的值達到峰值.說明 λ在該區間內，關聯性的度量發揮了最大作用.

當 λ發生變化即關聯性的權重發生變化，MAP也發生變化，說明推薦列表中候選API 的排名也發生了變化.進一步觀察3 類數據集最佳參數的取值，發現隨著測試集數據量的增加，達到最佳參數的取值越接近1，說明數據量越大，要達到MAP最優時的關聯性權重越小.這是由于數據量變大時，API 之間關聯性的差異性變小，使得MAP提升的表現并不明顯，但是推薦結果仍發生變化.

綜合以上分析，本文提出的CAPIRD 模型，能夠通過關聯性分析增加候選API 的多樣性，同時也能夠保證推薦結果的有效性，提高推薦性能.

5 結論

本文為了提高API 推薦性能，提出了基于上下文感知并面向多樣性的API 推薦方法CAPIRD.CAPIRD 是一種結合上下文相關性和API 關聯性的推薦方法.通過相關性分析，發現上下文相關API，然后度量相關性值；通過關聯性分析，挖掘API 的關聯模式，發現與目標API 關聯的其他API，然后度量關聯性值；最后利用MMR 算法線性組合相關性和關聯性，協調純相關API 與純關聯API 的比重，增加候選API 中的差異性，提高推薦性能.

采用3 個數據集進行驗證實驗，在與2 個基線方法的對比實驗中，CAPIRD 在MAP，S@1，S@5 都有提升，其中在MAP的平均提升率約為9%，S@1 的平均提升率約13%.實驗結果充分表明，CAPIRD 在API使用模式推薦場景中具有更好的表現.

CAPIRD 利用的上下文信息有限，如何更充分地利用上下文信息來推斷開發者的編程意圖，是未來工作需要探索和思考的.

作者貢獻聲明：賴寶強負責論文方法的設計與實現，并撰寫論文；李征負責論文整體結構的審核；趙瑞蓮負責論文的指導與校對；郭俊霞提供方法和實驗指導，并修改和審核論文.