一起养成写作习惯！这是我参与「掘金日新计划 · 4 月更文挑战」的第12天，点击查看活动详情。
导语
前面的一系列博客中，我们已经了解到Text2SQL任务的基本定义和WikiSQL数据集上的一些基本研究方法。然而，WikiSQL数据集虽然体量巨大，但是由于其数据集比较简单，导致其实际应用很受限。基于此，本篇博客将介绍目前Text-to-SQL领域应用范围最广，最复杂的数据集之一--Spider。
Spider数据集概述
基本特性
Spider数据集是一个多数据库、多表、单轮查询的Text-to-SQL数据集。WikiSQL 中查询和表的数量很多，但是所有 SQL 查询都很简单，仅包含 SELECT 和 WHERE 从句，而且WHERE子句中的约束条件不超过3个。此外，每个数据库都只是没有外键的简单的表。在 WikiSQL 上训练的模型在无法处理复杂的 SQL语句要素（如 GROUP BY、ORDER BY 或嵌套查询）和具备多个表和外键的数据库。Spider数据集由 11 名耶鲁大学学生标注，包含 10181 个问题和 5693 个独特的复杂 SQL 查询、200 个具备多个表的数据库，覆盖 138 个不同领域，实际应用性很强。
图1展示了Spider上的一个示例。从图中可以看出，Spider上的数据库是多表数据库，同时问题也复杂很多。相应的SQL语句中包含了JOIN、GROUP BY、HAVING、嵌套等诸多SQL高级语法内容。同时，该数据集也根据相应SQL语句的复杂程度划分了不同的难度等级。如下图所示，这里的hard和extra hard难度的SQL语句，即使是一名经验丰富的数据库工程师也很难快速写出。
Spider数据集将140个数据库作为训练集，20个数据库作为验证集，40个数据库作为测试集。同时，测试集不公开，研究者需要将自己的模型在验证集上调试到最佳性能后将模型发给Spider官方，有官方在测试集上进行测试，并将结果公布在Leaderboard上以确保模型方法对比的公平性。
评价指标
主要评价指标有两个：
-
Exact Match(EM): 模型预测的SQL语句必须与ground truth完全一样。
- 由于SQL语句中句式的多样性，完成同样的任务不一定能唯一确定SQL语句。因此这是一种过于严格的评价指标。
- 如上图所示，假如真实的SQL语句为
SELECT COUNT(name) WHERE SSN = 123，只有当预测结果与该语句一模一样时2，才认为预测正确。
-
Execution Accuracy(EX)：模型预测的语句执行后所得的结果与ground truth一样。
- 相较于EM放宽，但又引入另一种歧义：模型可能预测出语义完全不同的SQL语句，但恰好有相同的执行结果。这样的情况也会被该指标纳入正确范围。
- 如上图所示，假如预测的SQL语句为
SELECT COUNT(SSN) WHERE SSN = 123，这事，只要预测SQL语句的执行结果与真实SQL语句执行结果一致时，就认为预测正确。
相关研究
目前该数据集的Leaderboard如下：
主要研究论文如下：
实验
作者在两种划分形式下进行了实验。
- Example Split：将数据集中所有样例按照7:1:2比例划分训练/验证/测试。同一个数据库下的样例可能同时存在于训练和测试中（即测试集中的数据库在训练时模型已经见过了）。
- Database Split：将数据集中所有数据库按照7:1:2比例划分训练/验证/测试。同一个数据库下的样例只能存在于训练/验证/测试集之一（即验证/测试集中的数据库在训练时模型从未见过）。
其中，Dataset Split考验了模型在真实世界的泛化能力，体现了模型在一个没有见过的数据库上的真实表现，后续的研究一般都基于此。
作者将WikiSQL上一些表现很好的模型迁移到Spider上进行测试，得到结果如下：
可以看到，在Database Split下，TypeSQL和SQLNet性能都不佳。只有10%左右的准确率。
总结
Spider数据集提出于2018年的EMNLP。在当时，这个数据集的提出对于WikiSQL上各种表现不错的方法带来了巨大的挑战。比如当时最好的TypeSQL在WikiSQL上能够达到75%左右的准确率，但在Spider上却连10%都无法达到。Spider数据集涵盖了SQL的绝大部分高级语法，贴近现实应用，一经提出就吸引了广大研究者的兴趣。下一篇博客将为大家介绍Spider上作者给出的第一个baseline，SyntaxSQLNet模型。
