作為一名算法工程師，主要是想把自己模型調(diào)優(yōu)和復(fù)現(xiàn)算法遇到的一些坑總結(jié)一下（里面的一行字可能是我當(dāng)時花費了一周甚至更長時間得到的總結(jié)），希望能對讀者有所幫助。

一、熟悉數(shù)據(jù)

模型是數(shù)據(jù)的濃縮版----Andrew NG的二八定律，即80%的數(shù)據(jù)+20%的=更好的AI

對于新上手的一任務(wù)來說，需要熟悉你的數(shù)據(jù)。拿檢測任務(wù)來說，可以寫個可視化代碼查看標(biāo)注是否合理，查看一下待檢測物體的大小分布情況（例如anchor的預(yù)設(shè)），查看一下圖片大小，查看類別分布情況（例如是否有極端的分布）等等。

二、算法選型

在接到一個新領(lǐng)域的新任務(wù)時，需要調(diào)研相關(guān)領(lǐng)域算法，對該領(lǐng)域的發(fā)展有個大概的了解，掌握一些關(guān)鍵算法（比如歷年的SOTA）的思路。雖然調(diào)研需要花費一些時間，但是這樣在算法選型上可以少做一些實驗，性價比是很高的。站在他們的肩膀上就好了。

不太可取的思路：

在指標(biāo)上太鉆牛角尖。有些算法工程師遇到指標(biāo)在自己數(shù)據(jù)集效果不太好的情況時，立馬換別的算法，或者立馬換個backbone，或者立馬換個loss去做實驗。（需要認真分析為什么效果不好，是自己訓(xùn)練有問題，還是當(dāng)前數(shù)據(jù)不太適合該算法，是評測指標(biāo)不合理，還是評測指標(biāo)實現(xiàn)有問題。）

不進行相關(guān)調(diào)研，直接上SOTA算法。這樣做會有一些不太理想的問題，比如SOTA可能沒有針對自己場景的數(shù)據(jù)做優(yōu)化，比如當(dāng)前任務(wù)是小目標(biāo)居多（通過分析數(shù)據(jù)得到），雖然SOTA的總的mAP很高，但是small mAP比之前算法還低，那就要慎用 。比如SOTA用的是很重的網(wǎng)絡(luò)，但是任務(wù)是速度快，或者速度與效果兼顧，那也應(yīng)該慎用。

三、基于已有實現(xiàn)來優(yōu)化算法

對于某個任務(wù)在選擇好合適的算法以后，如果有相應(yīng)的效果比較好的開源實現(xiàn)，最好用開源項目進行算法的復(fù)現(xiàn)。

這樣做的目的：

更方便深入的理解算法的具體細節(jié)，比如可能代碼在文章沒有提到的某些層上偷摸的加了一個shift操作，比如文章提到的一些trick代碼根本沒有實現(xiàn)，比如代碼用了額外的數(shù)據(jù)訓(xùn)練但文章沒有提到，比如文章描述的數(shù)據(jù)增強方式與代碼的實現(xiàn)不一樣等。（這些可能發(fā)生在開源復(fù)現(xiàn)者沒有“一比一”復(fù)現(xiàn)論文的情況，也可能發(fā)生在論文作者自己沒有實現(xiàn)的情況）

能快速掌握算法的基礎(chǔ)性能，比如復(fù)現(xiàn)算法大概的運行速度（特別是文章沒給出的時候）和達到的效果

不用自己做一些無用功。要知道重寫和調(diào)試一份新的模型不僅費時費力，可能還因為文章沒有寫清楚一些細節(jié)，導(dǎo)致你幾乎無法復(fù)現(xiàn)到相應(yīng)的結(jié)果。

利用開源項目已復(fù)現(xiàn)的算法（這里復(fù)現(xiàn)不是完全能與代碼作者或者文章作者結(jié)果一致，可能是數(shù)據(jù)增強，隨機種子導(dǎo)致結(jié)果有偏差，但已獲取到八九不離十的結(jié)果）來改進模型可以有下面幾點思路：

代碼是否實現(xiàn)了文章一些漲點的trick，如果沒有可以嘗試

文章一般會分析實驗結(jié)果，后面會有作者自己的一些觀點，他們可能會說明為什么有些情況文章的算法效果較差

