小团队撬动大数据——当当推荐团队的机器学习实践-CSDN.NET http://www.csdn.net/article/2015-10-16/2825925

• Github项目: awesome-coder-resources：编程/学习/阅读资源---开源项目,面试题,网站,书,博客,教程等等...欢迎Star,欢迎围观...

由于机器学习系统的特殊性，构建一个靠谱好用的系统却并不是件容易的事情。每当看到同行们精彩的分享时，我都会想到，这些复杂精妙的系统，是怎样构建起来的？构建过程是怎样的？这背后是否有一些坑？有一些经验？是否可以“偷”来借鉴？

所以我希望做一个更侧重“面向过程”的分享，与大家分享一下我们在构建系统时的一些实践，一些坑，以及如何从坑里爬出来。

摘要：当当个性化推荐开发经理张相於深度分享当当推荐团队的机器学习实践经验。本次分享更侧重“面向过程”——在构建系统时的一些实践，一些坑，以及如何从坑里爬出来，以及“小团队”。
【编者按】当当个性化推荐开发经理张相於深度分享当当推荐团队的机器学习实践经验，侧重介绍一个小团队在构建系统时的一些实践，一些坑，以及如何从坑里爬出来。当当构建机器学习系统过程中踩过的坑主要包括：只见模型，不见系统；不重视可视化分析工具；过于依赖算法；关键流程和数据没有掌握在自己团队；团队不够“全栈”；巨型系统。工具方面，当当在探索阶段选择的是R和Python，大数据阶段则主要依靠Hadoop和Spark，目前集群是几百台的规模。在“全流程构建”的不断迭代中，当当还总结提取出的一套特征工程相关的工具——dmilch。
先说一下我的初衷。机器学习系统现在多红多NB这件事情我已不必赘述。但是由于机器学习系统的特殊性，构建一个靠谱好用的系统却并不是件容易的事情。每当看到同行们精彩的分享时，我都会想到，这些复杂精妙的系统，是怎样构建起来的？构建过程是怎样的？这背后是否有一些坑？有一些经验？是否可以“偷”来借鉴？
所以我希望做一个更侧重“面向过程”的分享，与大家分享一下我们在构建系统时的一些实践，一些坑，以及如何从坑里爬出来。
另外，我本次分享更侧重的是“小团队”，一是因为当当目前做ML的团队确实还比较小，其次是因为据我了解并不是每个企业都像BAT那样阵容庞大整齐。所以小团队的经历和实践或许会有独特的借鉴意义，希望这次分享能从不一样的角度给大家提供一些参考。

今天分享的实践经历来自当当推荐组的ML小团队。

我们的团队负责当当推荐/广告中机器学习系统从0开始的搭建、调优、维护和改进。除计算平台为其他团队负责维护以外，ML pipeline中的每个环节均要负责。生产的模型用于部分推荐模块和部分广告模块的排序。

分享开始之前，有必要阐明一下本次分享的定位。如上图所示，本次分享不涉及这些内容，对此有需求的同学可参考CSDN上其他精彩的分享。

上面这些，是本次分享所涉及到的，其中“面向过程”是本次的重点。分享的人群定位如下：

无论你处于构建机器学习系统的哪个阶段，如果能从本次分享有所收获，或者有所启发，那笔者带着“长假后综合症”做的这个PPT就没白忙活……

这是我们本次分享的大纲：先简单谈一下我对“小团队”的一些认识，再花主要的时间和大家分享一下当当的小团队机器学习实践。接着我会总结一些我们实践中猜到的坑，以及从这些坑中学到的东西。然后我会以一些参考文献为例，做一些对未来工作和可能方向的展望。最后是问答环节。
简论小团队
首先谈谈我对小团队的认识。

为什么会出现小团队？这个问题乍一看有点像是句废话，因为每个团队都是从小到大发展起来的。这没错，但是机器学习的团队还是有一些属于自己的特点的。

相比一些功能性系统，机器学习系统的特点之一是不确定性，也就是这个系统搭起来的效果，是无法从开头就量化的。这导致决策层在投入上比较谨慎，不会在刚开始就投入太多人。
这方面人才确实比较稀缺，招聘难。简历看着漂亮的挺多，有实际能力或经验的其实很少。本着宁缺毋滥的原则，小而精的团队是一个更好的选择。

