[论文阅读]Bridging Textual and Tabular Data for Cross-Domain Text-to-SQL Semantic Parsing

论文地址：Findings of EMNLP 2020 https://arxiv.org/abs/2012.12627
代码：BRIDGE

1 Introduction

早期的text2sql任务是在处理单表的问题，然而实际上的数据库是多表、多领域的，早期的方案不能很好的扩展。
针对不同的数据库（DB），近似的自然语言表达生成的 SQL 可能十分不同。因此，跨数据库 text-to-SQL 语义解析器不能仅简单地记住所看到的 SQL 模式，而是必须准确地建模自然语言问题、目标数据库结构以及两者的上下文。
如图中的例子，两个问题问的内容类似，但是生成的sql语句却很不一样。
最先进的跨数据库 text-to-SQL 语义解析器采用以下三个设计原则：

1. question和schema 的表示是互相关联的；
2. BERT等预训练模型可以通过增强对自然语言变化的泛化和捕捉长期依赖关系，显著提高解析准确性；
3. 在数据隐私允许的范围内，利用DB content来帮助理解schema，如上图的第二个例子中，“PLVDB”是name字段的值，但是name这个字段在问题中却没有提到，我们需要设计一个方法来解决这之前的隐藏的依赖关系

本文提出的BRIDGE，它整合了上述三个设计原则。

1. 用 tagged sequence 标记序列 来表示关系型数据库的schema，并把这个序列连接在question的后面。不像之前的工作，提出具体的layers来对db schema联合text-db linking建模，BRIDGE只是对标记序列（不包括question）用bert来表示embedding，然后是两个单层的BILSTM来表示schema。每个模式组件（表或字段）仅使用混合序列中其特殊标记对应的隐藏状态来表示。
2. 为了更好的对齐schema 和question，作者提出了anchor text，这个anchor text是 question中的词和DB单元值做相似度计算（编辑距离），大于某个阈值就认为是相同的词提取出来的，隐式地实现 text-DB 对齐。

通过结合 pointer-generator 解码器和 schema-consistency driven search space pruning（模式一致性驱动的搜索空间修剪），BRIDGE实现了SOTA的表现。
通过深层次的模型比较和错误分析，证明了本文提出的模型对于记住结构化的模型、变化的查询语言泛化能力是有效的，但在组合概括方面存在困难，并且缺乏可解释性。
跨领域的文本到sql仍然提出了许多未解决的挑战，需要模型在训练数据经常稀少的情况下，对自然语言变化和结构组合进行泛化。

2 Model

BRIDGE模型——结合了基于BERT的编码器和顺序 pointer-generator，以执行端到端 cross-DB text-to-SQL 语义解析。

2.1 Problem Definition

给定自然语言问题 Q 和关系型数据库的模式（schema）$\mathcal{S}=⟨\mathcal{T},C⟩$，解析器需要生成相应的 SQL 查询 $Y$。
一个数据库中可能包含很多张表（tables），一张表又包含多个字段（fields），所以 T = { t 1 , … , t N } \mathcal{T}=\left\{t_{1}, \ldots, t_{N}\right\} T={t1​,…,tN​} ， $C=\left\{c_{11},\dots ,c_{1|T_1|},\dots ,c_{n1},\dots ,c_{N|T_N|}\right\}$ 。每张表的表名和字段名都是文本字符。表中的字段可能有主键、外键，同时字段有不同的数据类型。
最新方法表明访问数据库内容可以显着提高系统性能。但为保护隐私，模型仅可以访问每个字段的值集（value set），而不是整个数据库的内容。 把这些 value sets 叫做 picklists。

2.2 Question-Schema Serialization and Encoding

如图，将Q和S拼接为一个混合的问题-模式序列，作为编码器的输入：
$$X=[CLS],Q,[SEP],[T],t1,[C],c11\dots ,c1\mid T1\mid [T],t2,[C],c21,\dots ,[C],cN|TN|,[SEP]X=[CLS],Q,[SEP],[T],t1,[C],c11\dots ,c1\mid T1\mid [T],t2,[C],c21,\dots ,[C],cN|TN|,[SEP]$$
每个表名前面都有特殊标记[T]，每个字段名前面都有[C]。

