【机器学习】Google机器学习工程的43条最佳实践

本文档旨在帮助那些掌握机器学习基础知识的人从Google机器学习的最佳实践中获益。它提供了机器学习的风格，类似于Google C ++风格指南和其他流行的实用编程指南。如果您参加了机器学习课程，或者在机器学习模型上构建或工作，那么您就具备了阅读本文档的必要背景知识。

术语

在我们关于有效机器学习的讨论中，将反复提出以下术语：

• 实例：您想要做出预测的事情。例如，实例可能是您要将其分类为“关于猫”或“不关于猫”的网页。
• 标签：预测任务的答案，可以是机器学习系统产生的答案，也可以是训练数据中提供的正确答案。例如，网页的标签可能是“关于猫”。
• 功能：预测任务中使用的实例的属性。例如，网页可能具有“包含单词'cat'”的功能。
• 功能列：一组相关功能，例如用户可能居住的所有可能国家/地区的集合。示例可以在特征列中具有一个或多个特征。“功能列”是特定于Google的术语。功能列在VW系统（在Yahoo / Microsoft中）或字段中称为“名称空间” 。
• 示例：实例（具有其功能）和标签。
• 模型：预测任务的统计表示。您在示例上训练模型，然后使用模型进行预测。
• 指标：您关心的数字。可能会或可能不会直接优化。
• 目标：您的算法尝试优化的指标。
• 管道：围绕机器学习算法的基础设施。包括从前端收集数据，将其放入培训数据文件，培训一个或多个模型，以及将模型导出到生产中。
• 点击率点击广告中链接的网页访问者所占的百分比。

概述

制作出色的产品：

做机器学习就像你是伟大的工程师，而不是像你不是伟大的机器学习专家。

事实上，您将面临的大多数问题都是工程问题。即使拥有优秀的机器学习专家的所有资源，大部分收益来自强大的功能，而不是伟大的机器学习算法。所以，基本方法是：

1. 确保您的管道端到端坚固。
2. 从合理的目标开始。
3. 以简单的方式添加常识功能。
4. 确保您的管道保持稳固。

这种方法可以在很长一段时间内很好地工作。只有在没有更简单的技巧可以让你更远的时候，才能摆脱这种方法。增加复杂性会降低未来的版本。

一旦你用尽了简单的技巧，最先进的机器学习可能确实在你的未来。请参阅 第III阶段 机器学习项目部分。

本文件安排如下：

1. 在第一部分应该帮助您了解的时间是否是正确的建设机器学习系统。
2. 在第二部分是有关部署你的第一个管道。
3. 在第三部分是关于启动和同时增加新的功能，以您的管道，如何评价模型和服务培训歪斜迭代。
4. 最后一部分 是关于到达高原时该 怎么做。
5. 之后，有一份相关工作清单和一个 附录，其中介绍了本文档中常用的系统背景。

机器学习之前

规则＃1：不要害怕在没有机器学习的情况下推出产品。

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

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

 

规则2：首先，设计和实施指标。

在正式确定机器学习系统的功能之前，请尽可能在当前系统中进行跟踪。这样做的原因如下：

1. 以前更容易获得系统用户的许可。
2. 如果您认为将来可能会关注某些事情，那么现在最好获取历史数据。
3. 如果您在设计系统时考虑到公制工具，将来情况会更好。具体来说，您不希望自己在日志中使用字符串来检测指标！
4. 你会注意到什么变化，什么保持不变。例如，假设您想直接优化为期一天的活跃用户。但是，在您早期操作系统期间，您可能会注意到用户体验的显着变化并未显着改变此度量标准。

Google Plus团队衡量每次阅读的扩展，每次阅读的转发，每次阅读的加号，评论/阅读，每位用户的评论，每位用户的转发等，用于计算服务时间帖子的优点。另外，请注意，您可以将用户分组到存储桶并通过实验汇总统计信息的实验框架非常重要。参见 规则＃12。

通过更加自由地收集指标，您可以更全面地了解您的系统。注意一个问题？添加指标以跟踪它！对上次发布的一些数量变化感到兴奋？添加指标以跟踪它！

 

规则＃3：选择复杂启发式的机器学习。

一个简单的启发式方法可以让您的产品出门。复杂的启发式方法是不可维护的。一旦掌握了数据并了解了您要完成的任务，请继续学习机器学习。与大多数软件工程任务一样，您将希望不断更新您的方法，无论是启发式还是机器级模型，您都会发现机器学习模型更易于更新和维护（参见 规则＃16）。

 

第一阶段：您的第一条管道

专注于您的第一个管道的系统基础架构。虽然想想你将要做的所有富有想象力的机器学习很有趣，但如果你不首先信任你的管道，就很难弄清楚发生了什么。

 

规则＃4：保持第一个模型简单并使基础设施正确。

第一个型号为您的产品提供了最大的推动力，因此它不需要花哨。但是，您将遇到比预期更多的基础设施问题。在任何人都可以使用你喜欢的新机器学习系统之前，你必须确定：

• 如何获得学习算法的示例。
• 关于“好”和“坏”对您的系统意味着什么的第一次切入。
• 如何将您的模型集成到您的应用程序中。您可以实时应用模型，也可以离线预先计算模型，并将结果存储在表中。例如，您可能希望对网页进行预分类并将结果存储在表中，但您可能希望实时对聊天消息进行分类。

选择简单的功能可以更轻松地确保：

• 这些功能正确地达到了您的学习算法
• 该模型学习合理的权重。
• 这些功能可以在服务器中正确访问您的模型。

一旦你有一个能够可靠地完成这三件事的系统，你就完成了大部分的工作。您的简单模型为您提供基准度量和基准行为，您可以使用它们来测试更复杂的模型。一些团队的目标是首次推出“中性”：首次发布，明确优先考虑机器学习收益，避免分心。

 

规则＃5：独立于机器学习测试基础设施。

确保基础结构是可测试的，并且系统的学习部分是封装的，以便您可以测试它周围的所有内容。特别：

1. 测试将数据导入算法。检查是否已填充应填充的要素列。在隐私允许的情况下，手动检查训练算法的输入。如果可能，检查管道中的统计信息与其他地方处理的相同数据的统计信息进行比较。
2. 测试从训练算法中获取模型。确保培训环境中的模型与服务环境中的模型具有相同的分数（请参阅 规则＃37）。

机器学习具有不可预测性的因素，因此请确保您在训练和服务中创建示例的代码测试，并且您可以在服务期间加载和使用固定模型。此外，了解您的数据非常重要：请参阅 大型复杂数据集分析的实用建议。

 

规则＃6：复制管道时要小心丢弃数据。

我们通常通过复制现有管道（即货物编程 ）来创建管道 ，而旧管道会丢弃新管道所需的数据。例如，谷歌加热管道什么是热点掉旧帖子（因为它试图对新帖子进行排名）。此管道已复制用于Google Plus流，旧帖子仍然有意义，但管道仍在丢失旧帖子。另一种常见模式是仅记录用户看到的数据。因此，如果我们想要模拟用户未看到特定帖子的原因，则此数据是无用的，因为所有负面示例都已被删除。Play中也出现了类似的问题。在Play Apps Home上工作时，创建了一个新的管道，其中还包含Play Games登录页面中的示例，没有任何功能可以消除每个示例来自哪里的歧义。

 

规则＃7：将启发式转换为功能，或在外部处理它们。

通常机器学习试图解决的问题并不是全新的。现有的系统可用于排名，分类或解决您要解决的任何问题。这意味着有一堆规则和启发式。当使用机器学习进行调整时，这些相同的启发式方法可以为您提供帮助。出于两个原因，您的启发式搜索应该针对他们拥有的任何信息进行挖掘。首先，向机器学习系统的过渡将更加顺畅。其次，通常这些规则包含很多关于你不想丢弃的系统的直觉。有四种方法可以使用现有的启发式方法：

• 使用启发式预处理。如果该功能非常棒，那么这是一个选项。例如，如果在垃圾邮件过滤器中，发件人已被列入黑名单，请不要尝试重新学习“列入黑名单”的含义。阻止消息。这种方法在二进制分类任务中最有意义。
• 创建一个功能。直接从启发式创建特征是很棒的。例如，如果使用启发式方法计算查询结果的相关性分数，则可以将分数包括为要素的值。稍后您可能希望使用机器学习技术来按摩值（例如，将值转换为一组有限的离散值，或将其与其他特征组合），但首先使用启发式生成的原始值。
• 挖掘启发式的原始输入。如果有一个启发式应用程序结合了安装次数，文本中的字符数和星期几，那么请考虑将这些部分分开，并将这些输入分别输入到学习中。适用于合奏的一些技术适用于此处（参见 规则＃40）。
• 修改标签。当您认为启发式捕获标签中当前未包含的信息时，这是一个选项。例如，如果您尝试最大化下载次数，但您也想要高质量的内容，那么解决方案是将标签乘以应用程序收到的平均星数。这里有很多余地。请参阅“您的第一个目标”。

在ML系统中使用启发式时，请注意增加的复杂性。在新的机器学习算法中使用旧的启发式算法可以帮助创建平滑过渡，但考虑是否有更简单的方法来实现相同的效果。

 

监控

通常，实施良好的警报卫生，例如使警报可操作并具有仪表板页面。

规则＃8：了解系统的新鲜度要求。

如果你有一个一天的模型，性能会降低多少？一周大了？四分之一岁？此信息可帮助您了解监控的优先级。如果您的模型在一天内没有更新，您会失去重要的产品质量，让工程师不断观察它是有意义的。大多数广告投放系统都有每天都要处理的新广告，并且必须每天更新。例如，如果Google Play搜索的ML模型 未更新，则可能会在一个月内产生负面影响。适用于Google Plus的热门游戏的一些型号 在他们的模型中没有帖子标识符，因此他们可以不经常导出这些模型。具有帖子标识符的其他模型更频繁地更新。另请注意，新鲜度可能会随着时间的推移而发生变化，尤其是在模型中添加或删除要素列时。

规则＃9：在导出模型之前检测问题。

许多机器学习系统都有一个阶段，您可以将模型导出到服务中。如果导出的模型存在问题，则它是面向用户的问题。

在导出模型之前进行完整性检查。具体来说，确保模型的性能在保持数据上是合理的。或者，如果您对数据有疑虑，请不要导出模型。许多团队不断部署模型， 在出口前检查ROC曲线（或AUC）下的区域 。有关尚未导出的模型的问题需要电子邮件警报，但面向用户的模型上的问题可能需要页面。因此，最好等待并确保在影响用户之前。

 