首先是对单兵能力的高要求。这很容易理解，人少就意味着每个人都需要发挥很大的作用，因此对单兵能力要求比较高。对于这个问题，其实没有太多好的办法，主要就是外部招聘和内部培养。
其次是在系统开发过程中，大家一般都需要交叉负责多个任务，这既是对个人能力的挑战，也是对协作能力挑战。但是另一方面，这其实是对员工最好的培养，能够让大家以最快的速度成长。
再次就是方向和需求选择的问题。因为人少，所以在决定下一步行动时，需要非常谨慎，尽量减少无产出的投入。这有时确实是一种限制，但是换个角度来看，这“逼迫”我们把精力集中在最重要的部分，好钢都是用在刀刃上。
最后一点，就是单点风险较高。由于每个人都负责了比较多的部分，所以每个人的离职、休假等异动，都会对系统造成较大影响。这个问题同样主要是通过内部培养和外部招聘来解决，不过还有一个方法，就是用有挑战的事情留住人。哪种方法好使，就要看具体环境的具体情况了。

这样一看，小团队挑战不小，但是反过来看，小团队也有一些独特的优势。

首先就是团队易于凝聚。这也是任何小团队的天然优势。
其次是易于协作。很多事情不需要开会，转身几句话就可以搞定。
再次是迭代速度的优势。由于流程所涉及的事情全部由少数几个人负责，不需要协调过多的资源，那么只要这几个人使劲，迭代速度就会快起来。
最后一点，也是非常重要的一点，就是团队的成长。由于大家都要负责很多事情，那么成长速度自然就会很快，同时个人的成就感也会比较高，如果调配得当，会让整个团队处于一种非常有活力的积极状态。

当当推荐机器学习实践
下面我们花一些时间来分享一下当当的机器学习团队是如何撬动机器学习系统这块大石头的。

这一页的架构图是上一页图中红框中部分的细节放大。从图中可以看出，机器学习系统是在结果排序中发挥作用的。关于这个架构的细节我在这里不做展开，感兴趣的同学可参照美团的同学前段时间的分享，是比较类似的架构。

上面的架构图是上一页架构中红框部分的进一步展开，也就是机器学习系统本身的一个架构简图。有经验的同学能看出来，这张简图中包括了机器学习系统的主要流程部件。
后面我们会说到这一套系统是如何搭建起来的，经历的过程是怎样的。系统初始阶段，是一个探索的阶段。这个阶段的意义在于，搞明白你的问题究竟是不是一个适合用ML技术解决的问题。
机器学习很厉害，但不是万能的，尤其是某些需要强人工先验的领域，可能不是最合适的方案，尤其不适合作为系统启动的方案。在这个阶段，我们使用的工具是R和Python。

上页右侧的图中，红色框住的部分是可以用R来解决的，蓝色框住的部分是用Python更合适的，绿色框住的部分是两者都需要。
为什么选择R和Python呢？
先说R。

是因为R的全能性，堪称数据科学界的瑞士军刀。
是因为R已经流行很多年了，属于成熟的工具，遇到问题容易找到解决方案。
当时（2013年）sklearn之类的还不够完善好用，而且有问题也不容易找到解决方案。

再说Python。

Python的开发效率高，适合快速开发、迭代，当然要注意工程质量。
Python的文本处理能力较强，适合处理文本相关的特征。
Python和Hadoop以及Spark等计算平台的结合能力较强，在数据量扩张时具有可扩展性。

不过，R的部分现在其实也可以用Python来替代，因为以sklearn，Pandas，Theano等为代表的工具包都已经更加成熟。
但是当过了初期探索的阶段，到了大数据量的系统时，R就不再适合了。主要原因就是两个：可处理数据量小和处理速度慢。

第一个是因为纯的R只支持单机，并且数据必须全部载入内存，这显然对于大数据处理是个很明显的障碍，不过现在的一些新技术对这一问题或许会有所缓解，但是我们没有尝试过。
其次就是计算速度相对慢，这当然指的也是在大数据量下的速度。

所以，如架构图中左边，一旦到了大数据量阶段，以****Hadoop****和Spark****为代表的工具们就会登上舞台，成为主要使用的工具。
过了初期探索、验证的阶段后，就要进入工程迭代的步骤了。

其实这个开发流程，特别像盖房子的流程，先要打地基，之后建一个毛坯房，之后就是不断装修，各种验工，直到可以入住。住进去一段时间可能觉得哪里又不满意了，或者又出现了什么新的、更漂亮的装修方法，那可能又会再次装修。如此反复。直到有一天你发财了，要换房子了，那也就是系统整体重构、升级的时候了。

