本篇文章主要讲解了对话系统的逻辑，以及如何实现应用智能客服。

“天猫精灵，放歌”，“送你一首好听的歌《XXX》”，《XXX》音乐响起……

相信有天猫精灵的用户对此场景都不陌生，或者语音操作其他智能音箱设备，比如操作小爱同学”小爱同学，放歌“。我们都了解如何语音操作智能音箱，通过唤醒词（天猫精灵、小爱同学），然后再说明意图（放歌），然后智能音箱被唤醒后，根据说明意图进行相关响应。

智能音箱作为对话系统的一种常见应用，还有我们生活常见到的对话系统应用：Siri、Echo、Bixby、小冰… 对话系统的应用到处可见，但我们对对话系统了解多少以及如何应用实践呢？

本文主要讲解对话系统的逻辑以及如何实现应用智能客服。

目录：

1. 对话系统的定义及发展

2. 对话系统的概述

2.1、对话系统的组件架构

3. 智能客服的实现

3.1、智能客服的概述

3.2、信息检索

3.3、知识库

3.4、设计与评价

4. 总结

5. 参考文献

一、对话系统的定义及发展

对话系统，也称会话代理，一种模拟人类与人交谈的计算机系统，即智能agent，旨在可以与人类形成连贯通顺的对话，通信方式主要有语音/文本/图片，当然也可以手势/触觉等其他方式。

我们说对话系统的发展，一般都会从早期经典的聊天机器人ELIZA开始（聊天机器人术语ChatterBot最早由Michael Loren Mauldin在1994年提及），ELIZA最出名的是以心理治疗师的方式行事。不过对话系统的技术发展主要分为三个阶段：

• 第一代：基于符号规则、模板，80年代末开始，目前依然使用，主要依赖专家人工制定的语 法规则和本体设计，容易解释和修补，但过于依赖专家系统，跨领域的扩展性不足，数据用来设计规则而不是学习，限定狭窄领域；
• 第二代：基于数据驱动的浅层学习，90年代开始（对话策略的强化学习也是这个时候研究出来），目前商用主流，主要是通过数据学习对话系统的统计参数，但不容易理解和修补，难扩展，模型和表示不够强大，不是端到端，难以扩大规模；
• 第三代：基于数据驱动的深度学习，近些年开始，目前研究主流，与第二代一样，数据学习模型的参数，不过神经模型和表示更强大，端到端学习变得可行（即完全数据驱动，模型相当黑盒子），但仍然难以理解和调试更新系统，目前尚无成功商业案例；

二、对话系统的概述

我们先看一段生活常见的对话：

从上面的对话，会发现我们的对话，展示我们人类三个基本的智力活动：

• 闲聊：语言学家称之为寒暄，示例对话A段落，闲聊一般没什么实质性内容，主要是拉近人与人之间的关系，建立信任；
• 知识型问答：示例对话B段落，根据提问（多少钱？），一问一答，单轮对话，主要是提供信息；
• 任务型对话：示例对话C段落，根据意图（购买手机），联系上下文，多轮对话，围绕意图进行对话，直至完成任务；

从我们对话活动中，我们可以发现，我们说话一般都带有目的行为，比如我想买一部手机，言语行为就是购买手机，也就是我们所谓的言语行为理论。言语行为理论，指的是，语言不是用来陈述事实或描述事物的，而是附载着言语者的意图。

根据对话活动，我们的对话引擎架构可以分为三个层次，如下图（图源自周明老师的自然语言对话引擎的分享内容）：

闲聊功能，一般可以通过网上语料库，找到最相似的句子的回复当作回复；问答功能，一般通过资源知识库（问答库/知识图谱等）进行回答；对话功能，一般通过识别意图，填充信息槽，完成任务；

对话活动中，我们发现会有单轮、多轮对话的概念。单轮对话，容易理解，也就是一问一答，与上下文无关；多轮对话，也就是多次对话，围绕意图，联系上下文，直至任务完成结束话轮。

目前任务型的多轮对话的实现，主要是基于有限状态的架构和基于框架的架构，也是目前商用主流，当然还有信息状态的架构（包括马尔可夫决策过程的概率化模型），基于端到端（神经模型）的架构。

