面向NLP的AI產品方法論——如何通過數據分析迭代優化
本系列文字是一位創業者的投稿《面向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公司需要考量的事情。
歡迎各位同學與作者進行討論，一起精進專業。
【本文來自51CTO專欄作者“老曹”的原創文章，作者微信公眾號：喔家ArchiSelf,id:wrieless-com】
