面向NLP的AI產品方法論——如何設計多輪語音技能
本系列文字是一位創業者的投稿《面向NLP的AI產品方法論》，老曹盡量不做變動和評價，盡量保持系列文章的原貌，這是第2篇。
設計語音技能跟軟件開發一樣集體協作完成，本文主要討論，產品經理在業務各階段開發中，應該處理的任務。
在產品設計階段，產品經理應該需要思考的3個任務，以及在后續【業務開發】【功能驗收】【更新迭代】階段的2個任務。
給自己做一個命題作文，比如，電影。(其實是從外賣，電影、酒店3個里面隨機選的)
電影有2類服務，一個是通過語音購買電影票，屬于多輪語音交互，一個是通過語音點播電影節目，單輪語音交互。討論多輪的時候順帶上單輪。
語音購買電影票，本文不討論語音下單支付。語音點播電影，本文不討論語音控制(暫停/播放/快進/換一個/音量控制)。
不討論與開發溝通、需求文檔、數據埋點、后臺工具接入、風控預警、支付訂單、GUI的設計……只討論如何做好多輪語音交互技能設計。
1、使用場景與用戶畫像
產品的基本功，怎樣的用戶在什么情況下，使用什么硬件設備，使用語音達成目標?
語音技能是專門對不同的群體而設計的，比如對盲人設計訂餐功能，比如專門為外賣/快遞小哥，設計打/接電話，群發短信的服務等，都是要考慮好用戶畫像。為方便大眾理解，以電影作為例子。
點播電影使用場景:
- 用戶在家/辦公室，使用智能電視/有屏音箱，通過語音點播電影。
- 用戶在車里，通過車機，使用語音點播電影。
在車里語音點播電影節目，可以是“播放喜羊羊第5集”給后座帶屏幕的小孩看。
主屏的車機只做操控，不適合播放任何電影，干擾司機駕駛(即使是副駕駛有觀影需求)這個就是一個權衡，必要的時候，還要通過攝像頭檢測司機的眼動以保證駕駛安全，當然自動駕駛到達某種程度，我們交付給用戶的體驗，又會進行改變。
同時也要考慮一下其他語義之間的沖突和關聯。比如說，“我想看窗外”(假設有個這個名字的電影，或者是誤識別)會不會跟“語音控制車窗打開”這類技能互相沖突。
買電影票使用場景:
- 用戶在車里通過語音購買電影票。
- 用戶在任意地方通過語音買電影票。
買電影票而言，用戶雖然是全程填槽，但是在家使用，和在車機使用是完全不同的場景。
在室內使用，買電影票，用戶沒有明確某個電影，話術可以是“為你找到如下電影”加展示列表的方案，然后用戶可以使用眼睛做篩選，手指滑動電影列表，點觸選場次、座位等。
在車內使用，用戶同樣沒有明確，我們盡量不希望干擾司機的視線和手指，會采用，報電影名的方案，“評分前三的是《電影1》《電影2》《電影3》你想看那一部?”這種選擇的方案，盡量保護司機的眼睛和手不受打擾，后面的設計邏輯以此類推。
買電影票買的是服務，用戶有明確某個電影，然后找電影院的需求。同樣有為了消遣時間(電影是其中一個選項)，先找電影院，然后選擇看什么電影的需求。這些都是不同的場景行為。
這種就是在怎樣的場景下，用戶如何用語音技能服務，在設計技能的時候，這一類思考一定要到位，后面的所有設計，也是基于場景開展。
2、中控設計與業務邊界
添加一個技能并不是那么簡單，要站在全局角度去思考問題。
點播電影，從發起需求到電影播放。
買電影票，從發起需求到生成訂單進入支付環節。
此處存在幾種情況。
- 情況1、此前沒有，從0到1搭建一個新技能，如此業務處理就簡單。
- 情況2、已有一種技能存在，新增另外一個技能，要考慮并行情況。
比如當用戶說“我想看電影”，如果是情況1，單個技能則很容易處理。
但是如果是情況2，兩個技能同時存在，“我想看電影”就是一個模糊表述。
接下來的業務流程處理，就十分值得討論和考究了。
單個技能并不難，難得是如何處理好與其他已存在技能之間的關系。用戶在對話過程中的每一句話，都會被識別意圖。
用戶的第一句，使用顯性跳轉，直接進入對應的邏輯即可，這種情況非常容易處理，中控很容易根據用戶的意圖做分配行為。
難得是，用戶不使用顯性跳轉，采用模糊表述。
上面兩種選擇都是方案選擇，從實現難度上而言，從體驗層面而言，產品經理做得都是基于各種約束條件下的效用選擇。
以下兩種情況，用戶全程無意識，但是造成了，連續兩句話都是模糊表述的情況。
我們先假設自己的語音助手同時存在，電影點播和買電影票2個技能，來看看用戶連續2句話都是模糊表述的情況。
語言表述就是如此，隨場景和時間變化，在某些情況下表述，就是是模糊，過一段時間(比如院線排片下線)表述，就不會引起歧義。
當用戶模糊表述的時候，如果每次都采用追問的方案，就非常尷尬了，這個后面會講，一方面用戶在某些語境下實際上就是“你應該懂我”當下我所指的是什么，而計算機則未必明白。
所謂業務邊界，相對而言比較容易理解。
點播電影歸類于【語音&內容】，取決于接口方提供的作品，要考慮未來播放其他的內容的邊界。比如有些經典作品名，存在音樂歌曲、戲劇、有聲小說、電影、MV、等多種形式，而咱們做的技能，恰好又包含上述，且接口豐富每種資源都能夠搜到，那么就需要通過上下文的理解去處理好每一種指代，繼而做好邊界處理。
買電影票歸類于【語音&服務】，通過篩選電影院、作品名、場次、座位等，最終達成下單的結果，流程清晰明確，那么買電影票的其他相關服務，比如買爆米花可樂一類的零食，辦理影城的會員卡一類附加的，則是邊界外的內容。
往往把點播電影做好了，點播其他的音頻、視頻內容，也大同小異。同理買電影票做好了，買其他的(音樂會、演唱會、戲劇、景點)票，也大同小異。相對而言就是主槽位和輔槽位的變化不同。
一開始就窮盡所有情況，后續管理和添加技能庫也方便拓展，而一開始想得比較簡單，后續想要加想要改，那就麻煩得多了。不光說業務邏輯層麻煩，訓練數據也很麻煩。
故而一開始就講了，這一塊是全局性的考量。
3、槽位設計與對話設計
自然語言處理，本質是結構預測，基于用戶的表述，提取用戶的話術里面的詞槽，通過服務接口，完成后續行為。
對話設計是基于場景設計業務邏輯，通過對話管理，最終幫助用戶達成目標。
點播電影需求明確，直接得到結果的有：播放電影星球大戰、播放周星馳的功夫、播放電鋸驚魂第三部等等。
還有一些篩選的行為，好萊塢最近有什么新電影、我想看喜劇片/動作片、評分前10的好萊塢電影、詹姆斯卡梅隆導演的電影等，然后基于搜索結果，確認播放行為。
故而歸納出點播電影的槽位：[影片名]、[主演]、[導演]、[影片類別]、[評分]……
點播電影相對簡單，篩選后即可播放。而買電影票則復雜的多，畢竟買電影買的是服務，篩選條件較多。
常規來看，用戶定電影票的流程一般有如下兩種情況。
已經想好了看某個電影，然后基于此，尋找電影院。例如：我想看IMAX版本的阿凡達，基于此完成后續的追問，最終完成填槽行為。
另一種純粹是為了消遣時間，先找附近的電影院，然后基于此完成后續的追問，最終完成填槽行為。
繼而提煉出買電影票的槽位。
通過例句我們可以看出，輔助槽位是用來幫助主槽位做查詢行為的。
主槽位一般是服務于整體流程需求的進行設計，輔助槽位是基于接口情況，以及自身理解進行設計歸類。
對話設計分為兩個部分，定義主流程和對話管理。
點播電影，只有一個，即為影片，所有的服務都是為了選中影片而服務的，選中了就直接播放。而買電影票則是，因為其業務屬性，需要4個主槽位都填寫完畢。
主體流程設計基于用戶習慣，只要在后續的對話過程中，把4個主槽位確認完畢，即可完成買電影票的下單行為。
對話管理。此處是引用一段在其他文章里面的內容。
- 在對話服務過程中，反向管理用戶的表達，完善槽位的引導。例如在買電影票的場景，從需求到下單至少需要4個核心槽位。A電影名，B電影院，C場次，D幾張票。(選座可以提供默認規則)想要完成訂單的確認，則成功引導用戶填充ABCD四個槽位即可。好的完善和引導，則是：如果用戶填充了AB，AI應該追問CD的例子：我想看《魔童哪咤》，幫我在附近找個最近的電影院。此時AI需要展示哪幾個場次可以選擇，然后追問要買幾張票如果填充了ABC，應該追問D的例子：我想看《魔童哪咤》，附近找個最近的電影院，8點鐘左右開場的。此時AI只需要追問要買幾張票即可。ABCD四個主槽位，無論用戶的先后順序，先填充哪個槽位，后續能夠完善填充即可。人類的表述千奇百怪，無論多少個槽位，人類都可以組織語言聯合起來表述。亂序填充槽位才是智能化，自然表述的的基本要求。
自然語言處理中，用戶僅能依靠有限的語音提示以及短期記憶來完成操作。因此對話設計需要通過明確提示用戶需要進行的反饋，以及能進行的選擇，逐步的縮小用戶的對話走向，幫助用戶明確意圖，并完成最終的服務提供。
4、異常情況與自查清單
用戶按照正常情況來，一般而言都能夠完成任務。但是總會遇見異常情況的，服務的完整性需要保障，包含以下但不限于：
1、接口服務故障，導致的無法查詢。故障如何上報，或是自家公司運維層面的故障錯誤。
2、接口服務正常，查不到對應的東西，推薦近似內容規則如何設計。如某個系列電影被買斷，但是沒有播放版權，如何給予近似推薦。
3、用戶在對話過程中如果歧義表述，如何修復對話，并把業務拉回到正軌上。
4、未覆蓋話術如何兜底、沖突條件如何做取舍，模糊表述如何應對。例如：
- 有沒有團購券，爆米花，介紹一下這個電影的劇情。
- 幫我找一個距離我最遠的電影院，買一張最貴的電影票。
- 有沒有10塊錢以內的IMAX電影票。(顯然是不可能的事)
還有一些否定表述，雙重否定，前后矛盾的表述。
異常情況有太多種類型，分布于業務設計中的各個階段。
- 階段1：產品經理憑借業務理解和設計經驗去思考異常情況。
- 階段2：測試過程中，其他人員發現了異常情況。
- 階段3：產品上線后，用戶遭遇了異常情況。
由于業務類型太多，無法逐一窮舉。
但是在這個過程中，我們可以為自己設計一套業務的自查清單，來幫助自己完善思考的維度。
可以自己從經驗中提煉，也可以學習其他的規范，典型如《Google對話式交互規范指南》《阿里語音交互設計指南》《亞馬遜語音交互設計規范》一類是用來管理話術設計的清單。
清單越多，自己的專業度越好，交付的產品質量保障越好。
很多的東西都是自我不斷完善，總結提煉，復盤消化后，最終內化為自己的專業能力。
5、技能測試與版本迭代
通過了自查清單后，然后進入了內部流程測試，一般而言分為兩個測試步驟。
內行自測：產品經理(VUI設計師)自己編寫對話測試用例。
外行復測：找小白用戶(非而業務相關的行政人事等)自由放飛測試。
這2個過程中，往往會產出各種數據，業務邊界及異常情況，以及各種修改建議，然后重新迭代調整，直至數據和體驗達到一定標準后，即可更新上線。
上線前，依照流程標準，已經做好了數據埋點，并搭建好了完整的用戶對話log分析后臺。
上線后，通過業務后臺觀察業務數據，和實際真實用戶的表述，繼而迭代技能，提升體驗。
舉一個例子，是筆者在后續觀察用戶對話日志時的一些發現。
《速度與激情8》剛剛上映，用戶會表述是我想看速度與激情、速激、速8等等;《魔童哪咤》上映的時候，用戶的表述是，我想看哪咤的電影;《葉問3》上映的時候，用戶的表述會是，葉問。甚至是甄子丹的那個電影;
這些就是真實的用戶表述，此處就需要考慮這類應對方案，增加NER，模糊查詢，動態詞庫管理。最終完成語音交互技能的迭代。
這類問題如果有共性特征，我還會進行業務自查清單的迭代，當下次處理同樣類型的業務時，便可提前考慮到位。
從這個例子可以得出：“一開始就做好”相比“通過各種渠道反饋發現不好，然后通過迭代去做好”，從產品設計基本功上來看，根本是兩種境界。
再列舉一個筆者在開發過程中印象深刻的例子，。
我們在設計電影票技能的時候，內部曾經討論到，如果用戶需求明確，且一口氣完整滿足4個詞槽，是否應當直接給予結果?例如：我幫我買2張《魔童哪咤》的電影票，附近找個最近的電影院，晚上8點鐘左右開場的，隨便什么座位都行。
為了完成這個，我們花費了不少精力。從我們后臺的實際數據表現去看，實際上用戶并不會這么說，很少有用戶做多個復合條件疊加查詢的，且從來沒有用戶會一口氣說出4個詞槽!可以明確一個結論，我們此前的的一部分工作被浪費掉了!
從這個例子，我們可以得出一個思考：面對難題，每個人都能出方案，而難題有多種不同的解法，方案有優劣之分，話術覆蓋有先后順序，精力的分配有側重考量……
希望大家盡快達到這種境界，能從多個看似不同的方案中，挑選出不同情況下的最優解，即通過大家的復盤總結，迭代出自己的語音交互設計方法論。
【本文來自51CTO專欄作者“老曹”的原創文章，作者微信公眾號：喔家ArchiSelf,id:wrieless-com】