基于有限状态的架构和基于框架的架构，主要是基于脚本方法，一种动态记忆模式，将我们生活场景进行框架化，比如，我们去餐馆就餐时，一般活动次序的框架（即脚本）：进餐馆、入座、点菜、用餐、付账、离开。所以，我们对话活动可以根据意图框架进行信息抽取，填充相应的槽，即可完成对话任务所需要的信息，做出相应的反馈。

基于有限状态的架构，也是最简单的架构，系统采用系统主动会话，控制着与用户的会话，向用户提出一系列问题，忽略（或曲解）任何非直接的回答，并继续询问下一个问题，比如用户查询天气的任务，系统会询问用户的查询城市/时间，用户如果回答不是系统提问的问题，则忽略回答继续重复提问该问题。当然，系统一般也会有万能指令的策略，可以在对话的任何地方使用，以便用户请求相应的操作，比如我们常见的万能指令：帮助（返回帮助菜单）、人工/人工客服（转接人工客服）。

不过完全系统主动、有限状态的对话管理架构的限制过于严格，要求用户准确回答系统刚提问的问题，使得对话笨拙；用户可能一次性回复几个问题，或者用户主动提问，所以就出现了会话的主动权在系统和用户之间切换的混合主动，所以就出现目前一种常用的混合主动的对话架构就是依靠框架本身的结构来引导对话，即基于框架的架构。

基于框架的架构，对话系统询问用户问题，然后填充框架里的槽，但是同时也允许用户通过提供填充框架中的其他槽的信息来引导对话。这样，基于框架的架构可以去除有限状态的架构对用户提供信息的顺序的加强严格约束；当然，遇到多个任务需要多个框架处理的时候，系统必须能够对给定的输入填入哪一个框架模板的哪一个槽进行排歧，然后将对话控制转换到该模板。

下面我们来看看一个基于框架的对话过程（图源自周明老师的自然语言对话引擎的分享内容）：

对话过程，实际上就是对用户输入的话，检测意图是什么，如果检测不到，系统就判断可能是聊天，然后通过聊天的引擎进行沟通。如果检测到意图，比如知道用户是要订旅馆，那么就有对应的订旅馆的对话状态表记录目前进行的状态及要填充哪些信息。系统知道要填什么信息的时候，就会生成相应的问题让用户回答，用户回答完之后系统再把信息抽取过来填充到这个表里，直到所有的信息全部填充完毕，就完成了这个任务的对话过程。

这里就涉及到了对问题的理解，问题中有哪些信息要抓取出来，还有对话管理，比如状态的转移，slot的填充或者更改，选择一个新的slot开始对话，以及如果要决定填充哪个slot的时候，怎么生成对话可以让用户很自然地回答这个问题，从而获得系统所需要的信息。

2.1 对话系统的组件架构

我们现在已经对对话系统有了整体的认知，接下来讲讲我们目前常见的对话系统的组件架构。

上图为对话系统的典型架构，六个组件，语音识别和理解组件从输入中抽取意义，生成器和TTS组件将意义映射到语言，对话管理器与具有任务领域知识（如电商领域知识库）的任务管理器一起对整个过程进行控制。

用户说话，对话系统的语音识别器（ASR）将输入转为文本，文本由自然语言理解组件（NLU）进行语义理解（主要为分词、词性标注、命名实体识别、句法分析、指代消解、语义解析），接着对话管理器分析语义信息，保持对话的历史与状态，并管理对话的一般流程，通常，对话管理器联系一个或多个任务管理器（知识库），自然语言生成器根据对话管理器的对话策略生成对话的文本，最后文本通过语音合成器（TTS）渲染输出；其中，对话系统的主体是对话管理器，它是管理对话状态和对话策略的组件。

组件介绍：

