Spider: 用于复杂跨域语义解析和文本到 SQL 任务的大规模人工标注数据集

抽象的

我们介绍了 Spider，一个由 11 名大学生标注的大规模、复杂、跨域语义解析和文本到 SQL 数据集。 它包含 10,181 个问题和 5,693 个独特的复杂 SQL 查询，涵盖 200 个包含多个表的数据库，涉及 138 个不同的领域。 我们定义了一个新的复杂跨域语义解析和文本到 SQL 任务，其中不同的复杂 SQL 查询和数据库出现在训练集和测试集中。 以这种方式，该任务要求模型能够很好地泛化到新的 SQL 查询和新的数据库模式。 Spider 与大多数先前的语义解析任务不同，因为它们都使用单个数据库，并且训练集和测试集中使用了完全相同的程序。 我们对各种最先进的模型进行了实验，最好的模型在数据库拆分设置上仅实现了 12.4% 的精确匹配精度。 这表明 Spider 对未来的研究提出了严峻的挑战。 我们的数据集和任务可在 https://yale-lily.github.io/spider 上公开获取。

1简介

语义解析 (SP) 是自然语言处理 (NLP) 中最重要的任务之一。 它需要同时理解自然语言句子的含义，并将它们映射到有意义的可执行查询，例如逻辑形式、SQL 查询和 Python 代码。

最近，一些采用 Seq2Seq 架构的最先进方法能够在一些复杂基准测试（如 ATIS 和 GeoQuery）上实现超过 80% 的精确匹配精度。 这些模型似乎已经解决了该领域的大多数问题。

图 1: 我们的语料库标注了复杂问题和 SQL。 该示例包含多个表的联接、一个 GROUP BY 组件和一个嵌套查询。

但是，该领域之前的工作任务定义简单但却存在问题，因为大多数结果都是通过语义“匹配”而不是语义解析预测的。 现有的 SP 数据集有两个缺点。 首先，那些具有复杂程序的 Zelle 和 Mooney (1996); Li 和 Jagadish (2014); Yaghmazadeh 等人 (2017a); Iyer 等人 (2017) 在用于训练现代数据密集型模型的程序数量方面太小，并且只有一个数据集，这意味着同一个数据库用于训练和测试模型。 更重要的是，逻辑形式或 SQL 标签的数量很少，每个程序大约有 4-10 个自然语言问题的释义来扩展数据集的大小。 因此，完全相同的目标程序出现在训练集和测试集中。 即使在非常复杂的程序上，模型也能取得不错的性能，方法是在训练期间记忆问题和程序对的模式，并在测试期间以与训练集中看到的方式完全相同的方式解码程序。 Finegan-Dollak 等人 (2018) 通过程序拆分数据集，这样两个相同的程序就不会同时出现在训练集和测试集中。 他们表明，在该问题拆分数据设置上构建的模型无法推广到未见过的程序。 其次，现有的数据集在程序和数据库数量方面很大，例如 WikiSQL Zhong 等人 (2017)，只包含简单的 SQL 查询和单个表。 为了测试模型在未见过的复杂程序上的真实语义解析性能及其对新领域进行泛化的能力，必须使用一个 SP 数据集，该数据集包含大量复杂的程序和包含多个表的数据库。

但是，与其他大型真实数据集相比，例如用于物体识别的 ImageNet Deng 等人 (2009) 和用于阅读理解的 SQuAD Rajpurkar 等人 (2016)，由于以下原因，创建这样的 SP 数据集在某些方面更加耗时且具有挑战性。 首先，很难在网上找到包含多个表的许多数据库。 其次，给定一个数据库，标注人员必须理解复杂的数据库模式，以创建一组问题，使其对应的 SQL 查询涵盖所有 SQL 模式。 此外，编写不同的复杂 SQL 查询更具挑战性。 此外，对问题和 SQL 对进行审查和质量检查需要大量时间。 所有这些过程都需要非常具体的数据库知识。

