公元七世紀，在車遲國國家氣象局組織的一次求雨活動中，虎力、鹿力、羊力三位大仙成功地祈下甘霖，于水火中救了黎民。老國王雖然不明就里，卻從此尊他們為國師，奉道教為圭臬。

本世紀，算法工程師們的境遇也差不多：早些年，信奉糙快猛主義的大佬們覺得他們飽食終日、無所用心，沒工作只好在學校混博士，靠數據上的障眼法裝神弄鬼。可是，隨著去年AlphaGo大破李世石，大佬們在心底喊出“我操”的同時，慌不擇路地把各種搞劫持、送外賣的生意包裝成人工智能，并紛紛請來幾位懂算法的國師加持。雖然他們對國師們所做的事智商上并不理解，卻虔誠地希望他們快點兒求下雨來。

于是，算法工程師的身價也水漲船高了。各門派工程師不論過去練的是java、php還是excel，都放棄了最好語言的爭論，抄起了深度學習，發誓重新修煉成算法工程師。前些天，還有人在知乎上問我：20萬、50萬、100萬的算法工程師，到底有什么區別？

這樣充滿銅臭味兒的問題，讓我十分欣慰。雖說在北京，20萬已經基本不可能招到靠譜兒的算法工程師了，還是姑且用上面的數字做個參照，談談算法工程師的三個層次吧。（這里說的算法，并不是計算機系本科課程《算法與數據結構》里那個算法。那門課里講的，是排序、查找這類"確定性算法"；而這里我們說的，是用統計方法對數據進行建模的"概率性算法"。）下文中會提到一些算法和模型，但不過是為了舉例說明概念，無需深究，有興趣鉆研的朋友可以自己查閱資料。

第一層次"Operating"：會使用工具

這個層次的工程師，對常用的模型比較熟悉，來了數據以后，好歹能挑個合適的跑一下。

達到這個層次，其實門檻不高。早些年，您只要掌握了什么叫LDA、哪叫SVM，再玩過幾次libnear、mahout等開源工具，就可以拿到數據后跑個結果出來。到了深度學習時代，這件事兒似乎就更簡單了：管它什么問題，不都是拿神經網絡往上堆嘛！最近，經常會遇到一些工程師，成功地跑通了Tensorflow的demo后，興高采烈地歡呼：我學會深度學習了，我明天就統治人類了！

這事要真這么簡單，我是茄子。任憑你十八般開源工具用的再熟，也不可能搞出個戰勝柯潔的機器人來。這里要給大家狠狠澆上一盆冷水：進入這個領域的人，都要先了解一個“沒有免費的午餐定理”，這個定理的數學表達過于晦澀，我們把它翻譯成并不太準確的文藝語言：

如果有兩個模型搞一次多回合的比武，每個回合用的數據集不同，而且數據集沒什么偏向性，那么最后的結果，十有八九是雙方打平。

管你是普通模型、文藝模型還是2B模型，誰也別瞧不起誰。考慮一種極端情況：有一個參賽模型是“隨機猜測”，也就是無根據地胡亂給個答案，結果如何呢？對，還是打平！所以，請再也不要問“聚類用什么算法效果好”這樣的傻問題了。

這就很尷尬了！因為掌握了一堆模型并且會跑，其實并沒有什么卵用。當然，實際問題的數據分布，總是有一定特點的，比方說人臉識別，圖中間怎么說都得有個大圓餅。因此，問“人臉識別用什么模型好”這樣的問題，就有意義了。而算法工程師的真正價值，就是洞察問題的數據先驗特點，把他們表達在模型中，而這個，就需要下一個層次的能力了。

會使用工具，在算法工程師中僅僅是入門水平，靠這兩把刷子解決問題，就好比殺過兩只雞就想做腹腔手術一樣，不靠譜兒程度相當高。如果不是在薪酬膨脹嚴重的互聯網界，我覺得20萬是個比較合理的價格。

第二層次"Optimization"：能改造模型

這個層次的工程師，能夠根據具體問題的數據特點對模型進行改造，并采用相應合適的最優化算法，以追求最好的效果。

不論前人的模型怎么美妙，都是基于當時觀察到的數據先驗特點設計的。比如說LDA，就是在語料質量不高的情況下，在PLSA基礎上引入貝葉斯估計，以獲得更加穩健的主題。雖說用LDA不會大錯，但是要在你的具體問題上跑出最好的效果，根據數據特點做模型上的精準改造，是不可避免的。

互聯網數據這一現象更加明顯，因為沒有哪兩家公司擁有的數據是相似的。百度的點擊率模型，有數十億的特征，大規模的定制計算集群，獨特的深度神經網絡結構，你能抄么？抄過來也沒用。用教科書上的模型不變應萬變，結果只能是刻舟求劍。

改造模型的能力，就不是用幾個開源工具那么簡單了，這需要有兩方面的素養：

一、深入了解機器學習的原理和組件。機器學習領域，有很多看似不那么直接有用的基礎原理和組件。比方說，正則化怎么做？什么時候應該選擇什么樣的基本分布？(如下表) 貝葉斯先驗該怎么設？兩個概率分布的距離怎么算？當你看到前輩高人把這些材料烹調在一起，變成LDA、CNN這些成品菜肴端上來的時候，也要想想如果自己下廚，是否了解食材，會不會選擇和搭配。僅僅會吃幾個菜，說出什么味道，離好廚師差的還遠著呢。

二、熟練掌握最優化方法。機器學習從業者不懂最優化，相當于武術家只會耍套路。這就跟雷公太極和閆芳大師一樣，實戰起來一定是鼻青臉腫。管你設計了一個多牛逼的模型，如果無法在有限的計算資源下找出最優解，那么不過是個花瓶罷了。

