ACL 2018 | 提高NLP語義解析準確度:融合SQL語法的生成式語義解析模型

 2018-07-12 13:00:42.0

編者按:人們越來越習慣於通過自然語言來進行 人機交互 ,如何能讓計算機與用戶之間的「溝通」更加順暢?微軟亞洲研究院自然語言計算組在ACL 2018上提出了一個融合SQL語法的生成式語義解析模型,能夠更加準確地將用戶輸入的自然語言轉化爲機器可以理解並執行的表達形式。

無論是在日常生活還是工作中,人們都越來越多地使用自然語言來與計算機進行交互。例如,使用自然語音交互方式讓虛擬語音助手(如Cortana、Siri、Google Assistant、Amazon Alexa等)查詢天氣、預定日程、撥打電話等;用戶在搜索引擎中用自然語言輸入查詢內容,得到精準的答案;員工使用自然語言與結構化的企業數據庫交互,完成查詢操作。

在上述的應用場景中,輸入的是用戶的自然語言(natural language),而輸出的是機器可以理解並執行的規範語義表示(formal meaning representation),該表示可以在某個環境中被執行並返回結果。

自然語言處理領域,上述輸入-輸出任務被稱爲語義解析(semantic parsing),即把自然語言自動轉化爲一種機器可以理解並執行的表達形式。例如,在虛擬語音助手場景中,語義解析模型可以將用戶的語言轉換爲調用不同應用程序的API語句;在基於知識庫的搜索場景中,語義解析模型可以將用戶查詢轉換爲可以在結構化知識庫(如Microsoft Satori)上可以執行的SPARQL語句;在企業數據交互場景中,語義解析模型可以將用戶的語言轉換爲結構化查詢語句(Structured Query Language, SQL);

多變的自然語言與有限的結構化查詢語句

在本文中,我們以結構化查詢語句爲例介紹在語義解析領域的研究進展。該任務的輸入是一張web table或一個關係數據庫表以及一個關於這張表的自然語言問句,輸出是表達該問句語義的SQL語句。這個SQL語句可以在輸入的表上被執行,從而得到問題的答案。

圖1 結構化查詢語句

目前,做生成任務比較流行的方法是基於序列到序列(sequence to sequence)架構的神經模型,這類模型一般由一個編碼器(encoder)和一個解碼器(decoder)組成。編碼器負責建模句子表示,解碼器則根據編碼器得到的問句表示來逐個從詞表中挑選出一個個符號進行生成。

當生成任務的目標語言是SQL時,由於其語法的符號有限,我們可以使用Pointer Network模型來進行建模。這個模型在解碼過程中使用了「拷貝」機制,即只從SQL的關鍵字和問句中的單詞所組成的集合中選擇每個時刻生成的單詞,以達到減少預測空間大小的目的。在Pointer Network模型中,在每個時刻t,decoder選擇問句中第i個單詞xi的概率如公式1中所示:

公式1

其中代表解碼器中的隱層狀態,代表編碼器中第i個單詞對應的因層狀態。

由於自然語言表達的多變性,問句中對錶中內容的表述可能與表中的真實表述不一致。在圖1的例子中,表中的一列名稱爲「Song choice」,一個單元的內容爲「Anna Christine Nalick」。而在問句中對應的表達卻是「songs」和「anna nalick」。由於這種不一致的存在,用Pointer Network生成的SQL就包含了許多不能執行的結果。

融合SQL語法的生成式語義解析模型

圖2 融合SQL語法的生成式語義解析模型

爲了解決這個問題,我們提出了一個融合SQL語法的生成式語義解析模型,其整體結構如圖2所示。這是一個序列到序列的模型,其編碼器由雙向的RNN組成,雙向RNN的最終狀態向量在首尾相連後作爲解碼器的初始狀態。解碼器則由三個頻道和一個門單元組成。其中三個頻道分別爲Column、value、SQL頻道,在每個頻道中分別預測表中列名稱、表中單元格名稱和SQL語法關鍵字。而門單元則預測在每個時間節點應該選擇哪個頻道的預測結果作爲輸出。解碼器在t時刻生成目標yt的概率如公式2所示,其中zt代表由門單元選擇的頻道,pz(·)是選擇頻道的概率,而pw(·)類似於公式1,它是各自頻道的概率輸出。