为了解决对大型、高质量数据集的需求，以满足新的复杂跨域语义解析任务，我们介绍了 Spider，它包含 200 个包含多个表的数据库、10,181 个问题和 5,693 个相应的复杂 SQL 查询，所有这些都由 11 名大学生花费 1,000 个工时编写。 如图 1 所示，给定一个包含多个表（包括外键）的数据库，我们的语料库创建并注释了复杂的问题和 SQL 查询，包括不同的 SQL 子句，例如联接和嵌套查询。 为了根据输入问题生成 SQL 查询，模型需要理解自然语言问题以及数据库模式中表和列之间的关系。

此外，我们还为文本到 SQL 问题提出了一项新任务。 由于 Spider 包含 200 个具有外键的数据库，我们可以将包含复杂 SQL 查询的数据集拆分为训练和测试中没有数据库重叠的方式，这克服了先前数据集的两个缺点，并定义了一个新的语义解析任务，其中模型需要不仅要泛化到新的程序，还要泛化到新的数据库。 模型必须以问题和数据库模式作为输入，并预测新数据库上的未见查询。

为了评估任务难度，我们对几种最先进的语义解析模型进行了实验。 他们都难以完成这项任务。 最佳模型在数据库拆分设置中仅实现了 12.4% 的精确匹配精度。 这表明还有很大的改进空间。

2 相关工作和现有数据集

已经创建了几个具有不同查询的语义解析数据集。 输出可以采用多种格式，例如逻辑形式。 这些数据集包括 ATIS Price (1990); Dahl et al. (1994)、GeoQuery Zelle and Mooney (1996) 和 JOBS Tang and Mooney (2001a)。 他们已被广泛研究 Zelle 和 Mooney (1996); Zettlemoyer 和 Collins (2005); Wong 和 Mooney (2007); Das 等人 (2010); Liang 等人 (2011); Banarescu 等人 (2013); Artzi 和 Zettlemoyer (2013); Reddy 等人 (2014); Berant 和 Liang (2014); Dong 和 Lapata (2016)。 然而，它们是特定于领域的，并且没有针对多个 SQL 查询的标准标签指南。

最近，创建了更多使用 SQL 作为程序的语义解析数据集。 Iyer 等人 (2017) 和 Popescu 等人 (2003a) 为 ATIS 和 GeoQuery 数据集标注了 SQL 查询。 其他现有的文本到 SQL 数据集还包括餐厅 Tang 和 Mooney (2001b); Popescu 等人 (2003a)、学者 Iyer 等人 (2017)、学术 Li 和 Jagadish (2014)、Yelp 和 IMDB Yaghmazadeh 等人 (2017b)、咨询 Finegan-Dollak 等人 (2018) 以及 WikiSQL Zhong 等人 (2017)。 这些数据集在 NLP 社区 Warren 和 Pereira (1982); Popescu 等人 (2003b, 2004); Li 等人 (2006); Giordani 和 Moschitti (2012); Wang 等人 (2017); Iyer 等人 (2017); Zhong 等人 (2017); Xu 等人 (2017); Yu 等人 (2018); Huang 等人 (2018); Wang 等人 (2018); Dong 和 Lapata (2018); McCann 等人 (2018) 和数据库社区 Li 和 Jagadish (2014); Yaghmazadeh 等人 (2017b) 中已研究了几十年。 我们在表 1 中提供了有关这些数据集的详细统计数据。

之前的大多数工作都将他们的模型在没有模式作为输入的情况下进行训练，因为它们对训练和测试使用单个数据库。 因此，他们不需要泛化到新领域。 最重要的是，这些数据集的标记逻辑形式或 SQL 查询数量有限。 为了扩大这些数据集的规模并应用神经网络方法，每个逻辑形式或 SQL 查询对于自然语言输入都有大约 4-10 个释义。 之前的大多数研究都遵循标准的问答式训练和测试分割 Zettlemoyer 和 Collins (2005)。 这样，测试中完全相同的目标查询（具有类似的释义）也会出现在训练集中。 利用这种假设，即使在复杂的程序上，现有模型也可以通过记忆特定于数据库的 SQL 模板来获得不错的性能。 但是，这种准确性被人工夸大了，因为模型只需要在测试期间决定使用哪个模板。 Finegan-Dollak 等人 (2018) 表明基于模板的方法可以获得更高的结果。 为了避免得到这种膨胀的结果，Finegan-Dollak 等人 (2018) 提出了一种新的基于程序的拆分评估方法，其中完全相同的查询不会同时出现在训练集和测试集中。 他们表明，在这种框架下，所有当前最先进的语义解析系统的性能都会急剧下降，即使是在同一个数据库上，这也表明这些模型无法泛化到未见过的查询。 这表明目前语义解析研究存在局限性。

