不懂資料分析的演算法工程師，會有多慘

“我們的演算法工程師水平太差了，完全解決不了問題！”作為一個經常和傳統企業打交道的乙方，這種抱怨我聽得太多了，類似慘痛畫面也見得太多了。今天我們系統說說。

模型厲害不厲害，厲害！你看阿爾法大狗子都把天才少年柯潔咬哭了，能不厲害嗎。

於是，很多企業咬牙跺腳，出高薪，聘請來自網際網路大廠的演算法工程師、資料探勘工程師、資料建模師，期望他能做出超厲害模型；“只要你能預測精準了，那我肯定能如魚得水”是他們的口頭禪。

又剛好，一批2017年左右混入所謂網際網路大廠的演算法工程師們，被裁員了，以為自己可以打著“前頭騰阿高階演算法工程師”旗號收割一波傳統企業，從此烏雞變鳳凰，走上人生巔峰。

兩者一拍即合。悲劇就從這裡開始……

一、不考慮業務，背鍋死

陣亡案例1：某傳統企業，想建立產品推薦模型，精準匹配使用者需求；結果才半年，招來的演算法就被炒了——炒人理由：推薦不精準，反而干擾了正常銷售。

甲方市場部的頭頭還不屑的說：阿里的推薦演算法也不咋樣啊。

仔細研究業務場景就發現：親，不是阿里有問題，是你這公司不是阿里呀！阿里是平臺方，在平臺上有無數商品等著推。

但具體到你這個企業，就會發現：

• 有的產品是安身立命的爆款，不推也好賣。
• 有的產品是業務的心頭肉，只要出一點問題，那就是千刀萬剮。
• 有的產品先天短腿，功能不行、定價不合理，根本幹不過競品，推薦演算法有毛用。
• 有些產品品質還行，只是在內部政治地位不高，拿不到資源，或者定價不合理，導致後天短腿。

上一任演算法小哥哥，不考慮這些業務上明爭暗鬥，就直接上模型了；所有產品一鍋燉了做推薦（還是用協同過濾，完全沒考慮企業的使用者粘性，使用者行為資料量問題）；結果，主打產品出現下滑情況，銷售部、市場部聯手，一起把鍋往他身上甩。

結局，不但被趕滾蛋，而且搞得聲名狼藉。

認真分析了這些背景以後，一個最佳化方案出爐（如下圖）：

先做好產品分析，選好後天短腿的小品類，找到背書的部門，這時候可以開幹了；果然，第一波推廣馬上見效；於是甲方開開心心接手，自己回去最佳化迭代去了。

二、不細化場景，麻煩死

陣亡案例2：某連鎖店，希望能建立模型，精準預測每個店鋪的魚蛋、腸粉、飯糰、麵包……具體到每一個SKU的銷量，這樣門店既不會因為積壓浪費食材，又不會因為缺貨錯過銷售；結果七個建模的小哥折騰了半年也不夠精準，離職了4個，剩下仨垂頭喪氣。

到底如何100%精準呢！

認真思考這個問題場景，就會覺得很搞笑：真有100%精準預測魚蛋香腸的本事，這七個小哥還打個屁工啊，直接去炒期貨呀。

仔細研究以後發現：所謂的“缺貨錯過銷售”，根本就是一句話空話；因為沒有一個正式的缺貨登記系統（很多企業有，但這家沒有）；但是積壓導致的損耗率，卻是結結實實的高。

於是，一個最佳化方案出爐（如下圖）：

這樣運行了倆月，損耗率明顯下降，實實在在地看到了成本的減少；同時，雖然也有人抱怨：“誒呀，有些店缺貨了呀”。

可證據呢？證據呢？證據呢！沒有資料，空口白話，說了鬼信！於是順利扭轉局面；也不出意外地，甲方自己接手繼續優化了（是滴，甲方就是不喜歡籤二期、三期，都以為自己能搞掂後邊的，當然這是後話了，哈哈）。

三、不應對變化，含冤死

陣亡案例3：某大型渠道商，希望能建立模型，精準預測手機、平板銷量，避免積壓；先後換個5個做模型的，都不滿意！業務給的反饋是：預測不夠精準，導致決策失誤。

仔細研究以後發現，問題根本不在預測上，而是業務方的反覆橫跳。

考核模型效果，看的是總銷量，但總銷量分配給每個渠道負責人後，總有人跳出來要求加量、減量；而且常常看頭2周買的好，就拼命加，結果導致積壓；看頭2周差就都不想做，能甩就甩；最後整體資料偏差大，反而回頭怪演算法預測的不準。

知道這幫孫子的搞法，於是，一個最佳化方案出爐。

最佳化以後，效果立現：所謂的預測不準，90%是因為業務方自己不靠譜的談判、預判、騷操作搞出來的；不但順利脫身，而且也幫前邊五個冤死鬼洗刷冤屈（如下圖）。

四、資料質量差，著急死

