阿里项目工作总结(必备5篇)思维导图

Tips:关于平台数据的内容展示，为了方便统计，建议统计数据概览上的数据。如表示平台询盘数/订单数或者信保金额，可以搭配下图表附在PPT上。

在这样的时代，需要以把蛋糕做出来、做大为目的，需要控制好自己的边界和欲望；同其他前端组合作，同其他技术侧合作，同业务侧合作，同运营侧合作，将所有能团结的力量团结在自己身边，做好口碑，有限度的收获自己的那一部分，这样的开发才有出路。

未来，能做出来的轮子一定是复杂的、符合特定业务场景的轮子，包层皮党，捡果子党都将不复存在；而在这一个转换浪潮中，转换的越快越好的人，才能成长和收获。

就简单归纳这几个，不够详细，大家可以自己去深度找资料去学习和评估。

下面截图几个重要内容。

以上截图来自阿里巴巴官方月度发布会截图，一切以官方公告为准。

今天是个变化极快的时代。变局之下，学习是一个人对抗变化最好的竞争力。通过学习，掌握更多前沿的资讯，领悟更多超前的思想，提前布局和驱动自己看未来而努力！

这算是一个老生长谈的话题了，很多时候，我们发现离线 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 模型带来多大的离线收益，如果能够带来比较不错的收益，我们便可以顺着这个路子把文本类特征做的更加完备。

算法工程师其实并不应该仅关注自己手中的事，其实多思考思考产品的形态，也是极好的。虽然这一块，笔者自己的体会并不是特别深，但还是想写出来告诫一下自己别成为一个只懂算法的人。最后，个人对产品和算法的看法是算法的不确定性某种程度上是可以通过产品来进行弥补的。这个观点也是在最近我们大团队内部的某个产品上线后取得了非常好的效果之后逐渐形成的，算是一个抛砖引玉吧。

对于算法工程师而言，保持学习是一项重要的能力，紧跟学界、业界的前沿个人感觉还是比较重要的，另外根据业务的发展，或者手头需要做的事情来有针对性的学一些知识点也是很重要的。最后，关于创新，感觉和学生时期做的论文真的差异很大，学生时代是确定大方向之后，四处开花，哪里好做做哪里，工作之后，受限于业务和数据，这时候还能做论文创新的，不得不说，确实很强。