分享嘉宾：张超 OPPO 高级NLP算法工程师

编辑整理：王旭 北明软件

出品平台：DataFunTalk

导读： 今天分享的主题是小布助手在生成式聊天方面的探索和实践。主要内容包括以下几个方面：

  • 研发背景
  • 业界生成式方案
  • 小布助手业务实践
  • 总结与展望

01 研究背景

首先和大家介绍下小布助手的研发背景

1. 小布助手业务简介

① 小布助手是谁

小布助手是OPPO智能手机和IoT设备上内置的AI助手，主要包括语音、建议、指令、识屏和扫一扫5大功能模块。截至2021年8月，小布助手覆盖用户数达2.5亿，月活跃用户逾1.3亿，月交互次数超20亿次。

② 小布聊天技能

小布聊天技能作为小布助手数百个技能里面第一大技能，提供有趣、有温度、智能的聊天体验，具备智趣单轮、技能引导、话题多轮、情绪感知等基础能力。

  • 智趣单轮 ：提供很多有意思的单轮语料，包含了很多紧跟时代潮流的热梗；
  • 技能引导 ：根据用户的query去判断他当时所处场景，智能推荐一些有趣的技能，比如用户说我好无聊，就会问他，要不要我给你讲个笑话，他说好的，然后直接就给他讲笑话；
  • 话题多轮 ：针对线上比较高频的一些多轮话题而构建，比如说我想蹦迪，然后我们说你准备好了吗？他说好了，此时我们就已经知道他是说他已经准备好去蹦迪，接着我们就会告诉他你是整个舞池最靓的仔；
  • 情绪感知 ：在与用户交互的整个过程中，持续感知用户的情感状态，通过语料或表情与用户进行一些情感上的共鸣。比如用户说我失恋了，我们就会给他一些安慰的话和表情。

2. 小布聊天建设历程

按照建设的时间顺序，我们的聊天算法演进经历了：检索式聊天，规则式聊天，生成式聊天。

  • 检索式聊天

刚开始采用的是检索式聊天，主要解决一些头部query应答问题，解答一些小布人设相关的问题，结果相对安全可控，可以通过语料的增减快速上线。

  • 规则式聊天

规则式聊天主要解决检索式聊天中一些解决不了的问题，它有一定的规律，但是又不可穷举，比如说我叫什么名字这种问题，因为名字不可穷举，通过写语料的方式是写不完的。我们就针对这一类问题去做一些规则，在做规则应答的时候，识别用户query里面的槽位并根据槽位生成一些比较定制化的语料。通过这种规则应答也是比较安全可控的。但是当规则的数量大了之后，它的维护成本还是很高的。

  • 生成式聊天

最后我们建设的是生成式聊天，主要解决长尾query的应答。它应答的范围比较广，但最大的问题就是生成的内容不可控，容易产生一些安全性的问题，针对这一问题我们也做了一些优化。

3. 小布生成式聊天背景

我们为什么要做生成式聊天？因为小布助手的聊天场景是开放多轮的，传统的检索式问答很难满足这种应用场景。

从开放域来说，用户会跟我们无话不聊，从感情到蹦迪到动画片，到节假日到数字货币等等。如果通过写手去写这种语料，成本是非常高的。

另外，用户在跟我们聊天过程中期望我们有多轮聊天的能力。如果通过检索式方案去做，就需要有一些上下文理解能力，我们要去构建一个多轮语料库，成本相当高，跟单轮相比是一个指数级增长。而且这种上下文理解和指代消解的任务本身也是很难的，在中文领域，这种任务训练数据又非常的少，所以做起来是非常困难的。

谷歌的Meena和Facebook的Bleeder，这些大规模端到端的神经会话模型让我们看到了生成式端到端模型的发展空间，在这种开放多轮的场景中将有很好的应用前景。基于此，我们进行了一些探索和实践。

02 业界生成式方案

接下来介绍我们调研的一些业界常用方案。

1. 生成式建模与挑战

