Rasa是一個開源機器學習架構，用于建構上下文AI助手和聊天機器人。
Rasa有兩個主要子產品：
- Rasa NLU：用于了解使用者消息，包括意圖識别和實體識别，它會把使用者的輸入轉換為結構化的資料。
- Rasa Core：是一個對話管理平台（同時處理多個對話，互不幹擾|上下文資訊會存儲到如redis中，進行管理），用于舉行對話和決定下一步做什麼。
story.md解析
Rasa的故事是一種訓練資料的形式，用來訓練Rasa的對話管理模型。故事是使用者和人工智能助手之間的對話的表示，轉換為特定的格式，其中使用者輸入表示為相應的意圖(和必要的實體)，而助手的響應表示為相應的操作名稱。Rasa核心對話系統的一個訓練示例稱為一個故事。
example：
<!-- ##表示story的描述，沒有實際作用 -->
## greet + location/price + cuisine + num people
* greet
- utter_greet
* inform{"location": "rome", "price": "cheap"}
- action_on_it
- action_ask_cuisine
* inform{"cuisine": "spanish"}
- action_ask_numpeople
* inform{"people": "six"}
- action_ack_dosearch
<!-- Form Action-->
## happy path
* request_weather
- weather_form
- form{"name": "weather_form"}
- form{"name": null}
其中story.md中主要包含3部分：
1、messages
使用*開頭的語句表示使用者的輸入消息，我們無需使用包含某個具體内容的輸入，而是使用NLU管道輸出的intent和entities來表示可能的輸入。需要注意的是，如果使用者的輸入可能包含entities，建議将其包括在内，将有助于policies預測下一步action。這部分大緻包含三種形式，示例如下：
（1）*greet表示使用者輸入沒有entity的情況；
（2）* inform{"people": "six"} 表示使用者輸入包含entity情況，響應這類intent為普通action；
（3）* request_weather 表示使用者輸入Message對應的intent為form action情況。
2、actions
使用-開頭的語句表示要執行動作(Action)，可分為utterance actions和custom actions，其中，前者在domain.yaml中定義以utter_為字首，比如名為greet的意圖，它的回複應為utter_greet；後者為自定義動作，具體邏輯由我們自己實作，雖然在定義action名稱的時候沒有限制，但是還是建議以action_為字首，比如名為inform的意圖fetch_profile的意圖，它的response可為action_fetch_profile。
3、events
Events也是使用-開頭，主要包含槽值設定(SlotSet)和激活/登出表單(Form)，它是是Story的一部分，并且必須顯示的寫出來。Slot Events和Form Events的作用如下：
domain.yml解析：
domain，譯為**“領域”**，它描述了對話機器人應知道的所有資訊，類似于“人的大腦”，存儲了意圖intents、實體entities、插槽slots以及動作actions等資訊，其中，intents、entities在NLU訓練樣本中定義，slots對應于entities類型，隻是表現形式不同。它還包括機器能夠說的templates 。
1、intent
2、entities
3、slots
slots，即插槽，它就像對話機器人的記憶體，它通過鍵值對的形式可用來收集存儲使用者輸入的資訊(實體)或者查詢資料庫的資料等。
4、actions
actions即bot的回應，rasa core支援3種action——default actions，utter actions和custom actions。
DefaultAction是Rasa Core預設的一組actions，我們無需定義它們，直接可以story和domain中使用。包括以下三種action：
- action_listen：監聽action，Rasa Core在會話過程中通常會自動調用該action；
- action_restart：重置狀态，比初始化Slots(插槽)的值等；
- action_default_fallback：當Rasa Core得到的置信度低于設定的門檻值時，預設執行該action。
UtterAction是以utter_為開頭，僅僅用于向使用者發送一條消息作為回報的一類actions。定義一個UtterAction很簡單，隻需要在domain.yml檔案中的actions:字段定義以utter_為開頭的action即可，而具體回複内容将被定義在templates部分。
CustomAction，即自定義action，允許開發者執行任何操作并回報給使用者，比如簡單的傳回一串字元串，或者控制家電、檢查銀行賬戶餘額等等。它與DefaultAction不同，自定義action需要我們在domain.yml檔案中的actions部分先進行定義，然後在指定的webserver中實作它，其中，這個webserver的url位址在endpoint.yml檔案中指定。
5、forms
6、responses
responses部分就是描述UtterActions具體的回複内容，并且每個UtterAction下可以定義多條資訊，當使用者發起一個意圖，比如 “你好!”，就觸發utter_answer_greet操作，Rasa Core會從該action的模闆中自動選擇其中的一條資訊作為結果回報給使用者。
7、sess_config
session_config，即會話配置，這部分的作用為配置一次會話(conversation session)是否有 逾時限制。 舉例來說：
session_config:
carry_over_slots_to_new_session: true
session_expiration_time: 60
每次會話的逾時時間為60s，如果使用者開始一段會話後，在60s内沒有輸入任何資訊，那麼這次會話将被結束，然後Bot又會開啟一次新的會話，并将上一次會話的Slot值拷貝過來。當然，我們希望舍棄上一次會話Slot的值，可以将carry_over_slots_to_new_session設定為false。另外，當session_expiration_time被設定為0時，Bot永遠不會結束目前會話并一直等待使用者輸入(注：執行action_session_start仍然可以開始一次新的會話，在設定為0的情況下)。
8、templates
bot可以說的東西的模闆字元串
一般來說，簡單的chatbot的domain.yml主要包含intents、entities、actions和templates。
policies說明：
Policies是Rasa Core中的政策子產品，對應類rasa_core.policies.Policy，它的作用就是使用合适的政策（Policy）來預測一次對話後要執行的行為（Actions）。預測的原理是衡量命中的哪些Policies哪個置信度高，由置信度高的Policy選擇合适的Action執行。假如出現不同的Policy擁有相同的置信度，那麼就由它們的優先級決定，即選擇優先級高的Policy。Rasa對提供的Policies進行了優先級排序，具體如下表：
每一輪對話中，定義在配置檔案中的每個policy在預測下一個action的時候都會有對應的置信度。如果兩個政策得到相同的置信度（比如，memorization和mapping policy的置信度總是1或0），将會考慮到policies的優先級。rasa policies為各個policy設定了預設優先級。大的數值意味着更高的優先級，是以一般情況下不會同時使用同一優先級的policy。
memoization policy
MemoizationPolicy隻記住(memorizes)訓練資料中的對話。如果訓練資料中存在這樣的對話，那麼它将以置信度為1.0預測下一個動作，否則将預測為None，此時置信度為0.0。下面示範了如何在政策配置檔案config.yml檔案中，配置MemoizationPlicy政策，其中，max_history(超參數)決定了模型檢視多少個對話曆史以決定下一個執行的action。
keras policy
KerasPolicy政策是Keras架構中實作的神經網絡來預測選擇執行下一個action，它預設的架構使用LSTM(Long Short-Term Memory，長短期記憶網絡)算法，結構為LSTM+Dense+softmax，但是我們也可以重寫KerasPolicy.model_architecture函數來實作自己的架構(architecture)。
embedding policy
EmbeddingPolicy，即循環嵌入式對話政策(Recurrent Embedding Dialogue Policy，REDP)，它通過将actions和對話狀态嵌入到相同的向量空間(vector space)能夠獲得較好的效果，REDP包含一個基于改進的Neural Turing Machine的記憶元件和注意機制，在該任務上顯著優于基線LSTM分類器。
目前rasa版本裡面embedding policy被替換為了ted policy，ted policy是transformer embedding policy，采用的是transformer結構。
redp架構主要目的便是計算dialogue states和system actions的表征，是以在inference階段，将目前dialogue states的表征和所有候選system actions的表征計算相似度，并選擇最高的actions作為輸出，并根據action的不同進行下一步動作。
論文中将結構分為4個部分，分别為：
featurization：第一步是将user input，slot，system action這些資訊進行特征化。
- user input主要是nlu子產品得到的intent和entity資訊；
- system actions将action名字中的詞作為特征（比如action_search_restaurant = {action, search, restaurant}），這些特征因為都是詞，是以各自都使用bag-of-words的方法進行表征；
- slot資訊将使用一個bianry vector進行表征，各個次元上代表的slot資訊出現了就是1否則為0。
embedding layer
對于user input, slots, system actions來說，embedding layer的參數各不相同，它是個dense layer。
attention
由于未來的對話是未知的，這裡面的attention隻能用之前時刻的資訊作為輸入，該子產品使用的是一個修改版本的NTM，attention機制采用的是tensorflow自帶的BahdanauAttention（tf.contrib.seq2seq.BahdanauAttention）。并且，針對user memory和system memory上的attention，分别使用了兩個不同的子產品。
lstm
lstm用于對話狀态追蹤：
- 輸入： user memory attention之後的結果與embedded user input相加，而後再将embedded slots vector拼接成一個向量作為LSTM目前輪的輸入向量；
- 輸出：LSTM的輸出向量（隐層接一個dense layer）與system memory attention的結果進行相加，這個作為目前輪的dialogue state embedding。
- 得到目前輪的dialogue state embedding後，會存入LSTM state中，并且會将所有前面輪數的相應dialogue state embedding與system memory attention中的二值化的attention權值進行相乘，進而可以實作在維護的所有曆史state中進行跳轉的目的（即跳轉到曆史的任意一輪的對話state中）。
存在的問題：
對于源碼中的attention子產品以及lstm的輸入有些不了解的地方
- 源碼中的兩塊attention的輸入分别是embed_utter和embed_prev_action，對于這兩部分是否是user memory和system memory存在疑問。
form policy
FormPolicy是MemoizationPolicy的擴充，用于處理(form)表單的填充事項。當一個FormAction被調用時，FormPolicy将持續預測表單動作，直到表單中的所有槽都被填滿，然後再執行對應的FormAction。
mapping policy
MappingPolicy可用于直接将意圖映射到要執行的action，進而實作被映射的action總會被執行，其中，這種映射是通過triggers屬性實作的。
fallback policy
如果意圖識别的置信度低于nlu_threshold，或者沒有任何對話政策預測的action置信度高于core_threshold，FallbackPolicy将執行fallback action。就是對話機器人意圖識别和action預測的置信度沒有滿足對應的門檻值，該政策将使機器人執行指定的預設action。
參考文檔
recurrent embedding dialogue policy：https://arxiv.org/pdf/1811.11707.pdf
transformer embedding policy： https://arxiv.org/pdf/1910.00486.pdf