Rasa: OpenSource Language Understanding and Dialogue Management
摘要
這是一個用於構建會話系統的開源python庫，主要由兩個部分構成Rasa NLU（自然語言理解） 和Rasa Core（對話管理），這兩個軟件包都有大量文檔，並附帶一套全面的測試。該代碼地址：https://github.com/RasaHQ/
1 簡介
2 相關工作
Rasa的API使用了來自scikit-learn(專注於一致的API而不是嚴格的繼承)和Keras(不同后端實現的一致API)的思想，實際上這兩個庫都是Rasa應用程序的(可選的)組件。
Rasa nlu的性能優於各種閉源解決方案，使用條件隨機字段識別自定義實體。
Rasa的語言理解和對話管理完全脫鈎。這允許Rasa NLU和Core彼此獨立使用，並允許經過訓練的對話模型跨語言重用。對於語言生成，我們鼓勵開發人員通過為每個響應創作多個模板來生成各種響應。Rasa Core也沒有考慮到語音轉錄和NLU的不確定性，正如通常使用部分可觀察馬爾可夫決策過程（POMDP）所實現的那樣。
3 代碼說明
Rasa的架構采用模塊化設計。這樣可以輕松與其他系統集成。例如，Rasa Core可以與Rasa NLU以外的NLU服務一起用作對話管理器。
3.1 架構
對話狀態保存在tracker對象中。每一個對話會話都會有一個tracker對象，這是唯一一個有狀態的組件。tracker存儲槽，以及導致該狀態和在對話中發生的所有事件的日志。可以通過重放所有事件來重建對話的狀態。
當收到用戶消息時，Rasa會采取一系列步驟，如圖1所示。第1步由Rasa NLU執行，所有后續步驟均由Rasa Core處理。
- 上圖接受消息並將它傳遞給Interpreter(解釋器)（例如：Rasa NLU）來提取意圖（intent），實體（entity）和其他一些結構化信息。
- Tracker（追蹤器）保持對話狀態，他接收到新的消息的通知。
- Policy接收tracker的當前狀態
- Policy選擇下一個動作（action）
- Tracker記錄選擇的動作（action）
- 執行操作（這可以包括向用戶發送消息）
- 如果預測的操作不是“監聽（listen）”，請返回步驟3。
3.2 Action（動作）
我們將對話管理問題定為一個分類問題。在每次迭代中，Rasa Core預測都會從預定義列表中提取動作（action）。動作可以是簡單的話語，即向用戶發送消息，或者它可以是執行的任意函數。當一個動作（action）被執行時，它被傳遞到一個tracker實例中，因此可以利用在對話歷史中收集的任何相關信息：插槽，先前的話語和先前動作的結果。
Actions(動作)不能直接改變tracker，但是在執行時可能會返回事件列表。tracker使用這些事件來更新它的狀態。有許多不同的事件類型，例如SlotSet，AllSlotsReset，Restarted等。完整列表在文檔中地址如下：https：//core.rasa.ai
3.3 自然語言理解（NLU）
Rasa NLU是自然語言理解模塊。它包含松耦合的模塊，在consistent (一致的)API中結合了許多自然語言處理和機器學習的庫。為此，預定義的管道（pipelines ）具有合理的默認值，適用於大多數用例。例如，推薦的管道 spacy_sklearn，使用以下組件處理文本。首先，文本被標記化並且使用spaCy NLP庫注釋詞性（POS）。然后spaCy featuriser 為每個注釋查找一個GloVe向量，並將它們匯集起來以創建整個句子的表示。然后，scikit-learn分類器為數據訓練一個估計器，默認情況下，使用五折交叉驗證訓練多類支持向量分類器。然后，ner_crf 組件使用標記和詞性標簽作為基本特征，訓練條件隨機字段以識別訓練數據中的實體。由於這些組件中的每一個都實現了相同的API，因此很容易交換（比方說）GloVe向量，對於自定義，特定於域的字嵌入的，或者使用不同的機器學習庫來訓練分類器。還有其他組件用於處理詞匯外單詞和對於更高級用戶的許多自定義選項。所有這些詳細的文檔說明都在：https://nlu.rasa.ai。
3.4 Policies（策略）
policy的作用是在給定tracker 對象的情況下選擇要執行的下一個操作（action）。policy與featurizer被一起實例化，featurizer在給定tracker的情況下創建當前對話狀態的矢量表示。
標准特征描述符合以下功能：
最后一個action是什么；
最近用戶消息中的意圖和實體；
目前定義了哪些插槽。
槽（slot）的特征可能會有所不同。在最簡單的情況下，槽被單個二進制向量元素表示，顯示它是否被填充。槽作為分類變量被編碼為 1/k 個二進制向量，那些（向量）具有連續值的（向量）可以指定影響其特征的閾值，或者簡單地作為浮點數傳遞給featurizer。
有一個超參數 max_history，它指定了包含在特征中的先前狀態的數量。默認情況下，狀態堆疊形成二維數組，可以通過遞歸神經網絡或類似的序列模型進行處理。在實踐中，我們發現對於大多數問題，max_history的值在3到6之間是很好的。
4 用法
4.1 訓練數據格式
Rasa NLU 和 Core都使用人類可讀的訓練數據格式。Rasa NLU需要一個帶有意圖和實體標注的話語列表。這些列表可以指定為json格式或者是markdown格式。markdown格式非常的經湊且容易閱讀，可以由許多文本編輯器和Web應用程序（如GitHub）呈現。
閱讀json格式會有稍微的麻煩，但是（它）空格不敏感，更適合在應用程序和服務器之間傳輸訓練數據。
Rasa Core使用markdown來指定訓練對話（又名“故事（stories）”）
一個故事以一個名字開頭，前面有兩個“#”
名稱地選擇是任意的，但是它有助於調試。故事的主體是一系列事件，由換行符分割。一個事件如下：
用戶的表達注釋為一種對話行為。一般格式：
其中實體是由逗號分隔的鍵值對。系統操作也是事件，由以破折號開頭的行指定。故事的結尾用換行符表示。
4.1 機器教學
除了監督學習之外，Rasa Core還支持機器教學方法，通過系統開發人員可以做出正確的操作（action）。我們發現用於生成訓練數據這是一種實用的方法，並探索合理有效的對話空間。
以下是用戶參與餐館推薦系統的機器教學的示例（在第5節中描述）。向用戶顯示以下提示
如果用戶輸入2，表示操作錯誤，將向他們提供如下提示，其中列出了對話策略可能的操作和分配給他們的概率：
選擇正確的操作會創建一個新的訓練數據點。然后，Rasa Core訓練部分對話政策，並將對話推進到下一步。完成后，訓練的模型將保持不變，新生成的訓練數據將保存到文件中。
4.3 對話圖可視化
Rasa Core還具有可視化訓練對話圖表的功能。故事（story）圖是將動作作為節點的有向圖。邊緣被標記為在兩個操作執行之間發生的用戶話語。如果兩個連續動作之間沒有用戶交互，則省略邊緣標簽。每個圖都有一個名為START的初始節點和一個名為END的終端節點。請注意，圖表不會捕獲完整的對話狀態，並非沿着邊緣的所有可能的行走(walk)必然發生在訓練集中。為了簡化可視化，使用啟發式方法合並相似節點。如圖2所示運行簡化之前和之后生成的圖形。在簡化期間，將兩個節點合並為一個節點，該節點繼承所有傳入和傳出的邊，刪除流程中的重復項。這使得生成的圖形更容易解釋。
如果滿足以下兩個條件，則合並節點：
•它們代表相同的行為
•對於所有指向節點的對話，前面的max_history循環都是相同的。
圖2：說明故事圖如何簡化的最小示例。訓練數據包含兩個具有相同第一次交互的故事。因此，這些節點被認為是等效的並且被合並。
4.4 在生產環境中部署
Rasa NLU和Core的存儲庫都包含用於生成靜態虛擬機（VM）映像的Docker文件。這有助於重現性和易於部署到各種服務器環境。運行HTTP API的Web服務器支持基於線程和基於進程的並行性，允許它們在生產環境中處理大量請求卷。
5 演示
為了演示Rasa Core的用法，我們使用BAbl對話數據集[2]。這是一個簡單的槽填充練習，要求系統搜索餐館，並且必須填寫幾個槽才能進行成功的搜索。系統可以詢問用戶他們對任何槽的偏好。可用的插槽是位置，人數，美食和價格范圍。
由於問題的固有非線性，這是一個有趣的數據集 - 有多種方法可以獲得相同的信息，因此在每種情況下都沒有單一的“正確”操作。因此，准確性和精確度不是評估對話政策的最合適的指標。相反，我們會考慮系統如何根據已有的信息選擇操作。它應該嘗試填充空的插槽。
在圖3中，我們可以看到Rasa Core在給定已知的插槽的情況下附加到每個操作的概率。我們看到Core遵循粗略的詢問菜餚模式，其次是位置，然后是人數 - 就像在培訓數據中一樣。然而，它認識到它還可以通過將非零概率歸因於每個未填充的時隙來詢問其他未填充的時隙。填充的槽（“網格”的下對角線）給出的概率很小。這說明了Rasa Core如何使用上下文線索來學習非線性對話。
6 展望
Rasa NLU和Core都在積極開發中。它們可以作為非專業開發人員使用的會話AI應用研究的平台，因此永遠不會“完成”。許多主題正在積極開發中，包括改進對強化學習的支持，使NLU對拼寫錯誤和俚語具有強大的支持，並支持更多語言。我們還計划發布實際數據集，以比較不同模型的性能。作者歡迎對該項目的外部貢獻，其中的具體內容可以在GitHub上的存儲庫中找到。
圖3：這里我們繪制了為bAbl示例選擇動作的概率（第5節）。我們按順序通知系統正確（上下）：美食，位置，人數和價格，系統根據已有的信息選擇下一個操作（左上方框中列出）。系統傾向於詢問尚未被告知的插槽，直到所有插槽都被填充並且它搜索餐館。