陣亡案例4：某大型企業，想建立智慧客服，高薪挖來一個小哥；結果來了才發現，不但原始資料混亂，因為客服培訓做的太差，連最基礎的分類標籤：諮詢、投訴、建議都是錯亂一堆；結果嘛，自然是幹了半年沒成績，黯然滾蛋。

陣亡案例5：某大型企業，想建立“和抖音一樣的內容推薦演算法”，高薪挖來一小哥；結果來了才發現，內部根本沒有內容分類標籤，使用者打的標籤全是垃圾，90%都是空的……領導還說：“我都給了你那麼多錢了，你咋不能幹，為啥還要小妹來幫忙，你看人家抖音不都是演算法工程師做的？？”

是滴，越是迷信演算法模型的，反而越不重視資料建設，都是一臉：“你都有演算法了，你還要資料幹啥，資料不是初等低階的嗎？？？”

對了，應該有同學注意到，這些完蛋的週期都是半年，為啥？是因為很多演算法崗位，在網際網路公司就是吉祥物，為了能證明公司走在“人工智慧大路上”，維持股價；所以在網際網路公司的考核是遠沒有實體企業嚴格的；在實體企業半年不出業績，不滾蛋還怎樣。

五、問題的表面原因

以上場景，如果換一個2010年左右入行的資料探勘工程師，完全不會存在。

因為那個年代的資料探勘工程師大部分做的是電信、銀行的專案，對於資料分析方法掌握非常紮實，對於資料模型的生效場景非常謹慎；然而，一來，這些人不是輕易請的動的，二來，人家懂行。

一看你這企業：

• 領導期望過高；
• 業務相互甩鍋；
• 不懂基本原理；
• 資料基礎太差；
• 急於產出業績；
• 缺少清晰目標；

人家根本就不會來！

於是就有了開頭的畫面。

2017年開始的一波人工智慧熱潮，吸引了大量新人湧入資料探勘、演算法領域；有相當多的人根本沒有資料分析基礎，讀的是《西瓜書》+《統計學習方法》，做的是《泰坦尼克》《鳶尾花》《波士頓房價》，遇到問題就上模型，幹就完了奧力給！

這種情況，自然是盲人騎瞎馬，夜半臨深池了。

六、問題的本質原因

問題的本質在於：資料建模，本質上對抗的是低效率；是幫助人們解決運算變數多過時，手工計算複雜，難以處理的問題。

這是一種計算方法，不是智慧高於常人的神秘力量，不是仙風鶴骨的世外高人；資料建模應用最好的領域，也不是診斷經營問題，而是影象識別、語音轉化這些相對客觀的領域。

而傳統企業面臨的問題，比如：

• 突發情況多：天氣預報有雨，於是備貨少了，結果突然沒下，貨不夠賣；
• 目標不清晰：因為老闆個人喜歡，所以上了某款商品，結果老闆看走了眼；
• 業務能力差：預判不準，情緒化，收了客戶、供應商回扣，應和老闆態度想邀功。

這些亂七八糟的情況，更適合用資料分析方法來解決。

資料分析，本質上對抗的是不確定性；是透過認真的採集資料、梳理業務流程、診斷業務問題、進行資料測試；把主觀臆斷關進籠子裡。把“我以為”換成“我確信”。

所以遭遇複雜的企業經營問題，最好的做法是認真做好資料採集、認真建立分析模型、一點點積累分析經驗；而不是指望一隻阿爾法大狗子汪汪一叫就撥雲見日迎春歸。

所以我們看到，只要把複雜場景梳理清楚，撇除亂七八糟的因素，模型是可以在一定程度上解決經營問題的。

然而遺憾的是，從朋友圈文章，到管理層的內心，到正在調參的小哥的鍵盤，所有聲音都是：

• 演算法又打敗人類了！
• 演算法比你自己更懂你自己！
• 演算法實現了99%的超精準預測！

所以這種悲劇還會繼續上演，而且隨著2020年大量企業加速數字化，會上演更多，更慘烈；我們拭目以待哦。

最後，有同學說：陳老師你舉的都是實體企業的例子，那網際網路企業就是一片淨土呀。

呵呵！別的不說，單說生鮮電商，疫情影響，大家都覺得生鮮電商有前途，於是一幫連飯都沒有煮過、娃都沒有生過的演算法工程師們，正在努力研究“蔬菜精準推薦”“買菜智慧預測”演算法呢。

是滴！還是用熟悉的協同過濾，還是用熟悉的關聯規則哦。

至於結果，我們找個機會再做吐槽，有興趣的話，關注接地氣的陳老師，下一篇我們分享一個詳細建模過程，敬請期待哦。

#專欄作家#

接地氣的陳老師，微信公眾號：接地氣學堂，人人都是產品經理專欄作家。資深諮詢顧問，在網際網路，金融，快消，零售，耐用，美容等15個行業有豐富資料相關經驗。

本文原創釋出於人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基於CC0協議。