從開發框架到後端AI服務，一篇文章全面分析現有聊天機器人API

譯者 | 大愚若智

編輯 | Natalie

AI 前線導讀：本文歸納介紹了聊天機器人的發展和應用趨勢，並從開發框架、平臺、後端 AI 服務等方面爲但願着手此類開發的開發者提供了很是全面的建議和思路。

更多優質內容請關注微信公衆號「AI 前線」，（ID：ai-front）

聊天機器人：目前發展得如何？

人工智能正在崛起！雖然機器還不至於在遙遠的將來反抗本身的創造者——人類，但做爲一個飛速發展的趨勢，信息技術領域對基於機器的預測和決策等應用已經愈來愈廣泛。圍繞 AI 的炒做無處不在：無人駕駛汽車、智能圖像處理（例如 Prisma），還有通訊領域的各類新穎應用，例如對話式 AI，即聊天機器人（Chatbot）。

聊天機器人這個行業正在飛速擴展，但相關技術依然還很年幼。對話式機器人的應用目前依然比較虛幻，有些相似於文字模式的老派遊戲「I smell a Wumpus」，但目前該技術已經逐漸發展成爲一個重要的商務工具。聊天機器人提供了一種更加簡單友好的全新接口，很是適合用於瀏覽信息和接收服務。IT 專家以及包括 Google、微軟、Facebook 在內的行業巨頭均認爲該技術會在將來扮演重要的角色。

爲了發揮對話式人工智能工具（或者若是你嫌名字太長，也可將其稱之爲「聊天機器人」）的巨大潛力，咱們必須首先掌握一些基礎信息並理解其相應的技術棧。本文將探討可用於從事相關開發的各種技術，各類技術間的類似與不一樣之處，以及各自的優劣。

但在開始進一步介紹以前，首先來深刻了解一下聊天機器人以及它們的技術拓撲。

爲什麼、如何以及什麼時候使用聊天機器人？

面對不一樣的業務任務，目前已經有各類各樣的聊天機器人，從廣告宣傳到團隊構建不一而足，但這些機器人一般都有一些共通的核心功能。

我的助理機器人

業務事務一般離不開專業的組織性協助，但不是全部人都有足夠的預算請祕書來處理各類基本任務。好在聊天機器人能夠提供幫助。經過妥善的編程，它們能夠追蹤咱們的工做安排計劃，針對即將進行的活動發出提醒。此類機器人比較實用，由於基於功能來看很是簡單，而且可使用各類很是快速的通訊平臺，例如用消息系統做爲本身的接口。

客戶支持機器人

聊天機器人還有可能從事更復雜的任務，例如表明企業與真實客戶創建聯繫。哪怕對人類員工來講，客戶支持工做流程大部分都是可預測而且能夠實現腳本化的，所以很容易以機器人的方式實現。此時可經過典型的機器人行爲算法接受用戶查詢，解析並得到相關信息，在數據庫中找出相似案例，而後經過預設答案作出迴應。

團隊協做機器人

經過機器人爲開發者團隊提供支持，這種作法目前極爲流行，而緣由有不少。這種機器人可與開發環境無縫融合，藉此持續關注並審視軟件工程師有關軟件質量等目標的不一樣需求。然而這類機器人只能解決各類很是具體的任務，所以這種狀況下並不須要用到極爲複雜的商用機器人。這類機器人一般以某種很是簡單的「記分員」爲主，此外還包括有感知的聊天機器人，它們能夠爲開發服務器提供必要的支撐，並針對信息的提交、簡單的工做安排建立報表。

出版商 / 新聞機器人

出版商類型的機器人能夠天天不斷收集各類感興趣的信息。不少大型新聞機構（WSJ、NYT）以及技術類媒體（TechCrunch、MIT Technology Review）都會經過諸如 Facebook Messenger 等重要平臺，以簡要文字信息這種便利的方式分享內容。這種機器人背後的原理很簡單：從用戶處收集訂閱信息，安排相關新聞的交付操做，而後處理與用戶有關的其餘請求（例如退訂、更改所訂閱的話題、隨意瀏覽等）。

娛樂機器人

娛樂機器人目前不怎麼常見，而且用途較爲特殊：例如經過對話風格的工做流程管理賽事 / 電影 / 戲劇門票的預訂工做。一些機器人還能夠經過文字消息爲娛樂網站提供全面的沉浸式體驗。例如 Fandango Facebook Bot 可供用戶觀看新電影的預告片，閱讀影評，查找附近的電影院。很棒吧！

