Rules of Machine Learning: Best Practices for ML Engineering

DoubleV

发布于 2018-09-12 15:18:25

9440

发布于 2018-09-12 15:18:25

文章被收录于专栏：GAN&CVGAN&CV

原文地址：https://developers.google.com/machine-learning/rules-of-ml/ 作者：Martin Zinkevich

前言

Google大佬Martin Zinkevic近期写了一篇机器学习（ML）学习经验的文档，干货多多，特翻译过来分享给大家。

Martin Zinkevich：本文档旨在帮助具有机器学习基本知识的人员了解Google在机器学习方面的最佳实践。本文提供了机器学习的学习指南，类似于Google C ++风格指南和其他实用编程的流行指南。如果你学过机器学习课程或者有实践经验，那么你已经拥有了机器学习的背景知识。

术语：

在开始分享整个工作之前，先来阐述一些术语：

Instance：实例。需要预测的事物称为实例。例如，该实例可能是您要分类为“关于猫”或“不关于猫”的一个网页，或者其他类别。 Label：标签。待预测任务的真实结果称为标签。无论是机器学习系统预测的结果，还是训练数据的结果，都称为标签。例如，将网页标记为“关于猫的”，“关于猫的”就是标签。 Feature：特征。预测任务中使用的实例的属性。例如，一个网页可能有一个功能“包含单词’猫’”。 Feature Column: 特征集合。比如用户可能居住的国家，Feature Column包含实例的一个或者多个特征，它是Google制定的的术语，在其他系统中类似命名空间。 Example：instance+label Model：模型。预测任务的统计表示。使用实例训练模型，然后使用该模型进行预测。 Metric：度量指标。评价指标，有的可以直接优化有的不行。 Objective：工程中希望去优化的一个Metric。 Pipeline：围绕机器学习算法的基础步骤或流程。包括数据收集，制作成训练数据，模型训练以及最后的模型预测。 Click-through Rate：点击率，比如访问者点击网页中广告的比例。

概述

要想做好一个机器学习产品，只需要做到：

以一个伟大的机器学习工程师，和机器学习专家的心态去做机器学习

实际上，你将面临的大部分问题都是工程问题。对于工程来说，特征（Features）为王，越好的结果更依赖于好的特征，而不是一个伟大的机器学习算法。所以，机器学习的基本的方法是：

确保你的pipeline是端对端稳定的
确定一个合理的objective
以简单的方式增加寻常意义的特征-features。
确保你的pipeline仍然稳定

在学习前期，这个方法可以陪伴你很久。只有使用更多的tricks无法更近一步时，才会从这种方法中分化出来，在此基础上增加复杂度，但是方法越复杂，所耗费的时间精力越多。当所有简单的trick用完后，就可以开始一些尖端的机器学习技术了。本文包括四个部分：

第一部分应该帮助您了解遇到的情况是否适合建立机器学习技术解决。
第二部分是关于部署你的pipeline
第三部分是向pipeline中增加特征，评估模型和训练偏差，不断迭代这个过程。
最后一部分是遇到瓶颈时该怎么做。

之后，有一份相关工作清单和一份附录

序言：写在正文开始之前

法则1

rule #1：Don’t be afraid to launch a product without machine learning. 不要担心发布的产品没有用到机器学习技术

机器学习很酷，但它需要数据。理论上，您可以从不同的问题中获取数据，然后调整新产品的模型，但这可能会比基本启发式算法差。如果你认为机器学习会给你100％的提升，那么启发式会让你获得50％的机会。

例如，如果您在应用市场中对应用进行排名，则可以使用安装率或安装次数作为启发式。如果您检测到垃圾邮件，请过滤出之前发送过垃圾邮件的发布商。不要害怕使用人工编辑。如果您需要对联系人进行排名，请排列最近使用的最高（甚至按字母顺序排列）。如果您的产品不是绝对需要机器学习，那么在您有数据之前不要使用它。

法则2

rule #2：First, design and implement metrics. 首先，针对问题设计和完善评价体系

在开始设计机器学习系统之前，有足够的理由去当前系统的历史信息和问题，比如：

早期更容易获得系统用户的权限许可，收集数据更容易。
如果你觉得某个问题以后会受到关注，最好是从现状开始就搜集历史数据。
如果在设计机器学习系统的时候时刻考虑到你的度量指标，那么事情变得更容易，未来也可以避免很多麻烦的事情。
必须要注意到系统中的变化量和保持不变的量，比如，假设想要直接优化每天的活跃用户数，如果使用早起的系统可能发现，用户体验度的改变并没有明显的改变用户活跃度。

Google Plus团队衡量指标可扩展每次阅读，每次阅读的阅读次数，每次阅读的阅读量，评论/阅读，每位用户的评论数，每位用户的转化率等等，这些数据用于计算服务时间的帖子的好坏程度。另外，请注意，一个实验框架非常重要，您可以在其中将用户分组并通过实验汇总统计信息。见规则＃12 通过更加自由地收集指标可以帮助设计者更全面地了解机器学习系统。如果注意到一个问题？添加一个指标-metric来跟踪它！对上一版本的一些量化变化感兴趣？添加一个指标来跟踪它！

法则3