生成式建模方案基于语言模型来建模，根据context上文以及前面的预测结果持续地预测下一个word的生成结果，直到生成一个答案。

语言模型的建模注重的是上下文是否符合语言逻辑，表述是否通顺，但对其他方面可能欠考虑，比如上下文是否一致，生成的答案有没有安全性问题，对常识的理解，还有一些情感化共鸣等等。

2. 生成式模型介绍

下面介绍一下业界常用的一些生成式模型。

① RNN-based seq2seq

最基础的端到端生成式模型RNN-based seq2seq模型，发表于2014年。初期，该模型主要应用在翻译领域，后来在很多文本生成任务中得到了应用，包括生成式聊天。

该模型包含两个模块：encoder和decoder。encoder对context通过RNN-based模型去做编码表征，然后在decoder的时候使用context表征以及上一个预测结果去预测下一个word结果，是一个持续的过程。在解码过程中，每一个word所采用的context是一样的，不会动态变化，这样生成的效果并不好。

2015年提出了Seq2Seq+Attention的模型结构。这个模型结构除了encoder和decoder部分之外，还增加了attention模块。在当前时刻，该模块会计算上一个时刻的状态和context状态，对context里状态加权，融合到状态表征里，预测下一个word的概率分布情况。这种结构更好地利用了context的信息，也取得了更好的效果。在很长一段的时间内，Seq2Seq+Attention都是业界主流的方案。

② tensor2tensor

直到2017年，谷歌发表文章《Attention is all you need》，提出了tensor2tensor框架。

该框架的不同点在于encoder和decoder不再使用RNN-based模型，而是使用self-attention方式进行建模表征。

encoder使用双向语言模型建模，使用全“1”的self-attention mask。decoder使用单向语言模型建模，使用下三角矩阵的self-attention mask。

解码时，计算decoder与encoder之间cross attention权值，使用encode最后一层表示。

在业务实践当中，通常encode的层数设置比较少，decode层数设置比较多，decode层数增加效果较好。

Google Menna和Facebook的Blender均基于这种模型的结构来进行优化。

③ GPT模型

2018年，OpenAI提出GPT模型。该模型跟前面的tensor2tensor不一样的是，它只采用了tensor2tensor的decoder部分，使用单向语言模型建模。每次预测时，使用当前词的表征去预测下一个word的概率分布。

GPT最大的改进是采用预训练任务，通过对模型预训练，使模型学到很多通用知识，进而大幅度提升生成的效果。

OpenAI也发表了很多GPT系列的模型，比如说GPT2、GPT3，均是基于这种模型去建模优化。

④ Unilm模型

2019年，微软提出Unilm模型，该模型跟GPT一样采用tensor2tensor的decoder部分，不一样的地方是它的context部分，采用双向语言模型建模，使用全“1”mask。response部分采用单向的语言模型，使用下三角mask。同样也是基于当前词最终状态去预测下一个词。和GPT不同的是，它使用单向或者双向的预训练任务，因此训练效果也比较好。百度的plato系列是基于这种模型结构进行优化。

⑤ 模型对比

上图是对几种模型的对比。

3. 生成式decode方案介绍

① search

search通常有两种方案：greedy search和beam search。

  • greedy search ，这是最简单的方法。它是局部最优算法。每一步search的时候，都是选当前概率最大的值作为最终输出结果，这样很容易陷入局部最优。另一方面，在实践当中我们发现，它生成的答案往往都是通用无意义的，比如说像“好的”、“没有”等等这种无意义的答案。还有就是生成的结果很容易前后答案重复，体验不佳。
  • beam search ，这是一种近似全局最优的算法。它每一步解码的时候，保存一个top-k值，即它的beam size，这个值是可设的。到最终也会输出top结果，可以根据一定的策略去进行优选，或者直接选择最大的路线。在实践的过程中，我们发现beam内答案多样性也不够，同样容易生成一些通用无意义和前后重复的答案。当然业界也有很多优化方案，比如beam分组，还有不同维度的惩罚等等。这里就不展开介绍了。

