機器學習數據挖掘類工程師平時主要的工作內容是怎樣的？

11-24

比如研發類工程師可能就是根據項目需求寫代碼，那機器學習，數據挖掘類工程師平時主要的工作內容是怎樣的？我理解的是：根據項目選取不同的模型做實驗，根據實驗結果調參等等。經常閱讀本領域內相關的paper，實現一些最新的研究成果，參加各種學術會議。是這樣的么？請有在公司工作過的各位大大說明一下，謝謝了。

舉一個真實的例子。

背景：

當初所在的產品團隊所做的是一款類似於Steam的產品，遊戲下載是核心需求之一。但是因為國內用戶的機器普遍比較差，許多大型而高配置的單機/網路遊戲，下載後基本跑不起來，極大傷害用戶體驗。因此為用戶下提供了配置檢測功能，在下載前根據用戶的機型配置告訴其能否玩某款遊戲
對機器配置打分以及對遊戲最低配置要求打分都是基於很粗糙的經驗公式，經常出現False Positive（系統說能玩，但是用戶花了好幾個小時下載和安裝，結果不能玩；被用戶罵得狗血噴頭）或者False Negative（系統說不能玩，結果後來實踐發現該配置其實能玩，損失了用戶的粘性，PM恨死你）

故事在這裡開始發生。

第一步，產品團隊提出需求
產品團隊要求數據團隊基於海量數據（日活幾百萬，日遊戲下載數量過百萬，日遊戲啟動次數過千萬），優化配置檢測的評分系統。

第二步，將需求轉化為數學語言或者數學模型
數據團隊一看，這個簡單呀，其實就是：

目的：優化機器配置的打分函數f(機器配置)和遊戲最低配置要求的分數的函數g(遊戲)
評價：降低之前提到的FP和FN（可以使用小範圍的用戶反饋收集以及後台運營人員的小範圍測試）

第三步，搭建平台和抽取數據
根據數據量以及不能影響業務的最低職業操守，我們的選擇是Hive + MySQL + Python + R，然後開始抽取最近數月的日誌。

第四步，數據處理和清洗形成核心數據集
這一步應該是做這一行的同學們最恨的，原因無他：做起來看似最無技術含量而最耗時間，而往往又最影響最後的產出。（這一段擼啊擼的血淚史就省去了，諸君共勉）最後形成核心數據集，比較核心的欄位包括：用戶ID、機器配置及得分、玩各個遊戲的時長、各個遊戲的配置要求最低分等等。

第五步，研究數據和選擇合適的模型
一開始就熱血沸騰，這個需求好簡單呀，我能立馬體現價值！對於某些高配置遊戲，查看各種配置的機器玩這些遊戲的平均時長，就能優化各種配置的得分了。道理也很直觀，低配置機器因為很難支持高需求遊戲的運行，會出現卡頓或者藍屏，所以遊戲平均時長必然很短。這個推斷非常有道理，結果數據跑出來完全偏離常識，這裡出現第一坑：

可能出現了臟數據：中國的PC環境太複雜，各種機器改裝、刷機（比如許多同一個MAC地址的多個網卡等等）以及軟硬體偉哥式得打補丁增強，已經嚴重改變了該配置本來的性能
可能出現了Survivorship Bias（Survivorship bias），那些明知機器很爛但是仍舊堅持下載、啟動並玩高配置遊戲的用戶，可能是真愛，遊戲時間往往會更長

發現第一個坑，意識到問題沒有這麼簡單，開始調整模型，比如：是不是可以用某個配置玩一些高配置要求的遊戲的相對比例，來確定機器配置的得分（玩高要求配置遊戲越多的機器，按理說配置得分應該越高）。迅速發現第二個大坑：

遊戲的最低配置要求往往來自於遊戲開放商，其實也是很不靠譜的，所以最低分函數g(遊戲)也應該要優化。其中g(遊戲)是官方推薦，可以基本不用管了
機器-&>遊戲-&>機器-&>...，是一個循環，高配置機器的用戶更愛玩高要求的遊戲，高要求遊戲的用戶更多是高配置機器……（怎麼快搞成Collaborative Filtering的問題了）

然後在這第五步中間不斷摸索爬坑，甚至回到第四步，甚至的甚至讓產品新上線一些功能收集新的數據（比如：讓用戶對用戶是否能玩點擊確認或者否認），但是讓產品增加需求這個真的很難，產品汪和程序狗已經很不容易了，建議不要嘗試。

第六步，評估模型
優化後的配置打分的演算法以及遊戲最低要求配置得分的演算法上線，這時候產品和程序員是願意增加一些功能來收集數據幫助數據分析師評估模型和效果的。然後根據評估效果（FP和NP的出現概率），如果不行的話，回到第四步重新開始吧。

數據預處理，數據預處理，數據預處理。

大部分時間在做數據預處理，真正實際的模型選擇，參數調優占的工作時間大概不到30%。

