萬字長文總結：如何設計與實現 SuperScript 互動式會話引擎（附PPT） | 硬創公開課

SuperScript 是一款開源的互動式會話引擎，它帶有弱AI、自然語言理解、簡單易用和靈活可擴展的特點。SuperScript 也是目前開源領域內最優秀的聊天機器人引擎之一，社區討論活躍、模塊構建合理，受到諸多自然語言處理相關開發者的追捧。

近日，雷鋒網 AI 研習社有幸邀請到了呤呤英語 AI 技術負責人 Hain，他從代碼實操的角度為我們詳細介紹了 SuperScript 系統的設計與實現。

嘉賓介紹

Hain，Rockq 開發者社區創始人，呤呤英語 AI 技術負責人，曾就職於 IBM 開發中心和創新中心。

Rockq 社區是 2015 年 5 月在北京建立的分享、學習型社區，主要面向 JavaScript 開發者，並拓展到機器學習和虛擬現實領域。本著「精益創新，竭盡分享」的精神，Rockq 已經舉辦過 30 余次不同內容的分享活動。呤呤英語是一家兒童英語在線教育服務公司，有面向兒童的國際化社交網路和高等專業的外教團隊。從2016年開始，Hain 開始探索聊天機器人的商業機會，以及如何使用深度學習和 NLP 技術研發聊天機器人，目前已經推出了兩款聊天機器人服務，幫助少兒學習英語。

公開課內容

以下為本次分享的完整視頻（約 40 分鐘）。

以下是文字版整理：

大家好，我是 Hain，今天我們分享一下關於會話交互系統 SuperScript 的設計與實現。

首先做一個簡單的自我介紹，我曾在 IBM 開發中心和創新中心工作過四年，後來又創辦了一個開發者社區 Rockq，現在在一家英語教育創業公司呤呤英語做 AI 技術負責人，同時也是一個開源愛好者。

這裡是我的 Github 地址和主頁截圖，大家可以看到，左上角是 DeepQA2，使用深度學習訓練的一個會話模型，右上角這個是用 Node.js 訪問科大訊飛的語音識別的 API，其他還有用 Docker 的技術來做 ELK 的 Service 等。同時我也整理過一些問答的語料，因為大家都知道，使用機器學習訓練問答系統的難點是特徵提取，而特徵提取的天花板其實是在於精確的語料。這裡我通過整理 10 萬個問答對，得到了 3000 個精確的問答語料。此外我還為一些聊天機器人平台寫過 Node.js 的樣例，以及做過 TensorFlow 相關的入門教程。

今天我們主要講的內容是聊天機器人對話引擎，即通過 NLP 的技術去處理人機對話系統。

作為開發者，我們首先要考慮的問題是要做一個什麼樣的服務。根據我的觀察，在 IT 領域大概每十年就會有一個大的改變，包括 1970 年代的主機系統，1980 年代以 Mac 為代表的個人電腦浪潮，以及 1990 年代的谷歌搜索為代表的互聯網時代的到來，到 2000 年代以 iPhone 為代表的手機移動互聯網的問世，還有 2010 年代微信的推出。我們就會猜想說下一個十年會出現一個怎樣的服務，發生怎樣的改變，讓人們的生活更便捷。我覺得應該是人工智慧。而在人工智能里，應該有一個殺手級的應用，我覺得這個應用是聊天機器人。

所以從去年 3 月初我就開始調研聊天機器人的相關技術，以及它能用在哪些行業，解決什麼問題。我本人目前是在一家英語教育公司做面向兒童的英語教育機器人。實際上這兩年湧現了一大批做聊天機器人的公司或者組織，其中大公司一般更偏向於做底層，做一些理論研究和平台化的服務，而其他小公司和創業公司則更多的是從應用層面出發，解決一些實際的問題。這裡我介紹三種比較典型的面向聊天機器人開發者的平台級服務。

第一個是微軟推出的 Botframework，它的主要特點是提供了一個跨平台的連接方案。因為我們可能會將聊天機器人的服務分發的許多不同的平台上，例如對接自己的 OA 系統，對接到 Telegram，對接到 facebook messager，或者是通過簡訊和郵件的形式與你的機器人進行對話。這個是 Botframework 提供的方案。

