畢業於北京大學計算機專業。git
因互聯早期研發工程師,完成項目包括金融搜索,公告摘要抽取項目,銀行問答機器人。程序員
某基金管理公司的量化分析平臺,資產配置平臺算法負責人。github
擁有多年金融NLP經驗,帶領團隊完成問答機器人、投研系統、監管輿情、知識圖譜等項目。對金融文檔解析、抽取、搜索、量化分析、知識圖譜建設、對話系統等領域有深刻研究。算法
Bot Friday Zero - 沙龍第0場分享小程序
關於對話系統/產品/技術api
2019-07-19 於北京騰訊,QHDuan機器學習
首先筆者認爲: 所謂對話系統,是經過對話的方式,實現人機交互的一種方法。ide
就如同鍵盤鼠標是輸入設備,顯示器音箱是輸出設備,輸入輸出是什麼?是與計算機交互。對話系統也如此而已。工具
Rasa是一家經過機器學習技術實現對話系統、機器人開發的工具,同時也是一家創業公司。學習
Rasa最新於2019年初A輪融資$13M。
筆者認爲Rasa最大的創新,是開發了整套的基於機器學習的對話工具,而相對的,如wit.ai,dialogflow(原api.ai),luis.ai等都不夠完整。
相對來講國內的unit,yige ai,更完整,可是不管是體驗、效果、社區等等都不如rasa。
我的認爲:程序員更愛工具,而不是平臺。
主要實現天然語言理解(即NLU)功能,本質上就是識別句子的意圖和實體。
如「買一張去北京的票」,咱們能夠定義一個意圖是「購票」,實體是「北京」和「一張」。
意圖識別本質是短文本分類任務(固然在學術界可能稱爲Intent Detection來和Text Classification分開)。 單純短文本分類任務的SOTA基本上就是BERT了。
抽取本質是信息抽取任務。 抽取的SOTA如今通常仍是BiLSTM-CRF的各類變型,或BERT之類。
如今學術界的主要研究方向是多種工做結合,例如同一模型同時作意圖識別和信息抽取,互相配合增長整體準確率。
Rasa的NLU,主要是當前的社區版,主要仍是使用了各類開源技術,並無追求學術上的SOTA。 它使用的工具包括Spacy、sklearn-crfsuite
筆者認爲這是Rasa的核心部分,NLU有各類實現,開源的也有snips nlu等,可是core卻獨一無二。
Rasa Core主要完成了基於故事的對話管理,包括解析故事並生成對話系統中的對話管理模型(Dialog Management),輸出系統決策(System Action/System Policy)。
學術上通常認爲這部分會包含兩個模型:
對話狀態跟蹤(Dialog State Tracking / Belief Tracking)
對話策略(Dialog Policy / Policy Optimization)
對於1.其實Rasa實現很簡單,具體在它的論文 Few-Shot Generalization Across Dialogue Tasks, Vlasov et at., 2018 中說的比較具體。就是簡單的基於策略的槽狀態替換。
對於2.Rasa使用基於LSTM的Learn to Rank方法,大致上是將當前輪用戶意圖、上一輪系統行爲、當前槽值狀態向量化,而後與全部系統行爲作類似度學習,以此決定當前輪次的一個或多個系統行爲:
Rasa的可視化編輯工具,更方便NLU、NLG數據的管理,故事的編寫。
Rasa X可能暫時還不能讓全部非開發人員也能快速方便的使用。不過它本質上能夠方便開發人員快速開發,快速訓練模型驗證。
筆者是這麼認爲的,Rasa X就好像小程序開發也要有個本地開發工具同樣,或者像Android Studio那樣的工具。本地工具的優勢就是方便調試、開發、快速驗證、Debug。相對線上的缺點就是速度慢、驗證須要等待後臺訓練、不便於Debug。
能夠看出國內外如今不少機器人平臺都是徹底在線的,例如國外的luis.ai,dialogflow等。這樣固然也能夠,可是總仍是不若有一個可本身訓練的終端對開發者更友好。 國內的就不說了。
再舉個例子,如Elasticsearch、Docker都是很是棒的工具,可是若是官方開始的時候說:你不能本身本地架設,你只能用個人雲服務。這樣對於不少開發者來講就必然喪失了很大的興趣。
Pipeline 的過程是這樣的:
用戶輸入文字,送入解釋器,即Rasa NLU
NLU給出結果,如圖
從Tracker到Policy,Tracker用於跟蹤對話狀態,Tracker輸出的是Embedding
用戶意圖的Embedding
系統動做(上一步)的Embedding
實體(槽值/Slot)的Embedding
Policy給出系統行爲
Tracker記錄系統行爲,下一次會提供給Policy使用
返回消息給用戶
用戶意圖和系統行爲會經過bag-of-word的方法分詞,而後向量化,頗有趣的結果。在官方論文沒有仔細探討爲何,筆者猜想是爲了增長不一樣的意圖、行爲之間的語義關聯。
論文原文:
A bag-of-words representations for the user and the system labels are then created using token counts inside each label.
例如:
action_search_restaurant = {action, search, restaurant}
實體/槽值(Slot)的向量化就很是簡單了,只是走了是否存在的binary向量
The slots are featurized as binary vectors, indicating their presence or absence at each step of the dialogue.
不少對話系統的系統決策都採用的是分類(Classification)方法,也就是每次老是在多個系統行爲中選擇惟一一個。
而Rasa選擇了排序方法,即判斷當前對話狀態和系統行爲的類似度,筆者認爲這有兩個可能的好處(論文沒說明):
能夠更容易實現多個系統行爲的同時輸出。能讓一個對話狀態輸出多個系統行爲是Rasa的特點。至於爲何如此,可能有工程上的一些考慮,例如這樣更方便,例如兩個系統行爲,一個是機器人說「請等待」,一個是真的去查詢數據。
更方便擴展系統行爲。若是是分類模型,增長一個分類,那必須從新訓練整個分類器。若是是Ranking模型,若是隻是增長或減小分類,能夠考慮只訓練新增的系統行爲相關的和不相關的部分數據集,可能增長整體的訓練速度。更方便快速實驗、迭代。
機器學習方法的好處是實際工程上代碼量比較少,不少狀態不須要寫判斷(對比專家系統)。
能夠作到不寫邏輯下,快速驗證某些場景或對話流。例如一個非開發者甚至能夠不須要寫一行代碼就能搭建某種原型機器人。
要作好一個比較複雜的機器人,仍是須要對機器學習有了解的工程師。
針對複雜的機器人,可能須要大量數據。