蚂蚁金服核心技术:百亿特征实时推荐算法揭秘

文章提出一整套创新算法与架构,通过对TensorFlow底层的弹性改造,解决了在线学习的弹性特征伸缩和稳定性问题,并以GroupLasso和特征在线频次过滤等自研算法优化了模型稀疏性。在支付宝核心推荐业务获得了uvctr的显著提升,并较大地提升了链路效率。

0.综述

在线学习(Online learning)由于能捕捉用户的动态行为,实现模型快速自适应,进而成为提升推荐系统性能的重要工具。然而它对链路和模型的稳定性,训练系统的性能都提出了很高的要求。但在基于原生TensorFlow,设计Online推荐算法时,我们发现三个核心问题:

一些资讯推荐场景,需要大量长尾词汇作为特征,需使用featuremap对低频特征频次截断并连续性编码,但耗时且方法aggressive。

使用流式数据后,无法预知特征规模,而是随训练逐渐增长。因此需预留特征空间训练几天后重启,否则会越界。

模型稀疏性不佳,体积达到数十GB,导致上传和线上加载耗时长且不稳定。

更重要的是,在线学习如火如荼,当流式特征和数据都被打通后,能按需增删特征,实现参数弹性伸缩的新一代训练平台成为大势所趋。为了解决这些问题,从2017年底至今,蚂蚁金服人工智能部的同学,充分考虑蚂蚁的业务场景和链路,对TensorFlow进行了弹性改造, 解决了以上三大痛点,简化并加速离线和在线学习任务。其核心能力如下:

弹性特征伸缩体系,支持百亿参数训练。

group_lasso优化器和频次过滤,提高模型稀疏性,明显提升线上效果。

模型体积压缩90%,完善的特征管理和模型稳定性监控。

在与业务线团队的共同努力下,目前已在支付宝首页的多个推荐场景全流量上线。其中某推荐位的个性化online learning桶最近一周相比线上多模型融合最优桶提升4.23% , 相比随机对照提升达34.67% 。 某个性化资讯推荐业务最近一周,相比DNN基准uv-ctr提升+0.77%,pv-ctr提升+4.78%,模型体积压缩90%,链路效率提升50%。

  1. 弹性改造及优势

背景:在原生TensorFlow中,我们通过Variable来声明变量,若变量超过了单机承载的能力,可使用partitioned_variables来将参数分配到不同机器上。 但必须指定shape,声明后即不可改变,通过数组索引查找。

由于推荐系统中大量使用稀疏特征,实践中一般采取embedding_lookup_sparse一类的方法在一个巨大的Dense Variable中查找向量并求和,来代替矩阵乘法。开源Tensorflow限定了Variable使用前必须声明维度大小,这带来了两个问题:

1)需要预先计算特征到维度范围内的int值的映射表,这一步操作通常在ODPS上完成。因为需要扫描所有出现的特征并编号,计算非常缓慢;

2)在online learning场景下,为了容纳新出现的特征,需要预留一部分维度空间,并在线上不断修改映射表,超过预留空间则需要重新启动在线任务。

为了突破固定维度限制,实现特征的动态增加和删除,最朴素的优化想法是在TensorFlow底层实现模拟字典行为的Variable,并在此基础上重新实现Tensorflow上层API。由此我们进行了优化,在server新增了基于HashMap的HashVariable,其内存结构如下:

在声明该变量时,只需增加一句,其他训练代码皆不需改动:

每个特征都通过hash函数映射到一个2的64次方大小的空间内。当需要计算该特征时,PS会按需惰性创建并返回之。但其上层行为与原生TF一致。由于去掉了featuremap转ID的过程,我们内部形象地将其称为“去ID化”。在此之上我们实现了Group Lasso FTRL,频次过滤和模型压缩等一系列算法。

备注:弹性特征带来一个显著的优势:只要用足够强的L1稀疏性约束,在单机上就能调试任意大规模的特征训练,带来很多方便。我们的hashmap实现是KV化的,key是特征,value是vector的首地址。

