「數據私房菜」已開通微信羣，匯聚3000+位小夥伴一同成長學習，加Andy爲微信好友（微信號：AndyFeo）申請入羣，讓咱們共建一個成長型數據社區，《數據私房菜》致力於爲您提供大數據行業知識乾貨、就業職位、專業講座等對每一位有價值的信息。
git
內容來源：百度NLP公衆號github
編輯整理：Hohweb
注：轉載請聯繫百度NLP受權。算法
導讀：語義解析 ( Semantic Parsing ) 是天然語言處理技術的核心任務之一，涉及語言學、計算語言學、機器學習以及認知語言等多個學科，在近幾年中得到了普遍關注，語義解析任務有助於促進機器語言理解的快速發展。sql
本文重點介紹語義解析技術中的Text-to-SQL任務，讓機器自動將用戶輸入的天然語言問題轉成數據庫可操做的SQL查詢語句，實現基於數據庫的自動問答能力。數據庫
任務介紹及研究動機編程
當前，大量信息存儲在結構化和半結構化知識庫中，如數據庫。對於這類數據的分析和獲取須要經過SQL等編程語言與數據庫進行交互操做，SQL的使用難度限制了非技術用戶，給數據分析和使用帶來了較高的門檻。人們迫切須要技術或工具完成天然語言與數據庫的交互，所以誕生了Text-to-SQL任務。微信
咱們經過圖1中的實例來介紹一下Text-to-SQL任務。該任務包含兩部分：Text-to-SQL解析器和SQL執行器。網絡
解析器的輸入是給定的數據庫和針對該數據庫的問題，輸出是問題對應的SQL查詢語句，如圖中紅色箭頭標示。SQL執行器在數據庫上完成該查詢語句的執行，及給出問題的最終答案，如圖中綠色箭頭標示。app
SQL執行器有不少成熟的系統，如MySQL，SQLite等，該部分不是本文重點。本文主要介紹解析器，學術界中Text-to-SQL任務默認爲Text-to-SQL解析模型。
圖1
首先，咱們介紹一下術語「數據庫」和「SQL查詢語句」：
一、數據庫由一張或多張表格構成，表格之間的關係經過外鍵給出。在該實例中，數據庫由表 「中國城市」和「2018年宜居城市」 構成，兩張表經過外鍵：「中國城市」的「名稱」列和「2018年宜居城市」的「名稱」列關聯；
二、SQL是數據庫查詢語言，其構成來自3部分：數據庫（如實例SQL查詢語句中藍色標註的成分）、問題（如實例SQL查詢語句紅色標註的成分）、SQL關鍵詞（如實例SQL查詢語句中的Select、From、Where等）。
其次，咱們介紹一下Text-to-SQL解析模型。根據SQL的構成，解析器須要完成兩個任務，即「問題與數據庫的映射」和「SQL生成」。
在問題與數據庫的映射中，須要找出問題依賴的表格以及具體的列，如圖1實例中，問題「綠化率前5的城市有哪些，分別隸屬於哪些省？」依賴的數據庫內容包括：表格「中國城市」，具體的列「名稱」、「所屬省」、「綠化率」（SQL查詢語句藍色標註成分）。
在SQL生成中，結合第一步識別結果以及問題包含信息，生成知足語法的SQL查詢語句，如實例中的「Select 名稱,所屬省 From 中國城市 Where 綠化率 > 30%」。
Text-to-SQL研究進展
Text-to-SQL技術可以有效地輔助人們對海量的數據庫進行查詢，因其有實用的應用場景，引發了學術界和工業界的普遍關注。咱們接下來將從相關數據集和模型兩方面介紹該技術的研究進展。
一、數據集介紹
圖2給出了Text-to-SQL數據集發展趨勢，表明數據集參見表1。
圖2
其中術語介紹：
根據包含領域數量，數據集分爲單領域和多領域。
根據每一個數據庫包含表的數量，數據集分爲單表和多表模式。在多表模式中，SQL生成涉及到表格的選擇。
根據問題複雜度，數據集分爲簡單問題和複雜問題模式，其中問題複雜度由SQL查詢語句涉及到的關鍵詞數量、嵌套層次、子句數量等肯定。
根據完整SQL生成所需輪數，數據集分爲單輪和多輪。
若SQL生成融進漸進式對話，則數據集增長「結合對話」標記。當前只有CoSQL數據集是融進對話的數據集。
表1
由圖2和表1可知，當前主流數據集都是多領域的，這就要求Text-to-SQL解析模型除了知足問題無關外，還要知足領域無關。
二、模型介紹
SQL查詢語句是一個符合語法、有邏輯結構的序列，其構成來自三部分：數據庫、問題、SQL關鍵詞。
在當前深度學習研究背景下，Text-to-SQL任務可被看做是一個相似於神經機器翻譯的序列到序列的生成任務，主要採用Seq2Seq模型框架。基線Seq2Seq模型加入注意力、拷貝等機制後，在單領域數據集上能夠達到80%以上的準確率，但在多領域數據集上效果不好，準確率均低於25%。
從編碼和解碼兩個方面進行緣由分析。
在編碼階段，問題與數據庫之間須要造成很好的對齊或映射關係，即問題中涉及了哪些表格中的哪些元素（包含列名和表格元素值）；同時，問題與SQL語法也須要進行映射，即問題中詞語觸發了哪些關鍵詞操做（如Group、Order、Select、Where等）、聚合操做（如Min、Max、Count等）等；最後，問題表達的邏輯結構須要表示並反饋到生成的SQL查詢語句上，邏輯結構包括嵌套、多子句等。
在解碼階段，SQL語言是一種有邏輯結構的語言，須要保證其語法合理性和可執行性。普通的Seq2Seq框架並不具有建模這些信息的能力。
當前基於Seq2Seq框架，主要有如下幾種改進。
1）基於Pointer Network的改進
首先，SQL組成來自三部分：數據庫中元素（如表名、列名、表格元素值）、問題中詞彙、 SQL關鍵字。其次，當前公開的多領域數據集爲了驗證模型數據庫無關，在劃分訓練集和測試集時要求數據庫無交叉，這種劃分方式致使測試集數據庫中很大比例的元素屬於未登陸詞。傳統的Seq2Seq模型是解決很差這類問題的。
Pointer Network很好地解決了這一問題，其輸出所用到的詞表是隨輸入而變化的。具體作法是利用注意力機制，直接從輸入序列中選取單詞做爲輸出。在Text-to-SQL任務中，將問題中詞彙、SQL關鍵詞、對應數據庫的全部元素做爲輸入序列，利用Pointer Network從輸入序列中拷貝單詞做爲最終生成SQL的組成元素。
因爲Pointer Network能夠較好的知足具體數據庫無關這一要求，在多領域數據集上的模型大多使用該網絡，如Seq2SQL[1]、STAMP[8]、Coarse2Fine[9] 、IRNet[16]等模型。
2）基於Sequence-to-set的改進
在簡單問題對應的數據集合上，其SQL查詢語句形式簡單（僅包含Select和Where關鍵詞），爲了解決Seq2Seq模型中順序錯誤帶來的影響（如「條件1 And 條件2」，預測爲「條件2 And 條件1」，屬於順序錯誤，但對應的SQL是正確的），SQLNet[10]提出了Sequence-to-set模型，基於全部的列預測其屬於哪一個關鍵詞（即屬於Select仍是Where，在SQLNet模型中僅預測是否屬於Where），針對SQL 中每個關鍵詞選擇機率最高的前K個列。
該模式適用於SQL形式簡單的數據集，在WikiSQL和NL2SQL這兩個數據集合上使用較多，且衍生出不少相關模型，如TypeSQL[11]、SQLova[12]、X-SQL[13]等。
圖3 Sequence-to-Set
3）基於TRANX（自頂向下文法生成）的改進
複雜問題對應的SQL查詢語句形式也複雜，涉及到多關鍵詞組合、嵌套、多子句等。而且，測試集合中的某些SQL查詢語句形式在訓練集合中沒有見過，這就要求模型不只對新數據庫具備泛化能力，對新SQL查詢語句形式也要有泛化能力。
針對這種狀況，須要更多關注生成SQL的邏輯結構。爲了保證SQL生成過程當中語法合理，一些模型開始探索及使用語法樹生成的方法。
TRANX[14]框架借鑑了AST[15]論文思想，根據目標語言的語法構建規約文法，基於該文法能夠將生成目標表示爲語法樹（須要保證生成目標與語法樹表示一一對應），而後實現了自頂向下的語法樹生成系統，圖4給出了該系統流程。
咱們簡單介紹一下基於該系統實現Text-to-SQL任務。
首先，根據SQL語法制定規約文法（對應圖4中的ASDL Grammar），須要保證每一條SQL查詢語句都可由該文法產出。
其次，設計動做集合用於轉移系統（圖4中的Transition System），基於該轉移系統選擇合理的規約文法生成語法樹，該轉移系統將語法樹的生成轉成動做序列的生成，即轉成一系列文法的選擇序列，文法在選擇過程當中保證了合理性（即孩子節點文法均在父節點容許的文法範圍內）；該動做序列的生成可基於Seq2Seq等框架進行。
該框架在代碼生成、SQL生成等任務上都已驗證過，在Text-to-SQL任務上的模型包括IRNet[16]、Global GNN[17]、RATSQL[18]等。
圖4：基於TRANX的code生成
4）其餘改進
在多表數據集合上，一些模型加入圖網絡來加強數據庫的表示，如Global GNN[17]、RATSQL[18]等。在WikiSQL數據集合上，因爲該數據集給出了SQL執行系統，部分模型經過加入執行指導[19]來提高SQL的可執行性和準確率。
三、評價方法
Text-to-SQL任務的評價方法主要包含兩種：精確匹配率（Exact Match, Accqm）、執行正確率（Execution Accuracy, Accex）。
精確匹配率指,預測獲得的SQL語句與標準SQL語句精確匹配成功的問題佔比。爲了處理由成分順序帶來的匹配錯誤，當前精確匹配評估將預測的SQL語句和標準SQL語句按着SQL關鍵詞分紅多個子句，每一個子句中的成分表示爲集合，當兩個子句對應的集合相同則兩個子句相同，當兩個SQL全部子句相同則兩個SQL精確匹配成功；
執行正確指，執行預測的SQL語句，數據庫返回正確答案的問題佔比。
目前僅WikiSQL數據集支持Accex，其餘數據集僅支持Accqm。大部分數據集發佈了對應的評估腳本，方便你們在同一個評估標準下進行算法研究。
接下來，咱們就數據集DuSQL的建設和模型DuParser的構建，向你們介紹百度在Text-to-SQL技術方面的研究，並展現百度在ToB客服業務和搜索業務中對該技術的應用，同時也對該技術面臨的挑戰和將來發展進行了一些思考。
百度對Text-to-SQL技術的研究
百度在一些實際業務中須要用到Text-to-SQL技術，好比基於表格的問答、ToB的客服業務等，因此結合實際應用，在數據集建設及模型構建方面作了一些工做，有必定的技術積累。
一、數據集DuSQL
由表1可見，當前Text-to-SQL數據集大部分是英文數據集，中文數據集只有NL2SQL數據集和CSpider數據集。
表1
其中CSpider數據集是英文數據集Spider的翻譯版本，中英文化差別致使問題用語和知識上存在差別，好比行政區劃相關的數據在Spider數據集上表示爲「州、縣、市」等，在CSpider數據集上則表示爲「省、市、縣」等，這種差別性下降了該數據集在實際應用中的價值。
NL2SQL數據集中的問題相對簡單，問題類型爲基於單/多條件查詢匹配的答案檢索，可以解決如「3000元如下的手機有哪些」等簡單問題，但沒法解決「便宜的手機有哪些」、「蘋果8手機256G比128G貴多少」這樣較難的問題。在實際應用中，後種難度較高的問題佔比很高，尤爲是在商業智能（BI）和購物相關諮詢的業務中。
咱們從實際應用中隨機抽取用戶問題，就問題解決所須要的操做對問題類型進行了人工分析，結果如表2所示，能夠看出涉及到計算、排序、比較等操做的問題有必定的佔比。
表2
爲了更好地理解這些問題類型，咱們列舉了一些問題類型及對應的問題實例（數據庫見上篇圖1），見表3：
表3: 問題類型及實例
爲了更好地覆蓋實際應用中常見的問題類型，使構建的數據集在實際應用中發揮更大的價值，咱們基於實際應用分析構建了多領域、多表、包含複雜問題的數據集DuSQL。
數據集構建主要分爲兩大步驟：數據庫構建和<問題，SQL查詢語句>構建。在數據庫構建中，要保證數據庫覆蓋的領域足夠普遍，在<問題, SQL查詢語句>構建中，要保證覆蓋實際應用中常見的問題類型。
數據庫主要來自百科（包括三元組數據和百科頁面中的表格）、權威網站（如國家統計局、天眼查、中國產業信息網、中關村在線等）、各行業年度報告以及論壇（如貼吧）等。
從這些網站挖掘到表格後，咱們按表格的表頭對同類表格進行了聚類，並根據表格中的實體連接等信息構建表格之間的關聯，最終保留了813張表格，分爲200個數據庫。因爲不少表格的內容較敏感，咱們僅使用了表格的表頭，對錶格內容進行了隨機填充，沒法保證事實性。
基於一個半自動方案構建<問題, SQL查詢語句>，首先須要基於SQL文法自動生成SQL查詢語句和對應的僞語言問題描述，而後經過衆包方式將僞語言問題描述改寫爲天然語言問題。在自動生成SQL查詢語句時，咱們設計了覆蓋全部常見問題類型的SQL規約文法，最終構建了近2.4萬的數據。
表4展現了DuSQL數據集與其餘多領域數據集的對比狀況。其中，時間計算屬於常數計算，引入常量TIME_NOW（表示當前時間），好比數據庫Schema爲「{公司名稱, 成立年份, 員工數, …}」，問題爲「XX公司成立多少年了」， SQL查詢語句爲「Select TIME_NOW – 成立年份 Where 公司名稱=XX」。在實際應用中，常數計算中的時間計算需求較大，所以咱們構建了相關數據。
表4：CSpider來自Spider訓練集和開發集的翻譯，其統計使用Spider的統計
二、模型DuParser
基於實際應用，百度研發了一種基於表格元素識別和文法組合的解析算法DuParser，要求其在實際應用中可以基於用戶提供的數據或反饋達到快速迭代、效果可解釋、可控的要求，解析算法框架見圖5（對應的實例見圖6，不一樣顏色的箭頭表示了流程中各模塊對應輸入輸出）。
圖5
首先，「成分映射」模塊完成問題中表格相關成分識別（圖6黑色箭頭表示的流程），用戶提供的數據包括同義詞、應用常見問題形式等，該部分可充分利用用戶提供的數據進行效果優化。而後對識別的成分進行SQL關鍵詞識別（圖6紫色箭頭表示的流程），該部分算法基於Sequence-to-set模型改進。
前兩個過程將問題中被映射成功的詞彙替換成相應的符號，輸入到基於文法組合的解析算法中，該部分的替換使後面模塊與具體數據庫無關，這提高了模型對新數據庫的泛化能力。
最後，在基於文法組合的語義解析階段，經過改造CYK算法，DuParser構建了一個自下向上的解析框架（圖6藍色箭頭表示的流程），而且，在文法組合過程當中經過引入SQL片斷與對應問題片斷類似度匹配來選擇最優文法。
圖6：黑色箭頭表示成分映射，紫色表示標籤識別，藍色表示文法組合
該框架有如下幾個優勢：
首先，與端到端的神經網絡模型相比，它具備良好的可解釋性和效果可控性，容易進行系統調試和針對性效果優化；其次，它能夠充分利用用戶提供的數據及反饋，在用戶任務上快速啓動且加快迭代優化速度；最後，該框架能夠作到語言無關、領域無關，有很好的擴展能力。
該模型在單表數據集合上進行了效果驗證，結果見表5（使用的預訓練模型與對應的SOTA一致）。
表5
注:
1）NL2SQL數據集的SOTA是開源最好模型[20]在開發集上的結果;
2）WikiSQL數據集的SOTA模型是不加執行指導的X-SQL[13]模型；
3）Spider單表來自Spider數據集中的單表部分數據，SOTA模型是IRNet[16]，評估了其中單表上的準確率（非bert版本）；
4）百度應用數據會針對數據集作優化，重點是「同義詞」部分。
百度對Text-to-SQL技術的應用
Text-to-SQL技術主要的應用場景是基於數據庫的問答。在實際的應用中，百度將該技術應用於ToB客服業務和搜索業務中。
對於ToB業務，以UNIT平臺爲輸出接口，支持結構化問答業務（參見下方連接）。支持的業務應用於車載對話系統、企業智能報表生成系統、電話客服系統等，圖7給出落地於車載對話系統中的案例。
連接：
https://ai.baidu.com/forum/topic/show/957042
圖7
對於搜索業務，咱們探索了搜索中的計算類問答（圖8）和企業表格問答（圖9）。
圖8
圖9
目前挑戰及將來思考
Text-to-SQL技術在實際應用中可直接使用，但因爲實際應用領域覆蓋普遍，模型須要知足領域無關、語言無關、問題無關。
當前模型在中間表示、樹形解碼、圖網絡建模數據庫等方向均有探索，並取得了必定的成效，但對一些複雜操做的解決效果還不夠好，可參見Spider數據集標註爲「難」和「極難」的數據效果。同時，在實際應用中，還須要考慮如下問題：
表格的識別及規範化表示：表格默認以第一行爲表頭，但在實際挖掘表格中，有三種狀況：以第一行爲表頭，以第一列爲表頭，或者第一行和第一列共同表示表格；挖掘的表格存在信息缺失問題，如表名缺失、表格值不全等；同時，面對多個表格時缺失表間連接關係。
外界知識的利用：有一些常識信息不包含在表格中，如排序操做的方向判斷（列爲「出生日期」，問題爲「年齡最大的員工」）、表格值進制轉換（列爲「人口(億)」，問題爲「人口超5千萬的城市」）等，這些信息須要引入外界知識來協助SQL生成。
融進漸進式對話：對於用戶的歧義表達和模糊表達，須要有「提問-反饋-再提問」的過程，這類問題每每須要經過多輪對話解決，而用戶的問題一般是上下文相關的，所以須要模型具有基於上下文的理解和分析能力。
今天的分享就到這裏，謝謝你們。
社羣推薦：
歡迎加入 DataFunTalk NLP 交流羣，跟同行零距離交流。如想進羣，請加逃課兒同窗的微信 ( 微信號：DataFunTalker )，回覆：NLP，逃課兒會自動拉你進羣。
參考文獻
[1] Seq2sql: Generating structured queries from natural language using reinforcement learning (Victor Zhong, Caiming Xiong, Richard Socher. CoRR2017)
[2] Spider: A Large-Scale Human-Labeled Dataset for Complex and Cross-Domain Semantic Parsing and Text-to-SQL Task (Tao Yu, Rui Zhang, Kai Yang, Michihiro Yasunaga, etc. EMNLP2018)
[3] A Pilot Study for Chinese SQL Semantic Parsing (Qingkai Min, Yuefeng Shi, Yue Zhang. EMNLP2019)
[4] SParC: Cross-Domain Semantic Parsing in Context (Tao Yu, Rui Zhang, Michihiro Yasunaga, Yi Chern Tan, etc. ACL2019)
[5] CoSQL: A Conversational Text-to-SQL Challenge Towards Cross-Domain Natural Language Interfaces to Databases (Tao Yu, Rui Zhang, He Yang Er, Suyi Li, Eric Xue, etc. EMNLP2019)
[6] https://tianchi.aliyun.com/markets/tianchi/zhuiyi_cn
[7] Pointer Networks （OriolVinyals, Meire Fortunato, Navdeep Jaitly. NIPS2015）
[8] Semantic Parsing with Syntax- and Table-Aware SQL Generation (Yibo Sun, Duyu Tang, Nan Duan, etc. ACL2018)
[9] Coarse-to-Fine Decoding for Neural Semantic Parsing (Li Dong, Mirella Lapata. ACL2018)
[10] SQLNet: Generating Structured Queries From Natural Language Without Reinforcement Learning (Xiaojun Xu, Chang Liu, DawnSong. CoRR 2018)
[11] TypeSQL: Knowledge-based Type-Aware Neural Text-to-SQL Generation (Tao Yu, Zifan Li, Zilin Zhang, Rui Zhang, Dragomir Radev. NAACL2018)
[12] Achieving 90% accuracy in WikiSQL (Wonseok Hwang, Jinyeong Yim, SeungHyun Park, Mnjoon Seo. CoRR2019)
[13] X-SQL: Reinforce Context Into Schema Representation (Pengcheng He, Yi Mao, Kaushik Chakrabarti, Weizhu Chen. CoRR2019)
[14] TRANX: A Transition-based Neural Abstract Syntax Parser for Semantic Parsing and Code Generation (Pengcheng Yin, Graham Neubig, EMNLP 2018 )
[15] Abstract syntax networks for code generation and semantic parsing (Maxim Rabinovich, Mitchell Stern, Dan Klein. ACL2017)
[16] Towards Complex Text-to-SQL in Cross-Domain Database with Intermediate Representation (Jiaqi Guo, Zecheng Zhan, Yan Gao, Yan Xiao, Jian-Guang Lou, Ting Liu, Dongmei Zhang. ACL2019)
[17] Representing Schema Structure with Graph Neural Networks for Text-to-SQL Parsing (Ben Bogin, Matt Gardner, Jonathan Berant. ACL2019)
[18] RAT-SQL: Relation-Aware Schema Encoding and Linking for Text-to-SQL Parsers (Bailin Wang, Richard Shin, Xiaodong Liu, Oleksandr Polozov, Matthew Richardson. Submitted to ACL2020)
[19] Robust Text-to-SQL Generation with Execution-Guided Decoding (Chenglong Wang, Kedar Tatwawadi, Marc Brockschmidt, Po-Sen Huang, Yi Mao, Oleksandr Polozov, Rishabh Singh. CoRR2018)
[20] https://github.com/beader/tianchi_nl2sql
百度天然語言處理（Natural Language Processing，NLP）以『理解語言，擁有智能，改變世界』爲使命，研發天然語言處理核心技術，打造領先的技術平臺和創新產品，服務全球用戶，讓複雜的世界更簡單。
版權說明：感謝每一位做者的辛苦付出與創做，《數據私房菜》均在文章開頭備註了原標題和來源。如轉載涉及版權等問題，請發送消息至公號後臺與咱們聯繫，咱們將在第一時間處理，很是感謝！
本文分享自微信公衆號 - 數據私房菜（DataPrivateFood）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。