推荐系统之用户画像

用户画像是对现实世界中用户的数学建模

1.源于现实，高于现实

用户画像是描述用户的数据，是符合特定业务需求的对用户的形式化描述

2.源于数据，高于数据

用户画像是通过分析挖掘用户尽可能多的数据信息得到的。

标签是某一种用户特征的符号标示，用户画像是一个整体，各个维度不孤立，标签之间有联系，所以用户画像本质上就是用标签的集合来标示

1.每个标签在特征空间里，都是一个基向量，现实中用户画像需要的用户特征往往是成百上千的标签，所以用户画像是特征空间中的高维向量。用户画像实质上就是特征空间中的高维向量。特征空间的描述最多只能做到三维，四维就是理论上的一个存在了。

2.基向量之间有关联（向量之间会存在一个角度），不一定是正交的。

1.记录和存储亿级用户的画像，非常消耗我们的存储

2.随着用户兴趣的升级，支持和扩展不断增加的维度和偏好

3.毫秒级的更新

4.支撑个性化推荐、广告投放和精细化营销等产品

1.1.明确问题：是要解决分类问题，还是回归问题，是要确定用户是否流失，还是预测下一个月的销量。

1.2.追求需求和数据的匹配：比如评估用户是否存在欺诈行为或流失，都是需要了解用户的用卡习惯

1.3.明确需求：比如风险评估，用户流失都是分类问题，0和1.而聚类问题是对这一批数据未知，不知道把它分成几类，在现实问题中比如，我们有一堆文章进行分类。

1.4.数据的规模、重要特征的覆盖度等

2.1数据集成、数据冗余、数值冲突：数据是多种多样的，可能是微服务的数据，第三方传过来的，等等这些数据都不是很规范，比如，对同一维度的描述，可能有自己的一套定义接口的标准，举例对男女的描述，有的接口可能用M/F,有的用0,1，接口的规范不一样，所以需要进行预处理。

2.2数据采样：保证数据综合的覆盖所有可能出现的情况

2.3数据清洗、缺失值处理与噪声数据

3.1特征概述

数据和特征决定了机器学习的上限，而模型和算法只是逼近这个上限而已

特征：对所需解决问题有用的属性

特征的提取、选择和构造：

1.针对所解决的问题选择最有用的特征集合

2.通过相关系数等方式来计算特征的重要性（人工筛选、算法（随机森林）、PCA自动降维）

3.2特征提取：业务日志、WEB公开数据抓取、第三方合作

3.3特征处理：特征清洗、特征预处理（值处理、特征选择、特征组合、降维）、商业加工

3.4特征监控：

指标：时效性、覆盖率和异常值

可视化和预警：仪表盘监控

统计问题：

1.平滑：针对一些稀疏问题进行处理，在一些样本不够的情况下，一些样本特征比例为0的数据是我们不希望看到的就做平滑处理

2.归一化：归纳和统一，降低数据处理复杂度，把零散的数据降为0~1之间

分类问题：

2.1二分类：常见的算法有LR、SVM、RF、GBDT、NB

2.2多分类：RF、GBDT、最大熵、二分类+one vs all

回归问题：

常用的算法有ALS、Lasso、Ridge、回归树

聚类问题：

Kmeans等

语义分析：涉及到分词、LDA等

高维偏好：有些维度很高处理难度大，就进行降维可使用协同过滤里ALS、Slope算法

2.3常用模型实例

通常一个问题的解决需要尝试2~3种算法，但是最终可能选择其中的一种来上线（AB测试）。

逻辑回归一般效果还不错，模型非常简洁，而且效率很高，最重要的一点是适合并行的分布式处理，所以逻辑回归是用的非常多的非常简单高效的一种算法，下图是逻辑回归与支持向量机的使用准确率比较：

1.架构概述图如下

数据采集—>数据预处理—>数据存储—>离线和实时计算—>存储模型到hive/hbase/redis—>针对不同问题选取不同算法—>结果推送给mysql/redis—>可视化输出

辅助监控系统：

Ozzie:任务调度

Nagios：预警

Ganglia:总体集群的监控

2.详细架构图如下：

需求：性别预测问题

数据：

数据1：用户使用APP的行为数据

数据2：用户浏览网页的行为数据

1.数据挖掘常见问题中的哪一类，分类、聚类、推荐还是其他？

分类

2.数据集规模，数据集是否够大？

分类需要大的数据集

3.问题假设

所提供的数据是否满足所解决问题的假设？

男女行为不同的数据

预处理后的数据如下图：

表1特征工程

1.单个特征的分析

1）数值型特征的处理，比如App的启动次数是个连续值，可以按照低、中、高三个档次将启动次数分段成离散值

