四化大業(yè)：論算法工程師的自我修養(yǎng)

前言

本文落筆于2021年的1月1日，是我2021年的第一篇文章。本文將根據(jù)我的實(shí)踐經(jīng)驗(yàn)，討論一個算法工程師，如何提升自我修養(yǎng)，由菜鳥小白進(jìn)化為高手。

本文同樣不關(guān)注某個具體算法那樣的“術(shù)”，也不像《推薦算法的"五環(huán)之歌"》講“算法”之道，而是聚集于“算法工程”之道，即如何將算法從紙面落地于實(shí)際項(xiàng)目中。畢竟大家都是工程師出身，做算法的目的，既不是在象牙塔中灌水發(fā)文章，也不是打Kaggle比賽那種"一錘子"買賣。我們做算法的終極目標(biāo)，是要在復(fù)雜的互聯(lián)網(wǎng)工業(yè)環(huán)境中成功落地，能夠取得收益，最重要的，能夠持續(xù)取得收益。否則，掌握再多的NN、FM、Attention，也只不過是紙上談兵罷了。

理論化：扎實(shí)的知識基礎(chǔ)

雖然講工程， 但還是需要對算法的充分理解做基礎(chǔ)。項(xiàng)目開始前，選擇最可能產(chǎn)生收益的算法來實(shí)現(xiàn)，算法遇到問題，找到最可能的原因，這些都需要扎實(shí)的算法理論為后盾。否則，如果你只會將別人口中的知名的算法挨個試一遍，在機(jī)器已經(jīng)開始能夠自動調(diào)參，能自動搜索最優(yōu)網(wǎng)絡(luò)結(jié)構(gòu)的今天，你作為一個工程師的價值在哪里？

體系化+脈絡(luò)化

現(xiàn)在講算法的文章不是太少，而是太多，信息爆炸。每年KDD, SIGIR, CIKM上有那么多中外的王婆一起賣瓜，各種各樣的NN、FM、Attention滿天飛，其中不乏實(shí)打?qū)嵉母韶洠蝗狈皲蹁醯墓嗨模屗惴ㄐ氯藷o所適從。這是因?yàn)檫@些同學(xué)孤立地讀論文，結(jié)果只能是一葉障目，只見樹木，不見森林。輪到自己的項(xiàng)目，選作者來頭最大的、發(fā)布時間最新的來實(shí)現(xiàn)，與“聽小道消息買股票”沒啥區(qū)別。

正確的姿勢應(yīng)該是，梳理一門學(xué)問的脈絡(luò)，構(gòu)建自己的知識體系。只有這樣，才能真正將各篇論文中的觀點(diǎn)融匯貫通。在自己的項(xiàng)目中，采各家之所長，構(gòu)建最適合自己項(xiàng)目的算法。我已經(jīng)在《推薦算法的"五環(huán)之歌"》（https://zhuanlan.zhihu.com/p/336643635）和《無中生有：論推薦算法中的Embedding思想》（https://zhuanlan.zhihu.com/p/320196402）梳理了推薦算法的發(fā)展脈絡(luò)，請感興趣的同學(xué)移步閱讀。

重視基本功

現(xiàn)如今，有些人將各種NN+FM+Attention像搭積木一樣拼來拼去，組成一個全新的網(wǎng)絡(luò)結(jié)構(gòu)，起個古怪的名字，就能夠在KDD, SIGIR, CIKM成功灌水，讓一眾算法新人趨之若鶩。我勸大家，不要沉迷于奇形怪狀的NN結(jié)構(gòu)，千萬不要以為它們是能夠解決你問題的“銀彈”，更不要相信什么“深度學(xué)習(xí)使特征工程過時”這樣的外行話。

像我在《負(fù)樣本為王：評Facebook的向量化召回算法》（https://zhuanlan.zhihu.com/p/165064102）一文中的觀點(diǎn)，“排序是特征的藝術(shù)，召回是樣本的藝術(shù)”，特征工程、樣本選擇這樣的基本功，才值得廣大算法同行重視。否則，喂入的樣本與特征都有問題，garbage in, garbage out，再fancy的NN也不過是沙灘上的城堡。

