作者 | Japson
來源 | 木東居士
首先，《AI研發(fā)工程師成長指南》這個題目其實有些標題黨了，準確地來說，本文內(nèi)容應(yīng)該是：“要想成為一名AI研發(fā)工程師，需要具備哪些技能”。
其次，本文對“AI研發(fā)工程師”這個title的定義，也并不是大家第一印象中的“算法工程師”、“數(shù)據(jù)科學(xué)家”。
再次，本文實際上作者結(jié)合現(xiàn)階段行業(yè)發(fā)展、技術(shù)趨勢以及自身工作性質(zhì)做出的關(guān)于自身定位、職業(yè)技能、發(fā)展方向的思考。就像魔獸世界中的“職業(yè)攻略”，當我們在游戲中新建一個角色時，會先去了解這個職業(yè)的特點、天賦、技能樹等信息，這樣才會在“練級”的過程中少走些彎路。
最后，作者不是從一個很高的角度來對整個成長體系進行一個全面地闡述。而是站在道路的地點，不斷摸索、不斷前進、不斷地調(diào)整自己的規(guī)劃。因此本文不算是Best Practices，勉強算是Beta version，也希望能和大家不斷交流，不斷“發(fā)版”。
AI算法工程師年薪百萬，應(yīng)屆畢業(yè)生年薪都有80w…
去年AI人才缺口就已經(jīng)過百萬，今年將達500w…
加入《XXX訓(xùn)練營》，XX天打造AI算法工程師…
在網(wǎng)絡(luò)上充斥著各種類似上面那樣的吸引眼球的文章標題，向你訴說著人工智能這一火的不能再火的領(lǐng)域美好的前景。仿佛我們看了兩遍西瓜書、處理了MNIST和幾朵鳶尾花、在自己的筆記本電腦上掉了幾個包、得到了和教程上一樣的結(jié)果，打了幾場比賽，我們就已經(jīng)拿到了AI領(lǐng)域的通行證、成功轉(zhuǎn)型算法工程師、接大廠offer到手軟了一樣。
但實際，現(xiàn)在AI算法工程師的就業(yè)難度和準入門檻，遠比我們想象的要高。
上一張網(wǎng)絡(luò)上流傳的“諸神黃昏”吧
可以說一點不夸張，現(xiàn)在很多大廠的校招算法崗，門檻就是海外名校/985工科院校的博士/碩士。除了擁有與學(xué)歷匹配的學(xué)術(shù)能力以外，工程基礎(chǔ)也要非常扎實。
有人說：“我看網(wǎng)上說，AI人才缺口非常大，我不去大廠不就行了？其他的公司要求沒那么高吧？”
要求高不高我不知道，但是有一下兩點：
絕大多數(shù)公司，是不需要雇傭AI算法工程師，即沒有相關(guān)的業(yè)務(wù)需求，也負擔不起算法團隊的開銷
2019年研究生報考人數(shù)290萬人，預(yù)計招生70萬人，其中計算機是熱門專業(yè)，并且其中多數(shù)人的研究方向都是：
機器學(xué)習(xí)、數(shù)據(jù)挖掘之類。
此間競爭之激烈，諸如此類，雖未得其皮毛，也略見一斑。
當然，我說這些不是為了打擊大家的信心，而是要指出現(xiàn)在行業(yè)內(nèi)的痛點：AI工程化。
人工智能發(fā)展到現(xiàn)階段，已經(jīng)從實驗室中的算法走向了工程化應(yīng)用的階段。但是算法落地并沒有想象中的順利，開始有越來越多諸如場景碎片化、應(yīng)用成本高、實驗室場景到實際應(yīng)用場景效果差距較大等問題被暴露出來，而這些也成為當前階段AI落地應(yīng)用過程中新的痛點。
領(lǐng)域內(nèi)高水平的paper都是公開發(fā)表的，除了少數(shù)的核心算法，人才濟濟的AI企業(yè)很難在算法性能上與友商拉開距離。那么AI企業(yè)想要商業(yè)化，想要創(chuàng)收，行業(yè)細分領(lǐng)域縱深成了決定成敗的重要因素。需要下沉到業(yè)務(wù)領(lǐng)域，真刀真槍地進行拼殺。
在技術(shù)突破-商業(yè)化-產(chǎn)品化-工程化的階段路線中，除了技術(shù)強，接下來還有很多路要走。誰能夠更好更快地把算法從實驗室中拿出來、賣出去；更好更快地將模型交付到業(yè)務(wù)場景，真正產(chǎn)生實際的價值，讓客戶滿意，誰才能活得更久。
對于Scientist/Researcher而言，技術(shù)可以是一篇論文、一項 ImageNet 競賽的冠軍、也可以是一個重要數(shù)值（比如人臉識別準確率）的突破；但在商務(wù)側(cè)來說，論文與冠軍并不實用，如果技術(shù)無法融進安防、汽車、金融等行業(yè)，變成切切實實的產(chǎn)品，客戶與合作伙伴就會拒絕買單。
對于AI企業(yè)來說，能否深入了解各行業(yè)的業(yè)務(wù)流程、業(yè)務(wù)規(guī)則、知識經(jīng)驗，進而將技術(shù)能力轉(zhuǎn)化為業(yè)務(wù)解決方案創(chuàng)造價值，是發(fā)展的保障。
那么對于我們個人來說，應(yīng)該如何發(fā)展呢？
在《ML/DL科普向：從sklearn到tensorflow》一文中，我們談到：
…… 那么對于我們這些非算法崗位的人來說，就沒有辦法涉及這一領(lǐng)域了么？其實我認為，對于企業(yè)來說，對于AI人才的需求分為兩種：一種是學(xué)術(shù)界的牛人，發(fā)過大paper，有學(xué)術(shù)界比賽的結(jié)果的。公司需要他們?nèi)プ鏊惴ㄑ芯?，保持技術(shù)的領(lǐng)先性，在業(yè)內(nèi)贏得口碑，這樣才能在領(lǐng)域內(nèi)保持頭部領(lǐng)域。另一方面，人工智能早已不是一個概念了，企業(yè)需要把業(yè)務(wù)部門的算法落地的人，能夠快速、穩(wěn)定、高效地把實驗室中的算法落實到生產(chǎn)環(huán)境中，解決實際問題的人。這就需要那些工程底子扎實、能夠?qū)嵈驅(qū)嵉貙懘a，并且對算法模型理解深刻，能夠快速將AI項目工程化、落地有產(chǎn)出的復(fù)合型人才。
還是基于這個觀點，我決定將自身的技能樹偏向企業(yè)需要的第二種人，也就是標題所提出的“AI研發(fā)工程師”。從實際的工程應(yīng)用角度出來，focus人工智能項目落地的全流程以及解決方法，提高自己的AI工程化能力，以此作為個人核心競爭力。
網(wǎng)絡(luò)上很多文章描述的所謂“機器學(xué)習(xí)項目全流程”，例如：數(shù)據(jù)收集處理、特征工程、訓(xùn)練模型、模型測試等等。這套流程對不對？對。但是遠遠不能滿足企業(yè)的需求。
AI項目是團隊創(chuàng)造出的具有商業(yè)價值的產(chǎn)品、服務(wù)以及交付產(chǎn)物。有著明確的需求、計劃、周期、成本、交付流程以及驗收標準。
以下以toB業(yè)務(wù)為例，對AI項目全流程進行簡單梳理。toC業(yè)務(wù)大體如此，只是將客戶替換成公司業(yè)務(wù)方即可。
初步需求溝通確認
該環(huán)節(jié)主要是由銷售、售前完成。了解客戶的基本情況，輔助客戶根據(jù)自身業(yè)務(wù)挖掘AI應(yīng)用場景。根據(jù)實際的業(yè)務(wù)需求、數(shù)據(jù)質(zhì)量、硬件資源、期望產(chǎn)物來評估具體的方案以及建模思路。
POC階段
Proof of Concept。在完成初步的評估之后，團隊需要針對客戶具體應(yīng)用進行驗證性測試，包括確定業(yè)務(wù)場景邊界、業(yè)務(wù)評判指標、數(shù)據(jù)調(diào)研、資源需求、硬件/平臺部署等。
場景方案確認
該環(huán)節(jié)需要售前、科學(xué)家、工程師等多角色與客戶進行細致的場景溝通，明確需求、確定驗收標準、評估工作量。因為該階段結(jié)束后即輸出SOW方案，因此需要反復(fù)溝通商榷。
建模開發(fā)階段
4.1 項目詳細規(guī)劃
項目經(jīng)理根據(jù)前期資料提供詳細的方案設(shè)計、功能清單、資源投入、里程碑安排等內(nèi)容，召開項目啟動會，明確項目內(nèi)容及分工職責。
4.2 數(shù)據(jù)處理
科學(xué)家在明確業(yè)務(wù)場景及需求后，對數(shù)據(jù)處理。其內(nèi)容包括：數(shù)據(jù)質(zhì)量檢查、ETL處理（工作量較大）。還要對清洗后的數(shù)據(jù)進行探索性數(shù)據(jù)分析（Exploratory Data Analysis）以及可視化展示。EDA能夠幫助我們在探索階段初步了解數(shù)據(jù)的結(jié)構(gòu)及特征，甚至發(fā)現(xiàn)一些模式和模型
4.3 特征工程
根據(jù)探索性分析得到的輸出，結(jié)合對具體業(yè)務(wù)的理解，對分散的數(shù)據(jù)拼表并進行特征工程。
4.4 建模
形成初版建模，并對根據(jù)業(yè)務(wù)需求評估標準進行效果驗證。后續(xù)需要不斷進行模型迭代，直到滿足需求，并做模型效果匯報。
4.5 系統(tǒng)研發(fā)
將訓(xùn)練好的模型發(fā)布服務(wù)、部署上線，開發(fā)外圍對接系統(tǒng)以及部分定制化功能的開發(fā)。輸出可運行的系統(tǒng)。
測試上線
對系統(tǒng)進行流程測試、性能測試，滿足需求后對項目進行交付&驗收。
通過對AI項目全流程的介紹，我們將目光瞄準到“建模開發(fā)階段”的“系統(tǒng)研發(fā)”部分。雖然在上面只是一句話帶過，但是其中的工作量和技術(shù)含量不小。
提起機器學(xué)習(xí)，尤其是深度學(xué)習(xí)，大家可能會對諸如Tensorflow，Pytorch，Caffee的工具耳熟能詳。但其實在實際的機器學(xué)習(xí)的生命周期中，訓(xùn)練模型（上述工具主要解決的問題）只是整個機器學(xué)習(xí)生命周期的很小一部分。
數(shù)據(jù)如何準備？如何保證線上線下一致性？模型訓(xùn)練好了如何分布式部署？如何構(gòu)建HA？需要批量處理還是實時處理？實時數(shù)據(jù)如何拼接？如何對模型服務(wù)進行監(jiān)控、告警？做成PaaS還是MLaaS？
機器學(xué)習(xí)具有天然的Pipline特性，在企業(yè)需求中，大大小小的業(yè)務(wù)場景有眾多的模型，這些模型如何進行打包、處理、發(fā)布？離線訓(xùn)練、批量預(yù)估、實施預(yù)估、自學(xué)習(xí)等任務(wù)類型交錯，不同建模工具Sklearn、Tensorflow，Pytorch構(gòu)造的模型如何進行整合？開發(fā)框架Spark ML、Flink ML等如何協(xié)同、對接。生產(chǎn)環(huán)境如何進行擴展和伸縮？如何支持AB Test？
為了解決這些問題，新生的開源框架層出不窮：Google自研的對接Kubernets和Tensorflow的開源平臺Kubeflow；Spark團隊打造的ML pipelines輔助工具MLflow；雅虎提供的機器學(xué)習(xí)及服務(wù)平臺BigML；阿里巴巴推出的分布式機器學(xué)習(xí)平臺SQLflow等等。眾多廠商紛紛發(fā)力，目的就是解決AI工程化應(yīng)用的痛點。
這些工作都是需要一大批工程師去完成。因此，我認為了解AI工程化場景、解決方案；熟悉AI項目流程、機器學(xué)習(xí)Pipline；掌握AI系統(tǒng)研發(fā)、服務(wù)部署上線能力的工程師將會逐漸成為AI團隊的中堅力量。
之前鋪墊了那么多，既是梳理思路，也是為接下來的系列做一個開篇。按照我的初步計劃，技能樹大概包括（不分先后）：
工程能力：
身為工程師首先要有工程能力，springboot/Netty/Thrift/等相關(guān)工具框架一定要掌握，微服務(wù)是機器學(xué)習(xí)平臺的基礎(chǔ)。
Spark SQL、Spark ML等更是大數(shù)據(jù)工程師用來做機器學(xué)習(xí)的利器，不但要掌握、更要從中抽象出流程和處理方法。
容器化：
docker和k8s現(xiàn)在幾乎是機器學(xué)習(xí)部署的必備技能，也是眾多平臺的基礎(chǔ)。
是重要的前置技能。
機器學(xué)習(xí)&深度學(xué)習(xí)：
不要求能夠手推算法、模型優(yōu)化，但要能夠了解含義、上手使用，起碼要成為一名優(yōu)秀的調(diào)包俠（也便于吹水）。
開源框架：
其實我最近打算學(xué)習(xí)kubeflow，并輸出學(xué)習(xí)筆記及總結(jié)實踐。
本文其實是這個系列的開篇。
當然，后續(xù)還有有調(diào)整。
其實這種類型的文章，比單純的學(xué)習(xí)筆記、技術(shù)文章難寫多了。一方面，拖延癥迫使我把難寫的文章放在后面寫，另一方面，強迫癥又迫使我一定要在系列前出一個開篇。其實寫到最后，總覺得核心部分還差點兒意思，沒有搔到癢處，這是因為目前我還沒有能力站在一個全局的角度對職業(yè)技術(shù)體系進行劃分，只能梳理出目前的規(guī)劃和看法。后續(xù)要還需和朋友們進行交流。
有些事情是一定要做的，縱觀一些大牛前輩，無一不是在正確的時候做了正確的事。明確自己的目標，在前進的道路上不斷微調(diào)自己的方向，這樣才能在這個競爭激烈的職業(yè)中生存下去。
接下來會有系列的技術(shù)學(xué)習(xí)筆記，考慮到學(xué)習(xí)的連貫性，前期可能是一些基礎(chǔ)的docker/k8s等系列，后期會研究一些開源框架。技術(shù)文章可能會枯燥乏味，知識點也缺乏新意，但是經(jīng)過自己的整理和實踐，再加上自身的理解感悟，相信會不斷完善自己的知識體系。
聯(lián)系客服
