本系列文字是一位創業者的投稿《面向NLP的AI產品方法論》，老曹儘量不做變動和評價，儘量保持系列文章的原貌，這是本系列的最後一篇——第5篇
語音/對話式交互是一件非常有挑戰性的設計，極少有業務能一蹴而就。筆者所在的公司，過往開發了十幾個多輪語音交互技能，平均算下來，首個BOT上線後，差不多得有半年時間進行迭代，才能夠有穩定的，比較好的數據表現。
迭代優化的方法論有很多種，本文着重講，如何通過數據分析（也是筆者最喜歡用的），去迭代語音/對話式交互技能。
先引用此前筆者寫的《NLP方法論：如何設計多輪語音技能》一文，最後一個模塊的兩句話：
“上線前，依照流程標準，已經做好了數據埋點，並搭建好了完整的用戶對話log分析後臺。
上線後，通過業務後臺觀察業務數據，和實際真實用戶的表述，繼而迭代技能，提升體驗。”
工欲善其事，必先利其器，強大的數據後臺集羣，是讓業務變得越來越好的神兵利器。此前筆者也寫過如何搭建數據後臺，這裏就只講，在已有後臺的情況下數據分析思路。
一個AI語音交互助手，核心價值是幫助用戶完成任務，而在完成任務的過程中，又有着各種阻礙影響到AI助手爲用戶服務，傷害體驗，影響價值交付。所以我們解決問題的思考點在於：如何從業務過程中，通過數據發現各種問題。
問題一旦能被發現，就自然有解決方案。
從分析角度，筆者分爲三層（遞進延展）：
用戶在使用AI助手的過程中遭遇過哪些顯性問題。
爲什麼AI助手最終沒有幫助用戶完成任務。
如果用戶最終完成了任務，使用過程中有哪些不爽。
下圖是全文邏輯結構。
一、如何發現顯性問題
所謂顯性異常，指的是那些明顯影響用戶體驗，最終影響AI助手幫助用戶達成任務目標的問題。各家公司都能夠通過基本的規則設計發現問題，只要能發現問題，就有解決方案，各個業務設計者無非是，在有限條件下做業務權衡取捨。
來源1、數據後臺+風控預警
上線前一定要做好的數據埋點工作行爲。例如：網絡延遲、響應慢、異常、軟硬件故障、崩潰……此前在數據字典一文中也統計了這種情況（字段有刪減）。
既要統計行爲數，也要統計人次，行爲數代表着一共發生了多少次這類問題，人次代表着影響了多少個用戶（即範圍），事先設定好閾值，達到了一定情況就郵件/短信預警。
BOT業務一旦異常，就會迅速的被發現。當時間拉長到3個月，產品裏出現的各個方面的異常問題也能夠得出一條曲線，問題一暴露，針對性進行優化即可。
這類問題，屬於AI助手的穩定性考量範疇，但是一旦發生，極爲嚴重，基本上任務就沒法完成了。
來源2、踩贊分析+用戶後臺
DUI一般會設計這類功能反饋，以出門問問舉例，每次AI完成一句話後，底部都會有一個贊或者踩的功能。
同時也直接把客服模塊放到了較深的一個層級，用戶在使用過程中，向我們提出的各種建議，找客服人員投訴什麼的。
出門問問這一塊做得比較細緻，頁面層級比較深，期望用戶能夠給予更精準的反饋，到底自己的AI助手哪裏做的不夠好。
但是實際上，只有少量的用戶，會幫你做思考和分類，（我自己就是點個踩就跑掉，纔不幫你做分類呢，我就表達不爽，問題出在哪你自己想去），甚至你也攔不住用戶瞎填，這一塊完全就是把壓力推到用戶那邊，期望用戶付出更多的成本幫助定位業務問題。
但從另外一個角度而言，不也是有相當一部分用戶，認真分類填寫了，節省了我們的壓力麼？你看這其實是設計選擇，沒有好壞之分。
用戶的每次業務反饋都會在後臺出現，不管用哪種方式收集，都能夠以埋點的方式暴露出問題，暴露的人越多，這一塊的問題就越值得重視。自然這種問題類型，也會長期積累，跑出一個問題分佈圖。
來源3、關鍵詞搜索+情緒識別
前面的基本是用戶使用GUI交互行爲表達了不爽，但是這個範圍依舊不夠大，我們需要繼續延展。
如果是，用戶基本上不給點觸反饋、產品沒有設計踩的功能，亦或者是純語音交互，怎麼抓出來問題呢？
這一塊就能夠用得到對話log分析了，不討論隱私問題，基本上用戶跟AI助手發生的每一句語音，對話，點觸行爲，都會生成log。
一些關鍵詞搜索，必然是用戶表述的一些話，很容易就推理出，用戶必然受挫，只不過情緒程度不一樣。
另外一種就是使用模型算法，一般是用於輿情監控用的，可以抓出來用戶的積極/消極情緒和言論。有很多大廠都開放這類業務，不避嫌的話埋入自己的業務模塊裏面就好，當然你也可以自己訓練。
找到這些東西之後，然後分析這些話術出現在哪些技能裏面，分佈在哪個環節上，問題就自然暴露出來了。
二、是什麼導致任務未完成
用戶使用AI助手，就是爲了完成任務的。
對話過程中，如果用戶啓動了某項業務，最終（不管結果是好還是壞，用戶是否滿意）沒有結果，就是巨大的問題。
此處定義：任務未完成，指的是未成功填充全部槽位，用戶最終沒有得到結果。例如：買電影票和買機票沒到確認下單環節，問天氣，最終沒給到天氣結果等。
越是槽位越多的業務，越值得好好打磨，畢竟輪次越多，意外就越多，用戶隨時隨地會離開。
一般AI助手返回結果給用戶都會有一個標記。所以，此處的規則就比較容易定義。在一次會話行爲中，觸發了某項技能，最終該項技能沒有（標記）返回結果。這類問題就值得抓出來，進行定位分析。
數據提出來還要進行一些清洗行爲，例如：有些是失誤觸發，暴露的是中控錯誤理解，錯誤分配。有些用戶單單是啓動了該技能，最後直接退出，沒有超過1輪以上的對話，這些就不值得算進統計項內。
找出正常的用戶後，進行分析統計，比如4個槽位，僅僅填充了2個，用戶努力對話幾輪後，放棄掉了，哪裏卡住了，哪裏半途放棄了，這種就非常值得研究。很容易形成一個數據漏斗，看看問題主要集中出現在哪。
先解決有無結果的問題，然後纔有條件去討論結果優劣。
三、如何發現隱性問題
很多時候，用戶即使是磕磕碰碰，但最終還是可以完成任務，這些問題都是隱形的，那麼如何發現這些對話中的“磕磕碰碰”呢？
磕磕碰碰影響體驗，這種感受多了，用戶自然放棄。要發現這類問題，我們就得使用另外一項業務工具，對話log分析後臺。
討論之前，我們先明確一個概念：會話行爲，也稱之爲session。（雖然是業內大家都懂的，但可能定義不一樣，文章內還得解釋下。）
從進入到離開稱爲一次會話行爲，x分鐘（自定義）未檢測到用戶的對話，算作一次會話行爲的結束。
用戶一天內可產生x次會話行爲，每次會話行爲可能觸發1~y個業務，並進行z個對話輪次。
以用戶A舉例，該用戶在當天3個不同的時間段，產生了3次會話行爲，總共激活了5個業務，總計產生了11句對話輪次。
而我們的對話log分析後臺，就能夠以session爲單位，還原用戶的對話log，並解析在這次會話行爲中，用戶的表述和AI的理解。
簡單來說，用戶在一輪對話過程中，觸發了什麼技能，AI是如何理解這句話的意圖，並基於怎樣的業務邏輯進行回覆，（比如：獲得槽位後AI繼續追問，不滿意展示結果頻繁更換槽位，切換到其他技能）都可以通過這個工具進行展示和統計。
爲了幫助大家理解，引用此前寫過的文章中的例子。
“幫我找個好看點的/有內涵的/羞羞的電影”
“我想看關於海戰的電影”
“幫我找一個高大上的電影院”
“附近方便停車麼”
“我想選一個靠門的座位”
“這個電影院能辦理會員卡麼”當AI遇見這類問題無法問題，會出現如下幾種結果。
無法滿足需求，漏給兜底閒聊。無法識別意圖、觸發認慫話術。
兜底閒聊能接上話就好，一般AI認慫話術是，“抱歉我不明白，請對我說blablabla……”
如果上面的例子比較扯的話，來看下面在買電影場景下正常一些的例子。
“有沒有斯皮爾伯格導演的”
“我想看速激7”
“有沒有便宜點的”
“我要倒數第三排中間的座位”
“有沒有適合情侶去的私人電影院”這些又迴歸到業務設計上，就完全是業務以及語義覆蓋問題了。
此時，我們可以發現，在一次會話過程中，頻繁出現兜底，頻繁切換業務，頻繁認慫……這些都是非常影響用戶體驗的。
我們只需要設計一個抽樣規則，即，在一組會話中，若兜底大於x，切換業務大於y，認慫行爲大於z，可單獨抽樣，可疊加抽樣，就很容易篩選出對應的問題了。
同時我們還能對用戶的行爲進行抽樣分析。
個人認爲，能完成下單行爲的用戶，是真需求的用戶，他們的對話行爲的可信度非常高，如此可以規避掉那些隨便試試的用戶，類比就是逛淘寶但是不買的用戶。
例如：買飛機票這件事，最短路徑是3輪對話完成下單付費行爲，最長的是10幾輪後才完成下單付費行爲。爲什麼會有10幾輪呢？每個用戶不一樣，這個就得進一步去統計分析了。
比如我們可以統計出，過往x天（一般以BOT版本爲時間週期），所有完成訂單行爲的用戶，在指定業務下的平均對話輪數。用這個基準作爲比較，去發現問題。
提供幾個筆者的分析案例，也是此前的一些文章裏面提到過的。
案例一（買飛機票時，用戶切換技能後下單）
用戶在買飛機票的時候，我們發現相當一部分用戶會（擔心延誤）查看天氣，這個是用戶的購買決策依據，所以這個就給了我們啓發，不要讓用戶問，在查詢機票的時候，就直接一併顯示天氣情況了，如果有影響飛行的天氣，同時根據兩個城市的距離測算，給予一個火車/打車出行方式，給用戶做選擇。
同理推理出，在使用其他技能的時候，一定會有關聯查詢的，這就是通過分析得出的一個小優化點。這些都是通過數據分析暴露出使用習慣，而做出的優化行爲。
案例二（買電影票時，用戶口語習慣）
買電影票剛剛上線那段時間，發現大量用戶在填充電影名詞槽那裏卡住了。
《速度與激情8》剛剛上映，用戶會表述是我想看速度與激情、速激、速8等等；
《魔童哪吒》上映的時候，用戶的表述是，我想看哪吒的電影；
《葉問3》上映的時候，用戶的表述會是，葉問。甚至是甄子丹的那個電影；而AI先提取對應的影片名，然後交給接口方去完成查詢行爲，只有正確填充“指定電影的全稱”才能夠可查詢成功，所以此處就需要做映射關係的特殊處理。在定電影票例子中，十分考慮場景和時效性，也就是說，用戶在不同的時間點，說我要看《某》系列電影的時候，口語上大概率是絕對不會帶上第幾部的。
只要能暴露問題，就會有解決方案。
案例三（買電影票時，用戶的交互習慣）
我們在設計電影票技能的時候，內部曾經討論到，如果用戶需求明確，且一口氣完整滿足4個詞槽，是否應當直接給予結果？例如：我幫我買2張《魔童哪吒》的電影票，附近找個最近的電影院，晚上8點鐘左右開場的，隨便什麼座位都行。
爲了完成這個，我們花費了不少精力。從我們後臺的實際數據表現去看，實際上用戶並不會這麼說，很少有用戶做多個複合條件疊加查詢的，且從來沒有用戶會一口氣說出4個詞槽！可以明確一個結論，我們此前的的一部分工作被浪費掉了！
案例四（某一類業務用戶篩選習慣）
產品人員看自己負責的業務模塊，比如下圖。展示的是：某個單位時間內，多少用戶，使用了XX業務，中間更換了多少意圖，最終完成下單行爲。
比如定個酒店（這種非標準品確實很難搞），用戶會就自己在意的查詢條件，反覆進行篩選行爲，導致對話變得非常長。這個能暴露出用戶在意什麼，我們就可以基於用戶特別在意進行優化了。
長期使用對話log分析後臺，就能夠加深用戶使用的真實理解，我才能夠寫出《如何評測語音助手的智能程度（1）意圖理解》這類受各位內行認同的文章。
文末總結
其實很多的公司都在做數據分析，但是分析的範圍、顆粒度、效率都不一樣。
有了諸多業務後臺，數據分析才能夠得以開展。
有些後臺能直接呈現問題（看趨勢，看分佈，看漏斗），有些問題則需要跟剝洋蔥一樣，一層層的做抽樣、對比和驗證。
這中間最難的就是，雖然AI助手幫助用戶完成了任務，但是用戶完成任務的整個過程是黑盒的，你不知道用戶爽或者不爽，而針對用戶的對話log進行抽樣分析，就能夠快速找到用戶使用過程中的那些不爽點，使用習慣等等等等。
還是那句老話，只要問題能夠暴露出來，解決方案就是在有限條件下做業務權衡取捨。
出於公司業務隱私保護，本文不適合展示太多的實際業務圖表，希望各位理解。但是方法論都是共通的，我可以隨便換任何業務的任何案例，其實這一塊也不難，做互聯網的時候數據分析技能過關，切換到AI領域也是一樣的，技能可以應用於很多行業。
而做數據分析和做工具是兩件事，後者可能是諸多AI公司需要考量的事情。
歡迎各位同學與作者進行討論，一起精進專業。
關聯閱讀：
——DuerOS 相關——
https://dueros.baidu.com/dbp