正確對待細(xì)節(jié)

關(guān)注細(xì)節(jié)

通過面試，我發(fā)現(xiàn)很多人好讀書，但不求甚解。知道很多算法，但一問細(xì)節(jié)都不掌握，孰不知，算法成敗的關(guān)鍵都在細(xì)節(jié)里。隨便舉幾個例子：

• Wide&Deep為什么用了兩個優(yōu)化器分別優(yōu)化Wide側(cè)和Deep側(cè)？
• DSSM中的負(fù)樣本為什么是隨機(jī)采樣得到的，而不用“曝光未點(diǎn)擊”當(dāng)負(fù)樣本？
• 在DNN中加入position bias為什么不能和其他特征一樣喂入DNN底層，而必須通過一個淺層網(wǎng)絡(luò)接入？

細(xì)節(jié)搞清楚了，才算你真正搞明白了一門算法，未來你才能放心使用它。

也不要拘泥于細(xì)節(jié)

要從本質(zhì)上理解算法，而不要形而上學(xué)。比如，Youtube召回模型與雙塔召回模型，前者使用sampled softmax loss，后者使用hinge loss或bpr loss，到底有沒有必要在你的推薦系統(tǒng)中都實(shí)現(xiàn)一遍？我個人的觀點(diǎn)，盡管二者在細(xì)節(jié)上有很多不同，但是它們本質(zhì)上都屬于Pairwise LTR，優(yōu)化目標(biāo)都是讓user embedding與正例item embedding足夠近，而與負(fù)例item embedding距離足夠遠(yuǎn)。因此，沒必要在一個系統(tǒng)中分別實(shí)現(xiàn)，而應(yīng)該合二為一，否則召回結(jié)果高度重合，對大盤指標(biāo)發(fā)揮不了多少作用。

練習(xí)不依賴框架實(shí)現(xiàn)一遍算法

Keras、PyTorch之類的框架，將實(shí)現(xiàn)深度學(xué)習(xí)算法，變成了基本模塊的拼裝，大大降低了實(shí)現(xiàn)難度，但也此同時也使很多同學(xué)固步自封，沒有興趣再去了解算法細(xì)節(jié)。比如，如果你調(diào)用TensorFlow自帶DNNLinearCombinedClassifier來實(shí)現(xiàn)Wide&Deep，你能想到如何實(shí)現(xiàn)用兩個優(yōu)化器分布優(yōu)化Wide側(cè)與Deep側(cè)嗎？

掌握算法細(xì)節(jié)最徹底的方式，莫過于不借助高級框架，自己動手從頭實(shí)現(xiàn)一遍。在實(shí)現(xiàn)過程中，除了要保證準(zhǔn)確無誤，還要考慮程序的運(yùn)行效率。

如果時間不允許，看看別人是如何從頭實(shí)現(xiàn)的，對提升自己的算法功力，也大有裨益。對Wide&Deep實(shí)現(xiàn)細(xì)節(jié)感興趣的同學(xué)，可以看我的另一遍文章《用NumPy手工打造 Wide & Deep》（https://zhuanlan.zhihu.com/p/53110408）。對FM感興趣的同學(xué)，強(qiáng)烈建議通讀一遍alphaFM（https://github.com/CastellanZhang/alphaFM）的源代碼。

規(guī)范化：寫得一手好代碼

算法落地的痛點(diǎn)

鏈條太長

落地一個算法，需要經(jīng)過“文獻(xiàn)調(diào)研→算法選型→收集樣本→特征工程→模型編碼→離線測試→線上AB實(shí)驗(yàn)”這漫長的鏈條，線上AB測試起碼要一周以上，得出的結(jié)論才solid。全新算法的落地，花費(fèi)的時間以月計，牽扯算法、工程多方人員的配合。不到最后一刻，我們都不知道算法的成敗，但是無論哪個環(huán)節(jié)出錯，都可能導(dǎo)致算法落地功虧一簣。

