个性化推荐系统的基本结构

个性化推荐系统简介

个性化推荐系统是针对不同的用户进行差异化推荐的系统，目的就是帮助用户过滤掉没有兴趣的信息，为用户提供一个定制感强的信息流。其实早在移动互联网爆发以前，很多网站上就都有自己的个性化推荐系统，但是由于当时的算法，大数据，以及信息量都远不如移动互联网时代，因此大部分个性化推荐还是使用非常传统的策略，有点像是传统行业基于用户画像的营销手段。目前的个性化推荐系统，指的主要是基于机器学习和深度学习算法实现的系统。

传统推荐策略

在移动互联网普及以前，各大公司采用的推荐策略相对简单很多。因为用户的数量和用户的行为数据在体量上都远远小于移动互联网时代，并且最关键的是，那个时期还是一个主编写文章，或者头部网友做UGC的时期，商品上也往往是比较常见的品牌商品居多。所以在当时，个性化推荐往往对用户(user)的画像信息和物品(item)的画像信息进行分析，然后去做user与item的匹配。比如一个用户画像符合购买某个item的人群的统计特征，我们就会认为这个人很可能对这个item感兴趣；或者一个人看了某一篇文章，那么和这个文章有相同tag的其他文章也有可能是该用户该兴趣的文章。

除了比较偏向统计的方式以外，还有一些比较算法类的推荐方式。比如通过关联规则挖掘user之间以及item之间的关联。另一种常见的挖掘user和item之间关联的方式就是通过矩阵分解的思路，这也是比较早期的嵌入(embedding)方式。

当然即使对于个性化推荐系统，非个性化的热门推荐也是必不可少的。只不过在这一点上，各个产品对自家业务的理解和实际需求各不相同，所以热门推荐的类型也是五花八门。

信息过载

当移动互联网普及以后，信息过载的现象愈发严重，传统推荐策略的问题逐渐显露。信息过载指的是一个app掌握了大量的可曝光信息，这些信息的数量远远大于实际需要的曝光量，因此必须要从数据库中选出很小的一部分进行曝光。如果按照传统推荐策略，依靠用户画像去做推荐，那么很多item之间的差异很难被体现出来。随着user-item的矩阵维度的上升，矩阵分解的推荐难度也在变大。因此需要使用各种手段将真正有用的信息从大量数据里快速提取出来。这一阶段的推荐策略迅速向机器学习和深度学习的方式倾斜。

推荐系统基本结构

目前的推荐系统，无论是电商，还是短视频，在设计上都会遵循一个比较基本的框架。大体来说，推荐部分可以看成是先对item做召回(recall)，之后再对召回的结果做一个排序(rank)。这样得到的排序结果，就是最终曝光到用户app上的结果。当然这个结构是最基本的结构，实际上每个产品的推荐系统肯定要比这个复杂的多。简单介绍一个之前参与过的新闻与视频feed流的推荐系统的大致结构：

Kafka

Redis

Spark

Fetch Result

Crawler

Item Databases

User Databases

Raw Data

Behaviour Logs

Recall Layer

Ranking Layer

UI

Recall Result

Request

1. 通过爬虫获取数据，使用Kafka作为消息队列(MQ)将抓取的新闻和视频放入item库中，item库，user库和behaviour库，在推荐系统中一般统称为物料库。物料库中的原始数据是基于事实得到的，未经算法处理过的原始数据，用于后续的算法推荐。
2. 召回层包含多条召回通道，每条通道根据算法或规则需要从物料库中获得相应数据，之后将各自算法或规则的输出结果作为recall result存入数据库作为离线召回候选集。
3. 排序层一般是由一到两个点击率(CTR)预估模型构成的，目的是将recall result中的大量候选item进行排序，从而保证优先曝光高CTR的item。排序层的排序结果将会反映到app的feed流中，通过在app中埋点，我们可以实时得到用户对推荐结果的反馈。比如用户是否点击了某一个曝光的item，用户在观看视频之后是否进行了分享等等。这些数据将会存入Redis作为排序层的线上实时特征，同时也会由Spark进行批量统计，生成每分钟的报表并且更新raw data中的部分数据。

