2019年算起来已经过去了半年，回想这半年做的事情，因为18年底重新做了新推荐引擎，好像全部在找bug中了，在遇到了一堆的坑之后发现效果依然上不去，记录一些我的思考。
推荐系统越来越变成一个机器学习系统了
这一点不用我说，应该都有这个感觉，最早的推荐就是cf了，通过同一个用户群中点击了某一个物品的可能会点击用户群中其他用户喜欢的物品，或者这个共同被点击的物品集合，点击率其中某一些的可能会喜欢其中的另一部分。
第一代推荐系统靠一个cf就能打天下了，或者在cf中调参数，热度top物品降权，或者在计算中做策略。我当年刚入行的时候也做过这样的事情。
后来大家发现只用用户点击过的召回关联，或者userCf召回只用了一些点击中的物品共现对，没有考虑到用户总体的喜好，那么能不能搞一个描述用户整体喜好的东西，就是所谓的用户画像，通过抽取物品的重要特征，然后利用用户最近的行为去加权计算，得到用户对这些特征的置信度，同时很多公司还会分为短期画像，中期画像，以及长期画像，至于长度的定义要看物料的属性，比如音乐类的可以长一点，半年一年都可以用，新闻资讯类的就可以短一点，比如一个月，因为它讲究一个新，然后可以用画像做召回，也可以用画像做粗排序，相当于是给用户做推荐的时候综合了用户的兴趣点，在一个早期的算法工程师来看，这已经是很完美了。
后来，大家发现用用户画像做粗排还是太粗糙了。可以可以用一个精确的数学模型来优化，而推荐的结果最终是变成一个预测点击率的问题，也就是一个二分类问题，这方便机器学习技术也成熟了，所以大家就在粗排序后面又加了一个精排序，就是模型排序在线估计打分，刚开始是用lr，当然现在也有很多公司依然用lr，lr有很多它的优势。
到这一步就开始想，既然最后模型能得到一个相对精确解（在完美的情况下，特征能够完全描述清楚用户，且模型能够完美拟合就能得到精确解），那我们还做什么召回粗排啊，直接把所有物品给模型，然后模型预估打分把预估score最高的推荐给用户就好了嘛，还那么麻烦做什么召回和粗排。理想很完美，现实很骨感，模型直接对全库所有物料打分一次可能要些时间，这是在线服务不能接受的，尤其是我们为了结果更准备，会搞很多特征，特征维度越大，以为着计算时间更长，所以快和准永远不会成一起走的兄弟。
所以还要好好做召回和粗排，以及模型。
从后往前说吧，如果把它看成一个数学模型的解，越是后面越会得到一个精确解，前面的作用是粗筛出一个解的候选集合，越是前面这个解的集合越大，且解的精确度越低，就是所谓的高召回率和低准确率。而现在推荐系统的一个发展趋势是，前面也是越来越高召回率和高准确率，虽然这看起来很难。
最后层就是模型层了，模型层主要有两种玩法，一种是老式的玩法，用对业务场景的经验去玩特征，然后用简单的模型，比如LR，另一种是直接把所有的模型到一个复杂的模型中，让模型去学习，比如之前的自动组合二阶特征的fm，自动组合多阶特征GBDT然后后面用简单的LR，以及现在的各种深度模型wide-deep,deepfm,deep-cross之类的。都是通过模型的巧妙设计去自动做特征以及学习。而且这种玩法随着深度学习的发展效果上来说已经超过了人工特征LR的模式。
粗排刚开始最简单的ctr排序，count排序，或者用户模型计算物品的相似度top排序之列，后面看精排模型发展的这么风生水起，那么能不能把精排的经验往前挪挪呢，我们知道精排模型的有点是精度（准确性高），缺点是跑的慢，就是在有限的时间能预估打分的物品比较少。那么我们能不能稍微牺牲点精度，达到性能好呢。当然是可以的，比如深度学习的模型压缩技术，就是解决这个问题的，当然简单的模型LR也可以类似的做，就是我们只用特征重要性最高的10个左右特征，训练一个模型，线上效率也很高，也是现在普遍的做法。
推荐系统哪个环节做好收益最大
越来越追求精确解华
特征穿越
自动换到新引擎之后，
客户上报数据
- item session积累不同场景是否应该积累到一起
- 当发生上报数据重复
- 数据上报序列不一致，比如先上报点击后上报展示
- 数据上报延迟
推荐引擎模型打分模块设计思考
对特征序列做到线上线下一致
理财方面的读书分享