不容易debug

如前所述，算法落地的中間環(huán)節(jié)太多，每個環(huán)節(jié)都可能出問題

• 一開始選擇的算法，可能壓根就不合適你們的場景
• 有臟數(shù)據(jù)。但是線上數(shù)據(jù)存在個別臟數(shù)據(jù)，再正常不過了。況且，在幾T的數(shù)據(jù)中查找?guī)浊l臟數(shù)據(jù)，無異于大海撈針
• 算法實(shí)現(xiàn)有bug
• 超參不合適。當(dāng)算法沒效果時，很多算法同學(xué)不愿相信數(shù)據(jù)或模型有問題，覺得只要調(diào)調(diào)超參就能fix，但是大多數(shù)時候，這種想法不過一相情愿罷了。

而最困難的地方在于，你有可能壓根就察覺不出問題。線上AB測試有了正向效果，大家就覺得功德圓滿了，可以開心寫工作總結(jié)了。但是孰不知，代碼依然有bug，修正后，線上指標(biāo)會有更明顯的提升。

解決痛點(diǎn)要靠“防患于未然”

既然算法項(xiàng)目不好debug，就盡量不要出bug。就好比，二戰(zhàn)中德國空軍涌現(xiàn)出各參戰(zhàn)國中最多的王牌飛行員，好幾位的擊落戰(zhàn)績過百，但是二戰(zhàn)德國空軍談不上是最優(yōu)秀的空軍。我個人最欣賞的是以色列空軍，“猶太長臂”追求的是，戰(zhàn)端一開，就把敵人的飛機(jī)都擊毀在地面，使其壓根沒有升空的機(jī)會。

如何才能做到少出、不出bug？一要靠良好的編程習(xí)慣，二要靠小心謹(jǐn)慎的態(tài)度。

良好的編程習(xí)慣

良好的編程習(xí)慣和你刷過多少leetcode題沒關(guān)系。而且就個人感受而言，前者要比后者更重要。因?yàn)椋谌粘Ｋ惴ň幊坦ぷ髦校覀兒苌儆玫蒙蟣eetcode的解題思路，但是良好的編程習(xí)慣卻貫穿碼農(nóng)生涯的始終。

良好的編程習(xí)慣，說來也不復(fù)雜，無外乎就那么幾條

• 花點(diǎn)心思在命名上，給類、函數(shù)、變量起個“見名知義”的好名字。
• 模塊化。不要一個功能，從頭寫到尾，寫成一個幾百行的大函數(shù)。而要將其拆分成其他函數(shù)或類。
• 注意代碼復(fù)用，最忌諱拷貝代碼。
• 開閉原則，代碼模塊應(yīng)該對擴(kuò)展開放，而對修改封閉。
• 單一職責(zé)原則，每個代碼模塊只負(fù)責(zé)單一功能，不要將雜七雜八的功能都寫到一個類或函數(shù)中。

看似簡單，但是這些習(xí)慣能夠使你的代碼清晰、易讀。而易讀的代碼容易發(fā)現(xiàn)問題。但是，這幾條規(guī)則，知易行難，做不到的人，歸根到底還是一個“懶”字。

另外，我強(qiáng)烈建議，限制使用jupyter notebook。可能是受許多公開課的影響，很多人喜歡在notebook中寫程序、調(diào)模型，畢竟jupyter notebook能夠邊寫代碼，邊運(yùn)行查看結(jié)果，再加上圖表可視化，功能上的確很有吸引力。

但是，在notebook寫代碼，完全沒有條理，想到哪里，寫到哪里，你不會想到要劃分函數(shù)或類。另外，在notebook中非常容易就使用了全局變量，使你的代碼變成緊密耦合的意大利肉醬面。notebook的底層存儲格式，將算法邏輯代碼與頁面渲染代碼，雜揉一處，使版本控制失去了作用。因此，我對jupyter notebook的態(tài)度就是草稿紙，做一些前期的數(shù)據(jù)探索性分析還可以，實(shí)戰(zhàn)代碼免談。

