作者:张相於
本文是对<Rules of Machine Learning: Best Practices for ML Engineering>一文的翻译+解读。看过我翻译文章的同学知道我翻译文章一般都不太老实,没有那么“忠于原著”,本篇也不例外,本篇对于原文的解读大概有三种形式:
这种形式对于有的同学来讲可能会对原文信息有所损失,所以想要读到原文的同学,可以在这里找到原文:http:// martin.zinkevich.org/ru les_of_ml/rules_of_ml.pdf 。 或者去搜一些其他人比较忠于原著的翻译。
什么样的NB人物写东西敢起号称”Rules of Machine Learning”这种不怕闪了腰的题目?首先我们来简单介绍一下本文的作者Martin Zinkevich。
Martin Zinkevich现在是谷歌大脑的高级科学家,负责和参与了YouTube、Google Play 以及Google Plus等产品中的机器学习项目。在加入谷歌之前是雅虎的高级科学家,曾在2010年和2011年两度获得雅虎的最高荣誉Yahoo Team Superstar Awards,对雅虎的广告系统做出过很多杰出贡献。
拥有如此NB的背景,我们有理由相信这哥们儿写出来的东西还是具有足够的参考价值的。
本文把在产品中应用机器学习的过程从浅到深分成了三个大的阶段,又在这三个大的阶段中细分出了一些方面,以此对43条规则进行逻辑分类。简单来说,如果你是从头开始做机器学习系统,那么就可以在不同阶段参考这里面对应的条目,来保证自己走在正确的道路上。
To make great products:
do machine learning like the great engineer you are, not like the great machine learning expert you aren’t.
这句话一定程度上是对整篇文章(叫手册可能更合适)的一个高度概括,ML在实际工作确实更多是工程问题,而不是算法问题。优先从工程效率中要效果,当把这部分榨干后,再考虑算法的升级。
中心思想一句话概括:If you think that machine learning will give you a 100% boost, then a heuristic will get you 50% of the way there.
在构建具体的机器学习系统之前,首先在当前系统中记录尽量详细的历史信息,留好特征数据。这样不仅能够留好特征数据,还能够帮助我们随时了解系统的状态,以及做各种改动时系统的变化。
简单来讲,复杂的规则系统难以维护,不可扩展,而我们很简单就可以转为ML系统,变得可维护可扩展。
构建第一个ML系统时,一定要更多关注系统架构的建设。虽然机器学习的算法令人激动,但是基础架构不给力找不到问题时会令人抓狂。
第一版模型的核心思想是抓住主要特征、与应用尽量贴合以及快速上线。
确保架构是可单独测试的,将系统的训练部分进行封装,以确保其他部分都是可测试的。特别来讲:
从一个场景复制数据到另一个场景时,要注意两边对数据的要求是否一致,是否有数据丢失的情况。
机器学习系统解决的问题通常都不是新问题,而是对已有问题的进一步优化。这意味着有很多已有的规则或者启发式规则可供使用。这部分信息应该被充分利用(例如基于规则的推荐排序时用到的排序规则)。下面是几种启发式规则可以被使用的方式:
已有的启发式规则可以帮助机器学习系统更平滑的过渡,但是也要考虑是否有同等效果更简单的实现方式。
概括来讲,要保持好的监控习惯,例如使报警是可应对的,以及建设一个Dashboard页面。
如果模型延迟一天更新,你的系统会受到多大的效果影响?如果是一周的延迟呢?或者更久?这个信息可以让我们排布监控的优先级。如果模型一天不更新收入就会下降10%,那么可以考虑让一个工程师全天候监控它。了解系统对新鲜度的要求是决定具体监控方案的第一步。
模型上线前一定要做完整性、正确性检查,例如AUC、Calibration、NE等指标的计算确认等。如果是模型上线前出了问题,可以邮件通知,如果是用户正在使用的模型出了问题,就需要电话通知了。
这是一个非常重要,而又经常容易被忽略的问题。所谓的静默失败指的是全部流程都正常完成,但是背后依赖数据出了问题,导致模型效果逐步下降的问题。这种问题在其他系统中并不常出现,但是在机器学习系统中出现几率会比较高。例如训练依赖的某张数据表很久没有更新了,或者表中的数据含义发生了变化等,再或者数据的覆盖度忽然变少,都会对效果产生很大的影响。解决方法是是对关键数据的统计信息进行监控,并且周期性对关键数据进行人工检查。
这里的feature column指的是一个特征组,例如用户可能属于的国家这组特征就是一个feature column。
如果系统庞大,数据繁多,那么知道每组数据由谁生成就变得非常重要。虽然数据都有简单描述,但是关于特征的具体计算逻辑,数据来源等都需要更详细的记录。
objective是模型试图优化的值,而metric指的是任何用来衡量系统的值。
机器学习上线的初期,即使你只优化一个目标,很多指标一般都会一起上涨的。所以不用太纠结究竟该优化哪个。
虽然大佬这么说,但是在我自己的实践经验中,只优化一个目标,系统的整体效果却未必会上涨。典型的如推荐系统的CTR模型,上线之后CTR确实会提升,但是对应的CVR很有可能会下降,这时还需要一个CVR模型,两个模型同时使用才能真正提升系统效果。究其原因,是因为每个目标只关注系统整个过程的一个子过程,贪心地去优化这个子过程,不一定能够得到全局的最优解,通常需要把主要的几个子过程都优化之后,才能取得整体效果的提升。
objective应该是简单可衡量的,并且是metric的有效代理。最适合被建模的是可直接观测并被归因的行为,例如:
尽量不要在第一次就建模非直接效果的行为,例如:
非直接指标是很好的metric,可以用ABTest来进行观测,但不适合用作优化指标。此外,千万不要试图学习以下目标:
这些指标非常重要,但是非常难以学习。应该使用一些代理指标来学习,通过优化代理指标来优化这些非直接指标。为了公司的发展着想,最好有人工来连接机器学习的学习目标和产品业务。
优先选择预测结果有概率含义、预测过程可解释的模型,可以更容易的确认效果,debug问题。例如,如果使用LR做分类,那么预测过程不外乎一些相乘和相加,如果特征都做了离散化,就只有加法了,这样很容易debug一条样本的预测得分是如何被计算出来的。所以出了问题很容易debug。
排序系统工作的环境中数据分布是相对静态的,大家为了得到更好的排序,会遵守系统制定的规则。但是垃圾过滤更多是个对抗性质的工作,数据分布会经常变动。所以不应该让排序系统去处理垃圾信息的过滤,而是应该有单独的一层去处理垃圾信息。这也是一种可以推广的思想,那就是:排序层只做排序层的事情,职责尽量单一,其他工作让架构上更合适的模块去处理。此外,为了提升模型效果,应该把垃圾信息从训练数据中去除。
前面第一阶段的重点是把数据喂到学习系统中,有了基础的监控指标,有了基础的架构。等这一套系统建立起来后,第二阶段就开始了。
整体来讲,第二阶段的核心工作是将尽量多的有效特征加入到第一版的系统中,一般都可以取得提升。
简单来说,就是要深刻认识到,系统优化永远没有终点,所以系统设计方面要对迭代非常友好。例如增加删除特征是否足够简单,正确性验证是否足够简单,模型迭代是否可以并行运行,等等。
这虽然不是一条具体可行动的(actionable)规则,但是这种思想上的准备对整个系统的开发很有帮助。只有真正深刻意识到了系统持续迭代上线的本质,才会在设计在线和离线架构时为持续迭代最好相应的设计,并做好相应的工具,而不是做一锤子系统。
所谓学习出来的特征,指的是用另外的算法学习出来的特征,而非可以直接观测或收集到的简单特征。学习出来的特征由于存在外部依赖,或者计算逻辑复杂,不一定适用于你当前的模型,所以稳定性和有效性会有风险。而直接可观测的特征由于是相对比较客观的,依赖较少的,所以比较稳定。
中心思想是在说,要多利用可以在多个场景下使用的特征,例如全局的点击率、浏览量这些特征,可以在多个场景下作为特征使用。这样可以在一些冷启动或者缺乏有效特征的场景下作为特征使用。
如果数据量足够大,那么相比少数复杂特征,使用海量简单特征是更简单有效的选择。
所谓非常具体,指的是覆盖样本量比较少的特征,例如文档的ID或者query的ID等。这样的特征虽然每个只覆盖很少一部分特征,但是只要这一组特征整体能够覆盖率比较高,例如90%,那就是OK的。而且还可以通过正则化来消除覆盖率过低或者相关性差的特征。这也是大家都偏爱大规模ID特征的一个原因,现在很多大厂的排序模型特征都大量使用了大规模ID特征。
离散化和交叉是最常用的两种特征使用方式。其本质都是用特征工程的方式,在不改变使用模型本身的情况下增加模型的非线性。这两种方法本身没什么好说的,值得一致的是,在大规模ID类特征的交叉时,例如一段是query里的关键词,另一端是文档里的关键词,那就会产生很大量级的交叉特征,这时有两种处理方法:
所谓“人类可理解的方式”,我的理解就是离散化和交叉要基于对业务逻辑的理解,不能乱交叉。
这背后有复杂的统计原理做支撑,但你只需要知道结论就可以了。这个原则给我们的启示,是要根据数据量来选择特征的生成方式,例如:
总结起来就是,根据样本决定特征使用方式,样本不够就对特征进行高层次抽象处理,指导和样本量级相匹配。
如果某个特征已经没有用,并且它与其他特征的交叉也已经没有用,就应该将其清理掉,保持架构的整洁性。
在考虑添加或保留哪些特征时,需要统计一下特征的样本覆盖率,例如一些整体覆盖率很低的个性化feature column,只有很少用户能覆盖到,那么大概率这组特征作用不大。但另一方面,如果某个特征覆盖率很低,例如只有1%,但是其区分度非常大,例如90%取值为1的样本都是正样本,那么 这个特征就值得加入或保留。
未完待续……
End.
来源: http://www.36dsj.com/archives/100052