Press "Enter" to skip to content

机器学习在 360 手机助手的应用实践

本站内容均来自兴趣收集,如不慎侵害的您的相关权益,请留言告知,我们将尽快删除.谢谢.

推荐作为解决信息过载以及挖掘用户潜在需求的技术,目前已成为互联网产品的标配。工业界最开始由亚马逊使用协同过滤,包括常见的基于内容的推荐和基于用户的推荐;接下来出现矩阵分解,将用户行为矩阵分解为用户矩阵和物品矩阵,根据用户矩阵查找出最相关的TopK个物品;随着广告系统中CTR预估流程的日渐成熟,大部分推荐、搜索问题也转化为CTR预估问题,这个时期常见的模型包括LR、FM、GBDT以及一些模型融合的尝试(例如LR+GBDT[1]),这个时期难点是挖掘特征,需要做大量的特征工程;近几年深度学习凭借强大的表达能力和灵活的网络结构,在语音、图像上取得突破,在推荐领域也大放光彩,Wide&Deep[2]、DeepFM[3]、DIN[4]等网络结构在CTR预估问题中取得不错的效果。
在360手机助手产品中,首页、游戏页和软件页App推荐以及App相关推荐等多个场景中,用户下载App中推荐占有较高的比重。为了提升用户的黏度,360手机助手在产品中也加入资讯和游戏视频,如何更好的将App和内容进行混合,提升用户的下载转化和内容点击,也是推荐的一个挑战。本文主要概述360手机助手推荐涉及的方面,包括业务场景的理解,推荐系统架构,以及系统架构中比较核心的推荐流程、数据仓库建设以及线上分析监控。

业务场景


作为一个相对低频的APP,产品设计在应用场景中会尽量多元化,不仅要满足用户的找应用需求,也要满足用户下载后需求。

业务特点

应用市场的业务场景有如下几个特点:

  • APP总量多(百万级),但是优质相对较少,且不同APP生命周期不同

  • 用户使用频度相对较低,用户基础画像粒度较粗

  • 软件和游戏的爆款频率不同,影响用户下载的决策因素不同

  • 新手机和旧手机在下载习惯上差异大

  • 推荐场景较多,且优化目标不同

由于上面几个问题,应用商店的推荐系统在侧重点上会有所不同。
由于整个系统的每个部分都需要团队参与开发和维护,所以在工作的过程中我们尽量利用开源项目,并将部分代码模块化可配置化,一方面为了方便管理能够形成知识沉淀,另一方面为了减少维护上的麻烦并降低隐藏风险。

系统架构

360手机助手推荐整体框架图如下所示:

数据仓库层

由于算法技术部不仅要负责所有算法相关的工作,也要承担数据建设,数据分析等多维度的需求,在经历过各种阵痛之后才明白数据建设的重要性。部门最初的数据建设架构采取单层模式:接口层(或解析层)->应用,这种模式在数据源类型唯一且接口数量很少的场景下不会有太大问题,唯一的优势就是对于新业务的数据支持比较快,劣势很多:

  • 重复开发

  • 口径不一致

  • 改造维护成本高等等。

随着业务的发展,数据源类型增加(sdk形式、http请求、内部系统库等)、业务需求的变化(需求量、复杂性、重复性、及时性、多样性)单层模式的劣势被无限放大,此时数据的建设应该中心化、平台化(大数据中心),而数据仓库恰是大数据中心建设的核心。核心目的在于:

  • 接口层屏蔽数据源的多样化;

  • 应用层保障数据质量(完整性、及时性、准确定、唯一性);

  • 分层理念降低因源系统变化导致的迁移改造成本和维护成本、提高复用率避免重复开发及时响应业务需求;

  • 统一分层模型、命名规范,提供了全局的数据视图,使知识体系更便于查询和理解。

计算层

