title: “Rules of Machine Learning: Best Practices for ML Engineering”

这是Martin Zinkevich (Google) 在 NIPS 2016 Workshop 分享的谷歌机器学习最佳实践,PDF全文见Rules of Machine Learning: Best Practices for ML Engineering

机器学习产品所要面对的难题是工程问题(而不是ML算法),所以

do machine learning like the great engineer you are, not like the great machine learning expert you aren’t.

术语

  1. 实例( Instance):预测的对象,对应数据集中的特征集合
  2. 标记(Label):预测的先验答案,对应数据集中的目标
  3. 特征(Feature):实例的一个属性,比如网页可能有一个“包含猫”的特征
  4. 特征集 (Feature Column):关联特性的集合(feature column is referred to as a “namespace” in the VW system (at Yahoo/Microsoft))
  5. 模型(Model):模型是对预测任务的统计表示方法(statistical representation of a prediction task),基于样例训练后用来预测
  6. 度量指标(Metric)和目标(Objective):衡量算法的度量以及目标指标
  7. 流水线(Pipeline):围绕机器学习算法的基础设施,包括数据采集、预处理到训练集、模型训练以及模型导出等。

机器学习之前

  • 规则 1:不要害怕发布一款没有用到机器学习的产品
    • 机器学习需要数据,不要直接拿相似课题的数据来用(通常效果很差)
    • 获取数据之前可以用启发式算法(heuristics)发布产品
    • 如果机器学习对产品来说不是必须的,那获取数据前不要用它
  • 规则 2:设计并实施度量指标 (metrics) 来跟踪系统:一开始就设计好metrics有很多好处,比如容易获得用户许可、积累历史数据、预处理容易等,metrics也是系统设计的重要参考
  • 规则 3:使用机器学习而不是复杂启发式算法,机器学习相对启发式算法更容易维护和更新

机器学习第一阶段:第一个工作流(Pipeline)

  • 规则 4:第一个模型要保持简单,设计好基础架构
    • 设计基础架构,确定如何获取数据、如何评估系统好坏以及如何集成到产品中去
    • 简单的特征有助于建立正确可靠的模型
  • 规则 5:确保基础架构和机器学习分开测试
    • 基础架构和机器学习分开可以方便的系统的所有部分,比如数据导入和模型导出等
    • 确保训练环境和生产环境的模型性能一致
  • 规则 6:复制Pipeline时当心遗漏数据
    • 旧的Pipeline可能会依赖某些特定的数据,在复制时要确保它们也一起复制
  • 规则 7:把启发式(heuristics)转变为特征或者从外部处理它们
    • 机器学习与很多启发式问题重合,这些启发式算法有助于帮助机器学习
      • 启发式数据预处理
      • 启发式创建特征
      • 挖掘启发式算法的原始输入并在ML中使用原始输入
      • 修正标记

机器学习第一阶段:监控

  • 规则 8:了解系统的时效性
    • 很多模型具有很强的时效性,需要不停的频繁更新
    • 添加或删除特征时,通常需要更新模型
  • 规则 9:导出模型前发现问题
    • 导出模型前要确保其在训练数据集上获得可靠的性能
    • 导出模型前发现的问题只会影响训练过程,不会影响最重产品的用户
    • 检查ROC(或者AUC)曲线
  • 规则 10:当心未被报告的失败(silent failures)
    • 比如某个特征不再更新时,机器学习系统可能依然会有合理的表现,但会逐步退化
    • 跟踪统计数据,配合偶尔的人工检查,可以减少这类失误
  • 规则 11:文档化每个特征以及其维护者
    • 文档化有助于理解每个特征的作用和由来
    • 记录维护者可以确保每个特征团队里都有人懂得

