[人工智能]推荐系统（一）推荐系统整体概览

推荐系统（一）推荐系统整体概览

前记： 自工作后，（可能？自我认为？）由于工作日的搬砖劳累（虽忙，但受限于个人能力在入职近一年的时间里并未为部门业绩做出可以被认可的贡献，惭愧！），每每周末就在做饭、吃饭、在公司内部度课堂上学习各位前辈高人留下的优秀资料（但我还是很菜，哈哈哈），睡觉、加班（大多数周末）中度过，博客再也没写过。但总觉得多年来断断续续写博客的习惯不能就这么扔了，所以，尽量以后每个周末还是写一篇博客。后面就写一些平时做的推荐系统和计算广告相关的博客。

自1992年，施乐的帕拉奥图研究中心（PARC，PARC有很多创造性的发明，比如打印机，鼠标，操作系统图形界面等）发明了基于协同过滤的推荐系统¹后，后面比较出名的工业界应用就是亚马逊的UCF，Netflix的推荐系统等，进入到深度学习后，推荐系统基本在做电商、资讯、视频的公司里都开启了大规模的应用。在PC互联网时代，主线是 “人找信息”，所以搜索引擎的地位如日中天，进入到移动互联网时代后，大量的信息井喷，由此开启了 “信息找人”。所以推荐和搜索之间的关系，可以简单的理解：推荐是无query的搜索。 这篇博客主要介绍一下推荐系统的整体架构以及一些个人认为挺优秀的资料书籍。

• 1.推荐系统整体架构
  • 1.1 用户画像
  • 1.2 召回
  • 1.3 排序
    • 1.3.1 粗排
    • 1.3.2 精排
    • 1.3.3 混排
• 2.在离线一致性
  • 2.1 特征一致性
  • 2.2 模型一致性
  • 2.3 一致性监控

推荐系统的整体架构可以简单的用下图来描述。简单的描述一下推荐过程：当用户端发送一条请求到推荐系统server端后，整个推荐检索过程也就开始了，首先各路召回会根据请求中携带的用户画像信息候选物料库中筛选出千级别的候选集；送到粗排服务中进行打分排序，通过截断后选取百级别的候选集，然后送到精排服务进行打分排序，精排排序后，最终根据混排服务的要求，选择topN的物料发送到混排服务，参与混排；混排服务则采用一些策略决定最终的展现列表。

下面分开每个环节说一下，推荐系统中几个重要的模块。

一、用户画像
用户画像是整个推荐系统最基础且最关键的模块，服务于整个推荐系统各个环节。因此，用户画像数据的质量直接决定了推荐系统效果的好坏。用户画像主要基于用户的行为日志信息挖掘出用户的长期兴趣、短期兴趣、用户行为统计信息、用户DMP信息、用户负反馈 等等信息。

二、召回
一个推荐系统中的召回模块，通常由几十个召回通道构成，每一个召回通道侧重点各不相同，常见的召回算法有：CF类召回（ICF、UCF）、规则类召回（最新、最热等）、以及各种基于语义向量也就是embedding的召回，比如DSSM双塔召回，图召回（其实就是各种x2vec）。主要是为了降低后面排序环节的候选集大小，通常会把百万级的候选集缩小到千级别的候选集。

二、粗排
粗排的存在完全就是因为精排排序受限于时间复杂度，因为目前的精排模型往往是层数很深的DNN网络，由于线上时间的限制，所能预估排序的规模终究有限，所以才有了粗排这么一个环节。常见的粗排模型有DSSM等。由于粗排是给精排服务的，因此这里还涉及到粗精排目标一致性的问题，常用的做法就是粗精排特征对齐。 近年来，工业界在粗排环节也有很多尝试，比如引入知识蒸馏的思想，把精排-粗排构建一个teacher-student网络，即用精排模型指导粗排模型的训练。

