談一談資料探勘的軍規

筆者鼓勵致力於從事資料行業的去參加一些人工智慧，機器學習的培訓，然後有人說：其實很多企業不喜歡培訓出來的人，認為培訓不貼近實際，紙上談兵。

我倒不這麼看，其實即使在企業內幹資料探勘的人，很多也出不了活，這個不僅僅涉及業務和技術，更是管理上的問題。

任正非說，華為最後能留下來的財富只有兩樣：一是管理框架、流程與組織支撐的管理體系;二是對人的管理和激勵機制，什麼是流程化組織，簡單的說，就是基於流程來分配權力、資源以及責任的組織。

為什麼這麼說?

筆者的粗糙理解就是：好的做事的方法，靠人的口口相傳是沒有用的，寫成書也是沒人看的，只有把這些東西固化到企業的生產流程中去。

你要幹活就必須遵循這個流程，才能讓這些方法成為企業的基因，無時不刻發揮出其應有的價值，阻止突破底線事情的發生，流程讓新人做事一開始就站在巨人的肩膀上。

創新型的公司往往是傳統流程和機制的破壞者，但當初公司在建立這些流程和機制的時候，其實符合當時的大多利益，而且這些機制和流程確保了企業最基本的利益，所以後來要被顛覆，只是因為跟不上變化了而已，絕不是說機制和流程本身就是個問題。

可惜的是，對於資料探勘這麼複雜的、不確定性的工作，我們竟然很少去制定符合其特點的相關的流程和規範，有些資料探勘美其名曰立項建設，大多采用放飛的方式進行，失敗是大多數的，投資浪費是很多的，偶偶的亮點不能說明問題。

資料探勘工作定義的六個階段，業務理解、資料理解、資料準備、模型構建、模型評估、模型部署，被大家簡單的理解為純粹的技術步驟，從來沒想過這些階段跟管理有什麼關係。

但正是管理的缺位，導致大量的資料探勘工作事倍功半，新人來到一個團隊，歷經千辛萬苦作出的東西，往往一文不值，這到底是新人的問題還是團隊的問題?

資料探勘工作其實根本不可能靠閉關三日來給出什麼驚喜，這是為實踐所證明的。

如果你是一支資料團隊的管理者，改變不了整個企業的環境，比如資料驅動業務的思想，公司的政策等等，但應該在你的職權範圍內，在有限的資源條件下，用更好的管理手段讓資料探勘工作變得更有效。

最近，我跟團隊正在思考擬定資料探勘的管理流程和規範，共5個關鍵節點，希望新人做的資料探勘工作，能夠按照規定的流程走，從一開始就能站在一個較高的起點上，並一直處在一個較為正確的方向上，直到成功或者快速的失敗。

一、需求分析

團隊大了，工作多了，每個人的自由權就相對大了，這個時候團隊就要明確一些做事的原則，什麼樣的資料探勘可以做，什麼樣的資料探勘不要做，這個不能靠拍腦袋，以下給出了4個原則，如果不滿足就要退回：

1、公司或部門重點工作(比如OKR)、領導安排的重點需求、日常運營分析和一線反饋的重點需求，杜絕不計原則的去接收挖掘需求，資料探勘不是買菜，要耗費企業最珍貴的資料分析或挖掘資源，少而精是原則。

2、判斷是否已有相關模型或標籤滿足需求，有則推薦現有模型和標籤，如果有相關模型或標籤但無法滿足現有需求，則需優化原模型和標籤，這其實也是資料治理的要求，很多挖掘其實是原來做的不好或者未有效推廣，不能重複造輪子。

3、雙方明確資料探勘目標，初步評估技術可行性及大致所需工期，包括度量成功的指標(精確率、召回率)、定義成功的基準(小樣本驗證、AB測試等)，業務側可能的主觀評估標準(覆蓋使用者數、納入業務生產流程)等等。

4、聯絡業務方明確驗證方案，如果對方無法承諾驗證環境，比如政策和外呼資源等等，則要特別謹慎，根據經驗，由於配合不到位導致的模型延期上線或者失敗的案例比比皆是，究其原因，還是因為業務方不夠重視或者級別不夠，調動不了相關資源去推進這個事情。

除了以上原則，我們還制定了升級領導的原則，包括與業務方無法在目標上達成一致，實施週期超過XX人天等等，這些都是為了制止盲目的開啟一個資料探勘課題。

二、方案設計

這一過程看似簡單，有些人甚至只是腦子轉了下就倉促跳過，但很多建模失敗就栽在這個階段。

在方案設計階段要善於換位思考，承認自己的認知有限性，始終想著如何才能獲得最強的“業務大腦”和“資料大腦”來幫助你更好的理解業務和對應的資料，包括三個方面的工作：

