從開發框架到後端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 安裝實現：。隨後創建一個包含代碼的文件（可以參閱這裡【https://github.com/howdyai/botkit/blob/master/console_bot.js 】查看最基礎的控制台機器人範例），並使用 node.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

AI前線

緊跟前沿的AI技術社群

如果你希望看到更多類似優質報道，記得點個贊再走！

┏(＾0＾)┛明天見！

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！