• 语音识别：ASR（Automatic Speech Recognition）一般包括四大块：信号处理、声学模型、解码器、后处理，首先采集声音，进行信号处理，将语音信号转化到频域，从N毫秒的语音提出特征向量，提供给声学模型，声学模型负责把音频分类成不同的音素，接着解码器得出概率最高一串词串，最后的后处理就是把单词组合成容易读取的文本。简单的说，就是接受音频输入，返回一个转录的词串；当然，对话系统中，ASR系统一般都做了定制的优化，同时，一般对话系统还要求ASR系统返回句子的置信度，用来决定是否询问用户来确认该回答这样的任务；
• 自然语言理解：NLU（Natural Language Understanding）产生适合对话任务的语义表示（语义表示常见有一阶逻辑、语义网络、概念依存、基于框架的表示），主要通过分词、词性标注、命名实体识别、句法分析、指代消解等进行语义解析产生句子意义（即理解文本是什么意思），进行意图识别（一般通过动宾短语，事件提及，比如查询天气），从中抽取槽的填充值，进而完成语义表示；

分词：将句子切分词序列，词是承载语义的基本单元。中文自动分词被认为是中文自然语言处理中的一个最基本的环节，比如句子“我爱中国”，切分为“我/爱/中国”；

词性标注：识别词的词性，描述一个词在上下文的作用，比如名词、动词、形容词；

命名实体识别：也称作专名识别，是指识别文本中具有特定意义的实体，主要包括人名、地名、机构名、专有名词等；

句法分析：分析词与词之间的结构关系，确定句法结构，比如主谓宾关系；

指代消解：决定哪些实体被哪些语言表述所指代的任务，比如句子“香蕉熟了，把它给大家吃了”，句子中的它指的是香蕉；

• 自然语言生成与语音合成：NLG（Natural Language Generation）组件选择需要向用户表达的概念，计划如何用词句表达这些概念，并赋予这些词必要的韵律，TTS（Text To Speech）组件接受这些词句及其韵律注解，并合成波形图，生成语音；
• 对话管理器：DM（Dialog Management）为对话系统的主体，控制着对话的架构和结构，从ASR/NLU组件接受输入，维护一些状态，与任务管理器（知识库）交互，并将输出传递给NLG/TTS模块；

对话系统主要有三大模块：对话上下文（Dialog Context）、对话状态跟踪（Dialog State Tracking）和对话策略（Dialog Policy）。

对话上下文（DC）：记录对话的领域、意图和词槽数据，每个领域可能包含多个意图的数据, 一般以队列的形式存储；

对话状态跟踪（DST）：记录T-1状态与当前时间T的状态，即会结合上下文，确定当前对话状态，同时会补全或替换词槽；

对话策略（DP）：根据对话状态和具体任务决定要执行什么动作，比如进一步询问用户以获得更多的信息、调用内容服务等；

三、智能客服的实现

自然语言处理（NLP）技术一直以来被认为是成熟度相对较低的AI技术分支，不过，尽管NLP在开放领域环境中表现不佳，但对于限定场景来说，NLP及其背后的知识图谱技术却能发挥出巨大价值。智能客服就是NLP最常见的应用之一，也是对话系统最常见的应用之一。

作为企业客户关系管理（CRM）的重要组成部分，客服是连接企业与客户的重要桥梁，极大地影响着企业的销售成果、品牌影响及市场地位。但是，长久以来，客服行业都存在诸多痛点，客服人员流动性大、培训成本高、客服难以把控、大量重复性问题过度消耗人工客服，同时，如何提升售前转化，如何优化客服流程，如何从客服数据中发现企业业务问题等，都是各类企业面临的普遍问题。因为这些普遍问题的存在，智能客服应运而生。

根据国内客服行业的第三方报告（下图），智能客服正在以40%-50%的比例替代人工客服工作，AI将为智能客服厂商释放500-800亿市场空间，所以一直以来，大量企业布局智能客服行业。

3.1 智能客服的概述

智能客服，也就是我们所说的客户维护的智能服务，比如我们常见的淘宝小蜜、京东JIMI。

目前受限于NLP算法水平的限制，现在智能客服在实际使用中更多是发挥辅助作用。目前智能客服最常见的形式就是在人工客服系统基础上，扩展出智能客服的功能，最常见的功能为单轮问答、功能对话、人机协作。

