導(dǎo)讀：你是否有過來自用戶见秽、業(yè)務(wù)和老板們的 badcase "靈魂拷問"：

我運營的首頁頻道入口不可用，怎么回事呢讨盒？

為什么推送的消息解取，點進去是空白頁面？

為何這個商品的排序是這樣的返顺？

這個前端改版為什么效果一般禀苦，這個頻道入口為什么排在前面？

這個商品是我們運營 BD 了很久的商品遂鹊，折扣非常低振乏，怎么排序就這么靠后呢？

這個賣家最近被投訴了這么多秉扑，商品評分這么低慧邮，為什么排在第一個位置？

這個商品怎么會展示給我看呢舟陆？太惡心了误澳，根本不是我喜歡的！

我的首頁推薦的為什么有情趣相關(guān)的商品秦躯？

我剛剛下了一單買了個寶寶推車忆谓，怎么還在給我推薦呢？我又不會買2輛宦赠。

昨天我買了個 iphone 11手機陪毡，怎么今天給我推送了關(guān)于 iphone 11 降價的消息？

首頁猜你喜歡推薦怎么都是同類型的勾扭，多樣性怎么這么差毡琉？用戶沒法逛起來的。

剛剛點擊了一個商品妙色，下拉刷新推薦為什么沒有變桅滋，方案不是實時的嗎？

剛買了桶食用油身辨，怎么這么多坑位給我展示食用油柏つ薄？體驗太差了；蜕骸（本條來自阿里朱仰慕老師的知識圖譜分享）

"知乎這個相關(guān)問題是什么鬼号俐？"（來自知乎）

----瞬間崩潰----

潘亂老師的文章中有一段敘述，描述了 Robin 經(jīng)常反饋 badcase 的情況：

李彥宏愛看互聯(lián)網(wǎng)新聞定庵，但手百的個性化算法滿足不了需求吏饿，策略部門天天就被李彥宏報各種 badcase踪危，比如去年底爆出的百度內(nèi) Feed 業(yè)務(wù)推薦溝通群的群聊截圖，李彥宏問一條"搜狗 IPO 路演 PPT 注釋"的新聞并未推送給自己猪落。....手百團隊的應(yīng)對是給李彥宏私人定制一條流贞远。手百的策略部門找到百度新聞的科技內(nèi)容運營，把手百 Feed 推優(yōu)平臺的互聯(lián)網(wǎng)分類做成了李彥宏專用的定制流笨忌，早6點到晚12點要有人時刻在推蓝仲。算法搞不定李彥宏的口味，就靠編輯們純?nèi)斯ぜ影嗉狱c官疲。當然李彥宏知道后廢止了這個行為袱结，但不知他是否知道他經(jīng)常搜索的花草樹木搜索結(jié)果頁也是優(yōu)化定制的。

我覺得 Robin 反饋問題應(yīng)該是真實的袁余，畢竟信息流是百度重要的業(yè)務(wù)線擎勘，但是后面的專門定制和人工運營可能稍微有點夸張了。但是這背后是互聯(lián)網(wǎng)激烈競爭下颖榜，老板對于產(chǎn)品的要求越來越高棚饵。

互聯(lián)網(wǎng)流量紅利見頂?shù)那闆r下， 誰能更好地精細化地滿足用戶需求掩完，誰就能在激烈競爭中勝出噪漾。而 badcase 確實是一個個的坑，用戶摔跤多了且蓬，以后就不來你這條路了欣硼，挽回往往需要高昂的成本；用戶開開心心使用一般不會反饋問題恶阴，一旦不開心就有可能投訴反饋诈胜。如果一個產(chǎn)品很久沒有投訴反饋了，那倒要關(guān)心下活躍度了冯事。如何快速地定位和識別哪些是坑 ( 有些不是坑焦匈，是看上去像坑 )，并且快速填平這些坑是重點昵仅。

本文主要從個人角度給出一些看法缓熟，如有不妥之處還望大家批評指正。

01

怎么看 badcase

1. 存在的必然性

世界上沒有完美的事摔笤，也沒有完美的人够滑，人設(shè)計的產(chǎn)品也不可能有絕對完美；很多產(chǎn)品吕世、算法模型都做不到完美彰触，badcase 總是存在的。人工運營或設(shè)計的產(chǎn)品命辖，肯定就沒有那么千人千面渴析，用一個或者幾個形態(tài)去滿足萬千用戶晚伙，肯定無法讓所有人滿意；就算是千人千面的產(chǎn)品 ( 比如淘寶已經(jīng)非常智能俭茧、個性化 )，還是存在著被用戶吐槽的各種問題漓帚，因為機器學(xué)習(xí)/算法母债，也始終是在預(yù)估一定的概率，模型最后得到的也是兼顧大部分的一個解尝抖，也不是覆蓋全部用戶的最優(yōu)解毡们；更何況是各類模型的訓(xùn)練基于的數(shù)據(jù)也是有偏的，存在一定的噪聲 ( 比如網(wǎng)站數(shù)據(jù)中存在刷單昧辽、爬蟲衙熔、惡意攻擊、用戶誤點等各類非正常數(shù)據(jù) )搅荞，那學(xué)習(xí)出來的模型更加有偏了红氯。

