阿里小蜜新一代智能对话开发平台技术解析_语言 & 开发_DataFunTalk



 写点什么

1. 为什么做平台

首先给大家举个例子：

机器人：您好，这里是 114 移车热线，您的车挡住了出行，请您移下车好吗？

车主：哦，哪个车子啊？

机器人：车牌是浙 A，尾号是 29，请问是您的车吗？

车主：啊，什么情况？

机器人：这手机登记的是您的号码，您能去看一下吗？

车主：什么号码，我，你再说一遍

机器人：车牌是浙 A，尾号是 29，请问是您的车吗？

车主：哦，是我的，我打个电话

机器人：那请您移一下车好吗？

车主：嗯

这是一个政务场景上 114 移车的 case，这个场景是用我们“对话工厂”开发的机器人实现的。114 移车 case 只是一个我们真实生活中很小的一个点，还有很多的业务是需要对话机器人来帮助人类解决各种各样的问题，或者减少人类客服成本。比如说在政务的其他领域，我们希望机器人能帮助人来查社保、查医保、查公积金等；在电商领域，我们希望机器人能帮助做售后的客服，帮助消费者来开发票、催发货、查物流等；在电信领域，我们希望机器人能引导用户查话费、查流量等。

但是创造一个对话机器人的门槛是非常高的，做一个 demo 很简单，但能解决实际问题的机器人很难。假设我们把开发对话机器人的整个过程称为一个完整的生命周期，在每一步都会遇到很多困难，在开发阶段，冷启动很困难，根本不知道用户的真实表述会是什么样的，假设有了话术后，自然语言理解和对话管理也很难，用户可能根本不按预设的方式进行表述，方式千变万化，普通方式无法理解。在调试测试阶段，也面临着调试对话难、测试覆盖难和人工评测难的问题，是一件繁琐、费时费力的工作。在发布阶段，版本控制，代码回滚，线上部署也需要考虑怎么做到自动化和一键化。到了闭环阶段，线上状态监控、可视化数据分析、数据自动标注，机器人持续优化迭代也是一个难题。所以在整个生命周期中，如果以一个独立开发者的身份来做对话机器人是一件很难的事情，门槛很高。

基于以上两点：

1、需要对话机器人的业务很多；

2、独立开发者的开发成本又很高。

我们就想做一套平台产品来赋能开发者。如果我们做一个平台能够提供一些非常易于操作的开发工具，有丰富的内置能力，有强大的 AI 算法能力，以及全生命周期的配套工具，那么我们这些独立的开发者或者企业就能够做到零代码开发，快速交付具有鲁棒对话的机器人，并且该机器人可以在线上进行持续迭代优化。

平台的好处

基于这样的想法，我们打造了对话工厂（Dialog Studio）这个产品，属于小蜜机器人解决方案中的一个核心基础能力，我们已经嵌入到小蜜家族（阿里小蜜，店小蜜，钉钉小蜜，云小蜜等）的各个平台中，支持了包括阿里电商，电信，政务，金融，教育等领域的各个场景的对话机器人业务。这就是我们为什么要做一个平台型对话机器人产品的初衷。

2. “新一代”对话开发平台

我们把这个平台定义为“新一代”对话开发平台，为啥叫“新一代”，到底它新在哪。我们大概总结了三点：

第一个是新的设计思路：将原来以 Intent 为中心的设计思路转变为以 Dialog 为中心的设计思路。

第二个是新的开发模式：从原先表单开发方式转变为可视化拖拽式开发。

第三个是 End-to-End AI-Powered：从原来只提供单点的 NLU、DM 模型 AI 赋能方式转变为 End-to-End AI-Powered 平台，在整个生命周期的各个阶段都会用 AI 来赋能开发者。

下面针对这三点进行具体介绍：

2.1 从 Intent 为中心到以 Dialog 为中心

以 Intent 为中心的方式每次要创建单个的意图，如果遇到一个复杂场景，需要创建很多个意图堆积在一起，每次开发只能看到当前正在创建的意图，因为该技术起源于原来的 Slot Filling 方式，只能解决简单的，Slot Filling 这种任务形式对话，任务场景比较受限。而以 Dialog 为中心的设计思路，把人机对话过程通过图的方式展现出来，对话步骤用图上的节点进行抽象，开发者在设计对话流的时候，这种方式能提供一个全局的视野，而且图的节点抽象比较底层，可以进行各种任务的配置，适用场景比较广泛。

从以 Intent 为中心到以 Dialog 为中心

