導讀：你是否有過來自用戶、業務和老板們的 badcase "靈魂拷問"：

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

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

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

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

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

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

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

我的首頁推薦的為什么有情趣相關的商品？

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

昨天我買了個 iphone 11手機，怎么今天給我推送了關于 iphone 11 降價的消息？

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

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

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

"知乎這個相關問題是什么鬼？"（來自知乎）

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

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

李彥宏愛看互聯網新聞，但手百的個性化算法滿足不了需求，策略部門天天就被李彥宏報各種 badcase，比如去年底爆出的百度內 Feed 業務推薦溝通群的群聊截圖，李彥宏問一條"搜狗 IPO 路演 PPT 注釋"的新聞并未推送給自己。....手百團隊的應對是給李彥宏私人定制一條流。手百的策略部門找到百度新聞的科技內容運營，把手百 Feed 推優平臺的互聯網分類做成了李彥宏專用的定制流，早6點到晚12點要有人時刻在推。算法搞不定李彥宏的口味，就靠編輯們純人工加班加點。當然李彥宏知道后廢止了這個行為，但不知他是否知道他經常搜索的花草樹木搜索結果頁也是優化定制的。

我覺得 Robin 反饋問題應該是真實的，畢竟信息流是百度重要的業務線，但是后面的專門定制和人工運營可能稍微有點夸張了。但是這背后是互聯網激烈競爭下，老板對于產品的要求越來越高。

互聯網流量紅利見頂的情況下， 誰能更好地精細化地滿足用戶需求，誰就能在激烈競爭中勝出。而 badcase 確實是一個個的坑，用戶摔跤多了，以后就不來你這條路了，挽回往往需要高昂的成本；用戶開開心心使用一般不會反饋問題，一旦不開心就有可能投訴反饋。如果一個產品很久沒有投訴反饋了，那倒要關心下活躍度了。如何快速地定位和識別哪些是坑 ( 有些不是坑，是看上去像坑 )，并且快速填平這些坑是重點。

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

01

怎么看 badcase

1. 存在的必然性

世界上沒有完美的事，也沒有完美的人，人設計的產品也不可能有絕對完美；很多產品、算法模型都做不到完美，badcase 總是存在的。人工運營或設計的產品，肯定就沒有那么千人千面，用一個或者幾個形態去滿足萬千用戶，肯定無法讓所有人滿意；就算是千人千面的產品 ( 比如淘寶已經非常智能、個性化 )，還是存在著被用戶吐槽的各種問題，因為機器學習/算法，也始終是在預估一定的概率，模型最后得到的也是兼顧大部分的一個解，也不是覆蓋全部用戶的最優解；更何況是各類模型的訓練基于的數據也是有偏的，存在一定的噪聲 ( 比如網站數據中存在刷單、爬蟲、惡意攻擊、用戶誤點等各類非正常數據 )，那學習出來的模型更加有偏了。

2. 分類

Badcase 背后是對于理想態的追求，從 badcase 中可以發現：系統 Bug、邏輯漏洞、業務迭代方向。我們先對 badcase 問題進行一個分類 ( 你也可以有自己的分類 )，然后集中討論其中若干問題。

① 功能性問題：系統 bug

服務器日志打滿了，造成服務阻塞

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

② 體驗性問題：

推薦系統中推薦買過的商品、推薦買過并且降價了的商品

搜索系統中搜了綠色襪子，但是紅色襪子排在了綠色襪子的前面

首頁猜你喜歡的推薦都是色情類內容、各種標題黨內容

個性化推薦結果中都是同類型的內容或者商品，沒有多樣性

③ 政治正確性問題：

各類政治反動類的內容

④ 不明確問題：

為什么這個商品/內容排在第一個

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

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

其次我們將上述四種問題進行優先級排定，毫無疑問，①和③類問題非常致命，需要馬上解決，這些問題往往決定了產品的生死。對于①類核心鏈路上的功能類的 badcase，隨著這幾年互聯網的發展沉淀了一套測試和監控體系，③類問題目前內容類產品遇到的比較多，解決方案是通過自然語言、圖像、流量分發算法與人力審核結合的方式解決。