离线训练优化

经过这样的改造后,在离线批量学习上,带来了以下变化:

在线训练优化

online learning上,能带来如下变化:

 image 

除了性能有明显的提升之外,其最大的优势是不需提前申请空间,训练可以无缝稳定运行。

  1. 特征动态增删技术

弹性架构,主要目的就是特征优选,让模型自适应地选择最优特征,进而实现稀疏化,降低过拟合。本节介绍特征优选的两个核心技术:

使用流式频次过滤, 对特征进入进行判定。

使用Group Lasso优化器,对特征进行筛选和删除。

2.1 Group Lasso 优化器

稀疏化是算法追求的重要模型特性,从简单的L1正则化和Truncated Gradient[9], 再到讨论累积梯度平均值的RDA(Regularized Dual Averaging)[10], 再到目前常见的 FTRL[2] 。 然而它们都是针对广义线性模型优化问题提出的稀疏性优化算法,没有针对sparse DNN中的特征embedding层做特殊处理。把embedding参数向量当做普通参数进行稀疏化,并不能达到在线性模型中能达到的特征选择效果,进而无法有效地进行模型压缩。

例如:当包含新特征的样本进入时,一个特征对应的一组参数(如embedding size为7,则参数数量为7)被激活,FTRL判定特征中的部分参数无效时,也不能安全地将该特征删除。如图:

因此,在L1和L2正则的基础上,人们引入L21正则(group lasso)和L2正则(exclusive sparsity),分别表示如下:

L21早在2011年已经引入,它最初目的是解决一组高度关联特征(如男女)应同时被保留或删除的问题,我们创新地扩展到embedding的表示上,以解决类似的问题。

在L21中,由于内层L2正则将一个特征的所有参数施加相同的约束,能将整组参数清除或保留,由此决定embedding层中的某些特征对应的embedding向量是否完全删除,提升模型泛化性。因此称为group lasso。

而L12则正好相反,它迫使每组参数中的非0参数数量一致但值又尽可能不同,但使输出神经元互相竞争输入神经元,进而使特征对目标更具区分性。

对于DNN分类网络,底层表示要求有足够的泛化性和特征抽象能力,上层接近softmax层,需要更好的区分性。因此我们通常在最底层的embedding层使用group lasso。即如下的优化目标:

直接将L21正则项惩罚加入loss,模型最终也能收敛,但并不能保证稀疏性。因此Group lasso优化器参考了FTRL,将梯度迭代分成两个半步,前半步按梯度下降,后半步微调实现稀疏性。通过调节L1正则项(即公式中的λ),能有效地控制模型稀疏性。

Group lasso是弹性计算改造后,模型性能提升和压缩的关键。值得指出:

在我们实现的优化器中,Variable,以及accum和linear两个slot也是KV存储。

L12和L21正则相结合的方法也已经有论文讨论[8],但我们还未在业务上尝试出效果。

由于篇幅限制,本节不打算详细介绍Group lasso的原理和推导

2.2 流式频次过滤

讨论完特征动态删除的方法后,我们再分析特征的准入策略。

2.2.1 频次过滤的必要性

在Google讨论FTRL的文章1中提到, 在高维数据中大部分特征都是非常稀疏的,在亿级别的样本中只出现几次。那么一个有趣的问题是,FTRL或Group FTRL优化器能否能删除(lasso)极低频特征?

在RDA的优化公式中,满足以下条件的特征会被置0:

image

若在t步之前,该特征只出现过几次,未出现的step的梯度为0,随着步数增大,满足上述条件变得越来越容易。由此RDA是可以直观处理极稀疏特征的。 但对于FTRL,要满足:

image

其中,image不仅和历史梯度有关,还与历史学习率和权重w有关。 因此FTRL虽然也能处理极稀疏特征,但并没有RDA那么aggressive(此处还待详细地分析其下界,Group FTRL与此类似)。

