深度学习在知乎信息流推荐中的应用

转载自：搜索与推荐Wiki

“

推荐系统在我们的生活中扮演者十分重要的角色，无形中改变着我们的生活，使我们的生活变得更加高效，直接。无论是电商购物，音乐娱乐，还是新闻内容，推荐系统都是不可或缺的一部分，下面来领教一下知乎feed流是如何玩转推荐系统的！

”

知乎信息流推荐系统简介

知乎的信息流推荐框架是一个基于多策略融合的多源内容推荐系统，代号“水晶球”。如图所示：

在这个系统中，首页上出现的内容经历过两次排序。第一次是从数十个推荐队列里被“召回”，第二次是在合并后经过深层神经网络（DNN）的“排序”。

“召回”的第一个步骤是，召回模块根据用户的历史行为表现（用户画像、内容标签、内容源信息），确定数十个推荐队列。这数十个推荐队列是含有特定标签的内容池，有些队列里内容性质相似，比如热点新闻队列、视频队列，还有的队列与用户行为紧密相关，比如关注关系队列、搜索关键词队列。比如说，根据用户的关注关系向外扩展更多关注关系，根据用户兴趣召回感兴趣的内容，根据搜索关键词进行相关推荐。

API的数据还会反馈到Feedback&Control的模块里面，应用这些数据进行业务控制的操作，比如我们会记录每个用户看到的内容是什么，大家都知道在Feed信息流推荐有个很重要的应用是去重，推荐内容不能是有重复的，我们会用过滤保证推出来的内容没有重复。用户在一天里面看到哪些内容点击了哪些内容，这些内容都可以为业务提供一定数据支撑。

2016年之前，知乎的Feed流是比较简单的，你关注了什么样的人，这个人产生的各种各样的动态会在你的界面进行时间倒序的排序，和朋友圈的逻辑非常相似。2016年初上线了一个叫EdgeRank的排序系统，第一代Feed流算法在这个系统支持下取得了一定收益，系统维持了一年时间。

 2016年10月份知乎上线了一个基于GBDT的排序系统，对召回的内容进行一个排序。使用GBDT做排序持续了一年时间，引入GBDT后用户的Feed流使用时长的变化，是呈上升的趋势。在使用 GBDT 进行排序的过程中，逐步完善了用户画像和内容分析的系统，在用户特征和内容特征方面做了非常多工作，把用户的实时行为集成到GBDT里面，用户Feed流使用时长得到了激增。

2017年10月开始知乎先后在召回侧和排序侧引入DNN模型，在引入之后的2017年10月份到2018年7月份周期内，知乎的使用时长和阅读量也呈现出快速增长。

 在这之后，又做了一些优化工作，一个是7月份在DNN做的优化，把注意力机制和LSTM模型引入到DNN的模型里面去，一个是尝试强化学习在推荐系统中的应用。经过这么长时间的优化之后知乎的信息流系统已经在知乎整体业务中占了非常大的体量，用户渗透率（即有多少用户会有效来到首页看内容）达到88%，使用时长占比（包括刷知乎的时长以及在知乎中消费内容的时长等）达到76%。

基于深度学习的推荐召回

知乎在2017年上线了基于深度学习的推荐召回1.0版本，左边这张图是第一版上线时候的深度学习召回网络框架，整个系统把用户和用户的特征表示成了网络，它和库里几万条内容做了一个多分类，在上层进行SoftMax。整个网络训练下来可以得到两个成果。首先是一个 User Representation Network，它把用户信息表示成128维的网络，我们用了画像里的所有信息，包括他的兴趣标签、各种各样的用户信息，都会放到模型的输入里面去，这个输入经过四层网络之后得到用户128维的 Embedding 表示。与此同时，使用Faiss作为向量化ANN召回的Backend，用ANN召回的方式从这几个条目里选出他最感兴趣的内容推荐给他，这是整个召回框架的工作过程。

