前言
目前深度学习抢得了足够的眼球和关注度，从各大公司的布局、到如雨后春笋般出来的一波波的创业公司，再到各种普及入门、深度剖析相关的公众号，每天都有大量技术、论文解读相关的文章、博客等，各种各样的信息如洪水般涌入我们的视野，各种论文解析、各种深度剖析等等，在众多的信息中，我们如何去伪存真、吸收更多的有用的信息和知识点是一个要面对的新的问题。
身边也有越来越多的朋友、同学开始向这方面寻求转行，觉得自己所属的开发行业似乎已经是过时的技术，必须要拥抱深度学习这个技术风口。拥抱变化、追求变化是好的，但如果过味的追求风口、追求技术热点、不辩证的去看最终反而会延误自己的发展。
“算法工程师” 还是 “算法应用工程师”
周围有很多朋友都是从做服务端开始的，平时解决的很多问题都是工程相关的问题。我所认识的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、全连接、激活函数等)
总结
也学大量的公式和深度学习相关的论文是复杂的，让对其感兴趣的开发同学望而生畏，但代码是简单的、纯粹的，了解深度学习、掌握深度学习从代码开始不失为一种很好的方式。