由于FTRL在设计和推导时并未明确考虑极低频特征,虽然通过增大λ,确实能去除大量极低频特征,但由于约束太强,导致部分有效特征也被lasso,在离线实验中被证明严重影响性能。其次,对这些巨量极低频特征,保存历史信息的工程代价是很高昂的(增加几倍的参数空间和存储需求),如下图:

因此我们提出,能否在实时数据流上模拟离线频次过滤,为特征提供准入门槛,在不降低模型性能的基础上,尽量去除极低频特征,进一步实现稀疏化?

2.2.2 频次过滤的几种实现

注意: 由于默认的embedding_lookup_sparse对特征执行了unique操作(特征归一化以简化计算),因此在PS端是不可能获取真实特征和label频次的。需要Python端对placeholder统计后,上传给server端指定的Variable,优化器通过slot获得该Variable后作出联合决策。

最naive的思路是模拟离线频次过滤,对特征进行计数,只有达到一定阈值后再进入训练,但这样破坏了数据完整性:如总频次6,而阈值过滤为5,则该特征出现的前5次都被忽略了。为此我们提出了两种优化方案:

基于泊松分布的特征频次估计

在离线shuffle后的特征满足均匀分布,但对在线数据流,特征进入训练系统可看做泊松过程,符合泊松分布:
image

其中n为当前出现的次数,t为当前的步数,λ为单位时间发生率,是泊松分布的主要参数,T为训练总步数。image为特征最低门限(即最少在T时间内出现的次数)。

因此我们能通过前t步的特征出现的次数n,将t时刻当做单位时间,则
image。 根据泊松分布,我们可以算出剩余image时间内事件发生大于等于image次的概率image。 每次该特征出现时,都可按该概率image做伯努利采样,特征在t步进入系统的概率用下式计算:
image

通过真实线上数据仿真,它能接近离线频次过滤的效果,其λ是随每次特征进入时动态计算的。它的缺陷是:

当t越小时,事件发生在t内的次数的variance越大,所以会以一定概率误加或丢弃特征。

未来总的训练步数T在在线学习中是未知的。

频次过滤与优化器相分离,导致不能获得优化器的统计信息。

动态调L1正则方案

在经典的FTRL实现中,L1正则对每个特征都是一致的。这导致了2.2.1 中提到的问题:过大的L1虽然过滤了极低频特征,但也影响的了模型的性能。参考各类优化器(如Adam)对learning_rate的改进,我们提出:通过特征频次影响L1正则系数,使得不同频次的特征有不同的lasso效果。

特征频次和基于MLE的参数估计的置信度相关,出现次数越低置信度越低。如果在纯频率统计基础上加入一个先验分布(正则项),当频率统计置信度越低的时候,越倾向于先验分布,相应的正则系数要更大。我们经过多个实验,给出了以下的经验公式:
image
其中c是惩罚倍数,image为特征最低门限,这两者皆为超参,image是当前特征出现的频次。

我们在线上环境,使用了动态调节L1正则的方案 。在uvctr不降甚至有些微提升的基础上,模型特征数比不使用频次过滤减少75%,进而从实验证明了频次过滤对稀疏化的正向性。它的缺点也很明显:特征频次和正则系数之间的映射关系缺少严谨证明。

频次过滤作为特征管理的一部分,目前还少有相关论文研究,亟待我们继续探索。

3. 模型压缩和稳定性

3.1 模型压缩

在工程上,由于做了优化,如特征被优化器lasso后,只将其置0,并不会真正删除;在足够多步数后才删除。同时引入内存池,避免特征的反复创建和删除带来的不必要的性能损失。 这就导致在训练结束后,模型依然存在大量0向量。导出时要进一步做模型压缩。

由于引入了HashPull和HashPush等非TF原生算子,需要将其裁剪后转换为原生TF的op。 我们将这些步骤统称图裁剪(GraphCut), 它使得线上inference引擎,不需要做任何改动即可兼容弹性改造。由于有效特征大大减少,打分速度相比原引擎提升50%以上。

我们将图裁剪看做TF-graph的静态优化问题,分为3个步骤:

第一遍遍历Graph,搜索可优化子结构和不兼容的op。

第二遍遍历,记录节点上下游和元数据,裁剪关键op,并将Variable的非0值转存至Tensorflow原生的MutableDenseHashTable。本步骤将模型体积压缩90%。

拼接新建节点,重建依赖关系,最后递归回溯上游节点,去除与inference无关的子图结构

我们实现了完整简洁的图裁剪工具,在模型热导出时调用, 将模型从原先的8GB左右压缩到几百兆大小,同时保证模型打分一致。

3.2 模型稳定性和监控

online learning的稳定性非常重要。我们将线上真实效果,与实时模型生成的效果,进行了严密的监控,一旦样本偏差过多,就会触发报警。

由于需捕捉时变的数据变化,因而不能用固定的离线数据集评估模型结果。我们使用阿里流式日志系统sls最新流入的数据作为评估样本,以滑动窗口先打分后再训练,既维持了不间断的训练,不浪费数据,同时尽可能高频地得到最新模型效果。

我们对如下核心指标做了监控:

样本监控: 正负比例,线上打分值和online-auc(即线上模型打分得到的auc),产出速率,消费速率。

训练级监控: AUC, User-AUC(参考备注),loss, 模型打分均值(与样本的正负比例对齐),异常信息。

特征级管理: 总特征规模,有效/0/删除特征规模,新增/插入/删除的速率。

整体模型和调度:模型导出的时间,大小,打分分布是否正常,是否正常调度。

业务指标:uvctr,pvctr(小时级更新,T+1报表)。

线上与训练指标之间的对应关系如下表:

通过http接口,每隔一段时间发送监控数据,出现异常会及时产生钉钉和邮件报警。下图是对9月20日到27号的监控,从第二张图表来看,模型能较好的适应当前数据流的打分分布。

User-AUC:传统的AUC并不能完全描述uvctr,因为模型很可能学到了不同用户间的偏序关系,而非单个用户在不同offer下的点击偏序关系。为此,我们使用了User-AUC,它尽可能地模拟了线上uvctr的计算过程,在真实实验中,监控系统的uvctr小时报表,与实时模型输出的User-AUC高度一致。

4. 工程实现和效果

目前算法已经在支付宝首页的多个推荐位上线。推荐系统根据用户的历史点击,融合用户画像和兴趣,结合实时特征,预估用户CTR,进而提升系统整体点击率。

我们以推荐位业务为例说明,其采用了经典的wide&deep的网络结构,其sparse部分包含百级别的group(见下段备注1)。 一天流入约百亿样本,label的join窗口为固定时长。由于负样本占大多数,上游链路对正负样本做了1:8的降采样(见下文备注2)。

训练任务采用蚂蚁统一训练平台构建,并使用工作流进行定时调度,离线和在线任务的其他参数全部一致。Batchsize为512,每200步(即20万样本)评估结果,定时将模型通过图裁剪导出到线上系统。当任务失败时,调度系统会自动拉起,从checkpoint恢复。

该推荐业务的online learning桶最近一周相比线上多模型融合最优桶提升4.23% , 相比随机对照提升达34.67% 。 另一资讯推荐业务其最近一周,相比DNN基准uv-ctr提升+0.77%,pv-ctr提升+4.78%。实验效果相比有较大的提升。

备注1: group embedding是将相似emb特征分组,各自lookup求和后再concat,使得特征交叉在更高层进行。其设计是考虑到不同group的特征差异很大(如user和item),不应直接对位求和。

备注2: inference打分仅做pointwise排序,采样虽改变数据分布但不改变偏序关系,因此并未在训练上做补偿。

5. 未来工作

弹性特征已经成为蚂蚁实时强化深度学习的核心要素。它只是第一步,在解决特征空间按需创建问题后,它会带来一个充满想象力的底层架构,众多技术都能在此基础上深挖: 在工程上,可继续从分钟级向秒级优化,进一步提升链路实时性并实现模型增量更新; 在算法上,我们正在探索如样本重要性采样,自动特征学习,在线线性规划与DNN的结合,实现优化器联合决策等技术。

