雷鋒網按：本文作者王海良，呤呤英語開發(fā)總監(jiān)，北京JavaScript／Node.js開發(fā)者社區(qū)的運營者，曾就職IBM創(chuàng)新中心。本文為系列文章第一篇，由雷鋒網獨家首發(fā)，轉載請聯系授權。

目前機器學習，尤其是深度學習，已經成功的解決了圖像識別的問題。從IMAGENET大賽的近幾年成績看，識別類問題準確度已經接近100%。

與此同時，機器學習在解決“語音到文字”(Speech to Text)以及“文字到語音”(Text to Speech)方面也有了飛躍。

而一群更加瘋狂的人在嘗試用機器學習解決自然語音理解，甚至在自然語言理解的基礎上，開發(fā)聊天機器人。

通過這三個服務, 就可以構建聊天機器人并且發(fā)布上線。

• Step 1 - 在Telegram上注冊賬號

通過 BotFather創(chuàng)建Bot。

• Step 2 - 在Botframework上注冊賬號

創(chuàng)建一個Bot, 同時下載Botframework提供的SDK／Sample( Node.js|C#)，連接到Telegram。

基于Botframework的對話，要寫很多代碼實現，這樣我們更需要一個連接到已經提供一些對話的服務上。

• Step 3 - 接入 API.AI

API.AI可以提供標注對話，開放域對話和語音識別，意圖識別等功能。

• Step 4 - 服務發(fā)布

Telegram是一個神奇的IM，它提供了聊天機器人應用商店。使用Telegram IM的用戶可以快速體驗和使用這些Bot。

一些Bot的體驗真的很棒，尤其是使用了人工智能技術的Bot，以至于會出現下面的評論。

還有其他聊天機器人的玩家：wit.ai, Chatfuel, Facebook Messager, Apple Siri, 騰訊機器人平臺, Microsoft LUIS.AI, etc.

不管是像微軟這樣的大公司，還是像Operator在垂直領域提供服務的創(chuàng)業(yè)公司，都將聊天機器人看成是下一代人機交互的服務形態(tài)，聊天機器人不單純的提供了一個新的服務渠道，它還改變了服務本身，即通過歷史數據訓練Language Model，來部分取代人的作用，聊天機器人對信息的組織和處理能力，在搜索引擎基礎上，又往前邁了一大步。比如，京東JIMI依靠DeepQA系統(tǒng)，實現“最強大腦”，JIMI就是聊天機器人的一個形態(tài)。

聊天機器人模型分類

基于檢索的模型

回答是提前定義的，使用規(guī)則引擎、正則匹配或者深度學習訓練好的分類器從數據庫中挑選一個最佳的回復。

基于生成的模型

不依賴于提前定義的回答，但是在訓練的過程中，需要大量的語料，語料包含了context和response 。當下流行使用LSTM和 RNN訓練生成的模型，這種方法最早用來完成機器翻譯的任務 - Sequence to Sequence Learning with Neural Networks。

目前，在生產環(huán)境下，提供聊天服務的，一般都是基于檢索的模型，而Seq2Seq的出現，有可能使基于生成的模型成為主流，因為Seq2Seq在長對話的情況下，依然可以表現的很好。

長對話和短對話

長對話需要考慮的因素更多，就像目前API.AI提供的服務中，要完成一個任務，比如預定酒店。

小明: 幫我訂今天晚上，上海浦東香格里拉酒店。

這時，API.AI得到了時間，地點和人員。它可能正好檢索到了我們在訂酒店故事里的一條被標注的記錄。Intent, Entity確定了， Action就被確定了。

可是，如果是下面：

小明: 幫我訂今天晚上，上海的酒店。

Chatbot就要詢問：

Bot: 你需要訂哪家酒店？

長對話，其實就是能在用戶場景下對話，要識別場景，就需要考慮時間、地點、剛剛用戶都說了什么，以及用戶和Bot的關系。

"訂酒店"屬于個人助理類服務，目前，api.ai已經支持了這種“追問用戶更多信息”的功能，屬于簡單的問題。

而類似于客服機器人，更多情況是多問題-多交織的對話，就是長對話中，很難解決的問題。

所以，當下，大量機器人是面向短對話的。比如，微軟小冰，小娜，圖靈機器人, etc.

開放領域和封閉領域

這兩個主要從話題層面進行區(qū)分。在開放語境下，用戶可以和聊天機器人聊任何話題。在封閉語境下，只能聊機器人設定的主題。

這主要取決于數據：有什么數據，就能聊什么主題。

比如在車載系統(tǒng)中，對話的機器人一般都是十個左右的意圖，圍繞意圖進行訓練聊天主題。

老司機一般都聊什么？

• 服務區(qū)還有多遠？

• 我買的股票怎么樣？

• 播放一個音樂

• 聽交通臺

• 呼叫一個電話

• ...

挑戰(zhàn)

關聯上下文

關聯上下文，就需要在設計機器人的時候，給它一個問題，獲得一個回復。生成回復的時候，要考慮 P, U, L.

• P - Personality matrix

• U - User Relationship with Bot

• L - Lexicon

這需要在訓練LSTM Net的時候，要將更多信息注入，而且也更像是將基于檢索的模型和基于生成的模式混合起來完成。

意圖識別

就像API.AI， 及其WIT.AI, LUIS.AI們構想的一樣，要完成有效的對話，先要搞清楚用戶在表達什么意圖。但是目前API.AI們提供的方案需要人工標注Entity和Intent，這種工作很繁瑣，效率低。

能通過歷史數據，無監(jiān)督或者半監(jiān)督的完成意圖的分類模型是亟須解決的一個挑戰(zhàn)。

如何判斷一個模型的好壞

在使用LSTM訓練基于生成的模型的過程中，一個很大的挑戰(zhàn)就是沒有自動化的量化的標準：除了人工的和模型對話意外，不確定模型間的好壞。

這個問題的解決辦法，應該是在訓練時，就同時訓練正確的回答和錯誤的回答，然后使用recall@k機制驗證。

一種設想

在經過了很多調研和嘗試后，一種比較Smart的機器人的實現方案可能是下面這個樣子：

• 從社交網絡上對接到服務需要走InboundMessage, 從OutboundMessage中異步獲取回復。

• Bot Engine 處理session, context, personality，知識圖譜，對話規(guī)則和主題。

對話主題是基于人工經驗制作的。除了包括引導用戶做自我介紹類的"系統(tǒng)對話"，還要包括實現業(yè)務價值的"服務對話"，比如“學習英語單詞”，還要有“日常對話”，比如打招呼，詢問最近看的電影等生活場景。

• Bot Engine不能做到回復所有問題，因為基于規(guī)則的原因，能覆蓋的聊天內容范圍小，當在Bot Engine中，得不到好的答案或者沒有命中一個規(guī)則時，就請求背后的Bot Model.

Bot Model是通過深度神經網絡訓練而來，可以回答任何問題。

• 在對話服務過程中，會產生新的數據，使用強化學習，給Bot Model正向的激勵。

• 使用知識圖譜記錄Bot，User, World三層知識。

作為這個系列文章的第一篇，主要是介紹聊天機器人目前發(fā)展的狀況和分類，在后面幾篇中，將對上圖所設想的方案做更多描述。

最后

歡迎聯系我，尤其是業(yè)內人士，給予指正，一起優(yōu)化。

雷峰網特約稿件，未經授權禁止轉載。詳情見轉載須知。