机器学习第一阶段:第一个目标

  • 规则 12:不要过度考虑优化目标的选择
    • ML初期的metrics可能全部都会有提升,包括那些没有直接优化的目标
    • 保持metrics简单就好
  • 规则 13:选择一个简单、可观察、可归属的指标
    • 很多情况下你不知道真正的目标是什么
    • 一开始选择最容易建模的、直接可观察的指标
  • 规则 14:从可解释的(interpretable)模型开始
    • 比如线性回归、逻辑回归、泊松回归等概率驱动模型比zero­one损失等模型更容易理解
    • 简单模型更容易处理反馈回路
  • 规则 15:用规则层(policy layer)把垃圾信息过滤(Spam Filtering)和质量排序(Quality Ranking)分开
    • 质量排序应该专注有信誉的内容(in good faith)

机器学习第二阶段:特征工程

机器学习第一阶段主要关注三个问题:训练数据导入、确定系统的重点关注指标和保证底层基础设施的稳定可靠。当这三个问题都确认无误,也就已经搭建了一个可靠的机器学习系统,并且系统和每个组成部分都经过了严格测试,这时就可以进入第二阶段了。第二阶段中很多显著的特征被导入系统,将更容易取得成绩,这一阶段的主要任务是导入并以直观的方式组合这些显著的特征。

  • 规则 16:计划模型重建和迭代
    • 不要指望一个模型用到老,最好模型重建和迭代的计划
    • 一般情况下,特征调整(增加新特征,修改旧特征)、正则化规则调整以及指标调整时需要重建模型
  • 规则 17:从直接观察的(而不是经过学习的)特征开始训练
    • 外部系统创建的特征有可能跟本系统的目标不相符
    • 无法评估learned features对因子模型或深度模型非凸问题的影响
    • 从直接观察的特征开始训练可以获得较好的基准性能,进而可以尝试一些高阶的方法
  • 规则 18:提取能跨上下文泛化(generalize across contexts)的内容特征
    • 从不同上下文审视内容可以获取更丰富的特征
    • 不同于个性化,个性化是确定用户在特定上下文环境中的行为
  • 规则 19:尽量选择更具体的特征
    • 使用海量数据学习数百万个简单特征比学习几个复杂特征要简单
    • 即便很多简单特征只能覆盖一小部分数据,总体覆盖率依然可以很高
    • 可以用正则化方法剔除仅适用极少实例的特征
  • 规则 20:以合理的方式组合、修改已有特征
    • 离散化,包括提取连续特征并从中创建离散特征,比如可以对年龄做基于年龄段的分类
    • 交叉法是指将多个特征集(feature column)合并(并集、点乘法、交集等),比如{男性,女性}×{美国,加拿大,墨西哥}。注意交叉法有可能引起过拟合
  • 规则 21:线性模型中学习的特征权重数量与数据量成正比
    • 数据量的大小跟需要训练的特征数是正相关的
  • 规则 21:删除不需要的特征
    • 增删特征时需要仔细排查其覆盖范围以及对应的数据量

机器学习第二阶段:系统的人工分析

介绍几种反面模式(anti­-patterns)。

  • 规则 23: 你并不是典型用户(end user)
    • 开发者和团队成员有可能会引入个人感情色彩引发偏见
    • 考虑user experience methodologies
    • 让用户实测产品
  • 规则 24: 评估模型之间的差异
    • 产品交付之前评估模型与生产版本的差异
    • 确保版本之间symmetric difference尽量小
  • 规则 25: 选择模型时,实用性能比预测能力更重要(utilitarian performance trumps predictive power)
    • 如果某个改进措施导致了性能下降,那就不要采用它
  • 规则 26: 从误差中查找新模式、创建新特征
    • 一旦出现样例错误,应该从特征集寻找解决方案,比如增加新的相关特征
  • 规则 27: 量化观察到的异常行为(quantify observed undesirable behavior)
    • measure first, optimize second
  • 规则 28: 注意短期行为和长期行为的区别
    • 了解系统长期行为的唯一方法是只对当前的模型数据进行训练

机器学习第二阶段:训练服务的偏差(Training­-Serving Skew )

训练服务偏差是指系统训练的性能和服务的性能有偏差,通常有几个原因

  • 训练和服务的数据处理流水线不同
  • 在训练和服务中使用了不同的数据
  • 模型和算法间的反馈回路引起

