榨出聊天機器人的價值！用 Tensorflow 搭建能理解語境的客服小二！

AI 研習社按：原文載於Chatbots Magazine，AI 研習社編譯。

掌握對話溝通，語境為王。

我們將使用Tensorflow構建一個聊天機器人框架，向大家示範如何實現上下文的語境處理。

有沒有想過為什麼大多數聊天機器人缺乏會話語境？

我們將創建一個聊天機器人框架，為一個小島上的輕便摩托車租賃店建立一個對話模型。這家小店的聊天機器人需要處理營業時間，預訂選項等簡單問答。我們也希望它能處理客戶根據上下文提出的問題，例如關於同一天租金的查詢。體驗能做好的話，可以讓客戶的假期留下美好回憶！

這將通過三個步驟實現：

將對話意圖的定義轉換為Tensorflow模型

接下來，構建一個聊天機器人框架來處理響應

將基礎的上下文語料，整合進響應處理過程

我們將使用tflearn，一個基於tensorflow的Python包。 一般用iPython notbook作為輔助工具

把會話意圖的定義，轉化為 TensorFlow 模型

第一步，完整的notebook腳本可以在 GitHub找到：https://github.com/ugik/notebooks/blob/master/Tensorflow%20chat-bot%20model.ipynb

聊天機器人框架框架需要一個能定義會話意圖的架構。有一個簡潔的實現方式，是使用JSON文件：https://github.com/ugik/notebooks/blob/master/intents.json

每個會話意圖包含：

一個標籤（唯一的命名）

模式組（用於神經網路文本分類器的句子模式）

響應組

稍後我們將添加一些基本的上下文元素。首先是導入的包：

載入 JSON 會話意圖文件後，現在可以開始設計我們的文件、詞語和分類器的類。文件地址：https://github.com/ugik/notebooks/blob/master/intents.json

我們創建了文件（句子）列表，每個句子是一個由詞幹組成的列表，每個文件關聯一個意圖（一個類對象）。

詞幹"tak"將匹配「take」，「taking」，「takers」等。我們可以清理詞語列表，刪除無用的詞目。但現在這樣處理就夠了。

麻煩的是，這個數據結構不能用到Tensorflow，需要進一步轉換：從由詞語組成的文本轉換成由數值型變數組成的張量。

注意我們的數據是被打亂了的。Tensorflow將取出其中一些數據，並將其用作測試數據，以衡量新擬合模型的精度。

如果我們看一個單一的x和y列表元素，我們會得到詞袋數組，一個用於意圖模式，另一個用於意圖類。

現在可以準備建模了。

同樣的張量結構，也用在了 toy』 例子里的2層神經網路上，觀察理解這個模型擬合訓練數據的過程，會一直有用。

要完成這一部分的工作，我們將保存（ pickle ）模型和文檔，以便下一個notbook腳本可以調用。

搭建聊天機器人框架

第二步的完整notebook腳本看這裡：https://github.com/ugik/notebooks/blob/master/Tensorflow%20chat-bot%20response.ipynb

我們將構建一個簡單的狀態機來處理響應，使用我們（從上一步）的意圖模型作為分類器。這就是聊天機器人的工作原理。

語境聊天機器人框架，是帶狀態機的分類器。

導入相同的庫之後，我們 unpickle 模型和文件，並重新載入意圖文件。注意，聊天框架與我們構建的模型是分開的。除非意圖模式改變，否則不需要重建模型。由於有數百種意圖和數千種模式，模型可能需要幾分鐘的時間才能建立。

接下來，我們將載入保存的Tensorflow（tflearn框架）模型。需要注意的是，首先需要定義Tensorflow模型需要的數據結構，就像上一節所述。

在處理意圖之前，我們要想辦法把用戶輸入生成詞袋。這個技巧與我們以前使用過的訓練文本相同。

現在可以建立響應處理器了。

每個傳遞給response方法的句子都被分類。分類器使用model.predict（）並且非常快。模型返回的概率向量與我們的意圖按順序一一對應，生成潛在響應列表。

如果一個或多個分類結果高於閾值，就可以判斷一個標籤是否與意圖匹配，然後處理。我們將分類列表作為一個堆棧，並刪除棧頂來尋找合適的匹配意圖，直到找到一個或者棧為空。