2. 分類

Badcase 背后是對于理想態(tài)的追求，從 badcase 中可以發(fā)現(xiàn)：系統(tǒng) Bug咕痛、邏輯漏洞痢甘、業(yè)務(wù)迭代方向。我們先對 badcase 問題進行一個分類 ( 你也可以有自己的分類 )茉贡，然后集中討論其中若干問題塞栅。

① 功能性問題：系統(tǒng) bug

服務(wù)器日志打滿了，造成服務(wù)阻塞

運營配置的鏈接過期了腔丧，用戶無法進入活動頁

② 體驗性問題：

推薦系統(tǒng)中推薦買過的商品放椰、推薦買過并且降價了的商品

搜索系統(tǒng)中搜了綠色襪子，但是紅色襪子排在了綠色襪子的前面

首頁猜你喜歡的推薦都是色情類內(nèi)容愉粤、各種標題黨內(nèi)容

個性化推薦結(jié)果中都是同類型的內(nèi)容或者商品砾医，沒有多樣性

③ 政治正確性問題：

各類政治反動類的內(nèi)容

④ 不明確問題：

為什么這個商品/內(nèi)容排在第一個

為什么頻道的排布是這樣的

為什么運營BD的高折扣商品流量不大

其次我們將上述四種問題進行優(yōu)先級排定，毫無疑問科汗，①和③類問題非常致命藻烤，需要馬上解決，這些問題往往決定了產(chǎn)品的生死头滔。對于①類核心鏈路上的功能類的 badcase怖亭，隨著這幾年互聯(lián)網(wǎng)的發(fā)展沉淀了一套測試和監(jiān)控體系，③類問題目前內(nèi)容類產(chǎn)品遇到的比較多坤检，解決方案是通過自然語言兴猩、圖像早歇、流量分發(fā)算法與人力審核結(jié)合的方式解決倾芝。

而②類問題和④類問題讨勤，我們需要結(jié)合數(shù)據(jù)來做判斷和優(yōu)先級排定；對于②和④類的需求晨另，構(gòu)建 "badcase 收集 -> case 分析與挖掘 -> 策略嘗試 -> 觀察線上核心指標與 badcase 重新評估" 的閉環(huán)潭千。

這里主要對②和④類問題進行展開，本文接下來主要會對一些偏不明確類需求來做更多的展開與介紹借尿。我們從 case 分析開始介紹刨晴，關(guān)于 case 的收集我們在最后略做介紹。

02

分析

單 case 分析能夠從若干個樣本點發(fā)現(xiàn)用戶體驗問題路翻，可以幫助算法工程師尋找迭代點狈癞，是產(chǎn)品經(jīng)理進行需求挖掘的手段，但需求的論證還是需要與覆蓋更全面的數(shù)據(jù)分析結(jié)合茂契，特別是 case 背后問題的覆蓋率 ( 比如 case 是偶發(fā)還是大面積的 ) 和一些系統(tǒng)性的問題 ( 全局流量分配問題蝶桶，商品/賣家成長性問題等 )，這些問題需要從全局維度進行一些數(shù)據(jù)匯總和挖掘掉冶，才能發(fā)現(xiàn)一些問題真竖。不要先說對錯，請先用數(shù)據(jù)分析度量一下郭蕉，資源有限疼邀，根據(jù)分析結(jié)論確定優(yōu)先級。無法衡量就無法優(yōu)化召锈，對于互聯(lián)網(wǎng)產(chǎn)品而言旁振，系統(tǒng)的更新迭代必然需要建立一套度量衡，來把控整個流程優(yōu)化的方向涨岁。

1.?線上問題分析的前提

通過埋點盡量多的收集數(shù)據(jù)拐袜，包括用戶行為數(shù)據(jù)、線上當前環(huán)境數(shù)據(jù)梢薪、產(chǎn)品展現(xiàn)邏輯數(shù)據(jù) ( 比如推薦召回蹬铺、排序、業(yè)務(wù)邏輯流程數(shù)據(jù) )秉撇；這些數(shù)據(jù)盡量全甜攀，盡量覆蓋用戶全生命周期；沒有埋點和數(shù)據(jù)回流為前提的線上迭代琐馆，都是耍流氓规阀。

