动态 | 谷歌发布机器学习规则关于机器学习工程的最佳实践（下）

2018 年 5 月 27 日 AI科技评论

文章介绍了一种机器学习样式，类似于 Google C++ 样式指南和其他常用的实用编程指南。

AI科技评论按，本文来源于谷歌开发者博客，AI科技评论获其授权转载。以下为下篇，内容为进行机器学习之前的第 21-43 条规则。相关术语及第1-20条规则参见谷歌发布机器学习规则 (Rules of Machine Learning)：关于机器学习工程的最佳实践（上）

第 21 条规则：您可以在线性模型中学习的特征权重数目与您拥有的数据量大致成正比。

关于模型的合适复杂度方面，有各种出色的统计学习理论成果，但您基本上只需要了解这条规则。在某次谈话中，曾有人表达过这样的疑虑：从一千个样本中是否能够学到任何东西，或者是否需要超过一百万个样本，他们之所以有这样的疑虑，是因为局限在了一种特定学习方式中。关键在于根据数据规模调整您的学习模型：

1.如果您正在构建搜索排名系统，文档和查询中有数百万个不同的字词，且您有 1000 个有标签样本，那么您应该在文档和查询特征、TF-IDF 和多个其他高度手动工程化的特征之间得出点积。您会有 1000 个样本，十多个特征。

2.如果您有一百万个样本，则使用正则化和特征选择（可能）使文档特征列和查询特征列相交。这样一来，您将获得数百万个特征；但如果使用正则化，则您获得的特征会有所减少。您会有千万个样本，可能会产生十万个特征。

3.如果您有数十亿或数千亿个样本，您可以使用特征选择和正则化，通过文档和查询标记组合特征列。您会有十亿个样本，一千万个特征。统计学习理论很少设定严格的限制，但能够提供很好的起点引导。

最后，请根据第 28 条规则决定要使用哪些特征。

第 22 条规则：清理不再使用的特征。

未使用的特征会产生技术负债。如果您发现自己没有使用某个特征，而且将其与其他特征组合在一起不起作用，则将其从您的基础架构中删除。您需要让自己的基础架构保持简洁，以便尽可能快地尝试最有可能带来良好效果的特征。如有必要，他人可以随时将您的特征添加回来。

在决定要添加或保留哪些特征时，要考虑到覆盖率。即相应特征覆盖了多少个样本？例如，如果您有一些个性化特征，但只有 8% 的用户有个性化特征，那效果就不会很好。

同时，有些特征可能会超出其权重。例如，如果您的某个特征只覆盖 1% 的数据，但 90% 具有该特征的样本都是正分类样本，那么这是一个可以添加的好特征。

对系统的人工分析

在继续探讨机器学习的第三阶段之前，请务必重点了解一下在任何机器学习课程中都无法学到的内容：如何检查现有模型并加以改善。这更像是一门艺术而非科学，但是有几个有必要避免的反模式。

第 23 条规则：您不是典型的最终用户。

这也许是让团队陷入困境的最简单的方法。虽然 fishfood（在团队内部使用原型）和 dogfood（在公司内部使用原型）有许多优点，但员工应该看看是否符合性能要求。虽然应避免应用明显比较糟糕的更改，但在临近生产时，应对任何看起来比较合理的更改进行进一步测试，具体方法有两种：请非专业人员在众包平台上回答有偿问题，或对真实用户进行在线实验。

这样做的原因有如下两点。首先，您与代码的关系太密切了。您关注的可能是帖子的某个特定方面，或者您只是投入了太多感情（例如确认偏差）。其次，您的时间很宝贵。考虑一下九名工程师开一个小时会议所花的费用可以在众包平台上购买多少签约的人工标签。

如果您确实想获得用户反馈，请使用用户体验方法。在流程的早期阶段创建用户角色（请参阅比尔·布克斯顿的 Sketching User Experiences 一书中的描述），然后进行可用性测试（请参阅史蒂夫·克鲁格的 Don’t Make Me Think 一书中的描述）。用户角色是指创建假想用户。例如，如果您的团队成员都是男性，则有必要设计一个 35 岁的女性用户角色（使用用户特征完成），并查看其生成的结果，而不是只查看 10 位 25-40 岁男性的结果。在可用性测试中请真实用户体验您的网站（通过本地或远程方式）并观察他们的反应也可以让您以全新的视角看待问题。