有一句話說的挺好: 數據和特徵決定了機器學習的上限，模型和參數決定了逼近這個上限的程度。

所以，花大力氣去做特徵工程是很有意義的。

首先說明一下，在你印象中閱讀paper，搞科研成果的數據挖掘工程師可能在各大公司研究院中存在比較多（比如百度IDL）。一般公司的機器學習崗位很實際，找到的工程師往往是要解決一些實際問題的，所以有業務壓力，沒有給你預留做研究的時間。@盧嘉穎已經說了，數據預處理其實佔用了相當多的時間，機器學習演算法的好壞其實實際中主要取決於訓練數據質量，所以「特徵工程」就顯得十分重要，數據預處理做得好，簡單的演算法往往就可以達到目的，數據預處理差，再牛逼的演算法也沒有卵用。所以，干這行有時候會幹點體力活，就是這塊。
OK，主要工作內容是什麼？跟研發類工程師其實差別也不大，接受商務部門的需求（比如預估一次廣告投放的曝光量或互動率），然後就去做模型了，找一堆以往的投放數據，簡單的你可以做做回歸預測，在一定誤差內能解決問題。干這行有個問題，你不光得像研發工程師一樣去寫代碼實現演算法，你還會遇到一堆無解的問題（我覺得基本都無解），你選模型了，萬一模型然並卵呢？萬一參數然並卵呢？研發可以碼完code回家打Dota了，數據挖掘工程師的工作才剛剛開始... ...知道了吧，跟研發最大的差別是碼完代碼你的工作才剛剛開始。
最後，再留一條一個類似問題的解答做演算法工程師是什麼樣的工作體驗？ - 數據挖掘，去看看吧

我的流程一般是這樣：
1. 公司制定一個項目
2. 產品經理開始策劃該項目，提出業務需求
3. 將產品經理需求轉化為數據需求
4. 拉取伺服器日誌文件
5. 根據需求，開始提取數據
6. 數據處理，特徵研究（無限循環特徵研究，這是最耗時間的階段）
7. 尋找合適的模型
8. 評估模型
9. 返回第6步，不斷重複此過程~~

做數據挖掘最重要的工作可能在下面這兩方面：
1、數據理解
針對具體需求，知道需要哪些數據；拿到數據後，知道怎樣做變數選擇。這兩點往往最耗時，也最能體現牛逼數據分析師的價值。

2、數據準備
拿到數據後，怎麼清洗數據，採取哪種方式離散化等。這個階段相對偏向業務的數據理解階段，更容易著手。

歡迎大牛們，提出寶貴的不同意見~~····

Data cleansing.....

現在的工作大概是50%的BI，25%的開發+25%的演算法模型。感覺不同團隊做數據挖掘差別挺大的，有些是偏業務的，有些專搞模型演算法，還有些是造數據挖掘工具輪子的，對外都叫數據挖掘工程師。
偏業務的數據挖掘感覺做的工作比較雜，和業務相關數據需求都會提到你這裡來，大部分是一些數據指標，有些是數據結構比較複雜的功能模塊，演算法模型也有一些，不太多。搞演算法模型大部分的時間也都是在用sql，mr擼特徵，再做一些特徵處理特徵選擇的工作，在業務部門的好處就是對業務了解會多一點，擼起特徵來更有針對性，有時候效果會比專搞演算法模型的還要好一點。壞處就是演算法氛圍比較一般，也沒太多時間深入調優，差不多好用的話就去忙下個項目去了……

1、數據預處理。2、特徵選擇。3、隨便找個經典的演算法試試。4、ROC可以，搞定收工。

和樓上某答的業務壓力相同看法。

單人做過幾個前端抓取項目，挖掘WWW時候，字元類不用涉及到機器學習，圖像也不一定，挖掘的核心是很常用的字元運算。

實際操作能力是很重要的，也需要直覺的分解能力，知道那條道路是最快的，因為數據量大，你用的處理方式稍微慢，稍微模糊的話是不可能完成的，從接到訂單，到8小時之內收割完整個歐洲區數據，什麼時候用枚舉，什麼時候用暴力列表，判斷層深，你用機器學習？原始數據後期處理就知道了。

數據到手之後，，，，才考慮怎麼個機器學習。適用於數據對象的運動、變化。抽出個什麼高維特徵？我估計航母級企業內有限少數人實踐過吧，然而和回歸加權又有什麼區別？

但是如果能用一個word圖表完成的工作就千萬不能用複雜的方式來。

另外，個人感受是別用裝逼犯寫的開源坑，故意的，查文檔就夠你玩一星期的了.

嗯，看來機器學習只能用在過識別碼。。。。。。。

做聊天機器人
大部分時間當然是處理數據
然後讀論文
然後找有沒有現成的代碼拿來修改
如果沒有就蛋疼了 tensorflow用的最多一個部分一個部分的堆 model fn，input fn，eval fn……
最慘的就是碼出來跑不起來……
加油

干數據，每天