旅遊機器人

另外還有一種很是流行，而且應用範圍正在飛速增加的機器人：旅遊輔助機器人。經過使用這種面向客戶的聊天機器人，能夠幫助用戶完成一些本來很繁瑣的任務，例如選擇最佳出行方式，藉此將一些本來很是冗繁的流程轉變爲聊天應用中輕鬆隨意的對話。旅遊機器人不只能夠獲取並確認預訂信息，並且能夠針對重要時間向用戶發出通知，例如開始辦票了、開始登機了、航班狀態有變化了，此外還能從客戶處收集各類有價值的反饋。

聊天機器人已成全新用戶接口：機器人的最新願景

雖然不管怎麼說，聊天機器人也只是程序，只不過按照設計能夠經過傳統的對話方式，用文字形式（聊天平臺）與人類用戶進行交流。它會等待用戶說些什麼，而後按照程序安排做答。所以目前的聊天機器人，其本質都是一種很簡單的算法：接受並理解輸入的內容，提供相關回應做爲輸出結果。

然而實際上聊天機器人遠比上文說的複雜，由於它們能夠掌控上下文情境的力量，這個情境多是局部的（例如只適用於一次對話）或者全局的（例如可在屢次對話中續存，並能涵蓋語言語境以外的領域，如預訂披薩的機器人能夠處理用戶的最新訂單、位置、時區等信息）。雖然前一種作法一般可使用 Cookie、會話等臨時記憶實現，但後者須要將信息存儲在數據庫內，或經過 API 的方式訪問其餘內部服務獲取。

在介紹了上下文情境的概念後，還須要簡要說起 Web 應用程序相關的一些術語（例如 Cookie、會話、數據庫），這樣才能組成一個完整的聊天機器人。聊天機器人須要與 Web 應用共享不少信息，而 Web 應用主要負責提供在線瀏覽的網頁（一樣須要接收請求並作出響應，因此會共用數據庫等標準工具）。所以嚴格來講，聊天機器人也是一種 Web 應用。

因此說，對於各種信息和服務來講，聊天機器人實際上也是一種新類型的接口。這種接口很緊湊，能夠輕鬆地訪問，而且很是簡單。藉此你的服務也能夠從本來的居所（你的網站）進一步擴展至各類平臺，無需向用戶宣傳或營銷便可隨時訪問（之前的機制爲：用戶在聊天信息中看到廣告，點擊連接訪問廣告網頁，而後訂購產品；如今的機制變成了：用戶在聊天信息中看到廣告，直接經過對話訂購產品）。

聊天機器人如何理解各類任務？

聊天機器人的內部原理看似簡單，但實際上並不那麼容易實現。

機器人首先必須理解用戶說了什麼。實現方法有不少：能夠對用戶輸入內容進行模式匹配，或使用天然語言處理（NLP）技術對用戶意圖進行分類。前者很是簡單直觀，但隨着所輸入內容的範圍和規模逐漸擴大，維護難度會大幅增長。後者可經過機器學習技術解讀所輸入的內容，可是實現難度較大（至少在不使用已經應用相關技術的平臺前提下會很難）。爲了對各類可能的意圖進行分類，並從各類可能中肯定特定輸入的實際目的，必須準備一系列樣本。

好在有不少平臺已經實現了這樣的邏輯，咱們不須要再考慮這些問題，能夠直接使用它們提供的服務。然而咱們依然須要熟悉主要的 NLP 分類及其本質：

• 實體（Entity） 是指人類談話（口頭或書面）中，天然語言所包含的文字組合，與標準化解析後所表明的用戶隱含意圖之間的一種特殊映射關係。這有些相似於提取的變量，例如 DateTime 若是指定爲「聖誕節」，那麼可能就意味着「2017 年 12 月 25 日」。

• 意圖（Intent）, 與實體大相徑庭，是一種將用戶的消息映射爲相關機器人操做（預測工做流）的常規特徵。例如，「今每天氣如何」這句話可按照全文直接映射至「weather_inquery」意圖，而非映射至其餘內容。

• 操做（Action） 是指機器人能夠執行並做爲相關意圖響應結果的步驟。一般這多是傳統的函數，並可能經過可選參數從調用方得到更詳細的信息（上下文情境）。

取決於具體平臺，上下文情境可能多種多樣，在具體形式或拓撲方面並無什麼嚴格的規定。但情境主要體現爲鍵 / 值映射的形式，能夠持續追蹤實體的最新含義，並區分不一樣短語所包含的含義 / 意圖之間的差別。

