文章對填槽與多輪對話這一AI概念展開分析解讀，希望能夠幫助PM普及一些AI層面上的知識。

以一周前的這條微博作為開始——

一周前我講：相對的，自然語言解析技術(shù)已經(jīng)逐漸不再成為各家廣義智能助理產(chǎn)品的核心競爭力，識別用戶意圖之后所提供的服務(wù)開始成為對話機器人差異化的核心。

對于一個對話系統(tǒng)而言，我微博中所指的『后續(xù)服務(wù)』，就是上圖中的 DST（對話狀態(tài)維護(hù)）以及 Policy（動作候選排序），或者統(tǒng)一的稱其為 DM（Dialogue Mannagement，對話管理）。也即，當(dāng)接收到 NLU 模塊的輸出、其他場景及用戶特征信息之后，判斷系統(tǒng)應(yīng)該跳轉(zhuǎn)到什么狀態(tài)，以及執(zhí)行什么樣的動作。

產(chǎn)品角度，DM 是對話機器人封閉域多輪對話體驗的核心，正是一次次 DST + Policy 形成了人機間的多輪對話體驗。

注：我個人傾向于將“識別用戶意圖之后，為了獲取必要信息，與用戶進(jìn)行的有目的的多輪對話”稱為封閉域多輪對話，區(qū)別于識別用戶意圖之前，為了利用上文信息，所采用的『上下文替換』、『主體補全』等技術(shù)，也即開放域多輪對話。下文提到的『多輪對話』，均指封閉域多輪對話。

既然多輪對話在對話機器人類產(chǎn)品體驗中扮演著如此重要的角色，我便開始思考：一個架構(gòu)完備的多輪對話體系應(yīng)該是什么樣的。也即，多輪對話系統(tǒng)中，至少需要包含哪些模塊，才能為用戶提供一種與人人對話相去不遠(yuǎn)的人機對話體驗。

一、多輪對話

多輪對話定義

我有個習(xí)慣，就是在構(gòu)造一個復(fù)雜系統(tǒng)之前，先從紛繁的細(xì)節(jié)之中跳出，嘗試抽象的描述整個系統(tǒng)，及系統(tǒng)中的各個模塊，也即為它們『下定義』。這能幫助你在多種可行方案中做出選擇，也即幫你明確：什么該做，什么不該做，什么該誰做。

基于以上思想，我嘗試先給出幾個我個人對于多輪對話體系定義問題的回答——

基本定義：什么是多輪對話？?（封閉域）多輪對話是一種，在人機對話中，初步明確用戶意圖之后，獲取必要信息以最終得到明確用戶指令的方式。多輪對話與一件事情的處理相對應(yīng)。

補充說明1：所謂『必要信息』一定要通過與用戶的對話獲取嗎？?不一定，即便是人與人之間的交流，對話本身所包含的信息也只占總傳遞信息量的小部分，更多信息來源于說話人的身份、當(dāng)前的時間/地點等一系列場景信息。所以多輪對話的信息獲取方式，也不應(yīng)當(dāng)只局限于用戶所說的話。

補充說明2：多輪對話一定在形式上表現(xiàn)為與用戶的多次對話交互嗎？?不一定，如果用戶的話語中已經(jīng)提供了充足的信息，或者其它來源的補充信息已足夠?qū)⒂脩舻某醪揭鈭D轉(zhuǎn)化為一條明確的用戶指令，那就不會存在與用戶的多次對話交互。

以上，是針對多輪對話整體定義問題的回答，每個模塊的相關(guān)定義會在下文嘗試給出。

二、槽

1、槽（slot）

基本定義：什么是槽？?槽是多輪對話過程中將初步用戶意圖轉(zhuǎn)化為明確用戶指令所需要補全的信息。一個槽與一件事情的處理中所需要獲取的一種信息相對應(yīng)。

補充說明：多輪對話中的所有的槽位都需要被填充完整嗎？?不一定，以如下對話為例——

我：『去蕭山機場多少錢』

出租車司機：『70』

對話中的『70』，應(yīng)當(dāng)被理解為70元人民幣，而不必再去追問：『你說的是人民幣、美元、日元還是港幣？』。這類信息應(yīng)當(dāng)以默認(rèn)值的形式存在，也即槽有必填與非必填之分，與上文所說的『信息未必需要通過與用戶的對話獲取』相對應(yīng)。

