自动生成sql语句 软件，sql自动化测试

机器之心原作者：思源

“10万到20万之间的大众车型有多少种？”—— 机器能理解这样的自然语言并从表格中检索答案吗？这是一个值得思考的问题，也是追一科技中文NL2SQL挑战赛的一个重要目标。今天，首届中国NL2SQL挑战赛正式开始提交模型成绩。此前，追一科技AI实验室介绍了NL2SQL的概念和开发流程，但在这篇文章中我们将重点讨论如何解决这个挑战，并希望参赛者的提交成绩能够提高到一个更高的水平。

挑战地址：https://tianchi.aliyun.com/competition/entrance/231716/introductionNature Language for SQL是什么？

顾名思义，Nature Language To SQL 将自然语言转换为SQL 查询语句以检索您需要的信息。基本上，它将自然语言转换为机器语言以执行某些专门任务。该任务的重点是解析自然语言的语义，并将这些语义编码成计算机可以理解和执行的语句。

事实上，过去已经进行过很多类似的研究，例如将GUI界面转换为正式代码以及学习如何编辑源代码。虽然它们之间存在很多差异，但它们都使用深度网络从图像或文本中提取语义信息，然后尝试根据这些语义信息生成相应的代码。

因此，无论您是将自然语言转换为Python 还是C++ 代码，您的想法都与NL2SQL 相同。下面我们将通过一个简单的案例来看看您可以使用NL2SQL 做什么。如下图，有一个表格可以让你推断出很多信息，比如“各种车型总共售出了多少辆宝马？”

表当然看起来很漂亮，但如果它是一个包含数千个表的数据库，则需要SQL 语言。如果您手动将上述查询写入相应的SQL 表达式“SELECT SUM(Sales) FROM TABLE WHERE Brand==\'BMW\';”，您将得到答案“8”。但是，这种方法需要您了解SQL 语句，并且查询需要表达式。

NL2SQL所做的就是自动化这个过程，连接用户想要查询的表，并将用户的问题翻译成相应的SQL语句。首届中文NL2SQL挑战赛

通过NL2SQL竞赛题，追一科技希望拉近用户与结构化数据的距离，让机器不仅能理解我们的问题，还能从数据库中自己找到答案。

其实，竞争问题本身很容易理解。换句话说，如果你输入一个中文问题，你期望模型根据该问题输出相应的SQL查询语句。总赛题以金融和通用领域表为数据源，并提供带注释的自然语言和SQL语句对。玩家可以使用这些数据来训练一个可以自动生成SQL 语言的模型。

训练数据

据追一介绍，本次大赛的数据集包含约4500个表格，基于这些表格提出了5万个自然语言问题以及相应的SQL语句。通过爬取和解析公共数据源中的表来获取数据，并通过手动注释来构造问题和相应的SQL 语句。

具体来说，追一科技正在构建一个标注平台，允许标注者在平台上查看表格。理解表的内容后，注释者必须根据表用自然语言提出问题，并通过UI 点击来构造SQL 语句。标记的数据是手动验证的，一段时间后我们会尽力避免错误标记、歧义等。

比赛提供了40,000 个标记数据作为训练集，10,000 个未标记数据作为测试集。其中5000条未标注数据将作为初步测试集，玩家可以直接下载测试。剩下的5000个将作为半决赛的测试集。这些数据无法下载。玩家必须提交打包的代码镜像才能运行并获得预测结果。

此外，为了更容易区分预赛和半决赛，半决赛的测试集包含了更多训练集中未包含的表格数据，以验证解决方案的泛化能力。

数据集主要由三个文件组成，例如训练集包括train.json、train.tables.json和train.db。其中train.json存储所有问题和对应的SQL表达式，train.tables.json存储所有表。此外，train.db 是SQLite 格式的数据库文件，用于执行模型生成的SQL 语句。

train.json文件中的每一行都是一个数据样本，数据样本和字段说明如下：总体而言，模型应根据“table_id”和“question”预测完整的SQL 表达式“sql”。

由于SQL表达式由许多子语句组成，因此“sql”由一组选项组成，包括选定的列、列操作、选定的条件约束等。具体来说，SQL表达式字典为： \'agg\' 选择agg_sql_dict 作为条件类型，\'cond_conn_op\' 选择conn_sql_dict，\'conds\' 选择op_sql_dict。

请注意，“cond_conn_op”表示条件之间的关系。也就是说，如果一个表达式包含多个条件，它们之间的关系可以是AND、OR 或NONE。下面的“conds”具体描述了具有多个三元组的条件语句。例如，[3,0,100]表示选择第四列中大于100的条目，即col_4100。

那么表格会是什么样子呢？在train.tables.json文件中，每一行都是表数据。以下是数据示例和字段的简要说明。

表格数据很容易理解；只需确定每个特征列的名称、数据类型和数据值即可。

您可以在下面使用训练集中的特定样本和表格来了解模型应该预测什么。总体而言，模型应该首先根据table_id检索对应的表，然后根据问题从对应的表中检索信息，并生成对应的SQL表达式。它只是简化了问题，因为您不必根据问题搜索表格，也不必跨越多个表格。