第 24 条规则：衡量模型间的差异。

在向任何用户展示您的新模型之前，您可以进行的最简单（有时也是最有用）的一项衡量是，评估新模型的结果与生产有多大差别。例如，如果您有一项排名任务，则在整个系统中针对一批示例查询运行这两个模型，并查看结果的对称差分有多大（按排名位置加权）。如果差分非常小，那么您无需运行实验，就可以判断不会出现很大变化。如果差分很大，那么您需要确保这种更改可以带来好的结果。查看对称差分较大的查询有助于您了解更改的性质。不过，请确保您的系统是稳定的。确保模型与自身之间的对称差分较低（理想情况下为零）。

第 25 条规则：选择模型时，实用效果比预测能力更重要。

您的模型可能会尝试预测点击率。但归根到底，关键问题在于您用这种预测做什么。如果您使用该预测对文档进行排名，那么最终排名的质量比预测本身更重要。如果您要预测一个文档是垃圾内容的概率，然后选择一个取舍点来确定要阻断的内容，那么允许的内容的精确率更为重要。大多数情况下，这两项应该是一致的：当它们不一致时，带来的优势可能会非常小。因此，如果某种更改可以改善对数损失，但会降低系统的性能，则查找其他特征。当这种情况开始频繁发生时，说明您该重新审视模型的目标了。

第 26 条规则：在衡量的错误中寻找规律，并创建新特征。

假设您看到模型“弄错”了一个训练样本。在分类任务中，这种错误可能是假正例，也可能是假负例。在排名任务中，这种错误可能是假正例和假负例，其中正例的排名比负例的排名低。最重要的是，机器学习系统知道自己弄错了该样本，如果有机会，它会修复该错误。如果您向该模型提供一个允许其修正错误的特征，该模型会尝试使用它。

另一方面，如果您尝试根据系统不会视为错误的样本创建一个特征，该特征将会被系统忽略。例如，假设某人在 Play 应用搜索中搜索“免费游戏”。假设排名靠前的搜索结果中有一个是相关性较低的搞笑应用。因此，您为“搞笑应用”创建了一个特征。但是，如果您要最大限度地增加安装次数，并且用户在搜索免费游戏时安装了搞笑应用，那么“搞笑应用”特征不会达到您想要的效果。

如果模型弄错了您的某些样本，请在当前特征集之外寻找规律。例如，如果系统似乎在降低内容较长的帖子的排名，那么添加帖子长度。不要添加过于具体的特征。如果您要添加帖子长度，请不要试图猜测长度的具体含义，只需添加十多个特征，然后让模型自行处理（请参阅第 21 条规则）。这是实现目标最简单的方式。

第 27 条规则：尝试量化观察到的异常行为。

当现有的损失函数没有捕获您团队中的部分成员不喜欢的某些系统属性时，他们会开始有挫败感。此时，他们应该竭尽所能将抱怨转换成具体的数字。例如，如果他们认为 Play 搜索中显示的“搞笑应用”过多，则可以通过人工评分识别搞笑应用。（在这种情况下，您可以使用人工标记的数据，因为相对较少的一部分查询占了很大一部分流量。）如果您的问题是可衡量的，那么您可以开始将它们用作特征、目标或指标。一般规则是“先量化，再优化”。

第 28 条规则：请注意，短期行为相同并不意味着长期行为也相同。

假设您的新系统会查看每个 doc_id 和 exact_query，然后计算每个查询的每个文档的点击概率。您发现在并排分析和 A/B 测试中，其行为与您当前系统的行为几乎完全相同，考虑到它的简单性，您发布了它。不过，您发现它没有显示任何新应用。为什么？那是因为您的系统仅根据自己的查询历史记录显示文档，所以不知道应该显示新文档。

了解这种系统长期行为的唯一方法是，仅使用模型在线时获得的数据对其进行训练。这一点非常难。

训练-应用偏差

训练-应用偏差是指训练效果与应用效果之间的差异。出现这种偏差的原因可能是：

训练管道和应用管道中数据的处理方式有差异。
训练时和应用时所用数据有变化。
模型和算法之间有反馈环。