接下来我们具体介绍下对这些对话怎么抽象出图和节点的概念，可以从简单的一轮对话场景来说，一般的情况下一个人和机器的对话场景可能是人说一句话，机器说一句话。在这个例子当中，人问机器人：我还有几天年假，然后机器人回复：亲，您今年的年假还剩 5 天，等等。这一轮对话可以抽象成两个元素，一个元素叫用户说，一个元素叫机器人说。但是在好多产品中，用户的答案不是简单的静态答案，直接能回答的，需要机器人有一个思考过程，会进行一些逻辑的判断，比如说查看服务，做一些逻辑分支判断，这个时候我们在前面两个元素基础上增加一个逻辑运算元素，把这三个元素抽象定义为“对话工厂”画布上三种节点类型，分别为“触发节点”、“函数节点”和“回复节点”，从代码的角度来看就是“if”、“then”和“return”。所以整个抽象过程就是用这三类节点，一生二，二生三，三生万千对话，可以配置出各种业务场景，可以是简单的线性场景和复杂的、带各种分支的场景。把这种由节点定义的图称为 TaskFlow，它定义了一个对话机器人的所有任务。

重新对 Dialog 进行抽象

2.2 从表单式开发到可视化拖拽式开发

在开发模式上将原来的表单式开发方式变成了可视化拖拽式开发方式。原来表单式开发方式以 Intent 为中心，所以对于开发者来说更像做一道一道表单填空题，只能单点控制，整个对话流程非常不直观，所有 Intent 压缩在一个表单，填写复杂。在可视化拖拽方式中，整个对话流过程的每一个节点都可以通过简单拖拽方式进行完整描述，拥有全局视野，整体可控。

从表单式开发到可视化拖拽式开发

2.3 从单点模型到全生命周期 AI-Powered

第三点是从原来单点 NLU、DM 模型到全生命周期 AI-Powered，在对话机器人开发的各个阶段都利用了 AI 算法能力赋能开发者，加速开发过程和降低开发成本。在设计阶段尝试了半自动对话流设计辅助，让开发者从冷启动阶段就能够设置出第一版的对话流。在对话流的构建阶段，我们推出了智能荐句功能，也就是说在编写用户话术的时候，机器人可以进行话术推荐和联想。在测试阶段，我们推出了机器人诊断机器人功能，可以大大减少测试的工作量，增速测试过程。在在线服务阶段，会有全套的 AI-Powered 对话引擎，包括 NLU、DM 等算法。在数据回流阶段，通过 Active Learning 将日志数据进行自动标注，用于后续模型迭代训练。在持续学习阶段，我们构建了一套完整自动模型训练、评测、发布 Pipeline，自动提升线上机器人效果。

End-to-End AI-powered 平台

3. “一站式”对话开发平台

接下来我们聊一聊为什么叫“一站式”对话开发平台，因为我们是对对话机器人开发的整个生命周期进行赋能，不是单点开发过程。在“一站式”的对话平台我们提供了哪些能力来赋能开发者呢？假设把开发对话机器人的完整生命周期简化为以下几个阶段，首先需要学习相关知识；然后基于一定的知识储备在平台上设计构建机器人；接着对机器人测试和调试；然后就可以将其在线发布，提供对话服务；Serving 过程中可以对线上数据进行可视化分析；同时可以通过数据回流划分 bad case 和 good case，进行线上持续学习迭代。

开发对话机器人的完整生命周期

在上面几个阶段我们都提供了强有力的辅助和能力对开发者赋能。在设计构建阶段提供了 AI 智能荐句能力，用户只需要输入种子话术，平台就会自动推荐相似问法，能节省人工造句和打字时间。

构建对话流动态图时只需要拖拽式操作，在画布中将节点和边连在一起，可视化编程，对话逻辑一目了然，且条件分支简单配置，可以根据业务灵活定制。在该阶段通过服务注册中心的方式也解耦了开发者和设计者，开发者将服务注册到中心，设计者从中心发现并使用服务，他们基于商定好的协议沟通，开发和设计可以并行工作，使对话设计者可以做到完全不写一行代码，开发者专注于功能服务开发。

设计构建阶段：AI 辅助加速开发

设计构建阶段：拖拽式操作

设计构建阶段：Code Free 开发

在对话流测试阶段，平台能自动的对节点、分支和连线进行合法性校验，类似 coding 时 IDE 做的语法检查和静态编译检查，可以一键定位静态问题位置。在动态测试时，可以使用机器人诊断机器人，智能构建测试 case，全自动批量测试，最多可以同时跑几千个 case，并可以在几秒内完成，并生成测试报告一键定位动态问题进行修复。在遇到线上 bug 时，可以利用平台提供的链路排查工具，在这个工具里，只需要输入用户当时的话术、SessionId 或时间范围，会以 Stack Trace 的方式把错误呈现出来，比如某个节点的输入输出是啥，是否报错，可以一键定位问题节点。