python算法工程师需要会写什么_算法工程师到底在干嘛

本文经原作者授权整理发布

算法工程师到底有什么特别之处？这个岗位真的比普通工程师高一等吗？同为工程师，算法工程师为啥工资高几倍？从普通工程师转为算法工程师，会有多困难？算法真的那么难搞吗？

不知道各位程序员朋友平时有没有想过这些问题，不知道各位是怎么看待这些问题的，如果你心里对算法工程师也有着各种疑惑，你一定不能错过今天的文章，本文的作者从两个角度来解答了这些疑问。

在他看来：算法工程师首先要是个工程师，但是，算法工程师又不只是工程师。

是不是听上去有些绕，但是又仿佛很有道理？先别忙着下结论，看完内容再评论。

上篇：论算法工程师首先是个工程师

引子

最近校招面试到吐，算法岗位有点太热了，简直心力憔悴。我们的面试分两个部分，先是做一两道编码题，然后才是考察机器学习的知识。很多同学不理解，在网上 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。

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，上面这些都是工程没有做好啊，工程好了不需要关心。但是，真正的突破必然是打破现有的体系，需要你冲锋陷阵的时候自己不能上，别人凭什么听你的，跟你干。大概率就是在后面维护点边缘业务了。

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

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