我们注意到 Google 的生产机器学习系统也存在训练-应用偏差，这种偏差对性能产生了负面影响。最好的解决方案是明确进行监控，以避免在系统和数据改变时引入容易被忽视的偏差。

第 29 条规则：确保训练效果和应用效果一样的最佳方法是，保存在应用时使用的特征集，然后将这些特征通过管道传输到日志，以便在训练时使用。

即使您不能对每个样本都这样做，也对一小部分样本这样做，以便验证应用和训练之间的一致性（请参阅第 37 条规则）。采取了这项措施的 Google 团队有时会对结果感到惊讶。 YouTube 首页改用这种在应用时记录特征的做法后，不仅大大提高了质量，而且减少了代码复杂度。目前有许多团队都已经在其基础设施上采用了这种方法。

第 30 条规则：按重要性对采样数据加权，不要随意丢弃它们！

数据过多时，总会忍不住采用前面的文件而忽略后面的文件。这是错误的做法。尽管可以丢弃从未向用户展示过的数据，但对于其他数据来说，按重要性加权是最佳选择。按重要性加权意味着，如果您决定以 30% 的概率对样本 X 进行抽样，那么向其赋予 10/3 的权重。按重要性加权时，您仍然可以使用第 14 条规则中讨论的所有校准属性。

第 31 条规则：如果您在训练和应用期间关联表格中的数据，请注意，表格中的数据可能会变化。

假设您将文档 ID 与包含这些文档的特征（例如评论次数或点击次数）的表格相关联。表格中的特征在训练时和应用时可能有所不同。那么，您的模型在训练时和应用时对同一文档的预测就可能会不同。要避免这类问题，最简单的方法是在应用时记录特征（请参阅第 32 条规则）。如果表格只是缓慢发生变化，那么您还可以每小时或每天创建表格快照，以获得非常接近的数据。请注意，这仍不能完全解决问题。

第 32 条规则：尽可能在训练管道和应用管道间重复使用代码。

批处理不同于在线处理。进行在线处理时，您必须在每个请求到达时对其进行处理（例如，您必须为每个查询单独进行查找），而进行批处理时，您可以组合任务（例如进行关联）。应用时，您进行的是在线处理，而训练时，您进行的是批处理。不过，您可以通过一些方法来重复使用代码。例如，您可以专门为自己的系统创建一个对象，其中所有查询结果和关联都能以非常易于人类读取的方式进行存储，且错误也可以轻松进行测试。然后，收集了所有信息后，您可以在应用和训练期间使用一种共同的方法，在人类可读对象（特定于您的系统）和机器学习需要的任何格式之间架起一座桥梁。这样可以消除训练-应用偏差的一个根源。由此推知，在训练和应用时，尽量不要使用两种不同的编程语言。如果这样做，就几乎不可能共享代码了。

第 33 条规则：如果您根据 1 月 5 日之前的数据生成模型，则根据 1 月 6 日及之后的数据测试模型。

一般来说，要衡量模型的效果，应使用在训练模型所有数据对应的日期之后的日期收集的数据，因为这样能更好地反映系统应用到生产时的行为。如果您根据 1 月 5 日之前的数据生成模型，则根据 1 月 6 日及之后的数据测试模型。您一般会发现，使用新数据时模型的效果不如原来好，但应该不会太糟。由于可能存在的一些日常影响，您可能没有预测到平均点击率或转化率，但曲线下面积（表示正分类样本的分数高于负分类样本的概率）应该非常接近。

第 34 条规则：在有关过滤的二元分类（例如，垃圾邮件检测或确定有趣的电子邮件）中，在短期内小小牺牲一下效果，以获得非常纯净的数据。

在过滤任务中，标记为负分类的样本不会向用户显示。假设您的过滤器在应用时可屏蔽 75% 的负分类样本。您可能会希望从向用户显示的实例中提取额外的训练数据。例如，如果用户将您的过滤器未屏蔽的电子邮件标记为垃圾邮件，那么您可能想要从中学习规律。

但这种方法会引入采样偏差。如果您改为在应用期间将所有流量的 1% 标记为“预留”，并向用户发送所有预留样本，则您可以收集更纯净的数据。现在，过滤器屏蔽了至少 74% 的负分类样本。这些预留样本可以成为训练数据。