规则＃10：注意无声失败。

对于机器学习系统而言，这是一个比其他类型系统更多的问题。假设正在加入的特定表不再更新。机器学习系统将调整，行为将继续相当好，逐渐衰减。有时你会发现几个月过时的表格，而简单的刷新比那个季度的任何其他发布都提高了性能！由于实现更改，功能的覆盖范围可能会发生变化：例如，90％的示例中可以填充功能列，并且突然降至60％的示例。玩过一次有6个月陈旧的桌子，单独刷新桌子的安装率提高了2％。如果您跟踪数据的统计信息，以及手动检查数据，则可以减少这些类型的故障。

规则＃11：提供功能列所有者和文档。

如果系统很大，并且有许多功能列，请知道谁创建或维护每个功能列。如果您发现了解功能列的人员正在离开，请确保有人拥有该信息。尽管许多功能列都具有描述性名称，但最好有一个更详细的描述功能是什么，它来自何处以及预期如何提供帮助。

 

你的第一个目标

您有许多指标或关于您关心的系统的测量，但您的机器学习算法通常需要一个目标，即您的算法“尝试”优化的数字。我在此区分目标和指标：指标是系统报告的任何数字，可能重要也可能不重要。另见 规则＃2。

 

规则＃12：不要过度思考您选择直接优化的目标。

你想赚钱，让你的用户满意，让世界变得更美好。您关注的指标很多，您应该全部测量它们（请参阅规则＃2）。但是，在机器学习过程的早期，您会发现它们都在上升，甚至是那些您没有直接优化的。例如，假设您关心点击次数和在网站上花费的时间。如果优化点击次数，您可能会看到花费的时间增加。

因此，保持简单，并且在您仍然可以轻松增加所有指标时，不要过于平衡不同的指标。不要过分遵守这一规则：不要将您的目标与系统的最终健康状况混淆（参见 规则＃39）。而且，如果您发现自己增加了直接优化的指标，但决定不启动，则可能需要进行一些客观的修订。

 

规则＃13：为您的第一个目标选择一个简单，可观察和可归因的指标。

通常你不知道真正的目标是什么。你认为你这样做但是当你盯着旧系统和新ML系统的数据和并排分析时，你意识到你想要调整目标。此外，不同的团队成员往往无法就真正的目标达成一致。ML目标应该是易于衡量的东西，并且是“真实”目标的代表。 事实上，通常没有“真正的”目标（见 规则＃39）。因此，训练简单的ML目标，并考虑在顶部设置一个“策略层”，允许您添加额外的逻辑（希望非常简单的逻辑）来进行最终排名。

最简单的建模是直接观察并归因于系统操作的用户行为：

• 这个排名链接被点击了吗？
• 这个排名对象是下载的吗？
• 这个排名对象是转发/回复/通过电子邮件发送的吗？
• 这个排名对象是否被评级？
• 这个被显示的对象被标记为垃圾/色情/冒犯吗？

首先避免建模间接效应：

• 用户第二天访问了吗？
• 用户访问该网站多久了？
• 每日活跃用户是什么？

间接效应可以提供很好的指标，可以在A / B测试期间和发布决策期间使用。

最后，不要试图让机器学会弄清楚：

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

这些都很重要，但也难以衡量。相反，使用代理：如果用户满意，他们将在网站上停留更长时间。如果用户满意，他们明天将再次访问。就健康和公司健康而言，需要人为判断将任何机器学习目标与您销售的产品的性质和您的商业计划联系起来。

 

规则＃14：从可解释的模型开始，使调试更容易。

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

例如，在线性，逻辑或泊松回归中，存在数据的子集，其中平均预测期望等于平均标签（1-刻度校准，或仅校准）。这是正确的，假设您没有正则化并且您的算法已经收敛，并且它通常是近似真实的。如果每个示例都有1或0的特征，则校准该特征为1的3个示例集。此外，如果每个示例的特征都是1，则校准所有示例的集合。

使用简单模型，处理反馈循环更容易（参见 规则＃36）。通常，我们使用这些概率预测来做出决定：例如，在降低预期值（即点击/下载/等概率）中对帖子进行排名。 但是，请记住，当选择使用哪种模型时，决策比给定模型的数据的可能性更重要（参见 规则＃27）。

规则＃15：在策略层中分离垃圾邮件过滤和质量排名。

质量排名是一门艺术，但垃圾邮件过滤是一场战争。用于确定高质量帖子的信号对于使用您系统的用户来说将变得显而易见，他们会调整帖子以获得这些属性。因此，您的质量排名应该专注于对善意发布的内容进行排名。你不应该高质量排名学习者高举垃圾邮件排名。同样，“racy”内容应与质量排名分开处理。垃圾邮件过滤是一个不同的故事。您必须期望生成的功能将不断变化。通常，您会在系统中添加明显的规则（如果帖子有超过三个垃圾邮件投票，则不会检索它，等等）。任何学过的模型都必须每天更新，如果不是更快的话。内容创建者的声誉将发挥重要作用。

在某种程度上，必须整合这两个系统的输出。请注意，过滤搜索结果中的垃圾邮件可能比过滤电子邮件中的垃圾邮件更具侵略性。假设您没有正则化并且算法已收敛，则这是正确的。一般来说大致是正确的。此外，标准做法是从质量分类器的训练数据中删除垃圾邮件。

 

第二阶段：特征工程

在机器学习系统生命周期的第一阶段，重要的问题是将培训数据导入学习系统，获取任何感兴趣的指标，并创建服务基础架构。在您使用装配有单元和系统测试的端到端工作系统后，第二阶段开始。

在第二阶段，有很多悬而未决的成果。有许多明显的功能可以被引入系统。因此，机器学习的第二阶段涉及尽可能多地引入特征并以直观方式组合它们。在此阶段，所有指标仍应上升。将有很多发布会，现在是吸引大量工程师的好时机，他们可以加入您创建真正令人敬畏的学习系统所需的所有数据。

 

规则＃16：计划启动和迭代。

不要指望您现在正在使用的模型将是您将要启动的最后一个模型，或者甚至您将停止启动模型。因此，请考虑您在此次发布时添加的复杂性是否会降低未来的发布速度。许多团队多年来每季度或更长时间推出一个模型。推出新车型有三个基本原因：

• 您正在提出新功能。
• 您正在调整正则化并以新方式组合旧功能。
• 你正在调整目标。

无论如何，为模型赋予一点爱情可能会很好：查看示例中的数据可以帮助找到新的信号以及旧的，破碎的信号。因此，在构建模型时，请考虑添加或删除或重新组合功能是多么容易。想想创建管道的新副本并验证其正确性是多么容易。考虑是否可以并行运行两个或三个副本。最后，不要担心35的功能16是否进入此版本的管道。你下个季度会得到它。

 

规则＃17：从直接观察和报告的特征开始，而不是学习特征。

这可能是一个有争议的问题，但它避免了很多陷阱。首先，让我们描述学习的功能是什么。学习特征是由外部系统（例如无监督的聚类系统）或学习者自身（例如通过因式模型或深度学习）生成的特征。这两个都很有用，但它们可能有很多问题，所以它们不应该在第一个模型中。

如果使用外部系统创建功能，请记住外部系统有自己的目标。外部系统的目标可能只与您当前的目标微弱相关。如果您获取外部系统的快照，则它可能会过时。如果从外部系统更新功能，则含义可能会更改。如果您使用外部系统提供功能，请注意此方法需要非常小心。

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

 

规则＃18：探索跨上下文概括的内容功能。

通常机器学习系统只是更大图片的一小部分。例如，如果您想象一个帖子可能会在What's Hot中使用，那么很多人会在帖子中显示加号，转发或评论，然后才会显示在热门内容中。如果您向学习者提供这些统计信息，它可以在其优化的上下文中宣传没有数据的新帖子。 YouTube的观看接下来可以使用手表的数量，或共同钟表（一个视频多少次后，另一观看计数来观看）从YouTube的搜索。您还可以使用显式用户评级。最后，如果您有一个用作标签的用户操作，那么在不同的上下文中查看该文档上的操作可能是一个很好的功能。所有这些功能都允许您将新内容带入上下文。请注意，这不是关于个性化：弄清楚是否有人首先喜欢这个上下文中的内容，然后找出更喜欢或更喜欢它的人。

 

规则＃19：尽可能使用非常具体的功能。

凭借大量数据，学习数百万个简单功能比使用一些复杂功能更简单。正在检索的文档的标识符和规范化的查询不会提供太多的概括，但会将您的排名与头部查询上的标签对齐。因此，不要害怕每个功能适用于您的数据的一小部分的功能组，但总体覆盖率高于90％。您可以使用正则化来消除适用于极少示例的功能。

 

规则＃20：组合和修改现有功能，以人类可理解的方式创建新功能。

有多种方法可以组合和修改功能。TensorFlow等机器学习系统允许您通过转换预处理数据 。两种最标​​准的方法是“离散化”和“交叉”。

离散化包括获取连续特征并从中创建许多离散特征。考虑一个连续的功能，如年龄。您可以创建一个功能，当年龄小于18时，该功能为1，另一个功能在年龄介于18和35之间时为1，等等。不要过度思考这些直方图的边界：基本分位数会给你带来最大的影响。

十字架组合了两个或更多要素列。TensorFlow的术语中的一个特征列是一组同质特征（例如{male，female}，{US，Canada，Mexico}等等。十字架是一个新功能列，其功能包括{男性，女性}×{美国，加拿大，墨西哥}。此新功能列将包含该功能（男性，加拿大）。如果您正在使用TensorFlow并告诉TensorFlow为您创建此十字架，则此（男性，加拿大）功能将出现在代表男性加拿大人的示例中。请注意，需要大量数据才能学习具有三个，四个或更多基本特征列交叉的模型。

产生非常大的特征列的十字架可能过度拟合。例如，假设您正在进行某种搜索，并且您在查询中有一个包含单词的功能列，并且您有一个功能列，其中包含文档中的单词。您可以将它们与十字架结合起来，但最终会有很多功能（参见规则＃21）。

使用文本时，有两种选择。最苛刻的是点积。最简单形式的点积只是计算查询和文档之间共同的单词数。然后可以将此功能离散化。另一种方法是交叉：因此，当且仅当单词“pony”同时出现在文档和查询中时，我们才会有一个特征，当且仅当单词“the”出现时，才会出现另一个特征。在文档和查询中。

 

规则＃21：您可以在线性模型中学习的要素权重数量与您拥有的数据量大致成比例。