而②類問題和④類問題，我們需要結合數據來做判斷和優先級排定；對于②和④類的需求，構建 "badcase 收集 -> case 分析與挖掘 -> 策略嘗試 -> 觀察線上核心指標與 badcase 重新評估" 的閉環。

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

02

分析

單 case 分析能夠從若干個樣本點發現用戶體驗問題，可以幫助算法工程師尋找迭代點，是產品經理進行需求挖掘的手段，但需求的論證還是需要與覆蓋更全面的數據分析結合，特別是 case 背后問題的覆蓋率 ( 比如 case 是偶發還是大面積的 ) 和一些系統性的問題 ( 全局流量分配問題，商品/賣家成長性問題等 )，這些問題需要從全局維度進行一些數據匯總和挖掘，才能發現一些問題。不要先說對錯，請先用數據分析度量一下，資源有限，根據分析結論確定優先級。無法衡量就無法優化，對于互聯網產品而言，系統的更新迭代必然需要建立一套度量衡，來把控整個流程優化的方向。

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

通過埋點盡量多的收集數據，包括用戶行為數據、線上當前環境數據、產品展現邏輯數據 ( 比如推薦召回、排序、業務邏輯流程數據 )；這些數據盡量全，盡量覆蓋用戶全生命周期；沒有埋點和數據回流為前提的線上迭代，都是耍流氓。

2. 分析與挖掘

那怎么分析呢？我們來舉幾個例子，包括線上和離線2種，離線主要涉及模型迭代中的一些問題 ( 機器學習模型的優化可以從特征分析、樣本分析、模型分析出發 )。

線上：

①?老板提了一個 case：

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

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

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

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

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

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

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

因為問題是類目在商品粒度的曝光量問題，我們可以先看幾個數據，2個場景曝光的商品在商品畫像維度有啥區別嗎？對于有區分性的特征，展開進行二次分析。

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

那我們逐個再做分析，評分我們拉取了推薦和搜索的數據，發現原來推薦場景3分以下的商品沒有曝光；恍然大悟，之前推薦場景為了提升產品調性，對于低評分的商品不做展示，所以天然推薦場景就少了一波商品；在看價格那欄，搜索3分以下的價格明顯較低，那也一定程度上說明了上面圖中搜索客單價低的一個點；最后我們再看看 CVR 猜你喜歡低的很多的原因，其實我們分析各個類目都會發現搜索要高很多，為什么呢？因為搜索場景天然是用戶主動意圖場景，而猜你喜歡場景意圖更弱，所以天然就是高的，所以 CVR 這個的差異是正常的。

我們還可以對其它維度再進行拆解分析，但是你已經發現了評分帶來的問題，這時候，可以在低評分是否展現 ( 調性訴求 ) 上與類目流量上進行權衡，也可以通過 AB 實驗觀測相關指標。

上面問題延伸出來還有一個問題是，用戶冷啟動時，冷啟動的商品列表如何分配類目流量，可以參考下圖，通過點擊、訂單、gmv 貢獻率三者給予不同的權重，來進行配比。

③ 我們再來看一個 case：

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

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

首先我們將全站用戶進行區分和篩選，畫出了全局用戶在類目維度隨著瀏覽時間的衰減曲線，說明在2.5分鐘后用戶行為類目集中在原有類目的概率下降非常快。但是不管時間多短怎么樣，在二級類目平均的類目數都在2個以上的。我們再通過一些業務規則，區分用戶為強弱意圖用戶，分析這兩類用戶，發現強意圖用戶在非常長的時間段內都維持著較高的同類目瀏覽，而弱意圖用戶則出現了隨著時間快速衰減的情況。這時候可以在推薦或者搜索模塊架設意圖預測子模塊，對于強弱意圖明顯的用戶進行不同類目的干預，并且初期可以根據用戶分群選擇在每20個出 N 中選擇一定區間，配合負反饋/EE策略，進行類目衰減來做類目坑位更替，做到多樣性。