请注意，如果过滤器屏蔽了 95% 或以上的负分类样本，则此方法的可行性会降低。即便如此，如果您希望衡量应用效果，可以进行更低比例的采样（比如 0.1% 或 0.001%）。一万个样本足以非常准确地评估效果。

第 35 条规则：注意排名问题中存在的固有偏差。

当您彻底改变排名算法，导致出现不同的排名结果时，实际上改变了您的算法以后会处理的数据。这时，就会出现固有偏差，您应该围绕这种偏差来设计模型。具体方法有多种。以下是让您的模型青睐已见过的数据的方法。

1.对覆盖更多查询的特征（而不是仅覆盖一个查询的特征）进行更高的正则化。通过这种方式，模型将青睐专门针对一个或几个查询的特征，而不是泛化到所有查询的特征。这种方法有助于防止十分热门的查询结果显示到不相关的查询中。请注意，这与以下更为传统的建议相左：对具有更多唯一值的特征列进行更高的正则化。

2.仅允许特征具有正权重。这样一来，就可确保任何好特征都比“未知”特征合适。

3.不选择只处理文档数据的特征。这是第一条规则的极端版本。例如，即使指定应用是热门下载应用（无论查询是什么），您也不想在所有地方都展示它。如果不选择只处理文档数据的特征，这一点很容易做到。您之所以不想在所有地方展示某个特定的热门应用，是因为让用户可以找到所有所需应用至关重要。例如，如果一位用户搜索“赏鸟应用”，他/她可能会下载“愤怒的小鸟”，但那绝对不是他/她想要的应用。展示此类应用可能会提高下载率，但最终却未能满足用户的需求。

第 36 条规则：通过位置特征避免出现反馈环。

内容的位置会极大地影响用户与其互动的可能性。如果您将应用放在首位，则应用获得的点击率更高，导致您认为用户更有可能点击该应用。处理此类问题的一种方法是添加位置特征，即关于内容在网页中的位置的特征。您可以使用位置特征训练模型，使模型学习（例如）对特征“1stposition”赋予较高的权重。因此，对于具有“1stposition=true”特征的样本的其他因素，模型会赋予较低的权重。然后，在应用时，您不向任何实例提供位置特征，或为所有实例提供相同的默认特征，因为在决定以怎样的顺序显示候选实例之前，您就对其进行了打分。

请注意，因为训练和测试之间的这种不对称性，请务必在位置特征与模型的其余特征之间保持一定的分离性。让模型成为位置特征函数和其余特征函数之和是理想的状态。例如，不要将位置特征与任何文档特征组合在一起。

第 37 条规则：测量训练/应用偏差。

一般来说，很多情况都会引起偏差。此外，您可以将其分为以下几个部分：

训练数据和预留数据的效果之间的差异。一般来说，这种情况始终存在，而且并非总是坏事。
预留数据和“次日”数据的效果之间的差异。同样，这种情况始终存在。您应该调整正则化，以最大程度地提升次日数据的效果。不过，如果与预留数据相比，次日数据效果下降明显，则可能表明某些特征具有时效性，而且可能会降低模型的效果。
“次日”数据和实时数据的效果之间的差异。如果您将模型应用于训练数据中的某个样本，并在应用时使用同一样本，那么您得到的结果应该完全相同（请参阅第 5 条规则）。因此，此处的差异很可能表示出现了工程错误。

机器学习第三阶段：缓慢增长、优化细化和复杂模型

第二阶段即将结束时会出现一些信号。首先，月增长开始减弱。您将开始在指标之间做出取舍：在部分试验中，您会看到一些指标上升了，而另一些指标下降了。情况变得有趣起来。由于越来越难实现增长，因此机器学习系统必须变得更加复杂。注意：相比之前两个部分，本部分中会有较多的纯理论性规则。我们见过许多团队在机器学习的第一阶段和第二阶段非常满意。但到了第三阶段后，他们必须找到自己的道路。

第 38 条规则：如果目标不协调，并成为问题，就不要在新特征上浪费时间。

当您的衡量结果稳定时，您的团队会开始关注当前机器学习系统的目标范围之外的问题。如前所述，如果现有算法目标未涵盖产品目标，则您需要修改算法目标或产品目标。例如，您可以优化点击次数、+1 次数或下载次数，但让发布决策部分依赖于人工评分者。