有些文章會寫他們將來可能的工作，這也是一個改進思路

需要可視化查看實驗結(jié)果（特別是跑自己的數(shù)據(jù)集），結(jié)果可能與作者在公開數(shù)據(jù)集展示出的問題不一樣，分析效果差的原因

四、從0復(fù)現(xiàn)算法

復(fù)現(xiàn)算法是一個比較大的工程，這里的大工程不只是指代碼多或者工作量大，而是沒有一個基礎(chǔ)版，導(dǎo)致引入的不可控因素太多調(diào)試困難，比如數(shù)據(jù)接口是否有問題，模型是否搭建正確，訓(xùn)練方式是否存在問題。

在復(fù)現(xiàn)算法或者優(yōu)化算法是比較頭疼的是一切訓(xùn)練正常，loss曲線比你想象的還好看，訓(xùn)練了一年后（just kidding， maybe longer），測試一下發(fā)現(xiàn)效果奇差無比，都不好意思說是自己寫的代碼。一年就過去了。

這里有下面一些建議：

盡量測試每一個細節(jié)，從數(shù)據(jù)接口，模型，到loss輸出，到最終的評測代碼。保證每個部分都可控。

測試數(shù)據(jù)接口，從單進程，batch為1開始，方便打印數(shù)值進行對比。

不要隨意的去隨機，盡量保證問題可以復(fù)現(xiàn)比如先不要加入隨機數(shù)據(jù)增強，模型的隨機種子固定。

用少量的數(shù)據(jù)，這樣可以快速的做實驗，也可以讓模型快速過擬合。模型能過擬合可以大概確定模型是可以學(xué)到點什么的。

盡量按照原文來復(fù)現(xiàn)，在復(fù)現(xiàn)前，先不要過多的添加自己獨特的想法。比如訓(xùn)練參數(shù)，模型backbone，數(shù)據(jù)增強方式等等先按照文章來。不清楚的點可以嘗試email作者或者尋找相關(guān)圈子討論。

日志打印全，比如解loss為nan的情況，需要知道是forward的導(dǎo)致還是bp導(dǎo)致。

五、一些或許有用的訓(xùn)練建議

保證數(shù)據(jù)是可靠的

有預(yù)訓(xùn)練模型最好用上

通常學(xué)習(xí)率參數(shù)小于1e-5基本沒啥用了，比如cosine或者step操作，最后的學(xué)習(xí)率到1e-5就好了。當(dāng)然特殊任務(wù)不一樣

bn在訓(xùn)練時記得打開更新（特別是tf的小伙伴，容易漏），不然可能出現(xiàn)的問題是訓(xùn)練時loss下降很快，測試感覺模型就沒收斂

sgd是很棒的，但是實驗用adam或許收斂速度更好

如果想要很好的壓榨出一個算法的性能，請先保證當(dāng)前模型能到達相應(yīng)的性能再去壓榨。而不是盲目的換模塊，瘋狂調(diào)參，那樣可能只是浪費時間

不要太相信自己的調(diào)參技術(shù)，在沒有一個較好的baseline情況下，調(diào)參不會有質(zhì)的飛躍（除非是之前參數(shù)造成了某種bug）

數(shù)據(jù)小時，使用了預(yù)訓(xùn)練模型記得固定前幾層的模型參數(shù)，還可以用小點的學(xué)習(xí)率

loss balance有時候很有用

重復(fù)訓(xùn)練可能可以提升點數(shù)，將一個模型訓(xùn)練好后，用訓(xùn)練好的模型做預(yù)訓(xùn)練模型載入，繼續(xù)用同一套參數(shù)訓(xùn)練。有點像CyclicLR（https://pytorch.org/docs/stable/generated/torch.optim.lr_scheduler.CyclicLR.html#torch.optim.lr_scheduler.CyclicLR）

DL沒有像機器學(xué)習(xí)有那么多公式支撐，很多都是make sense就做個實驗來驗證，所以盡量多閱讀論文，看看別人的實驗，這樣就可以減少不必要的實驗

這篇文章是為了分享自己的一些心得，希望讀者能用得上，如果有嚴重錯誤還請告知，不想誤導(dǎo)他人

審核編輯 ：李倩