2. 分析與挖掘

那怎么分析呢？我們來舉幾個例子瘦麸，包括線上和離線2種谁撼，離線主要涉及模型迭代中的一些問題 ( 機器學(xué)習(xí)模型的優(yōu)化可以從特征分析、樣本分析滋饲、模型分析出發(fā) )厉碟。

線上：

①?老板提了一個 case：

"剛剛猜你喜歡點擊了一個商品喊巍，下拉刷新推薦為什么沒有變，方案不是實時的嗎箍鼓？"

我們先來這個 badcase 發(fā)生時的真實情況崭参，查看 badcase 問題的日志發(fā)現(xiàn)，此次點擊進入商品詳情頁只停留了0.5秒就馬上退出款咖，進而在首頁下拉刷新了頁面阵翎，并快速再次劃到了猜你喜歡。

我們再來看幾個數(shù)據(jù)：下拉刷新用戶占比之剧、用戶各頁面停留時長、平均用戶偏好衰減情況：

首先我們看到有下拉刷新的用戶占比只在0.85%砍聊，其次用戶在商詳頁的停留時長集中在2-17秒之間背稼，并且結(jié)合用戶行為衰減情況，在短時間周期內(nèi)玻蝌，用戶行為聚集程度較高蟹肘。通過分析結(jié)合問題，第一個下拉刷新的問題俯树，此功能是一個極少用的功能帘腹，更多人是下滑加載新的頁面時才會再次請求推薦接口；第二個問題點擊商品后许饿，推薦過程中兼顧2秒內(nèi)完成實時日志回流并在下次翻頁請求時完成計算就可以做到一定程度上的符合阳欲，但是這個 case 中商品詳情頁停留時長過短，整個推薦日志流還未返回陋率。

當然在成本可接受的范圍內(nèi)球化，實時性的提升肯定可以帶來更多收益，只不過成本的上升與收益的增加是否能夠相對正向是需要考量的瓦糟。當然推薦策略的實時性還可以嫁接一定的分群策略筒愚，比如新用戶剛進入推薦資源位，基本沒有行為菩浙，快速的正負行為 ( 有點擊和曝光無點擊 ) 反饋收集可以幫助推薦更精準巢掺，并且產(chǎn)品每天有大量新用戶來訪，這時候可以看看是否有必要加快日志的回流劲蜻。

② 類目或者行業(yè)運營提出了一個 case：

"首頁猜你喜歡在鞋子類目分發(fā)到的流量占總流量的7%陆淀，而搜索卻有15%；搜索代表了主動意圖斋竞，更能夠代表全站用戶的意圖倔约，理應(yīng)猜你喜歡也是這樣的類目分布？"

因為問題是類目在商品粒度的曝光量問題坝初，我們可以先看幾個數(shù)據(jù)浸剩，2個場景曝光的商品在商品畫像維度有啥區(qū)別嗎钾军？對于有區(qū)分性的特征，展開進行二次分析绢要。

上圖的分值是通過曝光商品的曝光量與商品特征中的特征值加權(quán)平均后的值吏恭，描述曝光情況的。從上圖我們可以看到在評分和客單上搜索明顯低于猜你喜歡重罪，但是 CVR 上明顯高于猜你喜歡樱哼。

那我們逐個再做分析，評分我們拉取了推薦和搜索的數(shù)據(jù)剿配，發(fā)現(xiàn)原來推薦場景3分以下的商品沒有曝光搅幅；恍然大悟，之前推薦場景為了提升產(chǎn)品調(diào)性呼胚，對于低評分的商品不做展示茄唐，所以天然推薦場景就少了一波商品；在看價格那欄蝇更，搜索3分以下的價格明顯較低沪编，那也一定程度上說明了上面圖中搜索客單價低的一個點；最后我們再看看 CVR 猜你喜歡低的很多的原因年扩，其實我們分析各個類目都會發(fā)現(xiàn)搜索要高很多蚁廓，為什么呢？因為搜索場景天然是用戶主動意圖場景厨幻，而猜你喜歡場景意圖更弱相嵌，所以天然就是高的，所以 CVR 這個的差異是正常的克胳。

我們還可以對其它維度再進行拆解分析平绩，但是你已經(jīng)發(fā)現(xiàn)了評分帶來的問題，這時候漠另，可以在低評分是否展現(xiàn) ( 調(diào)性訴求 ) 上與類目流量上進行權(quán)衡捏雌，也可以通過 AB 實驗觀測相關(guān)指標。

上面問題延伸出來還有一個問題是笆搓，用戶冷啟動時性湿，冷啟動的商品列表如何分配類目流量，可以參考下圖满败，通過點擊肤频、訂單、gmv 貢獻率三者給予不同的權(quán)重算墨，來進行配比宵荒。