第二個是 API.AI，它是矽谷的一個創業公司，去年被谷歌收購，收購之後現在主要在做會話訓練、會話管理，同時也接入了谷歌的語音識別方案。它在利用用戶的數據進行機器學習的訓練方面其實是一個非常領先的平台，但是由於一些眾所周知的原因，訪問它需要翻牆。其實我們也調研過使用 API.AI 的優缺點，發現它更像是一個做信息助手的平台，因為你上傳了自己的信息之後，是由人工去做 intent 標記，然後派發 action。特別適合於做一些點餐的應用、打車的應用和問問天氣等。這兩年 API.AI 升級比較大的地方是不同知識域的會話，在你自己上傳的數據之外，它可以給用戶提供訓練好的語言模型，比如一些打車的服務，直接可以在它的平台上調用。

第三個是 Telegram Bot Store，它其實是一個專門為開發好的聊天機器人分發服務的地方，在這個平台上可以找到一些非常優秀的聊天機器人，可惜還是要翻牆。我自己體驗過的一個非常好的聊天機器人實際上也是在 Telegram 上找到的，而且這個機器人也給了我很大的啟發。

今天我們主要關注的是上面這張圖中 Logic 這一部分。可以看到，圖中左邊這個 STT 的主要功能是將語音轉換成文字，然後通過 Logic 的服務對文字進行處理，TTS 這個部分是將文字轉換成語音。目前這個 Logic 其實更像是一個弱 AI，它與大家想象中的人工智慧其實還有一定的差距。

從一些公開的資料來看，現在大部分公司的語音助手的實現方案都如上圖所示。STT 之後會經過一個 NLU 的模塊，進行自然語言的理解。這裡 NLP 一般是進行一些規範化的操作，比如識別一些專有名詞和地名，把主謂賓等一些簡單的語言結構分析出來，糾正一些常見的語法和拼寫錯誤，把一些時態相關的詞根分解出來等。NLU 之後會進入一個 DST 的部分，DST 的全稱是 Dialog State Tracking，也就是聊天狀態的跟蹤。一般聊天機器人都會有自己的處理規則，而在這個會話進入系統之後，右側的 Policy 會加入影響，來決定下一步在哪個地方進行處理。DST 處理之後會進入 NLG，也就是自然語言生成，就會生成一個新的語句，作為剛剛進來這句話的一個回復，傳遞給 TTS，生成對應的語音。

一般來說現在的 STT 和 TTS 都有一些很成熟的方案了。我嘗試過一些 STT 的服務提供商，包括微軟、IBM 和谷歌的服務等，國內的話嘗試過科大訊飛的服務和雲之聲的服務等。基於這個對比的話，我認為谷歌是最準確的，但其實也要分具體的場景，比如普通話、英語還是粵語等，但總體上我認為谷歌的技術是最領先的。但由於防火牆和其他一些原因，其實綜合考慮選擇科大訊飛是比較合適的。而 TTS 我認為做的比較好的是 IBM 的服務。

剛才也提到了，整體上這套系統是一個弱的 AI，其實你也可以叫它「人工智障」。從長遠的角度來看的話，它其實還需要一個長期的發展，讓它變得更加智能。如果我們現在去體驗一些已有的聊天機器人，包括微軟的小冰和百度的度秘，你會發現其實很多的回答都是通過搜索引擎的搜索獲得的，有的時候還會給我們返回多條記錄，這一點其實非常不智能。

在公司里一般都會將上面提到的 NLU、DST 和 NLG 等部分再細分為好多模塊，每個模塊都有專門的團隊負責維護。而像我們這些創業公司來說，一般都只有一些小的團隊來做，沒有足夠的資源去細分這麼多模塊，因此我們就更偏向於去藉助一些開源的項目。我們現在的實現方案是如下這張圖。