三、精排
目前无论是学术界还是工业界，大部分的精力都集中于精排这个环节。主要有几个方面的因素：1.精排环节是模型层出的环节，学术界以论文为导向，自然把精力都放在了模型上面，不然着实没法水论文啊。2.这一波深度学习浪潮席卷了CV、NLP、推荐，虽然是由于数据、算力和算法三个因素共同助推了深度学习的浪潮，首先数据量自不用说，每年都在以指数的速度在增长，硬件算力优化历来都是小众，很多人没兴趣甚至也没能力去搞。加之工业界的成果如果想共享或者有影响力，最好的方式依然是发论文，而发论文嘛又回到了第一条里。本次推荐系统系列博客也主要集中在精排阶段的常用模型上。
精排阶段的目标就是排出用户可能最喜欢的item列表，本质上就是个ctr预估模型，因此精排模型的演进实际上就是CTR模型的演进历程。下面用一张图来简单的总结下工业界常用的CTR模型的演进历史，能够看出基本都围绕着如何更好的从样本中学出有用的信息，因此特征工程的重要性无与伦比，从统计机器学习时代的LR，进化到embedding+MLP的范式，也都是在围绕着如何学到更加有用的高阶交叉特征信息。在统计机器学习时代，LR在工业界占据统治地位，LR有着诸多的优点：简单可解释性强，易于分布式并行训练。但LR只是个线性模型，没办法学到学到一些高阶交叉信息，因此如果想学到更加细粒度的信息，需要大量的特征工程，既人工做二阶交叉特征，但这样的话，时间复杂度又回飙升，比如$N$个特征，两辆交叉复杂度就到了$O(N^2)$，所以rendle大佬提出了FM模型用于学习二阶交叉特征，Facebook则利用gbdt进行特征组合然后输入到LR里，提出了GBDT+LR的模型。待到深度学习来临后，embedding+MLP的范式成为主流，详细的后面在单独介绍每个模型时再一一详述，这里不再赘述，大家看看下面的图就好（为了这张图特意去下了个xmind，哈哈）。

四、混排
混排，顾名思义，就是多种不同类型的内容混合排序，在信息流推荐中，比如手百的信息流内容类型可能会包括：资讯，视频，小视频，图文，动态等等内容。在用户请求时，为了多样性的考虑，这些内容以列表页的形式展现给用户，那么必然涉及到排序，所以有了混排，最终的目的还是为了提高用户的点击率。此外混排还会涉及到一些策略，比如冷启用户的曝光处理，以及一些强制曝光策略等。

五、在离线一致性
推荐系统中，大多人只关注模型部分，但实际上整个推荐系统是一个庞大的工程（虽然相比较广告是小巫见大巫，等后面有机会写一写关于广告的那些事儿），离线的模型训练只是推荐系统的一个环节，对于有过工业界经验的人来说，最头疼的莫过于如何保证离线一致性了，因此通常负责离线模型的同学和负责在线工程的同学不是同一个，往往还是不同的语言，比如离线python，在线C++，就会导致很多不一致的问题。在离线不一致主要有两部分：1.特征的在离线不一致；2.模型的在离线不一致。
先来说说产生在离线不一致的根源，以特征为例：在离线没有采用统一的框架，比如在线用一套C++抽取框架，离线用一套java抽取框架，还是不同的人实现的，那么必然产生在离线不一致的情况。因此，最好的解决办法，就是在离线采用相同的特征抽取框架。模型也是，离线在线采用相同的代码框架，在百度内部，模型部分在离线采用相同的C++代码编译出来的bin文件，只要参数不配置错误，就能从根源上避免在离线不一致的情况。此外在离线特征一致性的监控也非常重要，能够检测出不一致的特征，及时修复。

参考文献
[1]: http://www.bitsavers.org/pdf/xerox/parc/techReports/CSL-92-10_Using_Collaborative_Filtering_to_Weave_an_Information_Tapestry.pdf
[2]: https://www.csie.ntu.edu.tw/~b97053/paper/Rendle2010FM.pdf
[3]: https://research.fb.com/wp-content/uploads/2016/11/practical-lessons-from-predicting-clicks-on-ads-at-facebook.pdf
[4]: https://www.csie.ntu.edu.tw/~cjlin/papers/ffm.pdf
[5]: https://dl.acm.org/doi/pdf/10.1145/2988450.2988454
[6]: https://arxiv.org/pdf/1703.04247.pdf
[7]: https://dl.acm.org/doi/pdf/10.1145/2959100.2959190
[8]: https://arxiv.org/pdf/1708.05123.pdf
[9]: https://arxiv.org/pdf/1803.05170.pdf
[10]: https://arxiv.org/pdf/1706.06978.pdf
[11]: https://arxiv.org/pdf/2007.03519.pdf