② sampling

另一种业界常用的是sampling decode方案。sampling就是采样，常用采样方法有两种：top-k采样和top-p采样。

  • top-k采样 ，是对最终概率值做降序排列，从top k结果里随机采样，采到的就是最终使用结果。top-k采样方法，其随机性较强，生成的答案多样性比较好。但有时候也会出现不太好的case。比如说像上图中top-k部分第二幅图的情况，前面几个概率值都特别大，top-k里面可能会存在一些概率值很低的字，如果采样采到了这些字，可能生成的结果并不理想，存在不通顺等情况。
  • top-p采样 ，在一定程度上能够缓解上述问题。top-p算法与top-k一样，首先会对每个字生成概率做降序排列，去计算累计概率，设定一个累计概率门线，对在门线内的词进行随机采样，然后把采样结果当做最终的结果。通过这种算法，其生成的多样性比较好，随机性也强，生成的答案一般也都比较通顺。虽然也会存在低概率被采样到的情况，但相对来说会少一些。

4. 生成式答案选择方案介绍

前面介绍如何去采样生成结果，下面介绍对生成的多个结果怎么排序。

① RCE rank算法

业界最简单的排序算法就是RCE rank的算法，即response和context的相关性预测。做预测最简单的方法是去训练一个分类任务，通过不同的context和response去判断是否相关。为了提升效果，也可以在response里面加入MLM任务。训练的时候通过同时训练两个任务提升整个模型效果。前面讲到一些采样不佳的case，通过这种排序可以很有效的把它们过滤掉，从而保证最终采样到的结果都是比较合理的。

② MMI rank算法

第二种使用比较多的是MMI rank算法。生成式的任务是通过一个context去生成一个response，每个response有一个生成概率。MMI算法是反向来做，训练的时候用response去生成context，在排序的时候有多个response，context固定之后用多个response去生成context，然后去计算能够生成的概率。最后排序的时候，使用前项跟后项的这两个概率做一个连立，作为最终排序的依据。

通过这种方法，可以有效地降低那些通用无意义的query的得分。

5. 生成式聊天评估方案

目前生成式评估分为两种方案：人工评估和自动化评估。

① 人工评估

迭代效率比较慢，对于模型迭代来说不利，但是它可能跟我们真实的体验效果比较一致。现在业界对于生成式的评估没有一个统一的标准，每个公司会提出一些自己的想法。

比如谷歌提的SSA就是回复的合理性，回复内容是否是万能答案，对两者做平均。facebook也有自己一套方案，都是通过人，一种是让一个人同时跟两个chatbot的去聊，判断哪个更好；第二种是让两个chatbot自己聊，人去判断哪个更好。在中文领域，百度也提了一种评估方案，包含四个方面评估，回答的内容是否跟上下文相关，是否包含一定的信息量，内容的新颖性，还有回复内容跟正常人说话是否相似。

② 自动化评估

在生成式任务里面有各种各样的指标，但是这种自动化指标跟我们真实的用户体验之间是有一定gap的。所以在自动化指标里面评估的效果比较好，在真实体验的时候并不一定就会好。

03 小布助手业务实践

下面来介绍一下小布助手的业务实践。

1. 整体方案与流程

① 小布聊天整体应答流程

当query出现之后，首先我们会去判断这是否是首轮的query。

如果是首轮的query，我们会优先用检索去应答。如果检索没有生成答案的话，我们就用规则去应答。如果规则没有答案，我们就会用生成式应答。

如果不是首轮的query，我们就会去判断它是不是上下文相关的。如果上下文不相关的话，我们认为它还是一个独立的query，那么我们还是像首轮的query一样处理。如果它是上下文相关的，那么我们优先会用生成式去答，如果生成式有结果，就直接返回，如果没有结果就进行兜底。这主要是因为生成式在建模的时候是考虑了这种上下文的理解能力的。

② 小布生成式聊天流程