機器人的不一樣類型：開放 / 閉合域，基於生成 / 基於檢索

雖然已經說過，聊天機器人其實是由某種類型的 Web 接口組成，但還要注意，這其實是一種人工智能應用，所以天然會涉及到分類學方法。

在介紹過機器人用來理解語言的方法後，一塊兒來看看忽略具體類型和響應方式的狀況下，各類機器人的拓撲。

首先能夠根據操做範圍（是否嚴格限定於某一閉合域，如天氣機器人或披薩機器人，或進行各類類型的通用對話），以及爲了響應用戶輸入所要進行的計算方式（是否會直接檢索預約義的響應內容，仍是根據輸入的信息生成對應的響應結果），將對話式 AI 劃分爲不一樣類型。

不管何種方式，對於檢索形式的響應，最重要的一點在於要嚴格區分靜態和動態響應。前者是最簡單的，有些相似於直接套用現成的模板，輸入的每一個信息都有對應的答案。後者則更像一種知識庫，能夠根據相關性得分返回一系列可能的響應結果。

對於適用於某種閉合域的聊天機器人，只須要解決圍繞有限的幾個問題所展開的交流便可，例如預訂酒店 / 餐廳 / 航班，購買披薩，買鞋等。很明顯，此時輸入的內容也是有限的，對於一個負責定夠披薩的機器人，徹底無需考慮用戶可能談到的政治、心理學或哲學問題。

開放領域的機器人主要側重於與用戶自身的對話，然而並不須要徹底理解用戶說的每一個字，無需檢索實體和意圖，也不須要追蹤上下文情境。這種機器人只須要努力模擬現實生活中的對話，其主要目的在於娛樂用戶，或解答相似 FAQ 那樣的通用問題。

如何構建一個聊天機器人？

瞭解了這些基礎知識後，能夠開始考慮構建一個了。不過開始以前還須要決定本身打算使用的平臺或工具。

若是但願快速上手並嘗試，但還沒準備好由本身來寫代碼，建議先從 無需編程的聊天機器人生成器 着手。這類應用主要面向非技術型用戶，很是簡單易用。此時無需過多考慮技術細節，只須要完成一些純粹的概念性工做便可（不過依然有必定的學習曲線）。這種方式最適合用於構建簡單的機器人，但並不適合複雜的商業用途，由於這類方式最大的不足在於缺少，甚至徹底不具有天然語言處理能力（這種能力是複雜的機器人所必須的）。相似的平臺有不少，例如 Chatfuel、ManyChat、Octane AI、Massively AI。

若是但願進行更復雜的開發，則須要用到機器人框架和 AI 服務。

框架 包含了聊天機器人工做流程內各類通用功能的抽象，爲了便於使用一般會打包提供。聊天機器人框架與其餘軟件框架（例如 Web 應用框架）相似，能夠爲咱們提供各類必須的工具。一般這類框架都是面向某種特定編程語言實現的。此外一些機器人框架還提供了託管式的，甚至可交互的開發環境，藉此進一步簡化機器人的建立過程。

AI 服務 則是另外一種獨立的雲端平臺，一般會提供以交互式方法建立聊天機器人邏輯所需的 GUI，並具有由機器學習技術驅動的天然語言處理功能，可經過 RESTful API 通訊。

另外還有一種比較新穎的方法，能夠將聊天機器人與交互式語音響應（IVR）系統直接集成到 Web 服務構建工具或框架中。例如這一領域最新的成果之一是由 Aspect 開發的 Customer Experience Platform（CXP）解決方案，該解決方案可用於構建 Web 服務。藉此咱們能夠輕鬆地建立由數據支撐的網站，並經過基於文本和語音的機器人接口提供給用戶使用。有關這種方法的詳細信息可參閱 這裏。

主要的機器人框架：Botkit、Microsoft Bot Framework、Rasa NLU

正如上文所述，框架實際上是一種面向特定編程語言的庫。下文將介紹三個主要的框架：適用於 Node.js 的 Botkit for node.js，適用於.NET（也適用於 Node.js，但下文將主要圍繞.NET，尤爲是 C#）的 Microsoft Bot Framework 及 Bot Builder SDK，以及適用於 Python 的 Rasa NLU。

Botkit