③ 我們再來看一個 case：

"首頁猜你喜歡怎么類目這么單一，用戶沒法逛起來，多樣的話用戶長期留存會好报咳。"

這里隱含了幾個問題：用戶可能喜歡看到多類目的猜你喜歡推薦列表侠讯，才會逛起來；用戶看到的類目多了暑刃，長期來說可以增加其粘性厢漩。這里我們可以通過撈取歷史的用戶日志，分析用戶的購物路徑下的商品瀏覽情況岩臣；其次我們可以通過歷史數(shù)據(jù)分析用戶瀏覽類目數(shù)多的情況下溜嗜，未來回訪和留存是否好。

首先我們將全站用戶進行區(qū)分和篩選架谎，畫出了全局用戶在類目維度隨著瀏覽時間的衰減曲線炸宵，說明在2.5分鐘后用戶行為類目集中在原有類目的概率下降非常快谷扣。但是不管時間多短怎么樣焙压，在二級類目平均的類目數(shù)都在2個以上的。我們再通過一些業(yè)務(wù)規(guī)則抑钟，區(qū)分用戶為強弱意圖用戶，分析這兩類用戶野哭，發(fā)現(xiàn)強意圖用戶在非常長的時間段內(nèi)都維持著較高的同類目瀏覽在塔，而弱意圖用戶則出現(xiàn)了隨著時間快速衰減的情況。這時候可以在推薦或者搜索模塊架設(shè)意圖預(yù)測子模塊拨黔，對于強弱意圖明顯的用戶進行不同類目的干預(yù)蛔溃，并且初期可以根據(jù)用戶分群選擇在每20個出 N 中選擇一定區(qū)間，配合負反饋/EE策略篱蝇，進行類目衰減來做類目坑位更替贺待，做到多樣性。

第二個問題零截，我們可以通過分析麸塞，發(fā)現(xiàn)如果過少的類目瀏覽確實長期來說回訪不足，當然這個可能只是相關(guān)涧衙，不是因果關(guān)系哪工，但是這個已經(jīng)可以說明在策略上是可以增加一定類目多樣性來保證回訪的。

稍微擴展一下弧哎，還可以分析消費折扣商品的用戶未來留存和回訪是否提升雁比。這里想說的是當你的排序模型無法優(yōu)化長期指標 ( LTV、回訪撤嫩、留存 ) 時偎捎，你可以考慮建立長期指標和短期指標的相關(guān)性，從而保證留存應(yīng)有的良好前提。做了 ( 保證曝光有類目多樣性 ) 不一定能提升長期留存茴她，但是不做 ( 推薦結(jié)果讓用戶沒機會看到更多的類目 ) 肯定會讓長期留存變低寻拂。短期實驗上線全量時，還可以考慮切小流量做反向 AB 實驗败京，來做最終的長期指標因果關(guān)系觀察兜喻。

離線：

排序模型迭代兩個模型架構(gòu)設(shè)計差異大，但是離線 AUC 接近赡麦，如何選取和優(yōu)化朴皆；或者深度學(xué)習(xí)模型排序結(jié)果有 badcase，如何找出其中不足的地方進行優(yōu)化泛粹？

比如你有 NN 類模型和 GBDT 2 類模型遂铡，離線指標差異小如何選取和融合呢？我們先看看數(shù)據(jù)晶姊，取出兩類模型測試樣本集的預(yù)測結(jié)果與真實結(jié)果扒接，分別對預(yù)測結(jié)果高度一致和非高度一致的取出分析 ( 分類模型可以取出錯分樣本或者分類正確樣本 )，通過樣本背后的特征做分析们衙，如下圖：

從上面的表格中钾怔，我們看到 GBDT 模型錯分的樣本相對 NN 模型在平均商品周曝光量上要高，用戶活躍度也相對較低蒙挑；我們通過平均商品周曝光量這個維度宗侦，進行切分，將全站周平均曝光量的25分位和75分位作為曝光量高低的切分點忆蚀，分別分析矾利，出現(xiàn)下面的表格，以及右邊的圖表馋袜；最終在結(jié)合同樣樣本集上男旗，兩個模型 AUC 接近，得出在現(xiàn)有的樣本欣鳖、特征下 NN 模型在長尾商品上表現(xiàn)更好察皇，GBDT 在頭部商品上表現(xiàn)更好；這樣可以嘗試在 NN 模型中加入一些先驗統(tǒng)計類特征泽台，或者在 GBDT 類模型中加入泛化類特征让网，或者可以做模型的融合。

這里還有幾個點需要注意师痕，就是 GBDT 模型也可以和 LR 類模型進行對比溃睹，模型迭代升級過程中也可以自己做對比，比如錯分與正確的樣本也可以做對比分析胰坟，或者高錯誤率的與低錯誤率的進行對比因篇。

