0
SuperScript 是一款开源的交互式会话引擎，它带有弱AI、自然语言理解、简单易用和灵活可扩展的特点。SuperScript 也是目前开源领域内最优秀的聊天机器人引擎之一，社区讨论活跃、模块构建合理，受到诸多自然语言处理相关开发者的追捧。
近日，雷锋网 AI 研习社有幸邀请到了呤呤英语 AI 技术负责人 Hain，他从代码实操的角度为我们详细介绍了 SuperScript 系统的设计与实现。
Hain，Rockq 开发者社区创始人，呤呤英语 AI 技术负责人，曾就职于 IBM 中国开发中心和创新中心。
Rockq 社区是 2015 年 5 月在北京建立的分享、学习型社区，主要面向 JavaScript 开发者，并拓展到机器学习和虚拟现实领域。本着“精益创新，竭尽分享”的精神，Rockq 已经举办过 30 余次不同内容的分享活动。呤呤英语是一家儿童英语在线教育服务公司，有面向儿童的国际化社交网络和高等专业的外教团队。从2016年开始，Hain 开始探索聊天机器人的商业机会，以及如何使用深度学习和 NLP 技术研发聊天机器人，目前已经推出了两款聊天机器人服务，帮助少儿学习英语。
以下为本次分享的完整视频（约 40 分钟）。
以下是文字版整理：
大家好，我是 Hain，今天我们分享一下关于会话交互系统 SuperScript 的设计与实现。
首先做一个简单的自我介绍，我曾在 IBM 中国开发中心和创新中心工作过四年，后来又创办了一个开发者社区 Rockq，现在在一家英语教育创业公司呤呤英语做 AI 技术负责人，同时也是一个开源爱好者。
这里是我的 Github 地址和主页截图，大家可以看到，左上角是 DeepQA2，使用深度学习训练的一个会话模型，右上角这个是用 Node.js 访问科大讯飞的语音识别的 API，其他还有用 Docker 的技术来做 ELK 的 Service 等。同时我也整理过一些问答的语料，因为大家都知道，使用机器学习训练问答系统的难点是特征提取，而特征提取的天花板其实是在于精确的语料。这里我通过整理 10 万个问答对，得到了 3000 个精确的问答语料。此外我还为一些聊天机器人平台写过 Node.js 的样例，以及做过 TensorFlow 相关的入门教程。
今天我们主要讲的内容是聊天机器人对话引擎，即通过 NLP 的技术去处理人机对话系统。
作为开发者，我们首先要考虑的问题是要做一个什么样的服务。根据我的观察，在 IT 领域大概每十年就会有一个大的改变，包括 1970 年代的主机系统，1980 年代以 Mac 为代表的个人电脑浪潮，以及 1990 年代的谷歌搜索为代表的互联网时代的到来，到 2000 年代以 iPhone 为代表的手机移动互联网的问世，还有 2010 年代微信的推出。我们就会猜想说下一个十年会出现一个怎样的服务，发生怎样的改变，让人们的生活更便捷。我觉得应该是人工智能。而在人工智能里，应该有一个杀手级的应用，我觉得这个应用是聊天机器人。
所以从去年 3 月初我就开始调研聊天机器人的相关技术，以及它能用在哪些行业，解决什么问题。我本人目前是在一家英语教育公司做面向儿童的英语教育机器人。实际上这两年涌现了一大批做聊天机器人的公司或者组织，其中大公司一般更偏向于做底层，做一些理论研究和平台化的服务，而其他小公司和创业公司则更多的是从应用层面出发，解决一些实际的问题。这里我介绍三种比较典型的面向聊天机器人开发者的平台级服务。
第一个是微软推出的 Botframework，它的主要特点是提供了一个跨平台的连接方案。因为我们可能会将聊天机器人的服务分发的许多不同的平台上，例如对接自己的 OA 系统，对接到 Telegram，对接到 facebook messager，或者是通过短信和邮件的形式与你的机器人进行对话。这个是 Botframework 提供的方案。
第二个是 API.AI，它是硅谷的一个创业公司，去年被谷歌收购，收购之后现在主要在做会话训练、会话管理，同时也接入了谷歌的语音识别方案。它在利用用户的数据进行机器学习的训练方面其实是一个非常领先的平台，但是由于一些众所周知的原因，访问它需要翻墙。其实我们也调研过使用 API.AI 的优缺点，发现它更像是一个做信息助手的平台，因为你上传了自己的信息之后，是由人工去做 intent 标记，然后派发 action。特别适合于做一些点餐的应用、打车的应用和问问天气等。这两年 API.AI 升级比较大的地方是不同知识域的会话，在你自己上传的数据之外，它可以给用户提供训练好的语言模型，比如一些打车的服务，直接可以在它的平台上调用。
第三个是 Telegram Bot Store，它其实是一个专门为开发好的聊天机器人分发服务的地方，在这个平台上可以找到一些非常优秀的聊天机器人，可惜还是要翻墙。我自己体验过的一个非常好的聊天机器人实际上也是在 Telegram 上找到的，而且这个机器人也给了我很大的启发。
今天我们主要关注的是上面这张图中 Logic 这一部分。可以看到，图中左边这个 STT 的主要功能是将语音转换成文字，然后通过 Logic 的服务对文字进行处理，TTS 这个部分是将文字转换成语音。目前这个 Logic 其实更像是一个弱 AI，它与大家想象中的人工智能其实还有一定的差距。
从一些公开的资料来看，现在大部分公司的语音助手的实现方案都如上图所示。STT 之后会经过一个 NLU 的模块，进行自然语言的理解。这里 NLP 一般是进行一些规范化的操作，比如识别一些专有名词和地名，把主谓宾等一些简单的语言结构分析出来，纠正一些常见的语法和拼写错误，把一些时态相关的词根分解出来等。NLU 之后会进入一个 DST 的部分，DST 的全称是 Dialog State Tracking，也就是聊天状态的跟踪。一般聊天机器人都会有自己的处理规则，而在这个会话进入系统之后，右侧的 Policy 会加入影响，来决定下一步在哪个地方进行处理。DST 处理之后会进入 NLG，也就是自然语言生成，就会生成一个新的语句，作为刚刚进来这句话的一个回复，传递给 TTS，生成对应的语音。
一般来说现在的 STT 和 TTS 都有一些很成熟的方案了。我尝试过一些 STT 的服务提供商，包括微软、IBM 和谷歌的服务等，国内的话尝试过科大讯飞的服务和云之声的服务等。基于这个对比的话，我认为谷歌是最准确的，但其实也要分具体的场景，比如普通话、英语还是粤语等，但总体上我认为谷歌的技术是最领先的。但由于防火墙和其他一些原因，其实综合考虑选择科大讯飞是比较合适的。而 TTS 我认为做的比较好的是 IBM 的服务。
刚才也提到了，整体上这套系统是一个弱的 AI，其实你也可以叫它“人工智障”。从长远的角度来看的话，它其实还需要一个长期的发展，让它变得更加智能。如果我们现在去体验一些已有的聊天机器人，包括微软的小冰和百度的度秘，你会发现其实很多的回答都是通过搜索引擎的搜索获得的，有的时候还会给我们返回多条记录，这一点其实非常不智能。
在公司里一般都会将上面提到的 NLU、DST 和 NLG 等部分再细分为好多模块，每个模块都有专门的团队负责维护。而像我们这些创业公司来说，一般都只有一些小的团队来做，没有足够的资源去细分这么多模块，因此我们就更偏向于去借助一些开源的项目。我们现在的实现方案是如下这张图。
从图中可以看到，最上面是一些微信小程序、微信公众号等一些即时的通信服务，然后下面是 Inbound Message，也就是用户发给聊天机器人的消息，然后再下面是 Bot Engine 即处理模块，这是我们今天要讲的重点。这个 Bot Engine 会负责分析这个语句，包括里面的概念和命名，而且它也有规则引擎，它会有一些 Trigger 和回复，开场白等。这些会被定义在 Topic 里面，也就是 Bot 可以跟用户交流的主题，这里主题又可以有许多类，比如打车、餐厅等。而整个 Bot Engine 还可以连接 Knowledge Graphics 做知识图谱，将来还可以在知识图谱里做更多智能化的查询和推理等。这里我们将 Bot 的知识分为三种类型，一种是 World Knowledge，即外部世界的知识，另一个是 User Knowledge，即用户跟 Bot 聊天结束后积累下来的知识，最后就是 Bot Knowledge，即 Bot 自己的知识。
整体上讲，Bot Engine 是一个承上启下的关系，它需要有一个非常灵活的解决方案。而且因为聊天机器人是一个集大成的服务，比如这个 Bot Engine 可能要连接到知识图谱的服务和搜索引擎等其他的服务，所以它是一个类似于中控一样的平台。当我们写的一些 Topic 没有命中用户想要聊的一些主题，也就是没有办法去回答一些问题的时候，我们就可以借助于深度学习。
深度学习是在这个图的最下面，叫做 Bot Model。Bot Model 其实是一个语言模型，我们通过算法和数据注入这个深度学习框架里，经过框架的运行，结果就会给我们输出一个模型。我们问模型一些问题，之后这个模型就会预测出这个回答可能是什么样的。实际上这里我们尝试过用 TensorFlow，使用了其中的 seq2seq 模型，加上我们自己的语料，结果发现效果还是不错的。所以我认为，在接下来的一段时间里，尝试去积累质量更高更多的语料，应该是接下来工作的重点，因为数据是特征提取的天花板，而特征提取是深度学习智能化程度的天花板。
现在关于用深度学习来做 Bot Model 的训练其实有非常多的算法，包括增强学习和生成对抗网络等。在我们这张图中，左边这条线的意思是说如果我们能在 Bot Engine 里面标注一些非常好的高质量的对话，那么就能进入我们训练好的模型，做一个增强学习。
整个图实际上就是我们现在正在努力实现的一个愿景。基于这张图我们其实做了许多关于 Bot Engine 的尝试，因为它实际上是一个相当于中控的地方。下面我们进入今天的正题，即如何实现一个 SuperScript 会话系统。
SuperScript 是 2014 年中旬左右由几个开源爱好者做的一个开源项目，当时它就提出来要做一个 conversational UI 的理念，它其实借鉴了之前的 RiveScript 和 ChatScript 这两个项目，另外它的主要作者贡献了许多在 Node.js 里面使用 NLP 的 package。这两年根据我自己的比较，SuperScript 在 Node.js 领域，或者在我调研对比的 200 多个聊天机器人的开源项目里，SuperScript 应该是做的最好的一个平台。SuperScript 的使用其实非常简单，在 Linux 平台使用 npm 命令安装之后，其实就可以嵌入代码使用了。
这里需要强调的是，SuperScript 其实不是一个研究性非常强的项目，它更偏向于去实现一个应用，它更是一个 development technology。
SuperScript 为用户开放的其实是非常简单的接口，当我们使用它的服务是这样的几行代码，就可以 setup 一个服务。比如说下图中的代码，我们在第一到第二行我们引用了 SuperScript 并声明了一个 Bot，然后在第三行对 SuperScript 进行了一些配置。在第七行我们得到了一个 botInstance，这个 botInstance 包含了两个核心的接口，一个是 reply，另一个是 directReply。当我们想和这个 Bot 对话时首先要传入用户的 ID，以及对话内容，然后就会通过 Reply 得到回复。而当我们有明确的想要聊的话题时，比如 hello 是属于 greetings 类别，这时就可以使用 directReply 接口，直接传入类别信息，然后取得回复。
下面是在 SuperScript 中生成 Topic 的过程，这里和之前的 RiveScript 和 ChatScript 其实是很相似的。图中展示的是通过脚本来生成对话，我个人在这里非常推荐这种方式。因为现在很多像 Botframework 这样的聊天机器人的平台，几乎都要求一定的编程能力，想要实现一个对话能力，就要写好多代码，而且还要调试，对开发者以外的人来说有一定难度。但是 SuperScript 采用的这种方式很简单，对开发者或者其他熟悉业务的人员来说都非常友好。
这里先要写一个 SS 文件，它有特殊的语法，使用前需要用自带的解析工具对文件进行编译，生成 data.json 文件。而这个 data.json 中就包括了会话中包括了哪些谈话、开场白和回复等。而在今年 1 月份发布的 SuperScript 最新版本 V1 当中，这个编译工具比上一个稳定版快了上百倍。这是因为它采用了一个全新的语法生成器。
简单地说，用 SuperScript 来写对话的语法主要有方式有上面这几点。第一个是定义一个 Gambit 作为开场，也就是下图中加号后面的部分，用户输入“i go by bus/train/car”中的任何一句，都会命中这条规则。
第二个也可以写一个正则表达式，例如下面的“hello *2”，表示如果用户输入 hello 后面再加一个两个单词的人名，也会命中这条规则。
第三个是在 Gambit 中定义两个字符串，然后在 Reply 中做回复。例如图中的“*1 is taller than *2”就定义了包括两个字符串的 Gambit，如果用户的输入符合这个 Gambit，则系统就会回复减号后面的那句话，其中 cap1 用 *1 代替，cap2 用 *2 代替。
另外 SuperScript 还支持多个回复，且系统会根据用户设置选择其中的一个回复。例如上图第四个例子，当用户多次输入符合 Hello 正则表达式的语句之后，系统就会保留 keep 后面的语句，在其他场景下再次发送 。
我们看一个聊天机器人的智能程度，主要是看它处理上下文和带有关联关系的对话的能力。SuperScript 在这方面也做了许多优化。如上图所示，Bot 问了一个问题说你叫什么名字，这时代码就会走到下面第 2 部分，根据用户回答的名字通过 % 符号又定义了一个新的规则，用来承接上面的问题，用户回答后才能进入下面的流程，即根据回答又问了 first name 是什么。如果说还要接着进行会话，则还可以根据上一次的回复为基础问更多的问题。比如这里问 first name 是不是刚刚的那个回复，回答如果是 yes，则回复 ok。而如果回复不是 yes，则会进入第 4 部分代码，返回重新开始对话的相关语句。
整个看起来，SuperScript 所支持的会话就是通过对应的 % 来找到对话中上下文的位置，然后进行对应的回复。这里需要强调的是，代码中的缩进并不影响执行，只是为了便于阅读。
下面讲一些更复杂的内容。在我们写 reply 的时候其实是可以加入一些复杂的句式的，也就是函数。比如调用外面的系统获取天气信息，那么就可以像下图这样采用角标加函数名的形式（getWeather函数）调用相关函数。具体函数的定义就如图中下面的部分所示，这里演示的是一些 JavaScript 的代码。在 SuperScript 启动的时候，用户可以选择 load 一些事先写好的 JavaScript 代码。相信大家也可以看到，这里展示的天气查询实际上是通过函数回调的方式处理的。
另外，在 SuperScript 中通过一条语句也能调用多个函数，例如“+ It is ^fun1 and ^fun2” 这条语句中，就同时调用了 fun1 和 fun2 两个函数。
同时 SuperScript 也支持嵌套函数的调用，如下图所示。
作为一个 Node.js 的环境，SuperScript 还支持导入各种 Node.js 的包和模型。另外，在书写一个 plugin 的时候，SuperScript 环境本身为函数提供了丰富的功能，如下图所示。我们可以用 this.message 应用用户所说的话，用 this.user 查询用户消息或者通话记录，用 this.user.memory 引用 SuperScript 内置的知识图谱图数据库等。
除了自己写函数之外，SuperScript 还内置了一些实现好的函数供开发者直接调用。例如下图所示的 topicRedirect 函数，用来在不同的 topic 之间灵活跳转。
下面讲一下知识图谱的部分。这里我们讲的知识图谱其实可以理解为我们为用户建立的一个画像，建立的用户和用户之间的关系。例如我们可以记录用户的大学专业、生日和喜欢的电影等个人信息，其实从数据结构来说很像是一个图，在聊天机器人里面得到了广泛使用，因为相对便于分析和查询。
从下面图中右侧的部分我们可以看到 SuperScript 中对知识图谱的使用。系统会为每个用户单独建立一个 memory，Bot 引擎也有自己的 memory，它们共同的参照是一个上文提到的 World Knowledge，即通用知识。而遍历、生成、查询和使用这些知识的过程，就会使用一些 plugin，例如上面提到的 this.user.memory 对应当前用户自己的 memory 空间，this.botfacts 表示 Bot 的空间等。这些空间的结构大约由三个部分组成：subject 名称，predict 关系，以及 object 实体。
讲完 SuperScript 的具体工作方式之后，我们下面讲一讲它底层具体是怎么实现的。通过分析源码我们发现，系统解析了脚本之后会生成 data.jason 文件，而 data.jason 文件其实是一个面向对象的模型。因为我们在编写脚本的时候其实思路是面向过程的，比如先说了什么，然后回复什么，然后又说了什么，等等。但是 SuperScript 在执行时其实是面向对象的，因此要首先解析成 data.jason。
如下图所示，首先我们是定义了一个 topic，topic 对应了很多属性，然后是开场 gambit，一个 topic 还会定义若干个开场，gambit 也有一些属性，例如 filter 和 trigger 等，filter 就是上文提到的 % 后面的部分，而 trigger 就是正则表达式一类的触发条件。一个开场 gambit 被命中以后，它会从内部包含的若干个 reply 里面的检索出条件最符合的发送出去，这里 reply 也包含了 filter 和 keep 等这些属性。而每个 reply 反过来又包含了若干个 gambit，系统不断地处于等待回复和下一个开场之间，这样一来就形成了会话。
另一个比较重要的内容是 ss-message，如下图所示，这里 ss-message 主要是处理了一些规范化输入、取词根、加入日期、判定问题和命名标识一类的操作。这些都得益于开源社区许多开发者所做的贡献，而底层则依赖于许多学术和社区提供的服务，例如 WordNet 和 ConceptNet 等。
到这里，Bot 虽然能根据用户的问题回复信息，但其实 Bot 回复的信息还是和自然语言有一定差距的，这里就需要有一个 Normalize 的过程。比如说，用户输入的是一个 emoji 表情，那么系统应该能识别出这个表情是微笑还是生气，这些功能都需要 Normalize。在 SuperScript 最新发布的 V1 版本中，最新发布了 bot-lang 这个模块，其实也是开源社区的支持。它的主要功能就是实现这里的 Normalize 的过程。
另外就是如何建立知识谱图了，SuperScript 内置使用的是 LevelDB 支持这部分功能，它的速度非常快。如下图所示，在 SuperScript 中主要通过 sfacts 模块来实现。sfacts 提供了创建 DB 和加载 DB 的方法，同时它也允许用户创建自己的 concept，创建自己的 DB 等一系列操作。
有时候我们需要在自己的聊天系统里创建 concept，例如商品的种类，当用户的输入匹配上某一种商品之后，我需要将流程导入到介绍相关产品或者下单的对话流程中去。而这些功能在工具里是没有的，需要我们自己实现。
在 SuperScript 里加载自己定义的 concept 可以分为如下图所示的三步。
第一步是创建一个 concept 文件，也就是声明一下名称和其中包含了哪些子类。
第二步是在通过解析工具生成 data.jason 文件的时候，需要引用第一步中声明的 concept 文件。
第三步是在启动 SuperScript 服务的时候要加载 concept 文件。
这就是加载自己定义的 concept 的过程。
另外一个 SuperScript 的核心，也是它与 RiveScript 和 ChatScript 等其他工具一个最大的不同，就是它实现了一种算法，即怎样从 topic 栈中获取答案的算法。如下图所示，算法的核心就是按照从左到右的语料库顺序依次排查，最左边的优先级最高，最右边的优先级最低。当收到用户的问话时，系统会首先在 pre 标签的 topic 中找寻 reply，如果没有找到，则系统会通过 last reply 中获取的当前聊天的会话，从当前会话中搜索 reply，如果还没有找到，则系统会通过 TF-IDF 在以往聊天历史中做一个词频排序查找，如果还是没有找到，则会跳到一些没有聊过的非系统 topic 中查找，最后，如果这些都没有找到，就会从 post 标签的 topic 中找寻。需要注意的是，这里 pre 和 post 标签都是系统规定的，但那内容需要用户自己实现。
在 SuperScript 最新发布的 V1 版本中，它的 get reply 接口要比之前的老版本快数十倍。除此之外，在 V1 版本中，还有其他一些重大变化，具体如下图所示。
首先是这个 FactSystem 以前用的是 LevelDB，它会在系统中产生一些 disk 文件，这个其实是不利于应用的，因为这个文件系统有写进程的锁，导致 SuperScript 只能是单实例的。但是在 V1 版本中，上层依然使用的是 LevelDB 的接口，但是下层它将数据都存储到了 MongoDB 里。这个过程就会让 SuperScript 相比过去有更好的延展性，在生产环境中这个意义是非常重大的。
第二个是开始支持多租户的形式，以前 SuperScript 只有单实例，同时也只有一个 personality，就只能跑一个服务。
第三个是新版本使用了 ES6，使用 babel 编译。这样让 SuperScript 兼容更多的新语言特性，同时也可能是许多接口速度大幅提升的原因。
作为国外的一个开源项目，其实 SuperScript 本身是不会考虑支持中文的。这一点对于我和其他关注 SuperScript 的国内开发者而言，是一个亟需解决的问题。
其实在 SuperScript 的社区讨论组里可以看到，相关的技术讨论还是非常活跃的，有很多人参与。虽然官方没有公布具体有哪些用户在使用 SuperScript，但通过官方讨论组可以看到它的用户目前有几百人。
随着未来聊天机器人的越来越流行，我相信 SuperScript 会越来越流行，越来越引起大家的关注。
最后在这里分享一个我自己做的网站：http://blog.chatbot.io/ 里面记录了一些我的工作总结，类似 SuperScript 这样的框架调研结果，以及关于深度学习算法层面的东西。
谢谢大家。
问题1：目前国内公司的交互会话系统和谷歌、微软等国外公司相比，差距有多大？
基于去年做的一些调研，国内的聊天机器人在客服、导购、老人小孩陪伴上都有尝试，偏应用层面，比如助理来也和出门问问，在聊了一些之后，甚至会转人工服务。而国内的大公司，前几年并没有发力，百度做了很多工作。我也关注今年腾讯的AI Lab也开始大量招并买马。相对国外来说，起步较晚。
而国内的开源领域和研究机构，也不比国外活跃。在硅谷涌现了一些新的服务比如dashbot.io, kitt.ai, qnamarker.ai,api.ai,在国内还没有看到特别好的copy。而且国外的开放语料比较丰富，由政府出面做了很多数据开放运动，包括dbpedia, wordnet, concept, imagenet都建立起来了。
做为一个开发聊天机器人的开发者，我觉得国外的工具比较多，国内还很欠缺，所以，我主要关注英语教育的聊天机器人。
问题2：能不能讲一下词库的设计思路？
我们还没有建设自己的词库，目前分词使用了开源领域的库，我们对于新词的识别还是次要的，因为是根据美国小学课程设立的会话内容。我们主要是处理chglish，目前也是通过常见的拼写错误识别方法和人工制作列表的方式进行。长远的角度来讲，我们希望积累到大量的数据，然后通过机器学习的方式来解决。
问题3：SuperScript 引擎的未来发展如何？
会对创业公司很有吸引力，包括集成Facebook Messager, Slack, Amazon Echo这样的IM和硬件，SuperScript是很灵活和有优势的，目前社区也相比其他对话引擎活跃，我觉得它会成为开源领域最流行的聊天机器人对话引擎。
问题4：人机对话中，可控性和智能型如何平衡？
我觉得现在开发机器人，主要由两个部分组成：基于规则的检索式的部分 + 基于机器学习的生成式的部分。而基于规则的部分，是开发者的可控性很强的，而基于机器学习的部分，得到的回复会超出人的解释范畴，带有数学的随机特点。在我们的对话中，更倾向于对话包含知识，因为是面向教育的，所以，基于检索的部分多一些，在基于检索的系统中得不到好的答案，在进入机器学习的语言模型获取答案。这样整体上，就可以回答用户的任何问题，而且效果看上去还不错。
所以，可控性带来更多的商业机会，比如个人信息助手，而智能型的可以带来更多的乐趣，比如闲聊解闷。而像api.ai这样的服务，通过人工标注 -> 意图识别 -> 派发行为这样的系统，是带有更多可控性的，可以作为开发个人信息助手的选择。而像tuling123的服务，是带有更多智能效果的，可以作为开发闲聊机器人的选择。当第三方的服务不能满足需求，或者自己的技术团队很棒的话，可以使用像SuperScript + Language Model这样的方式开发自己的聊天机器人。在调研了很多第三方服务之后，SuperScript 让我放弃了使用Botframework, TensorFlow让我放弃了使用api.ai.
问题5：像这种聊天机器人，体积通常较小，比较便携，感觉是不是可以在户外也使用，小朋友出门也想带着“朋友”一起出门的话，这一块有没有对应的应用场景分析过？
我见到过几款这样的智能硬件，外向像个蛋蛋，价格在七八百块，创业公司在做，360也在做，甚至做成手表，可以使用语音对话，它可以讲故事。其实里面就是运行android系统，加上应用。除了对话能体现出智能，其他部分没有技术壁垒。市场也很接受，我觉得挺好的，但是怎么提高更多价值呢？不能就卖硬件吧？我也思考过很多场景，我觉得这里的机会非常多。
比如面向由自闭症，孤寡老人，儿童，都会带来价值。但我觉得聊天机器人最好的入口还是VR或者AR。因为这样有更强的代入感，会作出用户更喜欢的产品。
我去年也体验了很多设备，Hololens、Rift、Vive、主动式，被动式的VR设备，玩过赛车、射击等游戏。我觉得像HoloLens这样的设备，搭载聊天机器人会成为划时代的产品，入口已经不愁了，主要是聊天机器人的智能程度。
问题6：虚拟机器人和实体机器人哪个更可能成为机器人的主流趋势？会有什么优势？
二者的性质不一样，我更相信实物机器人会取代工厂生产线上的工人，虚拟机器人会取代呼叫中心的客服。不论何种机器人，自然语言处理，对话和意图识别，都会让这些机器人更能按照人的意愿行事。
我觉得虚拟机器人的智能程度会更高一些，会更流行。因为虚拟机器人设定场景可能更便于机器人做判断。
问题7：目前聊天机器人在上下文联系问答上到底是个什么样的水平？
关于上下文关联，从算法层面，要考虑在语言模型训练时候，注入下面的数据：P - Personality matrix, U - User Relationship with Bot 以及 L - Lexicon。我也查找了相关的论文。这个处于前沿的探索阶段，我还不知道从算法层面上解决这些的成功案例。2015年, seq2seq 模型出现，而seq2seq的衍生模型，Seq2Seq attention/Seq2seqGAN 处理其实还是单论对话，训练长度也有限，语句长度越长，系统越难调。而从工程角度上看，开发技术一般是考虑建立bot的系统画像以及用户的画像，对话对上下文的分析也会限制在一个时间窗内。
比如SuperScript对上下文的分析就是开发者可以配置的，默认情况下，SuperScript在检索回复的时候，会考虑过去5分钟内，用户说的最近的10句话。
我觉得这里还需要融合更多的技术，比如建立知识图谱和搜索引擎，然后在superscript的上下文，有更多的查询能力。大家也可以去体验一下微软的小冰，google的allo和百度度秘。作为大厂的服务，这些应该具有说明意义。上下文关联，是一个很大的挑战。
雷锋网(公众号：雷锋网)相关阅读：
聊天机器人之热（一）：微软、Facebook、亚马逊等巨头为何押下重注
雷峰网原创文章，未经授权禁止转载。详情见转载须知。
专题