Rule #3: Choose machine learning over a complex heuristic. 在复杂的启发式方法和机器学习技术之间，优先选择机器学习技术。

基于简单的启发式方法的产品完全可以可靠的运行。但是复杂的启发式的方法是不可维护的。一旦你有了新的数据或者实现新的想法，你会希望不断更新您的方法，不管它是启发式还是机器学习模型，最终会发现机器学习模型更易于更新和维护（请参阅规则16）。

建立第一个机器学习pipeline

开始设计机器学习工程系统的时候，一定要确保设计的pipeline的可靠性。

Rule #4: Keep the first model simple and get the infrastructure right. 设计第一个模型的时候不需要设计的很复杂，但是一定要可靠

第一个模型为最终的产品提供了基础支持，所以它不需要花哨。但是，你会遇到比你期望的更多的基本问题。在任何人都可以使用你的新机器学习系统之前，你必须确定以下三点：

如何为机器学习系统收集学习样本（examples）
要确定你的系统对于“好”和“坏”意味着什么。
如何将您的模型整合到应用中。你可以应用实时模型，也可以预先计算脱机示例中的模型，并将结果存储在表格中。例如，您可能希望对网页进行预分类并将结果存储在本地，但你也可能想要对聊天消息进行实时分类。

选择简单的特征能更容易确保：

特征正确应用到算法中
模型能够学习到合理的权重
特征正确应用到模型中

一旦构建成功了满足上面三个条件的模型，大部分工作其实已经完成了。初始的模型可以提供baseline的metric，在此基础上设计更复杂的算法完善模型，结果与baseline相比较，可以比较算法优劣。

Rule #5: Test the infrastructure independently from the machine learning. 独立的测试机器学习系统的各模块

将系统中的各个部分模块化，独立的测试各个模块的性能，具体来说：

测试数据输入到算法中是否正确。检查应该填充的feature column是否正确填充，在隐私许可的情况下，手动检查您的训练算法的输入。如果可能，请检查pipeline中的统计数据，并与其他地方处理的相同数据的统计数据比较。
确保模型的鲁棒性。确保训练环境中的模型与实际部署环境中的模型具有相同的分数（请参阅规则＃37）

机器学习中很多不可预测的因素，因此请确保你在训练环境和部署环境中都使用所有的样本测试过代码的每一部分，而且确保可以在部署环境中加载和使用训练好的模型。此外，了解您的数据非常重要：Practical Advice for Analysis of Large, Complex Data Sets.

Rule #6: Be careful about dropped data when copying pipelines. 复制旧的pipeline做新的pipeline的时候，当心数据的丢失

通常我们通过复制现有pipeline来创建新的pipeline，旧pipeline会丢弃我们在新pipeline中所需的数据。例如，Google Plus What’s Hot的pipeline会丢弃较旧的帖子（因为它试图对新帖进行排序）。这条pipeline被复制用于Google Plus Stream，其中较旧的帖子仍然有意义，但新的pipeline不希望舍弃旧的帖子。

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

通常机器学习试图解决的问题并不是全新的。现有的系统可用于排序，分类或任何你试图解决的问题。这意味着有一堆规则和启发式方法。这些相同的启发式技术可以在机器学习时进行调整。由于两个原因，您的启发式技术应该针对他们拥有的任何信息进行挖掘。首先，向机器学习系统的过渡将会更顺畅。其次，通常这些规则包含了很多你不想扔掉东西。有四种方法可以使用现有的启发式方法：用启发式规则进行预处理。若特征相当完美，则可以采用这个方法。举个例子，在垃圾邮件过滤器中，如果发件人已经被加入黑名单了，则可以不用重新学习“黑名单”的概念。直接阻止该信息就可以！这种方法在二元分类（binary classification）任务中很有用。

创建特征。直接从启发式规则中创建特征会很便捷。举个例子，若要用启发式规则为某个查询结果计算相关度，你可以把分数纳入特征的值中。接下来，用机器学习的方法来处理这些值（例如，把这些值转化为由一系列离散值组成的有限集，或者也可以与其它特征相结合），但是要从启发式方法生成的原始数据入手。

是用启发式的方法做预处理。如果一些特征很awesome，那么考虑其作为一个备选项。例如，如果在垃圾邮件过滤器中发件人已被列入黑名单，那对于此人的消息选择屏蔽即可，而不是重新考虑一下黑名单的意义。这种方法在二分类任务中最有效。
制作特征。从先验方法中直接获取特征是很好的。例如，如果你使用启发式来计算查询结果的相关性分数，则可以将分数包括为某个要素的值。稍后，你可能需要使用机器学习技术来处理该值（例如，将该值转换为有限的一组离散值中的一个值，或将其与其他特征组合），但首先使用启发式生成的原始值。
挖掘启发式的原始输入。如果应用程序具有启发式功能，它将安装次数，文本中的字符数以及星期几组合起来，考虑作为特征-features使用。适用于模型集成的一些技巧（参见规则＃40）。
修改标签。当你发觉启发式方法捕捉了一些信息，而这些信息没有包含在标记中，这时可以考虑该选项。举个例子，如果你想让下载量达到最大，但同时对内容的质量有要求，那么可以用 app 的平均评级乘以标记来解决问题。

监控-Monitoring