由于在线学习是个复杂的系统工程,我们在开发和调优时遇到了大量的困难,涉及样本回流,训练平台,模型打分,线上评估等一系列问题,尤其是稳定性,但基本都一一克服。为了保证线上结果稳定可信,我们在观察和优化两三个月后才发布这篇文章。

本文作者为蚂蚁金服人工智能部认知计算组的基础算法团队,团队涉及图像、NLP、推荐算法和知识图谱等领域,带头人为国家知名算法专家褚崴,拥有定损宝和理赔宝等核心业务。


原文链接
本文为云栖社区原创内容,未经允许不得转载。

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/news/519740.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

老码农肺腑直言:为什么我不建议你学Python?

关于Python,我们听到最多的一句话就是:代码简洁。目前来看,代码量上C:Java:Python100:10:1。Python简洁度完胜,但这却也是他的“死亡缺点”!今天想跟大家分享,学Python的一系列惊天大坑……Python钱多“话少…

如何评估深度学习模型效果?阿里工程师这么做

复杂的深度模型中,如果效果不好,是因为网络设计的欠缺?还是数据天然缺陷?是训练代码的bug?还是Tensorflow自身的问题?基于此,阿里工程师推出了DeepInsight深度学习质量平台,致力于解…

开发者如何赶上 5G 风口?

戳蓝字“CSDN云计算”关注我们哦!随着5G正式步入商用,5G 技术引发广泛关注。据信息通信研究院《5G经济社会影响白皮书》预测,2030年,5G将直接带动的总产出、经济增加值、就业机会分别为6.3万亿元、2.9万亿元和800万个。据BOSS直聘…

罗辑思维在全链路压测方面的实践和工作笔记

业务的知名度越高,其背后技术团队承受的压力就越大。一旦出现技术问题,就有可能被放大,尤其是当服务的是对知识获取体验要求颇高的用户群体。 提供知识服务的罗辑思维主张“省时间的获取知识”,那么其技术团队在技术实践方面是如…

能用机器完成的,千万别堆工作量|持续集成中的性能自动化测试

1.背景 当前闲鱼在精益开发模式下,整个技术团队面临了诸多的能力落地和挑战,尤其是效能方面的2-1-1的目标(2周需求交付周期,1周需求开发周期,1小时达到发布标准),具体可见 闲鱼工程师是如何构建持续集成流水线&#x…

详解GPU技术关键参数和应用场景

戳蓝字“CSDN云计算”关注我们哦!作者 | Hardy责编 | 阿秃随着云计算,大数据和人工智能技术发展,边缘计算发挥着越来越重要的作用,补充数据中心算力需求。计算架构要求多样化,需要不同的CPU架构来满足不断增长的算力需…

5款神器级别Github 的Chrome插件

文章目录1. Chrome插件一:octotree2. Chrome插件二:sourcegraph3. Chrome插件三:Enhanced GitHub4. Chrome插件四:octolinker5. Chrome插件五:gitzip for github1. Chrome插件一:octotree Octotree是一个 …

用AI说再见!“辣眼睛”的买家秀

阿里妹导读:提起买家秀和卖家秀,相信大家脑中会立刻浮现出诸多画面。同一件衣服在不同人、光线、角度下,会呈现完全不同的状态。运营小二需从大量的买家秀中挑选出高质量的图片。如果单纯靠人工来完成,工作量过于巨大。下面&#…

云+X案例展 | 电商零售类:WakeData助力叁拾加数字化变革

本案例由WakeData投递并参与评选,CSDN云计算独家全网首发;更多关于【云X 案例征集】的相关信息,点击了解详情丨挖掘展现更多优秀案例,为不同行业领域带来启迪,进而推动整个“云行业”的健康发展。在新零售时代下&#…

linux环境安装Kafka最新版本 jdk1.8

