編輯導語:隨著科技的快速發展,如今我們的生活越來越便捷,很多時候通過說話便有機器代替我們去完成一些事情,這便是語音技能帶給我們的好處。日常生活中,語音技能彷彿無處不在,小到手機、智能音箱,大到機器人,那麼,語音已經應該如何設計出來呢?

隨著語音交互的普及,我們首先用到的最多的就是語音技能,比如:我們讓智能音箱唱歌、查天氣、講笑話等,這些都是語音技能。今天,我們就來聊聊如何從零到一的設計一個語音技能。

1. 基礎信息介紹

在設計語音技能之前,我們首先要掌握技能用到的一些基礎定義,每家公司可能叫法上面會有區別,但是都大同小異。

1.1 基礎定義

我們在聊聊語音技能常見的一些名詞和定義,主要有領域(domain)、意圖(intent)和槽位(slot),這些都是語音技能必不可少的一些參數內容。

1.1.1 領域

聽到這個詞,我們就感覺到了約束性,其實領域這個詞就是約束語音技能範圍的意思。一般一個語音技能,會有一個明確的領域,剩下的內容都在這個領域裡面做處理。

1.1.2 意圖

顧名思義就是判斷用戶具體要做什麼的意思,領域可以是一個大範圍的事情,而意圖是領域中的一個小分類。

比如:讓機器人跳舞是一個領域的事情,那麼「開始跳舞」和「停止跳舞」就是領域下的意圖的事情。意圖一般會非常明確,會有明確的邊界,在自然語言處理中屬於封閉域的問題。

1.1.3 槽位

根據槽位的有無,語音技能可以分為有槽位的和沒有槽位的。槽位一般就是指我們前面說到的實體詞,用來做信息抽取用的,補全和完善用戶的意圖。

比如:「唱首歌」就是沒有槽位的語音技能,只需要知道是唱歌的意圖就可以;而查天氣是常用的有槽位的語音技能,除了識別出這是一個查天氣的意圖之外,機器人還要知道要查什麼時間、什麼地點的天氣,時間和地點在這裡就是槽位信息。

有槽位信息的一般還會有默認槽位,就是沒有槽位信息的時候,直接使用默認的槽位信息,從而保證語音技能的正常。常見的就是「天氣預報」,默認的就是當地當天的天氣。

1.2 底層邏輯

再聊聊一下目前語音技能的底層邏輯,基於什麼能力實現的。

目前大部分做語音技能的公司,都是用正則表達式來寫的,就是基於一些文本規則,作為約束條件,篩選出來明確的意圖。抽取的槽位也是基於規則,或者窮舉的方式。

這樣做的好處是改動方便,以及改動后的影響好評估,而且冷啟動非常方便,甚至可以做到每天迭代;缺點也同樣明確,泛化能力弱,沒有學習能力。

也有一小部分公司已經開始使用演算法做語音技能了。

語音技能本質是一個意圖識別的事情,而意圖識別實際上又是一個分類問題,有基於傳統機器學習的SVM,基於深度學習的CNN、LSTM、RCNN、C-LSTM等。

槽位識別實際上是一種序列標記的任務,有基於傳統機器學習的DBN、SVM,也有基於深度學習的LSTM、Bi-RNN等。用演算法做的優點就是泛化能力強,有一定的學習能力;缺點就是成本高,適合複雜技能後期迭代的方向。

正則表達式- HELAY新鮮事

2. 語音技能的定義

在開始動手做語音技能的之前,要先對語音技能進行定義,知道技能的邊界,要有明確的反饋邏輯在裡面。我們這裡用「查天氣」這個爛大街,也是最典型的技能來舉例子。

2.1 定義技能

我們要明白為什麼做「查天氣」這個技能,以及要做到多細。

原因可能是我們就覺得這個技能很基礎,用戶都被教育過了,必須要有;也可能是我們看用戶的交互日誌,發現每天都有很多人有這個意圖,現在是未滿足狀態,值得單拿出來作為一個技能。

還可能是老闆覺得競爭對手有了,我們也要做。

假設我們是覺得是技能很基礎,必須要做。接下來我們就要考慮怎麼定義這個技能,需要注意以下幾點:

2.1.1 要明確技能的邊界,就是那些query是該技能要識別的,需要有一個明確的定義

這個看起來很容易,其實執行起來會很糾結,因為自然語言本身就有一定的歧異性。

就拿「查天氣」舉例子,比如:「今天該穿什麼?」、「明天能不能出去玩」算不算查天氣的意圖,都是要明確的。其實最讓你糾結的往往是模糊的語義,算作技能也不為錯,不算吧,又覺得用戶可能有這個意思。

所以明確的邊界的時候,有三種處理邏輯:

2.1.1.1 只處理特別明確的意圖,不care模糊的語義

比如:只處理「明天天氣」、「查一下天氣」等這樣的

2.1.1.2 模糊的意圖也一起處理,都歸為該技能

比如:「明天該穿秋褲嗎?」也屬於該意圖,和「明天天氣」一起處理