一般来说，系统中要包含警报程序，或设计界面使警报得以显示

Rule #8: Know the freshness requirements of your system. 掌握系统的实时需求

如果你使用的模型是昨天的模型，那么昨天的模型适应今天的需求吗？如果用的模型是一周前甚至一个季度前的呢？还可以保证同样的精度吗？因此，对系统的监控是必要的，知道何时该刷新系统能帮助你划分监控的优先级。如果你的模型一天没有更新，受益便下降，因此有必要指派一名工程师时关注它的动态。大多数广告服务系统每天都会有新的广告，因此需要实时处理和更新。比如，如果Google Play Search的机器学习模型一个月没有更新，它将带来负收益。对于含有post identifier 的模型需要经常更新模型。但是对于GooglePlus 的What’s Hot 中的模型并没有post identifier，所以他们可以不用频繁的导出模型。同时也应注意，信息的freshness是实时变化的，尤其是模型的feature columns更新时。

Rule #9: Detect problems before exporting models. 确保模型导出前没有问题

对于工程来讲，机器学习模型最终要上线运行，如果上线后出了问题，面对这个问题的将是用户。因此在导出模型之前多次检查模型是很正确的做法，具体来说，一定要保证模型在所持的数据上表现很好，如果对数据保持怀疑态度，那请不要上线运行。许多的团队会不断的部署模型检查ROC曲线下的面积参数。记住：问题出在上线前后的代价是不一样的，所以在输送给用户之前，耐心的确保模型的可靠性。

Rule #10: Watch for silent failures.

机器学习系统很容易出现隐藏的问题。比如系统的某些存放信息的table一直没有更新，短时间内系统仍能维持较好的性能，但是性能会随时间衰减。有时可能发现简单的刷新这些table可以大幅度提升性能，甚至大幅超过新季度的模型。解决此问题的方法是是对关键数据的统计信息进行监控，并且周期性对关键数据进行人工检查。

Rule #11: Give feature columns owners and documentation 记录feature columns的详细信息和创造者

如果系统的规模比较大，并且特征栏比较多，那么必须清楚每个特征栏的创建者或者维护者。如果某个了解该特征栏的人离开了，一定要确保另外还有人了解这部分信息。虽然很多特征栏的名字非常直观，但最好还是使用更详尽的文档来描述这些特征的内容、来自哪里以及它们的作用。

Objective

metric是系统的评估指标，其重要性与否视情况而定，见rule#2，但是Objective是算法优化的目标。

Rule #12: Don’t overthink which objective you choose to directly optimize. 不要纠结应选择那一个objective去优化

想关心的metrics太多了，就好像你想挣钱，想让用户高兴，想让这个世界更好，想…..，实际上应该measure所有metrics。然而，在机器学习算法的设计的前期，会发现即使没有直接优化一些指标，但是他们的metrics同样会增加。比如，假设你想优化网站的点击率和网站停留时间，会发现优化其中一个metric，另一个也会相应的增长。所以，在设计算法的前期，提高所有的metric都不是很难，就没必要花心思来如何权衡不同的指标。不过过犹不及：不要混淆了你的目标和系统的整体健康度。

Rule #13: Choose a simple, observable and attributable metric for your first objective. 选择一个简单、可观测并且可归类的metri作为第一个objective

大多数情况下你并不清楚最合适的objective是哪一个。即使定下一个objective之后，经过对数据和模型的分析，想要调整objective也是正常的。另外，团队的不同成员对objective可能会有不一样的选择。ML的objective应该是容易去测量的，并且确保是true的。但是，有时候可能没有一个完全true的objective（见Rule#39）因此，在简单的机器学习objective上训练，并创建一个“决策层”-“policy layer” ，以允许你在上面增加额外的逻辑（这些逻辑，越简单越好）。

最简单的机器学习建模方法是直接观察并归属到系统操作的用户行为：

经过排序后的链接是否被点击？
排序后的对象是否被下载？
对象是被转发/回复/通过电子邮件发送的吗？
对象是否被评价？
显示的对象是否标记为垃圾信息/色情/侵犯？

一开始避免对间接效应建模，一些间接效应如下：

用户第二天是否还会访问这个链接
用户浏览此链接的长短
每天有多少活跃用户

间接效应可以做出很好的衡量标准，并且可以在A / B测试和发布决定期间使用。

最后，避免用机器学习直接解决如下问题：

用户是否乐意使用该产品？
用户对体验满意吗？
该产品是否改善了用户的整体健康状况？
这将如何影响公司的整体健康？

不是说这些问题不重要，而是它们很难直接优化。话说回来：如果用户很高兴，他们会留在网站上更长时间。如果用户满意，他们将在明天再次访问，一些指标是相辅相成的。

Rule #14: Starting with an interpretable model makes debugging easier. 选择可解释的机器学习模型很利于早期调试

线性回归，逻辑回归和泊松回归直接由概率模型驱动。每个预测都可以解释为概率或预期值。这使得它们比试图直接优化分类准确性或排名性能的使用目标（零失败，各种铰链损失等）的模型更容易调试。例如，如果训练中的概率偏离了并行预测的概率或通过检查生产系统，则这种偏差可能会出现问题。