关于模型的适当复杂程度，有令人着迷的统计学习理论结果，但这个规则基本上只是你需要知道的。我有过一些对话，人们怀疑从千个例子中可以学到什么，或者你需要超过一百万个例子，因为他们陷入某种学习方法。关键是将您的学习扩展到您的数据大小：

1. 如果您正在使用搜索排名系统，并且文档和查询中有数百万个不同的单词，并且您有1000个标记示例，那么您应该在文档和查询功能之间使用点积，TF-IDF和一半 - 打破其他高度人性化的功能。1000个例子，十几个功能。
2. 如果您有一百万个示例，则使用正则化和可能的要素选择与文档和查询要素列相交。这将为您提供数百万个功能，但通过正规化，您将拥有更少的功能。一千万个例子，可能十万个功能。
3. 如果您有数十亿或数千亿个示例，则可以使用特征选择和正则化来跨文档和查询标记的要素列。您将拥有十亿个示例和一千万个功能。统计学习理论很少给出严格的界限，但为起点提供了很好的指导。

最后，使用 规则＃28 来决定使用哪些功能。

 

规则＃22：清理不再使用的功能。

未使用的功能会产生技术债务。如果您发现自己没有使用某项功能，并且将其与其他功能结合使用无效，请将其从基础架构中删除。您希望保持基础架构清洁，以便尽可能快地尝试最有希望的功能。如有必要，有人可以随时添加您的功能。

在考虑添加或保留哪些功能时，请牢记相关信息。该功能涵盖了多少个示例？例如，如果您有一些个性化功能，但只有8％的用户拥有任何个性化功能，那么它将不会非常有效。

与此同时，一些功能可能超过他们的重量。例如，如果您的功能仅覆盖了1％的数据，但90％的具有该功能的示例都是正面的，那么添加它将是一个很棒的功能。

 

系统的人体分析

在进入机器学习的第三阶段之前，重点关注任何机器学习课程中没有教授的内容：如何查看现有模型并进行改进。这更像是一门艺术，而不是一门科学，但有几种反模式有助于避免。

 

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

这可能是团队陷入困境的最简单方法。虽然鱼类食物（使用团队中的原型）和狗食（使用公司内部的原型）有很多好处，但员工应该考虑表现是否正确。虽然不应该使用明显不好的变化，但是任何看起来接近生产的东西都应该进一步测试，要么通过支付外行来回答众包平台上的问题，要么通过真实用户的实时实验。

有两个原因。首先是你太靠近代码了。您可能正在寻找帖子的特定方面，或者您过于情绪化（例如确认偏见）。第二是你的时间太宝贵了。考虑九个工程师参加一小时会议的成本，并考虑在众包平台上购买多少合同人工标签。

如果您确实希望获得用户反馈，请使用用户体验方法。在一个过程的早期创建用户角色（一个描述在Bill Buxton的 草绘用户体验中）并稍后进行可用性测试（一个描述在Steve Krug的“ 不要让我思考”）。用户角色涉及创建假设用户。例如，如果你的团队都是男性，可能有助于设计一个35岁的女性用户角色（完整的用户功能），并查看它产生的结果而不是10到25岁到40岁的结果男性。让实际人员观察他们对您的网站（本地或远程）在可用性测试中的反应也可以让您获得全新的视角。

 

规则＃24：测量模型之间的增量。

在任何用户查看新模型之前，您可以进行的最简单且有时最有用的测量之一是计算新结果与生产的差异。例如，如果您有排名问题，请在整个系统中对查询样本运行两个模型，并查看结果对称差异的大小（按排名位置加权）。如果差异非常小，那么您可以在不进行实验的情况下判断出几乎没有变化。如果差异非常大，那么您需要确保更改是好的。查看对称差异较大的查询可以帮助您定性地了解更改的内容。但请确保系统稳定。

 

规则＃25：在选择模型时，实用性能胜过预测能力。

您的模型可能会尝试预测点击率。但是，最后，关键问题是你如何处理这种预测。如果您使用它来对文档进行排名，那么最终排名的质量比预测本身更重要。如果您预测文档是垃圾邮件的可能性，然后对被阻止的内容进行截断，那么通过更多内容允许的精度。大多数时候，这两件事情应该是一致的：当他们不同意时，它可能会获得小幅收益。因此，如果存在一些改进日志丢失但会降低系统性能的更改，请查找其他功能。当这种情况经常发生时，是时候重新审视模型的目标了。

 

规则＃26：查找测量误差中的模式，并创建新功能。

假设您看到模型“错误”的训练示例。在分类任务中，此错误可能是误报或误报。在排名任务中，错误可以是一对，其中积极排名低于负数。最重要的一点是，这是机器学习系统知道它出错的一个例子，并且如果有机会就想解决。如果为模型提供允许其修复错误的功能，则模型将尝试使用它。

另一方面，如果您尝试基于示例创建功能，系统不会将其视为错误，则将忽略该功能。例如，假设在Play Apps Search中，有人搜索“免费游戏”。假设其中一个顶级结果是一个不太相关的插科打app。因此，您为“gag apps”创建了一项功能。但是，如果您正在最大化安装次数，并且人们在搜索免费游戏时安装了一个插科打app，则“gag apps”功能将无法获得您想要的效果。

一旦您有模型出错的示例，请查找当前功能集之外的趋势。例如，如果系统似乎降低了较长的帖子，则添加帖子长度。不要过于具体地说明您添加的功能。如果你要添加帖子长度，不要试图猜测长度意味着什么，只需添加十几个功能，让模型弄清楚如何处理它们（参见 规则＃21 ）。这是获得你想要的最简单的方法。

 

规则＃27：尝试量化观察到的不良行为。

您的团队的一些成员将开始对他们不喜欢的系统的属性感到沮丧，这些属性不会被现有的损失功能捕获。在这一点上，他们应该尽一切努力将他们的抱怨变成坚实的数字。例如，如果他们认为在Play Search中显示太多“插科打app”，他们就可以让人类评估者识别插科打app。（在这种情况下，您可以切实使用人工标记的数据，因为相对较小的查询占流量的很大一部分。）如果您的问题是可衡量的，那么您可以开始将它们用作功能，目标或指标。一般规则是“ 先测量，优化第二 ”。

规则＃28：注意相同的短期行为并不意味着相同的长期行为。

想象一下，您有一个新系统，它查看每个doc_id和exact_query，然后为每个查询计算每个文档的点击概率。您会发现它的行为与您当前的系统几乎完全相同，无论是并排还是A / B测试，因此您可以启动它。但是，您注意到没有显示新的应用程序。为什么？好吧，由于您的系统仅根据自己的历史记录显示该查询，因此无法了解应该显示新文档。

了解这样一个系统如何长期运作的唯一方法是让它只训练模型生效时获得的数据。这非常困难。

 

训练 - 服务歪斜

训练服务偏差是训练期间的表现与服务期间的表现之间的差异。这种倾斜可能是由以下原因引起的：

• 处理培训数据和提供管道数据之间的差异。
• 您在训练和服务之间的数据变化。
• 模型和算法之间的反馈循环。

我们观察到Google的生产机器学习系统存在培训服务偏差，从而对性能产生负面影响。最好的解决方案是明确监控它，以便系统和数据更改不会引起偏差。

 

规则＃29：确保您像服务一样训练的最佳方法是保存服务时使用的功能集，然后将这些功能传输到日志以在训练时使用它们。

即使你不能为每个例子做到这一点，也要做一小部分，这样你就可以验证服务和培训之间的一致性（参见规则＃37）。在Google上进行此测量的团队有时会对结果感到惊讶。 YouTube主页在服务时切换到日志记录功能，显着提高了质量并降低了代码复杂性，许多团队正在按照我们的说法切换基础架构。

 

规则＃30：重要性 - 权重采样数据，不要随意丢弃它！

如果您有太多数据，则会尝试获取文件1-12，并忽略文件13-99。这是个错误。虽然可以删除从未向用户显示的数据，但重要性加权最好是其余部分。重要性加权意味着如果您决定以30％的概率对示例X进行采样，则给它一个10/3的权重。通过重要性加权，规则＃14中讨论的所有校准属性 仍然有效。

 

规则＃31：请注意，如果您在培训和服务时间从表中加入数据，表中的数据可能会更改。

假设您使用包含这些文档功能的表（例如注释或点击次数）加入doc ids。在训练和服务时间之间，表格中的功能可能会发生变化。然后，您的模型对同一文档的预测可能在培训和服务之间有所不同。避免此类问题的最简单方法是在服务时记录功能（请参阅 规则＃32 ）。如果表格只是缓慢变化，您还可以每小时或每天快照表格以获得合理的数据。请注意，这仍然无法完全解决问题。

 

规则＃32：尽可能在您的培训管道和服务管道之间重用代码。

批处理与在线处理不同。在在线处理中，您必须在到达时处理每个请求（例如，您必须为每个查询单独查找），而在批处理中，您可以组合任务（例如，进行连接）。在服务时，您正在进行在线处理，而培训是批处理任务。但是，您可以执行一些重复使用代码的操作。例如，您可以创建一个特定于您的系统的对象，其中任何查询或联接的结果都可以以非常易读的方式存储，并且可以轻松地测试错误。然后，一旦您收集了所有信息，在服务或培训期间，您就会运行一种通用方法来桥接特定于您的系统的人类可读对象，以及机器学习系统所期望的任何格式。这消除了训练服务倾斜的来源。作为必然结果，尽量不要在训练和服务之间使用两种不同的编程语言。该决定将使您几乎无法共享代码。

 

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

通常，在您训练模型的数据之后测量模型的性能，因为这更好地反映了您的系统在生产中将执行的操作。如果您在1月5日之前根据数据生成模型，请在1月6日的数据上测试模型。您会期望新数据的性能不会那么好，但它不应该更糟糕。由于可能存在日常效应，您可能无法预测平均点击率或转化率，但曲线下面积（表示给出正面示例的得分高于反面示例的可能性）应该相当接近。

 

规则＃34：在用于过滤的二进制分类（例如垃圾邮件检测或确定有趣的电子邮件）中，对于非常干净的数据，在性能上做出小的短期牺牲。

在过滤任务中，标记为否定的示例不向用户显示。假设您有一个过滤器可以阻止75％的负面示例。您可能想从显示给用户的实例中提取其他培训数据。例如，如果用户将电子邮件标记为过滤器允许的垃圾邮件，您可能希望从中学习。

