机器学习43条军规:解密谷歌机器学习工程最佳实践(上)

从零开始学运营,10年运营老司机带路,2天线下集训+1年在线学习,做个优秀的运营人。了解详情

文章把在产品中应用机器学习的过程从浅到深分成了三个大的阶段,又在这三个大的阶段中细分出了一些方面,以此对43条规则进行逻辑分类。一起来学习下。

本文是对<Rules of Machine Learning: Best Practices for ML Engineering>一文的翻译+解读。看过我翻译文章的同学知道我翻译文章一般都不太老实,没有那么“忠于原著”,本篇也不例外,本篇对于原文的解读大概有三种形式:

  1. 原文翻译。对于作者本身阐述的比较好,而我也没什么可补充的部分,基本会原文翻译。
  2. 半翻译半解读。有的条目我觉得有些自己的经验和感想可以和大家分享,就会加一些自己的解读在里面。
  3. 省略。还有一些时候我觉得作者说的太仔(luo)细(suo),或者这个条目说得比较基本,无需太多解释,我就会不同程度的省略原文。

这种形式对于有的同学来讲可能会对原文信息有所损失,所以想要读到原文的同学,可以在这里找到原文。 或者去搜一些其他人比较忠于原著的翻译。

作者介绍

什么样的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在实际工作确实更多是工程问题,而不是算法问题。优先从工程效率中要效果,当把这部分榨干后,再考虑算法的升级。

Before Machine Learning

Rule #1: Don’t be afraid to launch a product without machine learning.

规则1:不要害怕上线没有机器学习的产品。

中心思想一句话概括:If you think that machine learning will give you a 100% boost, then a heuristic will get you 50% of the way there.

Rule #2: First, design and implement metrics.

规则2:在动手之前先设计和实现评价指标。

在构建具体的机器学习系统之前,首先在当前系统中记录尽量详细的历史信息,留好特征数据。这样不仅能够留好特征数据,还能够帮助我们随时了解系统的状态,以及做各种改动时系统的变化。

Rule #3: Choose machine learning over a complex heuristic.

规则3:不要使用过于复杂的规则系统,使用机器学习系统。

简单来讲,复杂的规则系统难以维护,不可扩展,而我们很简单就可以转为ML系统,变得可维护可扩展。

ML Phase I: Your First Pipeline

构建第一个ML系统时,一定要更多关注系统架构的建设。虽然机器学习的算法令人激动,但是基础架构不给力找不到问题时会令人抓狂。

Rule #4: Keep the first model simple and get the infrastructure right.

规则4:第一个模型要简单,但是架构要正确。

第一版模型的核心思想是抓住主要特征、与应用尽量贴合以及快速上线。

Rule #5: Test the infrastructure independently from the machine learning.

规则5:独立于机器学习来测试架构流程。

确保架构是可单独测试的,将系统的训练部分进行封装,以确保其他部分都是可测试的。特别来讲:

  1. 测试数据是否正确进入训练算法。检查具体的特征值是否符合预期。
  2. 测试实验环境给出的预测结果与线上预测结果是否一致。

Rule #6: Be careful about dropped data when copying pipelines.

规则6:复制pipeline时要注意丢弃的数据。

从一个场景复制数据到另一个场景时,要注意两边对数据的要求是否一致,是否有数据丢失的情况。

Rule #7: Turn heuristics into features, or handle them externally.

规则7:将启发规则转化为特征,或者在外部处理它们。

机器学习系统解决的问题通常都不是新问题,而是对已有问题的进一步优化。这意味着有很多已有的规则或者启发式规则可供使用。这部分信息应该被充分利用(例如基于规则的推荐排序时用到的排序规则)。下面是几种启发式规则可以被使用的方式:

  1. 用启发规则进行预处理。如果启发式规则非常有用,可以这么用。例如在垃圾邮件识别中,如果有发件人已经被拉黑了,那么就不要再去学“拉黑”意味着什么,直接拉黑就好了。
  2. 制造特征。可以考虑从启发式规则直接制造一个特征。例如,你使用启发式规则来计算query的相关性,那么就可以把这个相关性得分作为特征使用。后面也可以考虑将计算相关性得分的原始数据作为特征,以期获得更多的信息。
  3. 挖掘启发式规则的原始输入。如果有一个app的规则启发式规则综合了下载数、标题文字长度等信息,可以考虑将这些原始信息单独作为特征使用。
  4. 修改label。当你觉得启发式规则中包含了样本中没有包含的信息时可以这么用。例如,如果你想最大化下载数,同时还想要追求下载内容的质量。一种可行的方法是将label乘以app的平均star数。在电商领域,也常常用类似的方法,例如在点击率预估的项目中,可考虑对最终下单的商品或者高质量的商品对应的样本增加权重。

已有的启发式规则可以帮助机器学习系统更平滑的过渡,但是也要考虑是否有同等效果更简单的实现方式。

Monitoring

概括来讲,要保持好的监控习惯,例如使报警是可应对的,以及建设一个Dashboard页面。