例如，在线性，逻辑或泊松回归中，有数据的子集，其中平均预测期望等于平均label。假设你没有正则化并且你的算法已经收敛，这是真实的，并且通常情况下它是近似真实的。如果每个示例都具有1或0的特征，则校准该特征为1的3个样本的集合。另外，如果每个示例都具有1的特征，则所有示例的集合都将被校准。

使用简单的模型，处理反馈回路更容易（见Rule＃36）。通常，我们使用这些概率预测来做出决定：例如按降低的期望值排列帖子（即点击/下载等的可能性）。但是，请记住，何时需要选择使用哪种模型，决策不仅限于给定模型的数据的可能性（参见规则＃27）。

Rule #15: Separate Spam Filtering and Quality Ranking in a Policy Layer. 在策略层将垃圾信息过滤和质量排名分开

对于信息质量的排序是一门艺术，但垃圾信息过滤是一场战争。那些使用您的系统的人会变得很明显会根据你的信息质量排序方法作出相应的对策，并且他们会调整帖子以获得这些属性。因此，你的信息排序应该关注排名含金量高的信息。同样，对于内容“生动”的信息也应与信息质量排序分开处理。在某种程度上，这两个系统的输出将不得不被整合。请记住，在搜索结果中过滤垃圾信息应该比在电子邮件中过滤垃圾邮件受到更多的重视。假设您没有正则化并且算法已经收敛，这是正确的。一般情况下大致如此。此外，从质量分类器的训练数据中删除垃圾信息也是一种标准做法。

机器学习第二阶段：特征工程-Feature Engineering

在机器学习系统构建的第一阶段，重要的问题是将训练数据放入学习系统，获取任何感兴趣的度量标准，并创建服务基础架构。在进行了单元和系统测试的端到端系统工作后，即可开始进行机器学习的第二阶段-特征工程。

在第二阶段，有很多明显的feature可以被引入到系统中。因此，机器学习的第二阶段涉及尽可能多的引入特征并以直观的方式将其结合起来。在这个阶段，所有的指标在数值上还会继续增加。

Rule #16: Plan to launch and iterate. 做好更新模型-发布-更新模型-发布-… 过程循环的准备

不要奢望发布的模型可以作为最终版本一直work下去。因此，持续更新模型是必须的过程，因此要考虑到你给当前这个模型增加的复杂度会不会减慢后续的发布。许多团队每季度推出一个模型。一般以下三种情况会令你希望更新模型：

提出利用新的feature。希望调整正则化方式，以不同的方式利用原有的feature。微调了objective Rule #17: Start with directly observed and reported features as opposed to learned features. 优先使用直接观测或收集到的特征，而不是学习出来的特征（learned features）

这可能是一个有争议的问题，但它避免了很多陷阱。首先，让我们描述一个learned features是什么。learned features是由其他模型或者方法（例如无监督聚类）或由学习者本身（例如通过因子模型或深度学习）产生的features。这两种方法都很有用，但它们可能有很多问题，所以它们学习到的feature不应该放在现有的模型中。

因为其他模型或者方法有其自己的objective。此objective或许与现有模型的objective相关性很小甚至冲突。如果你用外部模型或方法更新feature，则其含义可能会改变。

因式模型和深度模型的主要问题是它们是非凸的。因此，不能保证可以近似或找到最优解，并且在每次迭代中找到的局部最小值可以不同。这种变化使得很难判断变更对机器学习系统的影响是有意义的还是随机的。通过创建没有深度特征的模型，您可以获得出色的基准性能。达到此基准后，可以尝试更复杂的方法。

Rule #18: Explore with features of content that generalize across contexts. 尝试利用具有上下文概括的内容的feature。

通常情况下，机器学习只占到一个大系统中的很小一部分，因此你必须要试着从不同角度审视一个用户行为。比如在What’s Hot中的一个post有许多评论、分享和阅读量，如果利用这些统计数据对模型展开训练，然后对一个新post进行优化，就有可能使其成为热门post。另一方面，YouTube上自动播放的下一个视频也有许多选择，例如可以根据大部分用户的观看顺序推荐，或者根据用户评分推荐等。总之，如果你将一个用户行为用作模型的标记（label），那么在不同的上下文条件下审视这一行为，可能会得到更丰富的特征（feature），也就更利于模型的训练。需要注意的是这与个性化不同：个性化是确定用户是否在特定的上下文环境中喜欢某一内容，并发现哪些用户喜欢，喜欢的程度如何。

Rule #19: Use very specific features when you can. 尽可能使用针对性的特征

简单的feature唾手可得，复杂的feature万里挑一。由于被检索的文本标识与规范化的查询并不会提供太多的归一化信息，只会调整头部查询中的标记排序。因此你不必担心虽然整体的数据覆盖率高达90%以上，但针对每个feature group里的单一feature却没有多少训练数据可用的情况。另外，你也可以尝试正则化的方法来增加每个feature所对应的样本数。

Rule #20: Combine and modify existing features to create new features in human-understandable ways 用可解释的方式对已有feature进行组合和修改