基于分析結(jié)果泞辐，我們可以對需求有大致地一個判斷，到底是否非常用戶體驗的情況還是個例竞滓，還是非典型用戶的 YY咐吼，大致預(yù)估出迭代能夠帶來的影響。但數(shù)據(jù)不是總能描述全部的真實世界商佑，或者不是所有的事情都是可以用數(shù)據(jù)描述的锯茄，這時候往往還需要結(jié)合其它方法，比如用戶訪談和調(diào)研茶没，當然這里面需要設(shè)計可靠的人群選取和調(diào)研內(nèi)容設(shè)計肌幽，傾聽利益相關(guān)方的訴求，也可能可以從用戶口中了解到競對的優(yōu)缺點抓半，進行對比和迭代點挖掘喂急。

03

如何處理與干預(yù)

1. 基礎(chǔ)和快速版本

先策略規(guī)則、然后通過分析找出漏洞發(fā)生的點笛求，進而通過算法和模型的方式進行彌補和修復(fù)廊移。基礎(chǔ)探入、簡單快速類版本狡孔，往往希望在系統(tǒng)設(shè)計和方案選型的時候就要考慮到如何才能低成本、無其他副作用蜂嗽、快速準確地修復(fù) badcase步氏。

比如搜索引擎中通過有個搜索干預(yù)平臺，某個搜索詞搜不到結(jié)果或者結(jié)果不準徒爹，在搜索的 QP ( query process ) 階段嵌入一個規(guī)則邏輯，對用戶 Query 在配置的詞庫中的查找芋类，如果命中則直接將其映射為配置詞 ( 比如把搜索結(jié)果不準的非常見詞通過規(guī)則映射為同義的常見詞 )隆嗅，對前面各個模塊處理的結(jié)果能進行干預(yù)以快速響應(yīng) badcase 處理。

比如首頁猜你喜歡不允許有黃圖侯繁、或者色情類內(nèi)容出現(xiàn)胖喳，可以在類目 id、商品 id 維度進行干預(yù)贮竟，比如對召回模塊后丽焊，截斷和過濾模塊對命中黑名單類目 id 和商品 id 的商品進行過濾，或者通過敏感詞庫對召回候選內(nèi)容標題進行檢測是否包含咕别，避免較明顯的 badcase技健，從而優(yōu)化用戶體驗。

2. 復(fù)雜邏輯迭代

上述方式往往在問題可枚舉惰拱，或者可枚舉方案可以覆蓋80%-90%問題的時候被使用和長期維護雌贱，這類方案簡單、快速地解決線上問題。但長期來說欣孤，不會配置大量的邏輯在策略中馋没，可維護性差，可能解決了這個 badcase 又引入了另一個 badcase降传， 線上一堆修修補補的規(guī)則篷朵，未來問題的定位和調(diào)優(yōu)變成了比較困難的一件事。除了兜底策略以外婆排，需要時常對規(guī)則收口分析声旺，最終落地為通用的模塊。根據(jù)規(guī)則所覆蓋的邏輯進行抽象泽论，抽取出背后所代表的問題艾少，從 badcase 中學(xué)習(xí)總結(jié)規(guī)律持續(xù)尋找更優(yōu)雅的方式解決。

通過將問題背后的遺漏點融入原有體系翼悴，比如對模型依賴的樣本進行清洗和去噪缚够，構(gòu)建相關(guān)特征納入到模型中，將 badcase 背后欠考慮的目標融入原有目標鹦赎，或者通過業(yè)務(wù)干預(yù)層的方案設(shè)計收口等谍椅，前三種都是在模型效果維度進行干預(yù)：特征，樣本古话，模型雏吭。

① 搜索中場景的相關(guān)問題

搜索中常見的一些相關(guān)性問題，可以歸納為詞匯的同義陪踩、多義問題 ( 蘋果 )杖们，語言表達差異 ( 襪子男，男襪 )肩狂、輸入錯誤 ( 背帶庫 )摘完、泛語義/非常用詞召回 ( BTS->防彈少年團 )，無供給問題 ( 沒有匹配搜索詞的商品/內(nèi)容 )傻谁、誤召回問題 ( 相關(guān)性問題 )孝治、展示問題 ( 真正意圖商品排序靠后 ) 等。語義/非常用詞召回可以考慮引入領(lǐng)域詞庫审磁，訓(xùn)練的 NLP 模型 ( 比如 Embeding )谈飒，自動建立非常見詞與常見詞的關(guān)系，并在用戶搜索詞調(diào)用搜索擴展和歸一态蒂。

