一年阿里算法工程师的工作总结

责编：顶级算法 | 来源：shane miao
链接：zhuanlan.zhihu.com/p/455943291
上一篇精彩：吴恩达，新冠阳性！

 大家好，我是顶级算法。

看到一篇阿里算法工程师分享的一年工作总结，看完想起来当年的自己，很有借鉴意义，分享给大家~

20年5月到现在入职阿里已经快一年了，一年之中也做了几个项目，期间趟过了不少坑，以往的年度总结都是闭门造车，写完了扔印象笔记之中给自己看，今年学习了很多大佬们的文章，收获很多，尤其是在讨论的过程之中，对自身能力的强化很是受用。于是想晒晒自己一年的收获，欢迎各位大佬交流～
被暴打的现实
5月入职的时候，老板安排的是去做 CTR 模型。当时看到线上模型比自己想的更加简单，于是理所当然的认为把模型升级到学界最新的那种肯定能带来效果上的提升，但是做了很多尝试，最后发现其实并没有那么简单... 于是在被现实狠狠教育了一番之后，终于痛定思痛，开始做一个 SQL 工程师，一切从特征做起，模型配合着特征进行相对应的升级，自己的算法道路才渐渐走上正轨。
一些积累经验
1 .数据的准确性是非常重要的
具体地说，就是我们需要做很多数据清洗的工作。比如在日志中将虚曝光（服务器端打点）除去，只保留真正的实曝光（用户看到的），以及海外业务，还需要将国内的流量进行清洗等等。总之，核心思想就是要保证训练数据是用户真正看到的，且经过在线链路打分的数据。
另外如果没有必要，千万别对当前的数据做采样。首先做了负采样，就已经改变了数据的分布，它的效果就已经不够置信了，其次，采样完成之后还需要还原，尤其是在广告业务中，还原之后还需要再加上校准... 整套流程下来不仅提升了整个链路的复杂程度，拿到的效果还不一定是正向的。
2. 线上线下特征一致性
这算是一个老生长谈的话题了，很多时候，我们发现离线 auc 涨幅喜人，上线之后发现在线指标纹丝不动，甚至还有向下波动的趋势，第一反应就是特征不一致。于是立刻返工去查找线上特征和线下特征是否一致，导致整个项目周期拉的特别长。
笔者今年在这一块就吃了很大的亏。由于我们业务的在线链路中的特征是由 c++、 lua 等语言处理得到的。但是我们离线开发的时候使用的是 python、java以及 SQL 处理得到，导致我们在加新特征的时候往往需要先用 python 和 sql 写一遍离线逻辑，再用 c++、lua 实现同样的在线逻辑。这样的做法首先会导致重复开发，其次两套代码的业务逻辑以及不同语言底层库实现的区别势必会导致在线/离线特征处理的不一致。
为了解决上面的问题，我们使用 C++ 开发了一套特征处理库，我们将所有的特征处理逻辑全部封装进该库之中，只要保证在线、离线输入的数据是一致的，那么得到的特征也可以保证一致。离线情况下，我们则通过 streaming 调 c++ 库的方式来生成离线特征。
3. 线上环境特征的引入
由于我们组的业务场景、流量来源比较复杂，因此笔者刚开始做CTR相关工作的时候，锚定了流量渠道这个一个小点，挖了一部分特征，离线 auc 上也确实拿到了一定的涨幅，但是一上线人就懵了，在线指标跟online模型一模一样。后续跟朋友、师兄的讨论才明白了，渠道特征本质上是环境特征。这一部分特征，让模型可以分辨高 CTR 渠道和低 CTR 渠道，但是对于用户最后会不会点并没有过多的贡献。
4. 离线指标的全面化
CPC 广告场景中，一般情况下，最后的排序计算公式都是 ctr * bid_price， 这就要求在广告场景中，我们不仅仅需要保证预估的序是对的，还需要保证预估的 CTR 的值是准的。当然，其实值如果准了，那么序也应该会更准。但是离线指标中的 auc 仅仅只能验证模型对序的预估情况，并不能实际反应值是否准确。另外，搜索公众号Java后端栈后台回复“私活”，获取一份惊喜礼包。
因此，广告场景下，我们还应该关注类似于 COPC (click over predicted click) 这样的指标，当然 COPC 这个指标也有一定的局限性，比如样本中如果有一半的数据被高估、另一半的数据被低估，那么 COPC 的计算结果很可能表现的还不错。
5. 快速验证想法的能力
同是打工人，大家身上都背着 KPI 和绩效。这时候，我们做的很多事会需要确定性结果，但是，作为算法工程师，我们做的很多事，都不能保证有确定性的结果。这时候，快速验证想法就是很重要的能力，我们需要在简短的 1-2周内验证自己的思路是否能产生效益，然后再决定是否加大投入时间，把这个想法做的更加饱满，全面。
举个简单的例子，比如我们需要挖掘文本类特征对 CTR 模型的重要性，最简单的办法就是去做一些重合特征，比如判断 query 和 item title 的重合度，重合词等等，看这些重合特征能对 CTR 模型带来多大的离线收益，如果能够带来比较不错的收益，我们便可以顺着这个路子把文本类特征做的更加完备。
6. 要有产品思维
算法工程师其实并不应该仅关注自己手中的事，其实多思考思考产品的形态，也是极好的。虽然这一块，笔者自己的体会并不是特别深，但还是想写出来告诫一下自己别成为一个只懂算法的人。最后，个人对产品和算法的看法是算法的不确定性某种程度上是可以通过产品来进行弥补的。这个观点也是在最近我们大团队内部的某个产品上线后取得了非常好的效果之后逐渐形成的，算是一个抛砖引玉吧。
7. 学习和创新
对于算法工程师而言，保持学习是一项重要的能力，紧跟学界、业界的前沿个人感觉还是比较重要的，另外根据业务的发展，或者手头需要做的事情来有针对性的学一些知识点也是很重要的。最后，关于创新，感觉和学生时期做的论文真的差异很大，学生时代是确定大方向之后，四处开花，哪里好做做哪里，工作之后，受限于业务和数据，这时候还能做论文创新的，不得不说，确实很强。
写在最后
聊一些有的没的把，工作是一场长跑，身体的好坏其实是相当重要的。每天抽时间出来锻炼身体，做身材管理，我个人认为是比赚钱多少更重要的事情。另外，作为算法工程师毕竟会面临很多不确定性，如何在失败的情况下，保持一个好的心情也是一个很重要的能力。余以为每个人都应该找到一个适合自己的解压方式，比如我自己在压力大或者心情不佳的时候选择长跑，10km下来，就又是一个元气满满的自己。
排序序列：

1、程序员必知必会的排序一：冒泡排序
2、程序员必知必会的排序二：快速排序
3、程序员必知必会的排序三：直接插入排序
4、程序员必知必会的排序四：希尔排序
5、程序员必知必会的排序五：拓扑排序
6、程序员必知必会的排序六：选择排序
7、程序员必知必会的排序七：归并排序
8、程序员必知必会的排序八：基数排序
9、程序员必知必会的排序九：堆排序

觉得不错？欢迎转发分享给更多人
最近有一些小伙伴，让我帮忙找一些 面试题 资料，于是我翻遍了收藏的 10T 资料后，汇总整理出来，可以说是程序员面试必备！所有资料都整理到网盘了，欢迎下载！
👆扫码回复【面试题】即可获取👆

如何有效地做算法题？
字节跳动面试经验总结，已顺利拿到offer！
一位大佬用了算法刷题宝典，进阿里了！
迷你天猫商城系统（附源码），改改就能接外包换钱！
五大基本算法之分治算法
算法分析的正确姿势
这些书，真tm肝……
CTO 写的代码，真是绝了
策略模式-短信模板业务场景
比冒泡算法还简单的排序算法：看起来满是bug的程序，居然是对的
AES 加密算法的原理详解