我们还希望模型不仅能泛化到未见过的查询，而且能泛化到未见过的数据库。 Zhong 等人 (2017) 发布了 WikiSQL 数据集。 在他们的问题定义中，测试集中的数据库不会出现在训练集或开发集中。 此外，该任务需要将不同的表模式作为输入。 因此，模型必须泛化到新的数据库。 然而，为了为 24241 个数据库生成 80654 个问题和 SQL 对，Zhong 等人 (2017) 对 SQL 查询和数据库做了一些简化的假设。 他们的 SQL 标签只涵盖单个 SELECT 列和聚合，以及 WHERE 条件。 此外，所有数据库只包含单个表。 没有包含 JOIN，GROUP BY 和 ORDER BY 等。

近年来，研究人员构建了一些用于代码生成的数据集，包括 IFTTT Quirk 等人 (2015)，DJANGO Oda 等人 (2015)，HEARTHSTONE Ling 等人 (2016)，NL2Bash Lin 等人 (2018) 和 CoNaLa Yin 等人 (2018)。 这些任务将自然语言描述解析为更通用的编程语言，例如 Python Allamanis 等人 (2015); Ling 等人 (2016); Rabinovich 等人 (2017); Yin 和 Neubig (2017)。

3 语料库构建

图 2： 我们 Spider 语料库的标注过程。

所有问题和 SQL 查询均由 11 名计算机科学专业的学生编写和审查。 其中一些是英语母语人士。 如图 2 所示，我们分五个步骤开发我们的数据集，总共花费了约 1,000 小时的工时：§3.1 数据库收集与创建，§3.2 问题和 SQL 标注，§3.3 SQL 审查，§3.4 问题审查和改写，§3.5 最终问题和 SQL 审查。

3.1 数据库收集与创建

收集具有复杂模式的数据库很困难。 虽然关系数据库在工业界和学术界被广泛使用，但其中大部分并不公开。 只有少数具有多个表的数据库可以在线轻松访问。

我们从三个来源收集了涵盖 138 个不同领域的 200 个数据库。 首先，我们从不同的大学数据库课程、SQL 教程网站、在线 csv 文件和教科书示例中收集了大约 70 个复杂数据库。 其次，我们从 DatabaseAnswers 收集了大约 40 个数据库，其中包含了跨越不同领域的 1,000 多个数据模型。 这些数据模型仅包含数据库模式。 我们将它们转换为 SQLite，使用在线数据库填充工具 填充它们，然后手动更正了一些重要字段，以使表内容看起来更自然。 最后，我们根据 WikiSQL 创建了剩余的 90 个数据库。 为了确保领域多样性，我们选择了大约 90 个不同领域的约 500 个表来创建这 90 个数据库。 为了创建每个数据库，我们从 WikiSQL 开发或测试拆分中选择了几个相关的表，然后根据我们选择的表创建了一个具有外键的关系数据库模式。 我们必须创建一些交叉表才能将几个表链接在一起。 对于大多数其他情况，我们不需要填充这些数据库，因为 WikiSQL 中的表来自维基百科，维基百科已经存储了真实世界的数据。

如果一些数据库模式的某些列名没有意义或缺少一些外键，我们会手动更正它们。 对于表名和列名，在数据库中使用缩写很常见。 例如，“student_id” 可以用 “stu_id” 表示。 为了我们的任务定义，我们手动将每个列名改回普通单词，以便系统只处理语义解析问题。

3.2 问题和 SQL 标注

对于每个数据库，我们让八名精通 SQL 的计算机科学学生创建 20-50 个自然问题及其 SQL 标签。 为了使我们的问题多样化、自然，并能反映人们实际使用数据库的方式，我们没有使用任何模板或脚本生成问题和 SQL 查询。 我们的标注过程确保了以下三个方面。

