一起养成写作习惯！这是我参与「掘金日新计划 · 4 月更文挑战」的第18天，点击查看活动详情。

前言

本文为我之前在CSDN平台上的一篇博客记录。原链接为：blog.csdn.net/u011426236/…

导语

• 论文地址：arxiv.org/abs/2012.12…
• 会议：EMNLP 2020

摘要

本文提出了BRIDGE，它是一个强大的序列架构，用于在跨数据库语义解析中建模自然语言问题和关系数据库之间的依赖关系。BRIDGE以标记序列的方式表示问题和DB模式，其中一些字段使用问题中提到的具体值进行扩展。混合序列由BERT编码， 且后续层最少。文本-数据库的上下文关系通过一个在BERT中微调的深度注意力机制实现。结合具有指针生成网络的译码器，通过schema-consistency 驱动的搜索空间剪枝，BRIDGE在流行的跨数据库Text-to-SQL benchmark的Spider和WikiSQL上获得了最先进的性能。分析表明，BRIDGE有效地捕获了所需的跨模态依赖性，并具有推广到更多文本db相关任务的潜力。代码实现可以在github.com/ salesforce/TabularSemanticParsing上找到。

1 简介

Text-to-SQL是将人类的自然语言语句翻译成SQL语句的任务。其形式化定义如下：给定一个自然语言问题$Q$和数据库模式$S=<T,C>$，我们希望得到其对应的SQL语句$Y$。

Text-to-SQL任务的挑战性在于模型需要从一个在一个没有见过的关系型数据库中根据数据库模式（schema）将自然语言问句使用SQL语句正确表达。如图一所示：

图中用户问的两个问题都是想要计数，但是由于数据库的模式不同，导致目标SQL语句差异很大。

目前最先进的一些方法一般都遵循以下三个原则：

1. 使用Question和Schema联合进行上下文编码
2. 使用预训练语言模型
3. 利用数据库中的内容（即数据库中的具体值）

本文介绍一个新的模型BRIDGE，其将关系数据库的schema表示为拼接到question之后的标记序列。同时，将问题中提到的具体值追加到具体字段之后，并使用BERT对拼接后的序列进行编码表示。解码器则直接使用一个指针生成网络解码器。

2 模型

2.1 问题定义

给定一个自然语言问题$Q$和数据库模式$S=<T,C>$，我们希望得到其对应的SQL语句$Y$。其中，数据库模型包括表名$T=\{t_1,t_2,\cdots\}$和列名$C=\{c_{11},\cdots,c_{1|T_1|},\cdots,c_{n1},\cdots,c_{N|T_{N}|}\}$。其中某些列名之间存在主键-外键关系。同时，每个列有一个数据类型$\tau\in\{number,text,time,boolean\}$。

此外，本文设定我们可以“部分”获取数据库内容，比如我们可以知道一个列包含的所有值（称为picklist）是什么，而不知道具体是哪个id对应这个值（这样设计是为了尽可能保护数据库用户隐私）。

2.2 Question-Schema Serialization and Encoding

本文将问题和数据库schema按如下方式进行序列化： 在每个表名之前加入一个特殊的token [T]代表整个表的信息，在每个列名前加入一个特殊的token [C]代表整个列的信息。并使用[SEP]将Question和Schema进行分隔。然后将该序列送入BERT进行编码。 如上图所示，$X$编码后即经过一层双向LSTM获得序列的初始编码表示$h_X$。然后问题部分经过另一个Bi-LSTM后得到问题部分的最终表示$h_Q$。

而数据库schema部分则需要考虑一些额外的meta-feature：

1. 是否是主键$f_{pri}$
2. 是否是外键$f_{for}$
3. 该列的数据类型$f_{type}$

利用上述特征，借助一个前馈网络g进一步进行编码： 就得到了最终编码$h_S$。

2.3 Bridging

这里是论文的一个重要创新点。由图2我们可以看到，Property_Type_Code这个列名其实并没有在Question中提到，但是这一列的值（即picklist）中包含Question中提到的“House”、“Apartment”。如果只让模型自己推断它们是Property_Type_Code这个列中的值的话有些困难。因此，这里作者使用了一种模糊搜索的方法，对问题中提到的值在数据库中进行模糊搜索，将其可能在哪些列中出现的信息添加到编码中。

本文将这些在问题中出现的数据库的值称为anchor text。如图2所示，Question中出现的“House”、“Apartment”在数据库的Property表的Property_Type_Code这个列和Reference Property Types表的Property_Type_Code这个列中有出现。因而将它们添加到相应的列的后面。并使用特殊token [V]作为前导符。

2.4 解码

与之前很多工作复杂的解码流程不同，本文所述模型只采用了一个简单的基于LSTM的指针生成网络作为Decoder。在每一个时间步，解码器只会执行以下三种操作之一：