但这种方法引入了采样偏差。如果在服务期间将1％的所有流量标记为“保持不变”，则可以收集更干净的数据，并将所有保留的示例发送给用户。现在，您的过滤器阻止了至少74％的反面示例。这些举例可以成为您的训练数据。

请注意，如果您的过滤器阻止95％或更多的负面示例，则此方法变得不太可行。即便如此，如果您希望测量服务性能，您可以制作更加细小的样本（例如0.1％或0.001％）。一万个例子足以准确地估计性能。

 

规则＃35：注意排名问题的固有偏差。

当您彻底切换排名算法以显示不同的结果时，您已经有效地更改了算法将来会看到的数据。这种倾斜会出现，你应该围绕它设计你的模型。有多种不同的方法。这些方法都是支持模型已经看到的数据的方法。

1. 对于涵盖更多查询的功能具有更高的正则化，而不是仅针对一个查询的功能。这样，模型将支持特定于针对所有查询推广的特征的一个或几个查询的特征。这种方法可以帮助防止非常受欢迎的结果泄漏到不相关的查询中。请注意，这与更常规的建议相反，即在具有更多唯一值的特征列上进行更多正则化。
2. 仅允许要素具有正权重。因此，任何好的特征都将比“未知”的特征更好。
3. 没有纯文档功能。这是＃1的极端版本​​。例如，即使给定的应用程序是一个受欢迎的下载，无论查询是什么，您都不希望在任何地方显示它。没有纯文档功能可以保持这么简单。您不希望在任何地方展示特定的热门应用程序的原因与使所有所需应用程序可访问的重要性有关。例如，如果有人搜索“观鸟应用程序”，他们可能会下载“愤怒的小鸟”，但这当然不是他们的意图。显示这样的应用程序可能会提高下载速度，但最终不满足用户的需求。

 

规则＃36：避免使用具有位置特征的反馈循环。

内容的位置显着影响用户与其交互的可能性。如果您将应用程序放在第一个位置，它将更频繁地被点击，您将确信它更有可能被点击。解决此问题的一种方法是添加位置特征，即关于页面中内容位置的特征。你训练你的模型具有位置特征，并且它学会了重量，例如，重度特征“第一位置”。因此，对于“1stposition = true”的示例，您的模型对其他因素的权重较小。然后在服务时你不给任何实例提供位置特征，或者你给它们所有相同的默认特征，因为你在决定显示它们的顺序之前对候选人进行评分。

请注意，由于训练和测试之间的这种不对称性，保持任何位置特征与模型的其他部分有些分离是很重要的。使模型成为位置特征的函数和其余特征的函数的总和是理想的。例如，不要将位置特征与任何文档特征交叉。

 

规则＃37：衡量训练/服务偏差。

在最普遍的意义上，有几件事可能导致歪斜。此外，您可以将其分为几个部分：

• 训练数据的性能与保持数据之间的差异。一般来说，这将永远存在，并不总是坏的。
• 保持数据的性能与“次日”数据之间的差异。同样，这将永远存在。您应该调整正则化以最大化第二天的性能。但是，保留和次日数据之间的性能大幅下降可能表明某些功能对时间敏感，可能会降低模型性能。
• “次日”数据与实时数据的性能差异。如果将模型应用于训练数据中的示例和服务时的相同示例，则应该给出完全相同的结果（参见 规则＃5 ）。因此，这里的差异可能表示工程错误。

 

第三阶段：缓慢增长，优化细化和复杂模型

将有一些迹象表明第二阶段即将结束。首先，您的月收益将开始减少。您将开始在指标之间进行权衡：您会看到一些上升，而其他一些实验则会下降。这是它变得有趣的地方。由于增益难以实现，机器学习必须变得更加复杂。需要注意的是：此部分比之前的部分有更多的蓝天规则。我们已经看到许多团队经历了第一阶段和第二阶段机器学习的快乐时光。一旦达到第三阶段，团队必须找到自己的路径。

 

规则＃38：如果未对齐的目标成为问题，不要在新功能上浪费时间。

随着您的测量平台，您的团队将开始研究当前机器学习系统目标范围之外的问题。如前所述，如果现有算法目标未涵盖产品目标，则需要更改目标或产品目标。例如，您可以优化点击次数，加1次或下载次数，但可以部分根据人类评估者制定发布决策。

 

规则＃39：启动决策是长期产品目标的代理。

Alice有一个关于减少预测安装的后勤损失的想法。她添加了一个功能。物流损失下降。当她进行实时实验时，她会看到安装率增加。但是，当她参加发布审核会议时，有人指出每日活跃用户数下降了5％。该团队决定不启动该模型。Alice很失望，但现在意识到启动决策取决于多个标准，其中只有一些可以使用ML直接优化。

事实是现实世界不是龙与地下城：没有“生命点”来识别你产品的健康状况。团队必须使用它收集的统计数据来试图有效地预测未来系统的好坏程度。他们需要关心参与度，1天活跃用户（DAU），30 DAU，收入和广告客户的投资回报率。这些在A / B测试中可测量的指标本身只是更长期目标的代表：满足用户，增加用户，满足合作伙伴和利润，即使这样，您也可以考虑使用代理来获得有用的高质量产品和五年后蓬勃发展的公司。

唯一容易的启动决策是所有指标都变得更好（或者至少不会变得更糟）。如果团队可以在复杂的机器学习算法和简单的启发式算法之间做出选择，那么如果简单的启发式算法在所有这些度量标准上做得更好，那么它应该选择启发式算法。此外，没有对所有可能的度量值进行明确排序。具体来说，请考虑以下两种情况：

实验	每日活跃用户	收入/日
一个	百万	400万美元
乙	200万	200万美元

如果当前系统是A，则团队不太可能切换到B.如果当前系统是B，则团队不太可能切换到A.这似乎与理性行为相冲突; 但是，对变化指标的预测可能会或可能不会发生变化，因此这两种变化都存在很大的风险。每个指标都涵盖了团队所关注的一些风险。

此外，没有任何指标可以涵盖团队的最终关注点，“我的产品将在五年之后到底在哪里”？

另一方面，个人倾向于支持他们可以直接优化的一个目标。大多数机器学习工具都喜欢这样的环境。一个工程师敲打新功能可以在这样的环境中获得稳定的发布流。有一种机器学习，多目标学习，它开始解决这个问题。例如，可以制定约束满足问题，该问题在每个度量上具有下限，并优化度量的一些线性组合。然而，即便如此，并非所有指标都很容易被视为机器学习目标：如果单击文档或安装了应用程序，则是因为显示了内容。但要弄清楚用户访问您网站的原因要困难得多。如何预测整个网站未来的成功是 AI完整的：像计算机视觉或自然语言处理一样难。

 

规则＃40：保持合奏简单。

采用原始功能并直接对内容进行排名的统一模型是最容易调试和理解的模型。然而，一组模型（结合其他模型的分数的“模型”）可以更好地工作。为了简单起见，每个模型应该是仅考虑其他模型的输入的集合，或者是具有许多特征的基础模型，而不是两者。如果您的模型位于其他模型的顶部，这些模型是单独训练的，那么组合它们可能会导致不良行为。

使用简单的模型进行集成，仅将“基础”模型的输出作为输入。您还希望在这些集合模型上强制执行属性。例如，基础模型产生的分数的增加不应该降低整体的分数。此外，最好是输入模型在语义上是可解释的（例如，校准的），以便底层模型的更改不会混淆整体模型。此外，强制基础分类器的预测概率的增加不会降低整体的预测概率。

 

规则＃41：当性能稳定时，寻找新的信息来源，而不是改进现有信号。

您添加了一些有关用户的人口统计信息。您已添加了有关文档中单词的一些信息。您已经完成了模板探索，并调整了正则化。您还没有看到在几个季度内您的关键指标提升超过1％。怎么办？

是时候开始为完全不同的功能构建基础架构，例如该用户在过去一天，一周或一年中访问过的文档的历史记录，或来自不同属性的数据。使用 wikidata 实体或公司内部的某些内容（例如Google的 知识图表）。使用深度学习。开始调整您对投资预期回报的期望，并相应地扩展您的工作。与任何工程项目一样，您必须权衡添加新功能的好处和增加复杂性的成本。

 

规则＃42：不要指望多样性，个性化或相关性与您认为的流行度相关。

一组内容中的多样性可能意味着很多事情，内容来源的多样性是最常见的内容之一。个性化意味着每个用户都有自己的结果。相关性意味着特定查询的结果比任何其他查询更适合该查询。因此，所有这三个属性都被定义为与普通属性不同。

问题在于普通人往往很难被击败。

请注意，如果您的系统正在衡量点击次数，花费的时间，手表，+ 1，重新转发等等，那么您正在衡量内容的受欢迎程度。团队有时会尝试学习具有多样性的个人模型。为了个性化，他们添加了允许系统个性化的功能（一些表示用户兴趣的功能）或多样化（指示此文档是否具有与返回的其他文档相同的任何功能的功能，例如作者或内容），并发现那些功能比他们期望的重量更轻（或有时不同的标志）。

这并不意味着多样性，个性化或相关性没有价值。正如之前的规则所​​指出的，您可以进行后处理以增加多样性或相关性。如果您看到长期目标增加，那么除了受欢迎之外，您可以宣布多样性/相关性是有价值的。然后，您可以继续使用后处理，也可以根据多样性或相关性直接修改目标。

 

规则＃43：你的朋友在不同的产品中往往是相同的。你的兴趣往往不是。

Google采用一种模型预测一种产品中连接的紧密程度，并使其在另一种产品上运行良好，从而获得了很大的吸引力。你的朋友就是他们自己。另一方面，我看到有几个团队在产品划分中遇到个性化功能。是的，它似乎应该工作。就目前而言，它似乎并非如此。有时工作的是使用来自一个属性的原始数据来预测另一个属性的行为。此外，请记住，即使知道用户在另一个属性上有历史记录也可以提供帮助。例如，两个产品上的用户活动的存在可以本身是指示性的。

 

相关文档

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

• 机器学习速成课程：应用机器学习的介绍。
• 机器学习： Kevin Murphy的概率方法，用于理解机器学习领域。
• 分析大型复杂数据集的实用建议：一种思考数据集的数据科学方法。
• Ian Goodfellow等人的深度学习，用于学习非线性模型。
• 谷歌关于技术债务的论文 ，有很多一般性建议。
• Tensorflow文档。

机器学习规则：

 

ML工程的最佳实践

Martin Zinkevich