2、詞槽與接口槽

上文反復(fù)的提到，對話內(nèi)容并不是獲取信息的唯一方式，用戶身份以及當(dāng)前場景也包含著大量值得被利用的隱含信息。所以，與此相對的，一個完備的多輪對話體系應(yīng)當(dāng)同時具備從用戶話里以及話外獲取信息的能力。

我個人將“利用用戶話中關(guān)鍵詞填寫的槽”叫做詞槽，“利用用戶畫像以及其他場景信息填寫的槽”叫做接口槽。

舉個例子，我講『我明天要坐火車去上?！?。其中，分別將『明天』、『上海』填入名為『出發(fā)時間』、『目的地』的詞槽中，而我當(dāng)前所在的位置，則填入到了名為『出發(fā)地』的接口槽中。

3、槽組與槽位

我個人將“利用用戶話中關(guān)鍵詞填寫的槽”叫做詞槽，“利用用戶畫像以及其他場景信息填寫的槽”叫做接口槽。

舉個例子，我講『我后天要坐火車去上?！弧Ｆ渲?，分別將『后天』、『上海』填入名為『出發(fā)時間』、『目的地』的詞槽中，而我當(dāng)前所在的位置，則填入到了名為『出發(fā)地』的接口槽中。

不知道上文錯的如此離譜的結(jié)論，有沒有引起你的注意：）

仔細(xì)讀一遍上面舉的例子，就會發(fā)現(xiàn)一個很嚴(yán)重的矛盾點：難道『出發(fā)地』這個槽不能由用戶指定？用戶完全可以說『我后天要坐火車從北京去上海』，那它是詞槽還是接口槽？而且更進(jìn)一步的，難道只能用『我當(dāng)前所在的位置』來填入『出發(fā)地』這個槽中？比如，如果能讀到我的日程表，發(fā)現(xiàn)我明天會去杭州，那是不是就應(yīng)該用『杭州』而不是『我現(xiàn)在所在的位置』來填『出發(fā)地』這個槽了？

從中我們能發(fā)現(xiàn)什么呢？同一個槽，可能會存在多種填槽方式。

我將可能包含多種填槽方式的槽稱為槽組，槽組下面可能存在任意多個槽位，也即任意多種填槽方式，而每個槽位又都對應(yīng)著『詞槽』與『接口槽』兩種槽位類型之一。

本質(zhì)上來講，槽組（也即上文中提到的『槽』），對應(yīng)著一種信息，而幾乎不會有哪種信息的獲取方式只有一種。所以一個『槽』會同時對應(yīng)多種填槽方式也就是自然而然的了。

依照上文，同一種信息會有多種獲取方式，也即同一個槽組會對應(yīng)多種填槽方式（槽位）。那不同填槽方式之間必然會存在優(yōu)先級的概念。

就如同上文『訂票』的例子，『出發(fā)地』槽包含三種填寫方式，一種詞槽、兩種接口槽，自然的，詞槽的優(yōu)先級最高，『日程表中隱含的出發(fā)地』次之，『我當(dāng)前所在的位置』再次。

如果將其與前文提到過的必填/非必填結(jié)合起來，其填槽過程應(yīng)當(dāng)遵循以下步驟：

• 嘗試填寫詞槽
• 若失敗，嘗試填寫第一接口槽『用戶日程表中隱含的出發(fā)地』
• 若失敗，嘗試填寫第二接口槽『用戶當(dāng)前所在位置』
• 若失敗，判斷是否該槽必填
• 若必填，反問用戶，重填詞槽 *若非必填，則針對該槽組的填槽過程結(jié)束

我們需要知道，必填/非必填在邏輯上與槽組而不是槽位平級，只有信息才會分為必要/非必要，填槽方式不做這種區(qū)分。而且是否必填實際上與接口槽無關(guān)，只取決于是否需要與用戶進(jìn)行交互。

4、澄清話術(shù)

與槽組（也即與一種信息）平級的概念還有一個，叫做澄清話術(shù)。

澄清話術(shù)是對話機器人希望獲取某種信息時所使用的問句。比如『目的地』對應(yīng)的澄清話術(shù)就是『您想從哪出發(fā)呢？』，『出發(fā)時間』對應(yīng)的澄清話術(shù)就是『您想什么時間出發(fā)呢？』。