公式2

具體來說,在三個頻道中,column和value頻道的候選由於由N個單詞組成,所以用RNN建模,得到向量表示,而SQL頻道的候選用對應的word embedding表示。在每個頻道中,當前時刻生成元素的概率是由此時刻解碼器RNN的狀態向量和候選元素的向量表示之間通過計算相似度後歸一化所得。而門單元的概率輸出則是直接由解碼器RNN的狀態向量經線性變化後經過softmax所得。由於column、value頻道的預測候選是直接從表中獲得,所以解決了Pointer Network模型所面對的不一致問題。

此外,我們還在模型中加入了SQL語法和表結構的信息來提升性能

首先,列名和單元格直接的關係可以幫助column頻道的預測。如果我們在問題中提到了表中的某一單元格,那麼Where column的結果也大概率是此單元格所在的列。所以,我們也用了表中單元格的信息去幫助column頻道的預測。具體來說,我們將單元格的向量表示的加權求和與原列名稱的向量表示首尾相,以此作爲新的列名的向量表示。這個權重是由單元格中出現的單詞在句子中復現的程度決定的。

公式3

其次,列名和單元格之間的關係也可以幫助value頻道的預測。Where value所在的單元格一定在Where column所在的列,所以我們用一個全局變量保存了最近一側預測的列位置,在value頻道中只選擇這列的單元格作爲候選進行預測。直觀來看,要預測的單元格內容基本都出現在問句之中,所以我們進一步用上文中提到的由單詞復現得到的權重和value頻道預測的概率分佈做一個加權求和,從而得到最終value頻道的預測概率。

公式4

我們在WikiSQL數據集上進行了實驗。這個數據集包含了61,297/9,145/17,284個訓練/開發/測試樣本。每個樣本分別包含了一個問句、一張表、一個SQL表達式,以及問句在表中的答案。我們用了兩種評估指標,分別是邏輯表達式準確率(Acc_lf):生成的SQL是否和樣本中的SQL表達式完全匹配的比例,和執行準確率(Acc_ex):生成的SQL在表中查詢後得到的答案和樣本中的答案一致的比例。

實驗結果如下圖所示。Aug.PntNet代表Pointer Network模型,其中在STAMP(w/o)cell的模型中,value頻道預測的候選不是表中的單元格,而是問句中的單詞,即在value頻道沿用了Point Network的拷貝機制。在STAMP  (w/o column-cell relation)模型中,我們去掉了單元格信息對於column和value頻道的增強。

圖3

通過此表我們可以看到,用表中的元素整體作爲預測候選以及加入列名與單元格之間的依賴關係這兩點設計都對模型有所加強。我們在邏輯表達式準確率和執行準確率兩個維度上對比Pointer Network模型分別獲得了14.7%和14.1%的提升。

下圖展示了我們的模型在更細粒度上的執行準確率

圖4

可以看到,在Where從句中,我們模型的效果有着明顯的提升。

下圖中展示了模型的輸出樣例:

圖5

我們可以看到,我們的模型解決了問題表達和表中內容表達不一致所導致的問題。

總結

本文以自然語言到SQL語句生成任務爲例,介紹了在語義分析(semanticparsing)領域我們提出的一種融合SQL語法的端到端神經網絡方法。這一語義分析技術的應用將有效地提升搜索引擎的結果準確度、提高虛擬語音助手的多輪對話表現等。未來,我們還計劃使用更多樣的監督信號學習適用於不同場景的語義分析算法。

想要了解更多細節的讀者,歡迎閱讀我們發佈在今年ACL 2018上的論文:

Semantic Parsing with Syntax- and Table-Aware SQL Generation, Yibo Sun, Duyu Tang, Nan Duan, Jianshu Ji , Guihong Cao , Xiaocheng Feng , Bing Qin, Ting Liu, Ming Zhou, ACL 2018

論文鏈接:https://arxiv.org/pdf/1804.08338.pdf

文章來源:機器之心