对话系统之智能客服

简述对话系统的组成和逻辑，以及如何应用于智能客服

一、对话系统的定义

二、对话系统的概述

三、对话系统的组件架构

四、智能客服的实现

五、龙小湖

对话系统开源框架

一、对话系统的定义

智能对话系统是可通过语音识别、自然语言理解、机器学习等人工智能技术，使机器理解人类语言并与人类进行有效沟通，进而根据对人类语言中的意图进行理解并执行相应任务或做出回答的系统。智能对话系统可加载于智能硬件，基于对话交互满足智能硬件的操作控制需求，使人机交互更加自然；智能对话系统也可赋能于服务场景，以文本机器人、语音机器人、多模态数字人、智能质检和坐席辅助等对话机器人产品形式服务于客服、营销、企业信息服务等场景。

二、对话系统的概述

常见的对话系统可分为三类：聊天型，任务导向型和问答型：

闲聊型：通常是不关注某项特定任务，它的主要的目标是和人进行开放领域的对话，关注点是生成流畅、合理且自然的回复。
任务型：通常是帮助用户完成某项任务指令，如查找酒店、查询订单状态、解决用户的退款申请等等。用户的需求通常比较复杂，需要通过多轮交互来不断收集任务所需的必要信息，进而根据信息进行决策，执行不同的动作，最终完成用户的指令。
问答型：侧重于一问一答，即直接根据用户的问题给出精准答案。问答型和任务型最本质的区别在于，系统是否需要维护一个用户目标状态的表示和是否需要一个决策过程来完成任务。

在技术实现上，通常又可以划分为检索式、生成式和任务式：

检索式：主要思路是从对话语料库中找出与输入语句最匹配的回复，这些回复通常是预先存储的数据。
生成式：主要思路是基于深度学习的Encoder-Decoder架构，从大量语料中习得语言能力，根据问题内容及相关实时状态信息直接生成回答话术。
任务式：就是任务型对话，通常要维护一个对话状态，根据不同的对话状态决策下一步动作，是查询数据库还是回复用户等等。

检索式 vs. 生成式的优劣：

生成模型的对话更灵活，更像人，但是依赖的语料数据的训练、生成的语言结构等不是特别完善，容易出现语言结构混乱语无伦次看不懂的问题；
而检索匹配式，需要更多的精力去维护问答知识库，同时也会存在意图识别不准，问东答西的情况，但由于实现逻辑相较而言容易实现，且问答是可控的，不会出现语言结构错乱的问题。

一图总结如下：

2bc2fd8b4804aed78b220effac34ad32

闲聊、问答、任务型对话本质都是在被动地响应用户需求。在具体业务中还会有问题推荐、商品推荐等来主动引导用户交互。在美团的业务场景里主要是任务型和问答型，中间也会穿插一些闲聊，闲聊主要是打招呼或者简单情绪安抚，起到润滑人机对话的作用。

三、对话系统的组件架构

用户说话，对话系统的语音识别器（ASR）将输入转为文本，文本由自然语言理解组件（NLU）进行语义理解，接着对话管理器（DM）分析语义信息，保持对话的历史与状态，并管理对话的一般流程；自然语言生成器（NLG）根据对话管理器的对话策略生成对话的文本，最后文本通过语音合成器（TTS）渲染输出；

对话系统的关键是要让计算机“理解”并“生成”自然语言，主要涉及到NLP的三大核心任务：

自然语言理解：NLU（Natural Language Understanding）产生适合对话任务的语义表示（语义表示常见有一阶逻辑、语义网络、概念依存、基于框架的表示），主要通过分词、词性标注、命名实体识别、句法分析、指代消解等进行语义解析产生句子意义（即理解文本是什么意思），进行意图识别（一般通过动宾短语，事件提及，比如查询天气），从中抽取槽的填充值，进而完成语义表示；
对话管理器：DM（Dialog Management）为对话系统的主体，控制着对话的架构和结构，从ASR/NLU组件接受输入，维护一些状态，与任务管理器（知识库）交互，并将输出传递给NLG/TTS模块；
自然语言生成与语音合成：NLG（Natural Language Generation）组件选择需要向用户表达的概念，计划如何用词句表达这些概念，并赋予这些词必要的韵律，TTS（Text To Speech）组件接受这些词句及其韵律注解，并合成波形图，生成语音；NLG模块仍广泛采用传统的基于规则的方法，根据规则可以将各个系统动作映射成自然语言表达。

