机器学习规则:ML工程最佳实践----rule_of_ml section 3【翻译】

作者:黄永刚


ML Phase III: 缓慢提升、精细优化、复杂模型

第二阶段就已经接近结束了。首先你的月收益开始减少。你开始要在不同的指标之间做出平衡,你会发现有的涨了而有的却降了。事情变得有趣了。获取收益变得更难了,机器学习也已经变得更加复杂了。

警告:这一部分比前面有更多的理论虚的东西。我们见过很多团队在机器学习的一二阶段过得还是很愉快的。一旦进入第三阶段,他们就不得不寻找自己的出路了。

Rule #38: 如果目标没有变化就不要在新特征上浪费时间

随着评价进入平稳期,你的团队开始关注系统目标以外的其他问题。像以前的状态一样,如果已存的算法目标没有覆盖产品的目标,你就要改变你的目标或者产品的目标。例如,你或许优化点击、赞、下载,但是都是基于部分人类评委专家做决策的。

Rule #39: 基于产品长期目标做决策

Alice有个想法可以降低安装预测的逻辑损失。她加了一个特征。逻辑损失也降低了。当她做线上实验时,安装率也上升了。但是,当她做审议会议的时候,有人指出日活跃用户数下降了5%。小组没有上线这个模型。Alice比较失望,但是现在认识到做这个决定是基于很多准则的,而只有一部分是可以使用ML来优化的。

事实是真实世界不是地下城与龙:没有‘血量’表示你产品的健康程度。团队必须收集信息作出统计以尝试高效的预测出系统将来会成为什么样子。他们需要关注约定;日活跃用户数,30日活跃用户数,收益,广告商的投资回报。这些可以在自己系统里面使用A/B测试衡量的指标只是长期目标的一个间接衡量,既要满足用户需求,还要用户量的增长,满足合作方的要求,多赚取收益。

当左右指标都上升(至少不降低)时,最容易做决定了。如果团队要在复杂的机器学习算法和简单的启发式方法中选择,如果简单启发式方法能够在这些指标中做的更好,就应该选择它。而且,对于所有可能的指标之间也没有明确的优先级。考虑下面两个场景:

实验 日活跃用户数 日收益
A 1 百万 $4 百万
B 2 百万 $2 百万

如果当前系统是A,那么团队不可能转向B。如果当前系统是B,那团队不可能转向A。这可能和理性的行为是矛盾的。但是,改变指标后预测能不能成功不好说,因此存在巨大的风险。每一个都存在着风险。而且没有哪个指标可以说是最终的,“我的产品5年后是什么样子呢”?

个人来讲,另一方面倾向于可以直接优化的目标。大多的机器学习工具也倾向于这种情况,工程师也能够提取稳定特征。多目标学习问题从开始就强调这个问题。例如,可以针对每个指标建立一个有有约束的问题,之后将对于多个指标的问题结合起来一起优化。但是,并不是所有指标都是可以形成机器学习的目标函数。如果一个文档被点击了,或者一个APP被安装,是因为它们刚好被展示出来了。而且还很难找到为什么用户会访问你的网站。要对一个网站做整体的预测,这是很难的,就像计算机视觉和自然语言处理一样。

Rule #40: 使用简单模型做集成

使用原始数据并直接将内容进行排序,使用这种方式的模型都容易理解和调试。然而,如果讲这些模型集成起来效果会更好。为了尽可能保持简单,集成模型要么所有的输入是其他模型的输出,要么都是原始特征,最好不要两种都存在。而且要能够对这些基模型一起训练,否则会导致差的结果。

只将基模型的输出作为输入的集成最好使用简单的模型。这样也对集成模型性质有保证了。例如,基模型取得了增长,最起码不能集成之后的结果出现下降的情况。最好就是基模型可以某种意义上的解释,以便于基模型的变化不至于把集成模型搞混乱了。这样可以保证,基础分类器的预测概率增长在集成模型的概率上不会出现下降的情况。

Rule #41: 当性能进入瓶颈期,找其他信息源,而不是捣鼓已经有了的信息

你已经添加了用户人口信息,也添加过了文档的词组信息。也经过了模板摸索(指前面的两部分),也已经对正则化进行调节了。但是依然没有在关键指标上看到多于1%的性能提升。