從圖中可以看到，最上面是一些微信小程序、微信公眾號等一些即時的通信服務，然後下面是 Inbound Message，也就是用戶發給聊天機器人的消息，然後再下面是 Bot Engine 即處理模塊，這是我們今天要講的重點。這個 Bot Engine 會負責分析這個語句，包括裡面的概念和命名，而且它也有規則引擎，它會有一些 Trigger 和回復，開場白等。這些會被定義在 Topic 裡面，也就是 Bot 可以跟用戶交流的主題，這裡主題又可以有許多類，比如打車、餐廳等。而整個 Bot Engine 還可以連接 Knowledge Graphics 做知識圖譜，將來還可以在知識圖譜里做更多智能化的查詢和推理等。這裡我們將 Bot 的知識分為三種類型，一種是 World Knowledge，即外部世界的知識，另一個是 User Knowledge，即用戶跟 Bot 聊天結束后積累下來的知識，最後就是 Bot Knowledge，即 Bot 自己的知識。

整體上講，Bot Engine 是一個承上啟下的關係，它需要有一個非常靈活的解決方案。而且因為聊天機器人是一個集大成的服務，比如這個 Bot Engine 可能要連接到知識圖譜的服務和搜索引擎等其他的服務，所以它是一個類似於中控一樣的平台。當我們寫的一些 Topic 沒有命中用戶想要聊的一些主題，也就是沒有辦法去回答一些問題的時候，我們就可以藉助於深度學習。

深度學習是在這個圖的最下面，叫做 Bot Model。Bot Model 其實是一個語言模型，我們通過演算法和數據注入這個深度學習框架里，經過框架的運行，結果就會給我們輸出一個模型。我們問模型一些問題，之後這個模型就會預測出這個回答可能是什麼樣的。實際上這裡我們嘗試過用 TensorFlow，使用了其中的 seq2seq 模型，加上我們自己的語料，結果發現效果還是不錯的。所以我認為，在接下來的一段時間裡，嘗試去積累質量更高更多的語料，應該是接下來工作的重點，因為數據是特徵提取的天花板，而特徵提取是深度學習智能化程度的天花板。

現在關於用深度學習來做 Bot Model 的訓練其實有非常多的演算法，包括增強學習和生成對抗網路等。在我們這張圖中，左邊這條線的意思是說如果我們能在 Bot Engine 裡面標註一些非常好的高質量的對話，那麼就能進入我們訓練好的模型，做一個增強學習。

整個圖實際上就是我們現在正在努力實現的一個願景。基於這張圖我們其實做了許多關於 Bot Engine 的嘗試，因為它實際上是一個相當於中控的地方。下面我們進入今天的正題，即如何實現一個 SuperScript 會話系統。

SuperScript 是 2014 年中旬左右由幾個開源愛好者做的一個開源項目，當時它就提出來要做一個 conversational UI 的理念，它其實借鑒了之前的 RiveScript 和 ChatScript 這兩個項目，另外它的主要作者貢獻了許多在 Node.js 裡面使用 NLP 的 package。這兩年根據我自己的比較，SuperScript 在 Node.js 領域，或者在我調研對比的 200 多個聊天機器人的開源項目里，SuperScript 應該是做的最好的一個平台。SuperScript 的使用其實非常簡單，在 Linux 平台使用 npm 命令安裝之後，其實就可以嵌入代碼使用了。

這裡需要強調的是，SuperScript 其實不是一個研究性非常強的項目，它更偏向於去實現一個應用，它更是一個 development technology。

SuperScript 為用戶開放的其實是非常簡單的介面，當我們使用它的服務是這樣的幾行代碼，就可以 setup 一個服務。比如說下圖中的代碼，我們在第一到第二行我們引用了 SuperScript 並聲明了一個 Bot，然後在第三行對 SuperScript 進行了一些配置。在第七行我們得到了一個 botInstance，這個 botInstance 包含了兩個核心的介面，一個是 reply，另一個是 directReply。當我們想和這個 Bot 對話時首先要傳入用戶的 ID，以及對話內容，然後就會通過 Reply 得到回復。而當我們有明確的想要聊的話題時，比如 hello 是屬於 greetings 類別，這時就可以使用 directReply 介面，直接傳入類別信息，然後取得回復。

下面是在 SuperScript 中生成 Topic 的過程，這裡和之前的 RiveScript 和 ChatScript 其實是很相似的。圖中展示的是通過腳本來生成對話，我個人在這裡非常推薦這種方式。因為現在很多像 Botframework 這樣的聊天機器人的平台，幾乎都要求一定的編程能力，想要實現一個對話能力，就要寫好多代碼，而且還要調試，對開發者以外的人來說有一定難度。但是 SuperScript 採用的這種方式很簡單，對開發者或者其他熟悉業務的人員來說都非常友好。

