做演算法工程師是什麼樣的工作體驗？
演算法工程師，指的是有機器學習，數據挖掘，自然語言處理，分散式計算等方面工作的人員。
互聯網計算廣告從業快三年了，讓我來告訴你吧，工作大概是這個樣子：
每天的最重要工作就是跑數據！
每天的最重要工作就是跑數據！
每天的最重要工作就是跑數據！
重要的事情要說三遍！！！
想像的演算法工作是這樣的：拿到最近某大神新發的Paper，或者自己鑽研理論推公式產出理論成果，通過並行編程實現其支持大規模數據訓練，然後打敗現有模型，ctr提升200%，收入提高200%，此訓練工具在工業界廣為流傳，升值加薪贏取白富美，出任xxx...
但是現實中往往是這樣的：這個特徵可能對ctr預估是有用的，然後-&>特徵調研跑數據-&>生成訓練數據跑數據-&>模型效果不好請回到特徵調研-&>小流量實驗跑數據-&>實驗效果不好，回到特徵調研-&>全流量跑數據-&>效果不好請回到特徵調研-&>done,你終於有產出了，效果是ctr提升：0.2% !!!!!!
或者是策略升級，你想破腦子想了一個策略，然後，花了兩個月做實驗，策略調研跑數據-&>策略模型訓練跑數據-&>策略小流量跑數據-&>策略實驗對比跑數據-&>策略全流量跑數據。然後這個策略尼瑪後來發現是:負 向 的！沒錯，你這兩個月產出是0。艹
神馬演算法，先要把hql、mr、streaming其中一種寫的爐火純青，不然你啥也幹不了，是的，就是-啥-也-干-不-了！！
先寫這麼多吧 20150620理想中的演算法工程師：提出假設-&>收集數據-&>訓練模型-&>解釋結果。
實際中的演算法工程師：提出假設-&>收集數據-&>預處理-&>預處理-&>訓練模型-&>調試-&>調試-&>重新收集數據-&>預處理-&>收集更多數據-&>調試-&>調試-&>調試-&>...-&>放棄。
我不算工程師，只算打雜的。。還是說說我老闆吧，確實太佩服他了。
我老闆的title就是Research EngineerScientist, 之前是讀cs的phd，主要做的是機器學習。
他的工作內容包括：
1）跟大老闆討論idea，討論到底可不可行，能不能做。。很多也是淺嘗輒止，嘗試了一下效果並不好就棄坑了。
2）會讀很多paper，而且速度驚人。每年機器學習的一些會議icml，cvpr、acl都會關注，然後會發郵件列出一些他覺得不錯的paper給我這個low b看。不過確實太多了，我看paper速度也沒那麼多，其實很多時候我就划水了。業界的東西他好像看的主要是書，課本那些，估計是自己不算太懂也在學習吧。
3）全棧工程師，手速很快。我們為了開發比較快，很多時候都是用現成的api，哪個api寫得比較好就用哪個，當然還會根據需求改一下。所以看老闆寫模型，python，java是主力，為了給人展示自己也會做一些前端，用得很6，除此一些比較非主流的語言也是秒好。比較佩服他的地方是能迅速判斷完成一個特定的task需要什麼工具，然後讀api文檔很快就掌握了。
這個看在什麼公司的什麼部門做什麼樣的演算法狗，大致看來我覺得可以分為兩類：
1. 一樓答主的方向，一個行業通用、well-defined的機器學習問題，最經典的就是廣告的點擊率預估。這類工作的典型特點就是，問題已經很好的建模了，而且這個問題是能夠極大影響業務的（如ctr預估的准廣告點擊量就能提升-&>收入正向）。所以主要的工作主要是圍繞模型的幾個重要要素進行不斷的優化：特徵、樣本、演算法。
實際的工作中特徵優化的性價比最高，於是乎，便有了第一種工作形態：
設計特徵 -&> 跑數據調研特徵 -&> 新增特徵進行離線模型訓練 -&> 上線小流量實驗 -&> 分析實驗效果 -&>全流量 or 下線.
2. 在一個有較多能用（或者老闆期望）機器學習演算法解決的問題的部門，這種情況下的主要特點是問題並不明確，因此這個場景下的工作其實有點偏向於 data mining， 核心的工作路徑是：
業務分析 -&> 發現業務核心問題 -&> 問題的建模 -&> 問題解決
其中前三步是關鍵，問題解決部分才開始使用機器學習的演算法，甚至有時候並不是特別高深的演算法。
1和2的佔比來說的話，以度廠來說個人覺得2還是比較多，2和更多的業務線貼合的比較緊。但是以大家所感覺的高大上來說的話，1顯然比較貼近實驗室中大家感受到的機器學習工作。
－－－大清早的看到同事發來的問題，有感。
首先，我需要：
和運營撕逼需求，拚命解釋」自己是演算法工程師，不是算命工程師，不是你說轉化率要到95%就能到的「
和產品撕逼結果，拚命解釋」結果是經過嚴格的數學證明的，真的不是yy的，自己真的不是路邊算命的轉行過來的「
和老大撕逼排期，拚命解釋」一個月做10個模型做不完，不不不，5個也做不完，真的不能一個做完所有需求，不存在這樣的模型「
然後才開始梳理需求，整理可行性演算法，數據整理，數據預處理，模型訓練，模型評估，重新想可行性演算法，，數據整理，數據預處理，模型訓練...
首先針對特定的問題，選演算法。不過演算法用的都是經過學界積累認同的。不會用最新的演算法，因為不一定靠譜。然後大牛會大概選2到3個演算法。
之後就是實現演算法，對數據（企業這就爽多了，有數據，沒有數據用錢組織人去標數據）進行演算法的驗證。
然後就是調參數，選特徵，調參數，選特徵，調參數，選特徵。然後做出特定模型的最優解。
針對特定問題進行少量的修改模型（舉個手頭的例子，業界評價標準是F值，但是在實際產品中，對準確率更敏感，召回率不敏感，所以會略微修改模型，符合產品要求。）
最終，選擇應用於產品的模型。
調參數看上去比較枯燥無聊。大量依靠經驗。但是菜鳥和入門人士最大的區別。畢竟你對演算法不理解的話，調參數往往會走很大彎路。
然後會有負責高性能計算的同事，將演算法的計算優化，應用於產品中。
並不會一直很忙，閑的時候看PAPER、
PS：吐槽一下，學界的東西就算是頂會也有一半，在業界看來是廢紙，對於其他會議基本就是廢紙。
最後，如果認為自己更喜歡創建新模型之類的同學。請不要進企業中來，因為基本上新手進來都是調參數的。你廣泛的腦洞只有在學界才有意義。企業要的是結果。關注該問題，看了大量學術前沿的論文，至今不知道在業界有什麼卵用。。。。
演算法工程師在工作中主要會涉及三個方面的工作：
1、研究新演算法或者在現有演算法的基礎上做優化。這時需要讀一些研究論文，並針對自己所面對的應用場景，做專門的新型演算法研究及對現有演算法進行改進。
2、工程開發。將構建的演算法通過代碼實現，在數據集上進行測試，檢驗效果。
3、演算法調整、參數調優。對於大部分的演算法，構建好模型、代碼實現只是最初的一步，更多的工作量是在對演算法模型進行調整、參數進行調優，從而可以使得自己構建的演算法可以更加匹配你所分析的數據，達到最優的效果。
看paper，興奮，做實驗，沮喪，repeat。。。
1 根據業務場景，演算法調研，看paper看書看各種資料；
2 先考慮成熟的演算法，能用開源就用；能改就改；最後考慮自己實現；
3 數據預處理各種清洗各種過濾，上演算法，跑模型；這個階段各種等，等，等，漫長地等待；
4 演算法調參，優化；
6 A/B test
看各種paper，發現了一大堆似是而非的演算法，仔細一看，最後演算法判斷結果都是人工識別，尼瑪。
千萬別羨慕
有時幾個月搞不出點東西
天天收集數據，數據預處理，調模，跑數據，調模，重新收集數據，處理數據，跑數據，跑數據，調模，最後發現尼瑪越調越來越看不下去，算了，室內定位演算法，看了100多篇英文論文，發現其實並沒啥用
- 基於項目確定可行的演算法
- 看paper，尤其是經典的paper
- paper上演算法的實現
- 用數據跑模型，調參
- 效果不好，增加或整理數據，跑模型，調參，循環這個過程……
- 終於達到項目指標了
其實，在這個過程中，畢竟經典演算法就那些固定的，重頭戲是循環地收集數據和處理數據，它會極大限度地挑戰你的耐心，當你正要瘋掉或放棄的時候……咦，達到指標了
不要高興的太早，後期的運營維護還是離不開數據，數據，數據
理想中的演算法工程師：拿到一個問題，給出一個漂亮的formulation，再找一個好的優化演算法。怎麼多線程或者分散式實現一下，然後不斷優化模型
實際中的演算法工程師：詞表，跑數據，詞表，跑數據，詞表，跑數據，詞表，跑數據.....調包俠，調參狗，特徵豬，指標奴
調參俠..
看完有種還沒入門就想放棄的感覺。。。
和項目相關。
好的項目：調研論文，做實驗，開發，效果評估，上線。
不好的項目：sql，sql，sql……
無聊的項目：wrapper，wrapper，wrapper。
圍繞數據、特徵、模型的老中醫！
幾種努力方向：特徵工程、模型工程、參數調優等。
推薦閱讀：
※有哪些人堪稱「神人」，卻不為大眾所知？
※在日本穿漢服是種怎樣的體驗？
※如何評價比亞迪的「唐」？
※有哪些讓你忍不住反覆翻閱的書？
※做一個可愛的女孩子是一種什麼體驗？