本文档旨在帮助那些掌握机器学习基础知识的人从Google机器学习的最佳实践中获益。它提供了机器学习的风格，类似于Google C ++风格指南和其他流行的实用编程指南。如果您参加了机器学习课程，或者在机器学习模型上构建或工作，那么您就具备了阅读本文档的必要背景知识。

术语

在我们关于有效机器学习的讨论中，将反复提出以下术语：

• 实例：您想要做出预测的事情。例如，实例可能是您要将其分类为“关于猫”或“不关于猫”的网页。
• 标签：预测任务的答案，可以是机器学习系统产生的答案，也可以是训练数据中提供的正确答案。例如，网页的标签可能是“关于猫”。
• 功能：预测任务中使用的实例的属性。例如，网页可能具有“包含单词'cat'”的功能。
• 功能列：一组相关功能，例如用户可能居住的所有可能国家/地区的集合。示例可以在特征列中具有一个或多个特征。“功能列”是特定于Google的术语。功能列在VW系统（在Yahoo / Microsoft中）或字段中称为“名称空间” 。
• 示例：实例（具有其功能）和标签。
• 模型：预测任务的统计表示。您在示例上训练模型，然后使用模型进行预测。
• 指标：您关心的数字。可能会或可能不会直接优化。
• 目标：您的算法尝试优化的指标。
• 管道：围绕机器学习算法的基础设施。包括从前端收集数据，将其放入培训数据文件，培训一个或多个模型，以及将模型导出到生产中。
• 点击率点击广告中链接的网页访问者所占的百分比。

概观

制作出色的产品：

做机器学习就像你是伟大的工程师，而不是像你不是伟大的机器学习专家。

事实上，您将面临的大多数问题都是工程问题。即使拥有优秀的机器学习专家的所有资源，大部分收益来自强大的功能，而不是伟大的机器学习算法。所以，基本方法是：

1. 确保您的管道端到端坚固。
2. 从合理的目标开始。
3. 以简单的方式添加常识功能。
4. 确保您的管道保持稳固。

这种方法可以在很长一段时间内很好地工作。只有在没有更简单的技巧可以让你更远的时候，才能摆脱这种方法。增加复杂性会降低未来的版本。

一旦你用尽了简单的技巧，最先进的机器学习可能确实在你的未来。请参阅 第III阶段 机器学习项目部分。

本文件安排如下：

1. 在第一部分应该帮助您了解的时间是否是正确的建设机器学习系统。
2. 在第二部分是有关部署你的第一个管道。
3. 在第三部分是关于启动和同时增加新的功能，以您的管道，如何评价模型和服务培训歪斜迭代。
4. 最后一部分 是关于到达高原时该 怎么做。
5. 之后，有一份相关工作清单和一个 附录，其中介绍了本文档中常用的系统背景。

机器学习之前

规则＃1：不要害怕在没有机器学习的情况下推出产品。

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

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

规则2：首先，设计和实施指标。

在正式确定机器学习系统的功能之前，请尽可能在当前系统中进行跟踪。这样做的原因如下：

1. 以前更容易获得系统用户的许可。
2. 如果您认为将来可能会关注某些事情，那么现在最好获取历史数据。
3. 如果您在设计系统时考虑到公制工具，将来情况会更好。具体来说，您不希望自己在日志中使用字符串来检测指标！
4. 你会注意到什么变化，什么保持不变。例如，假设您想直接优化为期一天的活跃用户。但是，在您早期操作系统期间，您可能会注意到用户体验的显着变化并未显着改变此度量标准。

Google Plus团队衡量每次阅读的扩展，每次阅读的转发，每次阅读的加号，评论/阅读，每位用户的评论，每位用户的转发等，用于计算服务时间帖子的优点。另外，请注意，您可以将用户分组到存储桶并通过实验汇总统计信息的实验框架非常重要。参见 规则＃12。

通过更加自由地收集指标，您可以更全面地了解您的系统。注意一个问题？添加指标以跟踪它！对上次发布的一些数量变化感到兴奋？添加指标以跟踪它！

规则＃3：选择复杂启发式的机器学习。

一个简单的启发式方法可以让您的产品出门。复杂的启发式方法是不可维护的。一旦掌握了数据并了解了您要完成的任务，请继续学习机器学习。与大多数软件工程任务一样，您将希望不断更新您的方法，无论是启发式还是机器级模型，您都会发现机器学习模型更易于更新和维护（参见 规则＃16）。

ML第一阶段：您的第一条管道

专注于您的第一个管道的系统基础架构。虽然想想你将要做的所有富有想象力的机器学习很有趣，但如果你不首先信任你的管道，就很难弄清楚发生了什么。

规则＃4：保持第一个模型简单并使基础设施正确。

第一个型号为您的产品提供了最大的推动力，因此它不需要花哨。但是，您将遇到比预期更多的基础设施问题。在任何人都可以使用你喜欢的新机器学习系统之前，你必须确定：

• 如何获得学习算法的示例。
• 关于“好”和“坏”对您的系统意味着什么的第一次切入。
• 如何将您的模型集成到您的应用程序中。您可以实时应用模型，也可以离线预先计算模型，并将结果存储在表中。例如，您可能希望对网页进行预分类并将结果存储在表中，但您可能希望实时对聊天消息进行分类。

选择简单的功能可以更轻松地确保：

• 这些功能正确地达到了您的学习算法
• 该模型学习合理的权重。
• 这些功能可以在服务器中正确访问您的模型。

一旦你有一个能够可靠地完成这三件事的系统，你就完成了大部分的工作。您的简单模型为您提供基准度量和基准行为，您可以使用它们来测试更复杂的模型。一些团队的目标是首次推出“中性”：首次发布，明确优先考虑机器学习收益，避免分心。

规则＃5：独立于机器学习测试基础设施。

确保基础结构是可测试的，并且系统的学习部分是封装的，以便您可以测试它周围的所有内容。特别：

1. 测试将数据导入算法。检查是否已填充应填充的要素列。在隐私允许的情况下，手动检查训练算法的输入。如果可能，检查管道中的统计信息与其他地方处理的相同数据的统计信息进行比较。
2. 测试从训练算法中获取模型。确保培训环境中的模型与服务环境中的模型具有相同的分数（请参阅 规则＃37）。

机器学习具有不可预测性的因素，因此请确保您在训练和服务中创建示例的代码测试，并且您可以在服务期间加载和使用固定模型。此外，了解您的数据非常重要：请参阅 大型复杂数据集分析的实用建议。

规则＃6：复制管道时要小心丢弃数据。

我们通常通过复制现有管道（即货物编程 ）来创建管道 ，而旧管道会丢弃新管道所需的数据。例如，谷歌加热管道什么是热点掉旧帖子（因为它试图对新帖子进行排名）。此管道已复制用于Google Plus流，旧帖子仍然有意义，但管道仍在丢失旧帖子。另一种常见模式是仅记录用户看到的数据。因此，如果我们想要模拟用户未看到特定帖子的原因，则此数据是无用的，因为所有负面示例都已被删除。Play中也出现了类似的问题。在Play Apps Home上工作时，创建了一个新的管道，其中还包含Play Games登录页面中的示例，没有任何功能可以消除每个示例来自哪里的歧义。

规则＃7：将启发式转换为功能，或在外部处理它们。

通常机器学习试图解决的问题并不是全新的。现有的系统可用于排名，分类或解决您要解决的任何问题。这意味着有一堆规则和启发式。当使用机器学习进行调整时，这些相同的启发式方法可以为您提供帮助。出于两个原因，您的启发式搜索应该针对他们拥有的任何信息进行挖掘。首先，向机器学习系统的过渡将更加顺畅。其次，通常这些规则包含很多关于你不想丢弃的系统的直觉。有四种方法可以使用现有的启发式方法：

• 使用启发式预处理。如果该功能非常棒，那么这是一个选项。例如，如果在垃圾邮件过滤器中，发件人已被列入黑名单，请不要尝试重新学习“列入黑名单”的含义。阻止消息。这种方法在二进制分类任务中最有意义。
• 创建一个功能。直接从启发式创建特征是很棒的。例如，如果使用启发式方法计算查询结果的相关性分数，则可以将分数包括为要素的值。稍后您可能希望使用机器学习技术来按摩值（例如，将值转换为一组有限的离散值，或将其与其他特征组合），但首先使用启发式生成的原始值。
• 挖掘启发式的原始输入。如果有一个启发式应用程序结合了安装次数，文本中的字符数和星期几，那么请考虑将这些部分分开，并将这些输入分别输入到学习中。适用于合奏的一些技术适用于此处（参见 规则＃40）。
• 修改标签。当您认为启发式捕获标签中当前未包含的信息时，这是一个选项。例如，如果您尝试最大化下载次数，但您也想要高质量的内容，那么解决方案是将标签乘以应用程序收到的平均星数。这里有很多余地。请参阅“您的第一个目标”。

在ML系统中使用启发式时，请注意增加的复杂性。在新的机器学习算法中使用旧的启发式算法可以帮助创建平滑过渡，但考虑是否有更简单的方法来实现相同的效果。

监控

通常，实施良好的警报卫生，例如使警报可操作并具有仪表板页面。

规则＃8：了解系统的新鲜度要求。

如果你有一个一天的模型，性能会降低多少？一周大了？四分之一岁？此信息可帮助您了解监控的优先级。如果您的模型在一天内没有更新，您会失去重要的产品质量，让工程师不断观察它是有意义的。大多数广告投放系统都有每天都要处理的新广告，并且必须每天更新。例如，如果Google Play搜索的ML模型 未更新，则可能会在一个月内产生负面影响。适用于Google Plus的热门游戏的一些型号 在他们的模型中没有帖子标识符，因此他们可以不经常导出这些模型。具有帖子标识符的其他模型更频繁地更新。另请注意，新鲜度可能会随着时间的推移而发生变化，尤其是在模型中添加或删除要素列时。

规则＃9：在导出模型之前检测问题。

许多机器学习系统都有一个阶段，您可以将模型导出到服务中。如果导出的模型存在问题，则它是面向用户的问题。

在导出模型之前进行完整性检查。具体来说，确保模型的性能在保持数据上是合理的。或者，如果您对数据有疑虑，请不要导出模型。许多团队不断部署模型， 在出口前检查ROC曲线（或AUC）下的区域 。有关尚未导出的模型的问题需要电子邮件警报，但面向用户的模型上的问题可能需要页面。因此，最好等待并确保在影响用户之前。

规则＃10：注意无声失败。