第 39 条规则：发布决策代表的是长期产品目标。

Alice 有一个关于减少预测安装次数的逻辑损失的想法。她添加了一个特征。逻辑损失降低了。当她运行在线实验时，看到安装率增加了。但是，在发布评审会上，有人指出，每日活跃用户数减少了 5%。于是，团队决定不发布该模型。Alice 很失望，但现在她意识到发布决策取决于多个条件，只有一部分条件可以通过机器学习直接得到优化。

事实上，现实世界并不是网游世界：没有“生命值”来确定产品的运行状况。团队必须使用自己收集的统计信息来尝试有效地预测系统未来的表现会如何。他们需要关注互动度、日活跃用户数 (DAU)、30 日 DAU、收入以及广告主的投资回报率。这些可在 A/B 测试中衡量的指标本身仅代表了以下更长期目标：让用户满意、增加用户数量、让合作伙伴满意以及实现盈利，进一步，您还可以认为它们代表了发布优质且实用的产品，以及五年后公司繁荣发展。

唯一可以轻松做出发布决策的情况是，所有指标都在变好（或至少没有变差）。如果团队能够在复杂的机器学习算法和简单的启发式算法之间做出选择，而对所有这些指标来说，简单的启发式算法可以提供更好的效果，那么应该选择启发式算法。此外，并未对所有可能的指标值进行明确排名。具体而言，请考虑以下两种情形：

如果当前系统是 A，那么团队不太可能会改用 B。如果当前系统是 B，那么团队不太可能会改用 A。这似乎与理性行为背道而驰；但是，对更改指标的预测可能会成功也可能不会，因此这两种改变都蕴含着巨大的风险。每个指标都涵盖了团队所担心的一些风险。

此外，没有一个指标涵盖团队最关心的问题，即“五年后我的产品将何去何从”？

另一方面，个人更倾向于选择可以直接优化的目标。大多数机器学习工具也都青睐这样的环境。在这样的环境下，快速创建新特征的工程师能稳定地进行一系列发布。一种称为“多目标学习”的机器学习已开始解决此问题。例如，您可以提出约束满足问题，对每个指标设定下限，并优化指标的一些线性组合。不过，即使如此，也并不是所有指标都可以轻松框定为机器学习目标：如果用户点击了文档或安装了应用，那是因为相应内容展示出来了。但要弄清楚用户为什么访问您的网站就难得多。如何预测整个网站未来的成功状况属于 AI 完备问题：与计算机视觉或自然语言处理一样难。

第 40 条规则：保证集成学习简单化。

采用原始特征并直接对内容进行排名的统一模型是最易于进行调试和理解的模型。但是，集成学习模型（将其他模型的分数结合到一起的模型）可以实现更好的效果。为了简单起见，每个模型应该要么是仅接受其他模型的输入的集成学习模型，要么是接受多个特征的基本模型，但不能两者皆是。如果在单独训练的模型之上还有其他模型，则组合它们会导致不良行为。

使用简单的模型进行集成学习（仅将“基本”模型的输出作为输入）。此外，您还需要将属性强加到这些集成学习模型上。例如，基本模型生成的分数的升高不应使集成学习模型的分数有所降低。另外，如果传入的模型在语义上可解释（例如，经过校准），则最理想，因为这样一来，即使基本模型发生改变，也不会扰乱集成学习模型。另外，强制要求：如果基本分类器的预测概率增大，不会使集成学习模型的预测概率降低。

第 41 条规则：效果达到平稳后，寻找与现有信号有质的差别的新信息源并添加进来，而不是优化现有信号。

您添加了一些有关用户的受众特征信息，也添加了一些有关文档中字词的信息。您探索了模板，并调整了正则化。但在几个季度的发布中，关键指标的提升幅度从来没有超过 1%。现在该怎么办？

是时候开始为截然不同的特征（例如，用户在过去一天内、一周内或一年内访问的文档的历史记录，或者其他属性的数据）构建基础架构了。您可以使用维基数据条目或公司内部信息（例如，Google 的知识图谱）。利用深度学习。开始调整您对投资回报的预期，并付出相应的努力。与在任何工程项目中一样，您必须对添加新特征的好处与增加复杂性的成本进行一番权衡。