1、明確所需資料及必要的特徵：對於較為複雜且重點課題，一般都要組織相關利益方開展頭腦風暴，集思廣益進行特徵的有效選擇，大量的資料探勘工作失敗在於建模者僅憑自己有限的業務知識和有限的調研(包括有限的通識理解，特別是不諳世事的新人)就倉促選定變數，然後直接跳到自己以為擅長的資料建模階段在調參上耗盡心血，最後事倍功半，代價不可謂不大。

2、明確所需模型及技術實現步驟：一般跟著經驗走就可以了，關於技術實現步驟相信每個企業都有自己的經驗做法，比如我們就發現隨機森林在很多情況下好用，新人不清楚就問導師，這一步其實是比較簡單的。

3、進行方案設計的彙報：要向利益相關者及你的領導彙報方案，領導可能技術上不如你，但人生經驗比你足，業務視野比你開闊，擁有的資源比你多。

因此，要努力爭取到他的看法，領導支援你去做這個事情不代表他就支援你的設計，不要試圖跨過領導等有了建模結果後再向他彙報，因為一旦結果不好，領導的團隊成本已經花出去了，他不看好你的設計方案可以直接說NO，你要給他這個機會。

三、建模開發

這個階段大致可以分為三個子過程：

1、寬表開發及資料預處理：誰都知道這個步驟，大家都喜歡建立自己的寬表為自己的資料探勘服務，但如果你對企業的資料資產局理解不夠全面的化，就會在寬表處理上重複造輪子，效率很低。

因此，對於資料資產的全域性掌握進行定期的培訓和考試是有必要的，很多人做了好長時間資料探勘卻對於融合模型不清楚，這是管理上出現了問題。

2、模型基線開發及訓練評估：引數調優、交叉驗證、效果評估都是需要反覆進行的過程，但如果發現難以達到滿意的結果就不要一路走到死，召集相關人員進行一次技術討論是非常有必要的。

4、模型和標籤上線釋出：模型和標籤上線要遵循嚴格的標準，包括是否滿足當初設定的技術指標要求，是否滿足資料治理要求，是否滿足運維效能的要求等等。

四、試點驗證

1、效果驗證：跟功能開發不同，模型上線不代表就結束了，因為實際的生產環境跟你的訓練環境會有很大的差別，你需要協調業務方按照當初的承諾儘快的進行效果驗證，這個時候你要承擔起連線者的角色，推進各方儘快反饋生產的效果，如果無法達到當初的設定目標，就要考慮重新優化模型，試點推進不利很多時候是業務方的原因，比如外呼排期延後等等，這個時候就要推動領導協調。

2、試點彙報：一旦達到要求，就要組織業務方和自己方的領導進行彙報，明確模型是否具備全面推廣或納入生產的條件，這個涉及到業務方相關政策和資源的配合，不是簡單的模型的問題。組織這種會議其實是向各方領導表明，我已經完成了任務，但要讓這個模型產生價值，接下來你們得給我資源配合完成剩餘的非功能性工作，好的模型最後不了了之往往是溝通出了問題，業務方的領導跟你的領導很多時候資訊是極度不對稱的，你要幹成事情就得多做協調的事情。

很多試點的結果並不理想，彙報的另一個目的就是及時止損，一方面是由於市場變化很快，總有意外的情況發生，另一方面是現有的模型的確達不到業務要求，你不能被一個看似無前途的事情拖死，你需要領導幫你做決策，繼續幹還是放棄。

五、總結匯報

1、你要跟蹤模型的生產執行效果，及時釋出運營報告，讓你的領導和業務的領導知道你幹成了這個事情，很多時候，試點的效果很好，但一旦納入生產情況並不理想，因此要持續的跟蹤一段時間。

2、如果模型的效果保持穩定，則可以將其移交給統一運營團隊(如果有的話)，代表你交給公司的是一個可用的模型，從而進入常態化運營階段，這個時候自己才可以全身而退。後續如果運營團隊發現模型有問題，可以向你提交優化需求，由此迭代。

資料探勘最怕的就是隻管殺不管埋，比如訓練結果很好，但其實試點情況很差，試點情況還好，但生產情況很差，開始生產的時候還行，但持續一段時間就不行了。

模型師一定要記住，模型的上線絕對不是你工作的終點，而僅僅是起點，只有模型進入穩定的生產階段以後你才算完成了工作，大量的外包資料探勘工作所以失敗，就是因為他們把資料探勘工作當成了簡單的功能開發。

你會發現，筆者從需求分析講到總結匯報，都不在談技術，而是在談管理，我在談進入每個階段時要採用的質量控制的手段，其實每個階段的週期也要控制，一般來講，如果某個階段超過了二個禮拜(可以根據企業實際調整)，就要反思和對外暴露問題。

根據以上的內容很容易就畫出資料探勘的管理流程，可以貼在牆上成為軍規。當然每個企業的情況不同，流程可能不一樣，但一定要沉澱出這種流程，它們保證了基本的做事的效率，不會由於人員的變動而導致效率的下降，這就是任總所說的流程化組織要乾的事情吧。

這是我最近的一點思考，大家一起加油吧。