NL2SQL 这个领域研究进展如何了？ 大家如何看待WikiSQL的准确度达到90%以上 ？

在CUI（Conversation User Interface）的大背景下， 如何通过自然语言自由地查询数据库中的目标数据成为了新兴的研究热点。Natural Language to SQL( NL2SQL)就是这样的一项技术，可以将用户的自然语句转为可以执行的SQL语句。

NL2SQL这一任务的本质，是将用户的自然语言语句转化为计算机可以理解并执行的规范语义表示(formal meaning representation)，是语义分析(Semantic Parsing)领域的一个子任务。NL2SQL是由自然语言生成SQL，那么自然也有NL2Bash、NL2Python、NL2Java等类似的研究。下面是来自NL2Bash Dataset的一条数据，

NL: Search for the string ’git’ in all the files under current directory tree without traversing into ’.git’ folder and excluding files that have ’git’ in their names.

Bash: find . -not -name ".git" -not -path "*.git*" -not –name "*git*" | xargs -I {} grep git {}

虽然生成的程序语言不同，但核心任务与NL2SQL相同，都是需要计算机理解自然语言语句，并生成准确表达语句语义的可执行程序式语言。

广义来说，KBQA也与NL2SQL技术有着千丝万缕的联系，其背后的做法也是将用户的自然语言，转化为逻辑形式，只不过不同的是转化的逻辑形式是SPARQL，而不是SQL。通过生成的查询语句在知识图谱中的执行，进而可以直接得到用户的答案，进而可以提升算法引擎的用户体验。

图片来自于谷歌搜索

四大数据集

目前，NL2SQL方向已经有WikiSQL、Spider、WikiTableQuestions、ATIS等诸多公开数据集。不同数据集都有各自的特点，在这里分别来简单介绍一下这四个数据集。

WikiSQL是Salesforce在2017年提出的一个大型标注NL2SQL数据集，也是目前规模最大的NL2SQL数据集。其中包含了26,375张表、87,726条自然语言问句及相应的SQL语句。下图是其中的一条数据样例，包括一个table、一条SQL语句及该条SQL语句所对应的自然语言语句。

该数据集自提出之后，已经有17次公开提交。因为SQL的形式较为简单，不涉及到高级用法、Question所对应的正确表格已经给定、不需要联合多张表格等诸多问题的简化，目前在SQL执行结果准确率这一指标上已经达到了91.8%。

Spider是耶鲁大学在2018年新提出的一个较大规模的NL2SQL数据集。该数据集包含了10,181条自然语言问句、分布在200个独立数据库中的5,693条SQL，并且内容覆盖了138个不同的领域。虽然在数据数量上不如WikiSQL，但Spider引入了更多的SQL用法，例如Group By、Order By、Having，甚至需要Join不同表，这更贴近于真实场景，也带来了更大的难度。因此目前在榜单上，只有5次提交，在不考虑条件判断中value的情况下，准确率最高只有24.3，可见这个数据集的难度非常大。

下图是该数据集中的一条样例。在这个以College主题的数据库中，用户询问“讲师的工资高于平均工资水平的部门以及相应的预算是什么？”，模型需要根据用户的问题和已知的数据库中的各种表格、字段以及之间错综复杂的关系来生成正确的SQL。

WikiTableQuestions是斯坦佛大学于2015年提出的一个针对维基百科中那些半结构化表格问答的一个数据集，包含了22,033条真实问句以及2,108张表格。由于数据的来源是维基百科，因此表格中的数据是真实且没有经过归一化的，一个cell内可能包含多个实体或含义，比如“Beijing, China” or “200 km”；同时，为了可以很好地泛化到其它领域的数据，该数据集在测试集中的表格主题和实体之间的关系都是在训练集中没有见到过的。下图是该数据集中的一条示例，数据阐述的方式，展现出作者想要体现出的问答元素。

而The Air Travel Information System(ATIS)是一个年代较为久远的经典数据集，由德克萨斯仪器公司在1990年提出。该数据集获取自关系型数据库Official Airline Guide (OAG, 1990)，包含27张表以及不到2000次的问询，每次问询平均7轮，93%的情况下需要联合3张以上的表来得到答案，问询的内容涵盖了航班、费用、城市、地面服务等信息。下图是取自该数据集中的一条样例，可以看得出来比之前介绍的数据集都更有难度得多。

在深度学习端到端解决方案流行之前，这一领域的解决方案主要是通过高质量的语法树和词典来构建语义解析器，再将自然语言语句转化为相应的SQL。

现在的解决方案则主要是端到端与SQL特征规则相结合。

以在WikiSQL数据集上的SOTA模型SQLova为例：首先使用BERT对Question和SQL表格进行编码和特征提取，然后根据数据集中SQL语句的句法特征，将预测生成SQL语句的任务解耦为6个子任务，分别是Select-Column、Select-Aggregation、Where-Number、Where-Column、Where-Operation以及Where-Value，不同子任务之间存在一定的依赖关系，最终使用提取到的特征，依次进行6个任务的预测。

NL2SQL的未来

WikiSQL数据集虽然是目前规模最大的有监督数据集，但其数据形式和难度过于简单：对于SQL语句，条件的表达只支持最基础的>、<、=，条件之间的关系只有and，不支持聚组、排序、嵌套等其它众多常用的SQL语法，不需要联合多表查询答案，真实答案所在表格已知等诸多问题的简化，所以在这个数据集上，SQL执行结果的准确率目前已经达到了91.8%。

但同时存在一个问题，这样的数据集并不符合真实的应用场景。在真实的场景中，用户问题中的值非常可能不是数据表中所出现的，需要一定的泛化才可以匹配到；真实的表之间存在错综复杂的键关联关系，想要得到真实答案，通常需要联合多张表进行查询；每一张都有不同的意义，并且每张表中列的意义也都不同，甚至可能相同名字的列，在不同的表格中所代表的含义是不同的；真实场景中，用户的问题表达会很丰富，会使用各种各样的条件来筛选数据。诸如此类的实际因素还有很多。因此，WikiSQL数据集起到的作用更多程度上是抛砖引玉，而不具备实际应用场景落地的价值。

相比之下，Spider等数据集更贴近于真实应用场景：涉及到查询语句嵌套、多表联合查询、并且支持几乎所有SQL语法的用法，用户问句的表达方式和语义信息也更丰富。但即使作者们考虑到数据集的难度，贴心地将数据集按照难度分为简单、中等和困难，数据集的难度也依然让人望而生畏，目前各项指标也都很低。如何更好地结合数据库信息来理解并表达用户语句的语义、数据库的信息该如何编码及表达、复杂却有必要的SQL语句该如何生成，类似此类的挑战还有很多需要解决，都是非常值得探索的方向。

现在很多NLP的子任务的指标都已经刷得让人无路可走了，低垂的果实被摘得七零八落。NL2SQL，以及其它的语义分析的任务，因为各种各样的原因，现在还没有引起大家足够的关注，但却有着相比于其它任务更高的实际应用价值。如果可以落地真实场景，将极大地改变现有的用户和数据库之间的交互方式，人们可以自由地和数据库进行交互，充分挖掘数据的价值，也减轻程序员的负担。期待NL2SQL在不远的将来会迎来属于自己的春天，学术应用两开花。

“分析自然语言写的查询”和“把自然语言表达的信息需求变成查询”是两个截然不同的任务，前者只是后者的一个子集

事实上绝大多数结果能看的工作都在数据集构建/Introduction中明确指出了研究对象其实是前者