1. 从词汇表$V$（即SQL关键词表）中生成一个token
2. 从问题$Q$中复制一个token
3. 从数据库模式$S$中复制一个token

同时，作者使用了多头注意力机制（不熟悉的可以参考：NLP学习笔记（八）注意力机制（Attention））。计算同时如下： 这样，最后的输出分布即：

2.5 Schema-Consistency Guided Decoding

由于SQL语法的约束性，且一个数据库表名只有FROM子句出现后才会出现。所以作者修改了SQL语句各部分的顺序以便于模型的学习和生成。作者证明了这种修改可以一一映射回原SQL语句。

3 相关工作

略

4 实验设置

4.1 数据集

本文在WikiSQL和Spider上进行了实验。其数据集统计值如下：

4.2 评价指标

采用Exact Match(EM)、Exact Set Match(E-SM)、Execution Accuracy(EA)三种评价指标。其中EM多用于WikiSQL、E-SM多用于Spider、EA是二者皆会使用。

4.3 实现细节

略

5 结果

5.1 端到端的表现评估

5.1.1 Spider

下表展示了Spider数据集上各个方法的表现：

表4展示了各个难度上的表现：

5.1.2 WikiSQL

下图展示了各个方法在WikiSQL上的表现：

5.2 Ablation Study

本文进行了消融实验，以验证各个部分的作用。首先是Spider数据集上， 可以看到BERT对实验结果的好坏至关重要，其次Bridging主要对非常困难的SQL语句提升比较大。

在WikiSQL上的消融实验如下：

5.3 误差分析

5.3.1 手动评估

作者人为手动评估了50条错误数据，其错误类型分布如图：

5.3.2 定性分析

一些错误示例如下，主要包含四方面的内容：逻辑错误、单词理解错误、需要借助常识、模型的健壮性不够。

6 总结

本文提出了BRIDGE，一个强大的序列架构，用于在跨数据库语义解析中建模自然语言问题和关系数据库之间的依赖关系。BRIDGE将问题和DB模式序列化为一个带有标记的序列，并最大限度地利用预先训练过的语言模型(如BERT)来捕获文本提及和DB模式组件之间的链接。它使用anchor text进一步改善两个跨模态输入之间的对齐。结合简单的顺序指针生成网络解码器和模式一致性驱动的搜索空间修剪，BRIDGE在广泛使用的Spider和WikiSQL文本到sql基准测试中获得了最先进的性能。

分析表明，BRIDGE在概括自然语言变化和记忆结构模式方面是有效的。它实现了WikiSQL上的上界评分，在Spider的简单类别中显著优于以前的工作。然而，它在复合泛化方面表现不佳，有时还会出现无法解释的错误。这表明，当数据充足且目标逻辑形式较浅时，序列到序列模型是跨数据库语义解析的好选择，特别是考虑到实现更容易且解码有效。为了解决一般的Text-to-SQL的问题并向生产部署转移，我们计划进一步提高模型的组合泛化和可解释性。我们还计划研究BRIDGE的应用及其扩展到其他需要联合文本和表格理解的任务，如弱监督语义解析和事实检查。

附录

A.1 Examples of SQL queries with clauses arranged in execution order

修改顺序后的SQL语句示例：

A.2 Selective read decoder extension

即CopyNet，略

A.3 Anchor text selection

首先将问题和值全部小写化，然后使用一些启发式算法进行模糊搜索匹配。过程略，详见原文。

A.4 Performance by number of attention heads

Head的数量对实验结果的影响：

A.5 The Linear-inverse-square-root (L-inv) learning rate decay function

文中提到的学习率变化函数。略

A.6 Ensemble Modeling

BRIDGE在Spider数据集上的性能对随机种子很敏感。作者训练了10个不同的BRIDGE模型，只是随机种子有所不同。图A1显示了每个单独模型的性能(按递减的E-SM排序)，以及使用平均步长概率集成的top-k模型。 个体模型的性能变化确实很大。最佳模型和最差模型在E-SM上的误差分别为3.4绝对点和2.2绝对点。考虑到假阴性，真实模型的性能可以有较小的方差。

表A4显示了Spider开发集中的最佳(70.2%)和最差(66.7%)模型在错误重叠方面的比较。对于61%的开发集，两个模型都预测了正确的答案，24.4%的开发集，两个模型都犯了错误。在8.9%的例子中，只有最佳模型是正确的，而在5.5%的例子中，最差模型是正确的。手工检查表明，大多数两个模型评估不同的例子在语义上确实是不同的。

A.7 Performance by Database

在Spider上验证集上数据库的各自表现：

A.8 Visualizing fine-turned BERT attention of BRIDGE

原图太大，参见原文

A.9 Future Improvements

略