Press "Enter" to skip to content

Facebook大公开:解决NLG模型落地难题!工业界的新一波春天?

本站内容均来自兴趣收集,如不慎侵害的您的相关权益,请留言告知,我们将尽快删除.谢谢.

文 | 小喂老师

 

编 | 小轶

 

作为NLP领域的“三高”用户(高产、高能、高钞),FaceBook最近(2020年11月)又发表了一篇高水准文章,目前已被COLING-2020接收,号称解决了自然语言生成(NLG)落地的问题: Best Practices for Data-Efficient Modeling in NLG:How to Train Production-Ready  Neural Models with Less Data

 

看到这个有点标题党的文章,我不禁要发出关于NLG落地的素质三连:

众所周知,对于自然语言处理中的NLG问题,一直都没有很好的落地场景,即便是目前最合适的“文本自动摘要-Auto Text Summarization”,也没有特别合适的产品和落地领域。所以虽说你是大佬,但我也不觉得你可以做第一个吃螃蟹的人!

 

抱着这些疑惑,我一口气读完了整个paper,然后不禁发出感慨:“ 就这? ”——啊不,打错了——然后不禁发出感慨:“四高一”!!!

 

本篇文章的亮点比较多,属于一篇偏实验性论文,总结为一句话就是: 流程化NLG在对话系统落地过程中开发步骤和评估策略 。

 

文中研究的NLG主要指 对话系统中的NLG 。为解决 NLG应用落地 的难题,论文设计了一套Tree-Based数据集,并据此推出 Bucketing训练策略 + TreeAccuracy评价策略 。此外,还讨论了NLG中的 数据增强 , 知识蒸馏 , 生成模型选择 和 Data-fficiency 问题。为对话系统中的NLG落地给出了一套 完备&Less-Data&Low-Latency&生成结果High-Acceptable的方案 。

 

哈哈,这幺高的评价,那我们看一下这篇文章到底做了啥!

 

论文题目:

 

Best Practices for Data-Efficient Modeling in NLG:How to Train Production-Ready Neural Models with Less Data

 

论文链接:

 

https://arxiv.org/abs/2011.03877

 

Arxiv访问慢的小伙伴也可以在 【 夕小瑶的卖萌屋 】订阅号后台回复关键词 【 1221 】 下载论文PDF~

 

NLG先验知识

 

在谈论这篇论文之前,我先和大家的沟通一下NLG这个任务,保证大家有一个共通的认知观点。

 

自然语言生成(Natural Language Generation)是一个很难或者说高复杂度的自然语言处理任务。广义的NLG是给定一个输入(可以是文本、表格、图片或是结构化的数据),输出符合该输入的一段文本描述(可以是文章写作、摘要,也可是图片内容描述)。NLG通常被认为是真正意义上的人工智能,一个完备的NLG任务意味着图灵机的实现。本论文的NLG是特指对话系统(Chatbot System)中的自然语言生成,对于一个对话系统,它通常有如下几个部分:

 

自动语音识别-ASR

 

自然语言理解-NLU

 

对话策略-DM

 

自然语言生成-NLG

 

对于此处的NLG任务,它的输入是< Query , DM产生的Actions >,输出的是一段文本回复。

 

因为是一篇偏实验性的论文,所以论文的要点理解和模型框架并不算特别的难,但是需要大量的先验知识储备。接下来的四个小节中,我将依次列举一些必要的先验知识,包括:

 

Chabot System中的NLG

 

Structured NLG Data

 

Bucketing策略

 

BART模型

 

Chabot System中的NLG

 

在对话系统中,经过NLU,DM之后会获得一系列的 Dialogue Actions ,这类Dialogue Actions就是NLG的重要输入。在Chabot System中做NLG,常用的方法是基于模板生成结果。但是太过于死板且不可迁移。后来就提出了基于Encoder-Decoder的模型生成,和模板生成进行比较,也是有各自的优劣点(具体讨论可见论文细节)。

 

这里为了能让读者有一个对NLG任务比较直观的理解,给出了一个简单的例子(其中Query和Actions通常作为NLG的输入,ExpectResponse则指代模型NLG的输出):

 

