阿里算法专家：一个面向开发者的智能对话平台

内容来源：2018 年 08 月 05 日，阿里巴巴算法专家唐呈光在“人工智能技术沙龙（杭州站）”进行《小蜜智能对话开发平台》演讲分享。IT 大咖说（微信id：itdakashuo）作为独家视频合作方，经主办方和讲者审阅授权发布。

阅读字数：2759 | 7分钟阅读

摘要

本次演讲围绕小蜜智能对话开发平台，讲述其诞生背景、产品定位以及具体的内部实践。

获取嘉宾演讲视频及PPT，扫一扫下方二维码即可。

背景介绍

人工客服

开篇我们先来看一组来自一位淘宝商家的统计数据，根据数据显示每年淡季他们客服人均日常接待为800到900，旺季会上升到1500到2000。

这种情况普遍存在于淘宝天猫的大型店铺中，并且除开已经在职的客服人员外，每逢双11、双12这样的大促活动时他们还需要再聘请一些外包的客服来应对大流量冲击。另外中国移动的客服规模也有过之而无不及，他们在全国大概有数万的客服坐席，人力成本相当巨大。

阿里巴巴为减少这种人力上的消耗，专门成立了智能服务事业部，希望通过数据与技术的驱动，让天下没有难做的服务。为了能够由内到外的全面赋能，小蜜家族正式诞生。发布于2015年的阿里小蜜主要用来解决阿里巴巴自身的客服问题；发布于2016年的店小蜜服务对象是淘宝天猫中的商家；发布于2017年的店小蜜负责为外部的企业机构政府解决客服服务问题。

要想实现从内到外的全面赋能，首先要有一个平台级别的产品，因为我们所面临的是各行各业的需求，无法针对每个行业的特性去再定制机器人。

我们的对话平台遵循了通用机器人架构，首先ASM会将用户的语音转化成文本输入到NLU，然后进入到对话管理的对话跟踪模块，接着往下到对话策略模块输出action，NLG会将action转成自然语言，最后通过TTS转化成语音传达给用户。

产品定位

小蜜智能对话开发平台主要面向开发者，用以解决任务类、助理类的多轮对话问题。

作为一款技术赋能型的产品，我们期望它能让开发者开箱即用，同时能够根据自身业务场景灵活定制，最后做到越用越好。基于这些我们又提出了3个基本的设计原则，分别是冷启动快、灵活定制、鲁棒进化。

技术实现

冷启动快

冷启动快的最终效果是实现平台做的越多，用户做的越少。因此平台内部内置了大量功能模块，比如实体、意图、函数、对话、卡片等等。就拿时间实体来说，我们会对它进行各种维度的拆分，从具体的时刻、日期、星期、到周期、时间段。

其中内置函数除开提供了通用外部接口的调用，还集成了和行业相关的函数，内置模板中包括和垂直行业中的客户一起共创的经典模板，同时还有一些模板的子图。

灵活定制之对话抽象

灵活定制的目标是将对话抽象成简洁的子元素，让开发者基于此构建自己的业务。我们现在可以将多人对话拆分成多轮单元，每一轮称作一个turn，它负责接收用户的输入，并作出回复。这个过程中还需要进行逻辑处理，也就是根据语义决定要应答的自然语言。

这3部分会被抽象成3个基础节点，分别是触发节点、函数节点、恢复节点。在他们之外还有一个特殊的填槽节点，里面主要是一些抽象出来的通用节点。

天气查询场景示例

对于天气查询这样的功能仅使用4个节点就能简单完成。Start是通用的入口节点，查天气对应Entry触发节点。slot-filing（填槽）是为了应对各种不同情况，因为有可能用户完整的说出了需要查询天气的地点、时间，也有可能只有时间没有地点，当检测到有些槽信息没有填充的时候，会通过不断反问获取到缺失的信息。信息收集完之后会调用外部API，需要在函数节点中填写自己的API。最后经由回复节点以自然语言的形式传达给用户。

灵活定制之函数编程

中国移动的话费查询是典型的函数编程应用场景。整个流程中首先会判断当前是否处于下账期，如果是就回复无法查询，不是就进行号码检测，判断该号码是否归属中国移动，在确认身份后依据是否停机来决定播报信息。函数在其中主要负责对话逻辑处理。

函数编程这块如果要自己去做，一般要搭建自己的服务器而且还要考虑运维、扩缩容、容灾等问题。对此我们是和阿里云函数计算进行合作，以应对大促期间的流量高峰，减轻自身负担。

鲁棒进化之意图识别

平台的算法积累很大程度上决定了该平台的易用性，因此我们在鲁棒进化中花费了大量的精力。一般开发者在使用这类产品的时候，首先会输入一些用户query，但是这些query毕竟有限泛用性不强。为此我们提供了基于规则的语法，类似于正则表达式，每个pattern对应多条语句，而且还能处理短句或更复杂的句式。

从规则到模型

规则依旧没有泛化的能力，因此小蜜平台集成了从规则到模型的扩展，通过解析器可以将规则转换成训练语料，根据语料的规模后台会自动选择不同的模型参数进行训练，以达到最优的结果。整个过程完全不需要用户参与。

迁移学习

目前我们面临的一个比较大的问题就是准确率和数据量正相关，而用户又很难一次性提供大量数据。之所以如此，是因为很多的机器学习模型对训练数据有最低的要求，一般的深度学习模型就需要上万条数据。

由于用户的数据会逐步增长，在不同的阶段对准确率的预期也不同，因此我们需要有一种渐进式的方式，针对不同阶段提供不同方法来达成当前目标，其核心思想在于如何有效的利用用户提供的数据。比如少量数据的时候使用比较基础的相似度模型，有几百条数据后应用迁移学习的方法，再进一步就可以使用传统的机器学习模型，同时还会根据数据量进行各种模型的对比和调参。

对话状态跟踪

对话状态跟踪在学术界是相当热门的研究领域，但是业界真正落地的实践并不多。

实际的业务场景中长句和短句是最常遇到的问题。长句由于包含太多的信息，会造成NLU无法完全理解，一般的应对方法是只输出Top 1结果，不过一旦判断错误接下来的流程会完全跑偏。另一种短句的问题在于语义表述不全，需要做一次澄清，进一步确认用户的意图。

针对这种问题，我们采用的是NBT的解决方式。当不太确定语义的时候，进行智能澄清，去再次询问用户已获得更多信息。

对话状态跟踪还需要辅以最优的对话策略，比如澄清的时机，提出的选项的数量等，这些很难通过规则枚举来完成，而数据驱动的方式最为合适。我们期望充分利用用户标注的数据来训练模型，具体实践分为两步，首先通过监督学习得到预训练模型，然后再通过强化学习进一步调优。

以上为今天的分享内容，谢谢大家！

IT大咖说 | 关于版权

本文由“IT大咖说（ID：itdakashuo）”原创，转载时请注明作者、出处及微信公众号。投稿、约稿、转载请加微信：ITDKS10（备注：投稿），茉莉小姐姐会及时与您联系！

感谢您对IT大咖说的热心支持！