內容速覽

• 什么是語義解析（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的方法框架

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

詞匯映射：即構造底層的語法樹節點。將單個自然語言短語或單詞映射到知識庫實體或知識庫實體關系所對應的邏輯形式。我們可以通過構造一個詞匯表（Lexicon）來完成這樣的映射。

構建（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%）。

敬請期待。

https://zhuanlan.zhihu.com/p/25759682

總結

以上是生活随笔為你收集整理的揭开知识库问答KB-QA的面纱2·语义解析篇的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。