句子互動 | 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