Rule #8: Know the freshness requirements of your system.

规则8:了解你系统对新鲜度的要求。

如果模型延迟一天更新,你的系统会受到多大的效果影响?如果是一周的延迟呢?或者更久?这个信息可以让我们排布监控的优先级。如果模型一天不更新收入就会下降10%,那么可以考虑让一个工程师全天候监控它。了解系统对新鲜度的要求是决定具体监控方案的第一步。

Rule #9: Detect problems before exporting models.

规则9:在模型上线之前检测问题。

模型上线前一定要做完整性、正确性检查,例如AUC、Calibration、NE等指标的计算确认等。如果是模型上线前出了问题,可以邮件通知,如果是用户正在使用的模型出了问题,就需要电话通知了。

Rule #10: Watch for silent failures.

规则10:关注静默失败。

这是一个非常重要,而又经常容易被忽略的问题。所谓的静默失败指的是全部流程都正常完成,但是背后依赖数据出了问题,导致模型效果逐步下降的问题。这种问题在其他系统中并不常出现,但是在机器学习系统中出现几率会比较高。例如训练依赖的某张数据表很久没有更新了,或者表中的数据含义发生了变化等,再或者数据的覆盖度忽然变少,都会对效果产生很大的影响。解决方法是是对关键数据的统计信息进行监控,并且周期性对关键数据进行人工检查。

Rule #11: Give feature column owners and documentation.

规则11:给特征组分配负责人,并记录文档。

这里的feature column指的是一个特征组,例如用户可能属于的国家这组特征就是一个feature column。

如果系统庞大,数据繁多,那么知道每组数据由谁生成就变得非常重要。虽然数据都有简单描述,但是关于特征的具体计算逻辑,数据来源等都需要更详细的记录。

Your Fist Objective

objective是模型试图优化的值,而metric指的是任何用来衡量系统的值。

Rule #12: Don’t overthink which objective you choose to directly optimize.

规则12:不要过于纠结该优化哪个目标。

机器学习上线的初期,即使你只优化一个目标,很多指标一般都会一起上涨的。所以不用太纠结究竟该优化哪个。

虽然大佬这么说,但是在我自己的实践经验中,只优化一个目标,系统的整体效果却未必会上涨。典型的如推荐系统的CTR模型,上线之后CTR确实会提升,但是对应的CVR很有可能会下降,这时还需要一个CVR模型,两个模型同时使用才能真正提升系统效果。究其原因,是因为每个目标只关注系统整个过程的一个子过程,贪心地去优化这个子过程,不一定能够得到全局的最优解,通常需要把主要的几个子过程都优化之后,才能取得整体效果的提升。

Rule #13: Choose a simple, observable and attributable metric for your first objective.

规则13:为你的第一个objective选择一个简单可观测可归因的metric。

objective应该是简单可衡量的,并且是metric的有效代理。最适合被建模的是可直接观测并被归因的行为,例如:

  1. 链接是否被点击?
  2. 软件是否被下载?
  3. 邮件是否被转发?
    ……

尽量不要在第一次就建模非直接效果的行为,例如:

  1. 用户第二天是否会访问?
  2. 用户在网站上停留了多久?
  3. 日活用户有多少?

非直接指标是很好的metric,可以用ABTest来进行观测,但不适合用作优化指标。此外,千万不要试图学习以下目标:

  1. 用户对产品是否满意?
  2. 用户对体验是否满意?
    ……

这些指标非常重要,但是非常难以学习。应该使用一些代理指标来学习,通过优化代理指标来优化这些非直接指标。为了公司的发展着想,最好有人工来连接机器学习的学习目标和产品业务。

Rule #14: Starting with an interpretable model makes debugging easier.

规则14:使用可解释性强的模型可降低debug难度。

优先选择预测结果有概率含义、预测过程可解释的模型,可以更容易的确认效果,debug问题。例如,如果使用LR做分类,那么预测过程不外乎一些相乘和相加,如果特征都做了离散化,就只有加法了,这样很容易debug一条样本的预测得分是如何被计算出来的。所以出了问题很容易debug。

Rule #15: Separate Spam Filtering and Quality Ranking in a Policy Layer.

规则15:将垃圾过滤和质量排序的工作分离,放到策略层(policy layer)。

排序系统工作的环境中数据分布是相对静态的,大家为了得到更好的排序,会遵守系统制定的规则。但是垃圾过滤更多是个对抗性质的工作,数据分布会经常变动。所以不应该让排序系统去处理垃圾信息的过滤,而是应该有单独的一层去处理垃圾信息。这也是一种可以推广的思想,那就是:排序层只做排序层的事情,职责尽量单一,其他工作让架构上更合适的模块去处理。此外,为了提升模型效果,应该把垃圾信息从训练数据中去除。

ML Phase II: Feature Engineering

前面第一阶段的重点是把数据喂到学习系统中,有了基础的监控指标,有了基础的架构。等这一套系统建立起来后,第二阶段就开始了。