那是时候采取一些激进的做法,对针对不同的特征采取其它方式。如从不同维度对用户在过去一天一周一年中的使用信息进行统计并形成文档。或者使用深度学习模型。根据投入估计期望,并相应的调整投入的精力。作为一个工程项目,你必须对添加新特征所增加的复杂度和增加的收益之间进行权衡。

Rule #42: 不要期盼多样性、个性化,或者相关性和受欢迎程度相关

追求多样性意味很多东西,需要种类多样的内容来源。个性化意味着每个用户都有各自的结果。关联性意味着对一个特定的查询须有特定恰当的结果。因此这三个属性和普通的共性是不同的。

还要一个问题,这种共性很难被打破。

如果你的系统正在度量点击、滞留时长、播放量、分享量等指标,其实你真正的是在度量内容的流行程度。有的时候,团队尝试学习多样性的个性模型。为了实现个性化,他们添加了一些特征想实现系统能够实现个性化(代表用户兴趣的特征)或者多样性,但最终会发现这些特征所获得的权重远远的低于他们期望得到的。

这不是说多样性,个性化等没有价值。如前面指出的规则一样,你可以做一些后处理来增加多样性等。如果在长期目标指数得到了增长,那你就可以说多样性或者其他相关性是有价值的了。也可以继续使用你的后处理,或基于多样性等相关性来直接修改目标函数。

Rule #43: 其他人对不同的产品倾向相似,但你或许不同于此

google团队已经使用另一个产品的模型在另一个产品上,并取得了较好的结果。你可能就遇到了这么一群小伙伴。另一方面,我见过一些团队试图在独立产品中作出个性化特征。是的,按理讲应该是可行的的,但是现在看来,并不是这样。使用一个属性的原始数据来预测另一个属性的行为,有的时候是可行的。要记住,即使知道一个用户在另一个属相上的历史行为对你来说都是有帮助的。

reference:
- http://feisky.xyz/machine-learning/resources/rules_of_ml.html
- Rules of Machine Learning: Best Practices for ML Engineering

时间: 2024-09-29 03:32:45

机器学习规则:ML工程最佳实践----rule_of_ml section 3【翻译】的相关文章

机器学习规则:ML工程最佳实践----rules_of_ml section 1【翻译】

作者:黄永刚 机器学习规则:ML工程最佳实践 本文旨在指引具有机器学习基础知识的工程师等人,更好的从机器学习的实践中收益.介绍一些应用机器学习需要遵循的规则,类似于Google C++ 风格指南等流行的编程指南.如果你已经上过机器学习相关课程或者正在从事相关的工作,那你已经满足阅读本文所需的背景知识了. Before Machine Learning Rule: #1: 不要害怕开发没有应用机器学习技术的产品 Rule: #2: 设计评价指标并设立优先级 Rule: #3: 先使用复杂的启发式规

机器学习规则:ML工程最佳实践----rules_of_ml section 2【翻译】

作者:黄永刚 ML Phase II: 特征工程 第一阶段介绍了机器学习的一个周期,为学习系统获取训练数据,通过有趣的引导设计指标,创建一个服务框架.在有了一个完整系统之后,就进入了第一阶段. 第二阶段有很多比较容易的东西.任务就是将大量丰富的特征搞进系统中.因此,机器学习的第二阶段就是获取尽可能多的特征并将其有意的组合.第二阶段,所有的指标应该任然在提升.很多东西开始开发,很多工程师将一起花费大量的时间处理数据,以便于你能够创建出非常优秀的学习系统. Rule #16: 不要尝试一次做出完美的

机器学习43条军规:解密谷歌机器学习工程最佳实践(上)

本文译者张相於,首发于微信公号ResysChina(resyschina),「AI早餐汇」经授权转载.以下为注解和编译的内容: 本文是对<Rules of Machine Learning: Best Practices for ML Engineering>一文的翻译+解读.看过我翻译文章的同学知道我翻译文章一般都不太老实,没有那么"忠于原著".本篇对于原文的解读大概有三种形式. 原文翻译.对于作者本身阐述的比较好,而我也没什么可补充的部分,基本会原文翻译. 半翻译半解读

《配置管理最佳实践》——第2章 构建工程 2.1为什么构建工程如此重要

