不會SQL也能做資料分析？淺談語義解析領域的機會與挑戰
筆者按: 在第5次AI TIME PhD Debate上，筆者邀請了部分國內外語義解析領域的傑出華人學者共話語義解析的過去，現狀和未來。本部落格為筆者根據視訊討論總結的乾貨整理。對原視訊感興趣的同學可以直接觀看原視訊: 傳送門。語義解析是個新興熱門的領域，也歡迎讀者在本部落格下留言分享自己的感悟或問題，筆者會盡可能解答大家的問題。
一直以來是，語義解析(Semantic Parsing) 都是自然語言處理領域一個非常基礎且重要的研究問題。通俗來講，語義解析旨在讓計算機學會理解自然語言，並將其翻譯成機器可執行的、形式化的程式語言(比如 SQL語句) 。這樣一來，使用者無需學習程式設計，通過描述就可以驅動系統生成程式碼。鑑於語義解析潛在的商業應用價值，近些年來以Text-to-SQL為代表的語義解析領域引起了很多國內外研究者的研究興趣。
7月31日，PhD Debate第五期“語義解析漫談:機會與挑戰”，AI TIME特別邀請了來自卡內基梅隆大學的殷鵬程學長、俄亥俄州立大學的姚子瑜學姐、愛丁堡大學的王柏林學長，並由北京航空航天大學的劉乾(就是筆者我啦) 和清華大學的張亞嫻主持，共話語義解析方向的機會與挑戰。話不多說，下面就讓我們來看看嘉賓們具體討論了哪些話題吧！
語義解析領域近年來受關注的具體方向和任務
計算機自然語言介面 Natural Language Interface
SQL Generation (Text-to-SQL)
王柏林: 語義解析最常見的一個應用場景就是資料庫的自然語言介面(Natural Language Interface for Database, 又名 NLIDB)。一個主要的原因是資料庫我們平時應用比較多，許多應用都是通過資料庫來儲存資料的，而使用者和開發者也都需要與資料庫的頻繁互動來查詢資料。在這個方向上，最近受大家關注度比較多的就是 Spider這個資料集 [1]
標註者被要求想出一個複雜的問句，同時要標註出跟這個問句對應的SQL語句，如下圖所示：
當這個資料集建立完成後，我們就可以構建一個系統從這個資料集中學會將人類的自然語言翻譯成SQL語句，進而實現使用者通過自然語言查詢資料庫的需求。
劉乾：Spider是一個英文的資料集，中文領域與Spider相對應的是百度NLP團隊發表在EMNLP2020上的資料集 DuSQL [2]，它的一個例子如下圖所示。
DuSQL與Spider一樣，生成的SQL都需要在多張表格上進行連表查詢，問句也比較複雜。除了中文和英文的區別外，DuSQL相比Spider還額外考慮了使用者場景的區別，繼而在標註資料時考慮到不同場景的使用者的問句涉及到SQL語句的分佈情況。例如說，資訊檢索場景的使用者一般不涉及SQL裡的計算(Calculation)操作，因為他們提問主要是想得到一個通過檢索可得到的事實性答案，但它對於資料分析場景的使用者來說卻是很常見的。從這個角度來說，DuSQL帶給我們的啟示是: 在收集語義解析的資料前我們就要考慮好面向使用者的場景。場景的不同也會決定資料集的側重有所不同。
Code Generation
殷鵬程: 剛剛兩位講到了如何將自然語言轉換成SQL語句這種領域相關的程式碼(Domain-Specific Language, DSL)，其實語義解析還可以用在更廣泛的範疇，比如說通用的程式碼生成(Code)。在程式碼生成領域，第一項工作是由DeepMind於2016年釋出的HeartStone資料集 [3]。在這個資料集的設定下，系統所接受的自然語言的輸入並不是一個使用者提交的問題，而是一組關於爐石傳說卡牌的描述，系統的目標就是生成一串能夠實現這個卡牌的程式碼。一個包含輸入、輸出的示例如下圖:
相比於前面所講到的SQL Generation，Code Generation的難點在於輸出是更加複雜和多樣的。比如這裡系統要生成Python一個類的名字和成員函式。
其實呢，除了爐石傳說這種特定領域下的程式碼生成，我們還可以考慮開放領域下的程式碼生成。下圖是CoNaLa資料集，是由我們團隊在2018年構建的 [4]，它的目標是能夠自動化地把一個程式設計師的自然語言問題變成相應的Python程式碼實現。這個資料集是源自一些知名的程式設計問答平臺(如StackoverFlow)上網友提問的問題，和其他網友貢獻的一些Python實現。但是，想從這樣的平臺上自動抽取乾淨的平行語料還是比較困難的，我們團隊當時構建了一個模型來自動地抽取這樣的資料對。有了這些資料對後，我們邀請一些程式設計師對這些資料對進行進一步的過濾和修正，最終就可以得到CoNaLa這個資料集。
除了這種簡短的程式碼外，近些年也有如Github Copilot 這樣的能夠生成較為複雜程式的技術。Copilot背後的技術就是OpenAI最近提出的CodeX [5]，一個基於程式碼的預訓練模型。CodeX系統的輸入是一段提示(Prompt)，比方說下圖中的提示輸入到CodeX中，它可以生成一個判斷輸入數字是否為質數的Python程式。
Code Search
姚子瑜: 前一位嘉賓介紹了程式碼生成，那我接下來要介紹的技術與程式碼生成聯絡是非常緊密的，它就是程式碼檢索(Code Search/Code Retrieval)。當用戶用自然語言提問時，假設我們有一個非常大的程式碼庫，我們希望從這個大的程式碼庫中檢索到對使用者而言最有用的，最能幫助使用者回答問題的程式碼。下圖展示了StaQC資料集 [6] 中的一個示例。
相比於程式碼生成，程式碼檢索的特點在於使用者的問句可能更短，而期望的解決方案要更加複雜。目前，程式碼檢索的主要難點有三個: 1. 如何同時建模自然語言問題和程式碼的語義，以及它們之間的關聯，使得使用者可以檢索到有用的程式碼解決方案；2. 如何高效地檢索到最有用的程式碼解決方案；3. 如何找到有效的負樣本(negative sample)來訓練一個更有效的程式碼檢索模型。從另外一個角度來說，程式碼檢索其實也可以作為程式碼生成的一個前置流程。當系統需要產生一些複雜程式碼時，它可以先檢索一些程式碼作為基礎，然後對它們進行編輯(edit)得到一個新的程式碼返回給使用者。
語義解析與對話系統 Semantic Parsing and Dialogue Systems
劉乾: 除了單輪的語義解析外，近些年語義解析與對話系統的結合也吸引了很多關注。伴隨著任務型對話與對話式語義解析之間的界限越來越模糊，語義解析和對話系統之間的淵源也越來越深，包括了用於傳統對話系統的語義解析方法，對話式語義解析以及互動式語義解析。
Semantic Parsing for Dialogue Systems
殷鵬程: 隨著任務型對話需求的複雜程式逐漸提升，使用語義解析方法來解決傳統的任務型對話是一種趨勢。在這個方向上，首先我想介紹一下Facebook所提出資料集TOP [7]，它的任務要求模型能夠層次(Hierarchical)化地理解自然語言，這種層次化理解的難度我認為介於槽位填充(Slot Filling)方法與語義解析方法之間。下圖是一個TOP中的示例，它通過定義一種層次化的表示來支援巢狀查詢等複雜操作。
姚子瑜：如上位嘉賓所說的，當任務型對話複雜到一定程度後，解決方案最終其實會收斂到語義解析的方法。例如，去年微軟Semantic Machines 團隊就釋出了一個數據集 SMCalFlow [8]，將語義解析方法直接用在了任務型對話中。下圖展示了該資料集中的一個示例，大家可以看到相比TOP而言，這個資料集中的程式碼要更加複雜。而這種程式碼設計的主要動機在於更好地處理使用者自然語言中組合式(Compositional)的語義。
同時，為了更好地建模對話中的上下文，SMCalFlow 提出了兩種元運算元(Meta Computation)，分別是指代(Reference)和更新 (Revision)。指代對應的是refer，主要處理對話中存在指代的現象，比如用代詞指代上文中的某個物體。更新對應的是 revise，主要處理使用者希望更新歷史狀態時，比如使用者說 “把會議改到5點”。
劉乾: 剛剛兩位嘉賓介紹瞭如何在開放域(Open Domain)的場景下利用語義解析的方法來解決對話系統，但這些方法理論上都無法泛化到新的領域中。例如，當訓練資料是關於天氣預報的對話，測試時系統也只能完成天氣預報的功能，而無法跨域泛化(Cross-domain Generalization)，完成如訂會議室等功能。下面我們將介紹的面向資料庫的、帶上下文的語義解析(Contextual Semantic Parsing) 在訓練模型時就帶上了領域知識，例如領域相關的資料庫。在測試時，我們可以通過切換模型依賴的領域知識來實現它的跨域泛化，使得系統更加實用。
Contextual Semantic Parsing
王柏林: 面向資料庫的對話式語義解析相比傳統的對話而言泛化性要更強一些，也更關注於資料庫的互動。與傳統任務型對話動機一樣，當用戶與資料庫互動時，很多情況下都需要多輪互動才能達到最終的目的。下圖的例子展示了資料集 SParC [9] 中一個關於學生宿舍資料庫上的一個比較複雜的問句 C1。大家可以看到，這個問句非常複雜，使用者一般其實也不會這麼去提問。更自然的一種互動方式其實是使用者通過一組對話比如 Q1, Q2 等一起來完成一個複雜詢問的操作。
劉乾: SParC資料集的主要動機是想讓使用者通過一組簡單對話表達一個複雜意圖，因此它在資料標註時也遵循一樣的原則，即讓標註人員通過對話在最後一輪時產生一個複雜的SQL語句。但實際上這樣的標註方法會帶來一些問題，其中最主要的就是會造成SQL複雜度分佈不均勻。例如，在SParC資料集中，第1輪問句對應的SQL往往非常簡單，而最後1輪問句對應的SQL往往非常複雜。為了緩解資料集與真實情況下的分佈差異問題，西安交大與微軟的研究員改進了資料標註流程，並在今年ACL釋出了一個新的中文對話級NL-to-SQL的資料集CHASE [10]。CHASE中各輪SQL的複雜度比較均衡，它也鼓勵標註員在一輪對話中間開啟一個全新的話題，也因此更具挑戰性。下圖是CHASE資料集中的一個示例，可以看到中文的對話與英文的對話差距還是較大的，中文相比而言更加簡潔一些。
Interactive Semantic Parsing
姚子瑜: 互動式語義解析也是近幾年學術界關注的一個方向。雖然同為對話系統下的場景，但和上述嘉賓所關注的上下文依賴的場景不同的是，互動式語義解析(Interactive Semantic Parsing)關注在人機互動上。它允許一個系統通過與使用者的互動來澄清使用者的意圖(Clarify User Intent) ，獲得使用者確認 (Ask for Confirmation) ，以及通過使用者反饋糾正自身 (Ask for Correction) 等。通過互動，一個語義解析系統可以有更好的魯棒性以及提升它自己的置信度。目前，這個研究領域有一個相對比較初步的資料集 SPLASH [11] （如下圖），它可以用來訓練系統學會利用使用者的反饋更正自己的錯誤。
語義解析領域近年來受關注的新技術
模型架構與任務建模 Model Architecture
劉乾: 目前語義解析模型按照建模方式主要是兩種正規化，一類是以WikiSQL這類SQL相對比較簡單的資料集為目標的，通過將語義解析的生成任務分解成若干個簡單的分類子任務來完成語義解析，如XSQL [12]，另一類則是以Spider這類SQL相對比較複雜的資料集為目標的，通過自迴歸的生成式模型來完成語義解析，如 IRNet [13]。前者的好處在於通過簡化任務降低了模型的學習壓力，對工業界而已更容易商業化；而後者則更加通用，接下里嘉賓主要會側重於後者的相關討論。
Grammar-based Decoding
殷鵬程: 語義解析領域下其實囊括了許多不同的任務，如NL-to-SQL, NL-to-Python等。不同任務其實需要不同的領域知識(Domain-specific Knowledge)，其中很重要的一種知識就是生成程式碼本身要遵從的對應語法(Grammar)。下圖右側是一段Python程式碼和它所對應的抽象語法樹(Abstract Syntax Tree)，左側則是Python的語法。不難看出，Python的語法中其實蘊涵了許多對模型輸出空間的約束，例如，一個Expr (即表示式)只能展開成一個 Name (即變數名) 或者一個 Call (即函式呼叫)。
當我們在需要完成NL-to-Python任務的模型中引入Python語法作為先驗知識時，它應該可以保證所生成的程式碼在語法上一定是正確的，這就是基於語法的解碼方法(Grammar-based Decoding)， 而 [14] 就是其中經典的工作之一。在實際建模中，與傳統的直接利用序列到序列模型(Sequence to Sequence Model)來生成程式碼 [15] 不同，基於語法的解碼方法利用的是序列到樹模型(Sequence to Tree Model)，生成的實際上是上圖中抽象語法樹深度優先遍歷得到的序列(即動作序列, Action Sequence)，最終再通過確定性的演算法將動作序列轉換成目的碼。
Relation-Aware Encoding
王柏林: 前位嘉賓講到了通過語法來增強解碼器，接下來我要介紹的就是如何利用關係感知的編碼(Relation-Aware Encoding)來增強Text-to-SQL任務中編碼器的能力。當我們在構建面向資料庫的Text-to-SQL系統時，系統其實需要完成兩件事: 模式編碼(Schema Encoding)與模式連結(Schema Linking)，這裡的模式指的是資料庫模式，包括表名，列名和值。
模式編碼是指如何編碼資料庫資訊，因為資料庫由多個主外來鍵相連的表格構建而成，它本身是一個圖的結構，如何編碼這種圖結構對演算法提出了比較大的挑戰。模式連結是指使用者的問題中有一些詞或顯式或隱式地提到資料庫模式，比如這裡的cars就關係到表名cars_data和列cars_name。如何把問題和資料庫模式的這種關係讓模型感知到就是模型設計的另一個關鍵。
為了更好地解決這兩個挑戰，我們在Transformer的基礎上提出了關係感知的編碼方法RAT-SQL [16]。模型的輸入包含三部分，包括了使用者的問題，資料庫表名和資料庫列名。比如下面這個例子，模型在編碼 cars_data的時候會考慮到若干種關係，如cars_data 與使用者問題中cars一詞的連結關係，再如cars_data與其表內列名在同一個表的關係等。在具體實現時，這些關係會被加入到自注意力層種，從而讓Transformer能夠更好地感知和表示關係。
Meaning Representation
劉乾: 除了上述兩位嘉賓所提到的編碼器和解碼器的設計都會影響模型的效能外，其實還有一點很容易被大家忽視，就是資料集所使用的程式語言本身也會影響模型的效能。去年EMNLP上我們組做了一個工作 [17]，通過實驗我們發現: 即使用同樣語義的語料來訓練模型，模型在不同程式語言上的效能還是有顯著的差異。舉個例子，下表中展示了四種不同的程式語言所對應的的一段語義相同的程式，它們分別是Prolog，Lambda Calculuas, FunQL 和 SQL。我們發現在多數情況下模型在FunQL上的表現要比在SQL上的表現更好，而這有可能是因為FunQL本身的歧義要更少。這也啟發了我們，在收集語義解析的新資料集前要先想想程式語言是否有明顯的改進空間，再請專家標註資料。當然，關於這方面的研究學術界目前還不夠深入，也沒有確定性的結論來指導我們設計“更好”的程式語言。
預訓練模型 Pre-trained Language Models
殷鵬程: 正如我們之前所提到的，語義解析任務需要很多的領域知識，例如程式相關的語法結構。而在領域知識中，另一塊比較重要的其實就是表格 (例如text-to-SQL裡需要把表格作為輸入的一部分)。目前主流的語義解析中的預訓練模型都是與表格相關的。下圖對比展示了傳統的針對文字資料的預訓練(左側)和針對表格資料的預訓練(右側)。傳統的文字預訓練模型在閱讀理解任務中應用時需要利用Transformer來理解問題 Who created Facebook，並在相應的領域知識——非結構化文件上進行推理得到最終的答案；針對表格的預訓練模型在語義解析任務中應用時同樣需要學會理解問題如 Flights from Pittsburgh to Seattle，但它的領域知識變成了結構化的資料表，最終輸出的是程式語言如SQL, GraphQL 等。同樣地，針對表格的預訓練同樣需要用Transformer來編碼，編碼過程主要有兩大難點: (1) 如何用 Transformer編碼結構化的表格；(2) 如何設計一個通用的預訓練模型，使得其可以相容不同的程式語言。
TaBERT
殷鵬程: 針對以上問題，我們提出了一個可以增強表格理解的預訓練語言模型TaBERT [18]。該模型設計的主要一個出發點在於，現實生活中表格會非常長，比如商用系統中的資料表可能有成千上萬行。所以，第一步要先做一個數據精簡，即下圖中的選擇編碼(Selection Encoding)。以下圖中的問題為例，當用戶提問 In which city did Piot’s last 1st place finish occur? TaBERT首先會選幾個與問題相關的行(下圖紅色所示)，然後只需要編碼它們即可。有了精簡的表格後，接下來的一個關鍵問題在於，如何修改Transformer從而讓它能夠理解結構化的表格知識。TaBERT通過擴充套件傳統的自注意力(Self Attention)，讓模型既能注意到水平方向的其他格，也可以注意到垂直方向的其他格的內容。TaBERT最終的輸出不僅包括了使用者問題的表示，還包括了表格中的每個表頭的表示。這些表示可以被下游的語義解析模型用到，從而解碼得到對應的程式語言。
GraPPa
王柏林: GraPPa [19] 跟TaBERT的動機是一樣的，就是如何利用大規模的預訓練資料來通用地向語義解析模型注入領域知識。但是不同於TaBERT在網上爬取大規模的資料，GraPPa的核心思想是利用現有資料集裡的模板系統性地構造大規模的資料。其構造資料的核心思想借鑑於論文[20]，即通過同步上下文無關文法(SCFG)來合成新的自然語言和程式語言的成對資料。GraPPa首先通過現有的資料集人工歸納出SCFG文法，接著將這些SCFG應用在新的程式語言上，從而得到可能有噪音的(自然語言,程式語言)的成對資料。最終，搭配合適的預訓練目標，GraPPa可以普遍地增強text-to-SQL模型的效能。預訓練用到的訓練模板除了傳統的掩碼自然語言目標(Masked Language Model, MLM) 外，還引入了SQL語義預測目標(SQL Semantic Prediction)。前者就是利用自然語言上下文去預測當前被[MASK]掉的詞對應的原文中的詞，而後者是去預測這個自然語言對應的SQL的操作符有哪些。
TAPEX
劉乾: 不同於上兩個預訓練模型最終的應用場景是輸出SQL，TAPEX [21] 的目標是增強模型在弱監督場景下的效能。它的下游模型在接受自然語言問題和表格作為輸入後，直接輸出其對應的答案。因此呢，TAPEX 提出的目的就在於提升下游模型在理解表格結構以及在表格上進行推理的能力。那如何增強下游模型對錶格的推理能力呢，TAPEX給出的答案是：讓模型去模仿學習一個SQL執行器的行為。如果一個神經網路都能學會執行如此複雜的SQL，並給出它正確的執行結果，那我們可以預期它對錶格的結構也好，在表格上的推理能力都應是相當強的。TAPEX的實驗也驗證了，就只需要在這種SQL和其執行結果的純合成的資料上做預訓練，TAPEX也能在四個不同的資料集上都獲得最好的效能。
互動式語義解析 Interactive Semantic Parsing
姚子瑜: 互動式語義解析的主要目標是豐富人與語義解析系統之間的互動，系統可以通過與人的互動來提升系統的置信度。一個互動式的對話如下圖所示。
Learning from User Feedback
姚子瑜: 當用戶問的問題裡有歧義時，或者系統不理解使用者的問題時，我們希望系統能夠主動地提出一些澄清式問題以從使用者的反饋中學習。如下圖所示，當系統不理解使用者提出的問題時，可以通過使用者的反饋（比如做下圖的多選題）來告訴系統在這種提問下應該如何決策。在我們的工作中 [22]，我們實現了剛才所描述的系統，期望系統在部署後可以通過與使用者源源不斷的互動來持續提高在程式語言生成的能力。同時這種系統還可以在線上收集更多平行語料。
Learning to Edit Programs
姚子瑜: 除了可以通過互動讓系統更瞭解使用者意圖，系統其實還可以更通用地支援使用者對已經生成的程式進行簡單的編輯，從而在之前的程式的基礎上更快地表達使用者意圖。下圖給出了一個例子，其中源程式(source program)是待編輯的程式，目標程式(target program)是編輯後的程式。在 [23] 這個工作中，我們探索了能否設計一個通用的模型來完成程式的編輯操作。我們所提出的模型直接在程式對應的樹結構上做編輯操作，在每個動作時要確定若干資訊：(1) 編輯型別 (Delete/Add)；(2) 編輯結點 (Node)；以及可能的額外內容如新增的值 (Value)。
Learning to Detect Ambiguity
劉乾: 上面的兩個工作主要關注在系統對自己生成的程式不確信時，目前互動式語義解析中其實也有目標定位在歧義發現(Detect Ambiguity)的工作如 [24]。它主要關注的場景就是，當用戶的話語中包含歧義時，系統能夠發現並給予反饋，同時可以允許使用者簡單地通過選項消除自然語言中的歧義短語。但是，其實這種帶歧義負樣本的資料集目前並不常見。為了解決這個問題，[24] 就把歧義發現建模成了一個細粒度的自然語言和程式語言之間細粒度的匹配問題。匹配上的部分意味著這部分自然語言在程式語言中有所對應，否則的話就意味著這部分自然語言的語義並沒有在程式語言中體現，也就是我們所說的歧義短語。具體的檢測流程如下圖所示。
語義解析領域當前存在的挑戰與未來的方向
在思辨的最後，四位嘉賓針對語義解析領域當前存在的挑戰與未來的方向進行了討論，在這裡我們簡單介紹一下嘉賓們所討論的話題，更多思辨的細節請讀者觀看原視訊 (https://www.bilibili.com/video/BV1Uh411z7ZQ, 1:29:13)。
1. 資料集採集與標註成本高 Dataset Annotation
語義解析任務的目標是生成程式，這就要求資料集在採集時需要請領域專家如程式設計師進行標註，標註成本較高。如何降低資料集的標註成本是第一大挑戰·。
2. 語義解析領域的預訓練 Pre-training for Semantic Parsing
預訓練現在非常火熱，該如何設計針對於語義解析任務的預訓練模型，或者如何在語義解析裡用好開放式的大規模預訓練模型是第二大挑戰。
3. 模型的組合泛化問題 Compositional Generalization
程式是組合性的，組合的特點就意味著程式的搜尋空間非常大，如何讓語義解析模型能夠泛化地生成程式的新組合是第三大挑戰。
4. 未來資料集與任務正規化 Future Avenues: Datasets and Tasks
對於語義解析的未來，嘉賓們認為主要有兩大方向: (1) 如何將語義解析與閱讀理解等沒有顯式程式標註的場景結合，(2) 對這些新的領域和應用場景，該如何構建更有效的系統評價體系，從而幫助設計更實用，更有價值的語義解析系統。