做AI，底层框架or上层应用？

做底层AI框架和上层AI应用，哪个对自己的学术水平（或综合能力）促进更大？这一问题引起了知乎上不少的讨论。本文对解浚源、微调等用户的精彩回答做了整理，与读者共享。

左手“底层AI框架”，右手“上层AI应用”，如何选择？

对于做AI相关工作的人来说，具体选择做哪个方向，可能是需要深深纠结的一个问题。

知乎上就用户提出了此问题，引起了不小的关注和讨论：

新智元获得了解浚源和微调两位用户的授权，将他们对此问题的深度解析做了整理，与读者共享。

要有侧重，但两方面都需了解

作为一个深度学习转系统的人，我最近也在反思一个问题：深度学习系统（Deep Learning System）的核心到底是深度学习还是系统？

先放结论：无论你想做深度学习还是深度学习系统，都需要同时了解两方面的知识，根据自己的方向可以有所侧重，但一定不能对一方面完全不懂，否则是很难做出在实践中有用的成果的。

首先我们来看一下目前流行框架的开发团队和他们开发框架的驱动力：

Caffe：贾扬清和伯克利视觉实验室的小伙伴们开发。开始主要是自己用，属于需求驱动。

Torch：Yann LeCun的学生。需求驱动。

Theano：Yoshua Benjio的学生。用于自己科研，但是也发了系统的paper，属于需求＋科研驱动。

Tensorflow：Jeff Dean带领的Google员工，主要是系统出身。源于Google在AI领域的布局需求，资本驱动。

Neon：nervana员工，作为创业公司的产品。资本驱动。

MXNet：DMLC（主要是华人机器学习和分布式系统学生）的小伙伴。主要是Minerva，Purine，和cxxnet的开发团队合在一起，一半搞机器学习的，一半搞系统的。需求＋兴趣驱动。

剩下还有很多搞系统的人出于兴趣或者科研目的开发的框架，但大多没有流行起来，就不再赘述了。

可以看出，除了Google强推的Tensorflow，大多都是从自用和兴趣开始的。而Tensorflow的开发经费比其他所有框架的经费加起来还要多出几十倍，但是一年下来并没能一统江湖。可见需求驱动的力量，所谓“需要是发明之母”。

为什么主流深度学习框架多数出自“懂一点系统的搞深度学习的人”之手，而不是“懂一点深度学习的搞系统的人”呢？

我认为主要是因为深度学习系统和传统系统（比如操作系统，数据库）有一个本质区别：深度学习算法各部分的耦合非常紧密，牵一发而动全身。

搞系统的人的思路是，我做一个系统，定义好接口，保证接口正确，用户用就可以了，不需要了解实现细节。毕竟你用操作系统并不需要了解文件系统格式，用数据库并不需要了解一致性是怎么实现的。

但是这套思维用在深度学习系统上却不合适。

其一，一个数据矩阵流过整个系统，每一步的细节都可能对一百步以后的结果造成影响。而对于中间结果，你无法严格定义什么是正确的，一个好的算法不是N个好的部分的简单叠加。Hinton就说过，Dropout看起来像个Bug，但是它提高了精度，所以是个“好bug”。

其二，因为深度学习算法复杂，需要控制的因素多，一个固定接口很难满足所有用户的需要。还不如把系统写的简单灵活一点，让用户根据需要可以很方便的自己修改。

反过来对搞深度学习的人来说，如果你不了解系统内部细节，当你的算法效果好的时候，你并不知道到底是哪些因素导致了效果好。可能换了一个框架，效果就不好了，而原因是你根本不知道的某个实现细节。当效果不好时，你也不知道如何改进。

另一方面来说，当你需要实现一个新的算法的时候，经常会发现框架现有的接口不能解决你的问题，这时候就需要对系统内部的了解才能修改系统已实现自己的目的。

底层开发较难，上层更接地气

上周开会时遇到了TAMU的胡侠老师，他介绍了他们组最近开发的一个自动机器学习开源框架Auto Keras。胡老师原话是这么说的：“做开源框架是非常有意义的事情，尤其是你的工作在短时间内被很多人关注并使用是非常有成就感的。”

