句子互动 | The Bad Part of My Chatbot Experience

做者：Li Ming (李明)

毛豆网创始人CEO，清华大学计算机硕士。曾与2003年创立嵌入式操做系统培训公司亚嵌科技。毛豆网致力于为内容创业者提供技术支持服务，关注Chatbot和微信小程序的结合与互动，并在微信群中基于NLP技术为用户提供流畅体验。已获清华XLab/DNA基金数百万天使投资。

Bot Friday - 沙龙第2场分享

The Bad Part of My Chatbot Experience

2019-07-26 于北京腾讯，limingth

NLP技术到底哪家强

需求背景

从一句话中识别出时间，主题和地点，这是咱们正在作的项目毛豆课堂中衍生出的一个需求，经过添加毛豆课堂小助手为微信好友后，发送一句话能够经过这个 chatbot 来建立一个课程提醒。

本来这应该是作 Chatbot 项目要用到 NLP 中最多见的一个需求，特别是时间，如何可以快速获得最符合文本中人类意图的时间。但找了一圈能够识别时间的NLP，却没有发现真正可以符合咱们需求的解决方案。

常看法决方案的不足表如今：

识别出了时间实体所包含的分词，但却没有转换为时间变量，没法在程序中使用。例如讯飞和百度的开放平台。

有的虽然能转化为时间变量，但返回的倒是json格式的多项复杂结果，还须要继续写代码作筛选和取舍。例如微软提供的NLP库。

其余存在的问题，表如今大量采用了正则匹配，而忽略了上下文的语义分析。例如把9号楼（地点）识别为9号（时间）。

做为非NLP领域的技术人员，只为了在工程应用里加入一个时间识别功能，却不得不花费好几天研究各家的NLP接口和返回结果，是很是低效的一件事情，所以不禁发出了 “NLP技术到底哪家强？” 的感慨。

如下是我对这个过程的一点总结，但愿可以对后来者有所借鉴。

AI开放平台调研

通过研究和测试，发现各大AI平台提供的接口，都是词法分析的结果为核心，返回各个实体的文本字段。真正对于工程有价值的，应该不是一个文本，而是一个 Date 变量，所以就没有采用这方面的接口。

讯飞开放平台

词法分析: www.xfyun.cn/services/le…

关键字提取: www.xfyun.cn/services/ke…

百度开放平台

词法分析: ai.baidu.com/tech/nlp_ba…

实际使用的库和效果

通过比对和验证，最后实际使用的库是微软的 recognizers，用来实现从一句话中获取时间，还有玻森的BosonNLP，用来获取主题和地点。只不过这两家给出的结果，都是带有数组结构的 json，还须要加上很多的 if-else 才能筛选出合适的指望结果。

这也是目前咱们认为还很不满意的地方，实现的源码我放在了这里。但愿看过这篇博客，能给出更好解决方案的人和我联系。（个人微信号 limingth）

@microsoft/recognizers

npm安装包：www.npmjs.com/package/@mi…

recognizers 给出的返回值：

BosonNLP

命名实体识别：docs.bosonnlp.com/ner.html

npm安装包：www.npmjs.com/package/bos…

BosonNLP 给出的返回值：

Time-NLP

代码库：github.com/shinyke/Tim…

npm安装包：github.com/JohnnieFuck…

虽然最终咱们没有采用 chi-time-nlp，本来已经调通的代码后来注释了，但我仍是想借这个例子，说明一下我认为理想中的API是什么样子。这是我最先调试跑通的库，也是最快能解决问题的一个方案，惋惜原做者已经不维护了，不过它仍然有以下这样的示范价值。

理想中的API是这样的

搜索排在首页

接口和返回值简单清晰

无需注册Key/Token

自带测试调用范例代码

部署一个Demo网页

这方面能够参考讯飞开放平台的Demo页面。

开放问题讨论

“有一天微信SDK开放了 wechat.say() 怎么办”

Wechaty这个项目之因此会存在，是由于微信没有开放底层聊天协议，但实际上目前除了微信，已经有不少开放平台，例现在日头条推出的飞书平台，已经提供了全套机器人发送消息API。 若是微信也推出SDK，能够实现相似咱们的 bot.say()，这样的话，Wechaty的使用价值，包括在此之上构建的 Bot App 都会面临着大厦将倾的危机。虽然@卓桓表示咱们彻底能够加入一个新的 wechaty-puppet-xxx 来对接微信本身的接口，从而保障以前的应用能够不受影响，但这真的能够长久吗？我比较担忧，有一天新生代的程序员会不知道Wechay的存在。

“像统一小程序开发同样统一chatbot”

由上面这个问题继续引起思考，提供 say() 接口的聊天机器人平台愈来愈多，一样的一个 chatbot 业务逻辑可能会面临着须要移植到各个平台上的工做。就像如今搞定了微信小程序以后，还须要写支付宝小程序、百度小程序、qq小程序等，终于滴滴的研发同窗推出了跨端解决方案 chameleon项目 一统江湖，让一套代码能够运行多端。 基于 Wechaty 开发的 chatbot 将来有不少，并且很快除了微信平台你们也会须要一个维护一套代码就能够构建多个平台入口的解决方案。这个需求咱们不妨把它称做 chateleon（取自 chatbot + chameleon）。这个聚合各大平台机器人聊天接口的中间抽象层，和 wechaty-puppet 层有些相似，将来承载着能够接入更多底层的聊天平台支持，从而有一天能够在这个基础上，长出一个像 BotHub 这样的开发者社区。

“给Chatbot开发作一套最好的智能AI接口吧”

接着刚才上面的想法，BotHub 上构建的 chatbot 从业务上可能都须要一套 AI 智能接口，解决像 maodou-bot 同样相似的获取时间需求，包括词法分析和语义分析等等，若是每一个开发 bot 业务逻辑的工程师，都要花费大量时间去评估底层 AI 接口的能力，这也将是重复找轮子的工做。 有没有一个专一于聊天场景的 AI 接口服务，提供绝大部分常见的 AI 接口，咱们姑且给它取名 chaty.ai，能够帮助咱们实现一个最好的 parseTime() 接口，咱们只须要调用它去实现上层业务逻辑，而它只专一于寻找或者实现最好的AI算法来解决咱们须要的接口问题。

最后一张图，描绘一下我理想中的大同世界。That’s what I call Future of Chatbot Friday :-O