揭開知識庫問答KB-QA的面紗2·語義解析篇

PaperWeekly發表於2017-08-11

作者丨劉大一恆

學校丨四川大學博士生


揭開知識庫問答KB-QA的面紗2·語義解析篇


本期我們從傳統方法之一的語義解析(有時也被稱為語義分析)開始,以一個經典的語義解析 baseline 方法為例,介紹語義解析如何進行 KB-QA。該方法來自史丹佛 Berant J, Chou A, Frostig R, et al. 的Semantic Parsing on Freebase from Question-Answer Pairs,文章發表於 2013 年的 EMNLP 會議。


1. 什麼是語義解析


揭開知識庫問答KB-QA的面紗1·簡介篇中我們談到,知識庫 Freebase 由大量的三元組組成,並且這些三元組的實體和實體關係都是形式化的語言,比如 (BarackObama, PlaceOfBirth, Honolulu)。


給定一個自然語言的問題:“Where was Obama born?”我們面臨的第一個挑戰,就是如何建立問題到知識庫的對映? 


語義解析 KB-QA 的思路是通過對自然語言進行語義上的分析,轉化成為一種能夠讓知識庫“看懂”的語義表示,進而通過知識庫中的知識,進行推理(Inference)查詢(Query),得出最終的答案。 


簡而言之,語義解析要做的事情,就是將自然語言的問題,轉化為一種能夠讓知識庫“看懂”的語義表示,這種語義表示即邏輯形式(Logic Form)。


2. 什麼是邏輯形式


為了能夠對知識庫進行查詢,我們需要一種能夠“訪問”知識庫的邏輯語言,Lambda Dependency-Based Compositional Semantics (Lambda-DCS) 是一種經典的邏輯語言,它用於處理邏輯形式(在實際操作中,邏輯形式會轉化 SPARQL query,可以在 Virtuoso engine 上對 Freebase 進行查詢)。如果我們把知識庫看作是一個資料庫,那麼邏輯形式(Logic Form)則可以看作是查詢語句的表示。 


我們用表示一個邏輯形式,用表示知識庫,表示實體,表示實體關係(有的也稱謂語或屬性)。簡單而言,邏輯形式分為一元形式(unary)和二元形式(binary)。對於一個一元實體,我們可以查詢出對應知識庫中的實體,給定一個二元實體關係,可以查到它在知識庫中所有與該實體關係相關的三元組中的實體對。並且,我們可以像資料庫語言一樣,進行連線 Join,求交集 Intersection 和聚合 Aggregate(如計數,求最大值等等)操作。具體來說,邏輯形式有以下形式和操作:


揭開知識庫問答KB-QA的面紗2·語義解析篇

有了上面的定義,我們就可以把一個自然語言問題表示為一個可以在知識庫中進行查詢的邏輯形式,比如對於問句“Number of dramas starring Tom Cruise?”它對應的邏輯形式是:


揭開知識庫問答KB-QA的面紗2·語義解析篇


當自然語言問題轉化為邏輯形式之後,通過相應的邏輯語言(轉化為 SPARQL query)查詢知識庫就可以得到答案。那麼,語義解析要如何把自然語言問題正確地轉化為相應的邏輯形式呢?


3. 語義解析 KB-QA 的方法框架


語法分析的過程可以看作是自底向上構造語法樹的過程,樹的根節點,就是該自然語言問題最終的邏輯形式表達。整個流程可以分為兩個步驟: 


1. 詞彙對映:即構造底層的語法樹節點。將單個自然語言短語或單詞對映到知識庫實體或知識庫實體關係所對應的邏輯形式。我們可以通過構造一個詞彙表(Lexicon)來完成這樣的對映。 


2. 構建(Composition):即自底向上對樹的節點進行兩兩合併,最後生成根節點,完成語法樹的構建。這一步有很多種方法,諸如構造大量手工規則,組合範疇語法(Combinatory Categorical Grammars,CCG)等等,而我們今天要講的這篇論文,採用了最暴力的方法,即對於兩個節點都可以執行上面所談到的連線 Join,求交 Intersection,聚合 Aggregate 三種操作,以及這篇文章獨創的橋接 Bridging 操作(橋接操作的具體方式稍後會提到)進行結點合併。顯然,這種合併方式複雜度是指數級的,最終會生成很多棵語法樹,我們需要通過對訓練資料進行訓練,訓練一個分類器,對語法樹進行篩選。 


自然語言轉化為邏輯形式的流程如下圖所示:


