论文笔记:PICARD: Parsing Incrementally for Constrained Auto-Regressive Decoding from Language Models

39 篇文章 4 订阅
15 篇文章 12 订阅

论文笔记:PICARD: Parsing Incrementally for Constrained Auto-Regressive Decoding from Language Models

导语

  • 会议:EMNLP 2021
  • 地址:https://arxiv.org/abs/2109.05093

摘要

文本数据的大型预训练语言模型具有不受约束的输出空间;在每个解码步骤中,它们可以产生数万个token中的任何一个。当对SQL等受约束的形式语言进行Fine-tune时,这些模型通常会生成无效代码,使其不可用。本文提出了PICARD模型,一种通过增量解析约束语言模型的自回归解码器的方法。PICARD通过在每个解码步骤拒绝不可接受的token输出来帮助找到有效的输出序列。在具有挑战性的Spider和CoSQL数据集的Text-to-SQL任务中,本文展示了PICARD将性能尚可的T5模型转换为最先进的解决方案。

1 简介

虽然在将预先训练好的大型语言模型应用于下游任务方面已经取得了许多成功,但我们控制和限制这些模型输出的能力仍然非常有限。许多企业应用程序都无法实现,因为它们所需的语言模型还无法提供的严格程度和准确性。如果目标是一种形式化的语言,如SQL,那么我们希望模型能够精确且可证明地遵守SQL规范及其所有的词法、语法、逻辑和语义约束。不幸的是,仅靠预先训练,语言模型可能无法满足这些正确性要求。

对于Text-to-SQL翻译任务,最普遍的解决方式是约束解码过程,过滤掉无效的SQL语句。现在可以将自回归解码限制为仅能正确解析为SQL抽象语法树的token序列。最近,有人提出了对这种解析范式的半自回归改进。然而,尽管这些方法很有效,但它们有一个共同点,即实现它们的代价是使用特殊控制令牌的自定义词汇表或自定义模型体系结构,或两者都使用。不幸的是,这使得它们与一般的预训练语言模型解码器不兼容。一种侵入性更小、更兼容的方法是不限制生成过程,而是根据有效性过滤最终确定的波束假设。然而,这种过滤是以非常大的beam size为代价的。

我们使用了一种新的用于约束解码的增量解析方法PICARD(Parsing Incrementally for Constrained Auto-Regressive Decoding)来解决这些方法的开销问题。PICARD与任何现有的自回归语言模型解码器和词汇(包括但不限于那些预先训练好的大型Transformer)兼容,而且它不需要非常大的波束大小。PICARD完全不存在于模型的预训练或微调中,它可以在推理时轻松且可选地启用。PICARD直接操作语言模型的输出,即Text-to-SQL任务中生成的SQL语句。
在这里插入图片描述

在我们的实验中,我们发现PICARD在对Text-to-SQL任务进行微调后,可以显著提高大型预训练语言模型的性能。在Spider数据集上,我们发现带有PICARD的T5-Base模型优于没有PICARD的T5-Large模型,T5-Large和T5-3B模型也是如此。值得注意的是,在PICARD的帮助下,T5-3B模型在Spider和CoSQL数据集上的性能可以提高到最先进的水平。

2 PICARD方法

PICARD将模型预测分数与现有的贪婪算法和波束搜索算法简单地结合在一起,用于语言模型的自回归解码。它的参数是当前翻译输出的token id和对于每个词汇表里的token,模型的语言建模头预测的log-softmax分数。PICARD还可以访问SQL schema的信息,特别是关于表和列的名称以及关于哪个列包含在哪个表中的信息。在每一个生成步骤中,PICARD首先将预测限制在最高k个概率token上,然后给那些没有通过PICARD大量检查的token一个 − ∞ -\infty 的分数(参见图2)。
在这里插入图片描述
这些检查是由基于一元组合的快速增量解析所实现的。PICARD有四种设置来控制其全面性:off (不检查)、 lexing(词法检查)、 parsing without guards(无保护的解析), and parsing with guards(有保护的解析,即最高模式)。通过较高模式的预测将始终通过较低模式,但相反则不一定。

2.1 Lexing