我们在训练集里包含了几万个内容的Embedding，我们首先会在训练中生成一批Embedding，比如今天的数据来自于过去一周内分发量比较高的数据，这些内容数据会生成Embedding，我们先通过这些召回源把这些机制分发出去，还有一批内容是新产生的、未在训练集中包含的内容，这些内容通过其他的渠道分发出去之后，可以得到看到内容用户的Embedding是什么以及点击这些内容用户的Embedding是什么，我们可以利用这份数据把这些新产生内容的Embedding计算出来更新到Embedding库里面去，这个时候就可以拿到每天新产生内容的表示，并且把这些内容推荐出来。

后来我们又对召回框架进行了2.0升级。在1.0版本的召回框架里，“新内容Embedding怎么得到的”这个问题是延迟解决的。用户的表示网络和Embedding召回在效果收益非常明显，协同过滤用户矩阵分解最常用的方法就是ALS，我们拿了一个关键的指标也就是召回从这几万条里挑出的100个结果里准确度有多少，这100个结果里有没有预测到用户下次点击的数据，在这个指标上， DNN 比起ALS来讲提升了10倍的量级，我们希望一个内容产生之后马上算出Embedding放到网络里。

在2.0版本中，我们尝试了三个层面的技术升级：

• 使用了Content的原始特征，一个内容上打了标签，原始数据比如长度有多少，有没有图片，经过三层的网络之后会生成Feed Embedding，可以直接得到Content Embedding，解决新内容的召回机制问题。

• 在用户表示网络这一侧我们也做了优化，这个网络里就是一个最简单的全链接神经网络，我们做优化的时候是在User Representation Network引入FM Pooling层，学习用户高频消费行为的交叉特征，会让Top100的精确度提高8%。

• 用户在Feed流里有，“展示未点击的Skip数据”比线上“展示已点击数据”量级还要高，代表用户对内容并不是真正感兴趣。第一，我们把展示未点击的数据作为特征引入到User Representation Network里面，其中会用到历史搜索和历史阅读数据。第二，我们会把Skip数据作为指导采样的一种方式，训练大规模的标签Embedding时我们往往把正向数据之外的其他数据都当成负向数据使用，所有负向采样的sample都是在剩下的数据中，根据概率的方式或控制采样频率的方式提取。展示了但是跳过 的内容会在采样的时候加大权重，把它成为负例的概率变得更大，让用户的行为来指导采样。

Skip这两个数据为Top100 ACC产生了比较好的效果，从召回数据里来的CTR和整体的阅读量都有比较大的提高。

基于深度学习的CTR预估模型

知乎还在排序侧采用了CTR预估的模型。1.0版本总体结构和基于DNN的召回框架类似，使用两层Relu而不是直接点积作为Embedding的预估网络。这个模型上线一段时间之后，我们刚开始没有进行任何的参数裁剪的操作，收效没有达到我们的预期。后来我们做了一个简单的尝试，按照业务的理解把特征组合成不同的Field，这些Field之间先做连接，用户先分成N个Field，比如，Field1是自己填写的资料，Field2是用户兴趣标签，Field3是历史搜索行为，先经过一个简单的子网络再全连接到上层。这个 trick能够有效的减少特征在初始输入时候的错误交叉，会减轻模型的过拟合，线上应用则达到了非常明显的收益，AUC提升了1%，CTR提升了5.8%。

使用了DNN之后，我们还试用了谷歌出品的Wide & Deep Network，Deep是图上部分，效果没有明显的提升。随后我们做了一个分析判断，发现Wide & Deep Network的 wide 部分，都会在原始特征输入交叉方面做一个比较强的特征工程，否则所有信息在Deep部分已经得到比较好的应用，Wide 部分并没有提供什么额外的输入，也不会拿到特别好的数据表现。

今年我们开始在深度学习的CTR预估模型上尝试更加激进更有意思的优化，也就是2.0版本。其中最早引入的优化还是特征之间的交叉，我们引入FM层作为这些类别之间的Sparse Input之间的交叉，AUC提升了0.2%，CTR提升了1%。引入CNN及LSTM分别作为文本Encoder/Last Action Encoder，单用户使用时长提高50秒。

