起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識填槽與多輪對話：AI產品經理需要了解的AI技術概念
文章對填槽與多輪對話這一AI概念展開分析解讀，希望能夠幫助PM普及一些AI層面上的知識。
以一周前的這條微博作為開始——
一周前我講：相對的，自然語言解析技術已經逐漸不再成為各家廣義智能助理產品的核心競爭力，識別用戶意圖之后所提供的服務開始成為對話機器人差異化的核心。
對于一個對話系統而言，我微博中所指的『后續服務』，就是上圖中的 DST（對話狀態維護）以及 Policy（動作候選排序），或者統一的稱其為 DM（Dialogue Mannagement，對話管理）。也即，當接收到 NLU 模塊的輸出、其他場景及用戶特征信息之后，判斷系統應該跳轉到什么狀態，以及執行什么樣的動作。
產品角度，DM 是對話機器人封閉域多輪對話體驗的核心，正是一次次 DST + Policy 形成了人機間的多輪對話體驗。
注：我個人傾向于將“識別用戶意圖之后，為了獲取必要信息，與用戶進行的有目的的多輪對話”稱為封閉域多輪對話，區別于識別用戶意圖之前，為了利用上文信息，所采用的『上下文替換』、『主體補全』等技術，也即開放域多輪對話。下文提到的『多輪對話』，均指封閉域多輪對話。
既然多輪對話在對話機器人類產品體驗中扮演著如此重要的角色，我便開始思考：一個架構完備的多輪對話體系應該是什么樣的。也即，多輪對話系統中，至少需要包含哪些模塊，才能為用戶提供一種與人人對話相去不遠的人機對話體驗。
一、多輪對話
多輪對話定義
我有個習慣，就是在構造一個復雜系統之前，先從紛繁的細節之中跳出，嘗試抽象的描述整個系統，及系統中的各個模塊，也即為它們『下定義』。這能幫助你在多種可行方案中做出選擇，也即幫你明確：什么該做，什么不該做，什么該誰做。
基于以上思想，我嘗試先給出幾個我個人對于多輪對話體系定義問題的回答——
基本定義：什么是多輪對話？?（封閉域）多輪對話是一種，在人機對話中，初步明確用戶意圖之后，獲取必要信息以最終得到明確用戶指令的方式。多輪對話與一件事情的處理相對應。
補充說明1：所謂『必要信息』一定要通過與用戶的對話獲取嗎？?不一定，即便是人與人之間的交流，對話本身所包含的信息也只占總傳遞信息量的小部分，更多信息來源于說話人的身份、當前的時間/地點等一系列場景信息。所以多輪對話的信息獲取方式，也不應當只局限于用戶所說的話。
補充說明2：多輪對話一定在形式上表現為與用戶的多次對話交互嗎？?不一定，如果用戶的話語中已經提供了充足的信息，或者其它來源的補充信息已足夠將用戶的初步意圖轉化為一條明確的用戶指令，那就不會存在與用戶的多次對話交互。
以上，是針對多輪對話整體定義問題的回答，每個模塊的相關定義會在下文嘗試給出。
二、槽
1、槽（slot）
基本定義：什么是槽？?槽是多輪對話過程中將初步用戶意圖轉化為明確用戶指令所需要補全的信息。一個槽與一件事情的處理中所需要獲取的一種信息相對應。
補充說明：多輪對話中的所有的槽位都需要被填充完整嗎？?不一定，以如下對話為例——
我：『去蕭山機場多少錢』
出租車司機：『70』
對話中的『70』，應當被理解為70元人民幣，而不必再去追問：『你說的是人民幣、美元、日元還是港幣？』。這類信息應當以默認值的形式存在，也即槽有必填與非必填之分，與上文所說的『信息未必需要通過與用戶的對話獲取』相對應。
2、詞槽與接口槽
上文反復的提到，對話內容并不是獲取信息的唯一方式，用戶身份以及當前場景也包含著大量值得被利用的隱含信息。所以，與此相對的，一個完備的多輪對話體系應當同時具備從用戶話里以及話外獲取信息的能力。
我個人將“利用用戶話中關鍵詞填寫的槽”叫做詞槽，“利用用戶畫像以及其他場景信息填寫的槽”叫做接口槽。
舉個例子，我講『我明天要坐火車去上?！弧Ｆ渲?，分別將『明天』、『上?！惶钊朊麨椤撼霭l時間』、『目的地』的詞槽中，而我當前所在的位置，則填入到了名為『出發地』的接口槽中。
3、槽組與槽位
我個人將“利用用戶話中關鍵詞填寫的槽”叫做詞槽，“利用用戶畫像以及其他場景信息填寫的槽”叫做接口槽。
舉個例子，我講『我后天要坐火車去上?！弧Ｆ渲?，分別將『后天』、『上海』填入名為『出發時間』、『目的地』的詞槽中，而我當前所在的位置，則填入到了名為『出發地』的接口槽中。
不知道上文錯的如此離譜的結論，有沒有引起你的注意：）
仔細讀一遍上面舉的例子，就會發現一個很嚴重的矛盾點：難道『出發地』這個槽不能由用戶指定？用戶完全可以說『我后天要坐火車從北京去上?！唬撬窃~槽還是接口槽？而且更進一步的，難道只能用『我當前所在的位置』來填入『出發地』這個槽中？比如，如果能讀到我的日程表，發現我明天會去杭州，那是不是就應該用『杭州』而不是『我現在所在的位置』來填『出發地』這個槽了？
從中我們能發現什么呢？同一個槽，可能會存在多種填槽方式。
我將可能包含多種填槽方式的槽稱為槽組，槽組下面可能存在任意多個槽位，也即任意多種填槽方式，而每個槽位又都對應著『詞槽』與『接口槽』兩種槽位類型之一。
本質上來講，槽組（也即上文中提到的『槽』），對應著一種信息，而幾乎不會有哪種信息的獲取方式只有一種。所以一個『槽』會同時對應多種填槽方式也就是自然而然的了。
依照上文，同一種信息會有多種獲取方式，也即同一個槽組會對應多種填槽方式（槽位）。那不同填槽方式之間必然會存在優先級的概念。
就如同上文『訂票』的例子，『出發地』槽包含三種填寫方式，一種詞槽、兩種接口槽，自然的，詞槽的優先級最高，『日程表中隱含的出發地』次之，『我當前所在的位置』再次。
如果將其與前文提到過的必填/非必填結合起來，其填槽過程應當遵循以下步驟：
- 嘗試填寫詞槽
- 若失敗，嘗試填寫第一接口槽『用戶日程表中隱含的出發地』
- 若失敗，嘗試填寫第二接口槽『用戶當前所在位置』
- 若失敗，判斷是否該槽必填
- 若必填，反問用戶，重填詞槽 *若非必填，則針對該槽組的填槽過程結束
我們需要知道，必填/非必填在邏輯上與槽組而不是槽位平級，只有信息才會分為必要/非必要，填槽方式不做這種區分。而且是否必填實際上與接口槽無關，只取決于是否需要與用戶進行交互。
4、澄清話術
與槽組（也即與一種信息）平級的概念還有一個，叫做澄清話術。
澄清話術是對話機器人希望獲取某種信息時所使用的問句。比如『目的地』對應的澄清話術就是『您想從哪出發呢？』，『出發時間』對應的澄清話術就是『您想什么時間出發呢？』。
顯而易見的，澄清話術與槽組而不是槽位平級。
5、槽的填寫
上文講到，一個槽組可能會有多個槽位，槽位存在詞槽與接口槽之分。
先說詞槽。
詞槽信息的抽取其實還是有些麻煩的，不過這屬于解析的問題，不在本文探討的范圍內，這里只是簡單提一下，舉兩個例子：
- 用戶表達『不』，可能會有『不行』、『不是』、『算了』、『沒有』等一系列說法。
- 用戶話中有多個符合條件的關鍵詞，我們整套多輪對話中有多個槽，每個槽填一個還是多個值？哪個槽與哪個詞對應？
同義詞典、規則、雙向LSTM+CRF，各有各的方法。
再說接口槽。
接口槽與詞槽相比，額外存在一個問題，就是：接口返回的結果就是用戶需要的結果嗎？
這里需要分成兩種情況來討論，一種是：我們明確知道接口的返回值可以直接填入槽位（不是槽/槽組）中，不需要向用戶確認。
特別的，這里還要明確一點，即便是上述情況，也并不意味著當前槽/槽組只有該特定接口槽這一個槽位。有兩種情況存在：一種是該槽組下只有這一個槽位，該接口的返回值直接填入槽位中，也相當于填入了槽/槽組中；或者該槽位下有多個槽位，接口槽的填入值并不一定最終作為槽/槽組的填入值。
另一種是：我們知道接口的返回值只能作為參考，需要用戶的協助才能進行槽位的填寫。
這種情況下，需要提供選項，讓用戶最終決定該槽位的填入值，與詞槽一樣，這里同樣需要處理單值/多值的問題。單值/多值在邏輯上與槽組平級。
此外，這里還要注意一個否認選項的問題，比如我對阿里小蜜說，我忘記密碼了，它會通過接口拿到我的當前賬號，然后將其提供選項給我，問『你是忘記了哪個賬號的密碼？』，不過，除了我當前賬號之外，還有一個選項也被提供出來了，就是『不，不是這個賬號』。
這代表了一類問題的存在，用戶的意圖并不一定包含在接口的全部返回值之中。所以就必然會有這樣一種類似『不要/不是/不』的選項，我將其叫做否認選項。
用戶選擇否認選項后，即意味著該槽位的填寫失敗了，需要填入一個特殊值代表失敗。用戶選擇否認選項的失敗，可以與接口調用失敗等其它意外情況合并處理，因為這都意味著該槽位填寫失敗，意味著該種信息獲取方式未能成功獲取信息。
如果該槽組下只有這一個槽位，這個特殊的失敗表征值就應當作為整個槽組的填入值，如果還有其他槽位值，則根據槽位間優先級最終確定槽組填入值。
6、平級槽和依賴槽
上面說到底都在講一個槽組的填寫，也即一種信息的獲取，但多輪對話的目的是將初步用戶意圖轉化為明確用戶指令，這其中所需要的信息通常都不只有一種。
談完了槽組與槽位之間的關系，接下來談一下槽組與槽組之間的關系，也即信息與信息之間的關系。
為了便于理解，我先舉兩個例子來代表兩種多輪對話中所包含的極端情況。
第一種：訂車票，你需要知道用戶出發的時間、地點、目的地、座位種類。這四個槽組之間，沒有任何依賴關系。換言之，你只需要確定好這四個槽組中必填槽組之間的澄清順序，接收到用戶問句后，對還未填充完成的必填槽組依次進行澄清即可。我將這四個槽組之間的關系稱為平級槽關系。
另一種，不知道讀者玩沒玩過橙光，或者其它多結局的劇情類游戲。它們的特點是什么呢？每一個選擇都會有影響到后續劇情發展也即?每個槽組的填寫結果會影響其它槽組的填寫。換言之，部分槽組依賴前序槽組的填寫結果，在其依賴的前序槽組填寫完成之前，該槽組都無法進行填寫。我將槽組間的這種關系稱為依賴槽關系。
這種情況下，整個多輪對話過程就形成了一棵樹，極端情況下，這棵樹是滿的。樹上的每個節點放置著一個會對后續對話走向產生影響的槽組。
槽關系的選擇要根據實際業務場景來確定。
如果錯將平級槽采用依賴槽關系來管理，就會出現信息的丟失。比如 A、B、C，三者本為平級槽關系，但卻將其用 A->B->C 的依賴槽關系來管理，那即便用戶問句中包含填寫 B、C 槽組的信息，也可能會由于 A 槽組的未填寫而造成 B、C 槽組的填寫失敗。
如果錯將依賴槽采用平級槽的關系來管理，就會出現信息的冗余，比如 A、B、C三者的關系為 A、A1->B、A2->C，那即便用戶將值 A1 填入槽組 A 后，卻仍然需要向用戶詢問本不需要的 C 槽組的填寫信息。
上述兩種情況屬于全平級槽關系與全依賴槽關系的特殊情況，在實際的業務場景中，這兩種關系會是同時存在的，不同槽組間，既有平級槽關系，又有依賴槽關系。
實際業務場景中，完整的多輪對話過程通常會以樹的形式存在，每個節點存在一個或多個槽組，用于獲取一種或多種信息，節點間的槽組為依賴關系，節點內的槽組為平級關系。
上文將多輪對話定義為一件事情的處理，槽組/槽定義為一種信息的獲取，槽位定義為信息的一種獲取方式。這里我傾向于將多輪對話樹結構中的一個節點定義為處理事情的一個步驟。
一件事情的處理包含多個步驟，每個步驟中需要補全一種或多種信息，每種信息存在一種或多種獲取方式。
上述定義和組里算法大佬的定義有些分歧，不過誰讓這是我的文章呢：）就按我的來。
7、填槽意義
結合上文，我們需要了解到，填槽的意義有兩個：作條件分支多輪對話、作信息補全用戶意圖。換言之，填槽不僅是補全用戶意圖的方式，而且前序槽位的填寫還會起到指導后續信息補全走向的作用。
8、準入條件
上文我們講到，完整的多輪對話過程通常會以樹的形式存在，樹中包含多個節點，代表處理這件事情的一個步驟。
而每個節點，都應當有其特別的準入條件。樹的根節點往往需要限制?NLU 模塊的輸出，也即明確什么樣的用戶意圖將會由該棵多輪對話樹來處理；樹的中間及葉子節點往往需要根據前序槽組的填槽結果以及其他背景信息進行條件限制。（如果將所有信息，比如 NLU 模塊輸出，或是其他背景信息都看做前序槽組的填寫結果，那就能得到統一的槽組-條件-槽組-條件……形式，槽組用于獲取信息，條件用于信息限制）
我嘗試從兩個角度來描述一套完備的準入條件體系。
一個是多條件的組織形式，準入條件在邏輯上應該支持條件間的與或非，百度的 UNIT 平臺提供了一種相對成熟的組織形式，將準入條件整體劃分為條件和條件組，條件包含在條件組中，組內條件間是且關系，條件組之間是或關系（當然這里的且與或可以根據自身業務情況對調），條件本身支持非關系。
一個是單條件的限制能力，準入條件應當同時支持對前序槽組填寫值、填寫方式、填寫狀態進行限制。也即需要有針對值的條件、針對類型的條件和針對狀態的條件。簡單的講，狀態就是『填了嗎』，類型就是『誰填的』，值就是『填了什么』。
不同業務場景下我們會需要不同角度的限制條件。比如，上文中提到填槽的意義包含兩種：作條件分支多輪對話、作信息補全用戶意圖，如果僅僅作信息，那我們通常就只關心『填了嗎』，只要填寫完成就進行后續步驟，并不關系『誰填的』以及『填了什么』；但是如果槽組內的填入值會影響后續多輪對話走向，那我們就傾向于通過槽組的填入方式或填入值來作多輪對話的分支。
三、答案系統、話題切換和狀態切換
1、答案系統
先明確一個觀點，多輪對話樹的節點屬于對話節點而不是答案節點，同一份答案可能會出現在多個對話節點中。
答案系統和多輪過程應當是解耦的，答案系統中的每份答案都應當設置好自己的觸發條件。舉個例子，若存在 ABC 三個槽，A=A1、B=B3、C=C1 提供答案一，A=A2、B=B1、C=C2 或 A=A3、B=B2、C=C1 提供答案二。
另外，答案的種類也不應僅局限于文本，富文本、接口、話題切換，都可以視為合理的答案形式。
2、話題切換
話題切換指用戶與用戶的對話從一個多輪過程切換至另一個多輪過程，話題切換有主動切換和被動切換之分。
上文提到的作為答案的話題切換，就可以理解為主動的話題切換。
被動的話題切換是指，系統發現無法從用戶的問句中抽取信息以繼續當前的多輪對話，只好將其作為一條全新的問句重新進行解析和話題識別。
話題切換，尤其是主動的話題切換會涉及到一個新問題：槽繼承。舉個例子——
我：『我明天要坐高鐵從杭州到北京』
我：『算了，還是坐飛機吧』
這種情況下，機器人不應當重復詢問『出發地』、『出發時間』和『目的地』。
除了槽繼承，還有一個與之相對的問題叫做槽記憶，這通常適用在被動式的話題切換中。由于解析失誤，或者其他原因，使得用戶跳出了原話題，當用戶在一定時間內重新回到原話題時，不應讓用戶重復進行填槽，該技術已被用于阿里小蜜，不過他們似乎稱之為『多輪狀態記憶』。
舉個例子——
我：幫我訂張從杭州到北京的機票。
VPA：請問您希望哪天出發呢？
我：明天杭州下雨嗎？
VPA：明天杭州有雷陣雨。
我：后天呢？
VPA：后天杭州天氣晴。
我：機票訂后天的。
VPA：好的，已幫你預定后天從杭州到北京的機票。
3）狀態切換
我們還需要思考這樣一個問題，既然話題可以切換，也即一個多輪過程可以切換到另一個多輪過程，那多輪過程中的對話狀態是否可以切換？
我舉兩個例子——
第一個：
我：幫我訂張機票，從杭州出發。
VPA：請問你想去哪呢？
我：（發現明天杭州有雷陣雨）換出發地。
VPA：請問你想從哪出發呢？
我：上海。
多輪對話應當允許回到前序節點。
第二個：
我：我想買個杯子。
VPA：以下是為您推薦的杯子。（展示結果一）
我：換一換。
VPA：以下是為您推薦的杯子。（展示結果二）
多輪對話應當允許重復進入同一節點。
結語
就先這么多吧：）
作者：我偏笑?，AI產品經理大本營”成員，“AI研習小分隊”的分享嘉賓之一
本文由人人都是產品經理專欄作家?@黃釗?授權發布于人人都是產品經理，未經作者許可，禁止轉載。
題圖來自PEXELS，基于CC0協議
感謝作者分享。最近正在做類似工作，所以理解意圖，詞槽算比較輕松一點，我們這里沒有分這么細，只有統稱詞槽（沒有文中的詞槽、接口槽）