前言
最近在看一些基于如bot framework這樣的平臺搭建個性化的聊天機器人的資料令境，看的不多也不深，寫下來談一點自己的理解，主要是關于整個流程尤其是上下文設計的一些思考。這里尤其想感謝下一位作者的分享，我也是在看過他對bot framework的一些闡述后才能不那么膚淺的去看這個話題抛人，所以也參考了許多他文章中的見解。參考鏈接如下：
談 Bot Framework（以Facebook的wit.ai為例）
談 Bot Framework 中的上下文（Contexts）設計
概述
1. Bot Framework
Bot Framework是微軟開發(fā)的一款可讓任何人制作自己的聊天機器人脐瑰，按其自己的說法妖枚，或者說更深入的應該理解為“一個用于搭建、鏈接蚪黑、測試盅惜、和部署智能機器人的平臺”。用戶可以在這個平臺上忌穿，在模式上通過其定義好的規(guī)范和組件來搭建聊天（或會話）機器人抒寂，在內(nèi)容上可以個性化的定制，面向個性化應用提供服務掠剑。
目前國內(nèi)國外有很多這種聊天機器人搭建平臺屈芜，比如微軟的Bot Framework、Facebook的wit.ai朴译、Google的api.ai井佑、阿里的云小蜜和百度的dueros等等。
2. Frame-based chatbot
解釋frame-based chatbot之前眠寿，先提兩個概念：QA system和Dialog system/chatbot躬翁。
按照阿里對問題的分類，可以分為三類：
問答型：特點是依托結構化程度高且關聯(lián)性高的領域知識盯拱，針對問題盒发，返回知識作為答案。
任務型：特點是面向具體任務狡逢，同樣依托領域知識的概念宁舰，每個任務負責獨立的業(yè)務流程，任務之間相對互斥性強
閑聊型：特點是不是面向具體目標奢浑，語義意圖不明確蛮艰，領域不局限
兩種system概念根據(jù)具體的目標和問題分類進行區(qū)分。QA system（問答系統(tǒng)）主要針對解決問答型問題雀彼，而Dialog system/chatbot（對話系統(tǒng)/聊天機器人）針對解決任務型和閑聊型問題壤蚜。再具體的說即寡，QA system關注單輪系統(tǒng)對用戶query的response，而相比之下chatbot更加關注單輪的上下文以及多輪對話的需求仍律。
在兩種系統(tǒng)內(nèi)嘿悬，又分別按技術路線細分。比如QA system可分為ir-based（基于檢索）和knowledge-based（基于大規(guī)模結構化知識庫水泉，比如知識圖譜）；Dialog system/chatbot也可分為rule-based（基于規(guī)則）窒盐、ir-based和frame-based等草则。
frame-based直譯過來是基于框架，其實指的是主要通過槽位填充的方式理解intent（用戶意圖）蟹漓，然后解決會話需求的會話機器人炕横。它針對每個intent定義一個frame，作為以槽位填充為主要目的的會話流程的模式葡粒，如針對用戶訂機票這個intent的frame樣例：
frame主要內(nèi)容為field和prompt份殿。field定義了該intent需要填充的slot（比如訂機票的slot為origin、destination和departdate）和每個slot對應的prompt嗽交；prompt為提示話術卿嘲，主要是系統(tǒng)為了填充slot的提示語句，具體可分為針對每一個slot的提問prompt夫壁、對識別的slot值追加的confirm prompt以及在用戶無輸入或系統(tǒng)無法識別時的系統(tǒng)默認prompt拾枣。當用戶intent產(chǎn)生時，系統(tǒng)可以根據(jù)frame定義的模式執(zhí)行操作盒让。
對整個流程尤其是context的一些理解
frame-based chatbot在會話流程中按順序主要完成三個任務：識別domain→識別intent→填充slot
識別domain指識別識別會話所在領域梅肤，使用相應領域的知識做知識庫，比如訂機票這個任務屬于“出行助手”（打個比方）領域邑茄；識別intent指用戶意圖的識別姨蝴，具體做什么任務，比如“訂機票”肺缕；填充slot不用解釋左医，對origin、destination和departdate三個slot通過會話進行填充搓谆，最終按識別的意圖執(zhí)行任務炒辉。他們幾個的關系可以表示為：
一個domain對應多個intent，每個intent對應一個frame
同一domain下或者是可繼承（上下文可繼承）的intent間有時會共享相同的slot泉手，比如訂飛機票和訂火車票共享“出發(fā)地”黔寇、“目的地”和“出發(fā)時間”，所以intent和slot是多對多的關系斩萌。
本文有一些不同于參考文章的在于對context和lifespan的理解：
上圖展示了整個會話從識別domain到execute的流程缝裤。對于context的意義屏轰，我很認同參考文章中“作為信號，影響 Intent 的識別”和“作為載體憋飞，存儲已填寫的 Parameter Value”兩個作用霎苗。但我認為，可以將整個會話的context細分為兩種榛做，一種是父context唁盏，即圖中紅框表示的，從識別了domain開始检眯，父context即開始生命周期厘擂，存儲所有的intent的slot和value信息，無論是在同一個intent下對slot的刪改還是在可繼承的intent之間的場景轉(zhuǎn)換锰瘸，同名slot的value是共享的刽严；另一種是子context，即通常framework平臺中所描述的intent之間的inputContext和outputContext避凝，用于識別intent或者是slot的繼承舞萄，我認為，子context中存儲的實際上是slot的key信息管削，即在intent下所需要填充的slot列表倒脓，在場景切換時，不斷更新或繼承列表中的key佩谣，在確認了所有intent后直接去讀取存儲在父context中的value值即可把还。這樣的話，我們不需要事先定義context的生效輪數(shù)（lifespan）茸俭，只要在父context下吊履，所有場景都可以訪問或者說繼承到已填充過的slot value。當遇到不可繼承的場景切換或更改domain時调鬓，直接清空父context信息艇炎。這種intent間共享slot值也對應了之前所說的intent和slot多對多的關系。
總之腾窝，對應于context的兩種意義缀踪，父context作為載體，存儲已填寫的slot value虹脯；子context（input/output）有時作為信號驴娃，影響intent的識別，有時作為載體循集，存儲intent所需的slot的key唇敞。
基于dueros搭建樣例
筆者嘗試了下利用dueros搭建一個簡單的聊天機器人demo。具體的操作不贅述，dueros官方文檔寫得很詳細疆柔，主要介紹下整個流程和之前講的會話流程對應信息咒精。
定義技能名稱：即定義domain
定義意圖：定義domain下的intent
定義槽位：其實是在定義intent的frame，包括slot和prompt旷档。
至于詞典和常用表達的訓練是用于slot信息識別
定義意圖確認話術（補全frame中的reimport模叙，confirmImport）
以上就是基本的定義流程，然后當會話開始時鞋屈，按照模式進行slot填充最后執(zhí)行
以上只是個人的一些理解范咨，望批評指正。