这一页介绍的我们使用的工具，都是一些市面上常见的主流工具，除了dmilch这套工具。
dmilch（milch为德语牛奶的意思）：Dangdang MachIne Learning toolCHain是我们在不断迭代中总结提取出的一套特征工程相关的工具。包含了一些特征处理的常用工具，例如特征正则化、归一化，常用指标计算等。和linkedin前段时间开源出来的FeatureFu目的类似，都是为了方便特征处理，但是角度不同。

这一页介绍几个我们在工作流程中的关键点。其实小团队在这个方面是有着天然优势的，所以我们的中心思想就是“小步快跑”。
第一个关键点就是改动之间的串行性。这或许是机器学习这种算法类系统的独有特点，多个改进一起上的话，有时就无法区分究竟是什么因素起到了真正的作用，就像一副中药一样，不知道起效的是什么，而我们希望的是能把真正的“青蒿素”提取出来。
第二点就是项目推进机制。我们大概每周会有一到两次的会议讨论，主要内容是验证改进效果，方案讨论等，并当场确认下一步的动作。
技术人员其实是不喜欢开会的，那为什么每周还有开呢？我认为最重要的一个目的就是让大家参与讨论，共同对项目负责，共同成长。承担的工作有分工，但是在讨论时无分工，每个人都要对系统有想法，有建议。这也能确保大家互相吸收自己不熟悉的地方，更有利于成长。
还有一个不得不说的话题就是关于新技术的尝试。如果沿用我们之前的盖房子的例子，新技术就好比高大上的家具摆设之类的，家里没个一两件镇宅的，都不好意思跟人打招呼。
这方面我们的经验是，先把已有的技术吃透，用透，再说新技术，不迟。例如推荐中的协同过滤算法，一般会在购买、浏览、评论、收藏等不同数据，不同维度都去加以计算，看哪个效果更好。当把熟悉的技术的价值都“榨取”干了之后，再尝试新技术也不迟。
还有一点很重要，就是别人的技术，未必适合你。不同公司的业务场景，数据规模，数据特点都不尽相同，对于他人提出的新技术，要慎重采纳。
我们曾经满怀信心的尝试过某国际大厂的某技术，但是反复尝试都没有得到好的效果，反而徒增了很大的复杂性。后来和一些同行交流之后发现大家也都没有得到好的效果。所以外国的月亮，有可能只是在外国比较圆。上什么技术，还是要看自己系统所在的土壤适合种什么样的苗。
这部分结束之前我简单介绍一下我们的模型在推荐广告上上线后的效果：推荐首屏点击率提升了15%~20%。广告的点击率提升了30%左右，RPM提升了20%左右。可以看出效果还是很明显的。
那些年，我们踩过的坑
下面进入今天分享的下一个重要环节，那就是我们踩过的各种坑。
“前事不忘，后事之师”，坑或许是每个分享中最有价值的一部分。我们在构建系统时也踩过很多坑，在这里和大家分享几个我认为比较大的坑，希望对大家有所帮助。我会先介绍几个坑，之后再说一下我们从坑里爬出来的感觉、收获。
只见模型，不见系统。
如果要把我们踩过的坑排个名，这个坑一定是第一名。因为如果掉进了这个坑，那么指导你系统方向的依据有可能完全是错的。
具体来说，这个问题指的是在构建系统时，我们一开始基本只关注机器学习模型的好坏，AUC如何，NE如何，但是没有关注这个模型到了线上的最终效果是如何。这样做的后果是，我们觉得模型从指标等各方面来看已经非常好了，但是一上线发现完全没有效果。因为我们忽略了模型是被如何使用的，一直在闭门造成一样的“优化”模型，最后的效果自然不会好。
那正确的姿势是怎样的呢？从我们的经验来看，在系统搭建的初期，就要明确地知道：你构建的不是一个模型，而是一个以模型为中心的系统。时刻要知道模型出来之后要干什么，要怎么用，这种大局观非常重要。
模型虽然是系统的中心，但不是系统的全部。在系统设计、开发、调优的各个阶段，都要从系统的角度去看问题，不能眼里只有模型，没有系统（产品）。否则可能等你调出一个AUC=0.99的模型的时候，一抬头发现已经和系统越走越远了。
所以，做机器学习系统要注意模型和系统并重，如果只看到模型而看不到系统，很可能会做出指标漂亮但是没有实效的“花瓶系统”来。
不重视可视化分析工具
这是一个开始很容易被忽视，但是到后期会导致你很难受的一个问题（这里指的是非深度学习的系统）。
因为机器学习系统某种程度上是个黑盒子，所以我们的精力会习惯性地集中在参数、模型这些东西上，本能地觉得模型的内部工作是不需要关心的。但是我们的经验是，如果只关注黑盒子的外面，完全不关心里面，那么如果模型效果不好，那么将很难定位到问题的所在。反过来，如果效果好了，也会有点莫名其妙，就好比你家厕所的灯忽然自己亮了，或者电视机忽然自己开了，总会让人很不踏实。
这个问题上我们的感触是很深的。我们最早在做系统的时候，发现效果不好，其实是没有太多章法能够帮助定位问题的。只能是把各种特征来回特征，样本处理上变一下花样，如果效果好了，就好了，不好，接着折腾。
后来我们做了一套web页面，上面把每条样本、每个case的特征及其参数，样本的出现次数，在候选集里的排序等等，全部展示出来。如同把整个系统加模型给做了一次解剖，希望能够尽量多地看到系统的内部细节，对于分析问题有很大帮助。
这个系统帮了我们很大的忙，虽然也不能算是“有章法”的做法，但是把很多东西呈现在你面前之后，你会发现有些东西和你想的不一样，也会发现一些你压根不会想到的东西。这对于机器学习这种有点像黑盒子的系统来说，尤为宝贵。到现在，这个系统是我们每次效果验证时非常依赖的一个东西，可以说是我们的另一双眼睛。
过于依赖算法
这个坑相信很多同学也遇到过。我就举一个例子吧。我们当时遇到一个文本处理的问题，要过滤掉大量无关无用的文本词汇。一开始上了很多各种算法，各种调优，但是迟迟得不到满意的效果。
最后我们亮出了绝招：人肉过滤。具体说就是三个人花了三天时间纯人工把文本过了一遍（几千个上万个词），效果立竿见影。当时那个问题，或许是存在效果更好的算法的，但是从系统、工程角度整体衡量一下，还是人工的ROI最高。
所以虽然机器学习是以算法为主的系统，但是也不能思维僵化，凡事都只想着用算法解决，有的地方，还是小米加步枪比较合适。
关键流程和数据没有掌握在自己团队
这个坑，可以说不是一个容易发现的坑，尤其是在系统初期，是比较隐蔽的。我们也是在吃了一些亏之后才发现这个问题的。
在很多公司里，前端展示，日志收集等工作是有专门的团队负责的，而诸如推荐广告这样的团队是直接拿来用的。这样做的好处很明显，可以让机器学习团队专注于本职工作，但是不好的一面是，他们收集到的数据并不总是我们期望得到的。
举个例子。我们一开始使用的曝光数据是兄弟团队帮我们做的，但是我们拿来之后发现和其他数据不太对的上，找了很久才找到问题。这个问题直接影响到我们拿到的样本的正确与否，所以对我们的影响非常的大。
那造成这个问题的原因是什么呢？其实并不是兄弟团队不认真，而是他们并不完全理解我们对数据的需求，他们也不使用该数据，所以数据的质量就会有风险。吃了这一亏之后，我们现在把这部分工作也拿来自己做，这样数据正确与否我们可以全程监控，出了问题也可以自己内部解决，不用协调各种资源。
团队不够“全栈”
这个坑是一个比较复杂的坑。在上一个坑中，我提到我们发现了数据质量有问题，之后自己做了这部分曝光收集的工作。但是定位问题原因和自己接手并不是在数据一有问题的时候就做到的。原因既简单又残酷：我们组里当时没有前端人才。
因为曝光问题涉及到从浏览器到后台系统的一系列动作，而前端是这些动作的第一个环节。但是我们在组件机器学习团队的时候，并没有意识到这里面会有前端什么事，以为有后台+模型的人就够了。所以导致我们面对这个问题比较无力。直到后来有一位有着丰富前端经验的同事加入我们组，我们才定位到问题，并且做出了自己接手的决定。
这个问题给我们的教训是：组建团队的时候要更谨慎一些，要从更系统的角度看待，不能说做机器学习就只招算法工程师，这样会导致团队级的短板，为一些问题埋下伏笔。
不过有的问题在遇到之前可能也难以预测，所以这个坑确实比较复杂。
巨型系统
最后一个坑，当然也要留给一个大坑。这个坑我称之为“巨型系统”。
巨型系统是什么意思呢？简单来说，就是把整个系统做成“一个”系统，而不是分模块做成多个子系统。做成一个系统的含义就是系统内部的模块之间有着高耦合性，强关联性，样本、特征、训练、预测等等全部粘在一起，无法分离。这样做的后果是什么？
直接举例子。我们第一版的系统，光上线就上了得有一周。而且之后的维护相当困难，想改东西非常困难。为什么会做成这样的，我的反思是：在学习理论的时候，就想当然得把样本、特征、训练这个pipeline当做一套东西了，这种思维直接反应到系统里就是一个巨型系统。或许在你只有十几个特征，几百条样本的时候没有问题。但是当你特征涨到几百万，样本涨到几千万的时候，就需要好好想一下，你的系统是不是有点大得失控了。
那更好的做法是什么呢？我们后来的解决方法是：大系统小做。“大系统小做”这个说法不是我发明的，是今年春节后（或者是去年）看到微信团队在说抢红包系统架构时说到的一个概念。我觉得这个说法提炼得很好，表示非常赞同。这个做法的意思就是，虽然你的系统很庞大，很复杂，但是做的时候还是要做好模块分离，这样利于开发，也利于扩展、维护。
机器学习系统的特点在于，刚开始你可能用的特征什么的都很少，所以觉得一个系统里就可以搞定，但是做着做着，需要对特征做各种变换，样本做各种处理，系统会在不知不觉中变得庞大，而如果你只关注模型的话，很容易造出一个无法维护的巨型系统来。
万里长征刚起步
我们的团队在经历了刚刚这许多“坑”之后，一个系统可以说是搭建起来了，但是这只是万里长征的第一步。对于我们如此，其实对于机器学习系统这个新事物，本身也有着不同于传统软件系统的诸多复杂之处，还有很多的挑战需要去解决。我在这里用两篇参考文献简单介绍一下这些复杂之处，以及面对的挑战。有兴趣深入了解的同学可以找文章具体看看。

