每天資訊chatbot系列:對話設計中槽位的概念

菜單

chatbot系列:對話設計中槽位的概念

槽位是系統需要想使用者收集的關鍵資訊。本文從宏觀和微觀的角度,對槽位的類別分別進行了介紹。

chatbot系列:對話設計中槽位的概念

首先介紹下什麼是槽位。

槽位其實是個特定概念,是系統需要向用戶收集的關鍵資訊。而填槽則是收集使用者資訊的過程,是使用者將模糊或缺失的意圖補全的過程,而槽位值就是使用者表達的具體關鍵資訊。

打個比方,以種樹為例,種植者需要在適宜的土裡挖坑,並在坑裡撒種子,這個坑就相當於槽位,而在坑裡撒種子就等於填槽。具體撒的是什麼品種的種子就類似於槽位值的概念。

槽位從宏觀上講有三大類:垂直槽位或叫遞進槽位,平行槽位、組合槽位。

1。 垂直槽位

系統透過某個話題設定多個槽位,並且按照其預設的路徑引導使用者一個個去填槽,同時給出相應的答案。這些槽位通常是引導使用者深入話題的關鍵節點,而答案則是由這些節點牽引出的“故事情節”。

一般來說每個槽位都會給出幾個槽位值供使用者選擇(槽位值數量不多可窮舉/“是否類”的判斷型槽位),或者直接讓使用者輸入(半開放式,無法窮舉)。比如系統問使用者“是否炒過高送轉題材”,並給出“炒過”、“沒炒過”兩個判斷類問題的選項。又比如系統問使用者“您買入同花順的價格是多少”,這種半開放式的問題就需要使用者直接輸入。可以透過系統校驗看輸入的值是否合理。

垂直槽位以系統主動式對話為主,引導使用者按照既定的“故事線”發展。有點類似遊戲設計裡的前景故事。而且每個槽位都是往路徑更深一步的方向前進(除結束對話的選項外,如“聊點別的”)。

2。 平行槽位

通常以任務導向型對話為主,而且完成任務所需的槽位數基本上是固定的。

一般由使用者主動發起,系統根據使用者問句判斷缺少的槽位資訊,再進一步透過對話蒐集資訊,最終幫助使用者完成任務。

比如訂機票,包含時間、航班、目的地、出發地等槽位。使用者在向系統傳送問句可能會缺少部分槽位的槽位值,如“幫我訂一張從杭州飛北京的機票”就缺少時間、航班等槽位資訊。

這時就需要透過系統和使用者多輪對話來完成填槽的過程。不過有些包含流程的任務導向型對話也會存在先後關係。

比如支付訂單流程:“下單-填寫收貨資訊-確認訂單-支付-等待發貨……”,而“支付”環節可能又包括,“調取第三方支付平臺-輸入密碼-支付成功”。每個環節的槽位和槽位之間存在遞進關係。

平行槽位之間通常沒有先後順序,因此填槽的過程也是不固定的。主要看使用者提供的資訊缺少哪些內容,再決定先問什麼,再問什麼。但有時候會給平行槽設定優先順序,哪些槽位是必填,哪些是可填可不填。另外也會給平行槽排序,優先獲取哪些資訊。

3。 組合槽位

既包含垂直槽位又包含平行槽位。還是以上面支付訂單流程為例。流程中環節和環節之間的關鍵節點主要是垂直槽位,會決定每個分支的走向。某個流程環節內的是平行槽位。

比如“下單-填寫收貨資訊”中,“確認下單”就是垂直槽位,提供的“確認下單”,“返回檢視”兩個槽位值會引導使用者到不同的分支。使用者選擇“確認下單”就直接進到“填寫收貨資訊”環節,選擇“返回檢視”則是回到上一輪對話。而“填寫收貨資訊”環節內包含的姓名、地址、電話等都是平行槽位。

平行槽位不會決定路徑的分支走向,而是決定了路徑能否走通。

槽位從微觀上來說有三類:自定義槽位、詞庫槽位、介面槽位。

1。 自定義槽位

從運營後臺配置上看,自定義槽位就是運營可以自己編寫的分支路徑選項,選項作為前端推薦展示給使用者。

每個不同的路徑選項,都有自成一體的對話流邏輯,相互之間並不會重疊和影響。不同分支路徑下的對話流,相當於是故事的走向。而具體按什麼故事線走,就需要使用者在分支節點進行選擇。

自定義槽位裡面的值及數量並不固定,運營可以根據對話流走向的需要自定義編寫和增減。一些判斷類的問句,也可以用自定義槽位來給出推薦選項。

比如系統問“想要試試這個技能嗎”,給出的槽位值就是“好的”、“不用了”。

自定義槽位在槽位值取名上可以更加豐富,有個性。

還是上個例子,自定義槽位對應的“是否”選項值可以改為“好哇,試試唄”、“不用啦,下次吧”,更顯人性化特徵。

2。 詞庫槽位

詞庫槽位相當於是取資料庫的一組資料作為選項,或是作為匹配項來驗證使用者輸入。資料組對應槽位,每個資料點對應槽位裡面的值。

若詞庫槽位值的資料量比較小,可以作為推薦選項展示給使用者。若資料量中等,可以先展示幾個選項,同時支援使用者輸入。

其餘未展示的選項用來驗證使用者輸入是否與之匹配(使用者輸入不同於選項的情況下)。

若是資料量比較大,可以不展示選項,直接讓使用者手動輸入。此時系統問句要帶上提示,告訴使用者輸入的內容,怎麼輸入,資料格式或話術表達是否有限制要求等。

3。 介面槽位

等同於詞庫槽位,只是介面槽位是外部提供的,詞庫槽位是內部資料庫的資料。

本文由 @mileyhuang 原創釋出於人人都是產品經理,未經許可,禁止轉載。

題圖來自 Unsplash,基於CC0協議。