有很多中方式可以满足feature的操作和修改。比如深度学习框架Tensorflow，它可以使用transformations的方式对数据做预处理，其中两个标准的方法就是discretizations和crosses。 Discretization 会根据一个连续的特征创建许多离散的特征。假定年龄是一个连续的特征。我们可以创建如下特征，当年龄小于 18 时记为 1，或者当年龄在 18 到35 岁之间时为 1，以此类推。不用过多考虑如何划分年龄。

Cross由两个或多个feature column组成。根据TensorFlow给出的解释， feature column是一组同类的feature。（如｛男，女｝、｛美国，加拿大，墨西哥｝等）。而Cross是一个新的feature column，可以用｛男，女｝×｛美国，加拿大，墨西哥｝等来简单的表示。新的feature column会包含以下feature，如｛男，加拿大｝。使用TensorFlow时可以让它帮你创建cross。｛男，加拿大｝可以在样本中代表男性加拿大人。注意若模型使用三个以上的feature column组成的cross，则需要大量的数据来训练模型。

Cross 得方法可以产生很多feature column，有可能导致过拟合现象。举个例子，假设你要做某种搜索。检索词构成一个 feature column，文档中的词构成另一个feature column。你可以通过cross 来组合它们，但这样会出现很多feature（见Rule#21）。处理文本时，有两个替代性方案。最苛刻的方案是 dot product（点积）。点积仅统计检索词和文档词中的公共词汇。得到的feature可以被离散化。另一种方案是取intersection（交集）：因此，我们有一个feature来表示当“pony（色情）”这个词同时出现在文档和检索词中，另一个特征表示“the”同时出现在文档和检索词中。

Rule #21: The number of feature weights you can learn in a linear model is roughly proportional to the amount of data you have. 线性模型学习的feature参数的数量应大致和样本数成比例

关于模型的适当复杂程度，统计学习理论可以给出一个很好的结果，即根据数据调整模型的大小。有些人认为，样本越多，学习的效果越好，最好的结果是根据数据的多少选择学习方法，不要仅限于一种方法。

如果你在开发一个搜索排序系统，并且有数百万不同的词汇存在于文档和检索词中，而你仅有 1000 个带有标记的样本。那么你应该使用文档和检索词的点积特征、 TF－IDF 以及其它六个人工设计的feature。 1000 个样本，对应 12个左右的feature。
如果有一百万个的样本，那就通过 regularization 或feature selection，取文档特征栏和检索词feature column的交集。这样你能得到数百万个feature，但 regularization会帮你减少些许的feature。一千万个样本，对应大约十万个feature。
如果有十亿个乃至几千亿个样本，你可以通过 regularization 和feature selection，取文档feature column和 query token 的叉积。如果有十亿个样本，那么你会得到一千万个特征。统计学习无法给出一个严格的数据界限，但是可以提供一个合适的出发点。

可以按照Rule#28选择feature。

Rule #22: Clean up features you are no longer using. 清除不经常使用的features

不work的feature会给算法带来阻碍。如果你不常使用这个feature，并且这个feature和其他feature集合在一起也不会带来精度的提高，那么就可以抛弃掉这个feature了。相对**干净**feature的模型可以集中在更好的feature的处理上。但是feature的选择和丢弃需要注意一点，feature的涵盖范围，即此feature和多少数据相关联。比如一个feature只和8%的用户相关，那么这个特征就相对不是那么重要，但是也要考虑到feature权重的问题，如果feature关联的用户少，但是90%的正样本包含这个feature，那么它也是很重要的。

系统分析

在进入机器学习第三阶段前，有一些在机器学习课程上学习不到的内容也非常值得关注：如何检测一个模型并改进它。这与其说是门科学，还不如说是一门艺术。

Rule #23: You are not a typical end user. 设计者应站在用户角度看问题

这可能是团队陷入困境的最简单方式。尽管fishfooding（在团队中使用模型原型）和dogfooding（在公司内部使用模型原型）有很多好处，但技术人员应该考虑性能是否正确。性能不好的拒绝使用，新能说的过去的仍需进一步测试。但是应该通过支付外行人在众包平台上问题回答或通过对真实用户进行实时实验来进一步测试模型。

有两个原因。首先是你太接近工程。您可能正在寻找帖子的某个特定方面，或者您只是情绪上过度参与（例如确认偏见）。第二是你的时间很宝贵。与其9个工程师花一个小时讨论，不如在众包平台上找真实的用户来测试。

如果你真的想获得用户反馈，请使用用户体验方法。在一个流程的早期创建用户角色（一个描述在Bill Buxton的Sketching User Experiences中），然后进行可用性测试（一个描述在Steve Krug的“不要让我想”）。用户角色涉及创建一个假想用户。例如，如果你的团队全部是男性，则可能有助于设计一个35岁的女性用户角色（具有用户功能），并查看其生成的结果，而不是25至40岁的10个结果男性。引入实际的人员观察他们对本地或远程对网站的反应，可用性测试也可以为你提供全新的视角。

Rule #24: Measure the delta between models. 测量模型之间的差异

在模型上线之前，最简单且有时最实用的测量是计算当前模型结果与将投入使用模型的差异。如果差异非常小，那么你可以不用继续实验。如果差异非常大，那么需要确保差异的性质，是好还是坏。查看对称差异高的部分可以帮助您定性地了解变化是什么样，进而进一步确保系统稳定。确保与自身相比较的模型具有较低（理想情况下为零）的对称差异。