一个query过来，首先会做一个query的安全检测，安全检测通过之后，就会去做生成式模型，然后结合一些解码策略去生成答案。答案生成后，我们就会去答案做选择，选择排序之后对答案做一个QA的安全检测，确保我们生成的答案是安全可靠的。

2. 模型设计与优化

① 模型选型

模型选型参考的是百度plato two的模型方案，使用了两阶段式的训练。

  • 第一阶段1V1训练

在训练生成式任务的时候，相同的context会有多个response。因为同样说一句话，别人去答的时候可能有多种多样的回答方法。但是对于模型来说，我们给一个context然后生成多个不一样的response，模型学习起来是困难的。就相当于一个query有多个标签。为了降低学习的复杂度，我们首先1V1训练，对相同context的多个答案进行随机抽取，抽取出一个答案来进行训练，这样的话就降低了整个学习的难度。整个模型的选型用的是Unilm的模型结构，使用bert-base对这个模型来进行初始化，并且引入了一些预训练的知识。

  • 第二阶段1VN训练

使用全量的语料来进行训练。针对前面一对多的情况做了一个处理，首先会把context、response和隐状态同时输入到双向的语言模型里面来，然后利用这个隐状态来做一个分类，相当于去判断response跟context它们到底属于哪个类别的回复。在预测的时候使用不同的latent，根据context去生成，在相同的context的情况下，就可以合理地去生成不同的response。这样做还有一个好处，就是在预测的时候，隐状态是可以人为输入的，不同的输入可以生成更多种答案，可以很好地提高生成的多样性。Latent的状态个数也可以根据我们语料的情况去设置。

② 模型输入

模型输入除了普通的token embedding之外，我们加了一个context mask，主要去提示哪一部分是单向的语言模型，哪一部分是双向的语言模型。还有一个role embedding去提示当前query是哪个人物说的。目前支持两个角色的对话。Context支持的最大长度是128，支持的最大的对话轮数是10轮。

③ 训练配置

上图是我们模型训练的一些配置。

④ decode方案

在decode方面，我们使用的是sampling rank的方法，采样的方法用的是top-p的算法。

beam search中，一个query可以search出多个answer。采样的时候，都是一个query能采样一个结果。为了同时生成多个结果，我们会把相同的query组装成一个batch，同时输入进去做预测。query batch越大，生成的答案可能就越多，多样性就越好。

但是batch大了之后整体性能就会有很大问题，所以我们设置batch size为10，最大生成长度15。

采样的时候，在随机性放的比较大的时候，可能会采到一些不太好的结果，因此我们可以将一些query的随机性设少一点，一些随机性设大一点，这样哪怕采样采到一些不太好的结果，仍有随机性小的那些答案来保底，确保有一个合适的结果，兼顾生成结果的多样性与可靠性。

⑤ 答案选择方案

在答案选择方面，我们使用的是RCE算法，bert-base的模型。第一阶段生成式模型来对模型做初始化，训练时使用MLM任务。正样本基本上都使用的是生成式的训练语料，负样本有的是随机采样，有的是一些规则生成的。

在答案选择方面，除了纯模型的打分，我们还引入了很多别的变量进来。比如本来query生成不同的response，会有一个生成的概率，这也是我们一个参考因素。我们还会做一些规则去做冲突检测，如果当前query跟上文有明确的冲突，我们就把它的分值给降低。我们也会去对判断query是不是有意义的，如果无意义也会把它分值降低。除此之外，我们还会去做对query本身以及跟上下文的重复检测，把这个结果也纳入到我们最终的排序里面来。这就是我们最终的排序的结果分数的计算方法。

⑥ query安全检测

我们在安全方面也做了很多的工作。一个query要进入到生成式模型，会经过三个漏斗的步骤，第一步会做一个系统级的安全检测，然后闲聊业务会对query再做一个安全检测，包括一些关键词、长度或者一些特殊字符等等。最后还设置了一个安全模型，来提高敏感query的召回率。

我们做了一个线上的统计，线上query从源头到能够过生成式模型，通过率大概是85%。