顯而易見的，澄清話術(shù)與槽組而不是槽位平級。

5、槽的填寫

上文講到，一個槽組可能會有多個槽位，槽位存在詞槽與接口槽之分。

先說詞槽。

詞槽信息的抽取其實還是有些麻煩的，不過這屬于解析的問題，不在本文探討的范圍內(nèi)，這里只是簡單提一下，舉兩個例子：

• 用戶表達(dá)『不』，可能會有『不行』、『不是』、『算了』、『沒有』等一系列說法。
• 用戶話中有多個符合條件的關(guān)鍵詞，我們整套多輪對話中有多個槽，每個槽填一個還是多個值？哪個槽與哪個詞對應(yīng)？

同義詞典、規(guī)則、雙向LSTM+CRF，各有各的方法。

再說接口槽。

接口槽與詞槽相比，額外存在一個問題，就是：接口返回的結(jié)果就是用戶需要的結(jié)果嗎？

這里需要分成兩種情況來討論，一種是：我們明確知道接口的返回值可以直接填入槽位（不是槽/槽組）中，不需要向用戶確認(rèn)。

特別的，這里還要明確一點，即便是上述情況，也并不意味著當(dāng)前槽/槽組只有該特定接口槽這一個槽位。有兩種情況存在：一種是該槽組下只有這一個槽位，該接口的返回值直接填入槽位中，也相當(dāng)于填入了槽/槽組中；或者該槽位下有多個槽位，接口槽的填入值并不一定最終作為槽/槽組的填入值。

另一種是：我們知道接口的返回值只能作為參考，需要用戶的協(xié)助才能進(jìn)行槽位的填寫。

這種情況下，需要提供選項，讓用戶最終決定該槽位的填入值，與詞槽一樣，這里同樣需要處理單值/多值的問題。單值/多值在邏輯上與槽組平級。

此外，這里還要注意一個否認(rèn)選項的問題，比如我對阿里小蜜說，我忘記密碼了，它會通過接口拿到我的當(dāng)前賬號，然后將其提供選項給我，問『你是忘記了哪個賬號的密碼？』，不過，除了我當(dāng)前賬號之外，還有一個選項也被提供出來了，就是『不，不是這個賬號』。

這代表了一類問題的存在，用戶的意圖并不一定包含在接口的全部返回值之中。所以就必然會有這樣一種類似『不要/不是/不』的選項，我將其叫做否認(rèn)選項。

用戶選擇否認(rèn)選項后，即意味著該槽位的填寫失敗了，需要填入一個特殊值代表失敗。用戶選擇否認(rèn)選項的失敗，可以與接口調(diào)用失敗等其它意外情況合并處理，因為這都意味著該槽位填寫失敗，意味著該種信息獲取方式未能成功獲取信息。

如果該槽組下只有這一個槽位，這個特殊的失敗表征值就應(yīng)當(dāng)作為整個槽組的填入值，如果還有其他槽位值，則根據(jù)槽位間優(yōu)先級最終確定槽組填入值。

6、平級槽和依賴槽

上面說到底都在講一個槽組的填寫，也即一種信息的獲取，但多輪對話的目的是將初步用戶意圖轉(zhuǎn)化為明確用戶指令，這其中所需要的信息通常都不只有一種。

談完了槽組與槽位之間的關(guān)系，接下來談一下槽組與槽組之間的關(guān)系，也即信息與信息之間的關(guān)系。

為了便于理解，我先舉兩個例子來代表兩種多輪對話中所包含的極端情況。

第一種：訂車票，你需要知道用戶出發(fā)的時間、地點、目的地、座位種類。這四個槽組之間，沒有任何依賴關(guān)系。換言之，你只需要確定好這四個槽組中必填槽組之間的澄清順序，接收到用戶問句后，對還未填充完成的必填槽組依次進(jìn)行澄清即可。我將這四個槽組之間的關(guān)系稱為平級槽關(guān)系。

另一種，不知道讀者玩沒玩過橙光，或者其它多結(jié)局的劇情類游戲。它們的特點是什么呢？每一個選擇都會有影響到后續(xù)劇情發(fā)展也即?每個槽組的填寫結(jié)果會影響其它槽組的填寫。換言之，部分槽組依賴前序槽組的填寫結(jié)果，在其依賴的前序槽組填寫完成之前，該槽組都無法進(jìn)行填寫。我將槽組間的這種關(guān)系稱為依賴槽關(guān)系。