A)  SQL 模式覆盖。

我们确保我们的语料库包含所有常见 SQL 模式的足够示例。 对于每个数据库，我们要求标注者编写 SQL 查询，这些查询涵盖以下所有 SQL 组件：SELECT 具有多个列和聚合、WHERE、GROUP BY、HAVING、ORDER BY、LIMIT、JOIN、INTERSECT、EXCEPT、UNION、NOT IN、OR、AND、EXISTS、LIKE 以及嵌套查询。 标注者确保数据库中的每个表至少出现在一个查询中。

B)  SQL 一致性。

一些问题有多个结果相同的可接受 SQL 查询。 然而，对类似问题给出完全不同的 SQL 标签会阻碍语义解析模型的训练。 为了避免这个问题，我们设计了标注协议，以便所有标注者在有多个等效查询的情况下选择相同的 SQL 查询模式。

C) 问题清晰度。

我们没有创建（1）含糊不清或过于模糊的，或者（2）需要数据库之外的知识才能回答的问题。

首先，模糊的问题是指没有足够线索来推断要返回哪些列以及要考虑哪些条件的问题。 例如，我们不会问“X 大学最受欢迎的课程是什么？”，因为“受欢迎”的定义不清楚：它可能指的是课程的评分或选修该课程的学生人数。 相反，我们选择问“在 X 大学，选修学生人数最多的课程名称是什么？”。 这里，“受欢迎”指的是学生入学人数。 因此，可以使用“student_enrollment”列作为条件来回答这个问题。 我们认识到，模糊的问题出现在现实世界中的自然语言数据库接口中。

我们同意，未来的工作需要通过系统和用户之间进行多轮交互来澄清这个问题。 然而，我们这里的主要目的是开发一个语料库，以解决处理复杂查询并在数据库之间泛化的难题，而不需要多轮交互，这是现有的语义解析数据集无法做到的。 此外，当前最先进模型的低性能已经表明，我们的任务已经足够具有挑战性，而不需要模糊的问题。 此外，问题需要包含要返回的特定信息。 否则，我们不知道在前面的情况下是否也接受课程 ID。 现有的语义解析数据集中的大多数问题都是模糊的。 如果我们使用一个单一数据集，这不是一个严重的问题，因为我们有足够的数据领域特定示例来了解哪些列是默认的。 然而，在跨域任务中，这将是一个严重的问题，因为默认的返回值在跨域和人员之间有所不同。

其次，人类有时会问一些需要超出给定数据库的常识知识的问题。 例如，当人们问“显示向 John 报告的员工的员工 ID”时，正确的 SQL 是

SELECT 员工 ID

FROM 员工

WHERE manager_id = (

SELECT 员工 ID

FROM 员工

WHERE first_name = ‘John’)

这需要常识，即“X 向 Y 报告”对应于“员工-经理”关系。 我们不包括此类问题，并将它们留作未来研究方向。

标注工具

我们在基于 Web 的界面上打开每个数据库，该界面由 sqlite_web 工具提供支持。 它允许标注者查看每个表的模式和内容、执行 SQL 查询并检查返回的结果。 此工具对标注者写出反映给定问题真实含义并返回正确答案的可执行 SQL 查询非常有用。

Dataset	# Q	# SQL	# DB	# Domain	​​# Table / DB ​​	ORDER BY	GROUP BY	NESTED	HAVING
ATIS	5,280	947	1	1	32	0	5	315	0
GeoQuery	877	247	1	1	6	20	46	167	9
Scholar	817	193	1	1	7	75	100	7	20
Academic	196	185	1	1	15	23	40	7	18
IMDB	131	89	1	1	16	10	6	1	0
Yelp	128	110	1	1	7	18	21	0	4
Advising	3,898	208	1	1	10	15	9	22	0
Restaurants	378	378	1	1	3	0	0	4	0
WikiSQL	80,654	77,840	26,521	-	1	0	0	0	0
Spider	10,181	5,693	200	138	5.1	1335	1491	844	388