小心謹(jǐn)慎的態(tài)度

我寫代碼，一來寫的時候，就小心遵循著以上那些良好的編程習(xí)慣，保持代碼清晰、易讀。小心到什么程度？比如，我將向量命名為user_embedding/doc_embedding，而不是embedding_user/embedding_doc。這是因?yàn)楝F(xiàn)在的IDE都有代碼自動提示功能，如果采用將共同部分作為名字的前綴，我擔(dān)心要用到embedding_user的地方，當(dāng)我輸入embedding前綴時，IDE就自動提示embedding_doc，而我不小心一回車，就張冠李戴，犯下錯誤。

第二，寫完代碼后，不著急吼吼地就接入數(shù)據(jù)，開始訓(xùn)練，我起碼要將代碼檢查上兩遍。檢查時，要設(shè)想各種corner case，比如各種可能的臟數(shù)據(jù)。而以前Quora上有一個問題就是“算法工程師在等待模型的訓(xùn)練結(jié)果時做什么？”，而我會利用那段時間，再次檢查我的代碼。

總而言之，就是我們在開發(fā)算法代碼時，要小心、小心、再小心。因?yàn)槊總€環(huán)節(jié)犯下的bug，都有可能導(dǎo)致算法落地失敗，使你和團(tuán)隊投入的時間精力付之東流。更可怕的是，由于大數(shù)據(jù)+黑盒模型的雙重影響，你犯下的bug會非常非常難于被發(fā)現(xiàn)。

數(shù)字化：構(gòu)建模型的指標(biāo)看板

現(xiàn)如今，深度學(xué)習(xí)大行其道，在帶來模型性能提升的同時，也使模型愈發(fā)“黑盒”化，使之不容易調(diào)優(yōu)，出現(xiàn)問題，也不好定位原因。

面對模型黑盒，打開它是一種思路。學(xué)術(shù)界提出很多特征解釋算法，但是受限于這些算法的復(fù)雜度，在工業(yè)界落地的并不多。另一種思路就是，沒必要打開黑盒，只要對模型的輸入輸出長期監(jiān)控，通過歷史數(shù)據(jù)的積累，也能對模型的行為建立合理的預(yù)期。一旦模型出現(xiàn)異常，我們也能夠很快發(fā)現(xiàn)并定位原因。本小節(jié)就是介紹如何實(shí)現(xiàn)這第2種思路。

接下來所說的指標(biāo)分兩種，輸入模型的的上游數(shù)據(jù)的指標(biāo)，和模型的離線評測指標(biāo)，不包括線上業(yè)務(wù)指標(biāo)。這是因?yàn)椋谝唬€上指標(biāo)受其他非模型因素（e.g., 節(jié)假日或運(yùn)營）的影響比較大；第二，線上業(yè)務(wù)指標(biāo)會有專門的人員與工具去分析；第三，線上指標(biāo)已經(jīng)是target了，它出了問題只能告訴我們模型可能出了問題，但是對于定位問題還遠(yuǎn)遠(yuǎn)不夠。

重視離線評測指標(biāo)

我認(rèn)識一個有幾年工作經(jīng)驗(yàn)的老菜鳥 （這才是最可悲的），團(tuán)隊分配他去做一個召回模型，很快跑出模型，離線AUC還可以（這就是理論水平不足埋下的隱患，用AUC是照搬排序時的經(jīng)驗(yàn)，而召回模型因?yàn)闆]有真負(fù)樣本，很少用AUC評價），加上team leader是個工程出身，對算法一知半解，就批準(zhǔn)他上線。接下來幾個星期，他就只知道催工程同學(xué)幫他上線模型。終于上線了，第一天的線上指標(biāo)就不好，他選擇繼續(xù)觀察，同時嘗試不同的超參來撞大運(yùn)。觀察了一個多月，線上指標(biāo)不升反降，他又去懷疑是工程實(shí)現(xiàn)有問題，又去懷疑是ranker打壓了新召回。最后實(shí)在搞不定，找我?guī)兔ΑＮ夷梦易灾频恼倩胤治瞿_本一跑，召回的東西與用戶興趣與歷史，驢唇不對馬嘴，模型本身就有嚴(yán)重問題，換我是他的team leader，壓根就不會批準(zhǔn)他上線，浪費(fèi)大家的時間與精力。

