肺腑之言，聊聊推荐系统工程化应该怎么入坑

自从今年我在一些平台讲了几次推荐系统的公开课后，就有好多同学加我，问我推荐系统应该怎么入门，那么今天，我就结合自己的实际经历来聊聊推荐系统怎么入门比较好。

实际上，想要入门或者转行到推荐系统的一般有三类人，第一类就是推荐系统相关方向的研究生同学，第二类就是从NLP或者其他深度学习相关工作转行到推荐系统的同学，第三类就是由开发岗向推荐系统开发转行的同学。那么今天，我就从这三个角度来分别说一说推荐系统应该怎么入门。

我是推荐系统方向的研究生

目前很多同学在研究生阶段就已经开始从事推荐系统相关的研究，从协同过滤到FM，从传统的机器学习算法到深度学习算法，研究的范围越来越广，研究的深度越来越深，近几年来推荐系统领域相关的论文也是越来越多，一般来讲，大家都能使用MovieLens数据集在自己的模型上跑出一个不错的效果。

从算法角度和机器学习的角度来看，很多推荐系统方向的研究生对于机器学习，尤其是GBDT、LR、XGBoost等常见的算法都是了如指掌，对于协同过滤、DNN、双塔模型等理论和demo的实践也是有着比较深入的研究，这些都是目前大多数相关研究生的优势，但是了解这些只能说明你有了一定的相关基础，对于真正的落地和企业所需要的技能，还相差甚远。

我们拿最简单的基于item的协同过滤来举例子。按照正常的思路，当我接到一个使用协同过滤算法来做一个推荐系统的召回任务时，大家的第一反应就是去百度、Google和GitHub中去找item-base CF的代码，然后拿到本地来跑一跑，发现能够跑通，接下来我们就会根据其算法逻辑和相关的数据集，要么就是把我们自己的数据集处理成和网上例子数据集一样的方式，要么就是去改一下代码中数据集的处理方法，使其能够适应我们的数据集。首先来说，这个思路是正常的，也算是相对来讲比较常规的思路。但是实际上，细心的人能够发现，我们在网上找的item-base CF的算法，基本上都是一模一样的，最多就是换了一个变量名或者方法名，有的写得稍微好一点的可能会把里面一些耦合相对比较严重的地方给抽离处理，使代码具有可读性。于是，大家就会用这套代码把我们的数据集套进去，然后来做验证。而一般来讲，我们用于做开发或者测试的数据集相对来讲都是比较小的数据集，可能只有几万条甚至几千条数据，我们可以很快的验证出，这个模型的效果似乎还不错，于是大家就会想着，我们可以将其结合到业务逻辑中，然后进行上线。

一般来讲，在公司做推荐系统的开发需要经过以下几个步骤：开发、测试、预上线、压测、上线。

对于开发的同学来讲，开发、测试这两个步骤一般都是很容易的，按照上面的步骤来讲，直接把网上的demo拿来改改，然后就可以跑通，但是实际上，这也是留下了一个巨大的坑在里面，而这个坑实际上就是在预上线阶段。

因为我们在预上线阶段，所拿到的数据和生产上的数据一般是实时同步的，而生产上的数据量要远远大于我们在开发阶段的测试量，因此，在这个时候，我们经常会出现这样一个问题，那就是我们的模型跑不起来了，甚至在数据的加载阶段就会出现OOM的现象。这个时候大家可能会想，我是不是可以用小一点的数据来跑，于是，为了尝试，我们把数据集稍微改小了一点，以前是用历史1年的数据，现在改到了历史1个月的数据，ok，现在模型可以正常跑起来了，但是我们又会发现，之前跑一个模型只需要2个小时，现在要200个小时，而对于线上业务来说，这根本是不可以的，于是乎，大家就陷入了一个瓶颈。

实际上，上面这个例子是研究生在刚刚毕业或者实习阶段进入公司后会经常遇到的问题，因为我们在学习 阶段所用的数据量太小了，我们所关注的可能更多的是指标，点击率、召回率这些，但是实际上，在工业界中，点击率虽然是一个很重要的指标，但是我们的前提是要先把数据跑起来，那么，面对这种非常大量的数据我们应该如何去跑，如何去落地，这才是真正需要关心的地方。

因此，在这里我要给那些推荐方向的研究生同学一点建议，那就是，我们在做研究的时候也要去考虑一下实际的工业问题，想想如果在实际的工业生产中，我们的数据量大概会是多少，然后再去想办法造出这么大数据量的数据，再来验证自己的想法，这样的话，对于以后推荐系统工作的路，才会走的越来越稳。

所以说，研究生阶段区别于工作的最大问题就是，研究生阶段所关注的点在于指标，而不是落地，因此，要把怎么落地作为第一要素来做研究，这样我们才能走的更顺。