表 1： 文本到 SQL 数据集的比较。 Spider 是 唯一一个 包含跨域的多表数据库和复杂 SQL 查询的文本到 SQL 数据集。 它的设计旨在测试系统对新 SQL 查询和数据库模式以及新领域进行泛化的能力。

3.3 SQL 审查

一旦数据库用问答对进行了标注，我们要求不同的标注者检查问题是否清晰且包含足够的信息来回答查询。 对于具有多个可能 SQL 翻译的问题，审阅者会根据我们的协议二次检查是否正确选择了 SQL 标注。 最后，审阅者会检查当前数据库中的所有 SQL 标注是否涵盖了所有常见的 SQL 子句。

3.4 问题审阅和改写

在审阅 SQL 标注后，英语母语人士会审阅并纠正每个问题。 他们首先检查问题是否语法正确且自然。 接下来，他们确保问题反映了其对应 SQL 标注的含义。 最后，为了提高问题的多样性，我们要求标注者为一些问题添加改写后的版本。

3.5 最终审阅

最后，我们要求经验最丰富的标注者进行最终的问题和 SQL 审阅。 如果多个审阅者对某些标注问题不确定，则此标注者会做出最终决定。 此外，我们运行一个脚本来执行和解析所有 SQL 标注，以确保它们是正确的。

4 数据集统计和比较

我们在表 1 中总结了 Spider 和其他文本到 SQL 数据集的统计数据。 与其他数据集相比，Spider 包含具有多个表的数据库，并且包含包含许多复杂 SQL 组件的 SQL 查询。 例如，Spider 包含的嵌套查询数量大约是以前文本到 SQL 数据集总和的两倍，ORDER BY (LIMIT) 和 GROUP BY (HAVING) 组件数量是其总和的 10 倍。 Spider 包含 200 个不同的数据库，涵盖 138 个不同的领域，例如大学、俱乐部、电视节目、政府等。 大多数领域只有一个数据库，因此包含 20-50 个问题，而一些领域，如航班信息，有多个数据库，总共包含超过 100 个问题。 平均而言，Spider 中的每个数据库有 27.6 列和 8.8 个外键。 平均问题长度和 SQL 长度分别约为 13 和 21。 我们的任务使用不同的数据库进行训练和测试，评估跨域性能。 因此，Spider 是 唯一一个 文本到 SQL 数据集，它既包含不同领域中具有多个表的数据库，也包含复杂的 SQL 查询。它测试了系统对新 SQL 查询和数据库模式以及新领域的泛化能力。

5 任务定义

在提出的数据集之上，我们定义了一个文本到 SQL 任务，它比以前的工作更现实。 与大多数以前的语义解析或文本到 SQL 任务不同，模型将在我们任务中针对 不同复杂的 SQL 查询和不同领域中不同复杂的数据库 进行测试。 它旨在确保模型只有在真正理解问题的语义含义时才能做出正确的预测，而不是仅仅依靠记忆。 此外，由于我们的数据库包含不同的领域，我们的语料库测试了模型对新数据库的泛化能力。 通过这种方式，模型在该任务上的性能可以反映真实的语义解析能力。

为了使任务可行，并专注于语义解析的更基本部分，我们做出以下假设：

• 在我们当前的任务中，我们不评估模型在生成值方面的性能。 预测正确的 SQL 结构和列在当前阶段更现实，更关键，因为各种当前最先进的模型在我们任务上的性能较低。 在现实世界中，人们需要仔细检查条件值是什么，并在多次操作后将其最终确定。 在不与用户互动的情况下预测条件值是不现实的。 实际上，大多数人知道要问什么值，但不知道 SQL 逻辑。 一个更合理的方法是要求用户使用界面搜索这些值，然后提出更具体的问题。 此外，之前其他关于值预测的工作在训练和测试中使用单个数据库，这使得它容易过度拟合。 但是，SQL 查询必须包含值才能执行。 在我们的任务中，为每个问题提供了一个黄金值的列表以用于值预测。 模型需要将它们填入预测的 SQL 中的正确位置。