对于机器学习系统而言，这是一个比其他类型系统更多的问题。假设正在加入的特定表不再更新。机器学习系统将调整，行为将继续相当好，逐渐衰减。有时你会发现几个月过时的表格，而简单的刷新比那个季度的任何其他发布都提高了性能！由于实现更改，功能的覆盖范围可能会发生变化：例如，90％的示例中可以填充功能列，并且突然降至60％的示例。玩过一次有6个月陈旧的桌子，单独刷新桌子的安装率提高了2％。如果您跟踪数据的统计信息，以及手动检查数据，则可以减少这些类型的故障。

规则＃11：提供功能列所有者和文档。

如果系统很大，并且有许多功能列，请知道谁创建或维护每个功能列。如果您发现了解功能列的人员正在离开，请确保有人拥有该信息。尽管许多功能列都具有描述性名称，但最好有一个更详细的描述功能是什么，它来自何处以及预期如何提供帮助。

你的第一个目标

您有许多指标或关于您关心的系统的测量，但您的机器学习算法通常需要一个目标，即您的算法“尝试”优化的数字。我在此区分目标和指标：指标是系统报告的任何数字，可能重要也可能不重要。另见 规则＃2。

规则＃12：不要过度思考您选择直接优化的目标。

你想赚钱，让你的用户满意，让世界变得更美好。您关注的指标很多，您应该全部测量它们（请参阅规则＃2）。但是，在机器学习过程的早期，您会发现它们都在上升，甚至是那些您没有直接优化的。例如，假设您关心点击次数和在网站上花费的时间。如果优化点击次数，您可能会看到花费的时间增加。

因此，保持简单，并且在您仍然可以轻松增加所有指标时，不要过于平衡不同的指标。不要过分遵守这一规则：不要将您的目标与系统的最终健康状况混淆（参见 规则＃39）。而且，如果您发现自己增加了直接优化的指标，但决定不启动，则可能需要进行一些客观的修订。

规则＃13：为您的第一个目标选择一个简单，可观察和可归因的指标。

通常你不知道真正的目标是什么。你认为你这样做但是当你盯着旧系统和新ML系统的数据和并排分析时，你意识到你想要调整目标。此外，不同的团队成员往往无法就真正的目标达成一致。ML目标应该是易于衡量的东西，并且是“真实”目标的代表。 事实上，通常没有“真正的”目标（见 规则＃39）。因此，训练简单的ML目标，并考虑在顶部设置一个“策略层”，允许您添加额外的逻辑（希望非常简单的逻辑）来进行最终排名。

最简单的建模是直接观察并归因于系统操作的用户行为：

• 这个排名链接被点击了吗？
• 这个排名对象是下载的吗？
• 这个排名对象是转发/回复/通过电子邮件发送的吗？
• 这个排名对象是否被评级？
• 这个被显示的对象被标记为垃圾/色情/冒犯吗？

首先避免建模间接效应：

• 用户第二天访问了吗？
• 用户访问该网站多久了？
• 每日活跃用户是什么？

间接效应可以提供很好的指标，可以在A / B测试期间和发布决策期间使用。

最后，不要试图让机器学会弄清楚：

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

这些都很重要，但也难以衡量。相反，使用代理：如果用户满意，他们将在网站上停留更长时间。如果用户满意，他们明天将再次访问。就健康和公司健康而言，需要人为判断将任何机器学习目标与您销售的产品的性质和您的商业计划联系起来。

规则＃14：从可解释的模型开始，使调试更容易。

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

例如，在线性，逻辑或泊松回归中，存在数据的子集，其中平均预测期望等于平均标签（1-刻度校准，或仅校准）。这是正确的，假设您没有正则化并且您的算法已经收敛，并且它通常是近似真实的。如果每个示例都有1或0的特征，则校准该特征为1的3个示例集。此外，如果每个示例的特征都是1，则校准所有示例的集合。

使用简单模型，处理反馈循环更容易（参见 规则＃36）。通常，我们使用这些概率预测来做出决定：例如，在降低预期值（即点击/下载/等概率）中对帖子进行排名。 但是，请记住，当选择使用哪种模型时，决策比给定模型的数据的可能性更重要（参见 规则＃27）。

规则＃15：在策略层中分离垃圾邮件过滤和质量排名。

质量排名是一门艺术，但垃圾邮件过滤是一场战争。用于确定高质量帖子的信号对于使用您系统的用户来说将变得显而易见，他们会调整帖子以获得这些属性。因此，您的质量排名应该专注于对善意发布的内容进行排名。你不应该高质量排名学习者高举垃圾邮件排名。同样，“racy”内容应与质量排名分开处理。垃圾邮件过滤是一个不同的故事。您必须期望生成的功能将不断变化。通常，您会在系统中添加明显的规则（如果帖子有超过三个垃圾邮件投票，则不会检索它，等等）。任何学过的模型都必须每天更新，如果不是更快的话。内容创建者的声誉将发挥重要作用。

在某种程度上，必须整合这两个系统的输出。请注意，过滤搜索结果中的垃圾邮件可能比过滤电子邮件中的垃圾邮件更具侵略性。假设您没有正则化并且算法已收敛，则这是正确的。一般来说大致是正确的。此外，标准做法是从质量分类器的训练数据中删除垃圾邮件。

ML第二阶段：特色工程

在机器学习系统生命周期的第一阶段，重要的问题是将培训数据导入学习系统，获取任何感兴趣的指标，并创建服务基础架构。在您使用装配有单元和系统测试的端到端工作系统后，第二阶段开始。

在第二阶段，有很多悬而未决的成果。有许多明显的功能可以被引入系统。因此，机器学习的第二阶段涉及尽可能多地引入特征并以直观方式组合它们。在此阶段，所有指标仍应上升。将有很多发布会，现在是吸引大量工程师的好时机，他们可以加入您创建真正令人敬畏的学习系统所需的所有数据。

规则＃16：计划启动和迭代。

不要指望您现在正在使用的模型将是您将要启动的最后一个模型，或者甚至您将停止启动模型。因此，请考虑您在此次发布时添加的复杂性是否会降低未来的发布速度。许多团队多年来每季度或更长时间推出一个模型。推出新车型有三个基本原因：

• 您正在提出新功能。
• 您正在调整正则化并以新方式组合旧功能。
• 你正在调整目标。

无论如何，为模型赋予一点爱情可能会很好：查看示例中的数据可以帮助找到新的信号以及旧的，破碎的信号。因此，在构建模型时，请考虑添加或删除或重新组合功能是多么容易。想想创建管道的新副本并验证其正确性是多么容易。考虑是否可以并行运行两个或三个副本。最后，不要担心35的功能16是否进入此版本的管道。你下个季度会得到它。

规则＃17：从直接观察和报告的特征开始，而不是学习特征。

这可能是一个有争议的问题，但它避免了很多陷阱。首先，让我们描述学习的功能是什么。学习特征是由外部系统（例如无监督的聚类系统）或学习者自身（例如通过因式模型或深度学习）生成的特征。这两个都很有用，但它们可能有很多问题，所以它们不应该在第一个模型中。

如果使用外部系统创建功能，请记住外部系统有自己的目标。外部系统的目标可能只与您当前的目标微弱相关。如果您获取外部系统的快照，则它可能会过时。如果从外部系统更新功能，则含义可能会更改。如果您使用外部系统提供功能，请注意此方法需要非常小心。

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

规则＃18：探索跨上下文概括的内容功能。

通常机器学习系统只是更大图片的一小部分。例如，如果您想象一个帖子可能会在What's Hot中使用，那么很多人会在帖子中显示加号，转发或评论，然后才会显示在热门内容中。如果您向学习者提供这些统计信息，它可以在其优化的上下文中宣传没有数据的新帖子。 YouTube的观看接下来可以使用手表的数量，或共同钟表（一个视频多少次后，另一观看计数来观看）从YouTube的搜索。您还可以使用显式用户评级。最后，如果您有一个用作标签的用户操作，那么在不同的上下文中查看该文档上的操作可能是一个很好的功能。所有这些功能都允许您将新内容带入上下文。请注意，这不是关于个性化：弄清楚是否有人首先喜欢这个上下文中的内容，然后找出更喜欢或更喜欢它的人。

规则＃19：尽可能使用非常具体的功能。

凭借大量数据，学习数百万个简单功能比使用一些复杂功能更简单。正在检索的文档的标识符和规范化的查询不会提供太多的概括，但会将您的排名与头部查询上的标签对齐。因此，不要害怕每个功能适用于您的数据的一小部分的功能组，但总体覆盖率高于90％。您可以使用正则化来消除适用于极少示例的功能。

规则＃20：组合和修改现有功能，以人类可理解的方式创建新功能。

有多种方法可以组合和修改功能。TensorFlow等机器学习系统允许您通过转换预处理数据 。两种最标​​准的方法是“离散化”和“交叉”。

离散化包括获取连续特征并从中创建许多离散特征。考虑一个连续的功能，如年龄。您可以创建一个功能，当年龄小于18时，该功能为1，另一个功能在年龄介于18和35之间时为1，等等。不要过度思考这些直方图的边界：基本分位数会给你带来最大的影响。

十字架组合了两个或更多要素列。TensorFlow的术语中的一个特征列是一组同质特征（例如{male，female}，{US，Canada，Mexico}等等。十字架是一个新功能列，其功能包括{男性，女性}×{美国，加拿大，墨西哥}。此新功能列将包含该功能（男性，加拿大）。如果您正在使用TensorFlow并告诉TensorFlow为您创建此十字架，则此（男性，加拿大）功能将出现在代表男性加拿大人的示例中。请注意，需要大量数据才能学习具有三个，四个或更多基本特征列交叉的模型。

产生非常大的特征列的十字架可能过度拟合。例如，假设您正在进行某种搜索，并且您在查询中有一个包含单词的功能列，并且您有一个功能列，其中包含文档中的单词。您可以将它们与十字架结合起来，但最终会有很多功能（参见规则＃21）。

使用文本时，有两种选择。最苛刻的是点积。最简单形式的点积只是计算查询和文档之间共同的单词数。然后可以将此功能离散化。另一种方法是交叉：因此，当且仅当单词“pony”同时出现在文档和查询中时，我们才会有一个特征，当且仅当单词“the”出现时，才会出现另一个特征。在文档和查询中。

规则＃21：您可以在线性模型中学习的要素权重数量与您拥有的数据量大致成比例。

关于模型的适当复杂程度，有令人着迷的统计学习理论结果，但这个规则基本上只是你需要知道的。我有过一些对话，人们怀疑从千个例子中可以学到什么，或者你需要超过一百万个例子，因为他们陷入某种学习方法。关键是将您的学习扩展到您的数据大小：

