導讀：今天分享的主題是實時語音對話場景下的智慧對話的一些實踐。其中實時語音場景特指透過電話來進行一個語音對話。
主要內容包括3個部分：
- 語音對話的機器人：熱線小蜜
- 語音特色的文字驅動對話
- 語音語義驅動的雙工對話
01
語音對話機器人：熱線小蜜
先簡單介紹一下我們的產品：熱線小蜜。
1. 語音對話機器人：熱線小蜜
熱線小蜜是現在阿里巴巴集團用來承擔電話客服線路的智慧機器人。它有兩種形態：一個是由機器人來承接使用者透過電話渠道撥到平臺的熱線服務；另一個是平臺在某些場景下面主動透過電話觸達到使用者，來進行語音的對話。以上兩部分都是基於語音進行一個智慧對話的產品。
這裡展示了智慧對話的一個案例，即由機器人來解決使用者電話諮詢。這個是一個相對來說比較複雜的，且帶有比較強業務屬性的多輪對話案例。不論是呼入（由使用者主動打電話到平臺），還是撥出（由平臺對使用者進行觸達），理論上其核心都是語音與對話的技術。其中技術團隊的主要工作是最佳化語音與對話的體驗：一方面對使用者的理解越來越準確，另一方面提供儘量順暢的互動能力，最終達成好的互動體驗和業務效果。以上是實時語音場景下智慧對話的整體背景。
2. 實時語音對話挑戰
下面會側重介紹相對於傳統文字對話，語音對話中的一些差異性和特色內容。目前遇到的主要技術挑戰總結如下：
- 口語化：相對於傳統的基於IM的線上電話，使用者在語音對話中，會呈現出冗長的、不連續的、和/或帶有ASR噪聲的表述；
- 多模態：語音對話包含有聲音，天然具有比文字更豐富的資訊；
- 雙工化：低延時和強互動。
左圖展示了線上對話和熱線電話的三個典型例子：
- 口語化表達：線上對話可能就是簡單的五六個字，十個字以內；熱線對話，會有囉嗦的、講故事的情況；
- ARS噪聲：基於語音的下游任務一般來說會受到ASR噪聲的影響，而ASR噪聲可能會導致下游有一些誤差的傳播；
- 多模態：線上對話中僅表達了文字本身的意思。這段文字看起來好像是個問句，在熱線電話的音訊中雖然文字資訊一致，但是從聲音角度來講，明顯能夠聽到使用者中間蘊含的一些語氣以及和情緒相關的資訊。
右圖左側展示了一個比較經典的線上產品：阿里小蜜，是經典的一問一答的產品形態。右側展示了一段從英文資料集中擷取的電話語音片段，該片段呈現的並不是嚴格的一問一答的模式，它具有很複雜、很密集的互動，即存在低延時和強互動的特點。從人人對話的角度來看，人人之間的語音對話透過電話的延遲會低於500毫秒，相對於線上對話，其互動的頻次會更高，即呈現出雙工化。
從以上3個方面，將實時語音對話與現有使用比較廣泛的兩類產品做一個對比：
- 實時語音對話和線上對話：如左圖所示，若將傳統的一問一答形式稱為QA（即Single-Turn，單輪對話），線上/熱線產品還會存在Multi-Turn（多輪對話）的形式（會用到上下文的資訊）。Single-Turn和Multi-Turn是實時語音對話和線上對話共有的形式。此外，實時語音對話在Single-Turn中的輪與輪之間會有更細膩更復雜的互動，可稱之為Micro-Turn，其對話粒度會比Single-Turn更細。實時語音對話中的Micro-Turn會導致雙工化，Single-Turn（QA）會導致口語化，此外，對於整個語音對話系統中由語音帶來的額外的上下文資訊稱為多模化。
- 實時語音對話和語音助手（IOT裝置）：如右圖所示，第一點：實時語音機器人是面向客服諮詢的，其長query會更多；語音助手一般是提問/指令式的問題，相對來說query偏短一點。第二點：實時語音機器人的諮詢場景中，兩邊是對等的交流方式，存在比較頻繁的Turn-taking的動作；但語音助手這類智慧裝置的Turn-taking發生頻率會相對偏少。第三點：由於實時語音對話和語音助手都是基於語音的表達，所以口語化發生的程度差不多。第四點：使用者和語音助手，比如siri或者音箱類的產品交談時，可能不會有太多的情感，但如果使用者是來投訴/諮詢，則語音中會蘊含更豐富的情感。
3. 對話：從文字驅動到語音語義驅動
圖中展示了一個經典的幾乎所有語音對話方案裡面都會有的“五段架構”的模式。但是該架構存在著一些缺陷：
- 缺少針對性的演算法模型：如圖右側是基於文字的互動，最初版本是將線上互動機器人的NLU、DM、NLG模組直接遷移過來使用，但會發現基於這種方式得到的模型，對於口語化和包含ASR錯誤文字的適應性比較差，會直接影響NLU的準確性。
- 語音語義模組割裂：由於整個對話的核心模組（NLU、DM、NLG）是完全基於文字操作的，所以丟失了一些語音模態的資訊，如使用者情緒化的語氣就無法傳遞給模型，同時ASR也會給下游帶來誤差傳播。
- 語音控制能力簡單：對於ASR的傳統處理方式是使用固定VAD時長進行斷句。對於放音而言，原子化方法無法滿足精細化的雙工控制，即將一段文字轉成語音之後，就無法對其播放過程進行操作。這種簡單的控制能力，無法很好的對人人之間複雜語音的雙工動作進行響應，會造成“高延遲、弱互動”的體感，進而影響對話效果。
基於以上三個問題，對話的核心工作主要圍繞兩個部分展開：
- ASR和NLU：語音特色的文字驅動對話
- ASR和TTS：語音語義驅動的雙工對話
02
語音特色的文字驅動對話
1. 面向ASR的SLU
大部分的語音對話機器人都是基於ASR結果對下游進行語義理解的任務。上圖展示了實際業務中的一個場景：將使用者的一句描述匹配到他的訂單中，並且需要利用這個訂單資訊在其諮詢過程中做一些下游工作。此時發現使用者可能因為口音或ASR噪聲，把“軍被”翻譯成了“準備”，這個關鍵詞的ASR錯誤會導致無法匹配正確的候選訂單。
表中列出了4種類型的ASR錯誤：同音、相似讀音、拼音截斷或拼接、數字英文轉換。這四種類型的錯誤幾乎會發生在所有的基於ASR結果的NLP任務中，是一個共性問題。
針對ASR結果的共性問題，傳統方案是“糾錯+SLU”：透過糾錯模型把有錯誤的ASR文字改成正確的，再進入SLU模型得到最終結果。但這個方案存在一些缺陷：第一個是糾錯任務難，需要在GroundTruth的Vocabulary裡找到一個唯一正確的詞進行填充。但是下游的SLU模型任務本身可能不難，比如意圖分類模型可能就是幾個或十幾個意圖的一個分類任務，或者像剛才案例中的訂單匹配任務，相對來說比糾錯任務的決策空間要小。故這種方式雖然可行，但它是用一個更難的事情來解決一個相對來說更容易的事情，成本是比較高的。由此提出另外一種思路：基於錯誤的過程直接對映到正確的結果，即SLU容錯。
上圖表格中對比了三種方案（糾錯SLU、容錯SLU、端到端SLU）的優劣。其中端到端SLU（End2End SLU）在學術界做的比較多，工業界目前使用不是那麼普遍。端到端SLU是用音訊訊號直接理解到最終的結果。端到端SLU是可行的，但目前在學術界沒有得到和基於SLU pipeline模式的可比效果。核心原因在於：一方面音訊訊號比較容易過擬合，目前沒有好的解決方案；另外一方面是現有的大量對話系統已經處於ASR的下游任務中，對ASR是黑盒呼叫狀態，不見得在鏈路上能夠拿到聲學訊號。綜上所述，有必要做一個基於文字，有一定ASR容錯能力的模型。
故構建了一個具有容錯能力的預訓練模型，它可以同時encode一段文字的發音資訊和語義資訊。在某些字有錯誤的情況下，由於模型同時包含了語音、語義資訊，使其具有一定的容錯能力。透過這樣的模型，僅需要在下游任務自身語料上進行fine-tuning，就能得到具有ASR容錯能力的SLU模型。以上即是ARS-Robust 預訓練模型的基本思路。
上圖展示了已發表的相關工作，如之前的主流方案是WCN。WCN是ASR的中間結果，即ASR中間的indexes，它會將ASR輸出的indexes結果網路直接進行編碼，而不是對Top-One的結果進行編碼。這樣的encoding方式既能夠得到輸出表示，又能夠同時包含更豐富的上下文。WCN方案的問題在於需要拿到indexes輸出，但是對於黑盒ASR的下游任務，如果拿不到indexes輸出，模型就無法使用。
這些是ASR-Robust SLU的效果舉例。左側是ASR翻譯的結果,可以看到它的關鍵資訊是錯誤的，如果按照該結果進行分類，就會導致分類錯誤。但如果透過容錯方案，是可以把這樣包含一定錯誤的資訊，分類到正確結果上的。這是基於對query的語音、語義資訊同時進行編碼所達到效果，即ASR容錯。
2. 語音情緒檢測
除了口語化問題以外，我們對多模態也做了一些工作，即檢測使用者在語音中的情緒。情緒檢測在客服領域是一個很常見的應用場景，無論是人人對話、人機對話，還是機器人到人工間的跳轉，都存在一定的利用價值。為什麼需要去做音訊的情緒，而不是單純的文字？在實際過程中發現人機互動時，對機器人字面上的辱罵是比較少見的，但是使用者會呈現出一些不耐煩的情緒，單純從文字上去識別到負面情緒的案例是很少的。這是做情緒檢測的第一個動機：在使用者熱線呼入的對話中檢測、識別其負面情緒。第二個場景是熱線人工質檢，即對使用者與人工客服對話的分析，需要去檢測人工小二的服務質量，以及是否符合服務規範。人工小二很少會直接辱罵客戶，但有時語氣會有一些異常，如也會存在一些服務上的不耐煩，這種情況在文字上比較難檢測出，故需要進行語音檢測。
語音檢測的主要挑戰並不是在建模上，而是資料質量差，標註、建模方式不合理。目前調研到的所有學術界的音訊資料集質量都無法在工業界直接使用（與資料集的構成方式有關）。學術界現有音訊情緒資料集基本採用表演方式構造，即由演員透過給定的條件來表演一段相關的音訊，這與真實情況有較大差異。目前標註方式主要採用分類標註的方式，如委屈、恐懼、著急、失望、憤怒、辱罵等，單純從語音上是比較難去界定的。這樣進行分類標註的主觀性是比較強的，達標的誤差一致性也比較低。以上兩點導致目前學術界的分類資料是幾乎無法滿足工業需求的。
語音情緒檢測任務的核心並不在於模型的創新，而在於如何去構造一個能用的資料集。首先摒棄分類打標的方式：如左側下方展示的效價圖，透過情緒的正負面和強弱，將不同的情緒型別劃分到不同象限裡（目前更傾向於只做橫向象限，忽略縱向象限，只標註情緒的負面程度）。如此就將分類問題轉換成了迴歸問題，這樣可以避免在兩個分類狀態之間難以選擇，或是劃分標準模糊的問題，相對來說標註資料的質量會好很多。同時也能透過增加樣本量（標註量）的方式來減少標註誤差，提高標註質量。
語音情緒檢測任務的方法比較簡單直觀，將音訊訊號與文字訊號放在一起，做多模態的訓練。
3. 口語化表達
第三個工作——口語化表達，右側表格將口語化型別進行了分類舉例，其中資訊冗餘是最常見的型別。所以口語化表達任務的核心是對多資訊點的問題進行特殊處理。
主要採用以下兩種方案對query進行前處理：
- “短句分類+pattern推理”：雖然長句可能無法直接定位到一個意圖，但每個短句是能夠定位意圖的。故可以透過先對短句（意圖）定位，再利用短句間存在的因果關係，推理到最終意圖。
- “Bert-Sum”摘要
以上即是從NLU轉換成特色口語化理解的SLU的介紹。
03
語音語義驅動的雙工對話
1. 雙工對話的定義
如何定義雙工對話？左圖給出了三個例子，分別為同步對話，非同步對話及雙工對話。右側表格中總結了三類對話的區別。總結雙工對話的特點如下：
- 獨佔性：通訊雙方在打電話時，一般無法併發做其他事情，會導致時間比較敏感。
- 持續性、非瞬時、非原子：與線上對話不同，雙工對話的資訊傳遞是一個過程，不是一次性把資訊傳遞到位，所以會存在邊聽邊想、邊想邊說的情況。
- 不完全博弈：永遠無法精確判斷對方在下一秒鐘是否講完一句話，或下一秒鐘對方是否打算讓“我”來回答。
驅動雙工對話的底層邏輯在於：“減少共同靜默和共同發聲的時間”。
下面簡單看一下雙工對話是如何進行決策的。舉個例子，使用者和機器進行互動時，如果使用者話沒有講完，是需要去等待他的。最後，使用者講的是“我今天諮詢的問題，客服態度不好，想投訴”，使用者講到“想投訴”的時候認為使用者表達完成了，這時才去回答他的問題。這個例子反映了什麼時候去回答更合適的問題，我們永遠是需要對使用者進行預判的。正確的預判是我們期望的，錯誤的預判會導致互動中間產生一些比較差的體驗。另一種場景是由機器來對話，機器講話的同時使用者也講話了，使用者開始講話時是否就需要去打斷機器的講話？顯然不是。所以也需要去判斷合適的時機，即使用者是否真的想打斷對話，才去判斷要不要停止當前的對話。對於打斷的場景也需要對過程進行決策。如何進行這樣的預判？有兩種方案。第一個方案是由對話雙方給出顯式訊號，如辯論中會顯式的說“我的陳述完畢了，請你講”，但顯然在熱線電話中不太可能完成。所以只能基於第二種方案：基於上下文進行判斷。
2. 雙工對話的表示
如何實現雙工操控？按照人類的表達來模擬，就是耳朵在聽，腦子在想，嘴巴在說。如果把它變成一個機器人，就是需要控制收音，在收音時去控制什麼時候能夠觸發雙工動作，需要有這樣的動作決策機制及執行的方法。
如何把複雜的雙工對話轉換成一段可以結構化的方案，核心在於左下角的圖，即定義了一套DSL語法，可以將使用者任意一段雙工對話進行結構化，表示成“狀態、事件、動作”這三個要素。其中第一層為state（狀態），第二層為event（事件），第三層action（動作）。基於要素，可以表示一段對話，另一方面也能讓Robot具有響應雙工對話的能力。同時，對人人對話進行這樣表述之後，能將此資料作為訓練資料。
左圖是對人人對話進行表示後得到的視覺化結果。對Switchboard資料集中2400通英文對話進行了結構化表示，該資料集幾乎包含了所有雙工行為（該資料集透過InterSpeech 2021進行了公開），也是目前學術界規模最大最全的雙工行為資料集。以上為雙工對話的表示。
有了雙工對話的表示後，需要對它進行控制。圖中可以看到我們對傳統五段式機器的改造，即插入Duplex-Conversation部分。Duplex-Conversation分為三個部分：第一個是ASR驅動的語音控制部分，由它來將ASR和TTS由原來的原子化驅動變為一個更精細化操作。第二個是DuplexDM，其功能是不斷接收Micro-Turn（比Turn的粒度更細）的資訊，即決策時機，然後根據時機的state和event，給出一個action（包括等待不回覆，或是呼叫NLU鏈路進行回覆，或進行一些任務無關的回覆，如語氣詞、承接詞等）。將回復分為任務相關回復和任務無關回復兩個部分，其中任務無關回複稱為Task-free Chat，任務相關回復其實就是原來傳統的NLU、DM、NLG。透過這樣的改造，使機器人具有雙工互動的能力。
3. 雙工互動的能力
① 更短的響應時長
雙工互動能做什麼？第一個是更短的響應時長，能將機器的響應從一秒縮短到500毫秒以內。這個可以透過模仿了人的行為——“邊聽邊想”和“邊想邊說”的方式來實現：人人對話時並不是聽完整段對話，再開始思考回答，而是對方一邊在講，我一邊在思考如何回答；“邊想邊說”即在回答對方時，並不是把整個答案組織好之後再開始回答，而可能是先說幾個字的同時再想後面的一個答案。
實際上透過雙工鏈路實現了以上兩個功能，這裡不再贅述。“邊聽邊想”和“邊想邊說”的方式會比傳統NLU互動鏈路的響應時間快得多。
② 語義化打斷
雙工互動的第二個用途是：語義化打斷，其本質上是判斷是否應該接受使用者打斷。與傳統打斷的區別在於：傳統打斷是基於聲音，有發聲之後就會直接暫停/打斷；語義化打斷會將使用者可能並不是處於回答當前問題的query進行過濾，僅接受對當前query的回覆。 其核心在於基於語義上下文的決策模型，以及對TTS的精細化控制，由兩個功能共同組成了語義化打斷能力。
③ 互動式數字收集
雙工互動的第三個用途是：互動式數字收集。這個場景是指一些類似於電話號碼或者地址、身份證號這類資訊，精度要求較高，比較難一口氣直接報出，且中間可能還會有錯誤，使用傳統單輪方式收集的效果是比較差的。這種場景實際屬於密集、快速的多輪互動，傳統的turn-based方式無法滿足。此外，使用者在表述時會存在一些異常的情況，並不是一個標準的表述形式，甚至會出現澄清修改或者表達含糊的情況。針對這個場景，基於傳統Duplex DM方案，結合對數字的特殊處理（動作決策因子），進行端到端的最佳化，最終得到一個具有雙工互動能力的複雜互動式的數字收集。與傳統基於按鍵式的數字收集方式相比，在完善率上有顯著的提高，模擬了人和人對數字的收集過程。
④ 模擬環境
最後一點：實現雙工，特別是端到端的雙工，需要離線的模擬環境和建模方式。模擬環境有兩種構建方式（即實現方案）：第一種是語音層模擬，基於完全線上的語音通訊方式去構建使用者模擬器和機器agent，用這樣的方式進行離線模擬。該方案存在一個比較複雜的問題——比較難準確模擬語音通訊中的各種延遲。
我們實現了一個更巧妙的辦法：指令層模擬。上文有介紹過對雙工的完全結構化的定義，可以完全從結構化指令來模擬出一段聽上去和真實人人對話幾乎一樣的雙工對話，可以在指令層隨意模擬語音中間的延遲、互動等各種特性。基於指令層模擬的模式，可以更方便地實現雙工對話樣本的生成、模擬和訓練。
總體而言，我們完成了第二步——將短文字對話升級到了語音特色的文字對話，第三步——再升級到語音語義聯合驅動的對話中。對對話五段式的架構也進行了升級，加入了Duplex Conversation的模組。
04
總結
最後總結一下今天介紹的主要內容：一方面介紹了實時語音對話中的三個特點：口語化（包括表達含糊、ASR錯誤）、多模化（包含情緒、語速、背景環境等各種資訊）、雙工化（低延遲、強互動）。另一方面相應介紹了實際的工作：SLU、語音的多模態理解、雙工對話。
05
精彩問答
Q：由於使用者上文query可能提到了某個詞，或提到的詞和使用者當前的詞是有一定相關性的，所以能否基於上文資訊來最佳化ASR？
A：其實ASR容錯的核心思想是不是把ASR變準確，而是即使是在ASR錯誤的情況下也能得到正確的NLU結果。從提高ASR準確率的角度來講，問題中所述的方案是可以使用的。如上文提到的實體，如一首歌或者一個明星的名字，在當前可能會翻譯錯誤，但是結合上下文，可能就能夠進行糾正。但是我提到的場景是：資料沒有在娛樂領域進行訓練，對於某個明星的名字始終都是錯誤的，即上下文中的實體也是錯誤的，即無法單純依賴上下文來進行糾正。
Q：打電話時使用者的query一般會比較長、雜亂、口語化，對這些query只做匹配、分類嗎？還是真的會對query進行結構化的解析？
答：這個和業務方案和具體需求有關。我們主要的兩個下游任務就只有匹配和分類，也會做一些實體識別。
Q：“邊想邊說”模型是否存在說到最後發現自己說的不對，還需要重新說的情況？
A：這是一個經典的問題。目前使用的是一個比較取巧的辦法，也是模擬人的一種方案。“邊想邊說”模型的核心是為了減少響應時間，剛開始會回覆較為通用的話——承接詞，如“清楚了”、“瞭解了”，這個方式其實是和人人對話是一樣的。比如人在遇到比較難回答的問題時會說“我想想”，這是一種技巧，一般來說和下文不會那麼矛盾。這個模型也可以做得比較精細，如將承接詞進行分類，包括“思考”、“猶豫”、“清楚”等，不同的承接詞和下文答案的語義一致性/流暢性是不一樣的，為了避免出現比較突兀的搭配，也會做一些預測來儘量減少最終答案的突兀程度。在少量情況下也會出現前半句和後半句轉折比較突兀的情況，但總體來講效果還是比較好的。
Q：可以在哪裡體驗一下剛才demo中演示的效果嗎？
A：可以直接撥打淘寶官方的熱線客服進行體驗。
Q：雙工ASR當前的主流技術是流式transformer嗎？
A：ASR使用的是流式，因為流式響應速度更快，但我們系統不是對所有的流式結果都進行響應，而是選擇某些時機進行響應。如100字的句子中間可能有30個流式結果（每3個字返回一次結果），這樣100個字需要呼叫30次下游模型，這種呼叫方式的複雜度是比較高的。所以實際會控制呼叫頻次，如連續兩次流式結果比較接近，就不用呼叫了。
今天的分享就到這裡，謝謝大家。
在文末分享、點贊、在看，給個3連擊唄~
分享嘉賓：
分享嘉賓：陳克寒 阿里巴巴 演算法專家
編輯整理：熊丹妮 武漢天喻資訊
出品平臺：DataFunTalk