第二個問題，我們可以通過分析，發現如果過少的類目瀏覽確實長期來說回訪不足，當然這個可能只是相關，不是因果關系，但是這個已經可以說明在策略上是可以增加一定類目多樣性來保證回訪的。

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

離線：

排序模型迭代兩個模型架構設計差異大，但是離線 AUC 接近，如何選取和優化；或者深度學習模型排序結果有 badcase，如何找出其中不足的地方進行優化？

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

從上面的表格中，我們看到 GBDT 模型錯分的樣本相對 NN 模型在平均商品周曝光量上要高，用戶活躍度也相對較低；我們通過平均商品周曝光量這個維度，進行切分，將全站周平均曝光量的25分位和75分位作為曝光量高低的切分點，分別分析，出現下面的表格，以及右邊的圖表；最終在結合同樣樣本集上，兩個模型 AUC 接近，得出在現有的樣本、特征下 NN 模型在長尾商品上表現更好，GBDT 在頭部商品上表現更好；這樣可以嘗試在 NN 模型中加入一些先驗統計類特征，或者在 GBDT 類模型中加入泛化類特征，或者可以做模型的融合。

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

基于分析結果，我們可以對需求有大致地一個判斷，到底是否非常用戶體驗的情況還是個例，還是非典型用戶的 YY，大致預估出迭代能夠帶來的影響。但數據不是總能描述全部的真實世界，或者不是所有的事情都是可以用數據描述的，這時候往往還需要結合其它方法，比如用戶訪談和調研，當然這里面需要設計可靠的人群選取和調研內容設計，傾聽利益相關方的訴求，也可能可以從用戶口中了解到競對的優缺點，進行對比和迭代點挖掘。

03

如何處理與干預

1. 基礎和快速版本

先策略規則、然后通過分析找出漏洞發生的點，進而通過算法和模型的方式進行彌補和修復?；A、簡單快速類版本，往往希望在系統設計和方案選型的時候就要考慮到如何才能低成本、無其他副作用、快速準確地修復 badcase。

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

比如首頁猜你喜歡不允許有黃圖、或者色情類內容出現，可以在類目 id、商品 id 維度進行干預，比如對召回模塊后，截斷和過濾模塊對命中黑名單類目 id 和商品 id 的商品進行過濾，或者通過敏感詞庫對召回候選內容標題進行檢測是否包含，避免較明顯的 badcase，從而優化用戶體驗。

2. 復雜邏輯迭代

上述方式往往在問題可枚舉，或者可枚舉方案可以覆蓋80%-90%問題的時候被使用和長期維護，這類方案簡單、快速地解決線上問題。但長期來說，不會配置大量的邏輯在策略中，可維護性差，可能解決了這個 badcase 又引入了另一個 badcase， 線上一堆修修補補的規則，未來問題的定位和調優變成了比較困難的一件事。除了兜底策略以外，需要時常對規則收口分析，最終落地為通用的模塊。根據規則所覆蓋的邏輯進行抽象，抽取出背后所代表的問題，從 badcase 中學習總結規律持續尋找更優雅的方式解決。

通過將問題背后的遺漏點融入原有體系，比如對模型依賴的樣本進行清洗和去噪，構建相關特征納入到模型中，將 badcase 背后欠考慮的目標融入原有目標，或者通過業務干預層的方案設計收口等，前三種都是在模型效果維度進行干預：特征，樣本，模型。

① 搜索中場景的相關問題

搜索中常見的一些相關性問題，可以歸納為詞匯的同義、多義問題 ( 蘋果 )，語言表達差異 ( 襪子男，男襪 )、輸入錯誤 ( 背帶庫 )、泛語義/非常用詞召回 ( BTS->防彈少年團 )，無供給問題 ( 沒有匹配搜索詞的商品/內容 )、誤召回問題 ( 相關性問題 )、展示問題 ( 真正意圖商品排序靠后 ) 等。語義/非常用詞召回可以考慮引入領域詞庫，訓練的 NLP 模型 ( 比如 Embeding )，自動建立非常見詞與常見詞的關系，并在用戶搜索詞調用搜索擴展和歸一。

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