• 如前几节所述，我们排除了需要外部知识的某些查询，例如常识推理和数学计算。 例如，想象一个包含出生年份和死亡年份列的表。 为了回答诸如“X 的寿命有多长”之类的問題，我们使用 SELECT death_year - birth_year。 即使这个例子对人类来说很简单，它也需要一些关于寿命定义的常识和数学运算的使用，这不是我们数据集的重点。

• 我们假设数据库中的所有表名和列名都是清晰且自包含的。 例如，一些数据库使用特定于数据库的简短名称来表示表名和列名，例如“stu_id”，我们在语料库中将其手动转换为“student id”。

6 评估指标

我们的评估指标包括组件匹配、精确匹配和执行准确率。 此外，我们根据查询的难度来衡量系统的准确性。 由于我们的任务定义不预测值字符串，因此我们的评估指标不考虑值字符串。

我们将发布官方评估脚本以及我们的语料库，以便研究界可以共享相同的评估平台。

组件匹配

为了对模型性能进行详细分析，我们测量了预测结果和不同 SQL 组件上的地面真实值之间的平均精确匹配。 对于以下每个组件：

• 选择 $\bullet$ 何处 $\bullet$ 分组依据

• ORDER BY  $\bullet$ KEYWORDS （包括所有没有列名和运算符的 SQL 关键字）

我们将预测和地面真实值中的每个组件分解为几个子组件的集合，并检查这两个组件集是否完全匹配。 例如，为了评估每个 SELECT 组件，请考虑 SELECT avg(col1), max(col2), min(col1)，我们首先解析并将其分解为一个集合 (avg, min, col1), (max, col2)，并查看黄金集和预测集是否相同。 以前的工作直接比较解码后的 SQL 与黄金 SQL。 但是，一些 SQL 组件没有顺序约束。 在我们的评估中，我们将每个组件视为一个集合，因此，例如，SELECT avg(col1), min(col1), max(col2) 和 SELECT avg(col1), max(col2), min(col1) 将被视为相同的查询。 为了报告模型在每个组件上的整体性能，我们在精确集合匹配上计算 F1 分数。

精确匹配

我们衡量预测的查询作为一个整体是否等效于黄金查询。 我们首先评估上一节中描述的 SQL 子句。 预测的查询只有在所有组件都正确的情况下才正确。 因为我们在每个子句中进行集合比较，所以这种精确匹配指标可以处理“排序问题” Xu et al. (2017)。

执行准确性

由于当语义解析器能够生成新的语法结构时，精确匹配可能会提供错误的负面评估，因此我们还考虑了执行准确性。 对于执行准确性，该值对于执行 SQL 查询是必须的。 而不是生成这些值，每个问题都给出了一个黄金值列表。 模型需要选择它们并将它们填充到它们预测的 SQL 中的正确位置。 我们在组件和精确匹配评估中排除了值预测，并且在当前版本中不提供执行准确性。 但是，还应注意的是，当预测的 SQL 返回与黄金 SQL 相同的结果（例如，“NULL”）时，而它们在语义上不同时，执行准确性可能会产生错误的正面评估。 所以我们可以用两者来互相补充。

最后，我们的评估还考虑了多个可接受的键，如果 JOIN 和 GROUP 在查询中。 例如，假设一个表中的“stu_id”指的是另一个表中的“stu_id”，GROUP BY 两种情况都可接受。

SQL 难度标准

为了更好地了解模型在不同查询上的性能，我们将 SQL 查询分为 4 个级别：简单、中等、困难、极难。 我们根据 SQL 组件、选择和条件的数量来定义难度，因此包含更多 SQL 关键字（GROUP BY、ORDER BY、INTERSECT、嵌套子查询、列选择和聚合器等）的查询被认为更难。 例如，如果一个查询包含超过两个 SELECT 列、超过两个 WHERE 条件和 GROUP BY 两个列，或者包含 EXCEPT 或嵌套查询，则该查询被认为是困难的。 在此基础上添加更多内容的 SQL 被认为是额外困难的。 图 3 显示了 4 种难度的 SQL 查询示例。

