百度语义解析 ( Text-to-SQL ) 技术研究及应用

来源：DataFunTalk

本文长度为6500字，建议阅读10+分钟

本文介绍自然语言问题转成数据库可操作的SQL查询语句的应用。

[ 导读 ]语义解析 ( Semantic Parsing ) 是自然语言处理技术的核心任务之一，涉及语言学、计算语言学、机器学习以及认知语言等多个学科，在近几年中获得了广泛关注，语义解析任务有助于促进机器语言理解的快速发展。

本文重点介绍语义解析技术中的Text-to-SQL任务，让机器自动将用户输入的自然语言问题转成数据库可操作的SQL查询语句，实现基于数据库的自动问答能力。

任务介绍及研究动机

 

当前，大量信息存储在结构化和半结构化知识库中，如数据库。对于这类数据的分析和获取需要通过SQL等编程语言与数据库进行交互操作，SQL的使用难度限制了非技术用户，给数据分析和使用带来了较高的门槛。人们迫切需要技术或工具完成自然语言与数据库的交互，因此诞生了Text-to-SQL任务。

我们通过图1中的实例来介绍一下Text-to-SQL任务。该任务包含两部分：Text-to-SQL解析器和SQL执行器。

解析器的输入是给定的数据库和针对该数据库的问题，输出是问题对应的SQL查询语句，如图中红色箭头标示。SQL执行器在数据库上完成该查询语句的执行，及给出问题的最终答案，如图中绿色箭头标示。

SQL执行器有很多成熟的系统，如MySQL，SQLite等，该部分不是本文重点。本文主要介绍解析器，学术界中Text-to-SQL任务默认为Text-to-SQL解析模型。

图1

首先，我们介绍一下术语“数据库”和“SQL查询语句”：

1. 数据库由一张或多张表格构成，表格之间的关系通过外键给出。在该实例中，数据库由表 “中国城市”和“2018年宜居城市” 构成，两张表通过外键：“中国城市”的“名称”列和“2018年宜居城市”的“名称”列关联；

2. 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技术能够有效地辅助人们对海量的数据库进行查询，因其有实用的应用场景，引起了学术界和工业界的广泛关注。我们接下来将从相关数据集和模型两方面介绍该技术的研究进展。

1. 数据集介绍

图2给出了Text-to-SQL数据集发展趋势，代表数据集参见表1。

图2

其中术语介绍：

• 根据包含领域数量，数据集分为单领域和多领域。

• 根据每个数据库包含表的数量，数据集分为单表和多表模式。在多表模式中，SQL生成涉及到表格的选择。

• 根据问题复杂度，数据集分为简单问题和复杂问题模式，其中问题复杂度由SQL查询语句涉及到的关键词数量、嵌套层次、子句数量等确定。

• 根据完整SQL生成所需轮数，数据集分为单轮和多轮。

• 若SQL生成融进渐进式对话，则数据集增加“结合对话”标记。当前只有CoSQL数据集是融进对话的数据集。

表1

由图2和表1可知，当前主流数据集都是多领域的，这就要求Text-to-SQL解析模型除了满足问题无关外，还要满足领域无关。

2. 模型介绍

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的可执行性和准确率。

3. 评价方法

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的客服业务等，所以结合实际应用，在数据集建设及模型构建方面做了一些工作，有一定的技术积累。

1. 数据集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的统计

2. 模型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生成。
  

• 融进渐进式对话：对于用户的歧义表达和模糊表达，需要有“提问-反馈-再提问”的过程，这类问题往往需要通过多轮对话解决，而用户的问题通常是上下文相关的，因此需要模型具备基于上下文的理解和分析能力。
  

今天的分享就到这里，谢谢大家。

参考文献

[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

编辑：黄继彦

校对：林亦霖