文本-SQL转化任务，是将用户的自然语言转化为SQL继而完成数据库查询的工作。
例如根据下表，用户输入一个问题，模型将其转换为 SQL，查询数据库得到结果："-4.52, -9.55"
Query：新浪和人人网的周涨跌幅分别是多少？
SQL：SELECT 周涨跌幅 FROM 表 WHERE 名称=‘新浪’ OR 名称=‘人人网’
原本要辛辛苦苦写SQL，现在我用大白话告诉机器想看的内容，就能从数据库中拿到答案，这就是Text2SQL。
本文将解读Text2SQL领域最新论文，BERT从中学会了如何编写SQL语言。原文发表在EMNLP 2020会议上。
论文题目：
Bridging Textual and Tabular Data for Cross-Domain Text-to-SQL Semantic Parsing
论文链接:
https://arxiv.org/pdf/2012.12627v2.pdf
开源代码：
https://github.com/salesforce/TabularSemanticParsing
想快速获取论文的小伙伴也可以在订阅号【NLP情报局】后台回复关键词【0119】下载。
01 Text2SQL定义
Text2SQL解决的是将自然语言映射到数据库查询语句SQL的问题。论文中将跨领域的text-to-SQL任务定义如下：
给定自然语言问句 和关系型数据库模式 ，模型需要生成对应的SQL查询 。
我们知道，一个数据库中可能包含很多张表，一张表又包含多个字段，所以 ， 。每张表的表名 和字段名 都是文本字符。表中的字段可能有主键、外键，同时字段有不同的数据类型。
表中的单元值包含了真实数据信息，例如前文的“人人网”和“新浪”。
明白了什么是Q和S，我们来思考如何搭建模型。
02 模型架构
论文提出的模型BRIDGE采用了主流的Seq2Seq架构，把Text2SQL视作翻译问题（原序列：text，目标序列：SQL），包含编码器和解码器。
编码器
编码器的目的是对Q和S分别做向量编码，同时对两者之间的关系充分交互。
论文中，作者将Q和S拼接为一个混合的问题-模式序列 ，作为编码器的输入：
每一个表名、字段名分别用字符[T]和[C]分隔。问题Q和S之间用字符[SEP]分隔。最后，在开始位置插入[CLS]字符。
这样的序列既符合BERT的输入格式，从而优雅地编码跨模态信息，又能快速获取任意字段的编码向量（提取[T]/[C]对应特征即可）。
首先输入BERT，随后经过一层双向LSTM获得序列的初始编码表示 。
中的问题片段继续通过一层bi-LSTM获得Q的最终编码 。
Meta-data Features
相比于表名，字段名多了主键、外键等属性。为了利用这些特征（meta-data），论文中用了一层前馈网络对表名、字段名进一步编码。
这里的 分别表示各个字段的主键、外键、类型特征， 表示字段特征。将4个向量横向顺序拼接，经过函数 转化，可以得到每一个字段的最终向量表示。
表名没有额外特征，后三个维度均用零向量替代。各个表名、字段名都进行g函数转化，纵向拼接得到模式的最终编码 。
Bridging
截至目前，仅仅完成了Q和S的各自编码。读者可能会疑惑，交互在哪呢？
为了解决这个问题，作者使用锚文本（anchor text）将问题Q中包含的单元值与数据库字段链接起来。
具体实现上，作者将问题Q中的每一个token，与数据库表中每一列的所有value值进行字符串模糊匹配，匹配上的value值将被插入到序列X中。
如上图所示，问题Q和表格“Properties”、“Reference Property Types”相关联。其中Q包含的两个单词“houses”和“apartments”与两张表中的同名字段“Property type code”有重合单元值。
字段名“Property type code”本身没有在问题Q中出现，让模型直接推理出“houses”、“apartments”和“Property type code”相关，难度很大。
所以作者在 中把和问题有关的单元值人为拼接在相应字段之后，相当于直接告诉BERT哪些问题片段包含引用。
作者把这种方式称为“bridging”，即模型BRIDGE的由来。
解码器
解码器的目的是从编码特征中还原出相应SQL。
相比于前人的工作（RAT-SQL[2]、IRNet[3]等），BRIDGE解码器设计非常简洁，仅使用了一层带多头注意力机制[4]的LSTM指针生成网络。
在每一个step中，解码器从如下动作中选择1种：
1、从词汇表V中选择一个token（SQL关键字）
2、从问题Q中复制一个token
3、从模式S中复制一个组件（字段名、表名、单元值）
从数学定义上分析，在每一个时刻 ，给定解码状态 和编码表示 ，按照[4]中的方式计算多头注意力
是语义子空间总数量， 表示从Q或S中复制相应token加入当前解码结果的权重。
紧接着，作者给出了由V和输出分布产生的概率定义：
是LSTM输出的概率分布， 是长度为 序列，只包含 中的问题单词和特殊标记[T]、[C]（动作2、3）。 表示从V生成的概率（动作1）， 是最终输出分布。
03 数据集与评价指标
作者在WikiSQL、Spider[5]两份数据集上测试了效果。
Spider是耶鲁大学发布的数据集，训练/验证/测试集数据库不重叠，涵盖了几乎所有SQL语法，被公认是难度最大的Text2SQL数据集。
预测评价指标上，作者选择了完全匹配准确率（Exact Set Match）。模型输出SQL的各个子句（select、from、where）需要和标注SQL一一匹配。
04 实验分析
实验部分，作者端到端的训练并测试了模型在Spider上的表现。
模型训练
参数设置部分，作者用交叉熵loss、Adam-SGD优化器、uncased BERT-large训练模型。为确保训练的稳定性，使用了L-inv学习率衰减函数。
最终训练得到的 在Spider测试集上取得了65.0%的准确率，超越了榜单上大部分模型。
集成版本的 （3个模型，在解码的每一个step对输出分布取平均值）将准确率提升至67.5%，获得了榜单第3。
消融实验
为了证明BRIDGE各个子模块的有效性，作者做了消融分析实验。
BERT对于最终表现有至关重要的影响，带来3倍以上的提升效果。
此外，在训练过程中随机打乱db中table顺序（防止过拟合）、引入meta-data、bridging机制都有一定的积极作用。
其中，bridging机制对于Ex-Hard难度的样本有显著的提升效果（9%）。
05 错误分析
误差都去哪了呢？作者用最优的BRIDGE模型，随机选择dev上50条预测错误的样本进行了分析。
有9条样本属于假负样本（False Negative）。原因在于同一句话可以翻译成不同的SQL，E-SM指标不能发现这种差异。
# 例如“oldest age”，可以用两种SQL表示MAX(age) ORDER BY age DESC LIMIT 1
剩余错误中，36%属于逻辑错误。由于模型的泛化能力不足，或没有结合上下文“死记”训练集出现的固定模式，导致在select、where子句等处预测错误。
当输入的文本包含未见过的单词时，模型容易不知所措，不能准确推理这个词在数据库中的含义。作者认为“持续学习“是一种有效的解决方案。
最后，部分文本在推理时需要结合常识才能完成。例如“older than 21”，结合常识才能推理出 而不是 。
06 总结
这篇论文提出了BRIDGE模型，与BERT结合取得了奇效（提升300%）。
作者也在论文中对比、总结了许多前人的工作。应该说这是一篇SQL解析方向非常Robust的paper！
