内容简介:本文由机器之心经授权最近校招面试到吐,算法岗位有点太热了,简直心力憔悴。我们的面试分两个部分,先是做一两道编码题,然后才是考察机器学习的知识。很多同学不理解,在网上diss我们,说什么机器学习基本没有问。这种情况,一般是代码做的太烂了,面试官都没有兴趣去了解机器学习部分。机器学习算法岗位,很容易让大家有个误解,认为平时工作就是推推公式,调调参数。鉴于此,本文借用下我们团队最近的一个重要项目:深度学习在搜索、推荐中的应用,来描述下平时我们是怎么干活的,看完之后,大家应该很容易理解为何我们要求有编码能力。
本文由机器之心经授权 转载自知乎用户吴海波 ,未经授权禁止二次转载。
引子
最近校招面试到吐,算法岗位有点太热了,简直心力憔悴。我们的面试分两个部分,先是做一两道编码题,然后才是考察机器学习的知识。很多同学不理解,在网上diss我们,说什么机器学习基本没有问。这种情况,一般是代码做的太烂了,面试官都没有兴趣去了解机器学习部分。
机器学习算法岗位,很容易让大家有个误解,认为平时工作就是推推公式,调调参数。鉴于此,本文借用下我们团队最近的一个重要项目:深度学习在搜索、推荐中的应用,来描述下平时我们是怎么干活的,看完之后,大家应该很容易理解为何我们要求有编码能力。
其实,我们的编码题真的很简单,不用刷题也能做出来,看看其他公司出的题,已经有点类似面试造原子弹,进来卖茶叶蛋的蜜汁感觉。当然,他们有资本,可以通过这种方式选到很聪明的候选人。
回到正题,我们从去年年底开始探索深度学习在搜索、推荐中的应用,包括 排序 和召回。以前我们常常用和工程同学合作,对系统的理解,比如推荐引擎、搜索引擎来表达编码能力的重要性,可能对于应届生来讲,有点模糊。这次的项目经历可能更好一些。
先总结下指导思想
这大半年,我们踩了很多坑,特别是痴迷论文中的各种fancy结构,寄希望于换换模型拿到收益。最终都纷纷被打脸,反而是回归到开始,从使用更多的样本数据,改善样本清洗、构造的逻辑,谨慎选择经典的模型结构,对优化算法保持敬畏等等,拿到了不错的收益。先来几点务虚的鸡汤,大概有以下几点:
- 对比传统模型,深度学习更需要大量的数据去学习,样本数据的增加能明显的改善模型的结果。
- 在初期,请忘记paper里面各式各样的奇技淫巧。一套有效的方案,其效果是多和少的问题,不是有和无的问题。好好调参,比乱试各种论文idea有效。
- 深度学习真的可以自称调参炼丹师,所以比别人试的更快,是炼丹师的核心竞争力。
- Embedding太神奇,请把主要精力花在这里,深度模型对id的理解可以震惊到你。
-
关心你的模型的计算效率,最终还是要上线的,绕不过去的性能问题。
训练中的工程能力篇,就是各种踩坑各种填坑
样本规模的问题
一开始,我们把现有基线的特征数据喂到了深度模型中,试过dnn、dfm、lstm等等,发现效果比lr还差。当时为了快速尝试,将所有的数据load到了内存,限制了数据规模,而且有部分数据预处理的工作也是在 python 中处理,导致计算在cpu和gpu之间频繁切换,gpu利用率抖动很厉害。基于tf提供的性能工具,做了点分析后,判断是特征预处理这部分移太耗时了。另外,模型的参数很大,但是样本数不够,急需增加样本量。我们用spark将样本数据构造成tfrecord的格式,整个构建过程对比原来基于hive sql,再从hdfs拉到本地,快了近10倍,而且能用的样本数据量大了很多,发现模型效果好了很多。
embedding id量级过大的问题
深度学习是在图像、语音等场景起家,经常在nlp的论文中,将几十万的word做embedding称为大规模。工业界做user和item embedding的同学应该笑了。userid和itemid非常容易过百万、千万的量级,导致生成embedding lookup oom。可以参考我上篇文章: https://zhuanlan.zhihu.com/p/39774203 。
有些公司会选择对id进行hash,再做embedding,比如tf的官网就建议这样: https://www.tensorflow.org/guide/feature_columns#hashed_column 。也有些会选择simhash来替换直接hash。我们目前能做百万级别的原始id,后续如果需要加大量级,更倾向于只对样本特别稀疏的id做hash或根据id的metadata做重编码来做。
Wide模型带来的稀疏模型训练问题
大部分的wide & deep代码实现,其实用的tensor都是dense的。tf基于PS做的模型训练,当你的特征规模在亿级别时,网络通信是个灾难,加上grpc的垃圾性能,网卡利用率上不去,训练的时间大部分都耗在通信上了。
但如果花点心思看看tf的源码,解决方法其实很简单,采用一些sparse的op就行。比如用sparse_gather,就能解决网络传输的问题。但这个不是彻底的解决方案,tf在计算的时候又会把sparse的tensor转成dense做。继续看看源码,会发现tf自身实现的embedding_lookup_sparse。换个角度来理解,天然就能支持sparse的wide模型训练。把sparse的wide模型理解成embedding size为1的情况,上层接个pooling做sum,就是我们要的wide的output结果,方案很优雅。
分布式下训练速度不能随着batch size增加变快
这个问题,单纯看性能分析还不好发现。还是去看下TF的代码实现,其实是TF默认有个dimension压缩的优化带来的。TF为了节省存储,会对一个batch内的相同的feature做hash压缩,这里会有个distinct的操作,在batch size大的时候,性能损耗很明显。改下参数,就可以取消该操作,不好的地方是浪费点内存。
还有两个核心问题:TF不支持sparse模型和分布式下work的checkpoint问题,这里不展开了。
线上性能篇:
真实线上场景与batch size的训练的差异
真实排序的时候,一个用户过来,需要精排的候选集可能有几千。而我们在训练的时候,基于batchsize方式组织的predict代码。会将用户侧的feature复制几千次,变成一个矩阵输入到模型中。如果给tf自己做,这里就会有几千次的embedding lookup,非常的耗时。如果我们选择在请求的一开始,就把用户侧的lookup做掉,然后去做点内存复制,就能大大减少rt。
另外一个耗时大头是attention,这个解决方案也很多,比如用查表近似就可以。
还有一些是模型实现的细节不好导致性能很差,比如DCN的cross实现,一个简单的交换律能带来巨大的性能提升,参考: https://zhuanlan.zhihu.com/p/43364598
扯淡开始
上面很多工作,都是算法工程师和工程同学一起深入到代码细节中去扣出来的,特别是算法工程师要给出可能的问题点。做性能profile,工程的同学比我们在行,但是模型中可能的性能问题,我们比他们了解的多。当然也有很多同学diss,上面这些都是工程没有做好啊,工程好了不需要关心。但是,真正的突破必然是打破现有的体系,需要你冲锋陷阵的时候自己不能上,别人凭什么听你的,跟你干。大概率就是在后面维护点边缘业务了。
难道机器学习理论不重要吗
当然不是,这篇已经写得太长了,只讲两个点。
- 信念的来源:这个其实是很重要的,一个项目,搞个一年半载的,中间没有什么明确的产出,老板要kpi,旁边的同事刷刷的出效果,靠什么支持你去坚持继续填坑,只有对理论认知的信念。
- 假设总是很美好,现实数据很残酷,左脸打完打右脸,啪啪啪的响。怎么一步步的接近真实,解决问题,靠的还是对理论的理解,特别是结合业务的理论理解。
工程和理论的关系就有点像,理论起到是指路者的作用,而工程是你前进道路上披荆斩棘的利刃。没有理论就没有方向,没有编码能力,就只能当个吃瓜群众,二者缺一不可。
最后,总结下:算法工程师首先是个工程师。
PS:Don’t panic!Make your hands dirty!编码没有那么难。
本文由机器之心经授权 转载自知乎用户吴海波 ,未经授权禁止二次转载。
以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网
猜你喜欢:- 前端工程师如何成为全栈工程师?
- 从乙方工程师转为甲方工程师的一些思考
- Facebook工程师:从工程角度,系统掌握Python
- 软件工程师VS硬件工程师的思维对比,说中你了吗?
- 数据科学家、机器学习工程师与普通的软件工程师有什么不同
- 普通工程师简史
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
Ordering Disorder
Khoi Vinh / New Riders Press / 2010-12-03 / USD 29.99
The grid has long been an invaluable tool for creating order out of chaos for designers of all kinds—from city planners to architects to typesetters and graphic artists. In recent years, web designers......一起来看看 《Ordering Disorder》 这本书的介绍吧!