1. 如果您正在使用搜索排名系统，并且文档和查询中有数百万个不同的单词，并且您有1000个标记示例，那么您应该在文档和查询功能之间使用点积，TF-IDF和一半 - 打破其他高度人性化的功能。1000个例子，十几个功能。
2. 如果您有一百万个示例，则使用正则化和可能的要素选择与文档和查询要素列相交。这将为您提供数百万个功能，但通过正规化，您将拥有更少的功能。一千万个例子，可能十万个功能。
3. 如果您有数十亿或数千亿个示例，则可以使用特征选择和正则化来跨文档和查询标记的要素列。您将拥有十亿个示例和一千万个功能。统计学习理论很少给出严格的界限，但为起点提供了很好的指导。

最后，使用 规则＃28 来决定使用哪些功能。

规则＃22：清理不再使用的功能。

未使用的功能会产生技术债务。如果您发现自己没有使用某项功能，并且将其与其他功能结合使用无效，请将其从基础架构中删除。您希望保持基础架构清洁，以便尽可能快地尝试最有希望的功能。如有必要，有人可以随时添加您的功能。

在考虑添加或保留哪些功能时，请牢记相关信息。该功能涵盖了多少个示例？例如，如果您有一些个性化功能，但只有8％的用户拥有任何个性化功能，那么它将不会非常有效。

与此同时，一些功能可能超过他们的重量。例如，如果您的功能仅覆盖了1％的数据，但90％的具有该功能的示例都是正面的，那么添加它将是一个很棒的功能。

系统的人体分析

在进入机器学习的第三阶段之前，重点关注任何机器学习课程中没有教授的内容：如何查看现有模型并进行改进。这更像是一门艺术，而不是一门科学，但有几种反模式有助于避免。

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

这可能是团队陷入困境的最简单方法。虽然鱼类食物（使用团队中的原型）和狗食（使用公司内部的原型）有很多好处，但员工应该考虑表现是否正确。虽然不应该使用明显不好的变化，但是任何看起来接近生产的东西都应该进一步测试，要么通过支付外行来回答众包平台上的问题，要么通过真实用户的实时实验。

有两个原因。首先是你太靠近代码了。您可能正在寻找帖子的特定方面，或者您过于情绪化（例如确认偏见）。第二是你的时间太宝贵了。考虑九个工程师参加一小时会议的成本，并考虑在众包平台上购买多少合同人工标签。

如果您确实希望获得用户反馈，请使用用户体验方法。在一个过程的早期创建用户角色（一个描述在Bill Buxton的 草绘用户体验中）并稍后进行可用性测试（一个描述在Steve Krug的“ 不要让我思考”）。用户角色涉及创建假设用户。例如，如果你的团队都是男性，可能有助于设计一个35岁的女性用户角色（完整的用户功能），并查看它产生的结果而不是10到25岁到40岁的结果男性。让实际人员观察他们对您的网站（本地或远程）在可用性测试中的反应也可以让您获得全新的视角。

规则＃24：测量模型之间的增量。

在任何用户查看新模型之前，您可以进行的最简单且有时最有用的测量之一是计算新结果与生产的差异。例如，如果您有排名问题，请在整个系统中对查询样本运行两个模型，并查看结果对称差异的大小（按排名位置加权）。如果差异非常小，那么您可以在不进行实验的情况下判断出几乎没有变化。如果差异非常大，那么您需要确保更改是好的。查看对称差异较大的查询可以帮助您定性地了解更改的内容。但请确保系统稳定。

规则＃25：在选择模型时，实用性能胜过预测能力。

您的模型可能会尝试预测点击率。但是，最后，关键问题是你如何处理这种预测。如果您使用它来对文档进行排名，那么最终排名的质量比预测本身更重要。如果您预测文档是垃圾邮件的可能性，然后对被阻止的内容进行截断，那么通过更多内容允许的精度。大多数时候，这两件事情应该是一致的：当他们不同意时，它可能会获得小幅收益。因此，如果存在一些改进日志丢失但会降低系统性能的更改，请查找其他功能。当这种情况经常发生时，是时候重新审视模型的目标了。

规则＃26：查找测量误差中的模式，并创建新功能。

假设您看到模型“错误”的训练示例。在分类任务中，此错误可能是误报或误报。在排名任务中，错误可以是一对，其中积极排名低于负数。最重要的一点是，这是机器学习系统知道它出错的一个例子，并且如果有机会就想解决。如果为模型提供允许其修复错误的功能，则模型将尝试使用它。

另一方面，如果您尝试基于示例创建功能，系统不会将其视为错误，则将忽略该功能。例如，假设在Play Apps Search中，有人搜索“免费游戏”。假设其中一个顶级结果是一个不太相关的插科打app。因此，您为“gag apps”创建了一项功能。但是，如果您正在最大化安装次数，并且人们在搜索免费游戏时安装了一个插科打app，则“gag apps”功能将无法获得您想要的效果。

一旦您有模型出错的示例，请查找当前功能集之外的趋势。例如，如果系统似乎降低了较长的帖子，则添加帖子长度。不要过于具体地说明您添加的功能。如果你要添加帖子长度，不要试图猜测长度意味着什么，只需添加十几个功能，让模型弄清楚如何处理它们（参见 规则＃21 ）。这是获得你想要的最简单的方法。

规则＃27：尝试量化观察到的不良行为。

您的团队的一些成员将开始对他们不喜欢的系统的属性感到沮丧，这些属性不会被现有的损失功能捕获。在这一点上，他们应该尽一切努力将他们的抱怨变成坚实的数字。例如，如果他们认为在Play Search中显示太多“插科打app”，他们就可以让人类评估者识别插科打app。（在这种情况下，您可以切实使用人工标记的数据，因为相对较小的查询占流量的很大一部分。）如果您的问题是可衡量的，那么您可以开始将它们用作功能，目标或指标。一般规则是“ 先测量，优化第二 ”。

规则＃28：注意相同的短期行为并不意味着相同的长期行为。

想象一下，您有一个新系统，它查看每个doc_id和exact_query，然后为每个查询计算每个文档的点击概率。您会发现它的行为与您当前的系统几乎完全相同，无论是并排还是A / B测试，因此您可以启动它。但是，您注意到没有显示新的应用程序。为什么？好吧，由于您的系统仅根据自己的历史记录显示该查询，因此无法了解应该显示新文档。

了解这样一个系统如何长期运作的唯一方法是让它只训练模型生效时获得的数据。这非常困难。

训练 - 服务歪斜

训练服务偏差是训练期间的表现与服务期间的表现之间的差异。这种倾斜可能是由以下原因引起的：

• 处理培训数据和提供管道数据之间的差异。
• 您在训练和服务之间的数据变化。
• 模型和算法之间的反馈循环。

我们观察到Google的生产机器学习系统存在培训服务偏差，从而对性能产生负面影响。最好的解决方案是明确监控它，以便系统和数据更改不会引起偏差。

规则＃29：确保您像服务一样训练的最佳方法是保存服务时使用的功能集，然后将这些功能传输到日志以在训练时使用它们。

即使你不能为每个例子做到这一点，也要做一小部分，这样你就可以验证服务和培训之间的一致性（参见规则＃37）。在Google上进行此测量的团队有时会对结果感到惊讶。 YouTube主页在服务时切换到日志记录功能，显着提高了质量并降低了代码复杂性，许多团队正在按照我们的说法切换基础架构。

规则＃30：重要性 - 权重采样数据，不要随意丢弃它！

如果您有太多数据，则会尝试获取文件1-12，并忽略文件13-99。这是个错误。虽然可以删除从未向用户显示的数据，但重要性加权最好是其余部分。重要性加权意味着如果您决定以30％的概率对示例X进行采样，则给它一个10/3的权重。通过重要性加权，规则＃14中讨论的所有校准属性 仍然有效。

规则＃31：请注意，如果您在培训和服务时间从表中加入数据，表中的数据可能会更改。

假设您使用包含这些文档功能的表（例如注释或点击次数）加入doc ids。在训练和服务时间之间，表格中的功能可能会发生变化。然后，您的模型对同一文档的预测可能在培训和服务之间有所不同。避免此类问题的最简单方法是在服务时记录功能（请参阅 规则＃32 ）。如果表格只是缓慢变化，您还可以每小时或每天快照表格以获得合理的数据。请注意，这仍然无法完全解决问题。

规则＃32：尽可能在您的培训管道和服务管道之间重用代码。

批处理与在线处理不同。在在线处理中，您必须在到达时处理每个请求（例如，您必须为每个查询单独查找），而在批处理中，您可以组合任务（例如，进行连接）。在服务时，您正在进行在线处理，而培训是批处理任务。但是，您可以执行一些重复使用代码的操作。例如，您可以创建一个特定于您的系统的对象，其中任何查询或联接的结果都可以以非常易读的方式存储，并且可以轻松地测试错误。然后，一旦您收集了所有信息，在服务或培训期间，您就会运行一种通用方法来桥接特定于您的系统的人类可读对象，以及机器学习系统所期望的任何格式。这消除了训练服务倾斜的来源。作为必然结果，尽量不要在训练和服务之间使用两种不同的编程语言。该决定将使您几乎无法共享代码。

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

通常，在您训练模型的数据之后测量模型的性能，因为这更好地反映了您的系统在生产中将执行的操作。如果您在1月5日之前根据数据生成模型，请在1月6日的数据上测试模型。您会期望新数据的性能不会那么好，但它不应该更糟糕。由于可能存在日常效应，您可能无法预测平均点击率或转化率，但曲线下面积（表示给出正面示例的得分高于反面示例的可能性）应该相当接近。

规则＃34：在用于过滤的二进制分类（例如垃圾邮件检测或确定有趣的电子邮件）中，对于非常干净的数据，在性能上做出小的短期牺牲。

在过滤任务中，标记为否定的示例不向用户显示。假设您有一个过滤器可以阻止75％的负面示例。您可能想从显示给用户的实例中提取其他培训数据。例如，如果用户将电子邮件标记为过滤器允许的垃圾邮件，您可能希望从中学习。

但这种方法引入了采样偏差。如果在服务期间将1％的所有流量标记为“保持不变”，则可以收集更干净的数据，并将所有保留的示例发送给用户。现在，您的过滤器阻止了至少74％的反面示例。这些举例可以成为您的训练数据。

请注意，如果您的过滤器阻止95％或更多的负面示例，则此方法变得不太可行。即便如此，如果您希望测量服务性能，您可以制作更加细小的样本（例如0.1％或0.001％）。一万个例子足以准确地估计性能。