在词法分析模式下,PICARD只在词法级别上检查输出。它试图将部分的、detokenize后的模型输出转换为由空格分隔的单个SQL关键字(如select)、标点(如()、操作符(如+和-)、字面值(如SQL条件中的字符串和数字值)以及标识符(如别名、表、和列,而对这些词汇项出现的顺序不敏感。通过这样做,PICARD可以检测关键字中的拼写错误,或者拒绝对给定SQL模式无效的表和列名。例如,考虑以下问题(来自于Spider的验证集中的dog_kernnels数据库):

"What are the email, cell phone and home phone of each professional?"

我们的Fine-tune后的T5-Large模型预测输出为

select email_address, cell_phone, home_phone from professionals

而实际上ground truth是选择 “cell_number” ,而不是无效的 “cell_phone” 列。在词法分析模式下,PICARD可以捕获并避免这一错误。

2.2 Parsing without Guards

在Lexing模式之上最低的解析模式(即Parsing without Guards)中,PICARD在语法级别检查输出。PICARD试图将detokenize后的模型输出解析为表示SQL查询的抽象语法树(AST)的数据结构。与词法分析模式相反,关键字和子句出现的顺序现在很重要。PICARD可以拒绝无效的查询结构,例如查找 from 子句中的缺失或子句和关键字的错误顺序。它还可以检测SQL表达式组合的一系列问题:首先,如果PICARD匹配到了一个 tid.cid (注:tid即table_id,cid即column_id)的模式,但是实际上 tid 这个table里并没有 cid 这个column,那么该条输出将被拒绝。其次,如果PICARD首先配到了一个 alias.cid (alias即别名,即我们经常在SQL语句中使用的 FROM table_name as T1 …… )的模式,然后匹配到了一个 tid as alias 的模式,但实际上 tid 这个table里并没有 cid 这个column,那么该条输出也将被拒绝。对于绑定到表别名的子查询,也存在一个等价的规则。最后,PICARD禁止在相同选择范围内重复绑定表别名,但允许隐藏在周围范围内定义的别名。这可能发生在嵌套SQL查询中。

2.3 Parsing with Guards

在最高的解析模式中,PICARD在组装SQL的AST时进行额外的分析,称为Guards。如果PICARD匹配到 tid.cid 或者 alias.cid ,然后Guards需要 tid 或 alias 必须在from子句中出现。而且,而且,alias被限制为解析到其中包含cid列的表或子查询。如果PICARD匹配cid模式,那么另一个Guards要求最终将恰好包含具有该id的列的一个表引入作用域。这些Guards被急切地执行,以便在尽可能早的时间将无效的输出快速失效,逐出beam。Guards在解析from子句之后才开始执行。

只有有了这些保护,PICARD才能拒绝我们Fine-tune的T5-Large模型的错误预测:
假设问题是:

What are the makers and models?

模型的错误预测为:

select maker, model from car_makers

在这里,正确的表应该是model_list,因为它是Spider的car_1数据库中唯一一个既包含maker列又包含model列的表。

还可以进行其他检查和保护,例如,检查只比较相同类型的表达式,或者union, except, intersect的列类型是否匹配。我们把这些额外的检查留给将来的工作。

3 实验

我们的实验主要集中在Spider,一个用于文本到sql解析的大型多域和跨数据库数据集。我们对Spider训练集中的7000个例子进行训练,并对Spider开发集及其隐藏测试集进行评估。我们还报告了CoSQL的结果,这是一个基于sql的对话状态跟踪任务。其中,我们预测在交互上下文中给出的每个问题的SQL查询。对于这个任务,我们在Spider文本到sql训练数据和CoSQL对话框状态跟踪训练数据上进行训练,并在CoSQL开发和测试集上进行评估。

Spider和CoSQL都是zero-shot设置。在各自的训练、开发和测试集之间的问题或数据库之间没有重叠。

在Spider上,我们基于三个指标确定模型性能:exact-set-match accuracy(下称EM)、execution accuracy(下称EX)和test-suite execution accuracy(下称TEX)。EM通过将预测的SQL查询和ground-truth的SQL查询解析为规范化的数据结构来进行比较。这种比较对文字查询值不敏感,假如语义相同的SQL查询重写(即同样的逻辑,但是使用不同的表达方式)会使得该指标降低。EX比较在Spider数据集附带的数据库内容上执行预测的和实际的SQL查询的结果。该指标对文字查询值很敏感,但存在较高的假阳性率。最后,TEX将每个SQL模式的执行扩展到多个数据库实例。这些实例的内容经过优化,以减少误报的数量,并提供语义准确性的最佳近似。

在CoSQL中,我们通过question match accuracy(下称QM) 和 interaction match accuracy(下称IM)来衡量模型性能。这两个指标都基于EM。IM是交互中所有问题的联合精度。

我们收到Shaw et al.(2021)结果的启发,它的工作显示了一个预训练好的 T5-Base或T5-3B模型不仅可以学习Text-to-SQL任务,还可以泛化到没见过的数据库,结果甚至可以与当时最强的模型表现不分上下。而所有这些都没有对模型进行修改。因此,我们使用T5作为我们所有实验的baseline。

为了对未知的数据库进行泛化,我们将数据库模式与问题一起编码。我们使用的序列化方案与Shaw等人(2021)使用的相同。在使用数据库内容的实验中,我们以类似于Lin等人(2020)的BRIDGE模型的方式检测并将数据库值附加到列名上(详细可参考我的另一篇笔记:论文笔记:Bridging Textual and Tabular Data for Cross-Domain Text-to-SQL Semantic Parsing)。在对CoSQL对话框状态跟踪任务进行Fine-tune时,我们将交互中前面的问题按反时间顺序添加到输入中。超过T5模型的512 token 长度限制的输入将被截断。训练的目标是来自Spider和CoSQL训练集的SQL,除了将关键字和标识符转换为小写外,未进行修改。我们使用Adafactor对T5进行了多达3072个epoch的Fine-tune,batch_size大小为2048,学习率为1e-4。

在这里插入图片描述

结果 表1和图1总结了我们在Spider数据集上的发现。我们复现的Shaw et al.(2021)的T5的结果已经无法和当前最先进的模型(即LGESQL模型,参考论文笔记:LGESQL: Line Graph Enhanced Text-to-SQL Model with Mixed Local and Non-Local Relations)相比较。原因在于是这些模型预测了大量无效的SQL。例如,在Spider的开发集中,T5-3B模型生成的SQL查询有12%会导致执行错误。然而,当这些相同的模型被PICARD增强,我们发现实质性的改进。首先,无效的SQL预测变得很少见。对于使用PICARD的T5-3B,只有2%的预测是无效的。在这些情况下,没有找到有效的SQL预测就退出了beam search。其次,也是最重要的,通过使用PICARD, T5-3B模型提升到最先进的性能。我们测量的EM在开发集上为75.5%,在测试集上为71.9%。EX结果分别为79.3%和75.1%。这些数字与最接近的竞争对手LGESQL + ELECTRA持平或更高(见表1)。此外,我们在Spider的开发集上实现了71.9%的TEX。

在这里插入图片描述
我们对CoSQL对话状态跟踪数据集(见表2)的发现与Spider的发现相似。PICARD显著提高了性能,我们的微调T5-3B模型达到了最先进的性能。

在这里插入图片描述
PICARD不仅提高了性能,而且速度也很快。在Spider上对T5-3B模型进行评估时,beam size大小为4在NVIDIA A100-SXM4-40GB GPU上时的解码速度,无PICARD时平均为2.5秒/样本,有PICARD时平均为3.1秒/样本。

Beam Size 图1显示了在不使用PICARD和使用PICARD的Spider上对不同波束大小和T5大小进行解析时的结果。对于每个模型的beam size,PICARD都随着beam size的增加而提高性能。从beam size1到2这一步,这些增加是最强的,从2到4不太明显,然后饱和的beam size超过4。即使使用贪婪搜索(波束大小1),PICARD也允许一些适度的改进。注意,如果没有PICARD,这些模型就不能从波束搜索中受益。PICARD在每个解码步骤中处理的最高概率令牌的数量k对性能的影响不大,甚至可以忽略不计。T5-Base最大,T5-Large较小,T5-3B几乎检测不到。我们不研究k = 1的情况,因为它将beam search简化为约束贪婪搜索。

Ablations 在图3中,我们浓缩了PICARD的消融分析。我们展示了T5-Large模型在所有四种PICARD检查模式下的结果,以及Spider开发集上四种不同beam size的结果。当对每个解码步骤进行增量检查时,词法分析显示出比无约束的T5模型有一个小改进。无PICARD和lexing模式下的结果在很大程度上与beam size无关。当PICARD切换到更复杂的解析模式时,情况就不同了。无论是使用Guards还是不使用Guards,PICARD对性能的改进都在随beam size的增加而快速增加,其中使用Guards的解析显然比没有保护的解析具有更强的优势。

为了将PICARD与Suhr等人(2020)和Lin等人(2020)的效度过滤方法进行比较,我们还研究了当模型用序列末端token预测假设终结时,PICARD只检查假设时会发生什么在这种约束模式下,PICARD仍然是有效的,但比正常的增量操作要少得多。只有当beam sizze较大时,这两种操作模式之间的差距才开始缩小。这是可以理解的,因为Lin等人(2020)使用的beam size至少为16,最多为64,以达到滤波的最佳结果,而Suhr等人(2020)使用的波束大小为100。

4 结论

我们提出并评估了一种新的方法,PICARD,简单和有效的约束解码与大型预训练语言模型。在Spider跨域、跨数据库文本到SQL数据集和CoSQL基于SQL的对话状态跟踪数据集上,我们发现PICARD解码方法不仅显著提高了经过Fine-tune的T5模型的性能,而且还提高了未修改的T5模型的性能。它还提升了一个T5-3B模型,以建立的精确匹配(EM)和执行精度(EX)指标的最先进的结果。

  • 6
    点赞
  • 3
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
使用GATK的combinegvcf模块合并gvcf文件,可是到了这一步Using GATK jar /stor9000/apps/users/NWSUAF/2022050434/biosoft/gatk4.3/gatk-4.3.0.0/gatk-package-4.3.0.0-local.jar Running: java -Dsamjdk.use_async_io_read_samtools=false -Dsamjdk.use_async_io_write_samtools=true -Dsamjdk.use_async_io_write_tribble=false -Dsamjdk.compression_level=2 -jar /stor9000/apps/users/NWSUAF/2022050434/biosoft/gatk4.3/gatk-4.3.0.0/gatk-package-4.3.0.0-local.jar CombineGVCFs -R /stor9000/apps/users/NWSUAF/2008115251/genomes/ARS-UCD1.2_Btau5.0.1Y.fa --variant /stor9000/apps/users/NWSUAF/2020055419/home/xncattle/03.GVCF/01_out_GVCF/XN_22/1_XN_22.g.vcf.gz --variant /stor9000/apps/users/NWSUAF/2020055419/home/xncattle/03.GVCF/01_out_GVCF/XN_18/1_XN_18.g.vcf.gz -O /stor9000/apps/users/NWSUAF/2022050469/candy/bwa/gatk/Combine/chr1.g.vcf.gz 09:10:40.524 INFO NativeLibraryLoader - Loading libgkl_compression.so from jar:file:/stor9000/apps/users/NWSUAF/2022050434/biosoft/gatk4.3/gatk-4.3.0.0/gatk-package-4.3.0.0-local.jar!/com/intel/gkl/native/libgkl_compression.so 09:10:50.696 INFO CombineGVCFs - ------------------------------------------------------------ 09:10:50.697 INFO CombineGVCFs - The Genome Analysis Toolkit (GATK) v4.3.0.0 09:10:50.697 INFO CombineGVCFs - For support and documentation go to https://software.broadinstitute.org/gatk/ 09:10:50.698 INFO CombineGVCFs - Executing as 2022050469@node54 on Linux v3.10.0-1127.el7.x86_64 amd64 09:10:50.698 INFO CombineGVCFs - Java runtime: Java HotSpot(TM) 64-Bit Server VM v1.8.0_72-b15 09:10:50.698 INFO CombineGVCFs - Start Date/Time: July 21, 2023 9:10:40 AM CST 09:10:50.698 INFO CombineGVCFs - ------------------------------------------------------------ 09:10:50.698 INFO CombineGVCFs - ------------------------------------------------------------ 09:10:50.698 INFO CombineGVCFs - HTSJDK Version: 3.0.1 09:10:50.699 INFO CombineGVCFs - Picard Version: 2.27.5 09:10:50.699 INFO CombineGVCFs - Built for Spark Version: 2.4.5 09:10:50.699 INFO CombineGVCFs - HTSJDK Defaults.COMPRESSION_LEVEL : 2 09:10:50.699 INFO CombineGVCFs - HTSJDK Defa就停止了,没有输出文件,也没有报错文件
07-22
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值