图 3： 4 种难度的 SQL 查询示例。

	Test					Dev
	Easy	Medium	Hard	Extra Hard	All	All
Example Split
Seq2Seq	22.0	7.8	5.5	1.3	9.4	10.3
Seq2Seq+Attention Dong and Lapata (2016)	32.3	15.6	10.3	2.3	15.9	16.0
Seq2Seq+Copying	29.3	13.1	8.8	3.0	14.1	15.3
SQLNet Xu et al. (2017)	34.1	19.6	11.7	3.3	18.3	18.4
TypeSQL Yu et al. (2018)	47.5	38.4	24.1	14.4	33.0	34.4
Database Split
Seq2Seq	11.9	1.9	1.3	0.5	3.7	1.9
Seq2Seq+Attention Dong and Lapata (2016)	14.9	2.5	2.0	1.1	4.8	1.8
Seq2Seq+Copying	15.4	3.4	2.0	1.1	5.3	4.1
SQLNet Xu et al. (2017)	26.2	12.6	6.6	1.3	12.4	10.9
TypeSQL Yu et al. (2018)	19.6	7.6	3.8	0.8	8.2	8.0

表 2： 不同难度级别 SQL 查询的精确匹配准确率。

Method	SELECT	WHERE	GROUP BY	ORDER BY	KEYWORDS
Example Split
Seq2Seq	23.3	4.9	15.3	9.2	17.9
Seq2Seq+Attention	31.1	9.1	28.2	20.8	21.4
Seq2Seq+Copying	28.2	8.3	25.5	21.3	19.0
SQLNet	59.8	32.9	35.9	65.5	76.1
TypeSQL	77.3	52.4	47.0	67.5	78.4
Database Split
Seq2Seq	13.0	1.5	3.3	5.3	8.7
Seq2Seq+Attention	13.6	3.1	3.6	9.9	9.9
Seq2Seq+Copying	12.0	3.1	5.3	5.8	7.3
SQLNet	44.5	19.8	29.5	48.8	64.0
TypeSQL	36.4	16.0	17.2	47.7	66.2

表 3： 测试集上所有 SQL 查询的组件匹配 F1 分数。

7 方法

为了分析难度并展示语料库的目的，我们对几个最先进的语义解析模型进行了实验。 由于我们的数据集与 Geoquery 和 WikiSQL 等先前数据集有根本的不同，因此我们对这些模型进行了如下调整，使其适应我们的任务。 我们通过将数据库中所有表中的列串联在一起，创建了一个“大的”列列表，作为所有模型的输入。 此外，对于每个模型，我们限制了每个问题示例的列选择空间，使其仅包括数据库中该问题所询问的所有列，而不是整个语料库中的所有列名。

序列到序列

受神经机器翻译 Sutskever 等人（2014） 的启发，我们首先应用了一个基本的序列到序列模型，Seq2Seq。 然后，我们还探索了 Dong 和 Lapata（2016） 中的 Seq2Seq+Attention，通过添加一个注意力机制 Bahdanau 等人（2015）。 此外，我们通过添加类似于 Jia 和 Liang (2016) 的基于注意力的复制操作来包含 Seq2Seq+Copying。

原始模型没有考虑模式，因为它在训练和测试中具有相同的模式。 我们修改了模型，使其通过传递一个词汇掩码来考虑表格模式信息，该掩码限制模型仅从当前数据库中的 SQL 关键字、表格和列名称解码单词。

SQL网络

由 Xu 等人 (2017) 引入，使用列注意机制，并采用基于草图的方法，将 SQL 生成作为槽填充任务。 这从根本上避免了在 SQL 查询条件中顺序无关紧要时的序列到序列结构。 因为它最初是为 WikiSQL 设计的，所以我们将它的 SELECT 和 WHERE 模块扩展到 ORDER BY 和 GROUP BY 组件。

类型SQL

由 Yu 等人 (2018) 提出，通过提出不同的训练程序并利用从知识图或表格内容中提取的类型来改进 SQLNet，以帮助模型更好地理解问题中的实体和数字。 在我们的实验中，我们使用了从数据库内容中提取的问题类型信息。 此外，我们将它们的模块也扩展到 ORDER BY 和 GROUP BY 组件。 它是唯一使用数据库内容的模型。