计算层从整体上可以划分为离线计算和实时计算两部分。计算层使用到的平台主要是360系统部提供的Spark, Hadoop MR, HBox(其中完成了对TensorFlow、MXNet、Caffe、Theano、PyTorch、Keras、XGBoost等常用框架的集成,同时具备良好的扩展性和兼容性)。
离线计算层的输出主要包括:

  • 用户画像

  • 训练模型

  • 相关索引

  • 个性化Push列表

  • 榜单

  • 报表,分析报告等

实时计算输出主要包括:

  • 用户的实时行为反馈

  • item的短期特征

  • 服务器&业务的实时监控指标等

推荐系统层

这个部分主要指提供线上服务的引擎部分,整个引擎的工作方式通过配置文件定义,不同的推荐业务对应不同的配置文件。引擎会根据配置文件分别读取对应的召回数据,选取排序模型,选取策略规则,读取运营干预数据,最终返回给用户一个完整的推荐列表。

以APP推荐为例

数据收集:用户画像数据,APP的特征数据会随着推荐日志记录下来,通过scribe对日志进行实时收集,并与用户的反馈数据通过uniqID进行关联存入原始训练数据中。之后进行数据清洗,格式化之后保存为csv格式存入数据仓库DM层。
量化指标:APP推荐的指标比较好定义,可以通过CTR/CVR来衡量推荐效果。 但是在视频(内容类)推荐的场景中量化指标会比较复杂,因为在应用商店场景中内容推荐场景的最终目的是提升用户下载欲望,但是实验表明直接优化下载最终的推荐结果并不理想,所以在视频(内容类)推荐中我们正在尝试使用迁移学习中MTL的思想,通过改进Wide&deep模型支持多目标训练,利用Tensorflow来对模型进行改进。
数据清洗采样:用户的曝光日志量非常大,但是用户的点击行为数据相对来说却很少。所以数据采样是必须要做的一步,首先过滤掉没有真正曝光给用户的数据,否则这些数据对模型的影响会非常大,模型在训练时的表现也很不稳定。考虑到业务场景的特殊性,有些用户虽然有真实曝光,但只是只是短暂的行为同时这部分用户没有产生任何的反馈数据,所以这部分数据也会被过滤掉。最后会根据优化目标的调整进行上采样和下采样的尝试。
特征:基于应用商店的使用场景,我们抽象出如下几个方面的特征:

  • APP特征:基础特征:ID,APP名,简介,分类信息,包大小,评论信息,评级信息,更新时间等;统计特征:分时间段的下载、CTR、CVR、收入等

  • 用户特征:人口属性: 性别,年龄,地域等;设备信息: 机型,品牌,分辨率,操作系统等;行为属性: 类目偏好,分时活跃,下载,搜索,浏览,其他数据源画像等

  • 上下文特征:时间,地域,应用场景,曝光位置等;近期,长期曝光数据

  • 交叉特征:cross,浏览&ID,性别年龄&ID等等;intersection,性别年龄&ID CTR, 兴趣&ID CTR等等

分析:毕竟特征决定模型的上限,虽然深度学习在语音和图像上的端到端的学习取得了非常不错的成绩,但是在推荐系统上想要完成端到端的学习困难还是非常大的,毕竟数据噪声比较多,而且用户日志相比于图像来说也没有很好的结构。特征分析一方面对输入给模型的数据进行优化,另一方面非常重要就是能够发现系统中存在的隐藏bug,有些bug在系统中很不容易被发现,但是通过特征分析能够及时发现,并避免事情进一步恶化。根据JOIN之后的日志进行特征分析,首先通过整体覆盖度判断特征质量。对于数值型特征从均值,方差,相关系数,卡方等维度进行分析。对于类别类特征从单特征CTR,信息增益,AUC等几个维度进行分析。
小样本数据示例continuous