人机协作，一般是智能客服优先回答问题，解决不了再转人工，也就是智能客服解决一定的高频简单问题，疑难问题转接人工客服。

根据智能客服目前常见的定位单轮问答，知识库问答的技术本质也是搜索引擎相似的技术，都是信息检索。

3.2 信息检索

信息检索（Information Retrieval，IR）主要是寻找从文档集中获取可用信息的模型和算法，用户输入一个表述需求信息的查询字段，系统回复一个包含所需要信息的文档列表，比如我们平时所用的百度、谷歌搜索。

目前大多IR系统都是基于组合语义的一种极端版本，用户查询内容表示为检索词表达的信息需求，检索词进行词义排歧、同义扩展等处理（比如同义词扩展，可通过WordNet同义集），生成对应的向量，查询向量与文档向量（彼此向量通过权重处理，比如TF-IDF）计算相似度（可通过余弦计算，越接近1越相似，越接近0越独立），如下图。

其中，文档表示被系统索引及提供给检索的文本单元，文档列表表示用于满足用户需要的一组文档，检索词指文档列表中出现的词汇项，可用来当索引。

我们可以看到上图的信息检索架构返回的是文档列表，而智能客服问答返回的是答案内容，我们来看看问答与信息检索的区别：

我们可以看到，问答集成了知识表示、信息检索、自然语言处理和智能推理等技术，毕竟用户希望的是获取一段特定信息，问题的答案，需求的解决方案，比如用户问题怎么重置密码。

这个时候，我们返回的应该是用户问题重置密码的解决方案答案，所以智能客服的问答应用信息检索的时候，做了相应的调整，检索返回的是答案（即计算概率最大的候选答案，可以理解为所谓的推荐），同时一般会在问题查询处理的时候，增加问题分类模块，也就是某个问题是什么类型，可以针对类型更好的回答，分类器可以通过标注类型的对话数据进行训练。

3.3 知识库

现在我们了解了智能客服模型的实现，但对话系统如果没有语料库，还是不会对话，正所谓巧妇难为无米之炊。语料库也就是我们智能客服所说的知识库。知识库可以来自我们整理的知识图谱或者问答库等，知识库的难点在于数据的冷启动、数据的清洗及整理。

数据的冷启动，也就是生成知识库的原始数据有没有的问题（数据冷启动同样影响信息检索模型的训练），不过智能客服一般都是限定于领域，应用于自身企业的服务，前期客服都是人工服务，所以我们一般可以积累人工对话的数据作为知识库的原始数据（一般是选择一定周期内的数据，具有通用性）。

数据的清洗及整理，也就是有了原始数据后如何生成完整可读的知识库。我们常见的一种知识库就是所谓的问答库（即问题答案对，当然，一般还会有其他标签，比如人工标注的问题类型）。问答库的生成，我们可以通过原始对话数据对同一标识的对话（表示同一用户与人工客服的完整对话），根据对话身份ID的不同分别对同一ID的话段通过N-gram拼接起来（主要通过词袋出现的unigram、bigram、trigram，一般到trigram，太少句子不通顺，太多计算量大，毕竟N元模型的大小几乎是N的指数函数即O(|V|^N)，V为词汇量，然后通过N-gram拼接算法把N-gram片段拼接起来即可，一般可以通过NLTK工具包处理），成为一段较为通顺的句段，最后再经过人工审核及标注，形成完整可读的问答知识库。

其中，词袋指的是一段文本（比如一个句子或是一个文档）可以用一个装着这些词的袋子来表示，这种表示方式不考虑文法以及词的顺序；N-gram，即N元语法，指的是文本中连续出现的n个语词，N元语法模型是基于(n-1)阶马尔可夫链的一种概率语言模型，通过前面出现的n-1个单词预测下一个单词，通过n个语词出现的概率来推断语句的结构；当n分别为1、2、3时，又分别称为一元语法（unigram）、二元语法（bigram）与三元语法（trigram）。

下图为上述对话C段落，经过N-gram拼接处理后，再经过人工审核标注的问答库示例：

