基于多源數據融合的Java 代碼知識圖譜構建方法研究

蘇 佳, 蘇小紅, 王甜甜

(哈爾濱工業大學 計算機科學與技術學院, 哈爾濱150001)

0 引 言

知識圖譜(Knowledge Graph)是Google 在2012年正式提出的概念,它以圖的形式來表達客觀世界的實體(概念,人,事物)以及實體之間關系的知識庫,后來得到廣泛關注和應用研究。 以其大規模、可解釋、可推理等特點,現已經應用于智能問答、語義搜索、可解釋推薦、情報分析、決策支持、知識導航和醫療等領域。

知識圖譜是一個由知識和知識間的關系組成的結構化的語義知識庫,典型的知識圖譜采用三元組(頭實體,關系,尾實體)描述事實。 知識圖譜每個節點表示客觀世界中存在的概念或者實體,邊則描述概念或者實體之間的語義關系。 知識圖譜提供了一個通用的結構化框架來存儲和表示知識,從而實現基于實體和關系的挖掘、推理和分析。 在軟件工程領域,代碼知識圖譜目前研究較少,相關表示方法主要有以下幾種：

Zeqi Lin 等人［1］分析了代碼中的結構化信息,提取代碼元素之間的結構依賴關系(方法調用、繼承關系)來構造代碼圖譜(Code Graph),再利用TransR 方法學習共享表示空間的嵌入表示,再計算tf-idf 為代碼元素加權,利用土堆移動距離(EMD),通過移動“分布質量”的方式,把一個分布轉換為另一個分布所需要的最小工作量,來計算文檔與代碼之間的距離；同一個團隊［2］又利用軟件源代碼中特定于軟件的概念知識來改進API 學習資源的檢索,利用Recodoc 和基于關鍵字的啟發式算法提取文本中的API,生成API Graph,每個查詢或文檔都表示為一個加權的API 實體集合。 利用多關系數據嵌入算法TransR 計算API 實體相似性,在傳統方法獲得的檢索排名基礎上,用成對的API 實體相似性來計算文檔和查詢之間的概念相關性得分,對API 學習資源檢索結果進行重排序(文檔獲得更高分數排到頂部,反之底部),提高檢索準確性。

Wang L 等人［3］從軟件歷史倉庫中收集bug 數據,如bug 報告、commit 提交信息、代碼文件等。 用自然語言處理技術對數據進行預處理,提取bug 描述信息和相關開發者的信息。 使用LDA 主題模型來處理bug 描述信息,建立不同數據之間的聯系。根據bug 報告的屬性(depend on 和duplicate)建立bug 之間的關系。 根據bug 描述信息的文本相似度,建立不同bug 之間的相似關系。 用同樣的方法建立commit 之間的相似關系。 最后利用bug id,來構建bug、commit 之間的關系,最終得到bug 知識圖譜(Bug Knowledge Graph)。

LiuMingwei 等人［4］爬取了API 官方文檔,提取了API 相關的結構性知識和描述性知識,來構建API 知識圖譜。 他們首次提出了API 概念,利用詞的詞匯相似性和上下文相似性,將詞進行層次聚類,連接API 的不同的描述性句子,建立refer to 關系。在通用知識圖譜的基礎上,用分類器獲取軟件概念,將軟件概念和API 概念、API 實體用句向量計算相似度并建立related to 關系,生成了更好的面向task的API 摘要。

不同的應用場景下,需要定義不同的知識圖譜的實體和關系來滿足不同的需要。 現有的代碼知識圖譜構建的數據來源都較為單一,缺乏對代碼解釋性知識的獲取和融合。

本文在分析代碼相關知識圖譜國內外研究現狀的基礎上,提出一種基于多源異構數據的Java 代碼知識圖譜構建方法,該代碼知識圖譜可用于代碼的知識檢索,代碼摘要等場景。

1 Java 代碼知識圖譜構建方法

1.1 Java 代碼知識圖譜設計

為了挖掘API 知識之間的顯、隱式關系和豐富代碼知識,引入了API 相關概念［4］,記為api＿concept 實體。 本文設計的代碼知識圖譜包含package、 class、 method、 functional ＿ description、question＿description、api＿concept 等6 種實體,以及haveClass、 extend、 haveMethod、 hasFunctional Description、hasQuestionDescription、referTo 等6 種關系。 構建流程如圖1 所示。

圖1 Java 代碼知識圖譜構建流程Fig. 1 Java Code Knowledge Graph Construction Process

本文將從github、API 官方文檔以及Stack Overflow 問答社區(以下簡稱SO)的Q＆A 對等三種數據源進行數據挖掘,提取Java 語言相關的代碼知識。 在獲取到來自不同數據來源的知識后,通過知識融合將它們合理、統一地組織到同一個圖網絡中,構建Java 代碼知識圖譜。

1.2 Java 代碼知識提取

