智能語音平臺:技能搭建與多輪交互
通過本文內容,你將了解在搭建智能語音平臺的過程中,如何搭建一個技能以及支持不同的意圖,他們的本質和邊界是什么?
接下來我將從這幾方面進行展開:
- 了解語音全流程框架
- 意圖的組成部分
- 多輪交互
一、語音全流程框架圖
首先,簡單說一下語音交互的全流程的概念:
ASR(Automatic Speech Recognition):接收音頻返回字符串,可以根據不同的場景模式來定制ASR,比如智能冰箱語音ASR要更多的優化菜品種類等相關詞語的識別,車載語音ASR就要更加關注有聲內容的識別以及控制相關的詞語識別。
例如:冰箱食材管控技能,說法“棗吃完了”,但是誤識別成了“早吃完了”,就需要針對食物種類識別進行加強優化。
NLU(Natural Language Understanding):通過一系列手段從識別出來的句子中抽取關鍵詞,進行語義標識。
例如:“棗吃完了”,“棗”就代表食物種類,“吃完了”就代表食物數量為0。
DM(Dialog Management):為對話系統的主體,控制著對話的架構和結構,從ASR/NLU組件接受輸入,維護一些狀態,與任務管理器(知識庫)交互,并將輸出傳遞給NLG/TTS模塊。
例如:“棗吃完了”,首先需要把冰箱里面的棗的數量置為0,“再去蘇寧小店買2斤”,然后依據上文的輸出以及本輪的輸入去補全詞槽,根據上文的食物種類“棗”,然后提取“蘇寧小店”,“2斤”,“買”結合起來自動在蘇寧小店購買2斤棗,這就是DM需要完成的事情。
二、意圖的組成部分
2.1 基礎概念
意圖:用戶的每一輪對話,都可以認為是一個意圖,如“北京市今天天氣怎么樣”就對應著意圖【查詢天氣】。
語意槽:即從用戶說法中提取出的關鍵字,如“我要去上?!保Z意槽就是#地址#,取值“上海”。
2.2 意圖的必要和必填參數
語音輸入怎么觸發意圖,把相關的意圖說法盡可能對應上設定的意圖,把不相關的說法阻擋,本質上就是一個邊界問題。
首先,跟著我來思考一下想要去上海旅游的話,應該怎么表達?
A:我想去旅游。
B:明天我想去上海旅游。
C:明天我想從北京去上海旅游。
D:我想飛到上海旅游。
句式A:有兩個必要信息,“去”,“旅游”。
句式B:有兩個必要信息,“去”,“旅游”;非必要信息“上?!薄懊魈臁保槭裁疵魈旌蜕虾O啾攘硗鈨蓚€信息而言是非必要呢?因為沒了非必要信息,兩個必要信息也能明白意圖,但是沒了兩個必要信息的其中一個,就不能理解意圖)。
句式C:有兩個必要信息,“去”,“旅游”;非必要信息“明天”,“北京”,“上?!薄?/p>
句式D:有兩個必要信息,“飛到”,“旅游”,非必要信息“上?!?。
為什么定義“去”和“旅游”是必要信息呢?
如果你單說旅游的話,可能有旅游雜志,旅游景點,旅游指南等多種意圖,但是如果你加上了“去”,那就代表你想去旅游,是一個出行計劃類意圖。
如果你單說去的話,可能有去吃飯,去購物,去旅游等多種意圖,但是如果你加上了“旅游”,那就代表你想去旅游,是一個出行計劃類意圖。
為什么定義“上海”,“北京”“明天”是必填信息呢?
觸發了去旅游的意圖后,需要有出發地點、目的地,以及時間等必填參數才能完成服務,所以“目的地”“出發地”“時間”成為意圖的兩個“必填槽位”。
必要參數下面的“必要”和“必填”他們要解決的問題在本質上是不一樣的。
- “必要”是針對某說法能夠匹配到某個意圖,它的本質是“邊界判斷”,作用是對意圖進行分類和句式匹配。
- “必填”是在意圖已經確定的情況下,去請求后續服務的“必填參數”。
我們可以總結如下,一句話的信息可以按照“信息類型”和“必要要素”來劃分:
- 必填槽位信息,比如“上?!薄氨本?/li>
- 必要意圖信息,比如“去”“旅游”
- 非必填槽位信息
- 非必要意圖信息
所以,在配置意圖句式的模塊,對于是否觸發意圖這個邊界而言,“必要要素”是可以不含有解析框架中的任何槽位的,但是必須包含必要意圖信息。
但是,對于一條完整的意圖句式,一定要包含必要意圖和必要槽位兩個信息,必要槽位的信息可以有默認設置。
2.3 意圖句式
我們再來看一下這幾個例句:
A:我想去旅游
B:明天我想去上海旅游
C:明天我想從北京去上海旅游
D:我想飛到上海旅游
A和B的區別在于:僅僅在“去{上海}旅游”之間加了一個地名。
B和D的區別在于:“去”和“飛到”的表達差別。
這樣我們就可以得出一個結論:在一個句式中,我們把必要意圖信息按照順序排列好的基礎邊界句式,只要符合這個邊界的句式,全部可以匹配到這個意圖。
后續的工作就是把一些“非必要信息”配置上去以覆蓋更多的句式,比如必要意圖信息“去”“旅游”,非必要意圖信息“上?!?,“明天”,就可以組成句式如:
- {時間}去旅游。
- 去{地名}旅游。
- {時間}去{地名}旅游。
- {時間}飛{上海}旅游。
在原有必要要素組成的基礎句式基礎上面,我們可以增加非必要要素的配置、排列組合和詞庫等,衣服和這個邊界的更多句式。
在思必馳平臺上線的食材管理意圖里,自定義的一些句式說法:
三、多輪對話
多輪對話現在普遍的劃分方式,分為“線性”多輪和“非線性”多輪。
從功能層面上講:
- 線性多輪是在必填槽位缺失,通過系統主動發起追問的方式,去獲得缺失的槽位;
- 非線性多輪是需要聯系上文才能獲得用戶完整意圖的問題;
3.1 線性多輪定位與邊界
線性多輪解決問題得邊界,是在一個意圖的對話中,命中了必要意圖信息,但是觸發之后,卻缺失了意圖所請求服務必要要素(必填槽位信息)。
“必填槽位信息”是已經事先被定義好的,線性多輪的存在位置,就是為了彌補這個缺失。
舉例:導航意圖
必要完整要素:幫我導航到目的地(必要意圖要素+必填槽位要素)
用戶:“幫我導航”
反饋:“您要去哪里?”
用戶:“天安門”
反饋:“正在為您導航到天安門”
當觸發到必要意圖的時候,但是沒有必填槽位,就反饋尋找必填槽位信息,如果接下來的輸入是所需要的必填槽位,就請求服務,如果對應不上必填槽位信息,就正常執行即可。
3.2 非線性多輪-意圖內非線性多輪邊界問題
首先跟我來思考一下,日常生活中的對話。
周末無聊,你想看黃渤主演的綜藝節目來打發無聊時光,這時候你就可以跟女朋友說:“你給我找找綜藝節目。”
然后,女朋友興高采烈的給你搜羅著各類綜藝,問你:“你想看搞笑的?智力的?還是什么?”
你跟女朋友說:“我想看黃渤參與的?!?/p>
這時候,女朋友就給你找出了黃渤參與的綜藝類節目。然后,我們把對話置于智能語音助手上面就得出如下情況:
人:“我想看綜藝。”
機:“為您找到以下綜藝?!?/p>
人:“看黃渤參與的。”
機:“為您找到黃渤參與的綜藝節目。”
通過以上的例子,我們可以得出:在用戶第一輪對話后,我們可以知道了用戶的意圖(看綜藝)。第二輪給出主演人的非必填槽位,那么在看綜藝的這個意圖上面是可以增加主演人的非必填槽位的,我們就可以去補充上意圖的槽位,去相應用戶的需求。
邊界:需要聯系上文的意圖,如果接下來對話涉及到的槽位信息可以替換或補充上文的槽位,就可以獲得用戶的完整意圖信息。
得到這個邊界之后,我們在配置必要因素的時候,應該考慮:
- 意圖中的哪些槽位是可以改變的?比如:我想看綜藝,也可以是我想看黃渤的綜藝,又或者是我想看黃渤最新的綜藝。
- 哪些意圖是可以做槽位改變的?比如:我想看綜藝就可以有槽位的改變,我想去旅行對目的地,出發地的槽位進行改變,但是播控等一些簡單基礎意圖就不需要了。比如:播放,聲音大一點等都是單獨執行的命令,沒有必要增加其他的槽位信息。
3.3 非線性多輪-跨意圖非線性多輪邊界問題
接下來,繼續跟我進入一個場景:
假如你想帶你的女朋友去北京旅游,為了向女朋友展示你的體貼和細致,你想提前制定一下旅游計劃,比如:你在大眾點評篩選地點北京,人數2人,類別吃飯,然后給你推薦了許多吃飯地點。
如果這時候你點擊類別的景點,他就會為你篩選出來適合2個人在北京旅游的景點,這時候你不用再去輸入北京和人數了。
如果我們把操作對話置于智能語音助手上面就得出如下情況:
人:“幫我查查北京適合2人的吃飯地點”
機:“為您找到以下地點”
人:“那旅游景點有哪些呢?”
機:“為您找到以下旅游景點”
我們來看一下我們這兩次的對話,第一個需求是吃飯的地點,第二個需求是旅游景點,很顯然是不同的意圖表達,但是地點北京和人數都是一致的,也就是說槽位信息是一樣的。
假如你第二輪對話把“那旅游景點有哪些呢?”改成“那明天呢?”,如果把“北京”,“2人”和“那明天呢”組合在一起,是不能構成完整的信息表達的。
“跨意圖非線性多輪”問題的邊界:聯系上文,上一個意圖的槽位信息可以為下一個意圖所用,才能獲得用戶完整意圖信息。
現在普遍的實現,失去配置一個意圖的“輸入前置語境”和“輸出語境”,來限定某個意圖在第二輪的觸發。
比如:在“查飯店”這個場景中,兩個intent分別為“查飯店”和“查景點”。那么,在“查景點”這個跨意圖的配置中,前置輸入語境條件就是“查飯店”這個intent,觸發“查景點”這個意圖的必要要素就是“旅游景點”這四個字,然后槽位就是繼承自“查飯店”的槽位?!奥糜尉包c”的前置輸入語境條件也可以是“查酒店”“查出行方式”等其他可以繼承使用的槽位的意圖。
可以得知:如果我們在第一輪交互的時候,如果用戶僅僅問“那旅游景點有哪些呢?”要么就不會出發意圖,要么就是需要“線性多輪”或其他方式去補充必填槽位。而通過“跨意圖非線性多輪”的配置,在符合前置語境的條件的情況下,是可以匹配上“查景點”這個意圖,并且可以通過上文的槽位繼承的方式形成“完整用戶意圖”去請求后續的服務。
總結
本文由 @ walle 原創發布于人人都是產品經理。未經許可,禁止轉載
題圖來自Unsplash,基于CC0協議
多倫對話很好的思路,感謝!
寫的很好
謝謝
歡迎大家評論啊,有什么地方晦澀難懂的,可以留言,爭取給大家最好的閱讀體驗,
現在的DM應該更加是這樣的邏輯吧,先切分到不同的domain中去,然后進入到domain的bot,資源庫的是針對一個個bot的。圖上的DM 的架構更加像Alexa在Mars發布的intent直接打平,穿越bot的intent實現無縫調用。
您說的我就更不懂了,大神,我剛入行,拜托加個好友,求教一下:flysir
太專業了,看不懂,小弟剛入行,拜托加個好友,求教一下:flysir