第2章 构建工程 构建工程是高效地把源代码生成二进制文件的学科.构建工程可以很简单,例如仅仅执行一下 Makefile 或者 Ant 脚本:也可以很复杂,比如写一个完整的支持底层技术架构的构建框架.在本章中,我们将会讨论构建工程中遇到的挑战.构建工程的核心技术,以及一些选择合适构建工具的方法.我们也会讨论如何挑选和培养构建工程师.如果公司里现在没有一个合格的构建工程师,建议利用已有的资源去完成现在的工作.配置管理中构建工程是最具挑战性和最有意义的角色. 本章全面介绍了构建工程的方方面面,包括目标

《配置管理最佳实践》——2.10 建立构建过程

2.10 建立构建过程 实施构建工程最佳实践是一项非常具有挑战性的工作.构建工程师可以选择有益于公司的实践:也可以选择最好的工具去建立可重复的构建,实施持续集成.但是实际工作远不止此,构建工程部门还需要为开发团队提供培训和技术支持.我的经验是和研发团队合作,解决构建和部署过程中的问题,然后转到幕后做支持,把日常的工作还交给开发团队来负责.这里有个前提就是公司的合规部门允许这样做.曾经一家实施 SAS-70的公司认为可以接受这样的做法:但是另外一家公司认为这不合规,不能接受.在一些公司里因为合规的

《配置管理最佳实践》——2.13 结论

2.13   结论 构建工程最佳实践可以提高整个开发团队的效率,产出更高质量的代码.构建过程应该自动化,可回溯,快速,并且尽可能地简单.当遇到项目使用的技术十分复杂时,应该把构建分成几个可控制的部分.如果构建过程中可以自我检测错误,开发活动就会更有效.在选择工具时,要谨慎并且考虑构建职能如何更好地融入公司的文化.如果你在构建工程中发现哪些实践是有效的,日常构建中还需要改进什么,希望可以联系我.

《配置管理最佳实践》——2.4 建立构建职能的注意事项

2.4 建立构建职能的注意事项 根据我的经验,在开发团队中实施构建工程最佳实践之前,必须要打消大家的疑虑.有时,对现有构建过程复杂度认识不足,可能会导致人为错误.代码缺陷.不断返工.生产效率低等问题.造成这种现象的大部分原因都是技术上的,另外可能是过程上的.而一旦有问题,就会有人把责任推到构建过程上来,建议简化构建过程.曾经遇到过在某产品中使用的技术特别复杂,而专业技术人员深陷于复杂的技术泥潭之中,并把它弄得更复杂了.显然,我们都希望尽可能地把事情变简单,做到万无一失.但是现实情况是,很多专业技

《配置管理最佳实践》——2.2 从哪里开始

2.2 从哪里开始 首先就是要研究现有项目的构建过程.有时你会发现研发团队已经写好了构建脚本,可能采用的是Ant, Maven 或者Make.通常情况下,现有的构建过程只能部署产品到研发的测试环境中.构建工程师就要在此基础上进行修改,从而支持QA环境和产品环境.现有的构建脚本可能会频繁失败,这个时候就需要研发的支持来予以解决.构建工程师的工作就是确保这些脚本可靠,易维护.有时需要深入理解一个应用程序,才能理解它是怎么构建的.有时候,产品的架构太复杂了,这时候构建工程师就需要和开发工程师合作,一起

《C++编程规范:101条规则、准则与最佳实践》——第2章设计风格设计风格 C++编程规范:101条规则、准则与最佳实践 复杂性啊,愚人对你视而不见,实干家受你所累。 有些人避而远之。惟智者能够善加消除。 ——Alan Perlis 我知道,但是却又忘记了Hoare的至理名言:不成熟的优化是程

第2章设计风格 C++编程规范:101条规则.准则与最佳实践 复杂性啊,愚人对你视而不见,实干家受你所累. 有些人避而远之.惟智者能够善加消除. --Alan Perlis 我知道,但是却又忘记了Hoare的至理名言:不成熟的优化是程序设计中的万恶之源. --Donald Knuth[1] The Errors of TeX[Knuth89] 完全区分设计风格与编码风格是非常困难的.我们将一般在实际编写代码时才用得到的条款留到下一部分介绍. 本部分集中讨论适用面比一个特定的类或者函数更广的原则和