Rule #25: When choosing models, utilitarian performance trumps predictive power. 模型选择上，性能比预测能力重要

您的模型可能会尝试预测点击率。然而，最终，关键问题是你如何处理这个预测。如果您使用它来对文档排序，那么最终排序的质量比预测本身更重要。如果你预测文档是否是垃圾邮件，然后对被阻止的内容进行截取，那么你的预测精度就会提高。大多数时候，这两件事应该是一致的：当他们不一致时，它可能会有小幅增益。因此，如果一些改动增加了log loss但是降低了系统的性能，那需要寻找新的feature代替旧的。如果这些事情出现的很频繁，那么是时候重新审视一下objective的正确性。

Rule #26: Look for patterns in the measured errors, and create new features. 从测量误差中寻找问题，创建新的feature解决它

假设模型对训练样本给出了错误的预测。比如在分类中，存在分错或者漏分；在排序任务中，这种错误是成对存在的。重要的是要另机器学习模型知道这个错误并可以解决掉这中错误，可以通过创建新的feature帮助模型修复这个问题。

另一方面，如果你基于系统没有出错的样本创建feature，那么该feature将很可能被系统忽略。例如，假设在 Google Play商店的应用搜索中，有人搜索“免费游戏”，但其中一个排名靠前的搜索结果却是一款其他App，所以你为其他App创建了一个feature。但如果你将其他App的安装数最大化，即人们在搜索免费游戏时安装了其他App，那么这个其他App的feature就不会产生其应有的效果。

所以，一旦发现模型判断出错的样本，独立于当前的feature集合外去尝试解决。例如，如果你的系统降低了内容较长的帖子的排序位置，那就应该普遍增加帖子的长度。而且也不要拘泥于太具体的细节。例如你要增加帖子的长度，就不要猜测长度的具体含义，而应该直接添加几个相关的特征，交给模型自行处理，这才是最简单有效的方法。

Rule #27: Try to quantify observed undesirable behavior. 量化观测到异常行为

你的team中的一些人对损失函数无法优化的系统属性很烦恼。在这一点上，他们应该尽一切努力把他们的抱怨变成可靠的数据。例如，如果他们认为Play搜索中显示了太多“gag apps”，他们可能会让人类评估者识别gag apps。（在这种情况下，你可以使用人类标记的数据，因为相对较小的查询占了很大一部分流量。）如果你的问题是可衡量的，那么你可以开始将它们用作新的feature，objective或metric。一般规则是“先量化，后优化”。

Rule #28: Be aware that identical short-term behavior does not imply identical long-term behavior. 短期表现良好，但是长期运行不一定是这样

假设你有一个新机器学习系统，它可以查看每个doc-id和exact-query，然后根据每个doc的每次查询行为计算其点击率。你发现它的表现几乎与当前系统的并行和A/B测试结果相同，而且它非常简单，于是你发布了这个机器学习模型。但是新的模型中无法显示新的APP信息，为什么？由于你的系统只基于自己的历史查询记录显示文档，所以不知道应该显示一个新的文档。要了解一个系统长期运行的唯一办法，就是让它只基于当前的模型数据完成训练。但是这并不简单。

训练-测试误差（Training-Serving Skew）

训练测试误差是指训练的精度和测试的精度之间存在误差，一般由以下几个原因导致：

训练测试的数据处理方式不同
训练和测试的数据不同
模型和算法之间存在反馈

我们在谷歌对机器学习系统做了严密的监控，其精度的。最好的解决方案是是对系统和数据的变化进行监控，以便系统和数据的更改不会引起精度的震荡。

Rule #29: The best way to make sure that you train like you serve is to save the set of features used at serving time, and then pipe those features to a log to use them at training time 保存模型上线使用的feature 集合，并记录到日志文件中以便训练使用，这样可以保证模型训练和测试不存在误差。

即使你无法为每个样本都做到这一点，只需做一小部分，这样你就可以验证训练和测试之间的一致性（见规则＃37）。在谷歌进行这种测量的团队有时会对结果感到惊讶。 YouTube主页在服务时间切换到日志记录功能，服务质量得到提高，代码复杂度反而降低。目前有许多团队都已经在其基础设施上采用了这种策略。

Rule #30: Importance-weight sampled data, don’t arbitrarily drop it! 对采样数据按重要性赋权重，不要随意丢弃它们

如果你有非常多的数据，可能希望只使用其中的一部分完成训练，但这是错误的。那些对用户不可见的数据是可以被丢弃的，但最好还是给这些数据赋予一定的权重，比如你决定好30%的概率会用到样本X，那可以给它乘以一个10/3的权重。

Rule #31: Beware that if you join data from a table at training and serving time, the data in the table may change. 从table中组合数据时，要注意训练和测试table可能会发生变化

假设你想把文档的id和table中的其他特征（比如评论或者点击量）结合起来，在训练和测试的时候，table中的feature可能会发生变化，模型在训练和测试的时候对相同的文档可能会给出不同的预测。避免这种问题最简单的方法就是记录所有实际运行时的feature。若table中的数据变化缓慢化，你也可以照一定的频率对其做出记录，得到足够相近的数据。但是这样不能根治这个问题。

