閱讀469 返回首頁    go 阿裏雲 go 技術社區[雲棲]


阿裏雲智能語音交互技術實踐幹貨分享

阿裏雲技術總監/研發總監陳一寧博士通過直播分享了《阿裏雲智能語音交互技術實踐》。他首先介紹了智能語音麵臨的技術挑戰,然後對智能語音技術做了詳細介紹。其中,他主要分享了阿裏雲使用的BLSTM & LFR聲學模型的優化過程,並對基於深度學習的自然語言理解的不同場景進行了詳細分享。

 

以下內容根據直播視頻整理而成。

 

阿裏雲智能語音概述

阿裏雲智能語音交互=語音+自然語言處理,語音包括語音識別、語音合成、聲紋等,自然語言處理包括自然語言理解、對話係統、問答係統等。阿裏雲智能語音團隊不是一個簡單的算法團隊,其把算法包裝成引擎提供服務,在引擎之上有離線的pipeline與在線服務,在此之上包裝成各種各樣的產品對終端客戶提供服務。阿裏雲主要是以to B為主的企業,會做很多to B對應的工作。

智能語音技術挑戰

在阿裏集團內部,優勢是大量的數據,強大的計算能力,優秀的人才隊伍;挑戰是大量的業務,受限的人力。在公共雲服務上遇到的挑戰是個性化的需求和公共雲服務之間的矛盾。

c6ef979bc339052dcf79d76a70628e653ea308e5

上圖列舉了一些阿裏雲語音能力支撐內部客戶需求的一些場景,包括了客服類的產品等。

阿裏集團內部技術的挑戰

首先,大量的、多種多樣的業務,要求阿裏雲平台化發展,Scale永遠是一個問題,體現在采樣率包括8K、16K,錄音設備包括電話、手機、演講、車載、智能設備,場景上包括天貓魔盒、手機淘寶、螞蟻電話客服。在這種情況下,在阿裏雲內部形成了天生的ISV模式,即提供基礎的能力賦能給業務合作夥伴,和業務團隊共同成長。

90af00614cc62750d3054de19e1943222a2d9d23

阿裏雲不會直接麵對終端客戶,一般都是通過合作夥伴對外提供服務,合作夥伴會對產品做進一步的包裝,封裝成對應的自己的產品,滿足客戶的需求。這樣,阿裏雲就可以用一個核心的引擎服務各種各樣的用戶。

73ac365e27c6ccb1bc57cd010b77ced8ce6f5d3e

對於自然語言處理,必須要對語音做深入的理解。上圖中橫向是各種領域,縱向上各種不同的業務也會對自然語言理解有不同的要求。比如在車載環境就必須解決離線的問題。

de24bc2115de4926a067cead03321b17c0663adf

NUI平台架構如上圖所示,最右端是Speech Services,總的來看是一個基礎的架構。最上方是一些SDK等端上的服務,通過這些服務就可以服務不同的場景。

阿裏雲智能語音技術詳解

語音識別

模型訓練的Infrastructure

161527d30d5d4b3f2a83465ae6139ed7f45db15c

上圖展示了GPU多機多卡訓練架構,GPU多機多卡架構在深度學習中非常常見。阿裏雲將GPU多機多卡抽象了一層中間件,通過這個中間件把開源工具文件的讀寫、通訊之類的接口改寫掉。最下方是一些基礎設施,MaxCompute進行計算(CPU、GPU統一進行管理),在通信方麵以太網和Infiniband均使用,數據可以存儲在OSS或者MaxCompute上。

GPU Middleware功能特點包括:提供了API接口使得我們可以通過對訓練工具的簡單修改實現並行訓練;具有靈活性,自主管理任務隊列、數據分發、通信、同步等;Master-slave模式, 支持MA / SGD / ASGD等;不同GPU間通過API直接快速通信。

e064ca5c9e9f15db704cd3d2056c365d15ea7885

硬件圖是如上圖所示,右邊是GPU集群,集群之間通過Infiniband進行連接。集群和左邊存儲節點之間由超級交換機來連接。在實際的操作過程中,GPU集群的存儲能力比較差,整體的做法是:當需要數據的時候,就從存儲節點拉下來使用,用完之後再刪掉,通過不斷的交換來保證不會等待。

2223d2439105d8ade9e657ee895e265c73552d30

舉個例子,比如使用Kaldi + GPU middleware,不管是8 GPUs還是16 GPUs,加速比和全量相比沒有太大的差異。

BLSTM & LFR

a1453dd5a1de2e70ff128947e69ffad927989c75