第一篇是Google Research****的一篇paper****，讲的是机器学习技术债。题目也很有意思，可以翻译为：“机器学习：高利息的技术债信用卡”。
这篇文章主要说的是机器学习系统的搭建非常地复杂，如果缺乏经验，或者不够谨慎，在许多环节就容易“欠债”，这些债务当时觉得影响不大，但是由于“利息”很高，到后来会让你还起来很痛苦。
上图是我看了文章之后根据文章自己整理的，技术债的几个具体维度。这几个维度和我们自己的实践也是高度吻合的，当时看文章也是满膝盖的箭。
例如图中右上提到的“子系统边界模糊”，和我之前说过的“巨型系统”有类似之处，说的也是系统内部无分割。
再例如右下提到的“system-level spaghtti(系统级意大利面)”。意大利面代码常用来指代乱成一团的代码，由于机器学习系统一般都是在探索中搭建起来的，不像其他系统那样完全设计好再搭建，所以很容易产生意大利面代码。
如果能在搭系统之前参照这些维度加以考虑，那么系统的开发、升级和维护会轻松很多。相信这些经验也是Google这样的巨头公司摔了很多坑总结出来的。巨头尚且如此，对我们来说自然也不简单。

接下来这篇文章是现在在FB****的SGD****大牛Leon Bottou****在ICML 2015****上做的一个tutorial。题目叫：Two big challenges in machine learning，是一篇比较偏系统实践的文章，说的是机器学习面临的两个新的挑战。
第一点就非常地骇人听闻：机器学习破坏了软件工程。但是仔细想来，确实如此。机器学习系统的开发流程大多是探索式、渐进式的，这一点和传统的软件工程非常不同，这就给系统开发者们提出了挑战。我觉得以后很可能会出现专门的“机器学习系统架构师”职位。
第二点说的是当前的实验方式方法也遇到了极限。这一点乍一看是说科学实验的，其实不然。机器学习系统开发由于是探索式的，所以在开发中要经常做各种实验，验证各种效果，这个整体方法框架，也是需要精心设计的。显然在Bottou看来，目前的方法都不太合适。