第 42 条规则：不要期望多样性、个性化或相关性与热门程度之间的联系有您认为的那样密切。

一组内容中的多样性可以有多种含义，其中内容来源的多样性是最常见的一种。个性化意味着每个用户获得贴合其个人需求的结果。相关性意味着某个特定查询的结果更适合该查询，而非其他任何查询。因此，这三个属性均具有不同于常态的定义。

但常态往往很难被打败。

请注意，如果您的系统在测量点击次数、访问时间、观看次数、+1 次数、转发次数等数据，那么您测量的是内容的热门程度。团队有时会尝试学习具备多样性的个性化模型。为实现个性化，他们会添加支持系统进行个性化（代表用户兴趣的部分特征）或多样化（表明相应文档是否与其他返回的文档有任何相同特征的特征，例如作者或内容）的特征，然后发现这些特征的权重比预期低（或者有时是不同的信号）。

这并不意味着多样性、个性化或相关性不重要。正如上一条规则中所指出的那样，您可以进行后期处理来增加多样性或相关性。如果您看到更长期的目标有所增长，您可以声明除了热门程度外，多样性/相关性也很有价值。然后，您可以继续采用后期处理方法，也可以根据多样性或相关性直接修改目标。

第 43 条规则：在不同的产品中，您的好友基本保持不变，但您的兴趣并非如此。

Google 的团队通过以下做法取得了大量进展：采用一个预测产品中某种联系的紧密程度的模型，并使用该模型对其他产品进行准确预测。您的好友保持不变。另一方面，我曾见过几个团队在应对多个产品间的个性化特征时捉襟见肘。是的，当时看起来应该可以奏效的。但现在看来并没有。有时可以奏效的方法是，使用一个属性的原始数据来预测另一个属性的行为。此外，请注意，仅仅是知道用户有其他属性的历史记录也会有帮助。例如，两个产品上出现了用户活动或许本身就可以说明该问题。

相关资源

Google 内部和外部有许多关于机器学习的文档。

机器学习速成课程：应用机器学习简介。
机器学习：概率法，凯文·墨菲著，帮助了解机器学习领域。
分析大型复杂数据集的实用建议：一种考虑数据集的数据科学方法。
深度学习，伊恩·古德费洛等著，帮助学习非线性模型。
关于技术负债的 Google 论文，其中提供了许多一般性建议。
Tensorflow 文档。

致谢

感谢 David Westbrook、Peter Brandt、Samuel Ieong、Chenyu Zhao、Li Wei、Michalis Potamias、Evan Rosen、Barry Rosenberg、Christine Robson、James Pine、Tal Shaked、Tushar Chandra、Mustafa Ispir、Jeremiah Harmsen、Konstantinos Katsiapis、Glen Anderson、Dan Duckworth、Shishir Birmiwal、Gal Elidan、Su Lin Wu、Jaihui Liu、Fernando Pereira 和 Hrishikesh Aradhye 对本文档进行多处更正、提供建议和有用示例。此外，还要感谢 Kristen Lefevre、Suddha Basu 和 Chris Berg 对早期版本提供的帮助。任何错误、遗漏或（喘气声！）不受欢迎的看法均由本人承担责任。

附录

本文档中多处提到了一些 Google 产品。为了提供更多背景信息，我将在下面对几个最常见的示例进行简单说明。

YouTube 概览

YouTube 是流式视频服务。YouTube 的“接下来观看”和 YouTube 首页团队均使用机器学习模型对推荐视频进行排名。“接下来观看”会推荐在当前视频播放完后观看的视频，而首页向浏览首页的用户推荐视频。

Google Play 概览

Google Play 有许多解决各种问题的模型。Play 搜索、Play 首页个性化推荐和“用户还安装了以下应用”都采用了机器学习技术。

Google+ 概览

Google+ 在各种情况下采用了机器学习技术，例如对用户可以看见的帖子“信息流”中的帖子进行排名时、对“热门信息”中的帖子（目前非常热门的帖子）进行排名时、对您认识的人进行排名时，等等。

原文地址：

https://developers.google.cn/machine-learning/rules-of-ml/#human_analysis_of_the_system

对了，我们招人了，了解一下？