机器学习条军规解密谷歌机器学习工程最佳实践上
⇨⇦
文章把在产品中应用机器学习的过程从浅到深分成了三个大的阶段，又在这三个大的阶段中细分出了一些方面，以此对43条规则进行逻辑分类。一起来学习下。
本文是对<rules of=＂＂ machine=＂＂ learning:=＂＂ best=＂＂ practices=＂＂ for=＂＂ ml=＂＂ engineering=＂＂>一文的翻译+解读。看过我翻译文章的同学知道我翻译文章一般都不太老实，没有那么＂忠于原著＂，本篇也不例外，本篇对于原文的解读大概有三种形式：</rules>
原文翻译。对于作者本身阐述的比较好，而我也没什么可补充的部分，基本会原文翻译。
半翻译半解读。有的条目我觉得有些自己的经验和感想可以和大家分享，就会加一些自己的解读在里面。
省略。还有一些时候我觉得作者说的太仔（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.