首先從 Botkit 開始。按照設計，該框架能夠幫助忙碌的用戶快速簡單地針對本身的需求構建機器人，同時無需過多深刻具體的技術細節。該框架可經過一個統一的接口發送和接收消息。這個框架最初主要用於 Slack，但如今其功能經過擴展已經能夠支持鏈接至多種消息平臺。該框架提供了直觀的工做流，並以簡明扼要的方式加以整理，具有翔實的文檔，同時還提供了大量線上聊天機器人範例，藉此用戶能夠快速上手，並進一步開發本身的機器人。

然而要注意，該框架不包含天然語言處理功能，不過能夠經過中間件鏈接至現有的或自行開發的服務中實現天然語言處理。

該框架庫包含大量核心功能和鏈接器，爲多種平臺提供了支持。核心功能是以事件監聽器的形式實現的，如.on_message_receive、.hears 等。鏈接器的實現則取決於所鏈接的平臺。

Botkit 的使用很是簡單。首先須要安裝 Botkit，這一工做可經過 npm 安裝實現：npm install — save botkit。隨後建立一個包含代碼的文件（能夠參閱這裏【https://github.com/howdyai/botkit/blob/master/console_bot.js 】查看最基礎的控制檯機器人範例），並使用 node.js 運行：node my_bot.js。

Microsoft Bot Framework

微軟十分熱衷於緊跟技術發展趨勢，爲咱們提供了一種開發聊天機器人的全新方式。Microsoft Bot Framework 功能極爲全面，並提供了簡單易用的構建 SDK，其中包含兩個主要組件：用於實現集成的框架 Bot Connector SDK 自己，以及最基本的機器人邏輯和 LUIS.ai，後者主要用於實現天然語言處理，讓機器人感受上更像人類。

雖然 LUIS.ai 更像是一種功能而非組件，但該框架自己也可不借助該功能直接使用，而且單獨使用就已經能夠實現讓人印象深入的效果。這套工具很是健壯，在集成方面也能夠提供近乎無限的潛力（例如與 Messenger、Skype 等集成）。該開發環境爲交互式開發和簡單的測試提供了必要的工具，用戶還可將本身開發的機器人公佈出來並接受微軟的審覈，若是審覈經過還可歸入 Bot Directory（https://bots.botframework.com/ ），並被更多人使用。

Rasa NLU

雖然並不是專門爲聊天機器人的構建量身打造的框架，但 Rasa NLU 也是一種很方便的後端解決方案。Botkit 和 Microsoft Bot 可鏈接至各類消息平臺，而 Rasa NLU 更像是一種天然語言處理服務，能夠在用戶本地環境提供處理功能。此外 Rasa 提供了 Python 接口，可將實體提取器直接集成於使用 Python 開發的應用程序。此外該技術還可做爲服務在其餘框架中運行，並暴露 REST API 端點。

這些工具各自的利弊，可參閱下表。

卓越的 AI 服務：

Wit.ai、api.ai、LUIS.ai、IBM Watson

正如上文所述，AI 服務是一種可知足天然語言處理需求的雲端解決方案，藉此可開發智能機器人並預測複雜的流式對話。這種服務可爲預測模型的構建和訓練提供所需 UI，經過機器學習技術理解語言中包含的實體。

一塊兒看看這個領域的幾個重量級選手。

Wit.ai

根據官網介紹，Wit.ai 平臺可讓開發者輕鬆地構建能夠經過語音或文字方式交流的應用程序。該技術最近已被 Facebook 收購，並已歸入 Facebook 的 Bot API 中。

Wit.ai 可幫助用戶無需考慮內部邏輯，輕鬆構建機器人的行爲，並可經過多種語言實現可供註冊的機器人操做。

Wit.ai 中，用於定義行爲的關鍵概念叫作「故事」。舉例來講，這些故事表明着各類可能產生的對話所對應的基本骨架。一個「故事」可包含一組相關意圖，而意圖自己則是用戶定義的實體，其中包含了未被用於定義整個流程的各種特性。

隨後便可經過樣本訓練用於天然語言處理的機器學習模型，這是一種很好的作法。只須要告訴 Wit.ai 須要接受怎樣的輸入，當用戶發送了相似的請求後，便可酌情作出響應。

Wit.ai 提供了一套強大的語言實體理解機制。此外還有一個很棒的功能，該平臺能夠爲實體分配角色，藉此可進一步促進服務器端的處理工做。

爲了與服務器端交互，Wit.ai 還實現了「Bot sends」命令，並可經過與 Webhook 的集成實現自定義機器人操做，例如調用 API。

Api.ai

Api.ai 是另外一個能夠幫咱們構建支持天然語言處理的機器人的平臺。

