通過本文內容，你將了解在搭建智能語音平臺的過程中，如何搭建一個技能以及支持不同的意圖，他們的本質和邊界是什么？

接下來我將從這幾方面進行展開：

1. 了解語音全流程框架
2. 意圖的組成部分
3. 多輪交互

一、語音全流程框架圖

首先，簡單說一下語音交互的全流程的概念：

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 基礎概念

意圖：用戶的每一輪對話，都可以認為是一個意圖，如“北京市今天天氣怎么樣”就對應著意圖【查詢天氣】。

語意槽：即從用戶說法中提取出的關鍵字，如“我要去上?！?，語意槽就是#地址#，取值“上?！?。

2.2 意圖的必要和必填參數

語音輸入怎么觸發意圖，把相關的意圖說法盡可能對應上設定的意圖，把不相關的說法阻擋，本質上就是一個邊界問題。

首先，跟著我來思考一下想要去上海旅游的話，應該怎么表達？

A：我想去旅游。

B：明天我想去上海旅游。

C：明天我想從北京去上海旅游。

D：我想飛到上海旅游。

句式A：有兩個必要信息，“去”，“旅游”。

句式B：有兩個必要信息，“去”，“旅游”；非必要信息“上?！薄懊魈臁保槭裁疵魈旌蜕虾Ｏ啾攘硗鈨蓚€信息而言是非必要呢？因為沒了非必要信息，兩個必要信息也能明白意圖，但是沒了兩個必要信息的其中一個，就不能理解意圖）。

句式C：有兩個必要信息，“去”，“旅游”；非必要信息“明天”，“北京”，“上?！?。

句式D：有兩個必要信息，“飛到”，“旅游”，非必要信息“上?！?。

為什么定義“去”和“旅游”是必要信息呢？

如果你單說旅游的話，可能有旅游雜志，旅游景點，旅游指南等多種意圖，但是如果你加上了“去”，那就代表你想去旅游，是一個出行計劃類意圖。

如果你單說去的話，可能有去吃飯，去購物，去旅游等多種意圖，但是如果你加上了“旅游”，那就代表你想去旅游，是一個出行計劃類意圖。

為什么定義“上?！?，“北京”“明天”是必填信息呢？

觸發了去旅游的意圖后，需要有出發地點、目的地，以及時間等必填參數才能完成服務，所以“目的地”“出發地”“時間”成為意圖的兩個“必填槽位”。

必要參數下面的“必要”和“必填”他們要解決的問題在本質上是不一樣的。

• “必要”是針對某說法能夠匹配到某個意圖，它的本質是“邊界判斷”，作用是對意圖進行分類和句式匹配。
• “必填”是在意圖已經確定的情況下，去請求后續服務的“必填參數”。

我們可以總結如下，一句話的信息可以按照“信息類型”和“必要要素”來劃分：

1. 必填槽位信息，比如“上?！薄氨本?/li>
2. 必要意圖信息，比如“去”“旅游”
3. 非必填槽位信息
4. 非必要意圖信息

所以，在配置意圖句式的模塊，對于是否觸發意圖這個邊界而言，“必要要素”是可以不含有解析框架中的任何槽位的，但是必須包含必要意圖信息。

但是，對于一條完整的意圖句式，一定要包含必要意圖和必要槽位兩個信息，必要槽位的信息可以有默認設置。

2.3 意圖句式

我們再來看一下這幾個例句：

A：我想去旅游

B：明天我想去上海旅游

C：明天我想從北京去上海旅游

D：我想飛到上海旅游

A和B的區別在于：僅僅在“去{上海}旅游”之間加了一個地名。

B和D的區別在于：“去”和“飛到”的表達差別。

這樣我們就可以得出一個結論：在一個句式中，我們把必要意圖信息按照順序排列好的基礎邊界句式，只要符合這個邊界的句式，全部可以匹配到這個意圖。

后續的工作就是把一些“非必要信息”配置上去以覆蓋更多的句式，比如必要意圖信息“去”“旅游”，非必要意圖信息“上?！?，“明天”，就可以組成句式如：

• {時間}去旅游。
• 去{地名}旅游。
• {時間}去{地名}旅游。
• {時間}飛{上海}旅游。

在原有必要要素組成的基礎句式基礎上面，我們可以增加非必要要素的配置、排列組合和詞庫等，衣服和這個邊界的更多句式。

在思必馳平臺上線的食材管理意圖里，自定義的一些句式說法：

三、多輪對話

多輪對話現在普遍的劃分方式，分為“線性”多輪和“非線性”多輪。

從功能層面上講：

• 線性多輪是在必填槽位缺失，通過系統主動發起追問的方式，去獲得缺失的槽位；
• 非線性多輪是需要聯系上文才能獲得用戶完整意圖的問題；

3.1 線性多輪定位與邊界

線性多輪解決問題得邊界，是在一個意圖的對話中，命中了必要意圖信息，但是觸發之后，卻缺失了意圖所請求服務必要要素（必填槽位信息）。