这里的关键是模型需要知道如何从问题构造SQL 表达式。如下图，如果我们看一下“2019年第四周《大黄蜂》和《密室逃脱》两部电影的总票房份额是多少？”这个问题，我们发现它们各自的票房份额是15.6%原来是14.2%。综合来看，每周票房份额为29.8%。

那么模型需要做什么呢？它需要通过各种子任务来确定SQL表达式的不同模块，并构建完整的语句，通过该语句得到正确的答案。

具体来说，模型需要通过问题“占总票房收入的百分比是多少？”来确定是否需要选择第三个特征列“占票房收入的百分比(%)”。即\'sel\':[2]，以及对应的聚合函数“SUM”，\'agg\':[5]。从问题陈述“大黄蜂与密室逃脱”中，从电影标题中识别出“大黄蜂”和“密室逃脱”这两个条件，同时这两个条件之间的关系是“AND”，即需要“AND”。已确定\ 'conds' 和'cond_conn_op' 分别是什么？

如果这些预测正确，模型就可以正确合成SQL 表达式。

SELECT SUM(col_3) FROM Table_4d29d0513aaa11e9b911f40f24344a08 WHERE (col_1=='Bumblebee' and col_1=='Escape Room') 表达式完全正确的话当然没有问题，但只要有一个子句预测错误，陈述整个事情变成了一个问题。因此，在实际比赛中，追一科技的基线模型提供了多个指标，不仅需要知道每个子句的准确性，还需要知道整体表达的准确性。基线模型

由于此类问题确实非常困难，追一科技提供了一个基线解决方案供玩家参考。玩家只要报名参加挑战，就可以下载数据集并将其放入基线模型中来实验效果。您只能更改核心模型部分才能获得更好的效果。

基线模型地址：https://github.com/ZhuiyiTechnology/nl2sql_baseline 基线模型使用Python 2.7和torch 1.0.1构建。玩家必须在天池竞赛页面下载数据集和预先训练的词嵌入，并进行相应的组织。它需要一定的结构才能最终实现。以下是您需要组织的数据集结构。之后将以下data_nl2sql目录的所有内容复制到基线模型下的data目录中。

这里展示了数据集，但还有一个额外的字符级词向量文件char_embedding。

追一科技表示，其提供的字符级预训练词嵌入是在10G大小的百度百科和维基百科语料库上使用Skip-Gram进行训练的。以词为单位，避免了专有名词引起的OOV问题和分词错误引起的错误累积。

理论上，BERT 也可以用作模型的输入表示。 BERT 的细粒度分词非常适合数据集，目前WikiSQL 数据集上的SOTA 模型X-SQL 和SQLova 都采用了这种策略。追一科技表示，将SOTA模型迁移到本次挑战赛的数据集将显着提高其有效性，因此玩家也可以尝试BERT。

最后，基线模型GitHub项目详细介绍了训练和评估过程，玩家只需按照步骤操作即可。此外，如果您本地环境存在配置问题或缺乏GPU 计算能力，您还可以尝试在Colab 中运行基线模型。

Colab 基线模型：https://drive.google.com/open id=10RtAom_D4zOp_w5OsYLTtLd2TEuC7C1X 训练模型需要大量的计算能力。在K80 上训练一个epoch 大约需要7-8 分钟。基线模型默认训练100 个epoch。下面一的意思是，经过多次实验，验证集上的平均逻辑形式准确度为27.5%，这意味着每个SQL子句有27.5%的机会被正确预测。

模型结构

基线模型基于已有17 年历史的SQLNet 并对其进行改进，这也是WikiSQL 数据集的基线模型。这个网络的中心思想是分离不同的子句。不同子句的顺序并不重要，它们之间的独立性非常强，因此最好将它们分开。

由于SQLNet定义了模板并在模板上构建了子句之间的依赖关系，因此您可以通过在模板中填充各种子句来完成SQL语句的构建。在这里，模型必须分别预测每个子句的值。这意味着必须使用六个神经网络来预测选定的列、聚合函数、条件类型、条件值等。

下图(a)显示了SQL表达式模板，它分为两部分：SELECT和WHERE。 WHERE 还可以包含多个条件语句。下图(b)展示了各个子任务之间的依赖关系，其中SELECT和WHERE彼此独立，但内部又相关。例如，对于每个WHERE条件语句，模型需要根据特征列确定特征列的值，还需要根据特征列确定其与值之间的条件类型。他们中的三个人可以决定一个条目（行）。

注：选自原始SQLNet 论文arXiv: 1711.04436。

该模板相对通用，可以通过扩展模板合并任何SQL 语言。挑战的基线模型与SQLNet 没有太大区别，只是挑战增加了两个子任务：Select-Number 和Where-Relationship。这两个子任务可以更好的适应中文NL2SQL数据集。

事实上，我们发现WHERE子句是模型求解难度较大的部分，而该子句中确定特征列和确定特征列的值是最困难的，并且比其他子任务的精度要低。因此，如何解决这些问题，打造更强的整体表现，是玩家们应该思考的问题。

