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

介绍

推荐作为一种解决信息过载、挖掘用户潜在需求的技术，已经成为互联网产品的标配。亚马逊在业界最早使用协同过滤，包括常见的基于内容的推荐和基于用户的推荐。随后出现了矩阵分解，将用户行为矩阵分解为用户矩阵和商品矩阵，并根据用户矩阵找到 Top K 个最相关的商品。随着广告系统中 CTR 预估流程的成熟，大部分推荐和搜索问题都转化为 CTR 预估问题。这期间常见的模型有 LR、FM、GBDT，也有一些模型融合的尝试（如 LR+GBDT[1]）。这期间的难点是特征挖掘，需要进行大量的特征工程。近年来，深度学习凭借强大的表达能力和灵活的网络结构在语音和图像上取得突破，在推荐领域也大放异彩，Wide&Deep[2]、DeepFM[3]、DIN[4] 等网络结构在 CTR 预估问题上都取得了不错的效果。

在360手机助手产品中，在首页、游戏页、软件页等多个场景的应用推荐，以及应用相关的推荐中，推荐占用户下载应用的比重都很高。为了提高用户粘性，360手机助手还在产品中加入了新闻资讯、游戏视频等内容。如何更好地将应用与内容进行混合，提高用户下载转化和内容点击率，也是推荐面临的挑战。本文主要概述了360手机助手推荐所涉及的方面，包括业务场景的理解、推荐系统架构，以及系统架构中比较核心的推荐流程、数据仓库的构建、在线分析和监控等。

商业场景

作为一款相对低频的APP，产品设计在应用场景上会尽量做到多样化，不仅满足用户寻找应用的需求，更要满足用户下载之后的使用需求。

业务特色

应用市场的业务场景有以下特点：

由于以上问题，应用商店的推荐系统会有不同的侧重点。

由于整个系统的每个部分都需要团队的参与开发和维护，所以我们在工作过程中尽量利用开源项目，将部分代码模块化、配置化，一方面方便管理，形成知识积累，另一方面也是为了减少维护的麻烦，降低风险隐患。

系统结构

360手机助手推荐的整体框架图如下：

数据仓库层

由于算法技术部不仅负责所有算法相关的工作，还有数据构建、数据分析等多维度的需求，所以在经历了各种阵痛之后才意识到数据构建的重要性。部门最初的数据构建架构采用的是单层模型：接口层（或解析层）->应用。这种模型在数据源类型单一、接口数量较少的场景下不会出现太多问题，唯一的好处是对新业务的数据支撑比较快，但也存在不少弊端：

随着业务的发展，数据源种类增多（sdk形式、http请求、系统内部库等），业务需求的变化（需求量、复杂度、重复性、时效性、多样性）无限放大了单层模型的弊端。此时数据建设应该集中化、平台化（大数据中心），而数据仓库是大数据中心建设的核心。核心目的是：

计算层

计算层一般可以分为离线计算和实时计算两部分，计算层主要采用360系统部提供的Spark、Hadoop MR、HBox（集成了TensorFlow、MXNet、Caffe、Theano、PyTorch、Keras、XGBoost等常用框架，具有良好的扩展性和兼容性）。

离线计算层的输出主要包括：

实时计算输出主要包括：

推荐系统层

这部分主要是指提供在线服务的引擎部分，整个引擎的工作模式由配置文件定义，不同的推荐服务对应不同的配置文件，引擎会根据配置文件读取对应的召回数据、选择排序模型、选择策略规则、读取操作干预数据，最终返回一个完整的推荐列表给用户。

以APP推荐为例

数据收集：推荐日志会记录用户画像数据、APP特征数据，通过Scribe实时采集日志，通过UniqID与用户反馈数据关联并存入原始训练数据中，之后经过清洗、格式化、保存为csv格式存入数据仓库DM层。

量化指标：APP推荐的指标相对容易定义，通过CTR/CVR即可衡量推荐效果。但在视频（内容）推荐的场景下，量化指标更加复杂，因为在App Store场景下内容推荐的最终目的是提高用户的下载欲望，但实验表明直接优化下载这一最终推荐结果并不理想。因此在视频（内容）推荐上，我们正在尝试借鉴迁移学习中MTL的思想，改进Wide&Deep模型以支持多目标训练，并使用Tensorflow对模型进行改进。

数据清洗与采样：用户曝光日志的量非常大，但是用户点击行为数据量相对较少，因此数据采样是必要的步骤。首先过滤掉没有真正曝光给用户的数据，否则这些数据对模型的影响会非常大，模型在训练时的性能也会不稳定。考虑到业务场景的特殊性，有些用户有真正的曝光，但只是短期行为，这些用户不会产生任何反馈数据，因此这部分数据也会被过滤掉。最后会根据优化目标的调整尝试上采样、下采样。

特点：基于应用商店的使用场景，我们抽象出以下特点：