這個案例留給我們的教訓(xùn)就是，線上AB實(shí)驗(yàn)的代價太高了

• 一方面，現(xiàn)在的模型越來越復(fù)雜，很多時候，上線需要花費(fèi)工程同學(xué)的時間與精力，來保證線上服務(wù)的實(shí)時性能。更不用說，再小的流量也會影響用戶體驗(yàn)。所以，如果你什么樣的模型都只能靠上線來一試效果，最終耗費(fèi)的團(tuán)隊對你的耐心與信任。
• 另一方面，線上AB實(shí)驗(yàn)的耗時太長，為了得到solid的實(shí)驗(yàn)結(jié)果，最起碼要進(jìn)行一周，而且線上指標(biāo)受非模型因素（e.g.,運(yùn)營）的影響也比較大。所以，線上實(shí)驗(yàn)對模型效果的反饋慢又有噪聲，一點(diǎn)也不“敏捷”。

所以，我們一定要重視模型的離線指標(biāo)，盡可能在上線前發(fā)現(xiàn)模型可能存在的問題

• 看論文的時候，指標(biāo)的具體數(shù)值可看可不看，反正都是王婆賣瓜，自賣自夸。但是，一定要看離線實(shí)驗(yàn)的設(shè)計，看作者是怎么無偏地收集測試樣本，看作者從哪些維度來評測模型（不是只有準(zhǔn)確性，還比如：推薦結(jié)果的豐富性、對冷啟是否友好、......等），看作者用了哪些指標(biāo)來衡量模型在各個維度上的性能，看作者如何設(shè)計圖表使模型性能一目了然。
• 另一方面， 指標(biāo)有時是片面的（比如，召回算法都只召回?zé)衢Titem, 指標(biāo)未必很差），這時候人工評測模型，雖然土，但是也能發(fā)揮效果。比如，我就自制了一個工具來幫助我評測召回模型，采樣1000個用戶，把每個用戶的畫像與點(diǎn)擊歷史展示在左邊，把模型召回的item展示在右邊。這個工具能讓我對召回效果具備最直觀的認(rèn)識，比如：召回結(jié)果是不是太偏熱門，而缺乏個性化？召回結(jié)果是不是只集中于用戶的個別興趣，對用戶興趣的覆蓋面太窄？

指標(biāo)監(jiān)控看板

運(yùn)維有指標(biāo)看板來監(jiān)控機(jī)群性能，算法也需要有自己的指標(biāo)看板來監(jiān)控模型的性能。

• 我們要監(jiān)控上游的輸入數(shù)據(jù)，比如：每小時有多少樣本流入模型？樣本中的CTR和平均時長是多少？樣本中有多少user/doc/feature？feature經(jīng)過hash后的沖突率是多少？……
• 離線評測不是只在上線之前做一次就完事了，而是也需要周期性運(yùn)行，與同時段的上游輸入數(shù)據(jù)的指標(biāo)相對比，才能讓我們對模型建立合理預(yù)期，將來定位問題時用得上。常見的監(jiān)控指標(biāo)包括，auc/precision/recall等，另外還包括“今天的embedding相較于昨天embedding的變化幅度”這樣的對比指標(biāo)。

舉個例子來說明，指標(biāo)監(jiān)控在定位模型問題時發(fā)揮的重大作用。我們算法工程師的噩夢之一就是，之前好好的模型，線上指標(biāo)（突然或緩慢）掉下來了。有一天，我就遇到了這樣的名場面。借助指標(biāo)看板，

