导读：微博作为全球领先的中文广场社交平台，拥有海量用户与数据。在从海量数据中挖掘有价值的信息，为业务赋能的过程中，微博的推荐算法经历了数次升级换代，积累了许多经验。今天跟大家分享下，在此过程中我们遇到的问题，并且在长期改进与积累的过程中，微博机器学习平台的演进过程，以及当前架构如何更好的发挥算法的优势，为业务产生更多有价值的支撑。

主要内容包括：

微博简介
相关推荐场景描述
微博推荐算法实践
微博机器学习平台

01 微博简介

财报显示：微博拥有2.4亿日活DAU，5.5亿月活MAU，94%的移动月活占比。

微博利用机器学习相关的的算法策略通过对内容的合理发掘以及用户兴趣的个性化匹配，通过引导海量用户的行为，对优质UGC博主产生正向激励，促进微博优质UGC的生态建设，进而提升用户体验。共同构建积极活跃的微博内容生态。

02 相关推荐场景描述

1. 相关推荐场景

我们今天从微博的相关推荐这个场景入手，深入聊一下微博的机器学习机制。相关推荐的场景如图所示，它的逻辑就是用户在点入正文页之后，根据用户的选择，进行相关内容的推荐，引导用户兴趣收敛。

2. 相关推荐目标

相关推荐有两个目标，第一个目标是个性化满足用户内容消费需求。

在此基础上第二个目标是促进用户兴趣意图收敛，减少用户进一步搜索的行为，提升体验。

03 微博推荐算法实践

我们将从三个方面进行阐述：机器学习流程、样本与特征，以及算法实践。

1. 机器学习流程

item端：用户发博后，分别经过一系列复杂的审核与处理，将数据送入到物料库和数据中台中，作为微博内容池的基础物料。

用户端：用户通过浏览微博产生用户行为，经过ETL后，可以构建成机器学习服务的训练样本。

利用各种算法训练提取到相关信息后，产出模型，上线到模型服务进而通过召回、排序等阶段对用户的行为产生影响。

2. 样本与特征

① 样本策略

首先，我们结合业务经验对数据做了去噪和数据映射。为了更好地评价相关性模型的离线效果，我们构建了一套人工标注的Benchmark数据集，指导模型迭代方向。并作为离线指标评估基准。此外，我们在构建样本时做了一系列的调整工作，有几个典型的操作：例如我们在用户侧做的无效负样本过滤，就是将最近30天不活跃的用户曝光数据过滤掉，一方面削减负样本的数量，一方面也减少了错误的负样本给模型带来的噪声影响。此外，众所周知，在实际业务中，构建样本是dirty work，一致性层面我们花了极大精力来解决相关问题。但同样，我们的尝试也不完全都有效，比如在推荐流场景下效果不错的负例优化，在我们的AB上并没有观测到明显的正向提升。

② 特征选取

特征方面，微博有着非常丰富的特征体系，不过我们的实际使用中只用到了几大类，分别是ID类特征、阅读者特征、发博者特征、上下文特征、环境特征和物料特征。

总的特征选取原则是：减少人工干预，强化模型表现力。在实际模型分析中，也观测到了符合预期的现象。ID类特征效果最明显，线上有超过10%的涨幅，亲密度特征单独上AB，涨幅不明显。但在ID特征参与下，亲密度特征对线上效果有明显正向作用。经模型分析后，发现模型特征交叉得分有明显优势。

3. 算法实践

① 召回

目前相关推荐的主要模型是FM&双塔模型模型：

要注意的地方是对样本的构建并不是常见的feature+label，也就是一个样本对应一个label这种方式。在一个模型中用户的正例样本feature+负例样本的feature拼接成的双塔样本，这样不仅提升了整体可用的样本数量，使得深度模型有机会得到更充分的训练。还相当于对正样本做了上采样，平衡了正负样本比例。

双塔模型中，物料侧参数是共享的，item侧形成embedding和用户侧embedding进行cosine计算，学习目标是最大化正例负例距离，中间加了间隔阈值在里面relu(P(D_pos|Q)-P(D_neg|Q) + margin)。深度方面，我们更深的双塔也试过，但由于召回是非常扁平的结构，效果不变甚至下降。目前常用的是三、四层隐层。

② 模型升级

排序侧的演进过程，我们和业界步调基本一致，从策略系统到统计类推荐，随后到LR的模型排序，发展到FM，以及后来的FFM、Deep&Wide、DeepFM。整体来看，就是先扩大模型规模，再强化模型对特征交叉的捕获，随后是embedding的崛起引导的更高阶特征的使用。