這裡先要寫一個 SS 文件，它有特殊的語法，使用前需要用自帶的解析工具對文件進行編譯，生成 data.json 文件。而這個 data.json 中就包括了會話中包括了哪些談話、開場白和回復等。而在今年 1 月份發布的 SuperScript 最新版本 V1 當中，這個編譯工具比上一個穩定版快了上百倍。這是因為它採用了一個全新的語法生成器。

簡單地說，用 SuperScript 來寫對話的語法主要有方式有上面這幾點。第一個是定義一個 Gambit 作為開場，也就是下圖中加號後面的部分，用戶輸入「i go by bus/train/car」中的任何一句，都會命中這條規則。

第二個也可以寫一個正則表達式，例如下面的「hello *2」，表示如果用戶輸入 hello 後面再加一個兩個單詞的人名，也會命中這條規則。

第三個是在 Gambit 中定義兩個字元串，然後在 Reply 中做回復。例如圖中的「*1 is taller than *2」就定義了包括兩個字元串的 Gambit，如果用戶的輸入符合這個 Gambit，則系統就會回復減號後面的那句話，其中 cap1 用 *1 代替，cap2 用 *2 代替。

另外 SuperScript 還支持多個回復，且系統會根據用戶設置選擇其中的一個回復。例如上圖第四個例子，當用戶多次輸入符合 Hello 正則表達式的語句之後，系統就會保留 keep 後面的語句，在其他場景下再次發送 。

我們看一個聊天機器人的智能程度，主要是看它處理上下文和帶有關聯關係的對話的能力。SuperScript 在這方面也做了許多優化。如上圖所示，Bot 問了一個問題說你叫什麼名字，這時代碼就會走到下面第 2 部分，根據用戶回答的名字通過 % 符號又定義了一個新的規則，用來承接上面的問題，用戶回答后才能進入下面的流程，即根據回答又問了 first name 是什麼。如果說還要接著進行會話，則還可以根據上一次的回復為基礎問更多的問題。比如這裡問 first name 是不是剛剛的那個回復，回答如果是 yes，則回復 ok。而如果回復不是 yes，則會進入第 4 部分代碼，返回重新開始對話的相關語句。

整個看起來，SuperScript 所支持的會話就是通過對應的 % 來找到對話中上下文的位置，然後進行對應的回復。這裡需要強調的是，代碼中的縮進並不影響執行，只是為了便於閱讀。

下面講一些更複雜的內容。在我們寫 reply 的時候其實是可以加入一些複雜的句式的，也就是函數。比如調用外面的系統獲取天氣信息，那麼就可以像下圖這樣採用角標加函數名的形式（getWeather函數）調用相關函數。具體函數的定義就如圖中下面的部分所示，這裡演示的是一些 JavaScript 的代碼。在 SuperScript 啟動的時候，用戶可以選擇 load 一些事先寫好的 JavaScript 代碼。相信大家也可以看到，這裡展示的天氣查詢實際上是通過函數回調的方式處理的。

另外，在 SuperScript 中通過一條語句也能調用多個函數，例如「+ It is ^fun1 and ^fun2」 這條語句中，就同時調用了 fun1 和 fun2 兩個函數。

同時 SuperScript 也支持嵌套函數的調用，如下圖所示。

作為一個 Node.js 的環境，SuperScript 還支持導入各種 Node.js 的包和模型。另外，在書寫一個 plugin 的時候，SuperScript 環境本身為函數提供了豐富的功能，如下圖所示。我們可以用 this.message 應用用戶所說的話，用 this.user 查詢用戶消息或者通話記錄，用 this.user.memory 引用 SuperScript 內置的知識圖譜圖資料庫等。

除了自己寫函數之外，SuperScript 還內置了一些實現好的函數供開發者直接調用。例如下圖所示的 topicRedirect 函數，用來在不同的 topic 之間靈活跳轉。

