針對「小度」體驗問題,聊聊語音交互解決方案

近幾年來,智能音箱的普及度非常高,不少人都會選擇購置智能音箱並通過語音進行簡單的交互。然而,也有很多人在使用過程中,發現智能音箱存在著一些「聽不懂人話」的缺點……

作為小度音箱(無屏基礎版)的用戶,本文針對使用中的一個體驗細節進行分析,並嘗試給出語音交互的解決方案。

一、CASE示例

場景1

用戶:小度小度,播放金玟岐的《十三》/播放SHE的《十七》

小度:好的,播放金玟岐的《歲月神偷》/好的,播放SHE的《super star》

用戶:小度小度,播放金玟岐的《十三》/播放SHE的《十七》

小度:好的,播放金玟岐的《歲月神偷》/好的,播放劉德華的《十七歲》

……

無限循環

場景2

用戶:小度小度,播放鄧紫棋、艾熱的《光年之外》/播放鄧紫棋的《光年之外》熱愛版

小度:好的,播放鄧紫棋的的《光年之外》

用戶:小度小度,播放艾熱的《光年之外》/播放鄧紫棋的《光年之外》熱愛版

小度:好的,播放鄧紫棋的的《光年之外》

……

無限循環

二、問題抽象

  • 問題1:當播放音樂的語音指令有2到3個甚至多個約束條件的時候,DuerOS有時會回應錯誤
  • 問題2:即使用戶」字正腔圓、咬牙切齒「的反覆重複同一條指令,DuerOS仍會在多個錯誤回應之間循環切換,反覆給出錯誤的回應

三、問題可能原因分析

1. ASR(自動語音識別)識別錯誤或NLU(自然語言處理)分詞、忽略關鍵條件等錯誤

也就是說,在系統看來,它所收到的指令,前者可能類似於」播放SHE的』時期『「,後者則類似於」播放SHE的十/七「或者「播放SHE」(忽略了「《十七》」之類,理解的錯誤造成了小度無法正確播放。

2. 版權問題

經驗證小度的音樂版權服務方,百度音樂和QQ音樂都沒有金玟岐的《十三》的版權,但有其他幾首歌的版權,因此版權理應也不是這個體驗窪地的主要原因。

3. 策略問題:小度的語音交互什麼時候應該進入「對話模式」?

相比問題1,問題2才是造成這個體驗窪地的關鍵。這是因為,在小度已經無法正確識別用戶意圖的同時,沒有通過進入對話模式給用戶提供更多解決問題的方案,而是機械的重複系統里置信度最高的操作,這無疑會使得用戶火冒三丈。

所謂「對話模式」通常有多輪的語音交互,並且AI能夠理解用戶的上下文含義,從而更「聰明」地做出回應,舉個經典的例子:

  • 用戶:誰是美國的第16任總統
  • AI:林肯
  • 用戶:他去世時多大?
  • AI:林肯享年65歲

對話模式中,AI承接了上文的「他」指的是「林肯」;而如果是非對話模式,AI則會對用戶的第二句「他」不知所措。

目前的策略,一般情況下小度與用戶之間的交互是單輪命令式的,即用戶「小度小度」喚醒后給予小度指令,小度會做出單次回應。

但有以下兩種情況(記憶中觀察到的,因為疫情影響手邊沒有產品,應該會有情況遺漏)小度會切換到對話模式:

  1. 當用戶主動說出「進入極客模式」或者「來聊聊天吧」之類的指令
  2. 當小度「不自信」的時候。比如給予的指令小度理解不清楚、小度為了消除指令的歧義、或者出現打斷對話等異常情況時,小度會採用各種確認策略,反覆確認用戶的指令,這樣也就進入了多輪對話

所以在現有常規的交互策略下,當小度「自信」的時候,比如他自信地忽略掉了一些限定詞(例如艾熱、熱愛版),從而自信地認為用戶就是想聽鄧紫棋原版的《光年之外》,這時它一般不會進入對話模式。

儘管用戶火冒三丈地多次重複同樣的「播放《光年之外》艾熱版」的指令,小度依然會我行我素地播放鄧紫棋原版的《光年之外》。

我不清楚這種策略設置的決策依據是什麼,可能是這種case比較極端沒有被注意到,可能是技術限制,也可能是出於成本考慮,在此不做判斷,但不影響從體驗優化的角度給出建議。

四、嘗試給出解決方案

問題1的解決

結論:出於可能的成本考慮,「版權問題」的情況自動進入對話模式,其他由於AI能力問題造成的錯誤,交由問題2的解決方案一併解決。

示例對話:

用戶:小度小度,播放金玟岐的《十三》

小度:對不起,暫時沒有相關歌曲的播放版權,是否為您播放金玟岐的《歲月神偷》

用戶:好的

GUI原型:無

VUI交互流程:

問題2的解決

  • 結論:當用戶反覆喚醒小度重複相同指令時(先為「播放下一曲」之類的命令加白,不在此討論之列),自動進入對話模式。
  • 功能邏輯:

這裡有幾個概念需要解釋:

1)確認策略

AI在回應用戶指令時,會有一系列備選答案,按置信度高到低排列,形成N-Best列表。在使用列表中不同置信度的答案回應用戶時,AI需要使用不同的確認策略。高置信度的答案採用隱性確認,低置信度的答案採用顯性確認(舉例見下方示例對話)。

2)消除歧義策略

當用戶給出模糊不清的指令或冗餘的指令時,AI向用戶反覆確認、拆解或補充,以形成確定的指令。

示例對話:

//進入對話模式//

  • 用戶:小度小度,播放鄧紫棋和艾熱的《光年之外》
  • 小度:(置信度大於80%,隱性確認)好的,為您播放鄧紫棋的《光年之外》
  • ……(若循環上述對話,則進入對話模式,觸發確認策略) 

 //進入確認策略//

  • 小度:(置信度大於65%小於80%,顯性確認)您是希望播放鄧紫棋的歌曲《光年之外》現場版嗎?
  • 用戶:不是
  • 小度:(置信度大於50%小於65%,顯性確認)您是希望播放鄧紫棋、華晨宇的歌曲《光年之外》嗎?

……(置信度遞減)//進入消除歧義策略//

  • 小度:(置信度小於45%)對不起,請問您想聽哪誰的歌?
  • 用戶:鄧紫棋和艾熱
  • 小度:能說一下主要是哪位歌手嗎?
  • 用戶:艾熱
  • 小度:好的,在艾熱的歌曲中找到了23首歌曲,請問歌曲的名字是?
  • 用戶:《光年之外》
  • 小度:好的,為您播放,鄧紫棋、艾熱《光年之外》

GUI原型:無

VUI交互流程:略

五、結論

新的問題:

短期來看,這個解決方案有肉眼可見的需要改變的代碼量,因為第一步執行判斷「是否用戶重複了m次相同指令」應該是要在整個代碼架構上加一次判斷,有一定的工程量。

但是長期來看,對用戶體驗的提升是值得的。站在用戶的角度,無疑希望體驗能夠優化的更好。是否要為了優化這個體驗細節而付出這個開發成本(用戶有其他臨時替代方案,比如打開小度app手動搜尋歌曲,比如有屏音箱),需要更多的數據論證相關收益和優先順序,作為非內部人士,缺乏相應的決策依據,這裡不做判斷。

在重新看這個體驗問題中,由於場景的複雜和AI能力的不足,用戶扮演了一個「幫助系統修正錯誤」的反饋角色。

因為我的水平有限,相關思考多來自於工作的語音項目和學術論文設計,但沒有完整實操過複雜的語音助手項目落地,理解有誤的地方請不吝指正和批評。