本文將從三種數據來源中提取java 代碼的結構性知識、描述性知識以及概念和關系,并對這些不同來源的知識進行融合。 結構性知識主要包括API的相關實體,package,class,method,還有parameter和return values 等,在其他應用場景中還可以添加相關屬性,例如完全限定名稱,加入的版本號以及API Document URL。 代 碼 中 的 相 關 實 體, 除package,class,method 等外,還包括方法體內的API調用序列。 描述性知識主要包括來自API 文檔的功能性描述以及SO 的問題性描述,前者主要描述了API 的功能,后者主要描述了使用者使用時遇到的相關問題。

1.2.1 基于AST 的JAVA 源代碼的代碼知識提取

從github 獲取的源碼中提取的知識有：(1)類相關的實體和關系。 (2)方法相關的實體和關系。(3)方法體中的API 調用序列。 具體來說,本文通過源碼獲取的實體有package,class,method；關系有haveClass,extend, havaMethod。

抽象語法樹(Abstract Syntax Tree, AST),是通過使用樹狀結構來表示源代碼的抽象語法結構,它作為程序分析中一種重要的中間表示形式,在代碼分析、代碼重構、語言翻譯等領域得到廣泛的應用?，F有的一些相關工具中都含有將源代碼直接轉換為抽象語法樹的模塊。 用程序分析技術,通過解析源代碼的AST,遍歷包定義、類定義、成員變量表以及方法定義表,可以獲取所需要的結構性知識。 在方法體內提取API 調用序列,通過訪問methodInvoke節點,根據節點綁定的數據信息,進行正則匹配和過濾即可獲得API 調用序列,它除了作為代碼方法級別的一種知識,還在源代碼和代碼知識圖譜之間通過API 實體建立了聯系。

1.2.2 基于網絡爬蟲的API 文檔的代碼知識提取

基于網絡爬蟲從API 官方文檔爬取數據并提取代碼結構性知識以及描述性知識的流程如圖2 所示。

圖2 基于網絡爬蟲的API 文檔的代碼知識構建流程Fig. 2 Code knowledge construction process of API document based on web crawler

結構性知識提?。豪谜齽t表達式解析超鏈接,可以獲得package,class,method 實體,以及hasClass,hasMethod 關系。 識別表格中的＜td＞＜／td＞標簽,可以獲得returnType,parameter 屬性。

描述性知識提?。簽榱双@取完整的描述性知識,需要利用bs4 解析html 文檔,按以下規則進行網頁內容清洗：(1)恢復被“＜p ＞”和“＜li ＞”等標記打斷的句子；(2)＜blockquote＞＜／blockquote＞用“＿CODE＿＿”替換代碼片段；(3)＜code＞＜／code＞標簽直接過濾,留下內容。 其中,從API 官方文檔中提取的method description涵蓋了API 的功能描述以及使用方法,可以提供Java方法的相關信息,作為java 代碼的一種知識。

1.2.3 基于啟發式規則的Stack Overflow 代碼知識提取

從SO 中獲取知識,主要是獲取和API 相關的問題描述作為描述性知識,具體流程如圖3 所示。

圖3 Stack Overflow 的代碼知識構建流程Fig. 3 Code knowledge construction process from Stack Overflow

獲取SO 數據后,按照標簽＜java＞獲取Q＆A 對,并進行分詞。 由于問答語句是自然語言,是非結構化數據,為了將Q＆A 對和API 聯系起來,需要識別和API有關的Q＆A 對,并識別自然語言描述中的API 實體。

根據之前提取API 文檔中的API 實體,分別記錄全限定名稱和非限定名稱,按照以下啟發式規則,獲取Q＆A 數據和API 之間的對應關系：

(1)如果API 的全限定名稱出現在標題或者問題描述中,那么該問題和這個API 相對應。 (2)如果question body 中含有指向API 文檔的超鏈接,那么該問題和鏈接的API 相對應。 (3)如果question body中含有＜code＞標簽,那么該問題和＜code＞＜／code＞中間的非限定名稱對應；為API 實體和Q＆A 數據建立hasQuestionDescription 關系,如果一個API 實體對應多個Q＆A 數據,那么只連接score 分數最高的Q＆A。

為了增強可擴展性,本文在基于啟發式規則獲取到的Q＆A 對和API 的對應關系基礎上,采用NLP 領域中的命名實體識別模型和方法進行Java API 實體識別。

1.3 JAVA API 實體識別

命名實體識別(Named Entity Recognition,NER)是NLP 的基礎任務,指從文本中識別出命名性指稱項。 在本文中,將用來識別SO 中的Q＆A 語句中的API 實體。

條件隨機場(Conditional Random Field, CRF)是一種基于機器學習的方法,在馬爾科夫隨機場的基礎上增加了觀測變量,將所有特征進行全局歸一化,可以獲得全局最優解。 本文用啟發式方法選取如下特征來進行CRF 模型訓練：(1)當前詞是否首字母大寫,其他字母小寫。 (2)當前詞的詞性。 (3)前一個詞的詞性。 (4)當前詞是否含有“.”。 (5)當前詞是否全部為大寫。 (6)當前詞的后綴。 (7)當前詞是否含有數字。