下面講一下知識圖譜的部分。這裡我們講的知識圖譜其實可以理解為我們為用戶建立的一個畫像，建立的用戶和用戶之間的關係。例如我們可以記錄用戶的大學專業、生日和喜歡的電影等個人信息，其實從數據結構來說很像是一個圖，在聊天機器人裡面得到了廣泛使用，因為相對便於分析和查詢。

從下面圖中右側的部分我們可以看到 SuperScript 中對知識圖譜的使用。系統會為每個用戶單獨建立一個 memory，Bot 引擎也有自己的 memory，它們共同的參照是一個上文提到的 World Knowledge，即通用知識。而遍歷、生成、查詢和使用這些知識的過程，就會使用一些 plugin，例如上面提到的 this.user.memory 對應當前用戶自己的 memory 空間，this.botfacts 表示 Bot 的空間等。這些空間的結構大約由三個部分組成：subject 名稱，predict 關係，以及 object 實體。

講完 SuperScript 的具體工作方式之後，我們下面講一講它底層具體是怎麼實現的。通過分析源碼我們發現，系統解析了腳本之後會生成 data.jason 文件，而 data.jason 文件其實是一個面向對象的模型。因為我們在編寫腳本的時候其實思路是面向過程的，比如先說了什麼，然後回復什麼，然後又說了什麼，等等。但是 SuperScript 在執行時其實是面向對象的，因此要首先解析成 data.jason。

如下圖所示，首先我們是定義了一個 topic，topic 對應了很多屬性，然後是開場 gambit，一個 topic 還會定義若干個開場，gambit 也有一些屬性，例如 filter 和 trigger 等，filter 就是上文提到的 % 後面的部分，而 trigger 就是正則表達式一類的觸發條件。一個開場 gambit 被命中以後，它會從內部包含的若干個 reply 裡面的檢索出條件最符合的發送出去，這裡 reply 也包含了 filter 和 keep 等這些屬性。而每個 reply 反過來又包含了若干個 gambit，系統不斷地處於等待回復和下一個開場之間，這樣一來就形成了會話。

另一個比較重要的內容是 ss-message，如下圖所示，這裡 ss-message 主要是處理了一些規範化輸入、取詞根、加入日期、判定問題和命名標識一類的操作。這些都得益於開源社區許多開發者所做的貢獻，而底層則依賴於許多學術和社區提供的服務，例如 WordNet 和 ConceptNet 等。

到這裡，Bot 雖然能根據用戶的問題回複信息，但其實 Bot 回復的信息還是和自然語言有一定差距的，這裡就需要有一個 Normalize 的過程。比如說，用戶輸入的是一個 emoji 表情，那麼系統應該能識別出這個表情是微笑還是生氣，這些功能都需要 Normalize。在 SuperScript 最新發布的 V1 版本中，最新發布了 bot-lang 這個模塊，其實也是開源社區的支持。它的主要功能就是實現這裡的 Normalize 的過程。

另外就是如何建立知識譜圖了，SuperScript 內置使用的是 LevelDB 支持這部分功能，它的速度非常快。如下圖所示，在 SuperScript 中主要通過 sfacts 模塊來實現。sfacts 提供了創建 DB 和載入 DB 的方法，同時它也允許用戶創建自己的 concept，創建自己的 DB 等一系列操作。

有時候我們需要在自己的聊天系統里創建 concept，例如商品的種類，當用戶的輸入匹配上某一種商品之後，我需要將流程導入到介紹相關產品或者下單的對話流程中去。而這些功能在工具里是沒有的，需要我們自己實現。

在 SuperScript 里載入自己定義的 concept 可以分為如下圖所示的三步。

第一步是創建一個 concept 文件，也就是聲明一下名稱和其中包含了哪些子類。

第二步是在通過解析工具生成 data.jason 文件的時候，需要引用第一步中聲明的 concept 文件。

第三步是在啟動 SuperScript 服務的時候要載入 concept 文件。

這就是載入自己定義的 concept 的過程。