Query: "我要买一张明天去北京的火车票。"
Actions: {
"intent":"买火车票",
"slots":["destination":北京,
        "departure":UNK,
        "time":DayTime[“明天”]_DetailTime["UNK]]
"actions":["询问具体时间","询问出发地点"]
"ExpectResponse":"请问您想买【明天】【几点】的火车票?【出发地点】又是哪里呢?"
}

 

Structured NLG Data

 

如果使用Encoder-Decoder的生成模型来做NLG,那幺不可避免地就引入了模型输出结果不可控制的问题。在生成的模型中,可能缺少重要的要素,也可能要素值生成错误,这些都是生成模型中不可控制的。

 

作者所在的团队在2019年的一篇论文中( Constrained decoding for neural NLG from compositional representations in task-oriented dialogue ),给出了一种解决方法: 它将输入的action使用tree-structured的方式进行存储。这样的结构引入了更多的信息,也便于后面对生成结果进行判定 。本文实际上也算是Facebook在以前工作上的一种再创新。

 

为了便于读者理解,这里给出了论文中一个关于tree-structured input的数据。这是Facebook发布的Dialogue System中的一个case。他将Actions结构化。Reference指期望给出的NLG输出。

 

Query: "Do I have any reminder to buy milk?"
Structured Actions: 
    INFORM 1[amount[ 3 ]]
    INFORM 2[todo[ buy milk ] date time[time[ 7 pm ]]]
    INFORM 3[todo[ buy milk ] date time[colloquial[ tomorrow ]]]
    INFORM 4[amount remaining[1]]
Reference: Yes, there are 3 reminders. The first two are, buy milk at 7 PM and tomorrow. There’s 1 other reminder.

 

Bucketing策略

 

这种策略方式使用比较少,在机器学习中有使用过(我也是咨询了一位同事之后,才了解和理解的)。

 

在深度学习中,我们通常随机选取一批数据进行模型的训练。如batch_size = 64,选取64个随机数据进行训练。Bucketing则是一种 按照某种【策略】将数据分成一个个的bucket(桶),然后将一个个的Bucket的数据丢入到模型中进行训练 。这样的训练方法可以减少在模型训练过程中由imbanlanced distribution带来的bias,也能提高数据的利用率,是常用的一种利用“少量数据”训练模型的方法。

 

在Bucketing的过程中,这种【策略】就非常的重要。好的策略能大大提高数据利用率,坏的策略通常不比随机好,甚至会误导模型的学习。设置Bucket策略的出发点是: 各个bucket中的数据中,不一样的信息是希望模型能够学习的信息,一样的(共有的)信息是模型可以忽略的信息 。

 

在本论文的任务上,因为数据是tree-structured的数据,作者这里数据的 tree-structured degree 和 argument values ,尝试了多种方法进行Bucketing,都取得了比random好的效果。

 

BART模型

 

BERT模型我听过,BART模型又是啥??是不是写错了? BART是FaceBook AI团队在2019年发布的一款适用于生成的预训练语言模型 。

▲BERT、GPT、BART模型框架比较

如果说BERT适合做NLU,GPT框架适合做NLG。那如果我二者取其长,是不是就能更好的做NLP任务了?这个想法很简单也很正常,但你发不了paper,因为你没钱去训练这样的模型,但人家FaceBook有,所以人家FaceBook发了Paper(手动狗头)。模型框架很简单,但是非常有效,出来即刷新榜单,目前在NLP任务中,同量级的模型上仍有多处属于SOTA。

 

BART模型在HuggingFace的Transformers上开源了自己的预训练模型。笔者在今年8月份使用过BART模型进行过文本摘要生成。对于英文的生成来说,效果确实非常好,基本不用fine-tune也能比较好的生成通顺的有意义的文本;但是对于中文,因为没有Bart-zh,所以无法直接测试。不过FaceBook开放了25种语言的mBART,可用来做中文的文本生成,但直接生成的效果不好,语句通顺都成问题,还未尝试过fine-tune。不过从当前他人的使用评价和论文的结果来看,BART是一个很适合文本生成的预训练模型。

 

Paper Body

 

在介绍文章主体之前,我们再梳理一下文章说到的几个要点知识。确保这几个知识点你都能接受和掌握,我们再来看文章细节。

 

NLG任务是给定输入的(dialog act,user query),生成语句通顺,信息正确的回答。

 

传统NLG系统大多使用基于模板的文本生成(template-based text generation),有优有劣。

 

新的基于神经网络的NLG(neural-network-based language generation),其框架中主要步骤包括:

 

 

对于输入进行meaning representation(MR);

 

使用sequence-to-sequence(S2S)框架,产生对应的response。

 

 

因为本论文要探讨的是NLG产品化落地,所以我们期望探索 不同数据量下模型精度结果的情况 。即,在 Data-Reduction 的情况下,如何提高 Data-Efficiency 。

 

因为是要探讨NLG的产品化落地,所以也期望做一下 模型压缩 在NLG方面的探索。

 

在上面的几点理解后,我们从以下4个方面来看这篇论文:

 

训练数据

 

Bucketing策略

 

评估方法

 

模型

 

四种训练数据

 

数据这里使用的是Facebook团队2019年给出的四个对话系统相关的数据,数据的存储格式都是tree-structured的,数据的领域分别是:Weather, Reminder, Time, Alarm。数据的样例格式如上面给出。

 

四种数据处于不同难度级别,其中Weather最难,Alarm最简单。论文作者认为,这四个领域的数据能基本代表Task-oriented Dialogue System上NLG的难度水平,也基本满足NLG任务的任务需求(虽然笔者我不这幺认为,读者也不一定这幺认为:joy:)。

 

三种Bucketing策略

 

这里作者根据数据tree-structured的结构特色,使用了三种Bucketing策略,分别是:

 

Coarse grained(CB): 使用data中argument names进行Bucket group

 

Medium grained(MB): 精细到使用data中sub-arguments进行Bucket group,对于词语的形态进行归一化

 

Fine grained buckets(FB&FBQ): 更精细化的操作,包括对argument-value去语义化,甚至对query进行去语义化 (FBQ)

▲Bucketing 策略示例

一个完整的训练集使用不同的Bucketing策略,将会被分割成不同数量的buckets。越精细的Bucketing策略,被划分的buckets数量就越多。比如Weather的训练数据集使用CB:MB:FB划分得到的buckets数量分别是2240:6406:15456. 如上图是一个case以及其各种bucket策略的例子表述。

 

实验结果证明,无论哪种Bucketing策略,效果都优于random。其实可以预料得到,因为一个正确的bucket策略相当于引入了先验知识,让模型更能按照正确的方向进行优化学习。所以同等训练量和模型容纳能力的情况下,模型效果会更优。

 

三种评估方法

 

说到NLG问题,就一定绕不开NLG产生结果的评估。因为是自然语言生成的结果,和标准结果之间不能简单的用“==”来判断结果是否正确,因为会存在语义相同,表述不同的结果;也不能使用简单的Rouge-L来评判,因为如果在关键词(如数字,是否)上表述错误,是不可原谅的。所以NLG的结果评判也一直是一个问题。当然,可以引入人为评测,但是如果每一个NLG都使用认为评测,那幺成本将非常的高昂。这里作者所使用的3种评测方法是:

 

Tree Accuracy: 因为数据本身是tree-structured数据,所以非常方便的检测生成文本的重要token是否是MR中的token,如果是记为1,否或者缺失记为0;

 

BLEU: 2002年提出,是NLG中通用的一种结果检测方法。此处不做细述。

 

人工评测:有钱土豪用人工,土豪FaceBook没道理不用。这里论文从Correctness和Grammaticality两个方面对生成文本进行测评。

 

三种模型方法和结果

 

在原论文中最后给了7种模型策略,但我只列举了三种,因为其它都是在该三种方法上的排列组合。

 

S2S:使用Sequence-to-Sequence框架,用LSTM做encoder和decoder,输入的embedding使用的是glove的embedding。优点是轻量级,小。

 

BART:基于BART的模型框架进行Encoder-Decoder的模型训练,在BART的基础上进行fine-tune。

 

KD(Knowledge Distillation,知识蒸馏):使用BART的模型太大了,不利于模型的线上使用,需要使用知识蒸馏的做法。这里KD指的是将BART蒸馏到S2S模型中。

 

此外,作者还提到了JT和DDA。这不算模型,算是两种通用的增强模型效果的方法:

 

Joint-Training(JT): 将多个相近领域的数据一起训练。

 

Dynamic Data Augmentation (DDA):对于不同的Epoch,随机替换每个argument value。这样即便使用一批数据进行训练,每个Epoch的数据都不一样,增大数据可用性。个人认为:由于此任务数据的固有特点,才得以使用该方法进行数据增强,算是合理利用数据特色进行数据增强的一种方法。

 

最终输出的7种模型分别的输出结果如下:

 

图中横坐标是训练数据量,纵坐标是精度。最后作者认为: S2S+KD 和 S2S+KD+DDA取得了最好的效果 。

 

当然, 全文的重点是NLG的Data Efficiency,所以会实验各种数据量之下的模型结果 ,DDA策略无疑Data Efficiency最佳。而KD效果最差,但KD主要是为了工程应用而生,毕竟KD之后的S2S模型只有2M。

 

能达到这样的结果,确实振奋人心。用几句话总结论文的结论,那就是: 我们的Bucketing策略很好,我们的DDA很好,我们的TreeAccuracy很好,我们的KD很好。

 

此外,论文还分别给出了在四个Domian上的3种测评结果以及人工测评结果,最后给出结论:我们提出的Tree Accuracy还是很有代表性的;我们使用的S2S+KD+DDA是很有效果的,在四个Domain上通用。

 

论文结论

 

文章的结论我打算整体翻译一下,因为确实是提纲挈领,很有概括性(英文好的建议读原文,原文截图我保留在下面):

 

在训练task-oriented对话系统时,不仅要考虑模型的精度,还需要考虑模型的 数据利用率 以及可接受性(acceptability),响应延迟和所需的开发维护成本。为此,我们提出一个NLG开发流程:

 

根据数据中的结构(此处为基于树)对meaning representation进行Bucketing采样,以避免不必要和不平衡的数据采集,每个bucket收集1-3个case。训练模型并进行评估。

 

如果有任务和语义相似的多个domain数据,可以先进行 联合训练 ,然后进行domain内微调。训练模型并进行评估。

 

实施 动态数据增强(DDA) ,以减少响应对“可互换参数值”的依赖。与增强数据一起训练,并评估模型性能。

 

首先,使用预训练的模型(例如BART)为未标记数据生成响应,得到增强数据。然后,用增强数据和人工标记的数据,训练一个小模型(KD)。最后,用人工标记数据,进一步微调该模型。评估模型性能。

 

如有必要,请为每个MR存储桶收集更多示例,并从头开始部署模型。

▲论文结论

我的理解

 

关于论文

 

论文本身是一个偏实验性的论文,所以阅读时需要注重理解论文设计的原因。因为是做对话系统中的NLG,而且是基于该组2019年发表的数据集进行训练,其格式化的数据格式,引入了本文中两个非常大的亮点: Bucketing策略 和 DDA方法 。注意,这两种方法都是需要在Tree-based数据上进行实现的。此外,模型使用的BART模型和KD方法,都属于比较通用的方法,创新性属于锦上添花。

 

当然,论文期望知道 NLG落地对数据的需求(Data Reduction)、可能的数据增强方法(DDA)、模型压缩(S2S+KD)能达到的精度和应用领域的差异影响 的结果是什幺,并为此设计了一系列实验,也给出了相应的结论。

 

关于NLG

 

如开头所说的,一个完备的NLG意味着真正图灵机的实现,也意味着真正人工智能时代的到来。目前各大顶级公司都在走这样的路,包括目前很多论文都是将大量的NLP任务转化为语义理解的任务,如:机器阅读理解代替NER,QA方式代替信息抽取,模型生成代替文本分类。例如T5模型将各类NLP任务转化为一个通用任务模型,例如GPT-3的finetune用普通的自然语言描述代替。NLG目前不属于一个很好的可以工业落地和应用的领域,但是自然语言学者们却一直在探索NLG的任务。

 

一直说NLG的回答有很多的不可控性,本论文给出了一种Tree Accuracy的方法来评测模型生成的结果,确实从一定程度上衡量了模型输出结果的准确性,算是为NLG的落地提供了一些方向( 在格式化文本输出的落地上提供可能 )。但是这种情况其实是假设我们已经获取到了输出所需的槽位值,而非真正意义上的从文本中去理解,然后获取相关关系,再产出合理化的回复。所以本文对于通用意义上的NLG有参考意义,但对于问题的解决还是有很长的路要走!路漫漫其修远兮!

Be First to Comment

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注