机器学习43条军规：解密谷歌机器学习工程最佳实践（上）
摘要： 本文译者张相於，首发于微信公号ResysChina（resyschina），「AI早餐汇」经授权转载。以下为注解和编译的内容： 本文是对一文的翻译+解读。
本文译者张相於，首发于微信公号ResysChina（resyschina），「AI早餐汇」经授权转载。以下为注解和编译的内容：
本文是对<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的样本都是正样本，那么 这个特征就值得加入或保留。
译者信息：
张相於，现任转转推荐系统负责人，负责转转的推荐系统。曾任当当网推荐系统开发经理，多年来主要从事推荐系统以及机器学习相关工作，也做过反垃圾、反作弊相关工作，并热衷于探索大数据技术&机器学习技术在其他领域的应用实践。
原文发布时间为：2017-09-19
本文作者：张相於
本文来自云栖社区合作伙伴“AI早餐汇”，了解相关信息可以关注“AI早餐汇”微信公众号