8 实验结果和讨论

我们总结了所有模型在我们测试集上的性能，包括表格 2 中精确匹配的准确率和表格 3 中组件匹配的 F1 分数。

数据分割

对于最终的训练数据集，我们还选择并包含了来自六个现有数据集的 752 个查询和 1659 个问题，这些问题遵循我们的标注协议：餐厅、地理查询、学者、学术、IMDB 和 Yelp。 我们报告了所有模型在两种不同设置下的结果：（1）示例拆分，其中示例被随机拆分为 8659 个训练集、1034 个开发集和 2147 个测试集。 同一个数据库的问题可能出现在训练集和测试集中。 （2）数据库拆分，其中 206 个数据库被拆分为 146 个训练集、20 个开发集和 40 个测试集。 同一个数据库的所有问题都在同一个拆分中。

整体性能

基于 Seq2Seq 的基本模型，包括 Seq2Seq、Seq2Seq+Attention 和 Seq2Seq+Copying，其性能非常低。 然而，由于它们的通用解码过程，它们能够生成嵌套和复杂的查询。 因此，它们可以正确地预测一些困难和极难的例子。 但是，在绝大多数情况下，它们预测的 SQL 查询无效，存在语法错误。 注意力和复制机制也没有太大帮助。

相反，SQLNet 和 TypeSQL 利用 SQL 结构信息来指导 SQL 生成过程，显著优于其他 Seq2Seq 模型。 虽然它们可以生成有效的查询，但它们无法生成嵌套查询或包含 EXCEPT 和 INTERSECT 等关键字的查询，因为它们将可能的 SQL 输出限制在一些固定预定义的 SQL 结构中。

如表 3 中的组件匹配结果所示，所有模型在 WHERE 子句预测方面最困难。 WHERE 子句更有可能包含多个列和操作，这使得它的预测最具挑战性。 每个组件的预测错误最多的部分来自列预测。

总体而言，所有模型的整体性能都很低，表明我们的任务具有挑战性，还有很大的改进空间。

示例拆分与数据库拆分

正如第 5 节中所述，该数据集的另一个挑战是泛化到新的数据库。 为了研究这一点，我们在表 2 和表 3 中比较了两种设置下的模型性能。 对于所有模型，数据库拆分下的性能都远低于示例拆分下的性能。 特别是，TypeSQL 利用列名作为问题类型，并且在示例拆分下，它比其他模型有很大的优势。 然而，它的性能在数据库拆分数据集上下降最多。 这表明该模型在复杂的 SQL 预测方面表现良好，但无法泛化到新的数据库。 此外，我们观察到，所有模型在数据库拆分下的列选择方面，都比示例拆分表现得差得多。

总体而言，结果表明，我们的数据集对模型泛化到新数据库提出了挑战。

图 4: 作为外键数量函数的精确匹配精度。

数据库模式的复杂性

为了展示数据库模式的复杂性如何影响模型性能，图 4 绘制了精确匹配精度作为数据库中外键数量的函数。 随着数据库具有更多外键，性能下降。 第一个原因是，模型必须从复杂数据库模式中的许多候选中选择列名和表名。 第二，复杂的数据库模式对模型来说是一个巨大的挑战，需要捕获具有外键的不同表之间的关系。 在包含更多外键的数据库中，对问题的 SQL 答案更有可能加入更多表。 这表明此任务需要更有效的方法来编码具有外键的表的关联关系。

9 结论

在本文中，我们介绍了 Spider，一个大型、复杂且跨领域的语义解析和文本到 SQL 数据集，该数据集直接有利于 NLP 和 DB 社区。 基于 Spider，我们定义了一个新的具有挑战性和现实性的语义解析任务。 在此任务上对几个最先进的模型的实验结果表明，还有很大的改进空间。

致谢

感谢 Graham Neubig、Tianze Shi、Catherine Finegan-Dollak 和三位匿名审稿人提供讨论和反馈。 我们还感谢 Barry Williams 从 DatabaseAnswers 提供我们部分数据库架构。