代码结构

模型的主体在sqlnet目录中，你需要理解和修改的代码实质上就在该子目录model中，其他功能如数据加载和处理等可以直接复用。模型目录的代码结构简述如下。 sqlnet文件负责构建整个网络框架，模块目录下的代码就是完成子任务的各个神经网络。

追一表示，核心代码一般可以分为三个部分，玩家可以根据这三个部分来改变基线模型。

输入公式：由于问题和表格数据中有很多专有名词，因此自然语言问题、表格列名、表格内容都用单词来表达，以避免由于词汇覆盖率不足或分词错误而导致OOV问题。作为基本单位的单位向量。轻松切换到BERT、MT-DNN 和其他更好的特征表示。编码层：使用双向LSTM对自然语言问题和列名称进行编码，以获得相应的向量表示。这部分的结构在多个子任务之间共享，但参数不共享。各个子任务模块：由于基线是基于SQLNet修改的，所以模型仍然有多个子任务。基线模型还根据不同的子任务在代码级别进行了显式模块化。如果参与者对各个子任务之间的关系有更好的了解，或者认为有更好的方式来生成SQL，他们可以直接在这些子任务模块中重写SQL。等级

模型评估主要有两个指标：“逻辑形式准确性”和“执行准确性”，最终玩家排名根据这两个指标的平均值确定。其中，Logic Form Accuracy决定了玩家预测的SQL与实际SQL逻辑的准确性，即选择的目标列是否匹配、聚合函数是否匹配、条件列是否匹配、条件表示是否匹配。价值观一致等执行准确度表示玩家预测的SQL执行结果与实际的SQL执行结果是否相符。

计算这两个指标非常简单：如果预测的SQL表达式或搜索结果与注释匹配，则将正确答案的数量加1，并将最终正确答案的数量除以预测总数，这就是正确答案率。

然而，在实际训练中，基线模型也会输出一组子任务的效果。下面是训练80个epoch后的输出结果。除了逻辑形式和执行精度之外，可以看到还有八个子任务： Sel-Num.作为任务的准确性。

如上所示，“Sel-”代表SELECT部分的子任务，“W-”代表WHERE部分的子任务。例如，Sel-Col代表列选择的精度，Sel-Agg代表聚合函数选择的精度，W-Op代表条件类型选择的精度，W-Val代表条件值选择的精度。差异与改进

之前的基线模型展示了一个通用的解决方案。目前有很多好的NL2SQL模型可以作为参考，在WikiSQL数据集上实现SOTA结果。但在这里您需要了解竞争数据集和WikiSQL 之间的区别，以便您可以有目的地改进它。

数据集之间的三个主要区别

追一科技表示，本次大赛的数据集与WikiSQL主要存在三个差异/难点，这也是选手们在本次大赛中需要解决的核心问题。

表格的内容会显示给玩家，并且问题会被概括。

以这张表为例，如果WikiSQL 中的自然语言问题是“今天腾讯控股股票上涨了多少？”，那么对应的SQL 语句就是“SELECT 增减FROM TABLE WHERE 股票名称==\'腾讯'' 。 Holdings\'”，因此模型可以简单地从原始句子中提取子字符串作为条件值。但是，在挑战数据集中，同样的问题可能会变成“今天鹅厂上涨了多少？”。这不仅允许模型预测对股票名称列进行条件限制的需要，而且还可以概括表的内容以生成正确的SQL。

省略显式的列名信息，使其更加口语化。在WikiSQL 中，自然语言问题在注释方式上与基于模板的问题类似，因此通常包含更明确的列名称信息。例如，“今天腾讯控股股价上涨了多少？”，上市信息将是“股票”。在挑战数据集中，问题更加口语化，更接近现实生活场景。为了正确生成SQL，模型必须首先连接腾讯和股票名称列。

数字单位问题是针对这样的表：数据集中的一个问题可能是“本周北京成交了多少万平方米？”因此，存在着几千平方米到一万平方米的单位没有标准化的问题。

改进计划

我们已经展示了上面几个数据集之间的差异，理解它们对于改进您的解决方案非常重要。如前所述，目前WikiSQL 最好的模型，例如X-SQL 和SQLova，使用BERT 和MT-DNN 作为输入表示，可以取得非常好的结果。另外，模型处理流程和依赖关系还可以改进，可以概括为以下三个方向。

BERT、XLNet等具有更好的输入特征和更合理的模型结构，并且目前的基线模型是管道方法，预测条件列，然后预测条件操作和条件值。然而，在实际数据中，需要联合预测方法来解决该问题。如何合理地将表中的数据整合到我的模型中呢？以前的解决方案忽略了表中的数据。以下是关于上述三个方向的一些论文。更多顶级模型可以在WikiSQL 基准测试中找到。

[1]X-SQL: 丰富上下文到模式表示，2019

[3] 使用语法和表感知SQL 生成进行语义解析，2018

[1] WikiSQL 与表感知Word 上下文化的综合调查，2019

WikiSQL 基准：https://github.com/salesforce/WikiSQL