2.1.1.3 還有一種精細化的處理,把明確的意圖和模糊的意圖分開處理

比如:可以讓明確意圖直接執行,模糊意圖選擇反問,用戶確認后執行。用戶一旦確認后,以後這句話就歸位了明確意圖。

比如:用戶問「今天穿什麼出去好呢?」,計算機回答「您是不是想查詢今天的天氣?」,用戶回答「是的」,計算機回答「今天北京氣溫20度,適合……」;然後下次用戶問「今天穿什麼出去好呢」,計算機就可以回答「今天北京氣溫20度,適合……」,反之亦然。

當然如果模糊問的問法比較多,可以專門做意圖優化。

2.1.2 明確技能的領域、意圖和槽位的信息

就拿「查天氣」這個技能為例,領域我們一般設置為「weather」,但是意圖定義就會有兩種方案:

一種是簡單的,只有一個意圖,比如意圖也是「weather」;還有一種是精細化的處理,有若干餓意圖,比如「北京空氣質量?」算是「get_haze」,「今天會下雨嗎?」算是「get_rain」等,就是每個不一樣的問法,對應不同的意圖。

本質上越精細化的技能,給用戶的體驗會越好。


2.1.3 考慮技能內多輪的支持,以及支持的效果

由於自然語言先天是具有多輪屬性的,很多時候需要藉助上輪的信息,才能理解這句話,在做語音技能的時候,也要考慮到這方面的可能。

比如:用戶先說「明天天氣」,緊接著,用戶又說「後天呢?」,這個時候是否考慮支持,都需要在定義技能的時候明確。像用戶隔多久的多輪需要支持,支持的邏輯,我們這裡就不展開了。

定義好了技能,就知道了這個技能能幹什麼,方便後面的測試同學測試,也知道未來要迭代的方向。一般如果沒有數據支撐的話,建議先做最基礎的就可以,邊界越小越好。

2.2 觸發技能反饋

反饋這塊一方面依賴於產品底層的設計;另一方面依賴於產品形態,按照有無屏幕,可以簡單的分為兩種產品形態:有屏幕和沒有屏幕。這兩方面結合,才能設計出一個人性化的體驗。

產品的底層設計要考慮意圖要不要細化,比如:「今天有霧霾嗎?」和「今天天氣怎麼樣?」這兩種問法有沒有必要分開處理,設置不一樣的回復內容。

還要考慮如果槽位超出技能的邊界怎麼處理,比如:「三年後的天氣預報」,這個時候我們需要怎麼反饋,都是需要在語音技能定義的時候寫清楚。

具體怎麼展示以及怎麼回復,就要依賴於產品形態考慮。

有屏幕的可能更多的信息會通過屏幕展示,語音只是做到一個提醒的效果,有些場景甚至都不需要語音,而沒有屏幕的就要考慮語音播報的表達方式,要注意文字的長度,都播報那些內容,播報的先後順序,甚至播報的句式的豐富度都要考慮。

技能的反饋,是用戶直接能夠感受到的,其重要心怎麼強調都不為過,這塊可以參考語音交互的設計規則。

3. 數據的準備

前面說到的都是產品設計的時候要考慮到的問題,如果你把技能已經設計的差不多的時候,就可以準備這個意圖的訓練和測試數據,因為我們最終語音技能的開發是基於數據的,數據覆蓋的越全面,技能的效果越好。

無論訓練數據還是測試數據,簡單可以把數據分為兩部分,正例和反例。

3.1 正例數據

正例數據指的是正常的觸發文本,就是你設計的觸發query,像「明天天氣怎麼樣」、「天氣預報」、「查詢天氣預報」等,這些都是我們定義的「查天氣」的意圖。

一般在準備正例的數據時,最關心的是數據的來源,還有數據的豐富性。

如果是冷啟動的話,建議團隊內部,或者有專門的數據部門,進行人肉泛化,就是每個人自己寫幾條符合意圖的觸發query。

這裡亞馬遜在做智能音箱的時候有一個要求,就是每個意圖的正例訓練集的數據,不能少於30條(測試數據也一樣)。數據來源就是公司員工製造,數據豐富性就是依靠數據量標準約束。

如果是語音能力已經有了,每天都有大量的交互數據,我們就可以從真實的交互中拿數據。導出交互日誌需要逐一標註,從中找到屬於該意圖的數據。

這些數據的好處就是更加貼近用戶真實的情況,缺點就是成本會比較高,但一般都是可控的。

基於現有的交互數據標註,可以輕輕鬆鬆準備30該意圖的數據,建議越多越好,100條以上為最佳。數據來源就是用戶的交互,數據豐富性是依靠用戶的。

3.2 反例數據

反例數據指的是非該意圖的數據,就是除了正例數據,理論上所有的數據都是反例數據。像「明天要是不下雨就好了」、「我知道現在在下雨」、「我不想查天氣預報」等,這些都不是我們定義的「查天氣」的意圖。