• 首先，我發(fā)現(xiàn)模型的離線指標(biāo)也掉下來了，說明與線上工程實(shí)現(xiàn)或外界環(huán)境無關(guān)，應(yīng)該是模型本身出問題了
• 接著，我發(fā)現(xiàn)輸入模型的樣本中的ctr下降了，說明上游數(shù)據(jù)出問題了
• 詢問了負(fù)責(zé)上游數(shù)據(jù)的同學(xué)，發(fā)現(xiàn)他們縮短了等待用戶反饋的時間，導(dǎo)致一部分正樣本由于未能等到用戶反饋被當(dāng)成負(fù)樣本，從而定位了問題

看我的輕描淡寫，是不是感覺我解決這個問題超easy。實(shí)際情況恰恰相反，當(dāng)時我還沒有構(gòu)建出針對模型的指標(biāo)看板，模型的離線指標(biāo)和輸入樣本的CTR都是我遇到問題后再手工回溯的，花費(fèi)了一兩天才定位問題。吃一塹，長一智，經(jīng)此一役，我才充分認(rèn)識到模型指標(biāo)看板的重要性，現(xiàn)如今它成為了我團(tuán)隊每個算法工程師的標(biāo)配。

自動化：優(yōu)秀的工程師造工具

算法工作畢竟是實(shí)驗(yàn)科學(xué)，所以成功的關(guān)鍵是高效做實(shí)驗(yàn)（由于線上容量有限，所以下文所說的實(shí)驗(yàn)，主要指離線實(shí)驗(yàn)）

• 談到高效，我們的第一反應(yīng)是快。單位時間能做的實(shí)驗(yàn)越多，嘗試的方向（不同特征+不同模型+不同超參）越多，越可能找到最優(yōu)解。為了能夠快速實(shí)驗(yàn)，首先，實(shí)驗(yàn)的代價必須小，為了新實(shí)驗(yàn)要修改代碼是不可接受的，最好是修改一下配置，然后一鍵啟動；第二，能夠并行跑多組實(shí)驗(yàn)，充分發(fā)揮算力，這就要求各實(shí)驗(yàn)之間完全解耦，比如不會向同一個路徑下寫入結(jié)果。

• 但是，快只是高效的一個方面，能做的實(shí)驗(yàn)多了，實(shí)驗(yàn)管理就成了問題。

• 每個實(shí)驗(yàn)，我們都要記錄：特征的版本、模型的版本、超參的版本、用哪段時間的數(shù)據(jù)訓(xùn)練的、在哪段時間上測試的、各種離線指標(biāo)、......
• 跑幾十、上百個離線實(shí)驗(yàn)非常常見，這么多實(shí)驗(yàn)數(shù)據(jù)，如果缺乏管理，也就無從分析比較，無法得到正確結(jié)論，實(shí)驗(yàn)等于白做
• 手動管理，比如把實(shí)驗(yàn)數(shù)據(jù)記錄在excel里，也不是不可以，估計也是大多數(shù)算法同行的選擇。但是，一來人懶，特別是模型結(jié)果不好的時候，更沒心情做記錄了；二來，實(shí)驗(yàn)數(shù)據(jù)一般在服務(wù)器上，而excel在本地筆記本上，記錄時不得不ctrl-c/ctrl-v，出錯在所難免
• 因此，我們需要一個類似Source Version Control的工具，自動將實(shí)驗(yàn)數(shù)據(jù)管理起來。

實(shí)驗(yàn)管理工具

這個實(shí)驗(yàn)管理工具，應(yīng)該具備什么樣的功能？

