单轮对话
一、单轮对话
指简单的一问一答，问题可以用一句话来描述，不依赖于上下文。如下图所示：
对话交互中大大量的问题都是这样的单轮问答。
一般这样的问答依赖于一个知识库/问答对集合。机器人从知识库里检索相似的问题，给出答案。
二、单轮对话指标
1、召回率
召回率 = 机器人能回答的问题数 / 问题总数
召回率：机器人能答上来的问题越多，则召回率越高。
会话没有召回可能存在两种情况：
1）、知识库规则不够全面，问题是知识库里没有的问题，在这种情况下，需要完善知识库，涉及到知识库的初试设置和后续的自学习能力。
2）、相似问题在知识库里有，但是由于语义理解问题没有找到，这种情况下则需要优化算法。
例如：同一个问题，我的快递到哪儿了？或者我的快递什么时候到？其实都是问的查询快递的问题，因此可以归类为同一个问题，这个就是优化算法。
2、准确率
准确率 = 机器人正确回答的问题数 / 问题总数
对闲聊机器人来说，因为闲聊场景下没有明确的正确答案，所以准确率不是闲聊机器人的主要评测指标。
闲聊机器人更关注召回率，更关注问答的相关性，是否有趣有情感等指标。
对任务型和问答型机器人来说，要求优先保证准确率，即宁愿不回答，也不能答错。
准确率这一评测指标在实际使用中需要人工来标注机器人的回答是否准确，所以使用场景相对受限。
企业的客服部门通常会使用问题解决率来作为日常工作中对机器人的主要评测指标。
3、问题解决率
问题解决率 = 机器人成功解决的问题数 / 问题总数
机器人成功解决的问题数 = （问题总数 - 转人工客服的问题数量 - 顾客反馈不满意的问题数量）
企业需要设置合理的机器人转人工客服策略，确保顾客在客服机器人不能很好的解决问题的情况下，可以转由人工客服接待。同时，企业在客服系统中应该提供对机器人客服的反馈和打分机制。
三、单轮对话的难点
1、识别同一问题的不同表达方式
在口语中，通常一个意思有很多种不同表达方法。
做的不好的机器人需要把左边的5个问法一个一个的录入，而做的好的机器人，只要输入其中一个问法，其它的问法可以自动识别，返回一个相同的答案。
2、理解语义细微差别，处理差异性问法
语言在叙述中常有细微的差别，可能是一两个字的区别，语义就不一样了，也有可能字完全一样但标点语气不同，表达的也不是一个意思。好用的机器人，即使问句非常类似，但语义存在差别，也会自动匹配到不同语义下的不同答案。
3、聚类高频问题，自动学习优化知识库
提高召回率和准确率，需要完善知识库。人工补充知识库是非常困难的，机器人需要有自动学习能力，根据历史对话数据，自动总结及挖掘不在知识库内的高频问句，补充和完善知识库。
多轮对话
一、多轮对话
| 单轮对话 |
多轮对话 |
| 轮次和轮次之间独立，任意两句话之间相互独立 |
考虑话语之间的相互关系 |
| 执行一条指令所需的全部信息都在这一句话中 |
可以处理不完整的语义情况 |
| 没有记忆功能 |
记录历史话语 |
二、多轮对话评测指标
1、任务完成率
任务完成率 = 成功结束的多伦会话数 / 多伦会话总数
成功结束的会话数量越多，则认为任务完成率相对较高从而多伦会话的可用性也可能更好。
但需注意的是，会话成功结束，并不一定意味着问题得到解决，也有可能客户没有从机器人出得到需要的答案。通常，多伦会话机器人会设置转人工策略，当机器人会话不能继续时，转交给人工客服处理。
2、定制难度
1）是否提供完整的API接口和开发文档，技术开发人员能够快速开发和集成。
2）是否支持非AI专业人员开发多轮对话模型。
3）界面交互体验是否优秀，是否支持直观可视化编辑。
Q：所谓“必要信息”一定要通过与用户的对话获取吗？
A：不一定，即便是人与人之间的交流，对话本身所包含的信息也只占总传递信息量的一小部分，跟多信息来源于说话人的身份、当前的时间/地点等一系列场景信息。所以多轮对话的信息获取方式也不应当只局限于用户所说的话。例如：你要购买机票，但机器人通过定位就已经获得了你的位置，就不用再询问你从哪里出发了。
Q：多轮对话一定在形式上表现为与用户的多次对话交互吗？
A：不一定，如果用户的话语中已经提供了充足的信息，或者其它来源的补充信息已经足够将用户的初步意图转化为一条明确的用户指令，那就不会存在与用户的多次对话交互。
三、多轮对话难点
1、准确进行语义理解
1）要有上下文的关联
2）支持中途打断回溯
3）支持指代识别
2、状态管理和个性化语言生成
1）用户画像管理
结合用户画像，机器人应当做出千人千面的个性化问答反馈。
比如针对不同地域的用户咨询教育机构选课场景。
“北京” 的用户得到的机器人回复应当是北京开班的课程，
“上海”的用户得到的机器人回复则是上海开班的课程
所以即使相同的问题，不同地域的用户问，得到的答案会完全不同。
2）对话状态管理
例如：“请帮我订3月28日北京到上海的机票”->引导用户身份证信息
“请帮我订北京到上海的机票” -> 引导出发时间 & 身份证信息
意图识别
一、意图识别
指识别提问者的潜在目的及表达诉求。
意图识别与预置行业知识库有关系。预置行业知识库越完善，机器人对用户的意图就能够识别的更加具体和准确。
在相同的意图大类下，还有可能会将更详细的意图进行分类。
例如：“请问你们发哪家快递” 和“请问我的快递走到哪了”都同样属于物流咨询意图，但从更细致分类来讲，“请问你们发哪家快递”属于咨询物流供应商选型的意图，而“请问我的快递走到哪儿了”属于查询物流状态的意图。
任务型对话需要意图识别，而问答型对话不需要意图识别。
二、意图识别难点
1、用户输入不规范，且同一问题的不同用户的表达方式存在差异。例如，“请帮我订一张深沪高铁票”，这里的“深沪高铁”是否是和另一用户说的“深圳到上海的高铁”是同一个意思呢
2、多意图判断，相同的词汇比如水，可能有多种意思，可能是喝的水，也可能是护肤品爽肤水。
3、数据冷启动，必须基于大量数据才能定义并获取准确意图。
4、没有固定评价标准，用户意图并没有量化测量指标，基本以人为主观判断为准。
对话理解方法
一、基于语义解析：任务型
识别用户对话意图并将其参数化
例如：今晚六点帮我在全聚德预约一个包厢，十个人
意图：预定餐厅
词槽：餐厅名{全聚德} 时间{2018.10.1 18：00} 人数{10}
参数化就是生成结构化的数据。
1、常见技术手段、
| 启发式规则&推导 |
传统机器学习 |
深度机器学习 |
|
| 优势 |
少量数据即可启动 |
数据&特征驱动优化 |
纯数据驱动优化 |
| 优化手段直观可控 |
具有较好的泛化效果 |
具有较好的泛化效果， 可迁移性较强 |
|
| 劣势 |
需要大量专业知识 |
需要领域特征工程 |
|
| 容易达到效果瓶颈 |
需要标注大量语料 |
需要海量语料 |
|
| 可迁移性较差 |
可迁移性较差 |
可控性，可解释性差 |
|
| 可控性，可解释性较差 |
二、基于语义匹配：问答型
识别用户对话意图并找到与该意图最相似的问答对
例如：我想了解借现金怎么申请
question：【现金贷】借现金的申请流程是什么
answer：当您用自己手机下载百度钱包APP后........
即从知识库中找出整句与这句话最相似的问题，然后给出这个相似的问题的答案。
1、常见技术手段
一、词槽
满足用户对话意图时的关键信息和限制条件，可以理解为用户需要提供的筛选条件。
例如在查询天气时，词槽是地点和时间。
例如：“换到中央台”中的“中央台”就是一个“电视台词槽”。词槽会一定程度影响系统对“换台”这个对话意图的执行。
二、词典：
属于词槽的所有词汇组成词典
三、对话样本
用来给对话系统做示范，教他在用户说的具体句子里，该如何理解对话意图，哪个词是重要信息，对应的词槽是什么。
四、对话模板
用来给对话系统按具体语法、句式做出的示范，教他在某一特定语法，句式中，该如何理解对话意图，哪个词是重要信息，对应的词槽，特征词是什么。
例如：通过对话样本标注告诉机器人“三亚明天会不会下雨”与“三亚明天会下雨吗”都是询问天气的语句，其中“三亚”是对应城市city这个词槽，“明日”和“明天”都是time词槽。
这样的训练越多，机器人的理解能力便越强，这与学习语言中的人类孩童的学习方式十分相似。
例如：“[D:sys_loc][D:sys_time]天气如何”，上述标注表示可以将所有满足“[城市]+[时间]+天气如何”这一规则的query解析为WEATHERINFO对话意图。
对话模板也可以使用多条对话模板组成对话模板组，实现按片段去匹配用户query，实现更强的对话意图泛化匹配能力，提高模板对用户query的召回率。
对话系统分类
一、按场景分类
1、任务型：有任务目标，且需要参数化请求。如：智能助手
2、问答型：有任务目标，无参数化请求。 如：智能客服
3、闲聊型：开放，不限定领域。如：陪聊机器人
三种类型的特点：
| 任务型 |
问答型 |
闲聊型 |
|
| 平台系统开放性 |
一家公司开发，通常面向C端消费者。通常不开放技术细节，可能调用第三方服务，不能定制机器人会话 |
通常是一个平台，技术细节可能开放，可以让普通用户配置修改机器人 |
一家公司开发，通常面向C端消费者。通常不开放技术细节，可能调用第三方服务，很难定制机器人会话 |
| 技术方案 |
精准、可控、复杂 意图识别+多轮对话+对接公开API+知识图谱。领域意图和对话预先定义 |
较精准，较可控，较简单，需要自行挖掘问答对或意图识别+多轮对话+对接企业API+企业知识图谱。 补充同义问题 |
几乎完全不可控，可直接调用 检索式：构建一个闲聊库，检索类似的问题，给出答案。 生成式：从闲聊库这里生成模型。 |
| 优化目标 |
用最短的对话轮次，满足用户需求 |
用最短的对话轮次，满足用户需求 |
聊的越久越好 |
1、任务型：
整个对话围绕一个目标，一般通过多轮对话才能达成这个目标，ChatBot能达成目标就是合格的。
2、问答型：
不一定是用户提问，机器人回答。单轮就能完成的对话，也可以归类为问答型。
3、闲聊型：无目的对话，chatbot越接近人越好。
通常任务型+问答型结合使用。
对话系统话术设计注意事项
1、简洁明了
遵循格里斯法则：
1）质量准则：只说确认的真实的内容
2）数量准则：所说话的话需要满足交流所需要的信息量，但不应该超出交流所需的信息量
3）相关准则：只说和主题相关的内容
4）态度准则：见说话需清晰、明了，避免模棱两可
格里斯法则反例：
| 准则 |
反例 |
| 质量准则 |
宣传一件你做不到的事情，比如对用户说：“有什么可以帮助您的吗”。而实际上整个聊天机器人的系统仅仅能够提供酒店预订的服务 |
| 数量准则 |
多余的措辞，比如“请您注意听，因为我们的选项已经变了”。其实并没有人关注这些内容 |
| 相关准则 |
给了用户一些当前用不到的知识。比如在用户还没下单的时候就给用户解释退货的政策 |
| 态度准则 |
使用用户难以理解的专业术语 |
2、对话语句要自然
1）大声朗读你写的内容，使用随机化的表达，使对话听起来更自然
2）用对话的思维填写，而不是对官网或者app内容的复制粘贴
3）需要给用户明确的上下文暗示。而不是一个模糊的陈述，让用户不知所措。
3、处理新手用户&老手用户
只依靠使用次数来确认切换模式并不合适，因为一个人可能使用了多次，但是一两个月只使用一次。在这种情况下，应该继续保持新手提示。你的目标不是简单的训练你的用户，而是适应用户的行为，而不是用已有的命令让用户感到厌烦。
4、适当使用问候语&结束语
1）告诉用户你是谁
- 用户是否知道他们正在和谁对话，是机器人还是人工客服
- 当从机器人转到人工客服的时候，过程是否明确，用户是否知道了角色的转换
2）对话包含的信息量要合适
- 新接触产品和品牌的用户， 他们是否能够理解对话开始的问候语包含的信息是否合适？信息是否过量。
- 对于多次访问的用户，问候语是否有重复的问题？是否可以更加简短、亲切的问候语提供给他们
3）采用合适的方式结束对话
- 当用户完成目标的时候，是否提供了一个无障碍的推出路径？“好的，谢谢”，“不需要了，谢谢”，这类表达是否赋予了快速退出的含义？
5、积极确认
当用户提出请求，机器人进行确认--用类似“ok”、“好的”、“收到”、“明白了”的短语进行反馈，确认让用户知道他们说的话已经被获取到。随机的确认语可以让体验更加流畅。
确认策略：显性确认；隐性确认；置信度综合的显性确认和隐性确认
注意：
- 应答用于在话题更换前表示接受、拒绝、二次确认、更正。
- 对重复信息需要谨慎，应答要避免滥用
1）显性确认场景：
- 难撤销的操作
- 对于购买者的消费协议或法律法规的口确认
- 系统性能不好
2）隐性确认场景：
对获取信息的识别准确度较高，以减少出错的可能性。方便用户及时纠错
3）置信度综合的显性确认和隐性确认
使用这种方法的时候，系统将在一定的阈值内以明确的形式确认信息，拒绝较低置信度的信息，并以印象确认来确认置信度超过一定阈值的信息。
下图智能音箱的例子：
确认策略话术对比：
如果缺少应答，用户可能会质疑刚刚说的话，系统有没有听懂。对话UI可以在下一步操作之前，通过随机的确认来消除用户的这种质疑。也可以结合其他的一些连接词（如实际上，然后等），把整个对话更好的连接起来。
6、随机策略
要避免应答单调、套路化的方式之一就是随机机制。为了保持新鲜感和多样性，需要提供一个特殊的随机应答类别。
7、使用对话式标识
对话式标识是让用户了解交谈进展以及进展情况的重要方式。当系统在对话中使用了一些基本的对话礼仪之后，用户的参与度会更高，并且会以同样的方式进行恢复。他们就像胶水一样，将交互中的各个部分连接起来。
“计算机不应该像人那样说话”
注意：要使用适合你系统角色设定的对话式标识。同时，即使是非常正式、官方的系统，也可以使用对话式标识并从中获益。虽然用户都知道他们正在和机器人交流，但是人们依然会需要这些对话的基本原则。
例子对比：
8、加入异常处理
9、设计对话通用模块
10、设计延迟话术
原因：
1）糟糕的连接性能
2）系统处理进程，需要等候
3）数据库访问需要时间
11、设计歧义消除技术
当一个用户的指令不明确的时候，需要主动发文，消除歧义。
12、主动学习
人的表达会存在各种各样的情况，所以不管用户说什么，不要把它当成是一个错误来处理，而是要考虑如何把这转变为一个机会，去推进更顺畅自然的沟通，让机器进行主动学习。
对于重要的请求，需要明确的显性确认，而对于低风险的任务，可以采用隐形的确认，把它转变为一种提供有价值的互动的机会，让机器人像人一样在交流中学习。
创建对话系统
一、定义对话系统
1、确定场景边界
2、梳理业务要素/知识库
3、撰写故事线
4、抽取对话流程：画对话流程图
二、富集数据资源
1、资源类型
- 词典词槽
- 对话样本
- 问答对
2、如何富集
- 指定业务场景提取数据
- 对话日志中抽取相关数据
- 官方数据库
三、搭建系统、训练、评估和调优
2种方式搭建系统：代码工程实现（成本高，且要求工程师技术能力高）；第三方工具实现
找到一些搭建机器人团队以外的人，让他们在没有任何提示的情况下试用一下。对流程多测试几次，就能发现一些问题，例如哪个对话任务完成起来有困难，或是用户与语音交互的场景中，听者的感受如何。
之后也可以收集一些主观反馈，例如他们在哪里卡主了，在什么地方感觉不顺畅。当然这些信息只是你海量用户中的一部分反馈，但这可以帮你在产品真正上线发布之前就搜集一部分有价值的信息。
四、系统接入：全渠道API接入
用户在哪里，服务就接入哪里。搭建完了对话系统，要接入到不同的message app里。
五、系统接入：通用模块
- 智能人机协作：机器转人工服务，人工转机器服务
- 用户评价管理
- 数据化商业决策：根据用户数据进行商业决策
六、运营迭代
记录与观察机器人与用户的交流应答，沉淀用户信息。
在统计中查看热点业务问题的答案命中次数，根据统计结果更好的调整客服工作策略、甚至进一步调整企业市场宣传重点。
设置对话漏斗，层层追踪信息转化比例，我们要知道，用户在那一层或在哪一次对话中丢失了。
对话系统的生命周期
传统软件开发与对话系统开发的区别：
1、传统软件在设计了产品文档后就可以做开发了，但对话系统在产品文档与开发之间要加入脚本，即故事线设计。
2、传统软件的线上测试，可能不用考虑多个平台，但对话系统的设计需要加入适配不同的消息平台的控制机制
3、对话系统的分析中，要善于利用线上的对话日志，通过用户在对话过程中的纠正、反馈，来优化对话模型中的对话理解效果，让机器人越来越聪明
参考百度桔子互动