③ 规模提升

为了更强的模型表达能力，我们在更加多样化的特征组合和丰富的场景特征的基础上，大规模引入了ID类特征。从右图可以看到随着模型规模的越来越大，业务效果表现出了明显的正相关。

微博的实践经验表明，一定情况下机器学习的规模越大，效果指标就越好。同时随着模型维度的膨胀，模型训练阶段需要的数据量也在几何级上升。

大规模机器学习，带来可观的业务收益的背后，也带来了极大的挑战。

④ 大规模遇到的问题

模型规模增大也带来了一些问题，比如海量参数和梯度爆炸。

问题1：海量参数

模型太大，存不下、算不动、算的慢。

解决方案：

存不下 。我们通过自研的weips，也就是参数服务器来解决模型存储的问题；如果有不了解的同学，可以简单抽象为一个带自定义操作 ( 我们称之为psfunc ) 的大规模外部KV存储。
算不动 。模型训练方面，我们基于flink实现，同时为了降低存储和计算开销，对算法的求解过程做了稀疏化改造，并且参数改为低精度的类型来降低存储开销。
算的慢 。线上引擎的同学，通过指令集层面的优化，极大提升推理速度，解决了算的慢的问题。

问题2：梯度爆炸

模型不收敛，经排查出现了梯度爆炸，因为参数比较大，里面相加相乘的项比较多，进而导致了梯度爆炸。

解决方案：

首先对激活函数做了定义域的截断，相当于模型输入和输出都是一定在一定范围之内的，从表面上解决了梯度爆炸的情况，但是实质的问题没有解决。
通过优化初始化参数，让初始化的参数极度逼近于0，也就是均值是0，方差极小，来减少梯度爆炸的概率。
我们在优化算法的过程中同样做了梯度的裁剪，裁剪的方式也是设置了阈值的空间，超过阈值区间，我们会抛弃梯度。过小的梯度丢弃可以降低参数同步成本，提升参数同步的速度；过大梯度丢弃可以保证模型的稳定性，防止梯度爆炸，也减少了噪声产生的几率。
此外我们在大规模深度学习实践中也发现了batch_norm，是非常有效的避免梯度爆炸的手段。

⑤ 部署Weiflow

模型训练完了之后会进行线上部署，流程如下图，主要是通过灵活配置来解决依赖和资源相关的问题，解决了人力消耗的问题，新人小白几个小时就可以把流程部署完成，提高了效率。图中是小时级模型训练与上线，经过实际验证，在完全一样的配置下，相比对照组线上指标上涨35BP。

⑥ 在线机器学习

第一版，我们实现了FM这个模型，主要是FM比较简单，支持稀疏化操作，并且FM在离线是比较成熟的模型，各方面的支持也比较完备，模型基础好，工作量小。实现了SGD，FTRL和AdaGrad等多种优化器来保证效率，提高模型的收敛效果。训练是基于Weiflink ( Flink 微博的实时计算框架，基于Flink开发与封装 )，配合阿里云从Yarn迁转到K8s服务器，保证了稳定性。在线深度学习的开发也基本完成正在内测阶段。

在线机器学习系统主要包括如下几个部分，样本生成服务、模型训练服务、参数服务、模型部署服务、模型预估服务、排序服务。

我们认为一个重要的点是在线机器学习需要把用户行为日志进行拼接的，比如用户的阅读行为、点击行为、曝光行为等，Flink本身不支持，微博是通过二次开发进行多流拼接。拼接生成样本后进入训练组件，再有训练组件将梯度参数传递到参数服务器上。参数服务器在解决参数存储的同时，重点解决了热点存储访问和通信效率的问题。

⑦ DOING

召回：

目前的是将用户的行为序列引入双塔模型。如图，引用MIE ( 用户序列特征 ) 的ID类特征，通过预定义的操作将ID类特征转换成Embedding送入双塔中训练，基于欧氏距离来做用户与物料的召回。行为序列是通过卡了一段时间的样本取得定长的样本进行操作的。模型效果比较明显，单路召回点击率有两位数提升。

排序：

FiBiNET是将原始样本转化成Embedding的形式，然后将Embedding通过SENET Layer得到SENET-Like Embedding，然后将两部分分别进行内积和哈达玛乘积，再将结果进行concat，最后送入mlp。