• 我們下班前配置好要進(jìn)行的實(shí)驗(yàn)，然后一鍵啟動實(shí)驗(yàn)
• 實(shí)驗(yàn)管理系統(tǒng)，自動向后臺機(jī)群提交多組實(shí)驗(yàn)，多組實(shí)驗(yàn)并行運(yùn)行
• 每組實(shí)驗(yàn)結(jié)束后，自動記錄實(shí)驗(yàn)版本和結(jié)果
• 明早到了辦公室，打開電腦，昨天實(shí)驗(yàn)的各種報表、曲線已經(jīng)ready了

我在Youtube上看過一個Yelp工程師的介紹，聽說Yelp的實(shí)驗(yàn)管理系統(tǒng)不僅具備以上功能，而且每個實(shí)驗(yàn)結(jié)束后，還能向?qū)嶒?yàn)發(fā)起人發(fā)一封郵件，郵件里有完整的實(shí)驗(yàn)報告，包含圖表與曲線。實(shí)驗(yàn)發(fā)起人用新參數(shù)回一封郵件，后臺服務(wù)器收到郵件后，就會用新超參數(shù)開啟下一輪實(shí)驗(yàn)。

網(wǎng)上有一些開源的實(shí)驗(yàn)管理工具，但是

• 一來，浸入式太強(qiáng)，需要我們修改代碼，削足適履地適應(yīng)那套框架；
• 二來，運(yùn)維也不可能允許你在公共機(jī)群內(nèi)安裝一大堆亂七八糟的第三方框架

因此，我自己動手寫一個簡單的實(shí)驗(yàn)管理工具

• 實(shí)驗(yàn)是高度配置的，調(diào)節(jié)使用特征、調(diào)節(jié)網(wǎng)絡(luò)結(jié)構(gòu)、調(diào)節(jié)超參數(shù)、......，都通過配置完成，而無需修改代碼
• 實(shí)驗(yàn)一鍵啟動，各環(huán)節(jié)自動跨平臺銜接（數(shù)據(jù)準(zhǔn)備在Spark集群完成，模型在分布式訓(xùn)練集群完成訓(xùn)練與評估），并具備一定容錯能力
• 多組實(shí)驗(yàn)可以并行進(jìn)行，而一個實(shí)驗(yàn)內(nèi)部“數(shù)據(jù)準(zhǔn)備”與“訓(xùn)練模型”異步進(jìn)行，以減少等待

雖然前期投入時間多一些，但是有了實(shí)驗(yàn)工具的幫助， 我團(tuán)隊的實(shí)驗(yàn)效率大大提高。目前，我們正在朝著Yelp那套工具的方向邁進(jìn)，已經(jīng)隱約看到了“邊吃著火鍋，唱著歌，邊調(diào)模型”的美好未來。

利用工具+制造工具

實(shí)驗(yàn)管理工具只是一個例子。事實(shí)上，對待工具的態(tài)度，是小白與高手的區(qū)別之一：

• 小白的每個模型都是匠人手工版：為了新實(shí)驗(yàn)，要手動改一堆代碼，要手動ctrl-c/ctrl-v記錄結(jié)果，為了等實(shí)驗(yàn)結(jié)果不敢下班，......
• 高手善于利用工具，制造工具。為了每天節(jié)省5分鐘，他寧可花兩天時間造個工具。每天到點(diǎn)下班，吃著火鍋，唱著歌，等著實(shí)驗(yàn)結(jié)果曲線發(fā)到手機(jī)上。

總結(jié)

本文講述的，并非于某個具體算法的那樣的“技”，而是聚集于“算法工程”之道，從“理論化+規(guī)范化+數(shù)字化+自動化”四個方面提出了方法論，根據(jù)我的實(shí)戰(zhàn)經(jīng)驗(yàn)，討論了如何將算法從紙面落地于一個互聯(lián)網(wǎng)級別的實(shí)際系統(tǒng)中，從而為你老板和你創(chuàng)造價值。

本文落筆于2021年的1月1日，是我本人在2021年的第一篇文章。請無處不在的互聯(lián)網(wǎng)記錄下我的新年心愿：希望我和我愛的人在2021年平安順?biāo)欤?/strong>

- END -