本文轉(zhuǎn)載自公眾號(hào)“讀芯術(shù)”(ID：AI_Discovery)

筆者去初創(chuàng)公司工作主要是為了做項(xiàng)目，所以盡管任務(wù)緊急、團(tuán)隊(duì)又小，還伴隨著頻繁改動(dòng)的項(xiàng)目要求以及其它瑣事，筆者還是去了。不走運(yùn)的是，筆者作為一名機(jī)器學(xué)習(xí)工程師著手的第一份項(xiàng)目并不那么容易上手。

[[360184]]

那是一個(gè)大項(xiàng)目，背后有個(gè)大客戶，意味著要擔(dān)很大的責(zé)任，但是卻只有一個(gè)小團(tuán)隊(duì)負(fù)責(zé)此項(xiàng)目，團(tuán)隊(duì)其中一員就是筆者這個(gè)新手。項(xiàng)目負(fù)責(zé)人安排筆者去處理十二個(gè)模型的那一天，光是想想都心有余悸。更糟糕的是，當(dāng)筆者團(tuán)隊(duì)中的一個(gè)人被調(diào)去另一個(gè)項(xiàng)目時(shí)，他的工作量落到了筆者頭上。

但筆者不是來向你們傾吐苦水的。盡管這個(gè)過程頗為曲折，但是也讓筆者收獲了很多意料之外的經(jīng)驗(yàn)。

不斷研究

筆者犯過最大的一個(gè)錯(cuò)誤就是僅僅因?yàn)槟撤N方法最適合一些特定的數(shù)據(jù)，就用這一種方法去處理所有數(shù)據(jù)。換句話說，筆者僅在項(xiàng)目伊始做了一個(gè)試驗(yàn)。在找到捷徑以后，即使數(shù)據(jù)增長的越來越大，筆者依然堅(jiān)持使用那一種方法。

筆者認(rèn)為那是當(dāng)時(shí)最有效的方法。然而作為一名機(jī)器學(xué)習(xí)工程師，不僅要建構(gòu)一個(gè)系統(tǒng)，還要持續(xù)不斷地提升它的性能。筆者花了一個(gè)月的時(shí)間才接受這一事實(shí)。

筆者的前任主管曾說，機(jī)器學(xué)習(xí)工程師既是軟件工程師也是研究員。研究和軟件工程可不一樣。就算系統(tǒng)已經(jīng)構(gòu)建成功且沒有bug，研究也不會(huì)就此止步。研究是一個(gè)永無止境的過程，只要睜大雙眼，總會(huì)發(fā)現(xiàn)可以嘗試的新事物。

不要在模型學(xué)習(xí)的時(shí)候無所事事

“模型運(yùn)行著吶!就讓我休息一會(huì)兒吧!”隨著數(shù)據(jù)增長的越來越大，使用的方法也變得越來越復(fù)雜。一個(gè)完整的訓(xùn)練過程可以達(dá)到2至3小時(shí)。

當(dāng)程序運(yùn)行的時(shí)候，筆者常常借此拖延工作，現(xiàn)在我無比悔恨。有好幾次都出現(xiàn)了意外，比如運(yùn)行進(jìn)程接近尾聲的時(shí)候出現(xiàn)了程序錯(cuò)誤、得分比之前更低了、內(nèi)存錯(cuò)誤以及其它在快結(jié)束時(shí)才意識(shí)到的愚蠢失誤。

在模型學(xué)習(xí)的這段時(shí)間，明明可以做許多有意義的事情。

可以提前計(jì)劃工作步驟。一個(gè)程序開始成功運(yùn)行后，就用不同的方法著手下一個(gè)程序。等第一個(gè)程序運(yùn)行完畢，另一個(gè)程序就可以開始運(yùn)行了。在新程序運(yùn)行的時(shí)候，則可以評(píng)估分析前一個(gè)程序運(yùn)行的結(jié)果。所以如果發(fā)現(xiàn)前一個(gè)模型的任何可改進(jìn)之處，就可以立即修正然后重新運(yùn)行。

這個(gè)時(shí)間用來和主管或者其它工程師討論新方法、新點(diǎn)子也是極好的?？傊灰速M(fèi)時(shí)間。

做出明智的選擇

某些情況下，不同的方法得出的結(jié)果差別可能不是那么明顯。產(chǎn)出的成果相較其它方法的成果稍微優(yōu)秀一點(diǎn)，這樣的方法是不是就足夠好到成為最終選擇了?不是。許多因素都應(yīng)該被考慮在內(nèi)。分析的過程不僅僅是從一個(gè)單一的角度找出最佳方法，分析是一個(gè)細(xì)水長流的過程。