這種情況下，整個多輪對話過程就形成了一棵樹，極端情況下，這棵樹是滿的。樹上的每個節(jié)點放置著一個會對后續(xù)對話走向產(chǎn)生影響的槽組。

槽關(guān)系的選擇要根據(jù)實際業(yè)務(wù)場景來確定。

如果錯將平級槽采用依賴槽關(guān)系來管理，就會出現(xiàn)信息的丟失。比如 A、B、C，三者本為平級槽關(guān)系，但卻將其用 A->B->C 的依賴槽關(guān)系來管理，那即便用戶問句中包含填寫 B、C 槽組的信息，也可能會由于 A 槽組的未填寫而造成 B、C 槽組的填寫失敗。

如果錯將依賴槽采用平級槽的關(guān)系來管理，就會出現(xiàn)信息的冗余，比如 A、B、C三者的關(guān)系為 A、A1->B、A2->C，那即便用戶將值 A1 填入槽組 A 后，卻仍然需要向用戶詢問本不需要的 C 槽組的填寫信息。

上述兩種情況屬于全平級槽關(guān)系與全依賴槽關(guān)系的特殊情況，在實際的業(yè)務(wù)場景中，這兩種關(guān)系會是同時存在的，不同槽組間，既有平級槽關(guān)系，又有依賴槽關(guān)系。

實際業(yè)務(wù)場景中，完整的多輪對話過程通常會以樹的形式存在，每個節(jié)點存在一個或多個槽組，用于獲取一種或多種信息，節(jié)點間的槽組為依賴關(guān)系，節(jié)點內(nèi)的槽組為平級關(guān)系。

上文將多輪對話定義為一件事情的處理，槽組/槽定義為一種信息的獲取，槽位定義為信息的一種獲取方式。這里我傾向于將多輪對話樹結(jié)構(gòu)中的一個節(jié)點定義為處理事情的一個步驟。

一件事情的處理包含多個步驟，每個步驟中需要補全一種或多種信息，每種信息存在一種或多種獲取方式。

上述定義和組里算法大佬的定義有些分歧，不過誰讓這是我的文章呢：）就按我的來。

7、填槽意義

結(jié)合上文，我們需要了解到，填槽的意義有兩個：作條件分支多輪對話、作信息補全用戶意圖。換言之，填槽不僅是補全用戶意圖的方式，而且前序槽位的填寫還會起到指導(dǎo)后續(xù)信息補全走向的作用。

8、準(zhǔn)入條件

上文我們講到，完整的多輪對話過程通常會以樹的形式存在，樹中包含多個節(jié)點，代表處理這件事情的一個步驟。

而每個節(jié)點，都應(yīng)當(dāng)有其特別的準(zhǔn)入條件。樹的根節(jié)點往往需要限制?NLU 模塊的輸出，也即明確什么樣的用戶意圖將會由該棵多輪對話樹來處理；樹的中間及葉子節(jié)點往往需要根據(jù)前序槽組的填槽結(jié)果以及其他背景信息進(jìn)行條件限制。（如果將所有信息，比如 NLU 模塊輸出，或是其他背景信息都看做前序槽組的填寫結(jié)果，那就能得到統(tǒng)一的槽組-條件-槽組-條件……形式，槽組用于獲取信息，條件用于信息限制）

我嘗試從兩個角度來描述一套完備的準(zhǔn)入條件體系。

一個是多條件的組織形式，準(zhǔn)入條件在邏輯上應(yīng)該支持條件間的與或非，百度的 UNIT 平臺提供了一種相對成熟的組織形式，將準(zhǔn)入條件整體劃分為條件和條件組，條件包含在條件組中，組內(nèi)條件間是且關(guān)系，條件組之間是或關(guān)系（當(dāng)然這里的且與或可以根據(jù)自身業(yè)務(wù)情況對調(diào)），條件本身支持非關(guān)系。

一個是單條件的限制能力，準(zhǔn)入條件應(yīng)當(dāng)同時支持對前序槽組填寫值、填寫方式、填寫狀態(tài)進(jìn)行限制。也即需要有針對值的條件、針對類型的條件和針對狀態(tài)的條件。簡單的講，狀態(tài)就是『填了嗎』，類型就是『誰填的』，值就是『填了什么』。