另外一個 SuperScript 的核心，也是它與 RiveScript 和 ChatScript 等其他工具一個最大的不同，就是它實現了一種演算法，即怎樣從 topic 棧中獲取答案的演算法。如下圖所示，演算法的核心就是按照從左到右的語料庫順序依次排查，最左邊的優先順序最高，最右邊的優先順序最低。當收到用戶的問話時，系統會首先在 pre 標籤的 topic 中找尋 reply，如果沒有找到，則系統會通過 last reply 中獲取的當前聊天的會話，從當前會話中搜索 reply，如果還沒有找到，則系統會通過 TF-IDF 在以往聊天歷史中做一個詞頻排序查找，如果還是沒有找到，則會跳到一些沒有聊過的非系統 topic 中查找，最後，如果這些都沒有找到，就會從 post 標籤的 topic 中找尋。需要注意的是，這裡 pre 和 post 標籤都是系統規定的，但那內容需要用戶自己實現。

在 SuperScript 最新發布的 V1 版本中，它的 get reply 介面要比之前的老版本快數十倍。除此之外，在 V1 版本中，還有其他一些重大變化，具體如下圖所示。

首先是這個 FactSystem 以前用的是 LevelDB，它會在系統中產生一些 disk 文件，這個其實是不利於應用的，因為這個文件系統有寫進程的鎖，導致 SuperScript 只能是單實例的。但是在 V1 版本中，上層依然使用的是 LevelDB 的介面，但是下層它將數據都存儲到了 MongoDB 里。這個過程就會讓 SuperScript 相比過去有更好的延展性，在生產環境中這個意義是非常重大的。

第二個是開始支持多租戶的形式，以前 SuperScript 只有單實例，同時也只有一個 personality，就只能跑一個服務。

第三個是新版本使用了 ES6，使用 babel 編譯。這樣讓 SuperScript 兼容更多的新語言特性，同時也可能是許多介面速度大幅提升的原因。

作為國外的一個開源項目，其實 SuperScript 本身是不會考慮支持中文的。這一點對於我和其他關注 SuperScript 的國內開發者而言，是一個亟需解決的問題。

其實在 SuperScript 的社區討論組裡可以看到，相關的技術討論還是非常活躍的，有很多人參與。雖然官方沒有公布具體有哪些用戶在使用 SuperScript，但通過官方討論組可以看到它的用戶目前有幾百人。

隨著未來聊天機器人的越來越流行，我相信 SuperScript 會越來越流行，越來越引起大家的關注。

最後在這裡分享一個我自己做的網站： 裡面記錄了一些我的工作總結，類似 SuperScript 這樣的框架調研結果，以及關於深度學習演算法層面的東西。

謝謝大家。

問題1：目前國內公司的交互會話系統和谷歌、微軟等國外公司相比，差距有多大？

基於去年做的一些調研，國內的聊天機器人在客服、導購、老人小孩陪伴上都有嘗試，偏應用層面，比如助理來也和出門問問，在聊了一些之後，甚至會轉人工服務。而國內的大公司，前幾年並沒有發力，百度做了很多工作。我也關注今年騰訊的AI Lab也開始大量招並買馬。相對國外來說，起步較晚。

而國內的開源領域和研究機構，也不比國外活躍。在矽谷湧現了一些新的服務比如dashbot.io, kitt.ai, qnamarker.ai,api.ai,在國內還沒有看到特別好的copy。而且國外的開放語料比較豐富，由政府出面做了很多數據開放運動，包括dbpedia, wordnet, concept, imagenet都建立起來了。

做為一個開發聊天機器人的開發者，我覺得國外的工具比較多，國內還很欠缺，所以，我主要關注英語教育的聊天機器人。

問題2：能不能講一下詞庫的設計思路？

我們還沒有建設自己的詞庫，目前分詞使用了開源領域的庫，我們對於新詞的識別還是次要的，因為是根據美國國小課程設立的會話內容。我們主要是處理chglish，目前也是通過常見的拼寫錯誤識別方法和人工製作列表的方式進行。長遠的角度來講，我們希望積累到大量的數據，然後通過機器學習的方式來解決。

問題3：SuperScript 引擎的未來發展如何？

會對創業公司很有吸引力，包括集成Facebook Messager, Slack, Amazon Echo這樣的IM和硬體，SuperScript是很靈活和有優勢的，目前社區也相比其他對話引擎活躍，我覺得它會成為開源領域最流行的聊天機器人對話引擎。

問題4：人機對話中，可控性和智能型如何平衡？