整体来讲,第二阶段的核心工作是将尽量多的有效特征加入到第一版的系统中,一般都可以取得提升。

Rule #16: Plan to launch and iterate.

规则16:做好持续迭代上线的准备。

简单来说,就是要深刻认识到,系统优化永远没有终点,所以系统设计方面要对迭代非常友好。例如增加删除特征是否足够简单,正确性验证是否足够简单,模型迭代是否可以并行运行,等等。

这虽然不是一条具体可行动的(actionable)规则,但是这种思想上的准备对整个系统的开发很有帮助。只有真正深刻意识到了系统持续迭代上线的本质,才会在设计在线和离线架构时为持续迭代最好相应的设计,并做好相应的工具,而不是做一锤子系统。

Rule #17: Start with directly observed and reported features as opposed to learned features.

规则17:优先使用直接观测或收集到的特征,而不是学习出来的特征。

所谓学习出来的特征,指的是用另外的算法学习出来的特征,而非可以直接观测或收集到的简单特征。学习出来的特征由于存在外部依赖,或者计算逻辑复杂,不一定适用于你当前的模型,所以稳定性和有效性会有风险。而直接可观测的特征由于是相对比较客观的,依赖较少的,所以比较稳定。

Rule #18: Explore with features of content that generalize across contexts.

规则18:探索使用可以跨场景的内容特征。

中心思想是在说,要多利用可以在多个场景下使用的特征,例如全局的点击率、浏览量这些特征,可以在多个场景下作为特征使用。这样可以在一些冷启动或者缺乏有效特征的场景下作为特征使用。

Rule #19: Use very specific features when you can.

规则19:尽量使用非常具体的特征。

如果数据量足够大,那么相比少数复杂特征,使用海量简单特征是更简单有效的选择。

所谓非常具体,指的是覆盖样本量比较少的特征,例如文档的ID或者query的ID等。这样的特征虽然每个只覆盖很少一部分特征,但是只要这一组特征整体能够覆盖率比较高,例如90%,那就是OK的。而且还可以通过正则化来消除覆盖率过低或者相关性差的特征。这也是大家都偏爱大规模ID特征的一个原因,现在很多大厂的排序模型特征都大量使用了大规模ID特征。

Rule #20: Combine and modify existing features to create new features in human­-understandable ways.

规则20:用人类可理解的方式对已有特征进行组合、修改来得到新特征。

离散化和交叉是最常用的两种特征使用方式。其本质都是用特征工程的方式,在不改变使用模型本身的情况下增加模型的非线性。这两种方法本身没什么好说的,值得一致的是,在大规模ID类特征的交叉时,例如一段是query里的关键词,另一端是文档里的关键词,那就会产生很大量级的交叉特征,这时有两种处理方法:

  1. 点积。其实计算query和文档共同包含的关键词数量。
  2. 交集。每一维特征的含义是某个词同时出现在了query和文档中,同时出现则该维特征为1,否则为0。

所谓“人类可理解的方式”,我的理解就是离散化和交叉要基于对业务逻辑的理解,不能乱交叉。

Rule #21: The number of feature weights you can learn in a linear model is roughly proportional to the amount of data you have.

规则21:线性模型中可学到的特征权重数量,与训练数据的数量大体成正比。

这背后有复杂的统计原理做支撑,但你只需要知道结论就可以了。这个原则给我们的启示,是要根据数据量来选择特征的生成方式,例如:

  1. 如果你的系统是一个搜索系统,query和文档中有百万级的词,但是你只有千级别的标注样本。那你就别用ID级关键词特征了,而是要考虑点积类特征,把特征数量控制在几十个这个级别。
  2. 如果你拥有百万级样本,那么可以将文档和query的关键词进行交叉特征,然后用正则化进行特征选择。这样你会得到百万级特征,但是正则化之后会更少。所以说,千万级样本,十万级特征。
  3. 如果你有十亿级或者更高级别的样本,那么你可以使用query和文档的ID级特征,然后加上特征选择和正则化。十亿级样本,千万级特征。

总结起来就是,根据样本决定特征使用方式,样本不够就对特征进行高层次抽象处理,指导和样本量级相匹配。

Rule #22: Clean up features you are no longer using.

规则22:清理不再使用的特征。

如果某个特征已经没有用,并且它与其他特征的交叉也已经没有用,就应该将其清理掉,保持架构的整洁性。

在考虑添加或保留哪些特征时,需要统计一下特征的样本覆盖率,例如一些整体覆盖率很低的个性化feature column,只有很少用户能覆盖到,那么大概率这组特征作用不大。但另一方面,如果某个特征覆盖率很低,例如只有1%,但是其区分度非常大,例如90%取值为1的样本都是正样本,那么 这个特征就值得加入或保留。

未完待续……

End.

 

作者:张相於

来源:http://www.36dsj.com/archives/100052

本文来源于人人都是产品经理合作媒体@36大数据,作者@张相於

题图来自PEXELS,基于CC0协议

打赏也是一种认可
评论
有话不说憋着难受!