很多時候,我們做語音技能的時候,是很容易忽略反例數據的。

反例數據最好是能夠有意圖相關的關鍵詞,數據量最好可以和正例數據一樣多。在準備反例數據的時候,要注意一些意圖相反的操作,比如:「我不想查天氣預報」,這是比較典型的反例數據。

往往反例數據比正例數據要難收集,尤其是高質量的反例數據,一般交互日誌是最好的資源。

正例數據可以保證準確率,而反例數據可以減少誤召回,提高召回率。

4. 語音技能的實現

訓練數據準備好之後,就是技能的實現了,這塊需要工程師的支持。有些公司是工程師直接寫語音技能的邏輯,有些公司是會提供一個平台,通過培訓,讓產品經理和運營同學也可以寫。

這裡就會用到一些基礎能力,當一句query傳過來,首先會使用中文分詞對這句話進行分詞。

比如:「北京明天天氣怎麼樣」,會被分為「北京」、「明天」、「天氣」、「怎麼樣」,然後就是命名實體識別;比如:「北京」就是地點實體,「明天」就是時間實體,對應的就是語音技能的槽位。

最後就是匹配我們寫的正則表達式,這裡就不過多贅述,感興趣的同學可以搜搜看。

中文分詞:為什麼叫中文分詞呢?因為英文是以詞為單位的,詞和詞之間是依靠空格和標點隔開的,而中文是以字為單位的,一句話的所有字是連在一起的。

所以就需要演算法把一句話切分成有意義的詞,這就是中文分詞,也叫切詞,主要為了NLU後面處理做準備。了解鎚子手機的人可能知道上面有一個叫做「大爆炸」的功能,就是基於該演算法的。

這是NLU最底層的能力,一般都是用的開源的演算法,大家能力相差不大,基本可以保證準確率在90%以上。

命名實體識別:詞性標註是把每個詞的詞性標註出來,而命名實體識別是指識別文本中具有特定意義的實體,包括人名、地名、時間等。

一般來說,命名實體識別的任務就是識別出待處理文本中三大類(實體類、時間類和數字類)、七小類(人名、機構名、地名、時間、日期、貨幣和百分比)命名實體。

這個一般會根據本身業務的需求進行調整,不做明確的限制。

還有比較簡單的實現方式,就是通過窮舉實體+寫正則的方式,而不需要用到模型去做處理。

比如:「查天氣」這個技能,我們通過窮舉的方式,把表達地點和時間的詞語都窮舉出來,然後分別存到詞典裡面。最後使用這兩個詞典寫一些正則表達式,用來覆蓋我們準備的訓練集。

這樣做的的前提需要是實體詞是可以窮舉的,否者就會遇到召回率很低的問題。除了實現方法,我們還要考慮實現過程的效率,以及實現效果怎麼樣。

5. 測試驗收效果

一般的語音技能開發會比較快,開發完成之後就是驗收了,驗收最關心的指標是精準率和召回率。

5.1 驗收指標介紹

本質上就是計算機判斷了一次,然後人工判斷了一次,默認以人工判斷的為真實標籤,計算機判斷的為預測標籤,如下表:

5.1.1 精準率(Precision)

計算機認為對的數據中,有多少判斷對了。

精準率表示的是預測正例的樣本中有多少是真正類,預測為正例有兩種可能,一種就是真正類(TP),另一種就是假正類(FP),公式表示如下:

5.1.2 召回率(Recall)

的樣本中,有多少被計算機找出來了。

召回率表示的是樣本中的正例有多少被預測正確了。也只有兩種可能:一種是真正類(TP),另一種就是假反類(FN),公式表示如下:

其實就是分母不同,一個分母是預測標籤的正例數,另一個真實標籤的正例數。一般情況這兩個指標都會在0-1之間,越趨近於1,語音技能的效果越好。

5.2 驗收步驟

驗收這裡分為兩個步驟:一個NLU批量驗證;一個是端到端驗證,都可以用測試集來驗證。

NLU批量驗證就是把測試集的query,全部通過語音技能的邏輯跑一邊,一般用來驗證技能在NLU上面的效果。通常這一步只會測試新增的技能,單獨測試這個技能的效果,主要關心的是精準率和召回率,這一步理論上來說,必須這兩個指標都要達到95以上。

端到端驗證是模擬用戶正常使用,需要把技能放在整個語音鏈路上面,來觀察語音技能在實際情況中的表現。

通常這一步才會發現一些問題,比如:語音技能之間的衝突,甚至會發現ASR識別不對的情況。這一步主要關心響應時間、語音技能是否正常等情況。

測試一定要把好最後一道關卡,保證語音技能的精準率和召回率,同時也要測試技能之間優先順序的關係,是否技能之間會出現優先順序的問題。如果有多輪的語音技能,也要測試多輪的效果。

6. 總結

做一個語音技能,產品首先要有一個明確的定義,其次就是基於產品定義準備訓練集和測試集,然後基於訓練集完成技能的開發,最後使用測試集進行驗證。