自然语言处理技术的处理流程需经过获取语料、语料预处理、特征工程、特征选择与模型训练，实现机器与人的对话交互。近年来，深度学习技术的大量使用和不断突破极大推动自然语言处理技术的落地发展。

四、智能客服的实现

智能客服是什么

智能客服背后的技术主要是以对话交互技术为核心，它能让大部分简单的问题得以快速自助解决，让复杂问题有机会被人工高效解决。

用户的沟通对象可能有两个，除了跟机器人沟通外，还可能跟人工沟通。机器人的能力主要包括问题推荐、问题理解、对话管理以及答案供给。

目前，衡量机器人能力好坏的评价一般有外在和内在的评价指标，外在指标指的是我们业务可见的一些指标，比如智能客服的问题解决率（满意率）和转人工率，分别衡量问题解决的好坏，以及能帮人工处理多少问题；内在指标指的是模型算法的一些指标，信息检索常见的评价指标：准确率（precision）、召回率（recall）、F1值等。可根据具体业务场景选取适合的评价指标。而在人工辅助方面，我们提供了话术推荐和会话摘要等能力，核心指标是ATT和ACW的降低，ATT是人工和用户的平均沟通时长，ACW是人工沟通后的其它处理时长。

智能客服——多轮对话

理解了用户意图后，有些问题是可以直接给出答案解决的，而有些问题则需要进一步厘清。机器人对话示例：

这个例子背后的机器人是怎么工作的呢？首先当用户输入“如何联系骑手”的时候，问题理解模块将它与知识库中的拓展问进行匹配，进而得到对应的标准问即意图“如何联系骑手”。然后对话管理模块根据意图“如何联系骑手”触发相应的任务流程，先查询订单接口，获取骑手电话号码，进而输出对话状态给到答案生成模块，根据模板生成最终结果，如右边的红框内容所示。在这个过程中涉及到要先有意图体系、定义好Task流程，以及订单的查询接口，这些都是业务强相关的，主要由各业务的运营团队来维护。那么，对话系统要做的是什么呢？一是将用户的输入与意图体系中的标准问进行匹配，二是完成多轮交互里面的调度。

问题理解是将用户问题与意图体系进行匹配，匹配到的拓展问所对应的标准问即用户意图。机器人的工作过程实际是要做召回和精排两件事情。召回更多地是用现有检索引擎实现，技术上更多地关注精排。

此外，一些场景需要先行确定用户要咨询的是哪个业务，这里的一个任务是“判断用户Query是属于哪个业务”，该任务我们叫做领域识别。若能明确判断领域时，则直接用该领域知识来解答；当不能明确判断时，则还需要多轮对话交互与用户进行澄清。

智能客服——问题推荐

当用户进入服务门户后，机器人首先是要如何引导用户精准地表达需求，这样即可降低用户迷失或者直接转人工服务，也降低了若机器人不能正确理解时带来的多轮澄清等无效交互。

该问题是一个标准的曝光点击问题，它的本质是推荐问题。

智能客服——评价体系

你问我答之「智能客服评价体系」

五、龙小湖⭐️

龙小湖智能客服偏向于【检索式的FAQ问答型对话系统】：FAQ（Frequently Asked Questions）指常见问题的解答，具体形式是问题和与问题相关的答案组成的问答对（QA pair），通常这类 QA pair 数量较多。

当用户输入一个问题，龙小湖智能客服会去FAQ知识库里面找一个和客户的问题最相似的问题（Q），然后将该Q所对应的回答（A）返回给客户，完成知识问答工作。