下面為搜索模塊圖杭措，相關(guān)可參見：萬字長文解讀電商搜索——如何讓你買得又快又好

② 流量分發(fā)中的內(nèi)容不合規(guī) ( 黃圖、色情文字 )

內(nèi)容不合規(guī)問題 ( 黃圖钾恢、色情文章 )瓤介，可以通過圖像和 NLP 模型進行識別吕喘，結(jié)合用戶的行為數(shù)據(jù)來做干預(yù)的方式來解決 ( 我們發(fā)現(xiàn)電商中色情類商品，往往點擊率高 ( 前25%分位 )刑桑，但是同樣的轉(zhuǎn)化率很低 ( 后25%分位 ))祖很，可以大大減小 badcase 的情況捏肢。

③ 多目標/多階段問題

比如建模過程中希望兼顧多目標時，算法模型不是離線 AUC 提升就可以上了，你的建模是有偏的 ( 比如 point wise 的建模 )降允，樣本無法描述用戶真實的情況蚓再。推薦場景中往往需要考慮點擊率站粟、轉(zhuǎn)化率浦妄、客單價、回訪吴超、留存等钉嘹。你需要做的事情是，模型的目標如果沒有涉及 badcase 背后的東西鲸阻，那模型只會考慮當前指標跋涣，帶來 badcase。當然第一步是需要給出指標的度量方式鸟悴，比如很多時候產(chǎn)品調(diào)性是一個常被提及的詞陈辱，那什么叫產(chǎn)品調(diào)性呢，如何度量是關(guān)鍵细诸，如果可以度量沛贪，被模型納入進行才能成為可能。

比如推薦中的多樣性問題震贵，只通過 point wise 的 CTR 預(yù)估利赋，很容易喪失多樣性。這時候你最后還有打散的功能猩系，這個功能無法被 AUC 指標所描述媚送；這時候可以考慮引入 listwise 的排序策略，或多樣性干預(yù)及建模 ( DPP 或 MRR ) 方式蝙眶。當然多樣性也可能不是最后模型的問題，而是推薦的前置模塊出現(xiàn)了問題 ( 如下圖 )褪那，導(dǎo)致如何修正目標和數(shù)據(jù)幽纷，都無法在排序階段拿到很好的多樣性。進行充分的埋點完成日志收集博敬，如果按類目和主題在排序漏斗上快速收縮友浸，則需要優(yōu)化前置邏輯 ( 比如召回 )，否則無法在精排層完成多樣性的提升偏窝。

當然這里需要設(shè)計一套合理的方案去嘗試評估前后依賴的模塊收恢。文章可以參見：

https://engineering.linkedin.com/blog/2019/06/community-focused-feed-optimization

04

總結(jié)

細節(jié)決定成敗武学，從 badcase 出發(fā)，充分分析過后可以帶來全新的世界伦意。

1. 分析例行化

先找到核心指標背后的若干可度量指標火窒，并建立起與短期可觀測指標的聯(lián)系 ( 因為往往每個產(chǎn)品的核心指標都是長期的 )。比如用戶回訪驮肉、單次 session 內(nèi)轉(zhuǎn)化率與長期留存和 LTV 相關(guān)的指標熏矿，單次 session 內(nèi)轉(zhuǎn)化率好評估，但是用戶未來的回訪怎么在每次用戶來訪時度量离钝？這個可以結(jié)合之前長短期指標關(guān)系出出發(fā)票编，通過分析相關(guān)性建立兩者的聯(lián)系，假設(shè)最終我們分析到用戶單次瀏覽的類目數(shù)和折扣商品數(shù)均會帶來用戶回訪的提升卵渴，那我們就可以從這兩個指標出發(fā)構(gòu)建一個自動報表提升慧域。

① Badcase 提取器

通過 badcase 尋找優(yōu)化迭代點，不失為一種好的方法浪读，那如何收集和挖掘呢昔榴？如何找典型樣本點？

比如通過每天或者每周自動化統(tǒng)計各個場景高流低轉(zhuǎn)的商品 ( 曝光量屬于類目25分位瑟啃，轉(zhuǎn)化率屬于類目75分位的商品 )论泛，通過商品A的id查找當日的行為日志，隨機挑選若干用戶作為 case蛹屿；將這些用戶在場景內(nèi)推薦屁奏、搜索、分發(fā)置頂策略的執(zhí)行過程日志撈取错负，并做分析坟瓢，分析為什么這些商品能夠被召回和排序出來，可能是召回問題犹撒，可能是特征問題折联，可能是模型問題；找到一定規(guī)律后就可以針對性的優(yōu)化了识颊。