除此之外，研究生阶段很多时候都是在追求模型的效果以及研究成果。我之前跟很多推荐系统方向的研究生聊过这个话题，他们对目前最新的论文，以及相关的模型实现很了解，但是实际上大家不知道的是，在企业中，我们所追求的并不一定是新，而是效果好，而测试集的效果并不代表实际落地的效果，因此，在这一点上需要有所取舍，新的模型是要研究，但是关注的点要稍微变化一下，我们可以研究如何把新的模型应用在更大的数据集上，只有这样才更有意义。

所以，很多研究生的劣势在于，所做的项目和工作太过于理论化，与实际企业的内容脱轨比较严重，这也是很多人找工作碰壁的原因。

因此，对于推荐系统的研究生来说，入门实际上很容易，其难点在于，如何入行。在我看来，入门是从理论上的，而入行是站在工业角度来说的。

我是从其他深度学习工作转行的

除了研究生以外，还有一部分同学是从其他深度学习转行到推荐系统领域的，其中最多的就是NLP和CV。其实对于从其他深度学习领域入门到推荐系统领域的同学来说有着比较先天性的优势在于对于算法和深度学习基础的理解和认知，这会使得转行变得很快。但是，对于转行的同学来说，我们也要找到推荐系统与其他的不同之处。

对于NLP和CV或者其他机器学习的同学来讲，一些基础知识肯定是不成问题，但是光是这一点认识不足以很好的入门推荐系统，因为推荐系统与其他的深度学习领域所关注的点不同。

对于NLP或者CV模型来说，我们一般会把关注的点放在模型的精度以及算法的优化上，而这些一般来讲并不会涉及到业务逻辑本身。而推荐系统不一样，推荐系统是与业务强相关的，推荐系统里面所涉及到的每一个特征，所应用到的每一个策略都需要跟业务场景进行非常紧密的结合，因此，这说明对于推荐系统的工程师来讲，我们可能更多的是要了解到具体的业务需求，然后分析，我们应该使用哪些算法和哪些策略来做个需求，最终形成一套切实可行的方案，从而完成整个项目的开发。

上面这一段看起来很简单，实际上这里也有着比较复杂和比较难的点。首先，对于CV和NLP来讲，往往对QPS（每秒请求并发）这个指标没有什么要求，但是推荐系统往往是要做上线的，上线的前提就是要保证高可用性以及高并发，这也是推荐系统的一个难点所在。其最难之处在于，我们如何能够在使用深度学习或机器学习模型的前提下，来提高请求的并发，那么这里，我们可能又会涉及到负载均衡、服务器性能调优等比较全面的知识。

因此，对于从其他深度学习工作转行到推荐系统领域的同学来说，如何进行推荐系统的工程化是非常重要的。

另外，在推荐系统开发时，我们可能更加注重时效性，这个时效性有2层含义。一层是对于整个模型和接口的时效性，也就是说，我这个推荐系统的接口对外的响应速度是怎么样的，也就是上面所提到的QPS。第二个时效性是指内容的时效性。我们就拿新闻推荐来举例，很多新闻推荐热度高的往往是比较老的新闻，而刚出来的新闻往往在自己的产品里没用什么热度，但是我们要用什么样的策略能够把这些比较新的内容推荐出来，这也是一个推荐系统工程师所要考虑的问题。

因此，对于其他深度学习转行到推荐系统的同学来讲，工程化方面是需要格外关注的一个点。

我是由开发岗转行的

除了上面两种科班出身的例子之外，更多的是由其他开发岗位转行到推荐系统的同学，这里有些同学之前可能是做Java的，有些同学之前可能是做C++的，还有些同学之前可能是做大数据的。这些同学在转行推荐系统的时候，实际上和上面的两种情况正好是相反的。

对于其他开发岗转行到推荐系统的同学来说，首先最大的优势在于，对于工程化方面的理解比较深入，对于业务逻辑开发，接口开发以及高并发这样的工程化方面问题可以说是最大的长处，但是相反的是，对于深度学习和机器学习的理论可能就是比较薄弱的项目了，因此，对于开发转行推荐系统的同学来讲，最主要的亮点就是机器学习基础、深度学习基础和算法基础，其次就是要有一个相对完整的推荐系统项目经验。

实际上，对于大部分刚入行的同学来说，机器学习、深度学习和算法基础并不一定要掌握的非常深入，前期可以想把一些简单的基础知识掌握，比如一些常见的机器学习算法、一些常见的深度学习模型和基本的数据结构知识，在这些的基础上，我们再去学习其他的知识，一般来说就比较容易了。

但是，对于开发岗来说，单单是理论一般来讲是不够的，还需要有比较多的项目经验。针对于这一点，我倒是建议大家按照这样的顺序来做：

1、先看下网上的一些基本的算法，先对推荐系统的基本算法有一定的了解；

2、然后从GitHub上找一些demo去跑；

3、使用爬虫技术去爬取一些数据作为数据集，然后再自己去造一些用户行为数据，用作模型的训练；

4、自己去看算法的实现，然后去从时间复杂度的角度来优化算法，使其在大数据集上面能够跑的更快；

5、使用负载均衡和restful的方式进行上线。