zoukankan      html  css  js  c++  java
  • 第七章 人工智能,7.3 深度学习与自然语言处理在智能语音客服中的应用(作者: 余慈)

    7.3 深度学习与自然语言处理在智能语音客服中的应用

    1. 前言

    95188电话的支付宝热线目前已经用纯语音交互流程全面代替了传统的按键流程,这个我们称之为“蚁人”的智能语音客服会根据用户的描述判断用户的意图,从而为不同需求的用户提供快速的直达服务,或者直接推送自助解决方案,或者发现是属于紧急问题而直接转给对应业务线的人工客服处理。智能语音客服流程目前日均处理话务占整体话务数的91%,覆盖上百类业务线以及上千类问题,以超过70%的问题识别准确率日均成功为客服分流话务上万通,极大节省了客服人力资源,缩短话务高峰期的用户等待时间,提升了用户体验。在双11当天蚁人处理超过20万通电话,为双11业务提供强有力的支持。

    2. 系统概要

    蚁人流程的交互如下:

    1. 用户拨打95188,按1进支付宝
    2. 系统会提示用户用一句话描述所遇到的问题
    3. 用户在电话里描述他(她)想要解决的问题,比如支付宝密码忘记了等
    4. 系统会把用户语音输入转成文本,然后调用问题识别模块
    5. 对话管理模块(DM)根据识别结果有不同的路径:
      1. 识别出用户要求人工客服,或者需要人工处理的业务类(例如安全问题),就会转到所对应的业务线的客服处理。
      2. 识别出的业务可以自助解决,系统就会播放TTS给用户:“我想您遇到的问题是XXXX,请说’正确’,或者’错误’”。
      3. 识别失败,会进入多轮交互流程,进一步向用户提问并获得回答以帮助问题识别。
    6. 系统识别用户在确认阶段的反馈,如果用户肯定了问题,就会推送自助方案到支付宝手机端,并提示用户。如果用户否定,那么会把用户转到人工客服处。

    智能语音客服的核心功能是根据与用户的交互信息判断出用户的来电目的,也就是交互步骤#4中的问题识别模块。问题识别模块允许通过与用户的多轮交互来更准确地判断用户所遇到的业务问题。引入多轮交互流程因为,如果用户只有一次描述问题的机会,下列几个因素的影响往往会导致单轮问题识别无法做出准确的判断:

    • 智能客服的意图判断引擎是基于文本的,而现有的语音转文本技术的字错误率基本上高于10%,特别是对于一些环境噪音比较大的电话语音数据,ASR识别错误会比较大地影响单轮问题识别模型的准确率。
    • 用户的表达能力差异化。部份用户难以一次性地准确,完整地描述他(她)的意图,信息量的不足会使得单轮问题识别模型的识别困难。
    • 即在有很人性化的引导语的情况下,现有系统的统计数据证明仍然有相当大比例的用户(约30%)在面对机器人客服时仍然以“喂”,“你好”等传统对话方式开始交互, 而不会按系统引导语的提示来描述意图,导致无效描述。

    我们训练了3个DNN,它们之间互相协作来完成整个问题识别流程:

    1. 单轮交互问题识别模型:以用户的初始问题描述(如“我的支付宝账号登录不上去了”)为输入执行分类任务,分类目标是1000个业务问题。
    2. 多轮交互问题识别模型:以与用户的全部对话数据(如“用户:我花呗开通不了啊”,“系统:您是卖家吗”,“用户:是的”)为输入执行分类任务,分类目标与单轮交互问题识别模型相同,也是1000个业务问题。
    3. 问题预测模型:当问题识别结果的置信分不高于设定的阀值时,系统会认为用户描述信息量不足,问题预测模型就会从问题库里挑选出对分类最有帮助的问题向用户询问,并收集用户的回答用多轮交互问题识别模型来再次判别。

    3. 模型介绍

    3.1 单轮交互问题识别模型

    单轮交互问题识别模型的输入是用户的一句话描述文本(“我的账号被盗了”),输出是该描述所对应的业务分类(“如何解限”)。

    我们测试了feedforward neural network和RNN(plain RNN和LSTM)两种类型的网络,FFNN的输入为把句子分词后的基于词的bag of word向量;Plain RNN与LSTM的输入为基于词的one-hot序列。这两种类型网络的各种不同配置测试结果显示在测试集上的准确率Plain RNN与LSTM会比FFNN高约1.1%,说明用户描述中的词的顺序对业务分类影响不大,因此从性能及训练时间上考虑我们选择了FFNN。通过多次实验最终确定的结构为:2000维的输入层à 500的线性变换层 à 500的sigmoid unit à 1000的线性变换àsoftmax输出。更多的神经元数量,更多的层数和不同的激活函数,如RELU并未产生更好的效果。

    支付宝以前的IVR流程中有让用户在电话里先描述问题,然后客服接听电话后会打标出该通电话用户所遇到的业务问题。我们取了几个月的数据几千万条,对数据作了一些预处理:分词及词频统计、停用词表过滤、句子长度过滤等。生成的输入所用词表包含按词频排序的top 2000个词,扩展词表对准确率没有帮助。清洗完剩下有效描述文本几百万条。

    3.2 多轮交互问题识别模型

    多轮交互问题识别模型的输入是与用户的全部对话内容(如“用户:我花呗开通不了啊”,“系统:您是卖家吗”,“用户:是的”),输出是该段对话所对应的业务分类(“商家怎么开通蚂蚁花呗”)。

    对序列建模的自然选择是LSTM,我们构建了包含256个cell的LSTM网络。把训练数据中,客服与用户的所有话拼接在一起形成一个长句,以词的one-hot序列作为LSTM的输入。

    拉取客服与用户的380万通电话录音转成文本,这些电话在接听后被客服人员标注了所对应的业务类别,因此天然就是多轮的训练语料,通过BPTT可以训练出LSTM网络用于拟合这些实际发生的对话数据所对应的业务类别的分布。

    3.3 问题预测模型

    问题预测模型的输入也是用户的全部对话内容,它的输出是预先定义的问题库中的某一个问题。问题库的数据来源是从几百万通电话录音中提取客服询问用户的问句,通过文本聚类,将同义的问句归到同一类别,每一个问句类别形成一个典型问题,再通过人工review的方式筛选出最终的问题库。例如:

    • 余额宝的收支明细吗?
    • 余额宝转出吗?
    • 余额宝转入吗?
    • 大陆公司吗?
    • 大陆个人用户吗?
    • 实名认证吗?

    问题预测的目标是挑选一个问题,这个问题如果获得肯定的回答对分类到某个业务帮助最大。用数学建模如下:假设问题库的问题个数为N,业务类别总数为K,令Pi=第i(i = 1 ~ N)个问题是肯定回答的概率,Tj = P(业务分类为j | P1 P2 … PN)为业务类型为j的条件概率(j = 1 ~ K),当问题i变为肯定回答时的信息增益为InfoGain(i) = Entropy(T) – Pi * Entropy(T| Pi =1) – (1- Pi)*Entropy(T| Pi =0)),要挑选出来的问题就是 i = argmax(InfoGain(i))。公式中还有一个问题是如何计算Tj = P(业务分类为j | P1 P2 … PN),为此我们用了一个多层神经网络FFNN来建模从N个问题的回答的分布到业务类型的分布的映射。这个模型的训练数据也是来源于电话录音数据,每一通电话为一个训练数据,与之前的问题库建立流程类似,我们从电话录音文本中提取客服问的问题与用户的回答,转化成P1 P2 … PN向量,加上该通电话的业务类型标注形成了data-label的有监督训练语料。多轮流程的交互过程就是模型预测并提出一个问题,用户给出一个回答。根据这个问答,更新对应的问答分布(P1 P2 … PN)。根据更新后的输入,重新计算每个问题回答改变后的信息增益,选取信息增益最大的问题,向用户继续提问,直到用户意图足够清晰,多轮交互的LSTM网络能够给出高于阀值的分类目标。

    3.4 迭代优化

    在第一版单轮交互问题识别模型上线时识别准确率只有四十几,其主要原因在于训练语料中存在大量的噪声,即众多不同的客服人员对用户描述或电话标注业务类型时存在不少错误或者不一致的情况。这个原因有可能是由于业务熟练程度的原因导致错误标注,或者因为用户的描述本身未包含足够的信息,或表达有误。采用的解决办法是:

    1. 用带噪声的数据训练出一个模型
    2. 用模型识别一遍训练数据,设定一个阀值找出边界样本
    3. 根据业务词表过滤一遍,剩下的再人工检查修正

    经过几轮迭代后,识别准确率有很明显的提升。除了训练数据的预处理,我们还在智能客服语音流程里加入了反馈机制:在问题识别完成后会拿识别结果向用户询问系统是否准确地判断出他(她)的问题,用户可以表示肯定或者否定。这部份数据也会在下一个模型迭代周期中成为训练数据的一部份。我们在工程上也建立了数据拉取à清洗àID化的自动作流程,形成了数据闭环,使得模型迭代接近全自动化。

    4. 蚁人背后的团队

    蚁人项目涉及众多的系统间的交互,CC、MRCP、CSIVR、ASR、TTS、Gateway、DM等。整个系统的复杂程度很高,它的成功上线离不开众多小伙伴们的艰苦努力:感谢冷风、圣衣、良穆在和DM对接中的工作;小伙伴周躜在工程上给予的大力支持;智捷及初敏在算法及工程上的各种建设性建议;九清、弈客、心诗、婻西、佑助等在蚁人从诞生到落地运营的过程中的巨大努力;感谢坤承在模型训练上给予的大力支持;高杰在项目初期的架构规划上的工作;感谢SPEECH小伙伴们长秦、萧言、燕丹等的鼎力相助,以及众多我无法一一列举的伙伴们。

  • 相关阅读:
    Android开发之《内存对齐》
    Android开发之《libyuv库的使用》
    Android开发之《ffmpeg解码mjpeg视频流》
    Android开发之《USB Camera》
    Cenos配置Android集成化环境, 最终Centos libc库版本过低放弃
    (警告)不要轻易删除libc.so.6,以及误删恢复
    Android开发之《硬件加速》
    EPANET中的typedef使用
    面试
    NSString copy && strong
  • 原文地址:https://www.cnblogs.com/hujiapeng/p/6236843.html
Copyright © 2011-2022 走看看