我覺得現在開發機器人，主要由兩個部分組成：基於規則的檢索式的部分 + 基於機器學習的生成式的部分。而基於規則的部分，是開發者的可控性很強的，而基於機器學習的部分，得到的回復會超出人的解釋範疇，帶有數學的隨機特點。在我們的對話中，更傾向於對話包含知識，因為是面向教育的，所以，基於檢索的部分多一些，在基於檢索的系統中得不到好的答案，在進入機器學習的語言模型獲取答案。這樣整體上，就可以回答用戶的任何問題，而且效果看上去還不錯。

所以，可控性帶來更多的商業機會，比如個人信息助手，而智能型的可以帶來更多的樂趣，比如閑聊解悶。而像api.ai這樣的服務，通過人工標註 -> 意圖識別 -> 派發行為這樣的系統，是帶有更多可控性的，可以作為開發個人信息助手的選擇。而像tuling123的服務，是帶有更多智能效果的，可以作為開發閑聊機器人的選擇。當第三方的服務不能滿足需求，或者自己的技術團隊很棒的話，可以使用像SuperScript + Language Model這樣的方式開發自己的聊天機器人。在調研了很多第三方服務之後，SuperScript 讓我放棄了使用Botframework, TensorFlow讓我放棄了使用api.ai.

問題5：像這種聊天機器人，體積通常較小，比較便攜，感覺是不是可以在戶外也使用，小朋友出門也想帶著「朋友」一起出門的話，這一塊有沒有對應的應用場景分析過？

我見到過幾款這樣的智能硬體，外向像個蛋蛋，價格在七八百塊，創業公司在做，360也在做，甚至做成手錶，可以使用語音對話，它可以講故事。其實裡面就是運行android系統，加上應用。除了對話能體現出智能，其他部分沒有技術壁壘。市場也很接受，我覺得挺好的，但是怎麼提高更多價值呢？不能就賣硬體吧？我也思考過很多場景，我覺得這裡的機會非常多。

比如面向由自閉症，孤寡老人，兒童，都會帶來價值。但我覺得聊天機器人最好的入口還是VR或者AR。因為這樣有更強的代入感，會作出用戶更喜歡的產品。

我去年也體驗了很多設備，Hololens、Rift、Vive、主動式，被動式的VR設備，玩過賽車、射擊等遊戲。我覺得像HoloLens這樣的設備，搭載聊天機器人會成為劃時代的產品，入口已經不愁了，主要是聊天機器人的智能程度。

問題6：虛擬機器人和實體機器人哪個更可能成為機器人的主流趨勢？會有什麼優勢？

二者的性質不一樣，我更相信實物機器人會取代工廠生產線上的工人，虛擬機器人會取代呼叫中心的客服。不論何種機器人，自然語言處理，對話和意圖識別，都會讓這些機器人更能按照人的意願行事。

我覺得虛擬機器人的智能程度會更高一些，會更流行。因為虛擬機器人設定場景可能更便於機器人做判斷。

問題7：目前聊天機器人在上下文聯繫問答上到底是個什麼樣的水平？

關於上下文關聯，從演算法層面，要考慮在語言模型訓練時候，注入下面的數據：P - Personality matrix, U - User Relationship with Bot 以及 L - Lexicon。我也查找了相關的論文。這個處於前沿的探索階段，我還不知道從演算法層面上解決這些的成功案例。2015年, seq2seq 模型出現，而seq2seq的衍生模型，Seq2Seq attention/Seq2seqGAN 處理其實還是單論對話，訓練長度也有限，語句長度越長，系統越難調。而從工程角度上看，開發技術一般是考慮建立bot的系統畫像以及用戶的畫像，對話對上下文的分析也會限制在一個時間窗內。

比如SuperScript對上下文的分析就是開發者可以配置的，默認情況下，SuperScript在檢索回復的時候，會考慮過去5分鐘內，用戶說的最近的10句話。

我覺得這裡還需要融合更多的技術，比如建立知識圖譜和搜索引擎，然後在superscript的上下文，有更多的查詢能力。大家也可以去體驗一下微軟的小冰，google的allo和百度度秘。作為大廠的服務，這些應該具有說明意義。上下文關聯，是一個很大的挑戰。