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

內容速覽

• 什麼是語義解析（Semantic Parsing）
• 什麼是邏輯形式（Logic Form）
• 語義解析KB-QA的方法框架
• 實驗結果

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

註：語義解析的方法涉及到一些傳統linguistic的知識，也是KB-QA三大傳統方法中最難以理解的一種方法。這裡由於篇幅有限，我們將不再對相應的linguistic知識進行詳細介紹，為了方便大家理解，我們可能並未使用最標準的定義來解釋linguistic相關的名詞，而是給出方便大家理解的直覺上的解釋。如果您對linguistic相關的知識感興趣，可以關注我，之後我們將開設專欄，對傳統linguistic的知識進行介紹和梳理，敬請期待。

什麼是語義解析

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

(BarackObama, PlaceOfBirth, Honolulu)

給定一個自然語言的問題

「Where was Obama born？」

我們面臨的第一個挑戰，就是如何建立問題到知識庫的映射？

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

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

什麼是邏輯形式

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

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

有了上面的定義，我們就可以把一個自然語言問題表示為一個可以在知識庫中進行查詢的邏輯形式，比如對於問句

「Number of dramas starring Tom Cruise?」

它對應的邏輯形式是

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

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

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

1. 辭彙映射：即構造底層的語法樹節點。將單個自然語言短語或單詞映射到知識庫實體或知識庫實體關係所對應的邏輯形式。我們可以通過構造一個辭彙表（Lexicon）來完成這樣的映射。
2. 構建（Composition）：即自底向上對樹的節點進行兩兩合併，最後生成根節點，完成語法樹的構建。這一步有很多種方法，諸如構造大量手工規則，組合範疇語法（Combinatory Categorical Grammars，CCG）等等，而我們今天要講的這篇論文，採用了最暴力的方法，即對於兩個節點都可以執行上面所談到的連接Join，求交Intersection，聚合Aggregate三種操作，以及這篇文章獨創的橋接Bridging操作（橋接操作的具體方式稍後會提到）進行結點合併。顯然，這種合併方式複雜度是指數級的，最終會生成很多棵語法樹，我們需要通過對訓練數據進行訓練，訓練一個分類器，對語法樹進行篩選。

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

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

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

• 訓練分類器

分類器的任務是計算每一種語義解析結果（Derivation）的概率，作者通過discriminative log-linear model進行modeling，使用Softmax進行概率歸一化，公式如下：

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

對於訓練數據問題-答案對，最大化log-likelihood損失函數，通過AdaGrad演算法（一種動態調整學習率的隨機梯度下降演算法）進行參數更新。

可以看出特徵向量的訓練實際上是一種弱監督訓練（準確的說是一種遠程監督，Distant Supervison）。

• 構建辭彙表

辭彙表即自然語言與知識庫實體或知識庫實體關係的單點映射，這一操作也被稱為對齊（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）上抽取15millions個三元組構成一個數據集，如(「Obama」, 「was also born in」, 「August 1961」)，可以看出三元組的實體和關係都是自然語言的形式，取出其中的一個三元組子集，對裡面的每一個三元組的主語實體和賓語實體通過字元匹配的方式替換為知識庫的實體，並使用SUTime對數據進行歸一化。

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

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

同樣的，通過對知識庫進行統計，對每一個知識庫三元組中的實體關係也統計其兩邊的實體，可以得到實體對集合，通過比較集合和集合類似Jaccard距離（集合交集元素數目比集合併集元素個數）這樣的特徵來確定是否建立辭彙映射，如下圖所示

圖中綠色字體為，藍色字體為。作者定義了辭彙映射操作的三種特徵（用於訓練分類器），對齊特徵（Alignment features），文本相似度特徵（Text similarity features），和辭彙化特徵（Lexicalized features），具體內容如下表所示

其中文本相似度特徵中的指的freebase name。

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

• 橋接操作

完成辭彙表的構建後，仍然存在一些問題。比如，對於go，have，do這樣的輕動詞（light verb）難以直接映射到一個知識庫實體關係上，其次，有些知識庫實體關係極少出現，不容易通過統計的方式找到映射方式，還有一些詞比如actress實際上是兩個知識庫實體關係進行組合操作後的結果（作者最後提到這個問題有希望通過在知識庫上進行隨機遊走Random walk或者使用馬爾科夫邏輯Markov logic解決），因此我們需要一個補丁，需要找到一個額外的二元關係來將當前的邏輯形式連接起來，那就是橋接。

這裡舉個具體的例子，比如

「Which college did Obama go to?」

假設「Obama」 和 「college」 可被辭彙映射映射為 BarackObama 和 Type.University, 這裡"go to" 卻難以找到一個映射，事實上，這裡我們需要去尋找一個中間二元關係（即Education）使得上面的句子可以被解析為，如下圖所示

具體來說，給定兩個類型（type）分別為和的一元邏輯形式和，我們需要找到一個二元邏輯形式，在對應的實體對類型滿足的條件下生成邏輯形式，這就是橋接，由於這裡有類型的限制，所以我們可以在知識庫中相鄰的邏輯關係中暴力搜索符合條件的二元關係。

（註：在論文中還提到了另外兩種需要進行橋接的場景，這裡我們則不再贅述）

同樣的，作者也為橋接操作定義了相應的特徵（為了分類器的訓練），定義如下表所示

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

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

• 實驗結果

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

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

作者該論文的語義解析器Sempre進行了開源，感興趣的朋友可以點擊這裡。

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

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

首先，辭彙映射是整個演算法有效（work）的基點，然而這裡採用的辭彙映射（尤其是關係映射）是基於比較簡單的統計方式，對數據有較大依賴性。最重要的是，這種方式無法完成自然語言短語到複雜知識庫關係組合的映射（如actress 映射為）。

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

那麼這些問題怎麼解決呢？

在下一期中，我們將以2014年ACL的Yao X, Van Durme B. Information Extraction over Structured Data: Question Answering with Freebase[C]//ACL (1). 2014: 956-966. 這篇論文為例，介紹KB-QA的第二種傳統方法——信息抽取，該方法在WebQuestion數據集上的F1-score相比本篇論文有一個較大的提升（大於10%）。

敬請期待。

系列相關文章：

揭開知識庫問答KB-QA的面紗1·簡介篇

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

揭開知識庫問題KB-QA的面紗3·信息抽取篇

揭開知識庫問題KB-QA的面紗4·向量建模篇

推薦閱讀：