query的安全检测模型，最开始是用我们的线上的日志去训练了一个bert-base的模型。为了提升效率，我们又用bert-base去蒸馏了一个四层的bert，在线上用T4卡一次预测大概是三毫秒。使用query检测模型，相对于从策略去检测的话，识别准确率提升了7%，召回率也有12%的明显提升。

⑦ query-answer安全检测

有的query本身是不敏感的，但query和answer组合起来不太好。针对这种情况，我们基于bert-base来建模。这个模型相对于前面纯query检测来说难度更大一些，为了保证效果，这里我们就用了一个bert-base的模型，没有再去做蒸馏。

通过使用这种QA检测模型，线上敏感query下降了7.8%。

3. 应答安全方案

除了以上策略和模型方面的工作，我们在安全方面还对训练数据做了一些处理。首先我们对原始的训练数据进行安全识别，对于不合理的数据，我们考虑两种策略，一种是直接移除，另外一种是通过一些万能回复或者引导回复来进行替换，最终让模型看到的数据都是安全的干净的数据，这样就可以在很大程度上避免模型去生成一些不太合适的query。

4. 性能分析与优化

① 性能优化

基于预训练的生成式任务，还有一个很大的挑战，就是性能问题。生成式任务是一个自回归任务，需要一个字一个字地去生成，所以它调用模型的次数是非常大的。针对性能优化，我们也做了一些工作：

  • 动态batch ：前面讲过为了去使用sample rank的方法，我们会做一个batch去输入，在一个batch去预测的时候，我们发现有的已经生成完了，再让它继续输入进去做预测，其实已经没有意义了。所以我们动态地把这些已经生成完了的去掉，在预测的过程中batch size不断地减少，这样就能达到性能优化的结果。
  • 用onnx runtime的方式来进行模型的预测 ：首先我们从一个check point固化到Pb，然后转到onnx，用onnx去做加速。使用onnx进行加速后，单次预测耗时下降了20%。我们还尝试使用FP16去进行加速，但是生成的结果不太符合预期。

② 性能分析

生成式为了去提高预测的性能，往往都会去做一个cache机制。在做某一次预测的时候，预测完了之后我们会把这一次预测的一些中间结果保存起来，而在下一次预测的时候，只需要把上一次预测出来的结果当成输入去获得它的一个embedding，然后通过这个embedding和上一步存的中间结果进行交互的计算，直接来计算下一个预测的概率，就可以避免很多重复计算。当然，在第一次预测时没有cache，这样预测耗时相对会长一些，后面基本上就比较稳定了。

我们用我们的模型在T4卡上也做了一些测试。batch_size=10，seq_len=10的时候，第一次预测大概是15毫秒，后面每一次预测大概是9毫秒。整个生成式模型全链路算下来，也就是query安全检测 + 第1次预测 + 第N次预测 * (max_len - 1) + QA安全检测，计算下来大概是152毫秒左右。

5. 效果分析与展示

① 效果评估

我们对训练的模型做了效果评估，包括两个方面：

  • 自动化评估 ：使用selfchat的方式来进行评估，就是让两个自己去聊，然后我们去采他们的对话数据来进行评估。评估的自动化指标是多样性。上图（左）可以看到我们和业界其他一些方案的对比。
  • 人工评估 ：让三方评测团队对我们进行盲评，使用了5000多条线上的query。评估的标准主要包含安全性、相关性、丰富性和通顺性。打分的话，不合适是0分，还可以是0.5分，达到预期的是1分。小布助手得分为0的情况远远少于标杆产品，得分0.5和1的远超标杆产品，最后综合满意度接近85%。

② 效果展示

接下来展示一下我们生成式的效果。

从上图可以看出，内容生成的相关性是非常好的。结合我们线上的业务，我们也做了一些专门的优化，有时候线上的业务可能会存在有一些模糊意图，像是帮我打，我们针对这种模糊意图构建了很多的引导澄清的answer，然后通过使用