選自：Tryolabs
作者：Javier Wed
參與：朱朝陽、Rick R、黃小天
聊天機器人（chatbot）行業仍然處於它的早期階段， 但正已驚人的速度增長著。 起初看起來像是時尚或市場行銷策略的聊天機器人正成為消費者真正的需要。 你想知道你所在地區、附近的劇院正流行什麼電影嗎， 或者看一個簡短的預告片？你可以使用Fandango bot。 你是NBA球迷嗎， 想獲得比賽亮點和及時更新？或許你可以試一下NBA’s bot。 關於食物或衣服呢， 你見沒見過現在有多少品牌有聊天機器人允許你能夠輕鬆上網購買食物或者流覽衣物？
Fandango bot：https://www.facebook.com/fandango/
NBA’s bot：https://www.facebook.com/nba/
不可否認， 聊天機器人的背後確實有市場行銷的目的，
現如今有巨多複雜程度、表達能力、集成能力各不相同的平臺和工具供開發聊天機器人使用。 讓我們假設你想要開發一個聊天機器人。 你面臨的價值百萬美元的問題是：在所有的平臺裡， 哪一個最能滿足我的需求？
去年我們在Tryolabs就聊天機器人方面做了許多研究， 每一個新專案誕生時我們都會面臨這個問題。 在這篇文章中， 我們會概述一些我們學習和測試過的平臺。 我們將會看到， 取決於聊天機器人的使用場景，
通用聊天機器人架構
首先要瞭解的是聊天機器人內部是如何工作的。 基本是給定一個用戶輸入， 聊天機器人就會返回一個響應。 原理很簡單， 但實踐起來就不那麼容易了。
理解使用者的意圖
假設你正問一個旅遊機器人以下問題：
I want to fly to Venice, Italy from Paris, France, on January 31首先， 機器人需要理解你的輸入。 有兩種主要的技術來達到這個目的：模式匹配和意圖分類。
模式匹配方法需要輸入模式可能的清單， 以上輸入可能會匹配到如下的模式：
I want to fly to from on這種方法的好處就是模式可以被人類解讀，
內容分類方法依賴於機器學習的技術。 你需要一個樣本集來訓練一個在給定用戶輸入時能從所有可能的內容（例如， 買票、檢查航班狀態、獲取詳細資訊等）中選擇的分類器。
在任何場景中， 上述例子的城市和日期對於理解輸入並返回一個合適的答案是非常關鍵的。 聊天機器人可能會在資料庫（或者線上查詢）中查找在給定日期從威尼斯到巴黎的機票。 因此， 聊天機器人需要對輸入進行資訊提取來獲得重要的實體：位置、航班、機場、日期等等。
對輸入進行分類和從中提取資訊是你需要時刻謹記的兩個重要觀念。
對用戶回饋
一旦聊天機器人理解了用戶說的什麼， 它能夠基於當前輸入和交流的情境選擇或生成一個回復。
靜態回復
最簡單的方式是靜態回復， 對每一個使用者輸入， 最終都會有不同的清單。 這些靜態回復可以是範本， 比如The flight time is hours， 是聊天機器人計算出的一個變數。
動態回復
另外一個不同的方法是使用資源（例如知識庫）來獲取可能回復的列表， 然後對它們打分以選擇更好的回復。 如果你的聊天機器人主要是一個問答（QA）系統， 那麼這種方法就非常合適。
生成式回復
如果你有大的對話樣本語料庫， 你可以用深度學習技術來訓練一個在給定輸入下會生成答案的生成式模型。
不要忘了對話的語境
僅基於目前的輸入還不足以提供給用戶正確的答案。 為實現聊天機器人的邏輯， 對於語境的關注是非常重要的。 例如， 如果用戶鍵入以下的輸入:
How many bags can I bring with me?
聊天機器人僅能夠在它知道票的細節時回答問題。 典型來說， 這種資訊之前存儲在了交流的情景中。 當然， 每一個聊天機器人必須對它自己的語境建模和決定記憶的重要資訊。
現有平臺
在你選擇一個平臺之前， 你必須知道你要開發的是何種類型的聊天機器人——是面向目標的機器人，還是對話機器人，又或者是面向目標的有非常強的對話能力的聊天機器人？
一個面向目標的或者事務型的聊天機器人是商業出現頻率最為頻繁的一種聊天機器人。
交流類型的聊天機器人重點關注與用戶的交流。它不需要深入理解使用者說的什麼和記住交流的所有情景，它只需要效仿一段對話。那麼聊天機器人用來幹什麼呢？娛樂可以是一個原因，但是，比如說，你可以打造一個聊天機器人用以替代經典的FAQ，提供給使用者更動態的體驗。
講清楚了這個，從現有的平臺中我們能區分出三種家族:
面向對話的平臺
由技術巨頭支持的平臺
這不是一個正規的分類而是分組或對平臺編目錄的方式。
非程式設計平臺
它們是面向非技術人員的平臺。通常來說，即使沒有程式設計能力、沒有機器學習或自然語言處理專業知識，也可以比較容易地程式設計一個聊天機器人。其中的關鍵思想是用戶沒必要擔心技術細節。
有非常多的非程式設計平臺，在這裡把它們都列出來是不可能的。在Tryolabs我們已經測試了一些，知道了它們的優點和缺點：
Chatfuel：https://chatfuel.com/
ManyChat：https://manychat.com/
Octane Ai：http://octaneai.com/
Massively：http://www.massively.ai/
Motion.ai：https://www.motion.ai/
第一個要說的就是它們都是面向任務型的，最常用的例子是“訂一份披薩”。我們發現即使第一眼看上去是非常相同，在成熟度、圖形化使用者介面可用度和自然語言處理能力方面也有很大的不同。
優點
你可以快速開發一個聊天機器人
它們有一個很低的學習曲線
開發簡單聊天機器人非常理想
缺點
不同程度不同穩定性的平臺非常多。
有些時候圖形化使用者介面並不很容易理解，而且當聊天機器人邏輯變化更複雜時，也難以駕馭。
上述平臺沒有或很少有自然語言處理的能力。例如，一些平臺不能提取資訊。因此，給定一個短語比如”I'm in Boston”，他們不能提取城市波士頓(wei zhi實體)存在這個事實(實體)。
對於一些複雜的聊天機器人來說他們不太合適。
結論
從我們的觀點來看，非程式設計平臺無法處理大型商業工程項目。交流不能非常複雜，而且通常來說集成外部資源比如自然語言處理和機器學習的特殊組件是不可能的。
然而，非程式設計平臺對於小項目來說是非常好的選擇，例如，經常快速地為臉譜頁添加一個聊天機器人的功能。所以你可能想試一試看看它們能為你做什麼。
對話平臺
The main goal here is to allow the user to have a conversation with the bot, without considering a task-oriented scenario. These platforms typically use specification languages such as AIML (Artificial Intelligence Markup Language) to model the interactions with the user. The example below shows how to code interactions with AIML.
對話平臺的主要目的是允許使用者與機器人進行對話而不用考慮一些任務導向的情況。這些平臺通常使用諸如 AIML（Artificial Intelligence Markup Language，人工智慧標記語言） 等規範語言來類比與使用者之間的交互。下面這個例子展示了如何運用 AIML 來編寫這種交互。
當用戶說：“my dog’s name is Max”，聊天機器人就會識別該模式並提取狗的名字。必須指出的是，這種通過文本匹配進行資訊提取的方式與 NLP（自然語言處理，Natural Language Processing）提取資訊的能力比起來是非常簡單的。聊天機器人會回復“That is interesting that you have a dog named Max”。隨後，如果用戶詢問該狗的名字，聊天機器人就會回答“Your dog’s name is Max”。
這類平臺中最著名的一個例子是 Pandorabots（http://www.pandorabots.com/）。
優點
AIML 是一個標準。
它創建對話非常靈活。
缺點
對於人工創建的模式， 用 AIML 難以進行擴展。
資訊提取能力有限。
並不真正適用於面向任務的機器人
總結
雖然你不會去用這些平臺創建一個聊天機器人來訂餐或買票，但你會發現用它們來快速建模一個娛樂聊天機器人是非常有趣的，例如它可以取代常見問題解答（FAQ）服務並提供更好的使用者體驗。
科技巨頭們建立的平臺
這些平臺由科技巨頭公司所開發，並且不知何故，它們已經成為了一個標準，或至少正在成為一個標準：
Api.ai (Google)
Wit.ai (Facebook)
LUIS (Microsoft)
Watson (IBM)
Lex (Amazon)
這些巨頭們試圖同時擁有低學習曲線和強勁表現。
出於多種原因，在 Tryolabs我們將注意力集中於 Api.ai 和 Wit.ai。在我們的印象中，LUIS 和 Watson 提出了一個比我們所需要的更複雜（並且最終更強大）的框架。至於 Amazon Lex，我們寫這篇文章時還未獲得其有限的預覽許可權 。
我們不打算對 Api.ai 和 Wit.ai 做詳盡的對比或去深入研究每一個平臺，而是為你們提供我們的經驗回饋。當你在建模一個聊天機器人時會立即明白，其中最難的部分之一便是建模對話流（conversation flow）。基本上是它定義了聊天機器人的行為。讓我們看看 Api.ai 和 Wit.ai 是如何處理這個關鍵部分的。
Api.ai聊天機器人的行為
意圖（Intents） 和語境（Contexts）是使用 Api.ai 來塑造聊天機器人行為的重要概念。Intents 創建了使用者的聊天內容與 bot 所應採取的行動之間的聯繫。Contexts 是字串值，用於根據先前的請求來區分出可能含有不同意思的新請求。
總的說來，在 Api.ai 接收到一條用戶請求，它首先會被分配去確定該請求是否匹配某個已知內容。Api.ai 提出用一個默認回退意圖（“Default Fallback intent”）來處理不匹配任何用戶意圖（Intents）的請求。
Api.ai 介面
你可以通過指定一個啟動的語境列表來限定一條意圖的匹配。同時意圖的匹配可以創建和刪除語境。
在上面的例子中，當用戶說“I would like to order a large pizza”，此請求所匹配的意圖名為order，它可以創建一個名為ordering的語境。用戶指明了披薩的類型、大小等參數後，你就可以創建一個名為 pizza_selected（保持 ordering 的context處於啟動狀態）的語境。然後，如果用戶說：“What is the delivery time?”該機器人就會匹配一個名為get_order_info的意圖，其前提是名為pizza_selected
的語境存在。
這一套意圖&語境機制使得創建可建模大而複雜的 flow 的狀態機成為可能。然而你無法建模這種情況——意圖只有在某個語境不存在時才能被匹配。這是 Api.ai 目前的一個局限性，我們認為他們將很可能會致力於該問題的研究。
實體（Entities）
你可以定義自己的實體並使用平臺推薦的實體。在上面的“order a pizza”例子中，比薩的類型和大小是使用者定義的實體，而位址和數量是系統實體。
填槽（Slot-filling）能力
這是令 Api.ai 兼具靈活性和強大性能的一個關鍵因素。填槽允許你對給定的意圖進行標示——哪些欄位發揮作用以及它們是否為必填項。
有了填槽，你就不必親自處理丟失的資訊，因為這是在 Api.ai 端進行的。在上面的例子中，Api.ai 會詢問每個必填欄位直到它被用戶填上：比薩的類型和大小、地址和交貨時間。
你可以看到，“number”欄位可能是意圖的一部分，卻不是必填項。
伺服器尺寸編碼
當然，要為你的聊天機器人定義完整的邏輯，你需要在伺服器端添加一些自訂編碼。Api.ai 提出了一種 webhook 集成，使編碼變得非常簡單。基本上，Api.ai 將來自一個匹配意圖上的資訊傳遞給網頁伺服器，並從中得到一個結果。一個非常有用的功能是：發送到 Api.ai 中的結果可以在文本和語音水準上改變語境和聊天機器人的回復，因此你不僅可以實施伺服器端的邏輯，還可以在一定程度上修改聊天機器人端的邏輯。你可以決定讓哪個意圖來調用 webhook，以及是否要在填槽期間調用 webhook。該組合是進行聊天機器人行為定制化的一個強大而靈活的工具。
優點
Api.ai 提出了使用意圖和語境的一種強大方法去建模大而複雜的流。
填槽是一個集成特性。因此可以通過聊天機器人去解決一大部分邏輯編碼，從而減少了伺服器端的編碼工作。
域（Domains）可用，它是處理幾個常見用例和應用程式（例如閒聊、常識、航班時刻表、提醒…）的規範。
提出用“Training” 單元（公測中）來利用案例訓練聊天機器人。
若干平臺的一個集成：Facebook Messenger、Slack、Twitter、Telegram...
缺點
無法于 context 存在時阻止 intent 的匹配。
訓練區塊仍處於公測中。
Wit.ai聊天機器人的行為
使用 Wit.ai 塑造聊天機器人行為的關鍵概念是 stories。每個 story 都代表了一個可能的對話案例。應當指出的是，“intent”不再是一個概念，而是一個非強制性使用者實體。這是對 Wit.ai 影響較大的一個改變，它出於這樣一個事實，即一個複雜的聊天機器人需要很多能夠以某種方式被劃分為 stories 的 intents。
Bot 開發者基本上是通過舉例的方式來教 Wit.ai。下面的思想是，當一個用戶寫了“相似的（similar）”請求時，Wit.ai 就會對其進行處理，提取實體並應用開發人員所定義的邏輯。
Wit.ai 介面
一個故事可以被看作是一個使用者意圖表。你可以添加分支，該分支由特定變數值的存在與否等條件所觸發，並可從用戶輸入中提取。這允許你定義一個對話流。此外，你還可以使用書簽機制在意圖及故事之間跳躍。
你可以使用“Bot sends”命令（基本上是函數的調用）來與伺服器端進行交互。有趣的是，你可以在一個短語中設置實體的角色。例如這句話“I want to fly to Venice, Italy from Paris, France, on January 31”，你可以規定說第一個城市是始發地而第二個城市為目的地。
實體（Entities）
Wit.ai 允許你自己定義實體或使用預定義的實體。
伺服器尺寸編碼
Wit.ai 提出了一種 webhook 集成：它將每個“Bot sends”命令中的資訊傳遞到一個網頁伺服器中，並從中得到一個結果。通常你會在伺服器端創建或擴展對話語境。發送到 Wit.ai 的結果可以對聊天機器人端所使用的情境變數進行添加、修改和刪除。
優點
“故事”（story）這一概念很強大。
Wit.ai 允許使用分支和行動條件來控制對話流（例如，只在某些特定變數被定義時才顯示此消息）。
為實體分配角色有助於伺服器端的處理進程。
提出了“理解”（Understanding）單元來用樣本去訓練聊天機器人。
無法被聊天機器人處理的請求會被單獨列出，那兒有一個“收件箱”（Inbox）供開發者訓練機器人。
缺點
還在公測中。
即使 “故事”是一個很強大的概念，也存在難以控制對話流以及機器人傾向于誤解使用者請求的情況。
目前的限制：伴隨自然語言處理（NLP）和機器學習（ML）的改進
正如我們已經看到的，尤其是對於 Api.ai 和 Wit.ai 來說，要塑造一個聊天機器人就需要提供邏輯和語言資源，後者主要是輸入/輸出短語與實體。而這對於小型聊天機器人來說應該不成問題，但如果你打算處理很多專業術語及短語變體，那麼你就應該考慮使用自然語言處理和機器學習。我們來舉幾個這種情況下的應用案例。
單數和複數形式
如果你想讓你的聊天機器人提取“pizzas”作為一個實體，那麼僅僅定義“pizza”是不夠的，你還需要提供“pizzas”。
Api.ai 有一個功能叫做“自動拓展（automatic expansion）”，而 Wit.ai 有稱為“自由文本（free-text）”的實體。這些機制會嘗試基於單詞語境來捕捉新條目。所以如果你已經使用短語來訓練你的聊天機器人，比如“I’d like to order a pizza”，那麼它很可能會認為在“I’d like to order 3 pizzas”這句話中，單詞“pizzas”是一個實體。不過該功能的準確性取決於訓練過程，而你無法得知它會帶來多大的干擾。
一個有把握的選擇是為每個概念同時提供其單數和複數形式，可使用自然語言處理工具中的 inflectors 來生成它們。
同義詞、上位詞和下位詞（概念上外延更廣/窄的主題詞）
假設這樣一種情況，使用者想要一瓶汽水，但你的聊天機器人只知道具體的名目，諸如可口可樂或百事可樂，它們是汽水的下位詞。存在很多自然語言處理資源可以用來處理英語中的上位詞、同義詞和下義詞，比如詞庫（Thesaurus）和本體（Ontologies），但它們通常針對的是一些通用語言。因此，可口可樂作為一個非常具體的功能變數名稱，就不太可能屬於這種資源。
你可以嘗試去找到一個適合你的問題的現有詞庫，或自建一個詞庫。領域專家建立的資源價格昂貴但精確度高。你可以使用機器學習來創造語言資源，而深度學習技術則完全可以滿足你的個人使用需求。
情感分析
你想為你的聊天機器人加入一定程度的情緒反應嗎？那麼，你可以嘗試在伺服器端執行情感分析來快速適應回應。
然而這個任務如果使用 Api.ai 或 Wit.ai 則難以進行。如果你想得到一個非常靈活且語料豐富的聊天機器人，或許你應該考慮從零開始進行開發。
總結/最後的思考
顯然，聊天機器人呈上升趨勢，而我們在 Tryolabs 目睹了其快速增長的需求。如果做對了，這條用戶溝通管道就能夠為你增加訂單機會、提供一個更好的用戶體驗以及節約成本。然而實現過程絕非易事。
目前有大量的平臺可以幫助你創建一個聊天機器人。其中一些平臺已經利用所獲取的不同使用情況而被建立起來，所以很明顯，根據你的聊天機器人所針對的業務情況，有些平臺可能會比其它平臺更合適你。為了幫助你挑選出最佳的工具，我們回顧了現有聊天機器人搭建服務方的一些優勢及劣勢。
如果你打算建立一個複雜的聊天機器人，那麼你應該認真考慮一下穩定性、可擴展性和靈活性這三個方面。倘若你不夠重視人類語言的複雜性，一次談話很快就能偏離正軌。你可能需要從零開始建立自己的解決方案，或使用一個工具組合來解決一般的自然語言處理問題（即 Api.ai），以及為更強大的功能而選擇自訂伺服器端邏輯。
總之，聊天機器人生態系統發展很快，許多現有平臺所發佈的功能日新月異 。截至今天，很顯然當你雄心勃勃地試圖建立一個能夠處理複雜對話並採取行動（即付款）的聊天機器人時，你不能 100% 地依靠平臺，還需要定制化自然語言處理的發展。深度學習技術的最新進展可能在不久的將來會有很大幫助，我們對此非常期待。
你必須知道你要開發的是何種類型的聊天機器人——是面向目標的機器人，還是對話機器人，又或者是面向目標的有非常強的對話能力的聊天機器人？一個面向目標的或者事務型的聊天機器人是商業出現頻率最為頻繁的一種聊天機器人。
交流類型的聊天機器人重點關注與用戶的交流。它不需要深入理解使用者說的什麼和記住交流的所有情景，它只需要效仿一段對話。那麼聊天機器人用來幹什麼呢？娛樂可以是一個原因，但是，比如說，你可以打造一個聊天機器人用以替代經典的FAQ，提供給使用者更動態的體驗。
講清楚了這個，從現有的平臺中我們能區分出三種家族:
面向對話的平臺
由技術巨頭支持的平臺
這不是一個正規的分類而是分組或對平臺編目錄的方式。
非程式設計平臺
它們是面向非技術人員的平臺。通常來說，即使沒有程式設計能力、沒有機器學習或自然語言處理專業知識，也可以比較容易地程式設計一個聊天機器人。其中的關鍵思想是用戶沒必要擔心技術細節。
有非常多的非程式設計平臺，在這裡把它們都列出來是不可能的。在Tryolabs我們已經測試了一些，知道了它們的優點和缺點：
Chatfuel：https://chatfuel.com/
ManyChat：https://manychat.com/
Octane Ai：http://octaneai.com/
Massively：http://www.massively.ai/
Motion.ai：https://www.motion.ai/
第一個要說的就是它們都是面向任務型的，最常用的例子是“訂一份披薩”。我們發現即使第一眼看上去是非常相同，在成熟度、圖形化使用者介面可用度和自然語言處理能力方面也有很大的不同。
優點
你可以快速開發一個聊天機器人
它們有一個很低的學習曲線
開發簡單聊天機器人非常理想
缺點
不同程度不同穩定性的平臺非常多。
有些時候圖形化使用者介面並不很容易理解，而且當聊天機器人邏輯變化更複雜時，也難以駕馭。
上述平臺沒有或很少有自然語言處理的能力。例如，一些平臺不能提取資訊。因此，給定一個短語比如”I'm in Boston”，他們不能提取城市波士頓(wei zhi實體)存在這個事實(實體)。
對於一些複雜的聊天機器人來說他們不太合適。
結論
從我們的觀點來看，非程式設計平臺無法處理大型商業工程項目。交流不能非常複雜，而且通常來說集成外部資源比如自然語言處理和機器學習的特殊組件是不可能的。
然而，非程式設計平臺對於小項目來說是非常好的選擇，例如，經常快速地為臉譜頁添加一個聊天機器人的功能。所以你可能想試一試看看它們能為你做什麼。
對話平臺
The main goal here is to allow the user to have a conversation with the bot, without considering a task-oriented scenario. These platforms typically use specification languages such as AIML (Artificial Intelligence Markup Language) to model the interactions with the user. The example below shows how to code interactions with AIML.
對話平臺的主要目的是允許使用者與機器人進行對話而不用考慮一些任務導向的情況。這些平臺通常使用諸如 AIML（Artificial Intelligence Markup Language，人工智慧標記語言） 等規範語言來類比與使用者之間的交互。下面這個例子展示了如何運用 AIML 來編寫這種交互。
當用戶說：“my dog’s name is Max”，聊天機器人就會識別該模式並提取狗的名字。必須指出的是，這種通過文本匹配進行資訊提取的方式與 NLP（自然語言處理，Natural Language Processing）提取資訊的能力比起來是非常簡單的。聊天機器人會回復“That is interesting that you have a dog named Max”。隨後，如果用戶詢問該狗的名字，聊天機器人就會回答“Your dog’s name is Max”。
這類平臺中最著名的一個例子是 Pandorabots（http://www.pandorabots.com/）。
優點
AIML 是一個標準。
它創建對話非常靈活。
缺點
對於人工創建的模式， 用 AIML 難以進行擴展。
資訊提取能力有限。
並不真正適用於面向任務的機器人
總結
雖然你不會去用這些平臺創建一個聊天機器人來訂餐或買票，但你會發現用它們來快速建模一個娛樂聊天機器人是非常有趣的，例如它可以取代常見問題解答（FAQ）服務並提供更好的使用者體驗。
科技巨頭們建立的平臺
這些平臺由科技巨頭公司所開發，並且不知何故，它們已經成為了一個標準，或至少正在成為一個標準：
Api.ai (Google)
Wit.ai (Facebook)
LUIS (Microsoft)
Watson (IBM)
Lex (Amazon)
這些巨頭們試圖同時擁有低學習曲線和強勁表現。
出於多種原因，在 Tryolabs我們將注意力集中於 Api.ai 和 Wit.ai。在我們的印象中，LUIS 和 Watson 提出了一個比我們所需要的更複雜（並且最終更強大）的框架。至於 Amazon Lex，我們寫這篇文章時還未獲得其有限的預覽許可權 。
我們不打算對 Api.ai 和 Wit.ai 做詳盡的對比或去深入研究每一個平臺，而是為你們提供我們的經驗回饋。當你在建模一個聊天機器人時會立即明白，其中最難的部分之一便是建模對話流（conversation flow）。基本上是它定義了聊天機器人的行為。讓我們看看 Api.ai 和 Wit.ai 是如何處理這個關鍵部分的。
Api.ai聊天機器人的行為
意圖（Intents） 和語境（Contexts）是使用 Api.ai 來塑造聊天機器人行為的重要概念。Intents 創建了使用者的聊天內容與 bot 所應採取的行動之間的聯繫。Contexts 是字串值，用於根據先前的請求來區分出可能含有不同意思的新請求。
總的說來，在 Api.ai 接收到一條用戶請求，它首先會被分配去確定該請求是否匹配某個已知內容。Api.ai 提出用一個默認回退意圖（“Default Fallback intent”）來處理不匹配任何用戶意圖（Intents）的請求。
Api.ai 介面
你可以通過指定一個啟動的語境列表來限定一條意圖的匹配。同時意圖的匹配可以創建和刪除語境。
在上面的例子中，當用戶說“I would like to order a large pizza”，此請求所匹配的意圖名為order，它可以創建一個名為ordering的語境。用戶指明了披薩的類型、大小等參數後，你就可以創建一個名為 pizza_selected（保持 ordering 的context處於啟動狀態）的語境。然後，如果用戶說：“What is the delivery time?”該機器人就會匹配一個名為get_order_info的意圖，其前提是名為pizza_selected
的語境存在。
這一套意圖&語境機制使得創建可建模大而複雜的 flow 的狀態機成為可能。然而你無法建模這種情況——意圖只有在某個語境不存在時才能被匹配。這是 Api.ai 目前的一個局限性，我們認為他們將很可能會致力於該問題的研究。
實體（Entities）
你可以定義自己的實體並使用平臺推薦的實體。在上面的“order a pizza”例子中，比薩的類型和大小是使用者定義的實體，而位址和數量是系統實體。
填槽（Slot-filling）能力
這是令 Api.ai 兼具靈活性和強大性能的一個關鍵因素。填槽允許你對給定的意圖進行標示——哪些欄位發揮作用以及它們是否為必填項。
有了填槽，你就不必親自處理丟失的資訊，因為這是在 Api.ai 端進行的。在上面的例子中，Api.ai 會詢問每個必填欄位直到它被用戶填上：比薩的類型和大小、地址和交貨時間。
你可以看到，“number”欄位可能是意圖的一部分，卻不是必填項。
伺服器尺寸編碼
當然，要為你的聊天機器人定義完整的邏輯，你需要在伺服器端添加一些自訂編碼。Api.ai 提出了一種 webhook 集成，使編碼變得非常簡單。基本上，Api.ai 將來自一個匹配意圖上的資訊傳遞給網頁伺服器，並從中得到一個結果。一個非常有用的功能是：發送到 Api.ai 中的結果可以在文本和語音水準上改變語境和聊天機器人的回復，因此你不僅可以實施伺服器端的邏輯，還可以在一定程度上修改聊天機器人端的邏輯。你可以決定讓哪個意圖來調用 webhook，以及是否要在填槽期間調用 webhook。該組合是進行聊天機器人行為定制化的一個強大而靈活的工具。
優點
Api.ai 提出了使用意圖和語境的一種強大方法去建模大而複雜的流。
填槽是一個集成特性。因此可以通過聊天機器人去解決一大部分邏輯編碼，從而減少了伺服器端的編碼工作。
域（Domains）可用，它是處理幾個常見用例和應用程式（例如閒聊、常識、航班時刻表、提醒…）的規範。
提出用“Training” 單元（公測中）來利用案例訓練聊天機器人。
若干平臺的一個集成：Facebook Messenger、Slack、Twitter、Telegram...
缺點
無法于 context 存在時阻止 intent 的匹配。
訓練區塊仍處於公測中。
Wit.ai聊天機器人的行為
使用 Wit.ai 塑造聊天機器人行為的關鍵概念是 stories。每個 story 都代表了一個可能的對話案例。應當指出的是，“intent”不再是一個概念，而是一個非強制性使用者實體。這是對 Wit.ai 影響較大的一個改變，它出於這樣一個事實，即一個複雜的聊天機器人需要很多能夠以某種方式被劃分為 stories 的 intents。
Bot 開發者基本上是通過舉例的方式來教 Wit.ai。下面的思想是，當一個用戶寫了“相似的（similar）”請求時，Wit.ai 就會對其進行處理，提取實體並應用開發人員所定義的邏輯。
Wit.ai 介面
一個故事可以被看作是一個使用者意圖表。你可以添加分支，該分支由特定變數值的存在與否等條件所觸發，並可從用戶輸入中提取。這允許你定義一個對話流。此外，你還可以使用書簽機制在意圖及故事之間跳躍。
你可以使用“Bot sends”命令（基本上是函數的調用）來與伺服器端進行交互。有趣的是，你可以在一個短語中設置實體的角色。例如這句話“I want to fly to Venice, Italy from Paris, France, on January 31”，你可以規定說第一個城市是始發地而第二個城市為目的地。
實體（Entities）
Wit.ai 允許你自己定義實體或使用預定義的實體。
伺服器尺寸編碼
Wit.ai 提出了一種 webhook 集成：它將每個“Bot sends”命令中的資訊傳遞到一個網頁伺服器中，並從中得到一個結果。通常你會在伺服器端創建或擴展對話語境。發送到 Wit.ai 的結果可以對聊天機器人端所使用的情境變數進行添加、修改和刪除。
優點
“故事”（story）這一概念很強大。
Wit.ai 允許使用分支和行動條件來控制對話流（例如，只在某些特定變數被定義時才顯示此消息）。
為實體分配角色有助於伺服器端的處理進程。
提出了“理解”（Understanding）單元來用樣本去訓練聊天機器人。
無法被聊天機器人處理的請求會被單獨列出，那兒有一個“收件箱”（Inbox）供開發者訓練機器人。
缺點
還在公測中。
即使 “故事”是一個很強大的概念，也存在難以控制對話流以及機器人傾向于誤解使用者請求的情況。
目前的限制：伴隨自然語言處理（NLP）和機器學習（ML）的改進
正如我們已經看到的，尤其是對於 Api.ai 和 Wit.ai 來說，要塑造一個聊天機器人就需要提供邏輯和語言資源，後者主要是輸入/輸出短語與實體。而這對於小型聊天機器人來說應該不成問題，但如果你打算處理很多專業術語及短語變體，那麼你就應該考慮使用自然語言處理和機器學習。我們來舉幾個這種情況下的應用案例。
單數和複數形式
如果你想讓你的聊天機器人提取“pizzas”作為一個實體，那麼僅僅定義“pizza”是不夠的，你還需要提供“pizzas”。
Api.ai 有一個功能叫做“自動拓展（automatic expansion）”，而 Wit.ai 有稱為“自由文本（free-text）”的實體。這些機制會嘗試基於單詞語境來捕捉新條目。所以如果你已經使用短語來訓練你的聊天機器人，比如“I’d like to order a pizza”，那麼它很可能會認為在“I’d like to order 3 pizzas”這句話中，單詞“pizzas”是一個實體。不過該功能的準確性取決於訓練過程，而你無法得知它會帶來多大的干擾。
一個有把握的選擇是為每個概念同時提供其單數和複數形式，可使用自然語言處理工具中的 inflectors 來生成它們。
同義詞、上位詞和下位詞（概念上外延更廣/窄的主題詞）
假設這樣一種情況，使用者想要一瓶汽水，但你的聊天機器人只知道具體的名目，諸如可口可樂或百事可樂，它們是汽水的下位詞。存在很多自然語言處理資源可以用來處理英語中的上位詞、同義詞和下義詞，比如詞庫（Thesaurus）和本體（Ontologies），但它們通常針對的是一些通用語言。因此，可口可樂作為一個非常具體的功能變數名稱，就不太可能屬於這種資源。
你可以嘗試去找到一個適合你的問題的現有詞庫，或自建一個詞庫。領域專家建立的資源價格昂貴但精確度高。你可以使用機器學習來創造語言資源，而深度學習技術則完全可以滿足你的個人使用需求。
情感分析
你想為你的聊天機器人加入一定程度的情緒反應嗎？那麼，你可以嘗試在伺服器端執行情感分析來快速適應回應。
然而這個任務如果使用 Api.ai 或 Wit.ai 則難以進行。如果你想得到一個非常靈活且語料豐富的聊天機器人，或許你應該考慮從零開始進行開發。
總結/最後的思考
顯然，聊天機器人呈上升趨勢，而我們在 Tryolabs 目睹了其快速增長的需求。如果做對了，這條用戶溝通管道就能夠為你增加訂單機會、提供一個更好的用戶體驗以及節約成本。然而實現過程絕非易事。
目前有大量的平臺可以幫助你創建一個聊天機器人。其中一些平臺已經利用所獲取的不同使用情況而被建立起來，所以很明顯，根據你的聊天機器人所針對的業務情況，有些平臺可能會比其它平臺更合適你。為了幫助你挑選出最佳的工具，我們回顧了現有聊天機器人搭建服務方的一些優勢及劣勢。
如果你打算建立一個複雜的聊天機器人，那麼你應該認真考慮一下穩定性、可擴展性和靈活性這三個方面。倘若你不夠重視人類語言的複雜性，一次談話很快就能偏離正軌。你可能需要從零開始建立自己的解決方案，或使用一個工具組合來解決一般的自然語言處理問題（即 Api.ai），以及為更強大的功能而選擇自訂伺服器端邏輯。
總之，聊天機器人生態系統發展很快，許多現有平臺所發佈的功能日新月異 。截至今天，很顯然當你雄心勃勃地試圖建立一個能夠處理複雜對話並採取行動（即付款）的聊天機器人時，你不能 100% 地依靠平臺，還需要定制化自然語言處理的發展。深度學習技術的最新進展可能在不久的將來會有很大幫助，我們對此非常期待。