规则＃35：注意排名问题的固有偏差。

当您彻底切换排名算法以显示不同的结果时，您已经有效地更改了算法将来会看到的数据。这种倾斜会出现，你应该围绕它设计你的模型。有多种不同的方法。这些方法都是支持模型已经看到的数据的方法。

1. 对于涵盖更多查询的功能具有更高的正则化，而不是仅针对一个查询的功能。这样，模型将支持特定于针对所有查询推广的特征的一个或几个查询的特征。这种方法可以帮助防止非常受欢迎的结果泄漏到不相关的查询中。请注意，这与更常规的建议相反，即在具有更多唯一值的特征列上进行更多正则化。
2. 仅允许要素具有正权重。因此，任何好的特征都将比“未知”的特征更好。
3. 没有纯文档功能。这是＃1的极端版本​​。例如，即使给定的应用程序是一个受欢迎的下载，无论查询是什么，您都不希望在任何地方显示它。没有纯文档功能可以保持这么简单。您不希望在任何地方展示特定的热门应用程序的原因与使所有所需应用程序可访问的重要性有关。例如，如果有人搜索“观鸟应用程序”，他们可能会下载“愤怒的小鸟”，但这当然不是他们的意图。显示这样的应用程序可能会提高下载速度，但最终不满足用户的需求。

规则＃36：避免使用具有位置特征的反馈循环。

内容的位置显着影响用户与其交互的可能性。如果您将应用程序放在第一个位置，它将更频繁地被点击，您将确信它更有可能被点击。解决此问题的一种方法是添加位置特征，即关于页面中内容位置的特征。你训练你的模型具有位置特征，并且它学会了重量，例如，重度特征“第一位置”。因此，对于“1stposition = true”的示例，您的模型对其他因素的权重较小。然后在服务时你不给任何实例提供位置特征，或者你给它们所有相同的默认特征，因为你在决定显示它们的顺序之前对候选人进行评分。

请注意，由于训练和测试之间的这种不对称性，保持任何位置特征与模型的其他部分有些分离是很重要的。使模型成为位置特征的函数和其余特征的函数的总和是理想的。例如，不要将位置特征与任何文档特征交叉。

规则＃37：衡量训练/服务偏差。

在最普遍的意义上，有几件事可能导致歪斜。此外，您可以将其分为几个部分：

• 训练数据的性能与保持数据之间的差异。一般来说，这将永远存在，并不总是坏的。
• 保持数据的性能与“次日”数据之间的差异。同样，这将永远存在。您应该调整正则化以最大化第二天的性能。但是，保留和次日数据之间的性能大幅下降可能表明某些功能对时间敏感，可能会降低模型性能。
• “次日”数据与实时数据的性能差异。如果将模型应用于训练数据中的示例和服务时的相同示例，则应该给出完全相同的结果（参见 规则＃5 ）。因此，这里的差异可能表示工程错误。

ML第三阶段：缓慢增长，优化细化和复杂模型

将有一些迹象表明第二阶段即将结束。首先，您的月收益将开始减少。您将开始在指标之间进行权衡：您会看到一些上升，而其他一些实验则会下降。这是它变得有趣的地方。由于增益难以实现，机器学习必须变得更加复杂。需要注意的是：此部分比之前的部分有更多的蓝天规则。我们已经看到许多团队经历了第一阶段和第二阶段机器学习的快乐时光。一旦达到第三阶段，团队必须找到自己的路径。

规则＃38：如果未对齐的目标成为问题，不要在新功能上浪费时间。

随着您的测量平台，您的团队将开始研究当前机器学习系统目标范围之外的问题。如前所述，如果现有算法目标未涵盖产品目标，则需要更改目标或产品目标。例如，您可以优化点击次数，加1次或下载次数，但可以部分根据人类评估者制定发布决策。

规则＃39：启动决策是长期产品目标的代理。

Alice有一个关于减少预测安装的后勤损失的想法。她添加了一个功能。物流损失下降。当她进行实时实验时，她会看到安装率增加。但是，当她参加发布审核会议时，有人指出每日活跃用户数下降了5％。该团队决定不启动该模型。Alice很失望，但现在意识到启动决策取决于多个标准，其中只有一些可以使用ML直接优化。

事实是现实世界不是龙与地下城：没有“生命点”来识别你产品的健康状况。团队必须使用它收集的统计数据来试图有效地预测未来系统的好坏程度。他们需要关心参与度，1天活跃用户（DAU），30 DAU，收入和广告客户的投资回报率。这些在A / B测试中可测量的指标本身只是更长期目标的代表：满足用户，增加用户，满足合作伙伴和利润，即使这样，您也可以考虑使用代理来获得有用的高质量产品和五年后蓬勃发展的公司。

唯一容易的启动决策是所有指标都变得更好（或者至少不会变得更糟）。如果团队可以在复杂的机器学习算法和简单的启发式算法之间做出选择，那么如果简单的启发式算法在所有这些度量标准上做得更好，那么它应该选择启发式算法。此外，没有对所有可能的度量值进行明确排序。具体来说，请考虑以下两种情况：

实验	每日活跃用户	收入/日
一个	百万	400万美元
乙	200万	200万美元

如果当前系统是A，则团队不太可能切换到B.如果当前系统是B，则团队不太可能切换到A.这似乎与理性行为相冲突; 但是，对变化指标的预测可能会或可能不会发生变化，因此这两种变化都存在很大的风险。每个指标都涵盖了团队所关注的一些风险。

此外，没有任何指标可以涵盖团队的最终关注点，“我的产品将在五年之后到底在哪里”？

另一方面，个人倾向于支持他们可以直接优化的一个目标。大多数机器学习工具都喜欢这样的环境。一个工程师敲打新功能可以在这样的环境中获得稳定的发布流。有一种机器学习，多目标学习，它开始解决这个问题。例如，可以制定约束满足问题，该问题在每个度量上具有下限，并优化度量的一些线性组合。然而，即便如此，并非所有指标都很容易被视为机器学习目标：如果单击文档或安装了应用程序，则是因为显示了内容。但要弄清楚用户访问您网站的原因要困难得多。如何预测整个网站未来的成功是 AI完整的：像计算机视觉或自然语言处理一样难。

规则＃40：保持合奏简单。

采用原始功能并直接对内容进行排名的统一模型是最容易调试和理解的模型。然而，一组模型（结合其他模型的分数的“模型”）可以更好地工作。为了简单起见，每个模型应该是仅考虑其他模型的输入的集合，或者是具有许多特征的基础模型，而不是两者。如果您的模型位于其他模型的顶部，这些模型是单独训练的，那么组合它们可能会导致不良行为。

使用简单的模型进行集成，仅将“基础”模型的输出作为输入。您还希望在这些集合模型上强制执行属性。例如，基础模型产生的分数的增加不应该降低整体的分数。此外，最好是输入模型在语义上是可解释的（例如，校准的），以便底层模型的更改不会混淆整体模型。此外，强制基础分类器的预测概率的增加不会降低整体的预测概率。

规则＃41：当性能稳定时，寻找新的信息来源，而不是改进现有信号。

您添加了一些有关用户的人口统计信息。您已添加了有关文档中单词的一些信息。您已经完成了模板探索，并调整了正则化。您还没有看到在几个季度内您的关键指标提升超过1％。怎么办？

是时候开始为完全不同的功能构建基础架构，例如该用户在过去一天，一周或一年中访问过的文档的历史记录，或来自不同属性的数据。使用 wikidata 实体或公司内部的某些内容（例如Google的 知识图表）。使用深度学习。开始调整您对投资预期回报的期望，并相应地扩展您的工作。与任何工程项目一样，您必须权衡添加新功能的好处和增加复杂性的成本。

规则＃42：不要指望多样性，个性化或相关性与您认为的流行度相关。

一组内容中的多样性可能意味着很多事情，内容来源的多样性是最常见的内容之一。个性化意味着每个用户都有自己的结果。相关性意味着特定查询的结果比任何其他查询更适合该查询。因此，所有这三个属性都被定义为与普通属性不同。

问题在于普通人往往很难被击败。

请注意，如果您的系统正在衡量点击次数，花费的时间，手表，+ 1，重新转发等等，那么您正在衡量内容的受欢迎程度。团队有时会尝试学习具有多样性的个人模型。为了个性化，他们添加了允许系统个性化的功能（一些表示用户兴趣的功能）或多样化（指示此文档是否具有与返回的其他文档相同的任何功能的功能，例如作者或内容），并发现那些功能比他们期望的重量更轻（或有时不同的标志）。

这并不意味着多样性，个性化或相关性没有价值。正如之前的规则所​​指出的，您可以进行后处理以增加多样性或相关性。如果您看到长期目标增加，那么除了受欢迎之外，您可以宣布多样性/相关性是有价值的。然后，您可以继续使用后处理，也可以根据多样性或相关性直接修改目标。

规则＃43：你的朋友在不同的产品中往往是相同的。你的兴趣往往不是。

Google采用一种模型预测一种产品中连接的紧密程度，并使其在另一种产品上运行良好，从而获得了很大的吸引力。你的朋友就是他们自己。另一方面，我看到有几个团队在产品划分中遇到个性化功能。是的，它似乎应该工作。就目前而言，它似乎并非如此。有时工作的是使用来自一个属性的原始数据来预测另一个属性的行为。此外，请记住，即使知道用户在另一个属性上有历史记录也可以提供帮助。例如，两个产品上的用户活动的存在可以本身是指示性的。

相关工作

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

• 机器学习速成课程：应用机器学习的介绍。
• 机器学习： Kevin Murphy的概率方法，用于理解机器学习领域。
• 分析大型复杂数据集的实用建议：一种思考数据集的数据科学方法。
• Ian Goodfellow等人的深度学习，用于学习非线性模型。
• 谷歌关于技术债务的论文 ，有很多一般性建议。
• 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 Watch Next和YouTube主页团队都使用ML模型对视频推荐进行排名。观看下一个建议在当前正在播放的视频后观看视频，而主页则向浏览主页的用户推荐视频。

Google Play概述

Google Play有许多解决各种问题的模型。Play Search，Play Home Page Personalized Recommendations和'Users Also Installed'应用程序都使用机器学习。

Google Plus概述

Google Plus在各种情况下都使用机器学习：在用户看到的帖子“流”中排名帖子，排名“热门”帖子（现在非常流行的帖子），排名你认识的人等等。

 

原文链接：https://developers.google.com/machine-learning/guides/rules-of-ml/