第三个trick参考了阿里的一篇论文，我们引入Attention机制作为用户Embedding和CandidateEmbedding之间的交叉权重。举个例子，用户点击的十篇文章中，有九篇是关于体育的一篇是关于互联网的，等到下次体育相关内容的分数会比互联网相关内容的分数高得特别离谱，平均之后互联网信息淹没在体育信息里，但互联网内容也是用户喜欢的，权重却很难发挥出来。我们引入Attention机制，把用户的阅读历史跟当前候选集里相关的数据和权重学习之后，收到了良好效果，单用户使用时长增加了40秒左右。

知乎是一个社区化的平台，常常需要平衡很多指标的收益，预估阅读时长、点赞、收藏、分享、创作等行为。为了解决多目标预估中训练和预测效率问题，我们使用了CTR预估模型预训练网络，利用Parameter Hard Sharing，点击和点赞这两层共享之前的权重，会有一个独立的隐藏层model task自己的目标，这样能降低前向/反向传播中的计算量。

我们常常预估到一些非离散的目标，对于非离散目标如阅读时长，很多同行的做法是线性预估的方式预估，你阅读了60秒，我尽量把预测的值逼近。知乎的做法是，把一篇文章的阅读时长做一个Normalize操作。我们观察了一下阅读时长的分布，这个分布与正态分布比较类似。所以我们使用了 z-value 来对阅读市场进行离散化，离散化之后会把阅读时长分为五等——没点击、点击了阅读时长低、点击了阅读时长中等、点击了阅读时长偏高、点击了阅读时长非常高——将连续值预测转化成离散值预测。

在训练过程中，我们也修改了 Softmax 函数，如果预测出的档数和实际用户阅读时长档数差太多，我们加一个比较大的修改函数，让这种样本的 loss 加大。阅读时长这个模型上线之后，对知乎的使用时长和单篇文章的阅读时长都有提升。

推荐系统中的实际问题

模型训练问题 

• 样本组织方面，大家可以看到刚才我们用了很多实时特征，这些实时特征对用户和样本来讲都是不断变化的，最初知乎组织这些样本的时候都是使用从离线库里Join数据的方式做特征的梳理，后来我们发现线上往往会出现特征穿越的状况，你在线下记录的日志毕竟不是实时的，日志都是流失的放到数据库里，处理数据流的过程中也会出现顺序上的错误，所以我们会在线上进行实施打点避免穿越。

• 对于CTR预估的正向样本和负向样本，后者与前者相比存在几倍的量级差异。通常我们会对正负样本进行不同采样率的实验，不同的业务指标下采样率不一样，最终回有一个最佳的采样率。但采样率多少跟数据的分布和业务需要预估的指标特性相关，1比1不一定是最好的采样比例。

• 特征工程方面，我们在实际应用场景里发现对于分布范围比较大的特征，有一万个赞也有几万个赞的，做CTR预估的过程中赞量的影响会变得非常不平均，所以通常会进行特征的归一化和boxing，分成不同的段输入到CTR预估模型里达到比较好的效果。

• 模型评估方面，AUC是基础指标，我们发现AUC是一个特别基础的指标，对于两份离线文件之间的评估确实有比较大的意义，尤其AUC在现在状态下大家都训练到0.7或0.8的水平，上线之后各种数据指标并不一定能提升那么多，我们做了一个DCG Gain收益的指标，它具有更高的参考意义。

 业务问题

• 多样性问题如何解决？大家都知道Feed流里很多时候最精准不一定是用户最想要的，重复太多对于各种线上业务数据的改进也不一定是正向的结果，我们会引入各种框架进行业务导向的调权、打散、隔离和禁闭，一个内容出现几次之后你没有点击，之后都不会推荐相似的内容。

• 如何避免「信息茧房」的产生？以各种行为表现预估的方式去排序和推荐的推荐系统，最后会让用户传递一个信息茧房，推荐列表里翻来覆去就是这么几个内容。我们的解决方案是，采用一个Explore & Exploit机制，针对老用户及兴趣比较均匀的用户，适当减少兴趣探测手段，在探测过程中也会尽量使用Tag之间的关联信息增强探测效率。

在这浮躁的社会沉静，用心记录，用心学习！