② 流量分發中的內容不合規 ( 黃圖、色情文字 )

內容不合規問題 ( 黃圖、色情文章 )，可以通過圖像和 NLP 模型進行識別，結合用戶的行為數據來做干預的方式來解決 ( 我們發現電商中色情類商品，往往點擊率高 ( 前25%分位 )，但是同樣的轉化率很低 ( 后25%分位 ))，可以大大減小 badcase 的情況。

③ 多目標/多階段問題

比如建模過程中希望兼顧多目標時，算法模型不是離線 AUC 提升就可以上了，你的建模是有偏的 ( 比如 point wise 的建模 )，樣本無法描述用戶真實的情況。推薦場景中往往需要考慮點擊率、轉化率、客單價、回訪、留存等。你需要做的事情是，模型的目標如果沒有涉及 badcase 背后的東西，那模型只會考慮當前指標，帶來 badcase。當然第一步是需要給出指標的度量方式，比如很多時候產品調性是一個常被提及的詞，那什么叫產品調性呢，如何度量是關鍵，如果可以度量，被模型納入進行才能成為可能。

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

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

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

04

總結

細節決定成敗，從 badcase 出發，充分分析過后可以帶來全新的世界。

1. 分析例行化

先找到核心指標背后的若干可度量指標，并建立起與短期可觀測指標的聯系 ( 因為往往每個產品的核心指標都是長期的 )。比如用戶回訪、單次 session 內轉化率與長期留存和 LTV 相關的指標，單次 session 內轉化率好評估，但是用戶未來的回訪怎么在每次用戶來訪時度量？這個可以結合之前長短期指標關系出出發，通過分析相關性建立兩者的聯系，假設最終我們分析到用戶單次瀏覽的類目數和折扣商品數均會帶來用戶回訪的提升，那我們就可以從這兩個指標出發構建一個自動報表提升。

① Badcase 提取器

通過 badcase 尋找優化迭代點，不失為一種好的方法，那如何收集和挖掘呢？如何找典型樣本點？

比如通過每天或者每周自動化統計各個場景高流低轉的商品 ( 曝光量屬于類目25分位，轉化率屬于類目75分位的商品 )，通過商品A的id查找當日的行為日志，隨機挑選若干用戶作為 case；將這些用戶在場景內推薦、搜索、分發置頂策略的執行過程日志撈取，并做分析，分析為什么這些商品能夠被召回和排序出來，可能是召回問題，可能是特征問題，可能是模型問題；找到一定規律后就可以針對性的優化了。

上述問題還可以通過 badcase 找到對應的人群，分析人群的效果。比如對上述商品A的所有曝光，我們拉取后根據用戶維度進行聚合，發現都是這個商品相對于全局，被分發到了非常高比例的新用戶，那可以看看推薦邏輯中是否有跟新用戶相關的邏輯，有可能是你的冷啟動列表問題；你也可能發現這個商品的近期轉化數據異常高 ( 背后可能是商家的刷單 )，導致流量在某個時間節點突然變多，那你就找到了如何對作弊商家和商品的處理方向；也可能是發現這些商品同屬于一個類目 ( 情趣用品 )，這類商品往往點擊率高，轉化低。

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

搜索中則可以分析熱搜詞中低點擊率的 Query，同樣可以分類目來看?？赡芸梢哉业絾栴}，是在這個 Query 下，QP 邏輯處理不好，導致召回商品不相關，可以優化 QP 問題；或者這個 Query 下根本沒有相關的商品，比如用戶搜了 BTS ( 防彈少年團 )，你根本沒有相關的周邊產品，可以做類目和商品擴展。還可以在搜索詞維度區分并分析，比如下圖中的一些維度。