分析：毕竟特征决定了模型的上限，虽然深度学习在语音、图像上端到端学习取得了非常好的效果，但是在推荐系统上完成端到端学习还是非常困难的，毕竟数据是有噪声的，用户日志相比于图像并没有很好的结构化。特征分析一方面可以优化输入到模型的数据，另一方面能够发现系统中隐藏的bug也非常重要。有些bug在系统中不容易发现，但是通过特征分析可以及时发现，防止进一步恶化。根据JOIN后的日志进行特征分析，先以整体的覆盖率来判断特征质量。对于数值型特征，可以从均值、方差、相关系数、卡方等维度进行分析。对于分类型特征，可以从单个特征CTR、信息增益、AUC等维度进行分析。

小样本数据示例连续

小样本数据示例类别

召回部分其实应该单独写，但是为了完整性，这里简单介绍一下。基于内容：根据APP的名称、简介、作者、标签等信息，进行基于内容的相似度，但由于APP的介绍通常较短，重点不够突出，单纯基于内容的相似召回效果并不理想。

基于物品：基于物品的协同过滤对于召回频率较高的应用比较有效，因为用户行为受展示内容影响较大，而长尾应用的行为很少。但如果完全基于协同过滤，就会存在长尾应用召回不完整或无法召回的问题。

基于Embedding的方法：一开始我们用word2vec根据用户安装数据做embedding，但是用户安装的app之间相关性不强，不能得到像文本分类那么好的效果。后来我们参考了YouTube推荐系统的思想，通过做排名模型预测间接得到app的embedding向量，然后计算各个app的相似度。

如下图所示，左侧基于协同过滤的结果基本集中在共享单车上，右侧基于 embedding 方法可以发现一些其他的共性。但是每个模型单独看效果都不是很好kaiyun体育，所以需要在线进行多个模型的融合。融合方法需要一些人工经验和通过排查 bad case 进行调整。

基于人群的聚类：主要针对新用户或者特征较少的用户，比如基于机型、地域、性别、年龄等属性的召回。这部分如果只考虑各人群的下载安装量，结果不会有差异化，所以需要考虑群体间的差异。TGI在这里是测量效果比较好，但是单纯基于TGI会导致结果不受控制kaiyun官方网app下载app，所以需要对TGI公式进行变形，综合考虑其他因素作为最终结果。

基于用户投票的召回率：这部分结果主要针对榜单的应用场景，为用户提供相对权威的榜单结果，提高用户信任度，最终提高用户下载率。榜单分为总榜、飙升榜、新榜、品类榜等。这部分数据会结合公司其他业务的数据进行统一考虑云开·全站apply体育官方平台，在排序计算时会考虑IMDB等算法。

排序模型：同时我们将代码封装成通用工程，通过配置文件选择特征组合及处理方式，自定义模型选择，选择优化器，自定义模型导出格式等。对于自定义模型，只需要重新定义model_fn即可。特征的离散化、embedding、crossover等操作都集成在模型中，在线上只需要数据原始特征即可。在线引擎和离线训练使用同一套配置文件处理特征，避免在线和离线部分因人为偏见导致模型使用异常。代码结构化后，其他场景可以快速完成从离线训练到在线验证的流程。

示例：下图中，左侧（1）支持特征列的转换处理，左侧（2）展示了模型训练时的参数，左侧（3）展示了完整的特征列定义。

项目前期，排序规则的权重比较高，我们参考了Facebook提出的Edge Rank思想，将不同的用户行为定义为不同的Edge，每条Edge的权重不同（比如下载大于浏览），以相关度作为Edge下item的得分，将所有得分相乘得到最终排名。缺点是每条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和Thompson采样，对于新游戏，需要尽量增加曝光权重，同时如果有优质资源需要卖点或者强制品牌曝光，会预留空间进行运营配置。

在线的

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

对比效果

某业务场景上线后CTR对比数据

业务层

从用户角度来说，业务层指的是不同的推荐场景，每个场景下的产品设计和用户需求都是不一样的。

协调调度层

不同层之间的数据流需要形成完整的闭环，这样整个系统的发展才能健康。协调层的工作主要包括实时收集用户推荐日志；商品特征变化后引擎的精准更新，用户画像更新后用户画像体系的快速完整更新，模型更新后排序引擎的快速完整更新等。

分析监控层

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

总结与展望

在机器学习的道路上我们还有很长的路要走。业务方面，我们需要继续加强对业务场景的理解，不断优化每一个场景。系统方面，特征服务器、去重服务器等需要进一步拆分和优化。特征方面，我们会继续对特征的挖掘和利用进行深入研究，目前我们还没有使用图片特征，未来会针对图片做一些尝试。模型方面，我们会继续探索网络结构，尝试新的模型特征，并将它们与场景特点相匹配。学术界和工业界的成功经验非常宝贵，为我们提供了新的思路和方法。但由于业务问题和场景积累的数据不同，我们还需要适配场景，才能实现业务目标的提升。

参考

[1]He Chai, M. Ispir 等。推荐系统的广泛和深度学习。arXiv preprint arXiv:1606.07792，2016。[3]Guo H, Tang R, Ye Y 等。DeepFM：一种基于分解机的神经网络用于点击率预测[J]。2017:1725-1731。[4] Guorui Zhou, Chengru Song 等。用于点击率预测的深度兴趣网络。arXiv preprint arXiv:1706.06978，2017。[5]Covington P, Adams J, Sargin E. 用于 YouTube 推荐的深度神经网络[C]// ACM 推荐系统会议。ACM，2016:191-198。