前言
目前深度學習搶得了足夠的眼球和關注度，從各大公司的布局、到如雨后春筍般出來的一波波的創業公司，再到各種普及入門、深度剖析相關的公眾號，每天都有大量技術、論文解讀相關的文章、博客等，各種各樣的信息如洪水般涌入我們的視野，各種論文解析、各種深度剖析等等，在眾多的信息中，我們如何去偽存真、吸收更多的有用的信息和知識點是一個要面對的新的問題。
身邊也有越來越多的朋友、同學開始向這方面尋求轉行，覺得自己所屬的開發行業似乎已經是過時的技術，必須要擁抱深度學習這個技術風口。擁抱變化、追求變化是好的，但如果過味的追求風口、追求技術熱點、不辯證的去看最終反而會延誤自己的發展。
“算法工程師” 還是 “算法應用工程師”
周圍有很多朋友都是從做服務端開始的，平時解決的很多問題都是工程相關的問題。我所認識的BAT以及在國外工作的同學，雖然頂著“算法工程師”相關的頭銜，但絕大多數都是直接運用公司或業界內現有的計算平臺，對已有算法進行使用，甚至很少一部分才會對現有算法進行較大的改造。所以大部分人其實是算法應用工程師，更多的時間是在處理數據、調參等問題。
話說回來，我為什么要強調一下這個問題，真的是因為在實際工作環境中，能夠發論文、有些突破性改造的真的是很少，大部分是組合使用。比如將原來深度模型后面掛了一個邏輯回歸，將其改為使用SVM；原來是5層的神經網絡，改為LSTM等等，目的只有一個就是解決問題、提升效果。
所以后面會寫一些文章，來從程序員的角度來聊聊深度學習相關的知識內容，當然主要是借鑒git上已有的代碼來進行解釋。其目的有三，第一是讓廣大的做服務端相關的同學認識到“術”的相通之處，所謂的算法工程永遠離不開工程，在工程領域積累的寶貴經驗對學習和使用算法工具大有好處；第二是和更多的人交流，鍛煉問題簡化的能力，希望能將問題通過代碼的形式表述清楚；第三就是積累一下文檔化的經驗，寫Blog越來越少了，希望后面能抽出時間多寫寫，讓文筆更順暢、邏輯更清晰些。
繞不開的工程
記得在14年還在學校的時候，那個時候從公司實習回去，經過了雙十一、以及兩次大促的洗禮，對很多中間件產品都很熟悉了，對如何處理高并發、如何提高程序可用性都有了一定的認識和提高。所以在解決實際問題的時候會多多少少的向這方面思考一下。當時實驗室在進行并行深度學習平臺搭建，就是自己搭建分布式深度學習系統，那個時候我們還在用caffee,而tensorflow剛出來但還沒有支持分布式。做法就是傳統的PS模式(Parameter Server 參數服務器模式)，但實際搭建的過程中遇到很多工程性的問題，比如最開始學生們搭建的參數服務器是寫死的，根本沒考慮參數服務器宕機的情況。在參數傳遞過程中數據量過大的壓縮問題，數據量過大的序列化問題等。以如下兩個問題為例：
- 如何保證參數服務器的高可用：
如果不知道ZK(ZooKeeper),那么真不知道會用多么復雜的方法來解決這個問題
2.壓縮和傳輸問題
在worker和參數服務器交互過程中，涉及到大量參數信息的同步，即worker需要將batch更新后的數據同步給參數服務器，參數服務器也會將同步后的結果下發到worker。這里面就存在很多工程優化點，例如向上和向下的參數傳遞如果采用原值傳遞，那么數據量是巨大的，那么采用何種壓縮算法、或者采用何種數據結構(可以考慮差值)都是要嘗試或者動態決定的。緩存數據如何設計才能加速數據的獲取這都是工程上要解決的問題。
同樣在處理自然語言相關的問題上，很多工程化的手段都是必須的，甚至解決的問題遠比算法本身解決的問題要多。無論是在學校還是工作中，這樣的工程手段都是解決問題的首選，例如在學校的時候做的一些知識庫的問答工作，就用到了很多的搜索技術來幫助解決問題(如QP即查詢改寫，搜索提示)，利用規則引擎去解決高頻問題等。所以說工程手段是必須的，這也正是廣大的服務端開發的同學所擅長的，千萬不要拋棄自身的優勢去完全擁抱其他的東西。“技術”更關鍵的在于“術”，“技”只是熟練程度不同而已，而“術”確有相通之處。
涉及內容
后面每天會抽出部分時間來對一些git上的深度學習相關的代碼、實例進行講解，希望能夠對剛入門這個方向的開發同學有所幫助。同時也會對一些問題進行總結，主要會涉及LSTM、CNN、AutoEncoder、Seq2Seq，以及Computer Vision相關的主要算法(AlexNet、ResNet、VGGNet等)，一些Tensorflow的常用函數，常用概念的總結(如卷積、池化、門、Dropout、全連接、激活函數等)
總結
也學大量的公式和深度學習相關的論文是復雜的，讓對其感興趣的開發同學望而生畏，但代碼是簡單的、純粹的，了解深度學習、掌握深度學習從代碼開始不失為一種很好的方式。
