智能語音交互技術在360的落地實踐

本次分享的主要內容包括:
1. 對話系統(tǒng)的基礎知識
2. 360智能語音交互平臺介紹
3. 對話核心技術:語義理解、對話管理、QA
▌對話系統(tǒng)的基礎知識






-
規(guī)則匹配,也就是精確匹配,可以解決 top query,規(guī)則匹配沒有泛化能力。 -
生成模型,基于規(guī)則匹配的泛化 ( 請注意這里生成模型是內部說法,并不是"生成式模型 ( Generative Model )"的概念 )。 -
相似度匹配模型,主要應用在沒有槽位 ( slots ) 的語義理解,如用戶說"我要聽歌",我們可以找到相似的 Query,根據(jù)相似 Query 的反饋回復用戶。 -
深度模型,我們做了 SF-ID ( Slot Filling and Intent Detection ) 聯(lián)合學習的方案。
規(guī)則匹配和相似度匹配的方案大家都比較熟悉,這一節(jié)我們主要分享生成模型和深度模型。
① 語義理解-生成模型
我們的生成模型是基于匹配模型的泛化,是完整精確匹配與片段式匹配的區(qū)別,類似隱馬爾可夫模型,我們可以用轉移序列和發(fā)射序列進行匹配。例如下圖中,我們的標注人員只標注了3種句式,直接匹配只能匹配這三種說法。我們增加了 3-gram 模型進行匹配,將原始序列拆成三元片段,在這個基礎上通過 beam search 進行解碼,這樣像例子中的3條語料,在實際匹配中可以額外泛化出6種句式,達到了很好的效果。
這里還可以加上三元回退、二元回退、停用詞、同義詞等,還可以把泛化效果做的更好。
② 語義理解-深度模型 SF-ID
業(yè)界通用型的 NLU 一般會先過意圖識別模型,再將識別出的意圖傳給槽位識別模型進行判斷。整個 Pipeline 如下:
經(jīng)過我們的技術分析和業(yè)務反饋,這樣的流程有以下問題:
誤差傳遞。即意圖識別模型判斷錯誤,會影響槽位識別的效果
沒有引入外部知識。如"播放忘情水"的意圖應該是 play_music,而"播放白雪公主"的意圖應該是 play_story
OOV問題。如用戶說"播放你的酒館打了烊",真實意圖是"播放你的酒館對我打了烊",用戶說錯的時候沒有辦法解決
我們的槽位-意圖識別 ( Slot Filling – Intent Detection ) 的方案有一個演進過程,針對這些問題我們的方案如下:
首先是誤差傳遞問題,這個問題的解法,我們有兩個階段。最開始我們的模型是 LSTM-CRF,針對它效果不好的問題,我們首先加了 Attention,并且 Softmax 和 CRF 可以互換調整。第一個比較大的提升是采用聯(lián)合訓練的方式,也就是 Slot Gated Modeling 這篇論文[1]的方案。
這個方案引入了 slot gate,模型在預測公式上引入了 intent 影響,論文里用的標注模型是 Softmax,但我們換 CRF 后效果會更好。有些情況 Softmax 標注的序列中,I 標注會在 B 前面 ( ps:這個是序列標注問題的標注類型,B:Begin,I:Inside,O:outside,即序列的開始、中間、結束 ),但 CRF 不會將 I 標注在 B 前面。這個可能是因為 Softmax 更專注于局部信息,但 CRF 是對全局的概率轉移進行了建模。
接下來,我們又更新到了 SF-ID 模型。比較巧的是這個方案的作者當時在我們組工作,也就把這個思路帶來了,后來論文[2]被 ACL 2019 發(fā)表了。這個方案和 slot gate 方案的主要區(qū)別是,slot gate 方案中只有 intent 影響 slot,slot 的結果不能對 intent 起作用,還是有誤差傳遞的情況;新方案的 SF-ID 是兩個子網(wǎng)絡,兩個子網(wǎng)絡互相迭代訓練,兩個子網(wǎng)絡互相傳遞信息迭代,這樣就把 intent 對 slot 的單向影響變成了 intent 和 slot 互相影響。大家若有興趣,歡迎看一下參考文獻中第二篇論文。
基于聯(lián)合訓練 SF-ID 兩任務的思想,我們基本在模型層面解決了誤差傳遞的問題。
接下來我們討論一下外部知識的引入。我們的經(jīng)驗是沒有外部知識 ( 輸入層增加 knowledge vector ),模型效果并不好。但引入外部知識之后,準確率馬上提高了15%。
舉個例子,用戶說"播放張學友的吻別",我們通過外部知識可以打上標簽 ( 張學友:張:B-singer、學:I-singer、友:I-singer;吻別:吻:B-song、別:I-song ),于是可以在 word embedding 的基礎上增加 knowledge embedding,如圖所示:
再就是 OOV 問題,這個問題業(yè)務上比較困難,因為用戶如果說的是"你的酒館打了烊",但這個并不是歌名,知識庫也就引不進去了。我們的做法與 NER 類似,首先學習槽位邊界,提供多種解碼路徑,如路徑1:意圖為 play_music,并給"你的酒館打了烊"打上 like_song ( 疑似歌曲 ) 的標簽;路徑2:意圖為 play_story,并給"你的酒館打了烊"打上 like_story ( 疑似歌曲 ) 的標簽。接著通過知識庫進行校驗,我們根據(jù)編輯距離、文本相似度等策略可以判斷路徑1的置信度更高,因此選出路徑1。具體可見 Rank 策略。
③ 語義理解-Rank
這個步驟是多路徑選擇消歧,即獲取到多個解碼路徑后,我們選擇一個置信度最高的,作為語義理解部分的結果。Rank 階段我們主要采用的還是經(jīng)典的 xgboost 模型+規(guī)則策略。這里規(guī)則是為了業(yè)務的可干預性,有利于產(chǎn)品運營人員快速解決一些業(yè)務 case。
2. 對話核心技術-對話管理
對話管理 ( Dialog Manager ) 系統(tǒng)分為兩個部分:DST ( Dialog State Tracking,對話狀態(tài)跟蹤 ) 和 DP ( Dialog Policy,對話策略 ) 兩個模塊。
DST 主要用于狀態(tài)追蹤,這一模塊維護對話的上下文狀態(tài)、進行上下文語境的管理、意圖槽位繼承等。DP 是決策模塊,它根據(jù) DST 記錄的當前系統(tǒng)狀態(tài),進行系統(tǒng)動作決策。
目前對話管理模塊的實現(xiàn)主要有基于框架 ( Frame based ) 的管理、基于有限元狀態(tài)機 ( FSM ) 的管理和基于 Agenda 的管理等。我們引入了其中的兩種:
Frame Based:在以完成任務為導向的對話系統(tǒng)中,F(xiàn)rame Based 的系統(tǒng)將對話建模成一個填槽 ( slot filling ) 的過程。槽是多輪對話過程中將初步用戶意圖轉化為明確用戶指令所需要補全的信息。例如:"告訴我去車站怎么走",其中目的地是一個槽位,"車站"是該槽位所填充的值。目前,360智能語音交互系統(tǒng)已經(jīng)支持這一模式。
該方法的特點是:
輸入相對靈活,用戶回答可以包含一個或多個槽位信息
對槽位提取準確度的要求比較高
適用于相對復雜的多輪對話
FSM Based:這種方法主要用于特定的任務,如訂票。這種方法通常將對話建模成一棵樹或者有限狀態(tài)機。系統(tǒng)根據(jù)用戶的輸入在有限的狀態(tài)集合內進行狀態(tài)跳轉并選擇下一步輸出,如果從開始節(jié)點走到了終止節(jié)點則任務就完成了。
該方法的特點是:
提前設定好對話流程并由系統(tǒng)主導
建模簡單,適用于簡單任務
將用戶的回答限定在有限的集合內
表達能力有限,靈活性不高
我們的創(chuàng)新點在于通過上下文語境實現(xiàn)了跨場景的信息繼承,這里要引出兩個概念:上文語境和下文語境。上文語境是指上文出現(xiàn)過的信息,主要用于信息繼承;下文語境是指當前對話中要存儲的信息,我們可以給不同類型的信息設置不同的繼承輪數(shù)。我們可以把語境信息想象成一個銀行,根據(jù)"存錢+取錢"的工作模式進行語境信息的獲取與更新,并且支持基于對話輪數(shù)和事件的遺忘,這樣就可以做到跨場景的繼承。
對話管理的工作流程:
對話管理模塊的工作流程和強化學習的"馬爾科夫決策過程"比較類似[3]。在用戶和 bot 的對話過程中,每一輪對話都有當前狀態(tài) ( state,圖中為 s1-s4 ) 以及 bot 根據(jù)當前狀態(tài)做出的反應 ( action,圖中為 a1-a4 )。DST 做的就是追蹤 state,管理對話狀態(tài)的轉移;DP 做的是管理各狀態(tài)下的系統(tǒng)動作,根據(jù)當前 state 的信息,做出反應。這里 DP 可以做出的反應包括調用子功能、繼續(xù)詢問、澄清、兜底回答等。
下圖展示了在訂票場景下的一輪對話中,對話管理系統(tǒng)的流程:
3. 對話核心技術-QA
最后介紹的是 QA 部分,QA 的系統(tǒng)很大程度上依賴相似搜索,其實和檢索式閑聊系統(tǒng)非常相似。
在360智能語音對話平臺上,QA 系統(tǒng)通過預處理 -> 粗召 -> 精排 -> 過濾的流程得到最接近的答案并輸出給用戶。下面詳細介紹一下這個流程:
Query 預處理:這部分是對輸入 Query 進行歸一化,方法和業(yè)界比較通用,不再贅述
粗召:分為基于 keyword 的召回和基于 Embedding 的召回?;?keyword 召回是利用 ElasticSearch 實現(xiàn),找出字面相似的結果;基于 Embedding 的召回是我們將所有候選 Answer 建立了 Faiss 索引,通過 Query 的深度語義 Embedding 進行語義相似性的檢索,這樣可以召回字面不同但實際含義相似的結果
精排:主要用的是我們訓練的 LSTM-DSSM 模型,將 Query 和粗召結果做相似性打分,根據(jù)相似度由高到低排序
過濾:根據(jù)業(yè)務邏輯的過濾,最終輸出符合條件的相似度最高的候選
這里重點講一下我們的 LSTM-DSSM 模型,模型示意如下:
文本相似度問題的傳統(tǒng)解法有 BM25、TF-IDF、編輯距離、Jaccard 相似度等,使用的時候可以多個距離都算出來,用一個模型擬合各個距離的權重,進行加權求和?;谏疃葘W習的方法主要有 DSSM 的各種變種 ( 增加卷積層、增加 LSTM 等 ),近年來還有基于 BERT 的相似度計算。
DSSM 模型[5]最早是微軟提出來的,通過 Bing 搜索引擎的點擊日志數(shù)據(jù)訓練,它非常適合擬合搜索 Query 和 Document 的文本相似度。而公司有360搜索的搜索日志,每天都有億級別的點擊行為正負例出現(xiàn),給我們的模型訓練提供了豐富的語料,這是我們的優(yōu)勢。嘗試了不同模型后發(fā)現(xiàn),在我們的業(yè)務場景下,LSTM-DSSM 模型比其他模型效果都要好,甚至比 BERT 更好,而且計算量更低。
▌總結
本文首先介紹了語音交互系統(tǒng)的基本知識和系統(tǒng)流程;然后介紹了360智能語音交互平臺,重點分享了我們的業(yè)務架構;最后講解了對話系統(tǒng)的核心技術,包括語義理解的 SF-ID 模型、對話管理系統(tǒng)和 QA 的技術架構。
本次分享就到這里,謝謝大家。
▌參考資料
[1] Goo C W, Gao G, Hsu Y K, et al. Slot-gated modeling for joint slot filling and intent prediction[C]//Proceedings of the 2018 Conference of the North American Chapter of the Association for Computational Linguistics: Human Language Technologies, Volume 2 (Short Papers). 2018: 753-757.
[2] Haihong E, Niu P, Chen Z, et al. A novel bi-directional interrelated model for joint intent detection and slot filling[C]//Proceedings of the 57th Annual Meeting of the Association for Computational Linguistics. 2019: 5467-5471.
[3] Zhou L , Gao J , Li D , et al. The Design and Implementation of XiaoIce, an Empathetic Social Chatbot[J]. 2018.
[4] Palangi H, Deng L, Shen Y, et al. Semantic Modelling with Long-Short-Term Memory for Information Retrieval[J]. Computer Science, 2014.
[5] Huang P S , He X , Gao J , et al. Learning deep structured semantic models for web search using clickthrough data[C]// Proceedings of the 22nd ACM international conference on Conference on information & knowledge management. ACM, 2013
特別推薦一個分享架構+算法的優(yōu)質內容,還沒關注的小伙伴,可以長按關注一下:
長按訂閱更多精彩▼
如有收獲,點個在看,誠摯感謝
免責聲明:本文內容由21ic獲得授權后發(fā)布,版權歸原作者所有,本平臺僅提供信息存儲服務。文章僅代表作者個人觀點,不代表本平臺立場,如有問題,請聯(lián)系我們,謝謝!