上述溯源過程中，需要強調的是分析過程不要僅僅只關注全局均值，需要做細粒度拆分 ( 比如分類目 )，考慮分位數、眾數，甚至考慮觀察方差情況，并且進行對比分析。

2. 迭代閉環

業務方、算法、產品、老板反饋，收集 badcase 信息；通過數據分析，將分析結論通過規則或模塊快速應用，并結合 ABtest 進行觀測；定期梳理規則、干預模塊，通過樣本、特征、模型融合，并結合 ABtest 進行觀測；分析跟蹤發現新一輪的問題。

3. 架構

① 推薦、搜索預覽平臺

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

② 系統拆解與日志上報

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

快速定位問題的能力，抗風險能力。一條明顯的推薦的 badcase 是否能夠很快找出錯誤的原因？是召回 i2i、c2i 等等 x2i 數據沒有 dump，還是特征數據有問題，還是排序模型更新的問題？這里關乎監控和報警，能否從監控和日志中快速定位原因？前端、后端、算法引擎、推薦策略 ( 召回、過濾、粗排、精排、業務邏輯等模塊 ) 各個模塊，如何協作才能使團隊合作的成本最低而整體利益最大化？

總之，通過監控做到早于老板發現問題，通過清洗的架構快速修復問題。

4. Badcase 可以幫助你加深業務理解

Badcase 可以幫助理解用戶，通過親自體驗、badcase 收集、分析挖掘、實驗迭代反饋驗證等環節，構建用戶模型；把產品用得比任何人都熟，典型用戶能夠熟練地說出重點標簽，負責場景核心數據非常了解，并能注意到和總結出優秀競品的細節差異、和規律性內容，再對場景進行迭代的時候就更加順手了。至于其它常規工具和技能的學習，那不是問題。

算法工程師需要多看數據、多做分析，養成 badcase review 的好習慣；判斷一個事情是否應該投入，投入多少資源去做，在什么時候做，最終收益如何。

數據無法度量所有，由于原有機制的邏輯，非全面覆蓋用戶情況，所以存在實驗的必要性。需要上線 A/B Testing 驗證優化效果，根據指標評估項目收益，效果正向則擴量，負向則分析調整或下線，并繼續迭代優化。

很多算法工程師執著于算法模型迭代，沒有抽離出來，對業務及迭代優先級排定，反而會事倍功半。

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

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

因為用戶需求固定，往往單場景會搶流量，造成1+1<2的情況，比如電商推薦中，往往各個場景實驗迭代獨立，比如首頁猜你喜歡分了aab三組實驗（分別1/3的流量），b組的推薦策略實驗效果明顯好于另外2組aa實驗，然后你上線了，但是你去分析全局的實驗結果，你發現其它場景（搜索、類目導航、商詳、頻道等）b組對應的人群反而低于了aa組，什么原因呢？通過分析，我們發現當b組推薦策略相對于aa組較優時，用戶很快會在首頁b策略成交，所以指標提升了；但其實a組部分用戶雖然沒在首頁成交，但是他們通過搜索或者類目或者商詳相似推薦等場景最終也完成了成交。所以實際全局增益小于局部增益，并且在上述單場景AB中，往往各場景都會上線效果明顯但同質化的策略，導致全局推薦結果接近，比如開頭手淘食用油的情況出現。

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

知識星球

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

1.星球主要會分享一些推薦、搜索、風控等領域的一些算法、產品、技術相關的資料，其次也會有一些好的內容分享，好的文章、好的書等。

2.在星球內你也可以向我提問，后期會有幾個嘉賓加入，暫定為推薦算法&工程、圖像、NLP、供應鏈等領域的專家，后期看大家的需求可能也會有產品和業務的嘉賓加入。

3.目前主題為推薦系統的細節(快速得分項)、搜索引擎的細節、用戶畫像、業務sense、生態系統、優質資料、好習慣、好內容、日常思考等。