來源：https://zhuanlan.zhihu.com/p/137927248
很多同學在使用深度學習的項目中，大概率會存在如下疑問：
- 項目中，絕大多數時候，幾乎只是在加數據訓練，但爲什麼自己做不好？
- 優秀的深度學習同學，到底和普通的同學，優秀在什麼地方？
根據自己的經驗，總結了幾個關鍵點，適合我自己，但不一定適合別人。
大的戰略方向是：工作中的項目應該與平時的學習充電要緊密聯繫起來。
但如何找到這個戰略路徑呢，下面提供個人的一點經驗。
總的來說，工作中的項目問題越多、越細，你才能在平時看論文中，有強烈的針對性，提高閱讀文獻的高效性。
利用深度學習做項目，應該關心如下幾點：
- 場景的理解
- 資料的收集
- 專題的研究
- 數據的研究
- 網絡結構、loss及壓縮的研究
- 量化結果及測試集的更新
下面分別進行解釋。
場景的理解
場景的理解，包括的內容比較多。主要有要解決的場景中的特點、問題及pipeline。
有項目經驗的人，應該有這麼一個過程：項目初期的方案和最後落地的方案，有時候是兩個完全不同的東西。但也是一步步迭代過程中完成的，而這個迭代的過程，逐漸的越來越理解場景的特點
下面舉幾個例子來進行說明
1）場景中的特點
在一篇關於人眼gaze的論文中，有這麼一句話
爲了充分利用頭部和眼睛的信息，作者採用了coarse to fine的策略。如何充分利用頭部和眼睛的信息，來提高gaze的精度，就是對場景的理解。
在一篇車道線檢測論文中，有這麼一句話
爲了利用上車道線的幾何信息，作者設計了一個檢測消失點的分支，來提高車道線檢測的精度的方案。
所以，在你要解決的場景中，需要仔細琢磨場景中有哪些特點，有什麼先驗信息，這些先驗信息如何使用到項目中，如何使用到深度學習當中。
這樣的例子很多，針對某個具體的專題研究，幾乎每篇論文都在針對某個問題進行解決。
2）場景中的問題
工程項目一般是測試推動迭代的。測試過程中，會發現很多bad case。大多數bad case能夠快速通過增加數據解決的，但實現中，有很多條件約束，不一定能夠滿足你的條件。比如預算不足、公司資源不向你傾斜、採集困難、標註成本巨大等等。
針對這些bad case可以作重點分析，它有什麼樣的特點。
在一篇3D人臉識別的論文中，提到表情的變化，會降低識別系統的精度。當然，這個是從bad case裏分析並提煉出來的問題。
要解決這個問題，最佳的辦法是採集更多更讓人臉，這個成本和難度是非常大的。作者通過3DMM進行生成人工數據。
這個方法，也可以用到公開數據集挑戰賽中。效果前幾的，一般會發論文，很多也開源了。可以利用他們的需要，把測試集跑一篇，看看針對什麼case效果好，什麼case效果不好。針對不好的case，可以作重點分析，提出相應的解決方案。這樣就有機會去做下發頂會的夢了。
實際的項目中，有些case結果不好，可能對整個項目的精度並沒有太大的影響，有些影響非常大。往往很多時候，關注的是影響大的case。
針對項目，確實該如此，但爲了提高我們自身的技能，也需要有點工匠精神，把這些問題，都可以歸納到你的問題集中。
但要注意的是，工作當中，是要有優先級的，這裏只是讓你有更多的疑問，這樣帶着思考去看論文，更有效
3）場景pipeline
很多問題，傳統方法已經是有解決方案的，但無法應對各種各樣的複雜場景。隨着深度學習的發展，越來越多的領域使用了深度學習。直接通過端到端的訓練不一定取到好的效果，那麼我們可不可以通過出中間結果+後處理，或多個模型進行串行解決？
在一篇車道線檢測的論文中
爲了解決車道線擬合的問題，作者將問題拆成2個過程，學習俯視變換，將圖像的車道線投影到地面，再進行擬合。
在自動駕駛裏，爲了得到3D bbox，有端到端的解決方案，也有分成很多步驟的方案。這些，都認爲是可以改變pipeline的思想
資料的收集
針對場景的理解，提出了自己的問題，那又如何才能去解決呢？
往往直接搜索，是很難找到直接相關的論文。這裏要說的是，臨時的搜索是很重要的，但更重要的是平時的積累。
比如每天泛讀1-2篇的文獻，做個簡要的記錄。泛讀時，可以針對領域，也可以不針對領域進行閱讀。
下面是本人的記錄樣例：
需要精讀的論文，再進行詳細筆記。
每週都會過下以前的論文，看看能否得到啓發。
有條件的，可以進行團隊作戰，每個每週看一定的論文，定期的進行交流和交換看，這樣一年下來，必定收穫巨大。
專題的研究
通過前兩步，心中有很多的疑問，將有點相關的論文，歸總在一起，進行對比分析。這樣，理解會加深很多。當然有很多專題論文。
下面是一篇關於數據不平衡的問題的綜述
我們要做的是，自己建立這樣的專題進行對比分析。當然不需要像上面那麼全，畢竟是發論文。是這個意思就行了。
比如，你在做一個手機拿到手上，檢測手機的項目，那麼可能存在一個問題，手機可能被遮擋的，只剩下一小部分，那麼可以建立一個遮擋檢測的專題。
如果當你看到擁擠場景中，論文說解決這樣遮擋的case，那麼你就可以歸檔到你的遮擋專題中，不一定非得專門來解決遮擋問題的論文。
數據的研究
數據的研究，往往很多人知道很重要，但不重視的問題。
以下一個虛擬對話場景：
老闆：XX問題，怎麼還沒有解
員工：這個問題解不了
老闆：爲什麼解不了？
員工：因爲沒數據
老闆：爲什麼不去提數據需求
員工：我提了呀，需求都提給了數據組了。
老闆：那你爲什麼不去追數據呢？
員工：數據量要求很大，人家說目前數據採集不完，標註不完，甚至需要數月或半年才能達到迭代需求，我還能怎麼辦。
老闆：有其它方式得到數據呢？比如優化採集設備、自監督或半監督標註的方案呢？
員工：。。。（內心：關我什麼事，沒數據，又不肯花錢，怎麼讓我做）
實際中的項目，是有很多關於數據的方案
比如，公開數據集，仿真貼圖數據進行預訓練，高仿真數據等等
比如，使用多目相機，或深度相機進行自動標註等等
下面是一篇論文中，將rgb數據，充分用到的3d數據中
還有上面提到的表情問題，通過3DMM進行增強
在實際的項目中，一般要麼從場景上去解，要麼從數據上解，兩者都不重視的，是不適合做深度學習
網絡結構、loss及壓縮的研究
這個不用說了，這個是很多人看論文的關注的重點。實際上，一篇論文的核心，是思路來源，及證明思路可行的過程。
有些論文，公開了這個過程，有些沒有。但實驗部分或多或少，都有點的，所以實驗部分是最不可忽視的部分
一篇研究跟蹤的論文，從他的一系列文獻中，可以得到他的優化跟蹤的過程，在逐步解決什麼樣的問題，來提高精度。
仔細研究他們的工作，收益非常大。遇到這樣的論文，應該精讀，好好琢磨下。
量化結果及測試集的更新
下面虛擬對話：
老闆：模型提升的怎麼樣了
員工：我的測試集的精度達到99.9%
老闆：爲什麼case的成功率爲80%
員工：可能過擬合了吧
老闆：你的測試集，包括了所有的測試組的測試case沒
員工：哦，一直都用的同一個測試集
過了很多天：
老闆：模型提升的怎麼樣了
員工：解了很多case，case完成率爲99%
老闆：爲什麼客戶反饋問題很多
員工：我是通過測試了的，是有郵件證明的
測試：產品只給了這些case
產品：我只負責定義了功能case
負責人：我馬上去增加這些case進行測試迭代
很多時候，我們需要不斷的更新自己的測試，不僅僅是產品和測試的工作，算法人員也需要不斷的更新新發現的case。
解決這個問題，不僅僅是測試樣例的完備及測試環境的等效性。還要研發人員需要站在客戶、產品的角度，理解我們的場景。
虛擬對話：
老闆：模型提升的怎麼樣了
員工：解了很多case，case完成率爲99%
老闆：那你的模型的精度與case完成率是什麼關係，怎麼分析你的模型自身的精度對產品精度的影響
員工：不清楚
老闆：那下一個指標可以多少
員工：99.1%
老闆：爲什麼只提升這麼點
員工：後面提升非常的難，符合28原則，需要優化好幾個月
老闆：能不能將精度換一種表現形式，達到能夠用周來迭代
員工：沒想過
自己負責的模型，需要模塊測試，除了解case率，還需要針對模型的指定的指標進行量化，甚至不同維度的量化，會加深對問題的理解。
比如，研究prelu的影響
比如，研究跟蹤中的overlap的影響
等等，這樣非常多。
總的來說：工作的目的不是完成工作內容，而是加深對問題的理解深度，才能在將工作和充電結合起來。
喜歡歷史的同學，歡迎關注本人的公衆號和知乎：