與 Wit.ai 嚴重依賴意圖進行預測的作法不一樣，Api.ai 由兩個重要概念：意圖和上下文情境（Wit.ai 也有上下文情境，但用途有所差別）。「意圖」充當了橋樑的做用，可將用戶的請求與對應的操做鏈接在一塊兒；而以字符串值形式呈現的「上下文情境」則可用於區分請求以及存在各類細微誤差的意圖。

Api.ai 與 Wit.ai 的基本工做流也有所差別。當 Api.ai 接到用戶請求後，首先會將其與意圖相匹配（若是沒有找到匹配的意圖，則直接使用默認意圖），隨後調用相應的操做。意圖的匹配過程能夠經過上下文情境列表加以限制，藉此確保始終具有可匹配的意圖（匹配能夠產生或刪除上下文情境），藉此建立出相似於包含不一樣狀態應用程序的工做流。

與 Wit.ai 相似，Api.ai 也能夠提取意圖。更重要的是，該平臺自帶一個 Slot-filling 系統的實現（Slot-filling 系統是一種方法，可用於從用戶處請求信息，並將其與已獲取實體進行關聯並繼續向用戶索取缺失的實體，藉此從用戶提供的信息中提取實體）。

服務器端邏輯一樣包含 Webhook，而 Api.ai 基本上是在調用各類服務並得到響應。這裏有個重點須要注意，服務器端代碼能夠修改上下文情境，所以會影響預測流的結果。

Microsoft Language Understanding Intelligent Service

LUIS 差很少算是 AI 服務領域的一個新選手，由微軟在 2016 年 Microsoft Build 大會上發佈。

與競爭對手相似，LUIS 提供了實體識別和訓練系統，能夠經過具有層次結構的實體區分細分的含義（有些相似 Wit.ai 中的「角色」）。

LUIS 須要經過意圖預測所要執行的操做，並使用了與 Api.ai 相同的邏輯。

訓練過程一樣是經過 UI 進行的，所以用戶能夠用靈活的方式加以訓練。用戶請求日誌能夠幫助用戶方便地作出解釋並對解釋進行糾正，藉此進一步訓練模型。

LUIS 一樣具有操做履行能力，可收集所需意圖和上下文情境，進而執行一系列連鎖操做。該平臺目前仍是測試版，僅可用於簡單的測試。此外該平臺還有另外一個測試版功能值得咱們注意，能夠經過專門設計的對話支持幫助咱們對相關請求進行整理，並對各類問題進行分組，藉此經過機器人爲用戶提供更簡潔的對話。

IBM Watson

IBM Watson 是一種認知雲服務，可實現包括天然語言處理、語音識別、情緒分析、對話在內的各類功能。可能有人還記得（或者已經忘了）IBM Watson 曾做爲一種具有認知能力的超級計算機系統，在電視問答節目 Jeopardy 中打敗過人類。是否納悶它們之間有沒有什麼關係？沒錯，是有一些關係，IBM 將那臺超級計算機的強大能力帶到了雲端，創造出一個能夠幫助咱們完成各類任務的龐大平臺。

然而該平臺的不足之處在於，整個平臺提供了太多功能，可能會讓用戶疑惑，進而須要花費大量時間來決定本身到底該用哪些功能。而就算肯定了要使用的功能，隨後可能也須要投入大量資源，才能順利開始使用。

此外該服務還很是貴（每一個 API 調用約 2 美分），所以可能並不適合初學者。但對於有着普遍而且明確用例的企業環境，IBM Watson 依然是一種不錯的解決方案。

這些工具的一些重要信息彙總以下表所示：

結論

聊天機器人正在飛速崛起並依然在不斷完善，更加貼近最終用戶，能與更多現有技術集成。經過深刻理解其本質、功能以及運行原理，能夠幫助咱們開發更有效的機器人，藉此改善產品的營銷、廣告宣傳以及總體消費者體驗。

目前咱們能夠經過多種平臺建立聊天機器人，這讓人激動，但同時也會讓人感受畏縮，但每種平臺都是針對不一樣用例設計的，在機器人開發過程當中包含了不一樣的角色。隨着深度學習技術的進一步發展，咱們也一樣期待對話式 AI 在不肯的將來也能利用這種技術，向着經過圖靈測試的最終目標邁出更大的步伐。

閱讀英文原文：

A Comparative Analysis of ChatBots APIs

https://medium.com/activewizards-machine-learning-company/a-comparative-analysis-of-chatbots-apis-f9d240263e1d