论算法工程师首先是个工程师之深度学习在排序应用踩坑总结

栏目: 数据库 · 发布时间: 4年前

内容简介:本文由机器之心经授权最近校招面试到吐,算法岗位有点太热了,简直心力憔悴。我们的面试分两个部分,先是做一两道编码题,然后才是考察机器学习的知识。很多同学不理解,在网上diss我们,说什么机器学习基本没有问。这种情况,一般是代码做的太烂了,面试官都没有兴趣去了解机器学习部分。机器学习算法岗位,很容易让大家有个误解,认为平时工作就是推推公式,调调参数。鉴于此,本文借用下我们团队最近的一个重要项目:深度学习在搜索、推荐中的应用,来描述下平时我们是怎么干活的,看完之后,大家应该很容易理解为何我们要求有编码能力。

本文由机器之心经授权 转载自知乎用户吴海波 ,未经授权禁止二次转载。

引子

最近校招面试到吐,算法岗位有点太热了,简直心力憔悴。我们的面试分两个部分,先是做一两道编码题,然后才是考察机器学习的知识。很多同学不理解,在网上diss我们,说什么机器学习基本没有问。这种情况,一般是代码做的太烂了,面试官都没有兴趣去了解机器学习部分。

机器学习算法岗位,很容易让大家有个误解,认为平时工作就是推推公式,调调参数。鉴于此,本文借用下我们团队最近的一个重要项目:深度学习在搜索、推荐中的应用,来描述下平时我们是怎么干活的,看完之后,大家应该很容易理解为何我们要求有编码能力。

其实,我们的编码题真的很简单,不用刷题也能做出来,看看其他公司出的题,已经有点类似面试造原子弹,进来卖茶叶蛋的蜜汁感觉。当然,他们有资本,可以通过这种方式选到很聪明的候选人。

回到正题,我们从去年年底开始探索深度学习在搜索、推荐中的应用,包括 排序 和召回。以前我们常常用和工程同学合作,对系统的理解,比如推荐引擎、搜索引擎来表达编码能力的重要性,可能对于应届生来讲,有点模糊。这次的项目经历可能更好一些。

先总结下指导思想

这大半年,我们踩了很多坑,特别是痴迷论文中的各种fancy结构,寄希望于换换模型拿到收益。最终都纷纷被打脸,反而是回归到开始,从使用更多的样本数据,改善样本清洗、构造的逻辑,谨慎选择经典的模型结构,对优化算法保持敬畏等等,拿到了不错的收益。先来几点务虚的鸡汤,大概有以下几点:

  1. 对比传统模型,深度学习更需要大量的数据去学习,样本数据的增加能明显的改善模型的结果。
  2. 在初期,请忘记paper里面各式各样的奇技淫巧。一套有效的方案,其效果是多和少的问题,不是有和无的问题。好好调参,比乱试各种论文idea有效。
  3. 深度学习真的可以自称调参炼丹师,所以比别人试的更快,是炼丹师的核心竞争力。
  4. Embedding太神奇,请把主要精力花在这里,深度模型对id的理解可以震惊到你。
  5. 关心你的模型的计算效率,最终还是要上线的,绕不过去的性能问题。
    训练中的工程能力篇,就是各种踩坑各种填坑

样本规模的问题

一开始,我们把现有基线的特征数据喂到了深度模型中,试过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,上面这些都是工程没有做好啊,工程好了不需要关心。但是,真正的突破必然是打破现有的体系,需要你冲锋陷阵的时候自己不能上,别人凭什么听你的,跟你干。大概率就是在后面维护点边缘业务了。

难道机器学习理论不重要吗

当然不是,这篇已经写得太长了,只讲两个点。

  1. 信念的来源:这个其实是很重要的,一个项目,搞个一年半载的,中间没有什么明确的产出,老板要kpi,旁边的同事刷刷的出效果,靠什么支持你去坚持继续填坑,只有对理论认知的信念。
  2. 假设总是很美好,现实数据很残酷,左脸打完打右脸,啪啪啪的响。怎么一步步的接近真实,解决问题,靠的还是对理论的理解,特别是结合业务的理论理解。

工程和理论的关系就有点像,理论起到是指路者的作用,而工程是你前进道路上披荆斩棘的利刃。没有理论就没有方向,没有编码能力,就只能当个吃瓜群众,二者缺一不可。

最后,总结下:算法工程师首先是个工程师。

PS:Don’t panic!Make your hands dirty!编码没有那么难。

本文由机器之心经授权 转载自知乎用户吴海波 ,未经授权禁止二次转载。

原文链接: https://zhuanlan.zhihu.com/p/44315278


以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

数据密集型应用系统设计

数据密集型应用系统设计

Martin Kleppmann / 赵军平、李三平、吕云松、耿煜 / 中国电力出版社 / 2018-9-1 / 128

全书分为三大部分: 第一部分,主要讨论有关增强数据密集型应用系统所需的若干基本原则。首先开篇第1章即瞄准目标:可靠性、可扩展性与可维护性,如何认识这些问题以及如何达成目标。第2章我们比较了多种不同的数据模型和查询语言,讨论各自的适用场景。接下来第3章主要针对存储引擎,即数据库是如何安排磁盘结构从而提高检索效率。第4章转向数据编码(序列化)方面,包括常见模式的演化历程。 第二部分,我们将......一起来看看 《数据密集型应用系统设计》 这本书的介绍吧!

JS 压缩/解压工具
JS 压缩/解压工具

在线压缩/解压 JS 代码

JSON 在线解析
JSON 在线解析

在线 JSON 格式化工具

HEX CMYK 转换工具
HEX CMYK 转换工具

HEX CMYK 互转工具