年末老師組織幾個課題組進行了2019年的總結，總結了一下科研過程中的經驗與習慣，這裏做一個整理。
關於創新點尋找
1. 通過多看論文尋找idea
通過多看論文，看相關領域和不相關領域的論文，瞭解一些流行的研究熱點，將這些論文熱點應用到自己的領域上，完成創新。很多論文，雖然在不同領域，但用的機制其實是差不多的，attention/self-attention/co-attention之類的。並且在自己領域吭哧吭哧對着問題去想解決方法，最後發現本質上其實還是一些其他論文用過的東西。所以瞭解其他領域的創新方法、移植、分析，是一種可行的創新方法。
也有學長說，Tpami的reviewer會提出論文的創新在其他領域出現過，認爲創新度不夠的情況。這個如果投tpami的時候需要注意一下。但就我的觀察而言，cvpr和iccv很多文章都是這個套路。
爲了提升速度，和其他人多交流是一個比較好的方式，可以快速瞭解大量論文。
2.通過傳統方法啓示創新idea
從傳統方法啓示deeplearning的方法創新也是一種可行的創新方法。這會讓我們所做的創新在論文寫作的時候可解釋性更強，更容易讓人接受。 但我自己的經驗是，一種更高效的方法還是用剛纔說的1方法來提升效果，然後用傳統方法來解釋創新進行寫作。
3.領域比較大的任務的創新方法
有的領域可能是綜合性任務，比如全景分割、實例分割，涉及detection、segmentation等等。對於這種任務還是以小點入手進行創新比較好。（我覺得是廢話）
4.通過縱向閱讀學習別人如何做創新
看論文的時候可以前後看，看看這篇論文follow了什麼論文，被什麼論文follow了，看看人家是怎麼做創新的。
我個人覺得...這種方法可以幫助你知道怎麼寫論文，但很難幫助你做創新。論文裏寫的創新story和真正的做的經常出現不一致的情況，所謂掛羊頭賣狗肉。
關於論文閱讀
1. 瞭解新領域時要把握脈絡
在瞭解新領域時，會閱讀很多的論文。這個時候一件很重要的事是梳理出這個領域發展的脈絡，哪些是重要的論文，劃分出一個新的方法代際，哪些是基於這些論文做出的一點小創新的論文。領域的發展是樹狀的，一些重要的論文劃分了代際，另一些論文做了一些小創新。
2.找出什麼是真正起作用的部分
如我上文所說，論文經常出現掛羊頭賣狗肉的情況。論文着力鼓吹的創新可能不是真正提升效果的部分，一筆帶過的方法纔是真正提升效果的部分。此外，論文寫作一般都講究一個包裝，要把平凡無奇、或是雷同的方法包裝出高級的感覺。所以在閱讀論文的過程中要進行逆向還原。（我認爲直接讀公式是一種比較快速還原方法破除包裝的方式
3.用不同顏色標記文章，關注文章的表達
爲寫作做準備，看論文的時候去關注其他論文的表達。可以用不同的顏色對錶達、生詞、文章重要內容、錯誤內容進行標註。
關於實驗部分
1.不要執着某一方法
都說deeplearning要調參，所以有時候做實驗驗證方法的時候，實驗效果很差，有的時候我們會希望通過調整參數來糾正實驗。但很多經驗告訴我們，調參帶來的改變可能不會特別大，像一個方法如果實驗出來性能只有百分之六七十就不要調了，調十天半個月往往以失敗爲告終。所以不要執着於某一個方法。
2.設置對照組
做算法設計的時候可能會把一整套方法都設計好，然後直接做實驗，這樣容易失敗。比較好的方式是設置明確的對照組，一點一點做改變，證明每一個小點的改進是否起作用，最後完成整個方法的實驗。
這種方法也可以避免實現過程中的一些小bug對實驗結論產生影響。有時候一個dataloader寫的不夠好，多了個bn，這種時候很難得出state-of-the-art效果，如果不設置對照組的話會錯誤地認爲實驗失敗了。如果設置一個base對照組，即使這些小問題沒注意到，也不影響方法有效性的驗證。
3.不要預設實驗結果會work，尊重實驗客觀規律
我們做實驗的時候往往功利心比較重，希望驗證方法有效性的時候實驗效果很好。這種心態和方法都是不對的。一方面是由於實驗失敗率客觀上比較高，這樣去期待不切實際，之會引起過大的情緒波動。另一方面是不應該只做一些性能驗證實驗，而是要做更多的探究實驗。去探究問題，利用實驗去了解問題的客觀性質等等，而不是單一的去驗證自己的方法有沒有效果。瞭解了問題的性質，自然能做出創新。
4.充分利用開源代碼
一套pipeline會有很多的細節，比如數據預處理、dataloader怎麼寫，bn層的處理，等等。自己寫的話容易在一些細節出錯，而這種細節往往對性能復現是有很重要的影響的。利用開源代碼會很好的避免這些問題。
5.注意論文的implementation detail，注意超參
超參還是很重要的。雖然自己做實驗不一定和其他人的超參一致，但還是能提供比較好的參考作用。
6.利用Git進行版本控制和團隊協作
7.基礎細節的注意
有的基礎知識，看起來挺簡單，大家也總覺得自己懂了，但在實踐過程中會出很多岔子。大家紛紛說起了bn的故事...貼幾個大家提到的點：
Batch-normalized 應該放在非線性激活層的前面還是後面？ - 論智的回答 - 知乎
fine-tune 的時候對於bn的處理：固定用的backbone的bn
RNN 中爲什麼要採用 tanh，而不是 ReLU 作爲激活函數？ - 何之源的回答 - 知乎
關於合作
1.帶團隊的時候大家一起制定計劃
不要機械地分配任務，大家的積極性會不高，無法一起開動腦筋。不過這也看團隊配置情況了。
關於rebuttal
1.挖掘reviewer真正的意圖
reviewer可能會問很多細節問題，但可能真正的concern不是這個，是某一個方面不瞭解或者不贊同。不要直接去東回答一下西回答一下reviewer的問題，切忌一直說“正文的xxx處寫了”。
2.會議強調novelty、期刊強調完備性
會議要快速引起reviewer的興趣，期刊要把工作做的完整。
3.會議的rebuttal成功機會小
會議投稿多，reviewer如果不喜歡你的工作就是找理由拒你，這個時候rebuttal機會不大。但期刊的reviewer是利用rebuttal來跟你交流，所以rebuttal的機會比較大一些。
4.寫作的時候先預估reviewer會怎麼問，甚至引導reviewer問我們準備好的問題