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

从零开始学运营,10年运营老司机带路,2天线下集训+1年在线学习,做个优秀的运营人。了解详情
文章把在产品中应用机器学习的过程从浅到深分成了三个大的阶段,又在这三个大的阶段中细分出了一些方面,以此对43条规则进行逻辑分类。一起来学习下。
本文是对<Rules of Machine Learning: Best Practices for ML Engineering>一文的翻译+解读。看过我翻译文章的同学知道我翻译文章一般都不太老实,没有那么“忠于原著”,本篇也不例外,本篇对于原文的解读大概有三种形式:
  • 原文翻译。对于作者本身阐述的比较好,而我也没什么可补充的部分,基本会原文翻译。
  • 半翻译半解读。有的条目我觉得有些自己的经验和感想可以和大家分享,就会加一些自己的解读在里面。
  • 省略。还有一些时候我觉得作者说的太仔(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:独立于机器学习来测试架构流程。 确保架构是可单独测试的,将系统的训练部分进行封装,以确保其他部分都是可测试的。特别来讲:
  • 测试数据是否正确进入训练算法。检查具体的特征值是否符合预期。
  • 测试实验环境给出的预测结果与线上预测结果是否一致。
  • Rule #6: Be careful about dropped data when copying pipelines.

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

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

    规则7:将启发规则转化为特征,或者在外部处理它们。 机器学习系统解决的问题通常都不是新问题,而是对已有问题的进一步优化。这意味着有很多已有的规则或者启发式规则可供使用。这部分信息应该被充分利用(例如基于规则的推荐排序时用到的排序规则)。下面是几种启发式规则可以被使用的方式:
  • 用启发规则进行预处理。如果启发式规则非常有用,可以这么用。例如在垃圾邮件识别中,如果有发件人已经被拉黑了,那么就不要再去学“拉黑”意味着什么,直接拉黑就好了。
  • 制造特征。可以考虑从启发式规则直接制造一个特征。例如,你使用启发式规则来计算query的相关性,那么就可以把这个相关性得分作为特征使用。后面也可以考虑将计算相关性得分的原始数据作为特征,以期获得更多的信息。
  • 挖掘启发式规则的原始输入。如果有一个app的规则启发式规则综合了下载数、标题文字长度等信息,可以考虑将这些原始信息单独作为特征使用。
  • 修改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的有效代理。最适合被建模的是可直接观测并被归因的行为,例如:
  • 链接是否被点击?
  • 软件是否被下载?
  • 邮件是否被转发?
    ……
  • 尽量不要在第一次就建模非直接效果的行为,例如:
  • 用户第二天是否会访问?
  • 用户在网站上停留了多久?
  • 日活用户有多少?
  • 非直接指标是很好的metric,可以用ABTest来进行观测,但不适合用作优化指标。此外,千万不要试图学习以下目标:
  • 用户对产品是否满意?
  • 用户对体验是否满意?
    ……
  • 这些指标非常重要,但是非常难以学习。应该使用一些代理指标来学习,通过优化代理指标来优化这些非直接指标。为了公司的发展着想,最好有人工来连接机器学习的学习目标和产品业务。

    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里的关键词,另一端是文档里的关键词,那就会产生很大量级的交叉特征,这时有两种处理方法:
  • 点积。其实计算query和文档共同包含的关键词数量。
  • 交集。每一维特征的含义是某个词同时出现在了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:线性模型中可学到的特征权重数量,与训练数据的数量大体成正比。 这背后有复杂的统计原理做支撑,但你只需要知道结论就可以了。这个原则给我们的启示,是要根据数据量来选择特征的生成方式,例如:
  • 如果你的系统是一个搜索系统,query和文档中有百万级的词,但是你只有千级别的标注样本。那你就别用ID级关键词特征了,而是要考虑点积类特征,把特征数量控制在几十个这个级别。
  • 如果你拥有百万级样本,那么可以将文档和query的关键词进行交叉特征,然后用正则化进行特征选择。这样你会得到百万级特征,但是正则化之后会更少。所以说,千万级样本,十万级特征。
  • 如果你有十亿级或者更高级别的样本,那么你可以使用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协议
    打赏也是一种认可
    评论
    有话不说憋着难受!
    钱柜娱乐777