不同業(yè)務(wù)場景下我們會需要不同角度的限制條件。比如，上文中提到填槽的意義包含兩種：作條件分支多輪對話、作信息補全用戶意圖，如果僅僅作信息，那我們通常就只關(guān)心『填了嗎』，只要填寫完成就進(jìn)行后續(xù)步驟，并不關(guān)系『誰填的』以及『填了什么』；但是如果槽組內(nèi)的填入值會影響后續(xù)多輪對話走向，那我們就傾向于通過槽組的填入方式或填入值來作多輪對話的分支。

三、答案系統(tǒng)、話題切換和狀態(tài)切換

1、答案系統(tǒng)

先明確一個觀點，多輪對話樹的節(jié)點屬于對話節(jié)點而不是答案節(jié)點，同一份答案可能會出現(xiàn)在多個對話節(jié)點中。

答案系統(tǒng)和多輪過程應(yīng)當(dāng)是解耦的，答案系統(tǒng)中的每份答案都應(yīng)當(dāng)設(shè)置好自己的觸發(fā)條件。舉個例子，若存在 ABC 三個槽，A=A1、B=B3、C=C1 提供答案一，A=A2、B=B1、C=C2 或 A=A3、B=B2、C=C1 提供答案二。

另外，答案的種類也不應(yīng)僅局限于文本，富文本、接口、話題切換，都可以視為合理的答案形式。

2、話題切換

話題切換指用戶與用戶的對話從一個多輪過程切換至另一個多輪過程，話題切換有主動切換和被動切換之分。

上文提到的作為答案的話題切換，就可以理解為主動的話題切換。

被動的話題切換是指，系統(tǒng)發(fā)現(xiàn)無法從用戶的問句中抽取信息以繼續(xù)當(dāng)前的多輪對話，只好將其作為一條全新的問句重新進(jìn)行解析和話題識別。

話題切換，尤其是主動的話題切換會涉及到一個新問題：槽繼承。舉個例子——

我：『我明天要坐高鐵從杭州到北京』

我：『算了，還是坐飛機吧』

這種情況下，機器人不應(yīng)當(dāng)重復(fù)詢問『出發(fā)地』、『出發(fā)時間』和『目的地』。

除了槽繼承，還有一個與之相對的問題叫做槽記憶，這通常適用在被動式的話題切換中。由于解析失誤，或者其他原因，使得用戶跳出了原話題，當(dāng)用戶在一定時間內(nèi)重新回到原話題時，不應(yīng)讓用戶重復(fù)進(jìn)行填槽，該技術(shù)已被用于阿里小蜜，不過他們似乎稱之為『多輪狀態(tài)記憶』。

舉個例子——

我：幫我訂張從杭州到北京的機票。

VPA：請問您希望哪天出發(fā)呢？

我：明天杭州下雨嗎？

VPA：明天杭州有雷陣雨。

我：后天呢？

VPA：后天杭州天氣晴。

我：機票訂后天的。

VPA：好的，已幫你預(yù)定后天從杭州到北京的機票。

3）狀態(tài)切換

我們還需要思考這樣一個問題，既然話題可以切換，也即一個多輪過程可以切換到另一個多輪過程，那多輪過程中的對話狀態(tài)是否可以切換？

我舉兩個例子——

第一個：

我：幫我訂張機票，從杭州出發(fā)。

VPA：請問你想去哪呢？

我：（發(fā)現(xiàn)明天杭州有雷陣雨）換出發(fā)地。

VPA：請問你想從哪出發(fā)呢？

我：上海。

多輪對話應(yīng)當(dāng)允許回到前序節(jié)點。

第二個：

我：我想買個杯子。

VPA：以下是為您推薦的杯子。（展示結(jié)果一）

我：換一換。

VPA：以下是為您推薦的杯子。（展示結(jié)果二）

多輪對話應(yīng)當(dāng)允許重復(fù)進(jìn)入同一節(jié)點。

結(jié)語

就先這么多吧：）

作者：我偏笑?，AI產(chǎn)品經(jīng)理大本營”成員，“AI研習(xí)小分隊”的分享嘉賓之一

本文由人人都是產(chǎn)品經(jīng)理專欄作家?@黃釗?授權(quán)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)作者許可，禁止轉(zhuǎn)載。

題圖來自PEXELS，基于CC0協(xié)議