物料库

我们的物料库使用的是Spark+Hive的形式，具体数据库的选取根据业务场景自行定义就好。物料库中的数据一般涵盖user画像信息，item画像信息，以及user behaviour log这三部分。物料库的更新并不一定要做到完全实时的流式处理，只要能满足线上推荐系统的更新要求就行。我之前做的这个推荐系统的物料库的更新可以算是是秒级延迟的微批处理，而Hive中的数据大概每10分钟才更新一次，但是这样的更新水平已经足以满足我们的算法更新需求了。新闻的规则召回以及相关新闻召回是更新频率最高的两个召回通道，也仅仅是在每小时更新一次的水平。

召回层

召回层的本质是过滤掉大量的无用信息，将海量数据过滤成几百条的候选集，从而解决排序算法无法在线遍历所有数据的问题。召回层往往包含多条召回通道，根据业务需要召回通道的逻辑也是五花八门。每一种召回算法最好可以有不同的功能，兼顾推荐系统的利用与探索两个方面。利用是指基于现有数据为用户找到他最感兴趣的相关items，特点是CTR/CVR高，或者用户的观看时间长，打分高等等。这部分推荐结果在很多指标上表现都很好，在召回通道上往往是由item CF等基于用户个人历史行为的算法来实现。探索则是为了避免过分利用导致用户的兴趣点被越推越窄，从而陷入一个局部无法接触更多的可能的情况。我们在为用户推荐时，还要考虑到如何帮助用户探索到他没有浏览过但很可能感兴趣的领域。这部分推荐结果在指标上可能不如利用型推荐结果，但是对推荐生态的整体生态健康贡献更大，比如推荐结果的多样性，用户的长期粘性等等。

召回算法根据不同业务虽然差别较大，但是也有一些比较经典的方向可以参考。

规则召回

规则召回可以说是最经典的推荐方式了，最简单的比如通过用户画像来判断用户最感兴趣的领域，然后将该领域的优质item推荐给该用户，或者很多论坛基于发帖时间和回复，转发，赞，踩的数量做的热榜召回，这些都属于规则召回的范畴。规则召回的一大优势就是不需要进行模型训练，因此在冷启动或者低频item，低活跃用户的推荐场景下表现良好。

Embedding的流行

伴随数据量的上升，将user或者item进行向量化的效果逐渐提升，优势也逐渐显现。使用embedding对user和item进行向量化，之后通过稠密向量得到的user之间或item之间的相互关系往往可以反映出更深层的联系。同时embedding也可以为许多模型提供输入的特征。因此对于大多数推荐系统而言，user和item的embedding几乎都是daily task类型的基础设施。

协同过滤与item CF

协同过滤是基于item共现的情况挖掘出高频组合，从而进行相似item的推荐。这可以算是item CF在早期非常有效的一种方式了。后续item CF的发展则是朝embedding方向深入挖掘，比较常见的有基于点击序列数据使用word2vec进行item的embedding，或者通过矩阵分解完成的embedding。

用户聚类和user CF

用户聚类最初也是通过用户画像进行，比如视频app可以为用户在各个分类下的兴趣做一个打分，之后通过这些分数将用户划分成不同的类，也可以将一些指标进行归一化后拼接到一个空间，之后使用k-means等聚类算法。主题模型同样也可以应用到用户聚类上，例如通过LDA算法，基于用户浏览过的items的类型或者tag数据，将用户划分为不同的主题人群。

随着embedding技术的流行，用户聚类也开始朝向量化转变。之前用来做recall的各类SVD算法，因为可以为生成latent vectors，因此在很多时候都是一边用着SVD做recall，一边就把user和item的embedding工作给做了。基于SVD类型的embedding更加全局化，相比于word2vec而言，SVD的做法更像是GloVe，对时序也不敏感。如果将用户的点击行为排序后，使用doc2vec，也可以根据点击序列得到用户之间的相关性。

