11月8-9日，由中国 IT 社区 CSDN 与硅谷 AI 社区 AICamp 联合出品的 2018 AI 开发者大会（AI NEXTCon）在北京举行，就人工智能的最新技术及深度实践，进行了全方位的解读及论证。本文是机器学习技术专题中知乎首页业务总监、首页推荐技术负责人张瑞的演讲实录。

信息爆炸时代，信息过载已经成为互联网核心问题之一，而通过 AI、机器学习等技术过滤低质无用信息，推动有价值信息的生产和迭代，被视为一种有效解决方案。以知乎为例，这家知识内容平台很早就开始着手机器学习的开发实践，并于 2016 年正式组建机器学习团队，利用站内丰富的中文语料库训练AI算法，推动有价值信息更高效触达用户，为内容产业提供了很好的技术借鉴。日前，在 2018 AI 开发者大会上，知乎首页业务总监张瑞就机器学习在知乎首页中的应用做了技术分享。以下是分享内容摘要。

一、知乎信息流推荐框架

知乎的信息流推荐框架是一个基于多策略融合的多源内容推荐系统，代号“水晶球”。如图所示，在这个系统中，首页上出现的内容经历过两次排序。第一次是从数十个推荐队列里被“召回”，第二次是在合并后经过深层神经网络（DNN）的“排序”。

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

水晶球系统架构

“召回”过程的第二个步骤是，各召回源根据用户的需求分别将自己的队列中的内容做排序后，按召回数量返回内容。我们会从内容类型、内容质量、召回技术三个维度对内容分类，召回源的数据经过汇聚之后会进行融合，最后，DNN 可以在 20ms 内对这些数据完成打分和排序过程，决定推送给用户的内容。
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%。

三、Feed 流推荐系统中的 AI 应用

1. 基于深度学习的推荐召回模型

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

基于深度学习的推荐召回-1.0版本

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

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

基于深度学习的推荐召回-2.0版本

在 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 和整体的阅读量都有比较大的提高。

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

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

基于深度学习的 CTR 预估模型 - 1.0 版本

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

基于深度学习的 CTR 预估模型 - 2.0 版本

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

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

基于深度学习的 CTR 预估模型-多目标预估

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

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

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

四、Feed 流推荐系统中遇到的实际问题

模型训练问题

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

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

特征工程方面，我们在实际应用场景里发现对于分布范围比较大的特征，有一万个赞也有几万个赞的，做 CTR 预估的过程中赞量的影响会变得非常不平均，所以通常会进行特征的归一化和 boxing，分成不同的段输入到 CTR 预估模型里达到比较好的效果。
模型评估方面，AUC 是基础指标，我们发现 AUC 是一个特别基础的指标，对于两份离线文件之间的评估确实有比较大的意义，尤其 AUC 在现在状态下大家都能训练到 0.7 到 0.8 的水平，上线之后各种数据指标并不一定能提升那么多，我们做了一个 DCG Gain 收益的指标，它具有更高的参考意义。

业务问题

多样性问题如何解决？大家都知道 Feed 流里很多时候最精准不一定是用户最想要的，重复太多对于各种线上业务数据的改进也不一定是正向的结果，我们会引入各种框架进行业务导向的调权、打散、隔离和禁闭，一个内容出现几次之后你没有点击，之后都不会推荐相似的内容。
如何避免「信息茧房」的产生？以各种行为表现预估的方式去排序和推荐的推荐系统，最后会让用户传递一个信息茧房，推荐列表里翻来覆去就是这么几个内容。我们的解决方案是，采用一个 Explore & Exploit 机制，针对老用户及兴趣比较均匀的用户，适当减少兴趣探测力度，在探测过程中也会尽量使用 Tag 之间的关联信息增强探测效率。

创作场景

知乎如何洞察你的真实喜好？首页信息流技术揭秘