内容简介:本文由机器之心经授权最近校招面试到吐,算法岗位有点太热了,简直心力憔悴。我们的面试分两个部分,先是做一两道编码题,然后才是考察机器学习的知识。很多同学不理解,在网上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硬件工程师的思维对比,说中你了吗?
- 数据科学家、机器学习工程师与普通的软件工程师有什么不同
- 普通工程师简史
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
Hive编程指南
卡普廖洛 (Edward Capriolo)、万普勒 (Dean Wampler)、卢森格林 (Jason Rutherglen) / 曹坤 / 人民邮电出版社 / 2013-12-1 / 69
市场中第一本Hive图书。 Hive在Hadoop系统中的应用趋势比较可观。一起来看看 《Hive编程指南》 这本书的介绍吧!