文章目录一、环境分布二、实战1. kafka下载2. 解压3. 配置4. 编写启动脚本5. 编写关闭脚本6. 赋予脚本可执行权限7. 脚本使用案例一、环境分布 软件版本jdk1.8kafkakafka_2.13-2.5.0 二、实战 kafka官网地址: http://kafka.apache.org/downloads 1. kafka下载 …

基于泛型编程的序列化实现方法

写在前面 序列化是一个转储-恢复的操作过程,即支持将一个对象转储到临时缓冲或者永久文件中和恢复临时缓冲或者永久文件中的内容到一个对象中等操作,其目的是可以在不同的应用程序之间共享和传输数据,以达到跨应用程序、跨语言和跨平台的解耦…

微服务架构下,解决数据一致性问题的实践

随着业务的快速发展,应用单体架构暴露出代码可维护性差、容错率低、测试难度大和敏捷交付能力差等诸多问题,微服务应运而生。微服务的诞生一方面解决了上述问题,但是另一方面却引入新的问题,其中主要问题之一就是:如何…

2019阿里云开年Hi购季满返活动火热报名中!

2019阿里云云上采购季活动已经于2月25日正式开启,从已开放的活动页面来看,活动分为三个阶段: 2月25日-3月04日的活动报名阶段、3月04日-3月16日的新购满返5折抢购阶段、3月16日-3月31日的续费抽豪礼5折抢购阶段。 整个大促活动包含1个主会场…

2019云计算高光时刻:乱云飞渡 传统IT大溃败

前言:2019年,物理机最后一张王牌也败给了云计算,无论从成本还是性能的角度,都没有不选云计算的理由,这是一个时代的终结。 2019的云计算市场格局,依旧是马太效应凸显、大者恒大的趋势继续,但在…

java 集成 kafka 0.8.2.1 适配jdk1.6

文章目录一、版本说明二、实战2.1. 依赖2.2. 生产者代码2.3. 消费端代码2.4. 测试三、小伙伴疑难解答3.1. 首先新建一个maven项目3.2. 把我的依赖和代码复制过去3.3. 把我写的case调试通3.4. 找到左边External Libraries3.5. jar处理3.6. 打开非maven项目,添加jar3.…

阿里云MWC 2019发布7款重磅产品,助力全球企业迈向智能化

当地时间2月25日,在巴塞罗那举行的MWC 2019上,阿里云面向全球发布了7款重磅产品,涵盖无服务器计算、高性能存储、全球网络、企业级数据库、大数据计算等主要云产品,可满足电子商务、物流、金融科技以及制造等各行业企业的数字化转…

linux环境安装 kafka 0.8.2.1 jdk1.6

文章目录一、环境分布二、实战1. kafka下载2. 解压3. 配置4. 编写启动脚本5. 编写关闭脚本6. 赋予脚本可执行权限7. 脚本使用案例三、Config配置四、Consumer配置五、Producer配置很多小伙伴问我,为什么不用最新版本的kafka呢?关于这个问题,都…

元旦限时特惠,耳机、书籍等大降价

戳蓝字“CSDN云计算”关注我们哦!今天是12月31日离2020年仅有不到一天的时间你们的2019年目标都实现了吗?在这一年你写了多少行代码改了多少个bug呢?2020年的愿望是否也是希望自己写的代码bug能少一些?小编的2020年希望能买到更多…

ant编译web项目

文章目录1.下载ant2. 解压ant3. 配置an环境变量4. 验证二、编译项目2.1. 新建一个build.xml2.2. 编译项目测试1.下载ant 官网链接: https://ant.apache.org/srcdownload.cgi 2. 解压ant 3. 配置an环境变量 4. 验证 ant -v二、编译项目 2.1. 新建一个build.xml…

Spark in action on Kubernetes - Playground搭建与架构浅析

前言 Spark是非常流行的大数据处理引擎,数据科学家们使用Spark以及相关生态的大数据套件完成了大量又丰富场景的数据分析与挖掘。Spark目前已经逐渐成为了业界在数据处理领域的行业标准。但是Spark本身的设计更偏向使用静态的资源管理,虽然Spark也支持了…