• $X$首先输入BERT，随后经过一层Bi-LSTM获得序列的初始编码表示 $h_X$ 。
• $h_X$ 中的问题片段继续通过一层Bi-LSTM获得Q的最终编码 $h_Q$
• 每个表/字段使用对应于其特殊标记 [T] / [C] 的 $h_X$ 切片表示。

Meta-data Features:相比于表名，字段名多了主键、外键等属性。为了利用这些特征（meta-data），论文中用了一层前馈网络（ $g\left({\mathbb{R}}^{4n}\to {\mathbb{R}}^n\right)$) 对表名、字段名进一步编码。

• 表名：没有额外特征，后三个维度均用零向量替代。
• 字段名：这里的 $f_{pri},f_{for},f_{type}$ 分别表示各个字段的主键、外键、类型特征， ${\mathbf{h}}_{\mathrm{X}}^q$ 表示字段特征。将4个向量横向顺序拼接。
• 各个表名、字段名都进行 g 函数转化，纵向拼接得到模式（schema）的最终编码 。

2.3 Bridging

仅对表名/字段名及其关系进行建模并不足以捕捉模式（schema）的语义及其与Question的依赖关系，即缺少 Q 和 S 的交互。

• 解决方法：使用锚文本（anchor text）将问题 Q 中提及的值（value mentions）与数据库字段（DB fields）链接起来。锚文本为BERT提供了其他词汇线索，来标识Q中的相应提及（mentions）。
• 具体实现：将问题 Q 中的每一个 token，与数据库表中每一列的所有 value 值进行字符串模糊匹配，匹配上的 value 值将被插入到序列 X 中（在相应的字段名称之后，并由特殊标记[V]分隔）。
  
• 例如：
  如图，问题 Q 和表格“Properties”、“Reference Property Types”相关联。其中 Q 包含的两个单词“houses”和“apartments”与两张表中的同名字段“Property type code”有重合单元值。字段名“Property type code”本身没有在问题Q中出现，若让模型直接推理出“houses”、“apartments”和“Property type code”相关，难度很大。

2.4 Decoder

解码器的目的是从编码特征中还原出相应SQL。

相比于前人的工作（RAT-SQL、IRNet等），BRIDGE解码器设计非常简洁，仅使用了一层带多头注意力机制的 LSTM pointer-generator 网络。

在每一个step中，解码器从如下动作中选择1种：

1. 从词汇表 V 中选择一个token（SQL关键字）
2. 从问题 Q 中复制一个token
3. 从模式 S 中复制一个组件（字段名、表名、单元值）

从数学定义上分析，在每一个时刻$t$，给定解码状态 $s_t$ 和编码表示
$\left[{\mathbf{h}}_Q;{\mathbf{h}}_S\right]\in {\mathbb{R}}^{(|Q|+|S|)\times n}$ ，按照以下公式计算多头注意力：
${\alpha }_{tj}^{(h)}$ 表示从 Q 或 S 中复制相应 token 加入当前解码结果的权重。
解码由 $V$ 产生（即上述解码器动作1）的概率和总的输出分布为：
其中， $P_{\mathcal{V}}\left(y_t\right)$ 是 softmax LSTM 的输出分布， ${\tilde{X}}_j$ 是长度为 ($|Q|+|\mathcal{S}|$) 的序列，其只包含 $X$ 中的 question words 和特殊标记[T]、[C]。

2.5 Schema-Consistency Guided Decoding

基于每个 SQL 子句中出现的 DB 字段必须仅来自 FROM 子句中的表，提出了一种简单的序列解码器剪枝策略。

按执行顺序生成SQL子句（Generating SQL Clauses in Execution Order）：将训练集中每个 SQL 查询的子句重新排列为表 1 所示的标准 DB 执行顺序。例如，SELECT COUNT(*) FROM Properties 转换为 FROM Properties SELECT COUNT(*)。

在执行顺序中包含子句的所有SQL查询都满足以下引理:

引理1：假设$Y_{exec}$是一个SQL查询，其中的子句按照执行顺序排列，那么$Y_{exec}$中的任何表字段都必须出现在表之后。

采用二元注意力掩码：${\tilde{\alpha }}_t^{(H)}={\alpha }_t^{(H)}\cdot \xi$ ，$\xi$ 初始值设为维度和字段数目相同的0向量，一旦表$t_i$被解码，$\xi$ 中对应于 $c_{i1},\dots ,c_{i|T_i|}$ 的元素置为1。这允许解码器仅在由引理1中的条件指定的空间中搜索，而解码速度的开销很小。

3 实验

3.1 评估指标

精确集合匹配（Exact Set Match (E-SM) ）：通过检查预测查询中每个SQL子句的无序集合匹配情况来评估预测SQL的结构正确性。它忽略了预测值中的误差。

执行准确度（Execution Accuracy (EA) ）：检查预测的SQL是否可在目标数据库上执行，以及执行结果是否与实际结果相匹配。这是一个性能上限，因为具有不同语义的两个SQL查询可以在一个数据库上执行相同的结果。

3.2 Implementation Details

锚文本选择（Anchor Text Selection）

给定一个数据库DB，使用官方数据库文件计算每个字段的值集pickist。设计了一种模糊匹配算法来将问题与数据库中可能提及的值进行匹配。

将问题和字段值转换为小写字符序列，并使用启发式确定的匹配边界计算最长的子序列匹配。

例如，问句“how many students keep cats as pets?”与单元值“cat”($s_c$​)匹配，匹配的子字符串为“cat”($s_m$​)。从question中$s_m$​的开始和结束字符索引 i、j 开始进一步搜索，以确保可以在 i-2 到 j + 2 内检测到单词边界，否则匹配无效。这不包括作为问题词子字符串的匹配项，例如“cat” 与“category”。将问题中匹配的全词短语表示为$s_q$，将问题匹配分数和单元格匹配分数定义为：

${\beta }_q=|s_m|/|s_q|$，${\beta }_c=|s_c|/|s_q|$。

每个字段最多包含 k 个匹配项，并通过更长的匹配项来打破平局。我们排除所有数字匹配，因为问题中提到的数字通常不对应于 DB 单元（例如“低于 50 美元的鞋子”）或无法有效区分不同字段。

4 Discussion

锚文本选择（Anchor Selection）

BRIDGE采用简单的字符串匹配来选择锚文本，提高锚文本选择的准确性可以显著提高端到端准确性。

将锚文本匹配扩展到简单字符串匹配之外的情况(例如" LA “→” Los Angeles ")是未来的方向。

目前BRIDGE忽略提到的数字。可以引入一些特征，表明问题中属于特定列的值范围内的特定数字。

输入大小

由于BRIDGE使用特殊的标记将所有输入序列化为一个序列，对于大型关系数据库来说，输入太长了。可以通过transformers最新改进框架解决，这些改进已经扩大了注意力机制来建模非常长的序列。

关系编码

BRIDGE将DB schema元数据特性融合到每个表字段表示中。这种机制不如直接建模原始图结构强大，规范化特定的注意头来捕获DB连接是一种很有前途的方法，可以在BRIDGE框架内对关系数据库的图结构建模，而无需引入(大量)额外参数。

5 Conclusion

提出了 BRIDGE，这是一种强大的顺序架构，用于在跨数据库语义解析中对自然语言问题和关系数据库之间的依赖关系进行建模。

1. BRIDGE 将问题和 DB 模式序列化为标记序列，并最大限度地利用预训练的 LM（例如 BERT）来捕获提及的文本和 DB 模式组件之间的链接；
2. 使用锚文本来进一步改善两个跨数据库输入之间的对齐；
3. 结合简单的顺序指针生成器解码器和模式一致性驱动的搜索空间修剪。

后续计划：

1. 进一步改进模型的组合泛化（compositional generalization）和可解释性。
2. 研究BRIDGE的扩展应用，这些任务需要结合文本和表格的理解，如弱监督的语义分析和事实检查。