2）类别型特征的处理，比如用户使用的设备是三星或者联想，这是一个类别特征，可以采用0-1编码来处理

3）数据归一化

2.多个特征的分析

1）设备类型是否决定了性别?做相关性分析，计算相关系数

2）App的启动次数和停留时长是否完全正相关，结果表明特别相关，去掉停留时长

3）如果特征太多，可能需要做降维处理

表2特征工程

1.典型的文本数据：网页->分词->去停用同->向量化

2.分词

1)jieba分词库等

2)去除停用词，停用词表除了加入常规的停用词外，还可以将DF（Doucument Frequency）比较高的词加入停用词表，作为领域停用词

3)向量化，一般是将文本转化为TF或TF-IDF向量

特征工程-结果

数据1特征工程后的结果

数据2特征工程后的结果

选择算法和模型考虑的因素:

训练集的大小

特征的维度大小

所解决问题是否是线性可分的

所有的特征是独立的吗?

需要不需要考虑过拟合的问题

对性能有哪些要求?

奥卡姆剃刀原理：如无必要，勿增实体

选择算法和模型:

1)LR:

只要认为问题是线性可分的，就可采用LR

模型比较抗噪，而且可以通过L1、L2范数来做参数选择

效率高，可以应用于数据特别大的场景

很容易分布式实现

2)Ensemble方法

根据训练集训练多个分类器，然后综合多个分类器的结果，做出预测

评估方法：混淆矩阵——PR,ROC,AUC

人群圈选，也叫人群定向。在业界有中广泛的业务场景。

业界比较优秀的方案有百度基于doris来实现海量用户的圈选，可以实现千万级人群秒级圈选。但是这种方案比较复杂：

1、需要数仓同学加工二值化tag，构建用户二值化tag到用户bitmap集合的倒排索引

2、需要通过构建哈希分桶列，解决超大bitmap基数交并集问题

3、需要数仓同学构建全局字典，防止不连续id带来的roaring bitmap性能问题

4、需要通过to_bitmap函数解决动态标签与静态标签的组合圈选问题

5、需要团队有doris的运维能力

本博文介绍一种基于spark的轻量级圈选，可以实现千万级人群分钟级（5分钟以内）圈选。

业界还有基于ES、MR、离线+服务bitmap等方案（我们选型时，doris还不火，故不在此列）。

ES：大人群的滚动导出会给集群带来很大压力的；另外就是如果构建一个大而全画像宽表的话，这个表会很稀疏，所以我们会按业务主题构建多个es表，这样就会涉及到多个表之间join的问题，而es是不支持join语义的。

MR：老方案了，性能不大行

es+bitmap方案：这个方案扩展起来有点doris的味道。但是自己开发的话，其实比较复杂，而且没有居多性能优化手段的话，性能没那么理想，大都是比不上spark的。

因此，最后我们选择了spark做为人群圈选的方案。

我们构建了用户画像相关的一站式平台，前端平台包括人群管理、标签管理、画像分析等相关功能。

中间层服务对应包含人群管理中心、人群任务调度、人群解析引擎（负责前端json到Spark SQL的转化）、标签管理中心的模块；当然也包含权限、安全、流控、人群监控等辅助模块。

存储层，我们主要基于spark进行人群定向，依托Hbase/Redis做用户单到点查询，用Mysql做配置信息存储。

我们选取两个主题的画像进行交集圈选，圈选结果千万级，测试结果如下：

APP构建用户兴趣模型，主要分为两步：一是要打通多端多源数据，实现全渠道数据整合，构建完整的用户视图，二是基于数据，进行全面的用户分析，构建兴趣模型。以上两步可以通过个推·用户运营平台来完成。

1.打通多端多源数据，让建模更贴合实际

在建立用户兴趣模型前需要获取足够的真实用户反馈数据。一定的数据量可以保障用户建模更贴合实际。个推·用户运营支持APP、Web、H5、小程序等多端数据接入，以及MySQL、Hive等多源数据整合，可以帮助APP实现跨平台用户数据的有效打通和统一治理，为构建用户兴趣模型提供数据支撑。

2.全面的用户数据分析，构建用户画像

在整理好用户基础数据后我们需要对数据进行分析和归类，创建出基本的用户画像。个推·用户运营支持APP将自有数据和个推标签数据结合，通过自定义规则、采用行业标签模板等方式将多端、多源用户数据标签化，构建全面立体的用户画像。同时，

 APP可以自主运用事件分析、漏斗分析等十余种分析模型，深度洞察用户兴趣点，辅助兴趣模型构建和应用。

个推·用户运营SDK正限时免费中，APP开发者与运营者可注册/登录个推开发者中心免费注册体验。

构建兴趣模型

---