例如，假設(shè)有兩個(gè)垃圾郵件分類模型，它們的F1值分別為0.95和0.96。第二個(gè)模型的精確率很低，召回率卻很高，而第一個(gè)模型的精確率和召回率則比較平衡。

在這種情況下，第一個(gè)模型比第二個(gè)更好，因?yàn)樗芨玫靥幚砝]件分類。第二個(gè)模型更容易把將普通文檔歸類為垃圾郵件，這樣就會(huì)有更多的非垃圾郵件文檔將被劃為垃圾郵件，這非常糟糕。

其他需要考慮的是與產(chǎn)出有關(guān)的重要事宜。某些情況下，如果資源和時(shí)間有限，選擇一個(gè)簡便的模型會(huì)助你一臂之力。前提是模型的性能仍然良好，并且與較復(fù)雜的模型沒有太大區(qū)別。

切莫混淆數(shù)據(jù)

數(shù)據(jù)顯然是影響模型性能的重中之重。因此，在項(xiàng)目執(zhí)行之初就必須一絲不茍地建立一個(gè)詳備的數(shù)據(jù)集，包括需要提取的信息類型、注釋指南、各個(gè)數(shù)據(jù)類別之間的平衡以及視需求而定的其它重要事項(xiàng)。

如果使用標(biāo)注工具(annotator)來構(gòu)建數(shù)據(jù)集，特別是對于NLP模型，則要確保技術(shù)和語言學(xué)兩方面認(rèn)知的同步。有時(shí)候，語言學(xué)人員不明白某個(gè)特定的標(biāo)注方法對現(xiàn)有的模型是否可行。同樣地，工程師有時(shí)候也不理解語言學(xué)的內(nèi)容。

需要注意的是，并不是數(shù)據(jù)越多越好。如果不能有效地反映所有的真實(shí)情況，再多的數(shù)據(jù)訓(xùn)練也是白費(fèi)功勞。除此之外，數(shù)據(jù)標(biāo)簽的不一致也是個(gè)大問題。

另外，每次實(shí)驗(yàn)，訓(xùn)練、驗(yàn)證以及測試數(shù)據(jù)的結(jié)構(gòu)和比例必須相同，特別是當(dāng)數(shù)據(jù)逐漸增多時(shí)。為了確保模型的性能，還必須考慮案例類型的分布。如果有專門的測試數(shù)據(jù)再好不過，這有助于添加訓(xùn)練數(shù)據(jù)后比較模型性能。

把步驟銜接起來

能夠構(gòu)建端到端系統(tǒng)是作為機(jī)器學(xué)習(xí)工程師必備的另一項(xiàng)重要技能。更重要的是，如果同時(shí)處理多個(gè)模型，那么使用管線(pipeline)會(huì)方便很多。加載數(shù)據(jù)集、預(yù)處理和特征提取、訓(xùn)練和評(píng)估模型，以及做出預(yù)測都可以簡化到只使用單個(gè)指令。

不要指望一次就能得到滿意的結(jié)果。此外，長時(shí)間重復(fù)做某事確實(shí)會(huì)有壓力。因此，使機(jī)器學(xué)習(xí)工作流程自動(dòng)化非常重要，這樣能節(jié)省時(shí)間、減輕壓力。

其他框架和工具

筆者也會(huì)因?yàn)槌霈F(xiàn)錯(cuò)誤而大呼小叫。在把系統(tǒng)部署到生產(chǎn)環(huán)境這一步驟出錯(cuò)后，筆者再一次陷入懊惱。因此，了解一些可用于部署的實(shí)用框架和有效工具十分有必要。可以把一些接觸過的框架和工具拿來做個(gè)比較，再根據(jù)需要選出最適合的。

對于筆者來說，Docker在部署中非常重要。它幫助筆者在容器中部署多個(gè)模塊。除此之外，Tensorflow Serving也非常好用，它可以很方便地使訓(xùn)練好的模型應(yīng)用于預(yù)測請求。

使人人都可以理解

寫文檔不僅是為了自己，也是為了他人。如果其他工程師想要繼續(xù)試驗(yàn)，或者只是想使用你的程序，你創(chuàng)建的文檔都能幫上他們。如果文檔也方便專業(yè)之外的人員閱讀和理解，那就更好了。

一份好的文檔通常包含超參數(shù)(hyperparameter)的配置、時(shí)期(epoch)、方法、數(shù)據(jù)和分?jǐn)?shù)等信息。此外，提供自動(dòng)化的腳本來運(yùn)行程序?qū)ζ渌こ處熀苡袔椭@樣就不必先閱讀整個(gè)代碼了。

誠然，筆者還有許多東西需要學(xué)習(xí)。但最應(yīng)該明白的是，不要害怕失敗。因?yàn)檠芯亢驮囼?yàn)本身就是一個(gè)嘗試、失敗、再嘗試的過程。