序列化推荐

RNNs衍生出了很多用于处理序列型数据的神经网络，这类网络面对用户点击序列这种时序型的数据可以给出很多创造性的推荐，是探索型recall算法的典范。常见的有GRU4Rec和BERT4Rec，还有USTC之前发过的一篇BINN。这种序列化推荐如果效果能够做好的话，是可以兼顾探索和利用的。有的时候你觉得上午想了一下自己想买个什么东西，下午打开一个常用的电商App，或许就被推荐了。这种不直接基于你搜索和浏览记录的推荐效果往往非常好，序列化推荐在这一点上是有很大优势的。

冷启动的召回

冷启动是指一个全新的user或者item出现在一个推荐系统中时，系统需要基于非常有限的数据进行的粗粒度的推荐方式。因此冷启动通道一般分为user cold start和item cold start两种。

排序层

粗排序

精排序

重排序

去博客设置页面，选择一款你喜欢的代码片高亮样式，下面展示同样高亮的 代码片.

// An highlighted block
var foo = 'bar';

指标与评价

常见指标与用户的体验

评价的困难

• 项目
  • 项目
    • 项目

1. 项目1
2. 项目2
3. 项目3

• 计划任务
• 完成任务

创建一个表格

一个简单的表格是这么创建的：

项目	Value
电脑	$1600
手机	$12
导管	$1

设定内容居中、居左、居右

使用:---------:居中
使用:----------居左
使用----------:居右

第一列	第二列	第三列
第一列文本居中	第二列文本居右	第三列文本居左

SmartyPants

SmartyPants将ASCII标点字符转换为“智能”印刷标点HTML实体。例如：

TYPE	ASCII	HTML
Single backticks	'Isn't this fun?'	‘Isn’t this fun?’
Quotes	"Isn't this fun?"	“Isn’t this fun?”
Dashes	-- is en-dash, --- is em-dash	– is en-dash, — is em-dash

创建一个自定义列表

Markdown

Text-to- HTML conversion tool

Authors

John

Luke

如何创建一个注脚

一个具有注脚的文本。¹

注释也是必不可少的

Markdown将文本转换为 HTML。

KaTeX数学公式

您可以使用渲染LaTeX数学表达式 KaTeX:

Gamma公式展示 $\Gamma (n)=(n-1)!\forall n\in \mathbb{N}$ 是通过欧拉积分

$$\Gamma (z)={\int }_0^{\infty }{t}^{z-1}{e}^{-t}dt.$$

你可以找到更多关于的信息 LaTeX 数学表达式here.

新的甘特图功能，丰富你的文章

Mon 06 Mon 13 Mon 20 已完成 进行中 计划一 计划二 现有任务 Adding GANTT diagram functionality to mermaid

• 关于 甘特图 语法，参考 这儿,

UML 图表

可以使用UML图表进行渲染。 Mermaid. 例如下面产生的一个序列图：

张三 李四 王五 你好！李四, 最近怎么样? 你最近怎么样，王五？ 我很好，谢谢! 我很好，谢谢! 李四想了很长时间, 文字太长了 不适合放在一行. 打量着王五... 很好... 王五, 你怎么样? 张三 李四 王五

这将产生一个流程图。:

链接

长方形

圆

圆角长方形

菱形

• 关于 Mermaid 语法，参考 这儿,

FLowchart流程图

我们依旧会支持flowchart的流程图：

Created with Raphaël 2.2.0 开始 我的操作 确认？ 结束 yes no

• 关于 Flowchart流程图 语法，参考 这儿.

导出与导入

导出

如果你想尝试使用此编辑器, 你可以在此篇文章任意编辑。当你完成了一篇文章的写作, 在上方工具栏找到 文章导出 ，生成一个.md文件或者.html文件进行本地保存。

导入

如果你想加载一篇你写过的.md文件，在上方工具栏可以选择导入功能进行对应扩展名的文件导入，
继续你的创作。

---

1. 注脚的解释 ↩︎