小样本数据示例category
召回部分实际上应该单独来写,但是为了介绍的完整性这里也简要做一个介绍。 content-based: 基于APP的名称,简介,作者,tag等信息做基于内容的相似性,但是由于APP的简介通常比较短,且重点不够突出,单纯基于内容做相似召回效果并不理想。
item-based: 基于item的协同过滤由于用户的行为受展示内容影响比较大,且长尾APP的行为非常少,虽然对于相对高频的APP召回效果比较好,但是完全基于协同过滤会出现长尾APP召回不全或者无法召回的问题。
Embedding-based的方式:最开始我们基于用户安装数据利用word2vec思想做了embedding,但是用户的安装的各个APP之间的关联性并不强,并不能像文本类得到比较好的效果。后期我们参考youtube推荐系统的思想,通过做排序模型预测,间接得到APP的embedding向量,再计算各个APP的相似度。
如下图左侧基于协同过滤的结果基本集中在共享单车里面,右侧基于embedding方式能够发现一些其他共性,但是单独看每个模型都不太好,所以线上需要多种模型做融合,融合的方式需要一些人为经验,并通过排查badcase来调整。

基于人群的聚类:主要是针对新用户或者用户特征比较少的用户,比如根据机型,地域,性别,年龄等属性做召回,这一部分如果单纯考虑各个人群的下载量,安装量会导致结果没有区分度,所以需要将群里之间的差异考虑进去。这里面TGI是一个比较好的衡量效果,但是完全基于TGI会导致结果不受控制,所以需要对TGI公式加以变形,综合考虑其他因素作为最终结果

基于用户投票的召回:这部分结果主要针对榜单应用场景,为用户提供相对权威的榜单结果,提升用户的信任度,最终提升用户下载率。榜单分为总榜,飙升榜,新锐榜,分类榜等等。这部分数据会综合公司其他业务的数据做统一考虑,在排序计算上考虑了IMDB等算法。
排序模型:同时我们将代码封装为一个通用项目,通过配置文件的方式选择特征组合和处理的方式,自定义模型选择,选择优化器,自定义模型的导出形式等,对于自定义模型只需要重新定义model_fn就可以了。特征的离散化,embedding,交叉等操作都集成在model里面,线上只需要数据原始特征就可以了。线上引擎与离线训练使用同一套配置文件对特征进行处理,避免在线离线两部分由于人为偏差造成模型使用异常。代码结构化之后其他场景就可以比较快速的完成从离线训练到上线验证的过程。
示例:下图左1支持对特征列的变换处理,左2模型训练时的参数,左3完整特征列定义。

在项目最初期排序规则权重比较高,我们参考Facebook提出的Edge Rank思想,将用户的不同行为定义为不同的Edge,每个边的权重不同(比如下载 大于 浏览),相关度作为Edge下面item的score, 并将所有得分相乘得到最终排序。缺点是各个Edge的权重不好定义,需要频繁做AB测试,同时处理问题不够平滑。
之后将规则抽象为特征快速尝试LR,因为LR模型简单解释性强,对于我们理解线上业务有很大的帮助,但是由于LR对于特征的质量要求比较严格,需要我们做大量的特征挖掘以及特征组合的尝试,从性价比的角度来看不会长期把该模型作为主要优化模型。
正是由于LR对特征组合需求比较高,我们开始尝试GBDT,以及GBDT+LR的方式,以此减少对特征组合的烦恼。树模型虽然对连续型特征的划分能力很强,但是具有对于大规模稀疏ID类特征树的深度不好控制等缺点。FM在处理交叉特征上有比较明显的优势。考虑到实现成本,后期我们将重点放在深度学习上DNN,FM等模型考虑利用神经网络的方式实现。
目前主要是基于深度学习的推荐,根据Google Play的论文提出的Wide&Deep模型对线上排序进行了更新。wide&deep能够同时兼顾记忆性和泛化性,对低阶特征和高级特征都能够进行学习,目前wide&deep模型已经全量上线多个场景。但是wide部分还是需要人为介入一些交叉特征项,所以目前正在利用DeepFM来减少人为交叉部分,挖掘隐藏交叉特征,以此提升线上效果深度学习框架我们选择了tensorflow,训练代码部分基于tensorflow高级API Estimator来减少操作底层API带来的复杂性,并利用feature_column灵活的特征处理特征提升我们对特征尝试的效率。

