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