想掌握對話溝通，語境為王。
我們将使用tensorflow建構一個聊天機器人架構，向大家示範如何實作上下文的語境處理。
有沒有想過為什麼大多數聊天機器人缺乏會話語境？
我們将建立一個聊天機器人架構，為一個小島上的輕便機車租賃店建立一個對話模型。這家小店的聊天機器人需要處理營業時間，預訂選項等簡單問答。我們也希望它能處理客戶根據上下文提出的問題，例如關于同一天租金的查詢。體驗能做好的話，可以讓客戶的假期留下美好回憶！
這将通過三個步驟實作：
将對話意圖的定義轉換為tensorflow模型
接下來，建構一個聊天機器人架構來處理響應
将基礎的上下文語料，整合進響應處理過程
我們将使用tflearn，一個基于tensorflow的python包。 一般用ipython notbook作為輔助工具
每個會話意圖包含：
一個标簽（唯一的命名）
模式組（用于神經網絡文本分類器的句子模式）
響應組
稍後我們将添加一些基本的上下文元素。首先是導入的包：
我們建立了檔案（句子）清單，每個句子是一個由詞幹組成的清單，每個檔案關聯一個意圖（一個類對象）。
詞幹"tak"将比對“take”，“taking”，“takers”等。我們可以清理詞語清單，删除無用的詞目。但現在這樣處理就夠了。
麻煩的是，這個資料結構不能用到tensorflow，需要進一步轉換：從由詞語組成的文本轉換成由數值型變量組成的張量。
注意我們的資料是被打亂了的。tensorflow将取出其中一些資料，并将其用作測試資料，以衡量新拟合模型的精度。
如果我們看一個單一的x和y清單元素，我們會得到詞袋數組，一個用于意圖模式，另一個用于意圖類。
現在可以準備模組化了。
同樣的張量結構，也用在了 'toy’ 例子裡的2層神經網絡上，觀察了解這個模型拟合訓練資料的過程，會一直有用。
要完成這一部分的工作，我們将儲存（'pickle'）模型和文檔，以便下一個notbook腳本可以調用。
語境聊天機器人架構，是帶狀态機的分類器。
導入相同的庫之後，我們 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。以後大多數聊天機器人架構都将無縫地銜接上下文。
想想意圖影響和反應不同上下文（語境）設定的創意方式。使用者的上下文字典可以包含各種各樣的會話上下文。
來一起愉快地玩耍起來！
====================================分割線================================
本文作者：吳楚