上述問題還可以通過 badcase 找到對應(yīng)的人群诚镰，分析人群的效果。比如對上述商品A的所有曝光祥款，我們拉取后根據(jù)用戶維度進行聚合清笨，發(fā)現(xiàn)都是這個商品相對于全局，被分發(fā)到了非常高比例的新用戶刃跛，那可以看看推薦邏輯中是否有跟新用戶相關(guān)的邏輯抠艾，有可能是你的冷啟動列表問題；你也可能發(fā)現(xiàn)這個商品的近期轉(zhuǎn)化數(shù)據(jù)異常高 ( 背后可能是商家的刷單 )桨昙，導(dǎo)致流量在某個時間節(jié)點突然變多检号，那你就找到了如何對作弊商家和商品的處理方向腌歉；也可能是發(fā)現(xiàn)這些商品同屬于一個類目 ( 情趣用品 )，這類商品往往點擊率高齐苛，轉(zhuǎn)化低翘盖。

分群還可以發(fā)現(xiàn)新上策略的問題，比如 B 策略在 ABtest 中表現(xiàn)較好脸狸，很快就全量上線了最仑，但是通過高流低轉(zhuǎn) badcase，發(fā)現(xiàn)原來 B 策略在人群1 ( 老用戶 ) 上效果翻倍炊甲，人群2 ( 新用戶 ) 上效果減半泥彤，但是最終效果只提升了25%；這時候你可能在人群2上沿用老策略卿啡，人群1上使用B策略吟吝，效果就又有了一個很高的提升。

搜索中則可以分析熱搜詞中低點擊率的 Query颈娜，同樣可以分類目來看剑逃。可能可以找到問題官辽，是在這個 Query 下蛹磺，QP 邏輯處理不好，導(dǎo)致召回商品不相關(guān)同仆，可以優(yōu)化 QP 問題萤捆；或者這個 Query 下根本沒有相關(guān)的商品，比如用戶搜了 BTS ( 防彈少年團 )俗批，你根本沒有相關(guān)的周邊產(chǎn)品俗或，可以做類目和商品擴展。還可以在搜索詞維度區(qū)分并分析岁忘，比如下圖中的一些維度辛慰。

上述溯源過程中，需要強調(diào)的是分析過程不要僅僅只關(guān)注全局均值干像，需要做細粒度拆分 ( 比如分類目 )帅腌，考慮分位數(shù)、眾數(shù)麻汰，甚至考慮觀察方差情況速客，并且進行對比分析。

2. 迭代閉環(huán)

業(yè)務(wù)方什乙、算法挽封、產(chǎn)品已球、老板反饋臣镣，收集 badcase 信息辅愿；通過數(shù)據(jù)分析，將分析結(jié)論通過規(guī)則或模塊快速應(yīng)用忆某，并結(jié)合 ABtest 進行觀測点待；定期梳理規(guī)則、干預(yù)模塊弃舒，通過樣本癞埠、特征、模型融合聋呢，并結(jié)合 ABtest 進行觀測苗踪；分析跟蹤發(fā)現(xiàn)新一輪的問題。

3. 架構(gòu)

① 推薦削锰、搜索預(yù)覽平臺

除了離線指標的評估通铲，往往算法工程師上線前，可以通過隨機挑選一些用戶請求即將上線 AB 的策略器贩，通過用戶畫像及歷史行為來主觀觀測和評估效果颅夺，相當于抽樣統(tǒng)計來反映整體情況的分析方法。先從用戶表中隨機抽取用戶蛹稍，通過用戶 id 查詢用戶最近的行為 ( 包括搜索吧黄、點擊、加購唆姐、收藏拗慨、購買等行為 )，再請求待評估場景策略厦酬，最終使用用戶行為與策略結(jié)果進行比對胆描，主觀判斷是否有不妥和直觀 bug 存在。比如下面的猜你喜歡推薦和商品詳情頁推薦：

② 系統(tǒng)拆解與日志上報

除了日常前后端系統(tǒng)的日志上報以外仗阅，推薦各模塊邏輯也需要盡量埋點記錄過程 ( 包括規(guī)則邏輯昌讲，記錄每個規(guī)則被觸發(fā)的條件和使用的頻率 ) 這個被使用的定義是：被命中，且結(jié)果和 ML 模型結(jié)果不同减噪。規(guī)則從增加到過期下線的整個生存期都應(yīng)該被仔細管理短绸。

快速定位問題的能力，抗風(fēng)險能力筹裕。一條明顯的推薦的 badcase 是否能夠很快找出錯誤的原因醋闭？是召回 i2i、c2i 等等 x2i 數(shù)據(jù)沒有 dump朝卒，還是特征數(shù)據(jù)有問題证逻，還是排序模型更新的問題？這里關(guān)乎監(jiān)控和報警抗斤，能否從監(jiān)控和日志中快速定位原因囚企？前端丈咐、后端、算法引擎龙宏、推薦策略 ( 召回棵逊、過濾、粗排银酗、精排辆影、業(yè)務(wù)邏輯等模塊 ) 各個模塊，如何協(xié)作才能使團隊合作的成本最低而整體利益最大化黍特？