不过，由于问答库的问题单一性，用户采用相似问法提问时，可能由于模型等问题找不到对应的答案，导致用户不满。即使我们对问题进行扩展等泛化处理，采用松弛模式允许匹配忽略部分文本的结果，但会引起一些不正确的结果，也引起用户的不满。所以为了提高问题的准确性，我们可以通过种子模式，即采用整理好的知识库的问题关键词，在原始或清洗后的对话数据集上进行搜索，查看用户常见的问法，进行问答扩展，增加问题的相似问法，比如上图的问答库的问题“购买一部2000元的小米手机”，可扩展相似问法“推荐一部2000元的手机，品牌不限”。

当然，知识库越丰富越好，毕竟越丰富则覆盖的业务范围问题越广，解决用户需求的可用性越好，就像我们人类一样知识面越广，则能解决更多问题，能力越好。

3.4 设计与评价

智能客服不是开放式的聊天对话系统，而是基于特定业务领域和业务场景的对话系统，目的是快速解决用户的需求，一个最理想的对话系统就是用最少代价就能帮助用户实现目标的系统，所以智能客服应以用户为中心的设计原则，用户满意度至关重要。

设计：

智能客服由于自身的目的性，应当根据自身的业务场景选择相应的对话策略、提示、错误信息反馈等设计原则。

常见的设计要点：

• 研究用户和业务：分析用户画像，以及调研用户常见的问题，获知用户的潜在问题进行相应的推荐引导，以及个性化回答用户；比如每个用户进入智能客服，界面的问题引导都不一样；
• 对话策略：问题高相似即反馈答案，一定程度相似可反馈相似的几个问题，收敛引导用户提问，低相似的问题可引导用户重新提问或引导转接人工客服；同时，增加闲聊库，保证用户对话的顺畅性，避免部分用户闲聊无应答。当然，还有快速收敛，用户输入时通过联想提问显示提示问题引导用户选择提问，一般也会有万能指令的策略，可以在对话的任何地方使用，以便用户请求相应的操作，比如我们常见的万能指令：帮助（返回帮助菜单）、人工/人工客服（转接人工客服）；
• 对话数据完整性：用户转接人工客服后，保证用户与系统对话的数据同时转接至人工客服对话窗口，方便人工客服快速了解用户需求，也避免用户再次提问，提高客服接线率和时间效率，提高用户满意度；
• 对设计进行迭代：数据监控，根据指标数据分析优化；根据用户满意度的意见进行优化；知识库的维护及更新（包括模型自主学习）；

评价：

用户满意度是我们智能客服的衡量标准，用户可以在系统界面满意度问卷进行显性反馈，这是我们直接拿到的用户真实评价。但反馈用户满意度毕竟需要操作成本，很多用户都不会去反馈，所以我们拿到直接的满意度评价比较少，更多会结合其他衡量指标进行综合评价系统。

评价一般有外在和内在的评价指标，外在指标指的是我们业务可见的一些指标，比如智能客服的问题解决率、人工客服系统的接线率/会话时长等衡量指标；内在指标指的是模型算法的一些指标，信息检索常见的评价指标：准确率（precision）、召回率（recall）、F-测度值。可根据具体业务场景选取适合的评价指标。

总结

当前受限NLP算法水平的限制，目前智能客服更多是辅助人工客服，未来，想进一步替代人工客服，NLP技术理应做到实现更好的多轮对话建模以及个性化回复，从而理解用户的真实意图及对话自然。

毕竟对于智能客服来说，重要前提就是准确理解用户问题，同时可以联系上下文，与用户进行自然地多轮对话，理解用户意图，解决用户问题，这样才能更好进一步替代人工客服。

参考文献：

《自然语言处理综论》（第二版）

https://36kr.com/p/5136136.html

https://www.leiphone.com/news/201703/6PNNwLXouKQ3EyI5.html

https://www.msra.cn/zh-cn/news/features/ming-zhou-conversation-engine-20170413

作者：铅笔小葵（微信号：gaokaikui  知乎专栏：铅笔小葵），产品经理，负责产品从0到1的开发，曾任Java工程师，参与后台开发。欢迎大家互相交流关注。

本文由 @铅笔小葵 原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自Unsplash，基于CC0协议