上圖紅色部分即邏輯形式,綠色部分 where was Obama born 為自然語言問題,藍色部分為詞彙對映(Lexicon)和構建(Composition)使用的操作,最終形成的語義解析樹的根節點即語義解析結果。 


接下來,我們還剩最後三個待解決的問題,如何訓練分類器?如何構建詞彙表?什麼是橋接操作? 


訓練分類器 


分類器的任務是計算每一種語法分析結果 d(Derivation)的概率,作者通過 discriminative log-linear model 進行 modeling,使用 Softmax 進行概率歸一化,公式如下:


其中 x 代表自然語言問題, 是一個從語法分析結果  和 x 中提取出來的 b 維特徵向量(該特徵向量包含了構造該語法樹所有操作的對應特徵,每種操作的具體特徵之後會提到), 是 b 維的引數向量。


對於訓練資料問題-答案對 ,最大化 log-likelihood 損失函式,通過 AdaGrad 演算法(一種動態調整學習率的隨機梯度下降演算法)進行引數更新。



可以看出特徵向量的訓練實際上是一種弱監督訓練(準確的說是一種遠端監督,DistantSupervison)。


構建詞彙表 


詞彙表即自然語言與知識庫實體或知識庫實體關係的單點對映,這一操作也被稱為對齊(Alignment)。我們知道自然語言實體到知識庫實體對映相對比較簡單,比如將“Obama was also born in Honolulu.”中的實體 Obama 對映為知識庫中的實體 BarackObama,可以使用一些簡單的字串匹配方式進行對映。 


但是要將自然語言短語如“was also born in”對映到相應的知識庫實體關係,如 PlaceOfBirth, 則較難通過字串匹配的方式建立對映。怎麼辦呢?沒錯,我們可以進行統計。直覺上來說,在文件中,如果有較多的實體對(entity1,entity2)作為主語和賓語出現在 was also born in 的兩側,並且,在知識庫中,這些實體對也同時出現在包含 PlaceOfBirth 的三元組中,那麼我們可以認為“was also born in”這個短語可以和 PlaceOfBirth 建立對映。 


比如(“Barack Obama”,“Honolulu”),(“MichelleObama”,“Chicago”)等實體對在文件中經常作為“was also born in”這個短語的主語和賓語,並且它們也都和實體關係 PlaceOfBirth 組成三元組出現在知識庫中。 


有了這樣的直覺,我們再來看看這篇文章是怎麼構建詞彙表的,利用 ReVerbopen IE system 在 ClueWeb09(注:該資料集由卡耐基梅隆學校在 09 年構建,還有一個 12 年的版本,ClueWeb12)上抽取 15 millions 個三元組構成一個資料集,如 (“Obama”, “was also born in”, “August 1961”),可以看出三元組的實體和關係都是自然語言的形式,取出其中的一個三元組子集,對裡面的每一個三元組的主語實體和賓語實體通過字元匹配的方式替換為知識庫的實體,並使用 SUTime 對資料進行歸一化。 


如(“Obama”, “was also born in”, “August 1961”) 經過預處理後轉化為 (BarackObama, “was also born in”, 1961-08)。 


接著我們對每一個三元組中的自然語言短語兩邊的實體對(entity1,entity2)進行統計,注意,由於自然語言短語 r1 知識庫實體關係 r2 的對應關係是多對多的,比如“was also born in”可能對應 PlaceOfBirth,也可能對應 DateOfBrith,我們需要對每一個 r1 進行區分,我們可以通過知識庫查詢到每一個實體的型別(type),比如 1961-08 的型別是 date 而 honolulu 的型別是 place,我們對 r1 兩邊的實體型別進行查詢可以得到主語實體的型別 t1 和賓語實體的型別 t2,因此 r1 可以進一步表示為 r[t1,t2],我們對其所在三元組兩邊的實體進行統計,得到實體對集合F(r[t1,t2])。 


同樣的,通過對知識庫進行統計,對每一個知識庫三元組中的實體關係 r2 也統計其兩邊的實體,可以得到實體對集合 F(r2),通過比較集合 F(r[t1,t2]) 和集合 F(r2) 類似 Jaccard 距離(集合交集元素數目比集合並集元素個數)這樣的特徵來確定是否建立詞彙對映,如下圖所示:



圖中綠色字型為 r1,藍色字型為 r2。作者定義了詞彙對映操作的三種特徵(用於訓練分類器),對齊特徵(Alignmentfeatures),文字相似度特徵(Textsimilarity features),和詞彙化特徵(Lexicalizedfeatures),具體內容如下表所示:



其中文字相似度特徵中的 s2 指 r2 的 freebase name。 