Rule #32: Re-use code between your training pipeline and your serving pipeline whenever possible. 尽量在训练的pipeline和测试的pipeline中使用相同的代码

批处理和在线处理是不同的。在线处理必须及时处理每一个请求（比如为每一个查询做单独的查找），批处理中可以合并一些请求做处理。训练的时候是批处理，上线的时候是在线处理，但是有时候代码还是可以重用的。比如，你可以创建针对你系统的对象，其中的所有联结和查询结果都以可读的方式存储，错误也可以被简单地测试。在模型上线或训练期间收集了所有信息后，你就可以通过一种通用方法在这个特定对象和机器学习系统需要的格式之间形成互通，训练和服务的偏差也得以消除。因此，尽量不要在训练时和服务时使用不同的变成语言，毕竟这样会让你没法重用代码。

Rule #33: If you produce a model based on the data until January 5th, test the model on the data from January 6th and after. 时间上，测试模型的数据要在训练模型的数据之后

训练完模型后，使用接下来收集的数据作为测试样本可以很好的测量模型的实际表现。如果你的模型是在一月五号训练完，那么使用一月六号或者更靠后的数据测试模型。这样做测试的精度可能比不上训练的精度，但是也不会差太多。

Rule #34: In binary classification for filtering (such as spam detection or determining interesting emails), make small short-term sacrifices in performance for very clean data. 二分类任务比如垃圾邮件分类中，在非常‘干净‘的数据上可以牺牲一些精度换取一些其他提升。

垃圾邮件分类中，被分为垃圾邮件的邮件不会展示给用户。假设你的模型可以阻挡75%的垃圾邮件，但是不能总是从展示给用户的邮件数据中学习，比如用户把模型分为正样本的邮件标记为了垃圾邮件，这时，你的模型应该从中学习并改进自己。但是这个方法引入了样本偏差，你可以从抽出1%的垃圾邮件作为‘示例‘(hold out)，用户可以看到这些样本，这显然影响了最终的过滤效果，但是用户会重新标记这些邮件是否是垃圾邮件，这样做，你的模型就可以从中继续学习。

Rule #35: Beware of the inherent skew in ranking problems. 注意排序问题中的固有偏差

当你调整你的排序算法后，算法的结果之间肯定存在差异。此时应该围绕这些差异设计你的模型，以下有一些方法可以帮助你优化：

对涵盖范围广而不是窄的feature做正则化，这种方式使得模型更偏好那些针对个别查询的feature，而不是那些能够泛化到被经常查询的feature，同时也阻止一些经常被查询的结果被分到不经常查询中，请注意，这个方法与传统的方法是相反的。
仅允许feature有正的权重，这样好的feature比其他未知的feature要更突出
不能仅仅有document-only的feature，这是一种极端情况。例如，你也不会想让最受欢迎的app到处出现而不管真正的查询是什么，肯定也希望其他的app可以被下载。例如，有人搜索‘bird watching app‘，展示给他们的是”angry birds”，最终”angry birds”下载量会增加，但是用户显然不是很满意。

Rule #36: Avoid feedback loops with positional features. 使用位置feature避免模型的反馈

我们都知道，链接展示的位置影响着浏览它的用户量，排名更靠前的app更容易被点击、下载，你也很确信他会被浏览。因此增加位置feature可以很好的表达具体信息，如果没有位置feature，这个因素造成的影响可能会算为其他feature的贡献，这显然不合理。注意，在训练的时候提供位置feature，模型上线的时候并不提供位置feature。而且位置feature必须是两两独立的。

Rule #37: Measure Training/Serving Skew. 测量训练-上线测试的误差

很多原因会导致这种误差，但是一般可以分为以下三种：

数据不同，训练数据和holdout数据会有些不同，这种差异经常存在，但并不一定是坏事。
模型在今天的holdout数据上的精度或许会和明天的数据上精度有所差别，这也是经常存在的，可以调整正则化方式维持精度的稳定，但是另一方面，如果精度相差很大，就需要详细分析是否是一些feature对时间太敏感了，导致了精度的降低。
同一个样本，不同时间模型预测的结果不同，这时可能是代码有bug。

机器学习第三阶段：步调放慢、精细优化、增加模型复杂度

标题已经在说明即将接近尾声了，接下来可能没有之前进步的那样快了。首先，你需要在metics之间做tradeoff：一些指标精度的提高可能会造成其他指标的下降。机器学习会变得更加复杂。事先声明：本节给出的规则是开放性的，许多team可以从上两个阶段获益颇多，但是在第三阶段，他们不得不找出适合自己的方法。

Rule #38: Don’t waste time on new features if unaligned objectives have become the issue. 如果你的objective和优化的最终objective有偏差，不要尝试使用新的feature去解决，而是确保objective一致。

在你的测试平台上，你的团队成员可能脱离与当前的机器学习系统的objective范围之外看待问题。如果产品的目标和算法优化的objective不一致，那么修改其中的一个调整到一致。比如，你可能优化点击量，点赞率，下载量，但是最终决策点是用户的评分，这就是objective不一致的问题。

Rule #39: Launch decisions are a proxy for long-term product goals. 模型能否发布最能衡量模型的能力