最優化，是機器學習最、最、最重要的基礎。你要知道，在目標函數及其導數的各種情形下，應該如何選擇優化方法；各種方法的時間空間復雜度、收斂性如何；還要知道怎樣構造目標函數，才便于用凸優化或其他框架來求解。而這些方面的訓練，要比機器學習的模型還要扎實才行。

拿大家以為"以不變應萬變"的深度學習舉個例子。用神經網絡處理語音識別、自然語言處理這種時間序列數據的建模，RNN（見上圖）是個自然的選擇。不過在實踐中，大家發現由于“梯度消失”現象的存在，RNN很難對長程的上下文依賴建模。而在自然語言中，例如決定下面的be動詞是“is”還是“are”這樣的問題，有可能往前翻好多詞才能找到起決定作用的主語。怎么辦呢？天才的J. Schmidhuber設計了帶有門結構的LSTM模型（見下圖），讓數據自行決定哪些信息要保留，那些要忘掉。如此以來，自然語言的建模效果，就大大提高了。大家初看下面兩張RNN與LSTM的結構對比，面對憑空多出來的幾個門結構可能一頭霧水，唯有洞徹其中的方法論，并且有扎實的機器學習和最優化基礎，才能逐漸理解和學習這種思路。

當然，LSTM這個模型是神來之筆，我等對此可望不可及。不過，在這個例子里展現出來的關鍵能力：根據問題特點調整模型，并解決優化上的障礙，是一名合格的算法工程師應該追求的能力。年薪50萬能找到這樣的人，是物有所值的。

第三層次"Objective"：擅定義問題

這個層次的工程師（哦，似乎叫工程師不太合適了），扔給他一個新的實際問題，可以給出量化的目標函數。

當年，福特公司請人檢修電機，斯坦門茨在電機外殼畫了一條線，讓工作人員在此處打開電機迅速排除了故障。結賬時，斯坦門茨要1萬美元，還開了個清單：畫一條線，1美元；知道在哪兒畫線，9999美元。

同樣的道理，在算法領域，最難的也是知道在哪里畫線，這就是對一個新問題構建目標函數的過程。而有明確的量化目標函數，正是科學方法區別于玄學方法、神學方法的重要標志。

目標函數，有時能用一個解析形式（Analytical form）寫出來，有時則不能。比方說網頁搜索這個問題，有兩種目標函數：一種是nDCG，這是一個在標注好的數據集上可以明確計算出來的指標；另一種則是人工看badcase的比例，顯然這個沒法用公式計算，但是其結果也是定量的，也可以作為目標函數。

定義目標函數，初聽起來并沒有那么困難，不就是制定個KPI么？其實不然，要做好這件事，在意識和技術上都有很高的門檻。

一、要建立“萬般皆下品、唯有目標高”的意識。一個團隊也好、一個項目也好，只要確立了正確的、可衡量的目標，那么達到這個目標就只是時間和成本的問題。假設nDCG是搜索的正確目標函數，那么微軟也好、Yahoo!也好，遲早也能追上Google，遺憾的是，nDCG這個目標是有點兒問題的，所以后來這兩家被越拉越遠。

所謂“本立而道生”：一個項目開始時，總是應該先做兩件事：一是討論定義清楚量化的目標函數；二是搭建一個能夠對目標函數做線上A/B測試的實驗框架。而收集什么數據、采用什么模型，倒都在其次了。

二、能夠構造準確(信)、可解(達)、優雅(雅)的目標函數。目標函數要盡可能反應實際業務目標，同時又有可行的優化方法。一般來說，優化目標與評測目標是有所不同的。比如說在語音識別中，評測目標是“詞錯誤率”，但這個不可導所以沒法直接優化；因此，我們還要找一個“代理目標”，比如似然值或者后驗概率，用于求解模型參數。評測目標的定義往往比較直覺，但是要把它轉化成一個高度相關，又便于求解的優化目標，是需要相當的經驗與功力的。在語音建模里，即便是計算似然值，也需要涉及Baum-Welch等比較復雜的算法，要定義清楚不是簡單的事兒。

優雅，是個更高層次的要求；可是在遇到重大問題時，優雅卻往往是不二法門。因為，往往只有漂亮的框架才更接近問題的本質。關于這點，必須要提一下近年來最讓人醍醐灌頂的大作——生成對抗網絡（GAN）。

GAN要解決的，是讓機器根據數據學會畫畫、寫文章等創作性問題。機器畫畫的目標函數怎么定？聽起來是一頭霧水。我們早年做類似的語音合成問題時，也沒什么好辦法，只能找人一句句聽來打分。令人拍案叫絕的是，Ian GoodFellow在定義這個問題時，采取了下圖的巧妙框架：

這樣一個目標，優雅得象個哲學問題，卻又實實在在可以追尋。當我看到這個式子時，頓時覺得教會機器畫畫是個不太遠的時間問題了。如果你也能對這樣的問題描述感到心曠神怡，就能體會為什么這才是最難的一步。

一個團隊的定海神針，就是能把問題轉化成目標函數的那個人——哪怕他連開源工具都不會用。100萬找到這樣的人，可真是撿了個大便宜。

在機器學習領域，算法工程師腳下的進階之路是清晰的：當你掌握了工具、會改造模型，進而可以駕馭新問題的建模，就能成長為最優秀的人才。沿著這條路踏踏實實走下去，100萬并不是什么問題。什么？您說還有300萬的呢？這個不用眼熱，人家只不過把你寫代碼的時間都用來跳槽了而已。