最好的方法是明确监控这些偏差。

  • 规则 29: 要确保训练和服务一样好,最好的方法是保存服务时的特征以便在训练时使用
    • 即便不能对每个特征都这么做,一小部分也能够验证和训练之间的一致性
  • 规则 30: 对采样数据进行加权(Importance weight)而不是直接丢弃
    • 丢弃数据很有可能会导致严重问题
    • Importance weighting是比丢弃更好的选择
  • 规则 31: 注意数据有可能发生变化
    • 数据发生变化有可能导致服务和训练时的性能不一致
    • 解决方法是保存服务时的特征(规则29)并在训练和服务Pipeline中复用相同代码(规则32)
  • 规则 32: 在训练和服务的Pipeline中尽量复用相同代码
    • 注意服务则是一个在线(online)处理过程,而训练是一个批处理过程,这其中有很多代码可以复用
    • 为了复用代码,最好用相同的编程语言
  • 规则 33: 训练和测试使用不同的数据集
    • 比如用5号的数据训练出来的模型最好用6号之后的数据进行测试
  • 规则 34: 在二元分类过滤场景(如垃圾邮件检测)中,不要为了纯净数据牺牲过大的性能
  • 规则 35: 注意排序问题的固有偏差(inherent skew)
    • 对涵盖更多查询的特征进行更高的正则化(higher regularization)
    • 只允许特征具有正的权重,这样就能保证任何好的特征都会比未知特征更合适
    • 不要选择document­-only features
  • 规则 36: 避免positional features的反馈回路(feedback loops)
    • 内容的位置会显著影响用户与它交户的可能性(置顶App的下载量通常下载量更大)
    • 处理这类问题的有效方法是加入位置特征
    • 注意要保持位置特征和其他特征的分离性
    • 不要交叉(cross)位置特征和文档特征
    • 理想情况下,让模型变成位置特征函数和其他特征函数的和
  • 规则 37: 测量训练/服务偏差(Training/Serving Skew)

机器学习第三阶段:减慢的增速、精细优化和复杂模型(Slowed Growth, Optimization Refinement, and Complex Models )

  • 规则 38:Don’t waste time on new features if unaligned objectives have become the issue
    • if the product goals are not covered by the existing algorithmic objective, you need to change either your objective or your product goals
  • 规则 39:Launch decisions are a proxy for long­term product goals
    • 模型发布决策是长期产品目标(高品质更有价值的产品)的代理
    • metrics之间可能并没有明确的排序
    • 使用multi­objective learning
  • 规则 40:保证集成模型(ensembles)简单
    • 每个模型应该要么是一个只接收其他模型的输入的集成模型,要么是一个有多种特征的基础模型,但不能两者皆是
    • 集成models on top of other models会导致不良的后果
    • 只用简单模型来集成:那些只把基础模型作为输入进行接收的模型
  • 规则 41:When performance plateaus, look for qualitatively new sources of information to add rather than refining existing signals
    • It is time to start building the infrastructure for radically different features
    • 调整投资预期
    • 尝试深度学习
    • 权衡新特征和以此带来的更高的复杂性
  • 规则 42:不要期望多样性、个性化、相关性和受欢迎程度之间有紧密联系
    • 在以受欢迎程度为目标的系统上,多样性和个性化通常得到更低的权重
    • 这并不是说多样性、个性化不重要,而是可以通过后处理来提高或者根据多样性和相关性改进目标
  • 规则 43:Your friends tend to be the same across different products. Your interests tend not to be
    • Teams at Google have gotten a lot of traction from taking a model predicting the closeness of a connection in one product, and having it work well on another. Your friends are who they are. On the other hand, I have watched several teams struggle with personalization features across product divides. Yes, it seems like it should work. For now, it doesn’t seem like it does. What has sometimes worked is using raw data from one property to predict behavior on another. Also, keep in mind that even knowing that a user has a history on another property can help. For instance, the presence of user activity on two products may be indicative in and of itself