阿里小蜜Chatbot架构介绍 论文笔记

2018年初, 阿里公开展示了自己的智能助手小蜜的设计结构. 作为类似客服助手的大型对话问答系统, 小蜜整合了任务型模块与开放聊天模块, 并围绕自身的应用场景, 构建了下文中介绍的工业级智能对话系统.

AliMe Assist- An Intelligent Assistant for Creating an Innovative E-commerce Experience

整个系统由三个服务模块构成: 助手服务(assistance service)、用户服务(customer service)、聊天服务(chatting service). 模块由一系列判别策略串联. 用户输入会通过下面的处理流程确定分配到哪个服务中. 下图可以看到三种服务对应的三类需求


这里先简单描述三个服务模块, 再按照下图处理流程描述整个系统的工作过程.

  • 助手服务(assistance service) 该模块用于处理"用户目标明确, 属性固定"的任务, 此类任务一般只需要用户确定类型的信息, 如"订飞机票"只要用户给出<出发地, 目的地, 时间>此类属性. 对用户输入的处理也只需要识别出用户需求所含的属性, 并让用户补充属性的值填充即可. 针对应用场景, 小蜜团队设计了基于字典(dictionaries)和样式(patterns)的填槽模块(slot-filling engine), 可以识别出15种不同的属性.
  • 用户服务(customer service) 如果用户需要的是寻找某种信息或某种解决办法, 比如"忘记登陆密码怎么办". 此类需求无法靠助手服务处理, 就需要用户服务模块了. 这里的核心是知识图谱技术, 通过抽取实体, 关系查询等技术找到需求对应的答案.
  • 聊天服务(chatting service) 以上两个模块能覆盖绝大多数的用户请求(95%), 但出现特殊情况, 比如知识图谱中不含盖的实体时, 系统就需要调用聊天服务处理了. 此模块实际上就是一个开放域对话系统, 通过Seq2seq模型, 结合检索和生成策略来回应用户请求. 检索和生成策略的结合方式很简单, 首先设定一个匹配度得分的threshold, 用检索策略选出一组用户输入对应的response, 对应一组匹配得分, 分数高于threshold的候选回复可以输出, 若没有可返还输出再调用生成模型seq2seq. 聊天服务模块的具体细节可参考该团队公开的另一篇
文章www.aclweb.org


下面通过描述处理流程展示小蜜的系统设计. 首先, 用户输入q(text/voice)被传给规则解析模块(business rule parser), 规则解析模块是由大量的样式(patterns)组成的前缀树匹配结构(trie-based), 用于判断q是否能被助手服务处理. 如果能匹配出确定的样式, 则检查该样式是否某种特例(文章的例子是打折促销(promotional activities))可以直接由模版(template)给出答案, 或是属于助手服务的处理范围, 则传给填槽模块处理.

如果规则解析模块没有检查到样式, 则进入意图分类模块(intention classifier), 该模块由FastText+单层CNN这种相对简单的深度网络模型构成, BTW 作者在这里解释了这种简单的网络结构已经足够好, 且比更多层的CNN或RNN有更好的扩展性(scalability). 这里判断用户是否需要直接连接人工服务(service staff), 若不需要则进入下面的用户服务判别处理流程.

这部分先由语义解析模块处理, 由语义匹配寻找语义标签, 也就是知识图谱(KB)中的实体(entity), 由KB中的实体关系寻找用户问题q对应的回答(answer)并返回; 假如没找到回答, 可以检查该问题q之前的上下文信息(context), 与q合并后再传给语义解析模块循环执行; 如果q是问答过程的第一句话, 没有上下文可用, 则借助识别出的语义标签向用户询问补充信息作为上下文, 如果得不到用户补充, 就将q传给聊天服务中的检索模块, 检索到匹配度高于threshold的回复就返回, 否则就接人工服务. 此外, 如果语义解析模块找不到语义标签, 就直接转到聊天服务部分. 聊天服务部分参考上面提到的文章即可, 此处不再重复.

比起华丽复杂的模型组合和所谓sota的实验数字, 本文的系统设计虽然细节繁多但简单明晰, 模型朴实却效果惊人, 能感受到团队在研究用户需求用户数据上花费的精力, 衷心希望国内的研究团队能越来越强, 以及此类硬核的文章能早日取代鼓吹大数据人工智能的媒体营销号甚至个别科研团队....

发布于 2018-10-11