主要为了做兴趣探测以及新品探测,线上主要使用UCB和汤普森采样,对于新游需要尽量提高曝光权重,同时如果有优质资源位需要售卖或者强制品牌曝光则会预留位置给运营配置。

线上

引擎排序部分目前分为两部分,深度学习排序部分完全基于TF Serving,好处是可以减少二次开发量,同时可以方便快速的验证模型效果,但由于每次请求都需要将大量的特征数据发送给TF Serving,所以会带来额外的网络开销。传统机器学习排序部分直接嵌入引擎中,作为引擎内的一个单元,与TF Serving相比节省了网络开销。同时当TF Serving服务出现问题时,引擎会自动将排序降级为传统机器学习排序。

对比效果

其中一个业务场景上线之后CTR的对比数据

业务层

从用户角度看,业务层指不同的推荐场景,每个场景下的产品设计和用户需求是不同的。

  • 比如首页第一屏的位置,虽然是个性化推荐,但是因为位置比较特殊,所以个性化推荐的可推内容需要做严格筛选,算法需要在有限的召回集里面做排序,这种场景对于排序的要求是比较高的。

  • 比如APP的相似推荐,这种场景更关注的是两个item之间的相关性,所以这中场景对于召回相似性的要求就比较高。

协调调度层

不同层之间的数据流向需要有一个完整的闭环,这样整个系统的发展才会是良性的。协调层的工作主要包括实时收集用户的推荐日志;item特征变动后准确更新的引擎,用户画像更新后快速完整的更新到用户画像系统,模型更新之后快速完整的更新到排序引擎等等。

分析&监控层

分析主要面向运营和产品人员,团队提供了自助查询平台和报表工作,方便非技术人员快速查询数据,分析结果。监控层主要包括核心指标监控和系统指标监控,系统指标监控通过ELK能够快速的搭建出可视化监控平台,能够方便快速的发现系统存在的问题并及时改进。

总结和展望

在机器学习的路上我们还有很长的路要走。在业务方面还需要继续加强对业务场景的理解对各个场景进行持续优化。在系统方面特征服务器,去重服务器等需要进一步拆分优化。在特征方面,我们会继续对特征的挖掘和利用进行深入调研,图像类的特征目前我们还没有使用,后续将专门针对图像做一些尝试。在模型方面,我们将持续进行网络结构的探索,尝试新的模型特性,并针对场景的特点进行契合。学术界和工业界的成功经验都很有价值,给我们提供了新的思路和方法,但由于面临的业务问题和场景积累的数据不同,还是需要进行针对场景的适配,以达到业务目标的提升。

参考文献

[1] He X, Pan J, Jin O, et al. Practical lessons from predicting clicks on adsat facebook[C]. Proceedings of 20th ACM SIGKDD Conference on KnowledgeDiscovery and Data Mining. ACM, 2014: 1-9. [2] H.-T. Cheng, L. Koc, J. Harmsen, T. Shaked, T. Chandra, H. Aradhye, G. Anderson, G. Corrado, W. Chai, M. Ispir, et al. Wide & deep learning for recommender systems. arXiv preprint arXiv:1606.07792, 2016. [3] Guo H, Tang R, Ye Y, et al. DeepFM: A Factorization-Machine based Neural Network for CTR Prediction[J]. 2017:1725-1731. [4] Guorui Zhou, Chengru Song, et al. Deep Interest Network for Click-Through Rate Prediction.arXiv preprint arXiv:1706.06978,2017. [5] Covington P, Adams J, Sargin E. Deep Neural Networks for YouTube Recommendations[C]// ACM Conference on Recommender Systems. ACM, 2016:191-198.

Be First to Comment

发表评论

电子邮件地址不会被公开。 必填项已用*标注