在實際使用中,我們可以通過詞性標註(POS)和命名實體識別(NER)來確定哪些短語和單詞需要被詞彙對映(Lexicon),從而忽略對一些 skippedwords 進行詞彙對映。並且,作者還建立了 18 種手工規則,對問題詞(questionwords)進行邏輯形式的直接對映,如“where,how many”對映為 Type.Location 和 Count。 


橋接操作 


完成詞彙表的構建後,仍然存在一些問題。比如,對於 go,have,do 這樣的輕動詞(light verb)難以直接對映到一個知識庫實體關係上,其次,有些知識庫實體關係極少出現,不容易通過統計的方式找到對映方式,還有一些詞比如 actress 實際上是兩個知識庫實體關係進行組合操作後的結果 (actor ∩ gender.female)。 


作者最後提到這個問題有希望通過在知識庫上進行隨機遊走 Random walk 或者使用馬爾科夫邏輯 Markov logic 解決,因此我們需要一個補丁,需要找到一個額外的二元關係來將當前的邏輯形式連線起來,那就是橋接。 


這裡舉個具體的例子,比如“Which college did Obama go to?” 假設“Obama” 和 “college” 可被詞彙對映對映為 BarackObama 和 Type.University,這裡"go to" 卻難以找到一個對映,事實上,這裡我們需要去尋找一箇中間二元關係(即Education)使得上面的句子可以被解析為 (Type.University ∩ Education.BarackObama),如下圖所示:

揭開知識庫問答KB-QA的面紗2·語義解析篇


具體來說,給定兩個型別(type)分別為 t1 和 t2 的一元邏輯形式 z1 和 z2,我們需要找到一個二元邏輯形式 b,在 b 對應的實體對型別滿足 (t1,t2) 的條件下生成邏輯形式 揭開知識庫問答KB-QA的面紗2·語義解析篇,這就是橋接,由於這裡有型別的限制,所以我們可以在知識庫中相鄰的邏輯關係中暴力搜尋符合條件的二元關係 b。(注:在論文中還提到了另外兩種需要進行橋接的場景,這裡我們則不再贅述)。


同樣的,作者也為橋接操作定義了相應的特徵(為了分類器的訓練),定義如下表所示:


揭開知識庫問答KB-QA的面紗2·語義解析篇


對於構建(composition)的其他三種操作,連線Join,求交集Intersection和聚合Aggregate,作者也定義了相應的特徵(為了分類器的訓練),如下表所示:


揭開知識庫問答KB-QA的面紗2·語義解析篇


至此,語法樹的構建,分類器的訓練,和分類器的輸入——特徵向量的構造方式我們都已經介紹完畢。最後我們再簡單的介紹一下實驗和實驗結果。


4. 實驗結果


由於語義解析樹的構建方式是指數級的,因此,在訓練和測試的時候,作者執行了標準的自底向上的集束分析器(Beam-based bottom-up parser)。在這篇論文之前,KB-QA 流行的資料集是由 Cai and Yates (2013) 構建的 Free917,該資料集只包含了 917 組問題答案對,因此,作者構建了一個更大的 benchmark 資料集 WebQuestion,包含了 5810 組問題答案對,該資料集的構建方式我在揭開知識庫問答 KB-QA 的面紗·簡介篇中進行了簡單介紹。 


作者測試了僅使用Alignment和Bridging以及都使用下的正確率,如下表所示:


揭開知識庫問答KB-QA的面紗2·語義解析篇


作者該論文的語義解析器 Sempre 進行了開源,感興趣的朋友可以查閱該專案資料。 


我們可以看出傳統的語義解析方法還是存在大量的手工規則,也涉及到了一些 linguistic 的知識,對於沒有傳統 NLP 先驗知識的朋友可能理解起來會稍微困難一些。 


最後,讓我們再思考一下該方法有些什麼缺陷? 


首先,詞彙對映是整個演算法有效(work)的基點,然而這裡採用的詞彙對映(尤其是關係對映)是基於比較簡單的統計方式,對資料有較大依賴性。最重要的是,這種方式無法完成自然語言短語到複雜知識庫關係組合的對映(如 actress 對映為 揭開知識庫問答KB-QA的面紗2·語義解析篇。 


其次,在答案獲取的過程中,通過遠端監督學習訓練分類器對語義樹進行評分,注意,這裡的語義樹實際的組合方式是很多的,要訓練這樣一個強大的語義解析分類器,需要大量的訓練資料。我們可以注意到,無論是 Free917 還是 WebQuestion,這兩個資料集的問題-答案對都比較少。 



相關文章