從上圖中可以看出,聲學模型對於語音識別的準確率提高有至關重要的作用。不論是工業界還是學術界,在聲學模型方麵都做了大量的工作。近些年來,基於深度學習的聲學模型主導了語音識別的進步。阿裏雲使用了雙向的LSTM,2015年12月上線所有客服業務,全世界第一個產品落地;2016年3月阿裏雲年會實時字幕,是BLSTM全世界第一個實時業務落地。

afcbe4695391061f2f4209c240e3fd4925a5b149

LC-BLSTM,Latency control是要使雙向的LSTM反向部分的時延變得可控。在操作過程中分為兩段,中間表示實際運算的部分,藍色部分是用來計算反向的BLSTM的信息,這樣就不用需要看到整句的所有信息,可以通過BLSTM數據訓練得到很好的近似。

837d9079811be6285880dc298bd8435439dce534

從上圖中可以看出, WindowLength中的所有數據都用來計算,但是最終有效產出的是黃色部分WindowShift。

3d2c16c6174837e8d78d9385059686e21d618069

其實,藍色的部分沒有別的用處,隻是幫助黃色部分最右邊的節點初始化了其狀態信息,對其傳送的狀態做了重新設定。所以,可以用一個更簡單的模型來做(因為隻需要做初始化)。即使用Full Connect網絡+非線性函數做模型,對這個網絡進行初始化,由於是多層的LSTM,所以上方需要做近似,在原先的網絡基礎上再加一層,或者跳過剛才的網絡直接從底層預測上去。

36e6e1ba8618814c67e88d6396d87e5c526cb4c5

更進一步,反向的LSTM直接使用RNN,簡單的RNN可以使運算量有很好的提升。優點是隻在WindowLength內部使用RNN,即使出現問題也不會傳播很遠,對梯度等進行控製可以有效避免出現問題。

0f3684ad8f46cb3d5fff19c6abb600343f1095df

上圖回顧了語音識別解碼的過程,有一個傳統觀點:短時平穩信號做短時傅裏葉變換,幀移是10ms,幀長是20ms或者25ms,這是一個標準的模式。

c107edad944d7250eb9dbc0ec4b35623c90adf02

新的思路是,每3幀抽取一次特征做語音識別,立竿見影的好處是運算量變為原來的三分之一。但是,測試結果表明,錯誤率發生了明顯的提升。出現這種情況的原因是,中間兩幀的信號完全沒有使用,對於語音的完整性有損傷,特征不足不能得到一個很好的識別率。

8b7ad6561639de6cfcf9e49896d74ad855b58677

第一種優化是將幀加長,如上圖所示做了一個SuperFrame。超長幀可以描述更多的語音信息,這樣就可以得到一個比較好的識別效果。

4d36ee6986b93a42412e65bdcaeb9653fc4cb3cd

傳統的一個Phone、三個State是一個經典的做法,可能分到一個State上的幀會很少。因此對應的想法是, 將一個Phone用一個State來表示, 或者去掉State信號直接用Phone, 結果是錯誤率有進一步的減小。

7a91b9ca2ad7c75ef60aa5bba0fa8891d4ad3edc

在此基礎上,發現30ms太容易跨越一個因素的邊界了,對多目標進行優化,識別率和原先方法區別不大,而且速度提升了三倍。

0f28f5c301bbcf55902ca1c3a66f8fbc9f706371

其實可以上來直接做SuperFrame,直接走訓練過程,把三個狀態直接變成一個狀態,可以避免中間做一層一層變化帶來的潛在的各種問題。得到最終的End-to-end效果計算量為BaseLine的三分之一,錯誤率比BaseLine更好。

模型的魯棒性與個性化

提高模型魯棒性的方法是訓練更多的數據,具體過程包括:數據篩選(刪去重複的、沒有必要的數據)、+加性噪聲、+乘性噪聲(模擬不同場景信道情況)、+快語速數據、進行模型訓練測試和與結果分析。

5a7583ef2d6ca3a3f5711358dd7b4bd5c336e657

即使完成上述操作,模型已經相當魯棒了,但是在真實的情況下,每個租戶都有自己的需求,而且是五花八門的。所以,在基礎模型會摞上領域模型,在其上摞上租戶模型,在其上摞上用戶模型。

自然語言處理

46be3450b4c001bb202aa57b3780cf8a94e536cc