我們來看一個分類示例，返回值中最有可能的標籤及其概率。

注意，「你的店今天營業嗎?」不是這個意圖的模式之一：「模式」: [「今天營業嗎?」, 「今天什麼時候開業?」, 「今天的營業時間?」] ；而不管對應項「營業」和「今天」 多麼適合模型（它們在選擇的意圖中是突出的）。

我們現在可以從用戶輸入中生成聊天機器人的響應。

以及上下文無關的其他響應..

讓我們利用一些基本的上下文，實現我們聊天機器人的拖欠租賃談話模型。

語境化

我們想要處理一個關於租賃摩托車的問題，並諮詢租金是否今天到期。是非問題是一個簡單的語境響應。如果用戶回答「今天」 ，上下文是租賃的時間範圍，那麼最好調取租賃公司編號1-800的問答響應。不佔用時間。

為了實現這一點，我們將把「狀態」的概念加入我們的框架。這包括用來維護狀態的一個數據結構，和在處理意圖時用來操作這個數據結構的特定代碼。

因為我們的狀態機的狀態需要容易維護，恢復和複製等等，所以很重要的是要把它全部保存在像字典這樣的數據結構中。

這是基本語境的處理過程：

我們的上下文狀態是一個字典數據結構，它將包含每個用戶的狀態。我們將為每個用戶使用一些唯一的標識（例如，元胞數）。這使得我們的框架和狀態機可以同時維護多個用戶的狀態。

在意圖處理流程中添加了上下文處理流程，如下所示：

如果一個意圖想設值相應的上下文，則可以這樣做：

如果其他意圖想要與上下文相關聯，則可以這樣做：

以這種方式，如果用戶剛剛輸入「today」而與藍色沒有關聯（無上下文信息），則我們的「today」意圖將不被處理。如果他們輸入「today」 作為對我們的Y/N問題（意圖標籤：「rental」）的回應，則意圖被處理。

上下文狀態更新了。

我們定義了「greeting」意圖來簡化上下文，就像通常的短對話一樣。添加一個「show_details」參數來幫助我們理解其中的含義。

再試試輸入「today」，這裡有一些值得注意的...

首先，我們對無上下文相關的「today」的回應是不同的。我們的分類產生了2個合適的意圖，而「opentoday」被選中，因為「今天」的意圖雖然較高的概率，而被限制在不再適用的上下文中。語境很有用！

有一些事情需要考慮了，那就是下面的語境化...

帶狀態的狀態模型

沒錯，你的聊天機器人將不再像無狀態的服務端那麼輕鬆愉快了。

除非要重置狀態，重新載入模型和文檔 - 每次調用您的聊天機器人框架時，那你都需要引入"狀態"概念。

這個不難。可以在其進程中運行一個有狀態的聊天框架，並使用RPC（遠程過程調用）或RMI（遠程方法調用）來調用，我推薦Pyro。

用戶界面（客戶端）通常是無狀態的，例如。HTTP或SMS。

聊天機器人的客戶端將調用Pyro函數，有狀態服務來處理。看，驚不驚喜，意不意外！

這是一個構建Twilio SMS聊天機器人客戶端的逐步指南，這裡是FB Messenger的一個實現。

別把狀態存到本地變數

所有狀態信息都必須放在像字典一樣的數據結構中，容易地持久化，重載或以原子複製。

每個用戶的會話將生成上下文，這將為帶有該用戶狀態的上下文。用戶ID可以用他們的元胞數，Facebook用戶ID或著其他唯一標識符。

有些情況需要（按值）複製用戶的會話狀態，然後作為意圖過程來恢復。如果狀態機在框架內帶有狀態相關的變數，那麼在實際中難以有效的。

所以現在你有一個聊天機器人框架，一個有狀態服務的方案，以及可以添加上下文的demo。以後大多數聊天機器人框架都將無縫地銜接上下文。

想想意圖影響和反應不同上下文（語境）設定的創意方式。用戶的上下文字典可以包含各種各樣的會話上下文。

來一起愉快地玩耍起來！

點擊展開全文

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