整个流程主要是QQ 匹配，也即使用用户的问题和问答库里的问题去匹配。涉及到传统文本匹配方法（信息检索中的BM25，向量空间模型VSM）、深度语义匹配方法（孪生网络、交互网络）、度量学习方法（margin-based softmax、对比学习）等。

整体架构

心法利器[13] | 任务方案思考：句子相似度和匹配

预处理模块：分词、实体识别、领域识别、句法分析、关键词抽取、同义词扩展、纠错等基本文本处理流程；
检索召回模块：通过同义词召回、传统BM25召回和语义召回，从 FAQ 库召回与 Query 相关的问题；
排序模块：通过 LTR 模型或者文本相似度模型对召回的问题进行排序，选出 Top k 返回；
最后是业务规则、流量干预等进行顺序调整；

在智能客服的框架中，最重要的模块是 FAQ 问答库的构建、语义召回、相似度模型和模型更新，它们性能的好坏对用户的使用体验有很大影响。

问答知识库构建

智能客服新三网场景问答模型优化实践

QABot是基于问答知识库来实现的，问答知识库是由一系列的问题-答案对组成的数据集。我们将问题划分为标准问题和扩展问题，标准问题是对同一个语义的所有扩展问的抽象。如：”如何发布帖子”，”怎么样发布帖子”，”个人中心里是怎么发布帖子的呢？”等这些问题都表达的是同一个意思，这样我们就可以将”如何发布帖子”抽象为一个标准问，其他相似问题作为该问题的扩展问。

由于我们的问答引擎是基于知识库来实现的，所以知识库的构建就显得非常重要，那么我们是怎么构建知识库的呢？

首先我们会对场景历史积累的问题进行整理，经过抽象、标注形成标准问和扩展问，同时对于扩展问较少的问题使用相关技术做问题扩展，形成初始问答知识库。
然后当系统上线以后，我们会不断的对场景进行问题挖掘，再经过标注整理来不断的扩充知识库。
半自动化挖掘新问题扩展知识库。从线上问答日志中挖掘用户提问，TextCNN新问题分类模型筛选出新标准问题，经过提前训练好的Word2Vec获取句向量，并用Kmeans聚类的方法对新标准问题进行聚类，将语义相同新标准问题聚为一类。最后将聚类结果交给编辑团队去审核，最终由编辑团队归纳总结出新的标准问题和对应的扩展问题并入知识库。

候选问题的语义召回

由于 FAQ 库里面的 QA pair 可能成千上万，如果每接收一个 query 就将其和库里所有的Q进行匹配计算相似度的话，那给用户的响应速度是不可忍受的；因此需要先从 FAQ 库里召回部分与 query 相关的候选 Q，然后再使用文本匹配模型计算 query 和候选 Q 的相似度。

通常的做法是将 FAQ 里面的 Q 存入 Elasticsearch 这样的搜索引擎中来做粗略的召回，但是 es 检索召回只能召回和 query 字面意思相关的候选 Q。另外可以使用表示型文本匹配模型提取 FAQ 库中的所有 Q 的语义向量，使用Faiss 或者 annoy 工具做向量索引，这样就能做语义层面的召回了。其实更进一步，我们可以将所有 Q 先按大类归纳分类，然后再将这些分好类的 Q进行向量索引，在召回时先使用分类模型对 query 进行分类，然后在相对应大类的向量索引里进行语义层面的召回。

相似度模型

在上文我们已经提到了使用表示型文本匹配模型进行语义召回，表示型文本匹配模型其实就是一个相似度模型了，在得到候选召回 Q 之后我们还需要做一个问题排序的工作，然后将排序最高的问题所对应的回答做用户 query 的回答，这里需要使用一个比表示型文本匹配模型性能更高的相似度模型来计算query 和候选 Q 之间的相似度来作为排序模型的特征。我们可以使用交互式的文本匹配模型来完成这个工作。