更多優質內容請關注微信公眾號“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 服務。藉此我們可以輕鬆地建立由資料支撐的網站，並通過基於文字和語音的機器人介面提供給使用者使用。有關這種方法的詳細資訊可參閱 這裡。
正如上文所述，框架其實是一種面向特定程式語言的庫。下文將介紹三個主要的框架：適用於 Node.js 的 Botkit for node.js，適用於.NET（也適用於 Node.js，但下文將主要圍繞.NET，尤其是 C#）的 Microsoft Bot Framework 及 Bot Builder SDK，以及適用於 Python 的 Rasa NLU。
首先從 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 功能極為全面，並提供了簡單易用的構建 SDK，其中包含兩個主要元件：用於實現整合的框架 Bot Connector SDK 本身，以及最基本的機器人邏輯和 LUIS.ai，後者主要用於實現自然語言處理，讓機器人感覺上更像人類。
雖然 LUIS.ai 更像是一種功能而非元件，但該框架本身也可不借助該功能直接使用，並且單獨使用就已經可以實現讓人印象深刻的效果。這套工具非常健壯，在整合方面也可以提供近乎無限的潛力（例如與 Messenger、Skype 等整合）。該開發環境為互動式開發和簡單的測試提供了必要的工具，使用者還可將自己開發的機器人公佈出來並接受微軟的稽核，如果稽核通過還可納入 Bot Directory（https://bots.botframework.com/ ），並被更多人使用。
雖然並非專門為聊天機器人的構建量身打造的框架，但 Rasa NLU 也是一種很方便的後端解決方案。Botkit 和 Microsoft Bot 可連線至各種訊息平臺，而 Rasa NLU 更像是一種自然語言處理服務，可以在使用者本地環境提供處理功能。此外 Rasa 提供了 Python 介面，可將實體提取器直接整合於使用 Python 開發的應用程式。此外該技術還可作為服務在其他框架中執行，並暴露 REST API 端點。
這些工具各自的利弊，可參閱下表。
正如上文所述，AI 服務是一種可滿足自然語言處理需求的雲端解決方案，藉此可開發智慧機器人並預測複雜的流式對話。這種服務可為預測模型的構建和訓練提供所需 UI，通過機器學習技術理解語言中包含的實體。
一起看看這個領域的幾個重量級選手。
根據官網介紹，Wit.ai 平臺可以讓開發者輕鬆地構建可以通過語音或文字方式交流的應用程式。該技術最近已被 Facebook 收購，並已納入 Facebook 的 Bot API 中。
Wit.ai 可幫助使用者無需考慮內部邏輯，輕鬆構建機器人的行為，並可通過多種語言實現可供註冊的機器人操作。
Wit.ai 中，用於定義行為的關鍵概念叫做“故事”。舉例來說，這些故事代表著各種可能產生的對話所對應的基本骨架。一個“故事”可包含一組相關意圖，而意圖本身則是使用者定義的實體，其中包含了未被用於定義整個流程的各類特性。
隨後即可通過樣本訓練用於自然語言處理的機器學習模型，這是一種很好的做法。只需要告訴 Wit.ai 需要接受怎樣的輸入，當使用者傳送了類似的請求後，即可酌情做出響應。
Wit.ai 提供了一套強大的語言實體理解機制。此外還有一個很棒的功能，該平臺可以為實體分配角色，藉此可進一步促進伺服器端的處理工作。
為了與伺服器端互動，Wit.ai 還實現了“Bot sends”命令，並可通過與 Webhook 的整合實現自定義機器人操作，例如呼叫 API。
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 基本上是在呼叫各種服務並獲得響應。這裡有個重點需要注意，伺服器端程式碼可以修改上下文情境，因此會影響預測流的結果。
LUIS 差不多算是 AI 服務領域的一個新選手，由微軟在 2016 年 Microsoft Build 大會上釋出。
與競爭對手類似，LUIS 提供了實體識別和訓練系統，可以通過具備層次結構的實體區分細分的含義（有些類似 Wit.ai 中的“角色”）。
LUIS 需要通過意圖預測所要執行的操作，並使用了與 Api.ai 相同的邏輯。
訓練過程同樣是通過 UI 進行的，因此使用者可以用靈活的方式加以訓練。使用者請求日誌可以幫助使用者方便地做出解釋並對解釋進行糾正，藉此進一步訓練模型。
LUIS 同樣具備操作履行能力，可收集所需意圖和上下文情境，進而執行一系列連鎖操作。該平臺目前還是測試版，僅可用於簡單的測試。此外該平臺還有另一個測試版功能值得我們注意，可以通過專門設計的對話支援幫助我們對相關請求進行整理，並對各種問題進行分組，藉此通過機器人為使用者提供更簡潔的對話。
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