在相关推荐实际数据的离线验证中，AUC有20BP的涨幅。小流量实验也观测到了正向效果，效果可期。但因为我们仍然处于放量阶段，考虑到可能存在的流量分桶不均、用户分组不均等情况，在没有实际大流量和反转试验前，确定性的结论不便于直接得出。不过目前来看，在相对DeepFM没有明显耗时劣势的前提下，取得相当不错的正向表现，大家随后也可以实际尝试下。

04 微博机器学习平台

1. 微博机器学习平台

① 平台演进

平台的支持对业务的支撑非常重要，目前机器学习平台支持的算法越来越多，灵活性越来越好，时效性也越来越高，存储性和稳定性都在稳步提升。目前支撑的参数规模到达万亿级，峰值到百万QPS，模型更新达分钟级。

② 平台现状

平台对外是一站式机器学习平台，就是通过统一交互和统一调度，将封装了数据存储能力和计算能力的各种物料、特征、样本、模型等服务，打包组合成解决方案，配合经验的共享和规范的统一，提供给业务方使用。

③ 平台接入

目前业务方的接入形成闭环的场景，从原始数据处理到模型推理都可以在平台一站式完成。业务方需要重点关注模型效果和业务效果的评估。正在推进中的是AutoML的自动模型评估，以及ABTest打通，进一步完善机器学习平台闭环，真正的一站式解决广大同学们的痛点。使用平台过程中，业务同学主要关注机器学习工作流和标准化的组件，提供插件化开发（weiclient、weiblink/weiflink、weilearn等插件化开发），由用户自定义，最终沉淀为平台组件。

④ 工作WeiFlow

这张图是WeiFlow的协议定义，是一个双层的有向无环图，双层主要是为了兼容异构环境和由于历史原因导致的不同计算框架。

⑤ 典型WeiFlow

这是典型的工作流实例，可以看到图中有多源依赖、并联依赖、链路串联依赖，基于双层dag设计可以完成兼容来统一托管新旧作业，实现作业的平滑迁移。

⑥ 服务标准化

从业务方反馈来看，机器学习平台可以解决业务痛点之外还可以提供一些提升效率的服务，比如指标数据统计、样本特征分析、Weilearn-plugin。此外从后台统计来看，SQL计算服务、深度学习服务、工作流服务作为服务使用Top3，一方面体现机器学习流程中样本、模型和工作流是刚需和常态需求。另一方面也体现平台专注于机器学习的特点与风格。

2. 微博机器学习平台的使用

下面看看机器学习平台是怎么用的：

① 计算服务

机器学习平台提供了统一完整的SQL计算服务，一站式解决不同集群，不同计算引擎，不同数据源的各种操作。汇集了不同的数据源，和不同的集群的使用概览，还有跨集群的数据的关联join，整体平台构建了一组统一的逻辑数据集群。这些对用户都是透明的，可以更专注于业务和数据本身。

② 样本服务

如何管理样本呢？平台的样本库不仅记录了样本的数据信息还有样本管理、共享和权限控制，既提供了共享的需求，也保证了数据安全。

③ 特征服务

平台提供接口查询样本中的特征，可以查一下目前支持什么样的特征，是否也有新特征需要上线，并且针对特征的可用性提供了特征完善度的统计。此外管理了数据的密级和访问记录，切实保障数据安全。

④ 训练服务

依托于模型库，模型训练就变得很简单了，用户只要关注用什么模型、模型参数、样本输入和特征配置。模型训练组件和样本库、模型库联动，支持一键上线和自定义模型改造。在简化使用的基础上，还保证了使用者极大的灵活性。

⑤ 模型服务

模型训练好之后要进行上线，这是通过模型服务完成的，模型服务和模型训练联动，拥有模型一键上线和版本切换的能力。实际中模型迭代非常快，版本的变更和模型同步也是很复杂的事情，机器学习平台解决了这个问题。此外支持配置共享，模型超参、特征处理、指标信息的组内分享，提高了效率。

3. 效果指标

随着平台接入，结合效率提升与经验赋能，平台同学同业务同学共同努力带来的涨幅十分可观。相关推荐和新浪移动都产生了核心指标double的喜人变化。

最后，我们希望能够"以微博之力，让世界更美"。今天的分享就到这里，谢谢大家。

作者介绍：

申恩兆，新浪微博算法工程师

李志然，新浪微博算法工程师

本文来自 DataFunTalk

原文链接：

微博推荐算法实践与机器学习平台演进

创作场景

微博推荐算法实践与机器学习平台演进