總之蛙讥，通過監(jiān)控做到早于老板發(fā)現(xiàn)問題，通過清洗的架構(gòu)快速修復(fù)問題灭衷。

4. Badcase 可以幫助你加深業(yè)務(wù)理解

Badcase 可以幫助理解用戶键菱，通過親自體驗、badcase 收集今布、分析挖掘经备、實驗迭代反饋驗證等環(huán)節(jié)，構(gòu)建用戶模型部默；把產(chǎn)品用得比任何人都熟侵蒙，典型用戶能夠熟練地說出重點標簽，負責(zé)場景核心數(shù)據(jù)非常了解傅蹂，并能注意到和總結(jié)出優(yōu)秀競品的細節(jié)差異纷闺、和規(guī)律性內(nèi)容，再對場景進行迭代的時候就更加順手了份蝴。至于其它常規(guī)工具和技能的學(xué)習(xí)犁功，那不是問題。

算法工程師需要多看數(shù)據(jù)婚夫、多做分析浸卦，養(yǎng)成 badcase review 的好習(xí)慣；判斷一個事情是否應(yīng)該投入案糙，投入多少資源去做限嫌，在什么時候做，最終收益如何时捌。

數(shù)據(jù)無法度量所有怒医，由于原有機制的邏輯，非全面覆蓋用戶情況奢讨，所以存在實驗的必要性稚叹。需要上線 A/B Testing 驗證優(yōu)化效果，根據(jù)指標評估項目收益，效果正向則擴量扒袖，負向則分析調(diào)整或下線蛤奥，并繼續(xù)迭代優(yōu)化。

很多算法工程師執(zhí)著于算法模型迭代僚稿，沒有抽離出來，對業(yè)務(wù)及迭代優(yōu)先級排定蟀伸，反而會事倍功半蚀同。

今天的分享就到這里，謝謝大家啊掏。

下一期話題《如何平衡全局收益和單場景收益》

因為用戶需求固定蠢络，往往單場景會搶流量，造成1+1<2的情況迟蜜，比如電商推薦中刹孔，往往各個場景實驗迭代獨立，比如首頁猜你喜歡分了aab三組實驗（分別1/3的流量）娜睛，b組的推薦策略實驗效果明顯好于另外2組aa實驗髓霞，然后你上線了，但是你去分析全局的實驗結(jié)果畦戒，你發(fā)現(xiàn)其它場景（搜索方库、類目導(dǎo)航、商詳障斋、頻道等）b組對應(yīng)的人群反而低于了aa組纵潦，什么原因呢？通過分析垃环，我們發(fā)現(xiàn)當b組推薦策略相對于aa組較優(yōu)時邀层，用戶很快會在首頁b策略成交，所以指標提升了遂庄；但其實a組部分用戶雖然沒在首頁成交寥院，但是他們通過搜索或者類目或者商詳相似推薦等場景最終也完成了成交。所以實際全局增益小于局部增益涛目，并且在上述單場景AB中只磷，往往各場景都會上線效果明顯但同質(zhì)化的策略，導(dǎo)致全局推薦結(jié)果接近泌绣，比如開頭手淘食用油的情況出現(xiàn)钮追。

如何去兼顧全局增益呢？欲知詳情阿迈，請看下回分解元媚。

知識星球

我開通了知識星球，我還給你們準備了一張優(yōu)惠券（在文章最后，掃碼進去就有「10元優(yōu)惠券」）刊棕。

1.星球主要會分享一些推薦炭晒、搜索、風(fēng)控等領(lǐng)域的一些算法甥角、產(chǎn)品网严、技術(shù)相關(guān)的資料，其次也會有一些好的內(nèi)容分享嗤无，好的文章震束、好的書等。

2.在星球內(nèi)你也可以向我提問当犯，后期會有幾個嘉賓加入垢村，暫定為推薦算法&工程、圖像嚎卫、NLP嘉栓、供應(yīng)鏈等領(lǐng)域的專家，后期看大家的需求可能也會有產(chǎn)品和業(yè)務(wù)的嘉賓加入拓诸。

3.目前主題為推薦系統(tǒng)的細節(jié)(快速得分項)侵佃、搜索引擎的細節(jié)、用戶畫像奠支、業(yè)務(wù)sense趣钱、生態(tài)系統(tǒng)、優(yōu)質(zhì)資料胚宦、好習(xí)慣首有、好內(nèi)容、日常思考等枢劝。