上圖是人機交互的經典圖,首先進行語音識別,然後自然語言理解,接著對話管理,最後進行服務。最終的結果分為兩種情況:麵向Task的對話,用戶主動,聊天,機器主動。阿裏更多是麵向Task的對話,這與其To B的業務模式有關。麵向Task意味著有多個領域、多個場景。如何做呢?答案是做雲+端有機協同的NUI平台(前文已提到,這裏不再贅述)。

d8a76bb559128baac271cc296bd9aaff21c94969

這個平台裏比較核心的內容是Open Dialogue。裏麵有兩個重要的部分:JSGF(理解),對話部分(執行對話)。當一個文本進來之後,需要理解其屬於哪一個Intention,從Intention中將內容抽出來,根據內容做各種各樣的操作,然後拿外部數據、JS腳本來執行。Open Dialogue的核心能力包括:語言理解能力,基於語法腳本和深度學習模型的語言理解,內置時間/地點/數量詞組件公共屬性的抽取組件,內置確認/取消/下一頁等公共意圖的處理組件;對話能力,用腳本驅動對話邏輯,支持自定義打斷和恢複機製;平台能力,提供運行腳本的引擎和服務,統一部署和監控,日誌采集和數據回流。

6a00d26b26ca6083616fe10725b38b0b7693b6a3

上圖是一個很常見的麵向任務的自然語言理解任務。我們首先需要進行分類其屬於的領域(飛機票領域),Intend是搜索機票,抽取裏麵的屬性(包括時間、目的地、航空公司選擇)。實際應用中碰到的問題比較多:多樣性的挑戰、魯棒性的挑戰、歧義性。

基於深度學習的自然語言理解

b3a98d42bb81d3149dba056009426941df26c629

在已知的領域上基本都采用深度學習的方式來做自然語言理解。在意圖判定上基本都是采用CNN的方式來判定,在屬性抽取上基本采用BLSTM的方式。

對話引擎

d10c75a9f7451a74a0fe72fc742f3b92657ed829

理解隻是對話的第一步,在此基礎上會做很多對話的管理。對話的管理可以通過雲端生成、調一個服務、讓客戶端做執行的工作。在整個對話的腳本語言裏麵,阿裏雲想解決的一個問題是任務之間切換的問題,即做任務邊界的劃分。基於Task Flow的對話腳本語言描述了任務的起始、中間步驟、扭轉和結束,可以指導上述工作。

d457549a5b04774bc3df810c14ab2b5ce3767a6c

上圖是一個典型案例,其中涉及到了屬性的Carry-over,當搜索火車票的時候選擇目的地、車次、時刻、購買,是一個正常的流程。中間過程中可能突然關心到天氣狀況。其實,問到目的地的時候,這些信息已經有了,就可以直接帶入後一個問題中獲得目的地的天氣狀況。此外,對於任務的打斷和返回,我們希望的是之前問過的信息仍然存在。

問答引擎

f716406e760bc659a7e1a02008db24d44e10b3d3

在問答領域,單輪問答是最常見的場景,其關鍵點在於Q-Q的相似性計算。當一個Question進來之後,我們在庫裏麵找到一個相似的問題,將其返回去作為有效的結果。其中,CNN、BLSTM方法都會用到。右圖的流程圖是一個比較古老的方式,實際使用的過程中發現上述流程並不是非常有效的。因為真實用戶如果是一個自由提問的場景,那麼Query一般比較長,很難通過抽取關鍵詞進行匹配,使得識別效果差很多,所以現在一般是直接在庫裏麵做相似度計算。多輪問答也是比較典型的場景,比如退貨的場景,同樣可以通過Open Dialog的方式完成任務。用戶可以指定自己的客服領域。

聊天引擎

阿裏雲也做了聊天引擎,其是基於<k,v>對的聊天引擎,具備讓用戶定製的能力,並且是基於深度學習模型的seq2seq聊天引擎,解決的問題包括:非任務性(如chat)的query占比60%左右;基於key-value的聊天模塊無法對用戶的任意chat輸入都能夠給出回複。

NUI平台定製能力

總結來說,NUI的定製能力包括:業務領域的語言理解Grammar、業務領域的對話過程、真實情況下可以做卡片和文本展示方式、問答係統。

智能語音技術未來展望/應用

在技術方麵,首先是越來越大的建模單元,然後是更加深度的網絡,最後是泛化能力更好的自然語言理解(從舉一反三變成舉一反十)。在應用方麵,主要有兩大場景:人機交互、數據價值挖掘。

最後更新:2017-04-19 23:31:08

  上一篇:go 多方位拓展之路:監控平台MongoDB實踐
  下一篇:go Packer & Terraform 讓 ESS 更靈活