近年來,越來越多的研究已經說明了深度學習在NLP 任務上的有效性。 BiLSTM-CNNs-CRF 在雙向LSTM-CNNs 的基礎上,加入了CRF,從而對于輸出序列進行優化。 BERT 是一個用Transformer 作為特征提取器的深度雙向預訓練語言理解模型,由多層的雙向Transformer 連接而成,利用Position Embedding 來學習位置信息, 通過訓練 MLM(Masked Language Model) 和NSP (Next Sentence Prediction)任務獲取到豐富的語言知識,在多種NLP 任務中獲得突破性進展。 將BERT 應用于NER 任務,只需用BERT 替換word embedding 來進行語義編碼。

本文使用CRF,BiLSTM-CNNs-CRF 以及用BERT 的三種模型對手工標注數據進行API 命名實體識別。

1.4 JAVA 代碼知識融合

為了將從不同數據源獲得的知識統一在同一個知識圖譜當中,需要對這些知識進行融合。 融合主要包括兩方面：一方面是API 實體融合；另一方面是API 概念的融合。

API 實體融合指的是根據API 實體名稱進行統一和融合,建立其他知識和API 實體之間的關系。利用API 官方文檔中獲取的API 知識,構建基本的API 知識圖譜作為基礎,再往API 實體上補充來自源碼的結構性知識,以及SO 的問題描述,最后將API 功能性描述和SO 上的問題性描述和API 概念相連接。

API 概念融合指的是從和API 相關的描述性知識中提取API 概念,作為描述之間的橋梁,從而建立描述性知識之間的關系。 本文中的API concept是由基本名詞短語構成,所以需要進行基本名詞短語提取。

依存句法分析(Dependency Parsing, DP) 通過分析語言單位內成分之間的依存關系揭示其句法結構。 使用語義依存刻畫句子語義,通過詞匯所承受的語義框架來描述該詞匯,而其數目相對詞匯來說數量小。 這個框架表示大部分的句子,同時也能據此迅速提取句子的核心內容。 本文使用斯坦福句法分析器(stanford corenlp)對前文提取的描述性知識句法分析并提取依存關系。 在句法分析后,獲取所有NP 節點作為候選節點。 在此基礎上,按如下規則進行剪枝過濾：(1)去除句法樹上子節點含有NP的節點。 (2)根據依存關系｛ compound 復合,nmod復合名詞修飾(只保留連詞or,and),amod 形容詞修飾(過濾常見詞) ｝,保留NP 內的節點。 (3)最后過濾停用詞和無關符號,即可得到該句所需要的API概念集合。 api＿conception 和對應的描述性語句之間建立(description,referTo,concept)關系,從而連接了不同的描述性語句。

1.5 JAVA 代碼知識圖譜構建和可視化

Neo4j 是一種圖數據庫管理系統,屬于原生圖數據庫,其使用的存儲后端專門為圖結構數據的存儲和管理進行定制和優化的,在圖上互相關聯的節點在物理地址也指向彼此,因此更能發揮出圖數據的優勢。 知識圖譜非常適合用Neo4j 進行存儲,基于Neo4j 生成部分java 代碼知識圖譜的可視化結果如圖4 所示。

圖4 java 代碼知識圖譜的部分可視化結果Fig. 4 Partial visualization results of Java code knowledge graph

2 實驗和分析

2.1 實驗設置

Q＆A 數據作為有標簽的樣本數據,標簽為Q＆A含有的API。 為保證數據的質量,從中按照score 得分,選取Top-2000 數據,進行人工標注,API 命名實體識別。 標注采用BIOES 標注方法,用B 表示這個詞處于一個實體的開始(Begin), I 表示內部(Inside), O 表示外部(Outside),E 表示這個詞處于一個實體的結束,S 表示這個詞自己就可以組成一個實體(Single)。 標注示例如圖5 所示。

圖5 API 命名實體識別的BIOES 標注示例Fig. 5 Examples of BIOES Labeling for API Named Entity Recognition

其中第一列是自然語言句子中的單詞,第二列是單詞的詞性,第三列為人工按BIOES 的標注的標簽。

2.2 評估指標

本文在API 實體識別時,采用如表1 所示的準確率、精確率、召回率以及F1 值作為評價指標。

表1 API 命名實體識別評價指標Tab. 1 API Named Entity Identification Evaluation Criterion

其中：TP 將API 實體預測為API 實體數,FN 將API 實體預測為其他類型數,FP 將其他類型預測為API 實體數,TN 將其他類型預測為其他類型數。

2.3 實驗結果和分析

2000 個樣本隨機選用1600 個進行訓練,200 個作為驗證集,200 個作為測試集。 測試句子中200個句子一共有1394 個token,203 個API 實體,實驗結果如表2 所示。

表2 API 命名實體識別測試集實驗結果Tab. 2 Experimental Results of API Named Entity Recognition %

可以看出深度學習模型相較于傳統的機器學習模型在API 識別方面具有優勢,而BERT 模型在四個指標上均可以達到最好效果。

3 結束語

本文提出了一種Java 代碼知識圖譜的構建方法,將github 源碼、API 文檔和Stack Overflow 問答社區的多源知識進行提取和融合,構建成圖譜,并通過實驗驗證了BERT 模型相比于其他現有模型可以獲得更好的API 實體識別效果。