“必填槽位信息”是已經事先被定義好的，線性多輪的存在位置，就是為了彌補這個缺失。

舉例：導航意圖

必要完整要素：幫我導航到目的地（必要意圖要素+必填槽位要素）

用戶：“幫我導航”

反饋：“您要去哪里？”

用戶：“天安門”

反饋：“正在為您導航到天安門”

當觸發到必要意圖的時候，但是沒有必填槽位，就反饋尋找必填槽位信息，如果接下來的輸入是所需要的必填槽位，就請求服務，如果對應不上必填槽位信息，就正常執行即可。

3.2 非線性多輪-意圖內非線性多輪邊界問題

首先跟我來思考一下，日常生活中的對話。

周末無聊，你想看黃渤主演的綜藝節目來打發無聊時光，這時候你就可以跟女朋友說：“你給我找找綜藝節目?！?/p>

然后，女朋友興高采烈的給你搜羅著各類綜藝，問你：“你想看搞笑的？智力的？還是什么？”

你跟女朋友說：“我想看黃渤參與的?！?/p>

這時候，女朋友就給你找出了黃渤參與的綜藝類節目。然后，我們把對話置于智能語音助手上面就得出如下情況：

人：“我想看綜藝?！?/p>

機：“為您找到以下綜藝?！?/p>

人：“看黃渤參與的?！?/p>

機：“為您找到黃渤參與的綜藝節目?！?/p>

通過以上的例子，我們可以得出：在用戶第一輪對話后，我們可以知道了用戶的意圖（看綜藝）。第二輪給出主演人的非必填槽位，那么在看綜藝的這個意圖上面是可以增加主演人的非必填槽位的，我們就可以去補充上意圖的槽位，去相應用戶的需求。

邊界：需要聯系上文的意圖，如果接下來對話涉及到的槽位信息可以替換或補充上文的槽位，就可以獲得用戶的完整意圖信息。

得到這個邊界之后，我們在配置必要因素的時候，應該考慮：

1. 意圖中的哪些槽位是可以改變的？比如：我想看綜藝，也可以是我想看黃渤的綜藝，又或者是我想看黃渤最新的綜藝。
2. 哪些意圖是可以做槽位改變的？比如：我想看綜藝就可以有槽位的改變，我想去旅行對目的地，出發地的槽位進行改變，但是播控等一些簡單基礎意圖就不需要了。比如：播放，聲音大一點等都是單獨執行的命令，沒有必要增加其他的槽位信息。

3.3 非線性多輪-跨意圖非線性多輪邊界問題

接下來，繼續跟我進入一個場景：

假如你想帶你的女朋友去北京旅游，為了向女朋友展示你的體貼和細致，你想提前制定一下旅游計劃，比如：你在大眾點評篩選地點北京，人數2人，類別吃飯，然后給你推薦了許多吃飯地點。

如果這時候你點擊類別的景點，他就會為你篩選出來適合2個人在北京旅游的景點，這時候你不用再去輸入北京和人數了。

如果我們把操作對話置于智能語音助手上面就得出如下情況：

人：“幫我查查北京適合2人的吃飯地點”

機：“為您找到以下地點”

人：“那旅游景點有哪些呢？”

機：“為您找到以下旅游景點”

我們來看一下我們這兩次的對話，第一個需求是吃飯的地點，第二個需求是旅游景點，很顯然是不同的意圖表達，但是地點北京和人數都是一致的，也就是說槽位信息是一樣的。

假如你第二輪對話把“那旅游景點有哪些呢？”改成“那明天呢？”，如果把“北京”，“2人”和“那明天呢”組合在一起，是不能構成完整的信息表達的。

“跨意圖非線性多輪”問題的邊界：聯系上文，上一個意圖的槽位信息可以為下一個意圖所用，才能獲得用戶完整意圖信息。

現在普遍的實現，失去配置一個意圖的“輸入前置語境”和“輸出語境”，來限定某個意圖在第二輪的觸發。

比如：在“查飯店”這個場景中，兩個intent分別為“查飯店”和“查景點”。那么，在“查景點”這個跨意圖的配置中，前置輸入語境條件就是“查飯店”這個intent，觸發“查景點”這個意圖的必要要素就是“旅游景點”這四個字，然后槽位就是繼承自“查飯店”的槽位?！奥糜尉包c”的前置輸入語境條件也可以是“查酒店”“查出行方式”等其他可以繼承使用的槽位的意圖。

可以得知：如果我們在第一輪交互的時候，如果用戶僅僅問“那旅游景點有哪些呢？”要么就不會出發意圖，要么就是需要“線性多輪”或其他方式去補充必填槽位。而通過“跨意圖非線性多輪”的配置，在符合前置語境的條件的情況下，是可以匹配上“查景點”這個意圖，并且可以通過上文的槽位繼承的方式形成“完整用戶意圖”去請求后續的服務。

總結

本文由 @ walle 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議