确实如此，很多业内人士在逐渐把目光投向到更底层更接近“基础设施”的方向上，比如自动调参、大规模机器学习、并行式机器学习。毕竟好的算法想要被更多人使用，就需要降低使用门槛，提供通用的框架。假设如果没有Sklearn，估计做机器学习的人最起码要少一半。如果没有TF或者Torch，做深度学习的人估计也要少一半。

其实严格意义上来说，从提出算法，封装算法，到应用在现实数据集上是一个流水线作业，是从上游到下游的工作。我的一个观察是，做算法研究的很多人代码写的很糙，运行效率可能非常低。

举个简单例子，当你展示一个简单的K近邻算法时，你可以写成每次都进行重新搜索，也可以先构造一课K-D树来降低时间复杂度。仅聪逻辑角度来看，前者和后者都是正确的，但效率可能相差不少。

这种现象造成了大部分前沿研究的结果不容易落地，因为代码未经优化或者在实现时存在各种各样的bug。我觉得一个非常好的突破角度就是研究如何高效实现各种传统及前沿算法，从最简单的向量化、并行运算，到更复杂的结构设计甚至到大规模的并行计算。如果把底层框架做好，那么对于工业界和科研界都有很大的意义：

工业界可以快速尝试前沿算法，在真实数据上验证算法的可靠性及实用性。

科研界可以公平的对比前沿算法，防止科研造假。很多论文声称他们的算法是远超当前的最佳算法（SOTA），但事实上可能仅仅是因为他们没有正确实现SOTA而已。

我从去年起开始尝试造一些小轮子，也做了一些小框架。这个过程中由不少全新的感受：

设计、实现框架很容易，发现原有算法中的不足，有助于激发新的点子。以基于K近邻的算法为例，假设在实现时你发现整个程序效率受制于K近邻部分，你就可以尝试用K-D树来加速，甚至替换掉K近邻的步骤，用聚类来模拟这个过程。所以当你了解算法的瓶颈时，你就可以提出新的有意义改进，反哺学术研究。

增强自己的实现能力，避免沉溺研究后的纸上谈兵。近两年最受关注的传统分类方法要数陈天奇的XGBOOST，的确非常的好用。我认为XGBOOST的成功要归功于算法很早就被封装成了成熟的工具库，这是基于陈天奇老师深厚的系统设计和实现功力。我想过去十年肯定有一些很优秀的算法蒙尘，只是因为它们的作者无法把它们封装成成熟的轮子供大家使用，非常可惜。

更符合工业界的定位，为求职路加分。其实大部分情况下，工业界并不在意你发过多少厉害的文章，而更在意你是否可以把公司的需求落地。我自己的经验是即使是学术参会，也没有多少人对我的水文感兴趣，而更多的是聊我开发框架的经历，因为他们不仅听说过可能还是使用者。

成就感。框架的使用者远比论文的阅读者要多得多，当你发现你设计的框架被全世界的人广泛使用时，会有很强的成就感，会觉得自己为这个领域发展做出了一点点贡献，而不是仅仅写出了一些这辈子不会再有人看的水文。

以上观点主要在讨论要不要尝试学习开发框架，尝试造出一些新的轮子。回到正题，「底层框架」哪个「上层应用」更好？我的观点是这取决于你所拥有的技能：

底层框架：难点在于封装和性能。比如如何设计API（接口），如何提高运行速度进行优化，如何写好测试保证方法正确。

上层应用：难点在于如何把已有的轮子用在现实数据上去，这涉及里很多现实的问题比如数据清理，比如理解如何正确的调用底层的功能。

一般来说，大部分人不适合写底层。毕竟优秀的框架已经很多，而且对于系统架构以及代码优化的要求很高，大部分人并不具备所需的知识。

而上层应用就显得更接地气，可以加深我们对于数据的敏感度，擅长做上层应用的同学也会是职场offer收割机。其实能够做好上层应用并不容易，这需要对于问题的深入理解。

换句话说，底层框架和上层应用分的是不同的蛋糕，侧重点各不相同。

从做研究的角度来看，发明一个算法其实不该是终点。作为算法的提出者更应该自己动手实现自己的模型，毕竟酒香也怕巷子深。