栗子：Alice有一个降低logistics loss的idea，增加了一个新的feature后，Loss确实降低了。当上线测试的时候，发现下载量的确上升了，然而等到模型发布的时候，被人指出日活跃用户数量减少了5%，最终模型没有发布，Alice很失望，但是也意识到了最终是否发布由多个指标决定，而且其中很少一部分是可以被机器学习算法直接优化的。

事实是，现实世界不是龙与地下城：没有“生命点”来确定你的产品的健康状况。该团队必须使用收集的统计数据来有效预测未来系统的良好状态。他们需要关心参与度，1天活跃用户（DAU），30 DAU，收入和广告商的投资回报。这些在A / B测试中可衡量的指标本身仅代表更长期的目标：满足用户，增加用户，满意合作伙伴和利润。

所有的metric都在变好（至少没有变坏）是最好发布模型的时候。如果一个复杂的机器学习模型和先验方法取得了同样好的结果，最好的结果是发布先验方法的模型。然而，所有的metric也没有一个明确的重要性排序表，对于一些特殊的情况，比如：

无论当前系统是A还是B，他们肯定都不想更换为另一种模型，二者有冲突的部分，然而，对指标变化的预测可能会或可能不会出现，因此这两种变化都有很大的风险。每项指标都涵盖了团队所关注的一些风险。 没有任何一个指标能回答：“五年后我的产品在哪里”？ 每个工程师显然更喜欢能够直接优化的objective，这很常见。现在也有一些多目标学习系统在试图解决这种问题。但仍然有很多objective无法建模，比如用户为什么会来访问你的网站等等。作者说这是个AI-complete问题，也常被称为强AI问题，简单来说就是不能用某个单一算法解决的问题。

Rule #40: Keep ensembles simple. 模型集成的方法要尽可能简单

模型集成的方法很容易提升最终的效果。但是请注意：尽可能的使用简单的模型集成方法，要么是每个模型以其他模型作为输入，要么是一个basemodel以多种feature作为输入，最好不要二者都使用。 也有可能你表现最好的几个模型放在一起，效果反而变差了。

有时你还希望在这些集成的模型上强制增加属性。例如，由基本模型生成的分数的增加不应该降低集合的分数。此外，最好传入的模型在语义上可解释，这样基础模型的更改不会混淆集成模型。此外，单一基础模型预测概率的增加不会降低集成模型的预测概率。

Rule #41: When performance plateaus, look for qualitatively new sources of information to add rather than refining existing signals. 当性能稳定时，寻找定性的新信息来源来添加而不是对现有的信号做精调

你先是添加了一些用户的信息，又添加了一些文档词汇的信息，接着你又浏览了一遍模版，而后又调整了正则化方式，但是最后，关键的metirc却只提升了不到 1%。现在怎么办？那么是时候使用不同的feature构建基础架构了，feature可以是此用户在最后一天，一周或一年中访问过的文档的历史记录，或者来自不同属性的数据。使用wikidata实体或公司内部的东西（例如Google的知识图），或者使用深度学习技术。开始调整您对期望的投资回报的预期，并相应地扩大您的努力。与任何工程项目一样，你必须权衡添加新feature的好处与增加复杂性的成本。

Rule #42: Don’t expect diversity, personalization, or relevance to be as correlated with popularity as you think they are. 不要指望多样性，个性化或相关性与你认为的受欢迎程度有关

一组数据内容中的多样性可能意味着很多事情，内容来源的多样性很常见。个性化意味着每个用户都有自己感兴趣的点。相关性意味着特定查询的结果比任何其他查询更适合该查询。因此，这三个属性的定义和标准都不相同。

问题是越简单的事情越不容易改变。

请注意，如果你的系统正在测量点击次数，花费的时间，手表，+1的次数，转发等等，说明你正在衡量内容的流行度。团队有时试图学习一个多样化的个性化模型。为了个性化，他们添加了允许系统个性化（表示用户兴趣的一些特征）或多样化的feature（指示该文档是否与返回的其他文档（例如作者或内容）具有共同feature的feature），并且发现那些feature得到（或有时是不同的符号）比他们预期的要小的权重。

这并不意味着多样性，个性化或相关性并不重要。正如前面的规则所指出的那样，你可以进行后处理以增加多样性或相关性。如果你看到更长期的objective指标的增加，那么你可以独立于受欢迎程度，宣称多样性/相关性是有价值的。然后，你可以继续使用后处理，或者根据多样性或相关性直接修改objective。

Rule #43: Your friends tend to be the same across different products. Your interests tend not to be. 不同产品上的好友可能很多是相同的，但是并不意味着这些好友对此产品的感兴趣点是一样的。

Google 经常在不同产品上使用同样的好友关系密切度预测模型，效果都差不多，这证明不同的产品上好友关系是可以迁移的。但他们尝试将一个产品上的个性化feature使用到另外一个产品上时却常常得不到好结果。事实上，好友都是一样的，按理说个性化feature应该也差不多一致啊，事实并非如此。有些特殊的情况下可能会起作用。但是，请牢记，即使知道用户在其他媒体资源上有历史记录，也是可以提供帮助的。例如，同一个用户同时活跃在两个不同的产品上，这本身就暗示了一些东西。