推荐系统之--特征工程（用户画像构建）

特征工程往往是推荐系统中必要的一环，而且是最基础最重要的一环，不论是在模型训练阶段还是召回阶段，都需要以特征工程为基础。

下面会从几个方面讲解特征工程

特征工程的概念

那具体什么是特征工程呢？
特征工程就是：从用户信息，物品信息，场景信息中提取特征的过程。
为什么需要提取呢？
因为在机器学习中，送进模型中的必将都是数值化的，所以需要将物理世界中的信息提取出来，这就是特征提取的过程-特征工程

那在特征工程中，需要面对的难题和宗旨是什么呢？

在物理世界中，信息存在的特点是：丰富甚至冗余。所以在特征提取的过程中，也就是将信息量化的过程中，必将带来一个问题，那就是信息的丢失，因为数字世界是无法完美表征物理世界的，这就是难题所在。
所以特征工程最大的宗旨是什么？
那就是抽取一组特征，让其最大限度的表征物理世界的所有信息，并尽可能的剔除冗余信息。

小例子引出特征工程应用

讲完特征工程的理解，下面开始举个例子，看看物理世界中的特征是如何被提取出来的。
假设有这么一个业务背景：给用户推荐喜欢的电影，这里如何提取信息构建用户画像呢？

从实际出发，判断一部电影是不是我们喜欢的，通常会有以下几点：

1.电影类型是否是我感兴趣的
2.电影是不是大片
3.导演和演员是否是我喜欢
4.海报是否吸引人
5.是否我看过该影片

在以上的5点中，进行特征工程其实就是挨个数字化的过程

1. 针对第一点，可以通过简单的统计频率来数字化，如根据用户对不同类型的电影的行为来得到用户每一个类型tag的分数情况：比如动作片45%，喜剧片30%，用得到的分数表示用户的兴趣指数。

2. 针对第二点，可以统计影片的热度来统计是否是大片，或者看看影片是否有大牌明星，又或者看看电影的制作经费等。

3. 针对第三点，和第1点一样，可以根据用户的历史行为，看对具体的导演和演员的一些行为情况的次数统计

4. 针对第四点，可以通过图像处理，提取图像内容，根据图像的内容判断是否是大片，比如利用图像检测，识别图像中的内容，识别明星是不是大牌明星等

5. 针对第五点，可以根据用户观看历史行为，判断是否看过

以上就是真实世界的信息量化的过程，也就是特征工程做的工作。任何的特征工程其实就是根据实际出发，将我们认为有用的信息提取出来。

为什么需要学习特征工程提取技术

  下面有一个问题了，在进行特征提取的时候，到底哪一些特征有用呢，比如为啥判断一个人是否喜欢的电影的时候，为什么会考察电影的类型，导演和演员等。你可能会说，不看这些看哪些呢，因为这些都是从实际的生活和业务理解出发。这是人们最真实的选择要考察的内容，所以还有啥好问的呢？但是你想想如果有一个东西你从没见过，你对其的生活经验几乎为0的时候，你就不知道该如何考察是否喜欢他的标准了哦。这时，大佬们就站出来了。

  大佬们为了我们入门方便，已经总结出了一个大致的特征选择方针，我们只需要在这些方面来进行特征量化，自然也就大差不差。下面总结以下推荐系统常用的特征

推荐系统常用特征

1. 用户行为数据

显性	对商品的打分，视频的打分，点赞，踩，对歌手专辑的评分等
隐性	点击，加入购物车，购买，浏览时长，播放时长，收藏，分享等

2. 用户关系数据

显性	好友关系
隐性	互相点赞，同一个社区，点赞同一篇文章，同看一部电影

3. 物品和用户属性，标签数据

用户	年龄，性别，住址，学历，工作年限（其他根据具体业务进行添加）
物品	一级分类，二级分类，年代，颜色，等

4. 物品描述内容数据

物品描述(所属一级分类二级分类等)，句子个数、文章长度等	nlp技术提取的关键词，主题，分类等

5. 场景信息(上下文信息)

场景	gps，ip获取地点，季节，月份，社会大事件等 ，是否工作日，网络情况、等

6.后验信息

物品后验信息统计	货源、统计(1h,3h,1d,3d的曝光量、总点击量、跳出率)
用户后验信息统计	统计（1h,3h,1d,3d浏览量，下单量等）

7.交叉信息

多特征交叉	时间段与一级分类的交叉，时间段与二 级分类的交叉等

特征工程的具体例子

  大多数的推荐场景中，基本上从以上的五点进行挖掘考虑，应该问题就不是很大。
下面举一个具体新闻推荐系统的例子，实际情况下大概的特征的结构如下

score的计算过程

我们来看看这个tag的score通常是如何计算得到的

  一般情况下，score的分数都是根据具体的业务来制定计算规则，下面以新闻推荐系统为例，看看score是如何计算的

首先给出两个符号的意义

符号	含义
c	点击量
e	曝光量
r	CTR点击率(等于 c/e)

进入正题，详解score的计算方式是如何一步步的进行改进的

  首先计算score，最开始想到的就是统计频率，也就是用简单的ctr来判断，比如体育的score，一个用户在体育这个标签下的score，就是计算系统在给用户曝光的体育相关的内容中，其实际所点击的比例。

score = c/e

  思考一下是否有问题？当然有，如果有一些体育的文章所有人都点击，那他其实就不能够很好的表征用户的喜好，只能说这篇文章比较热门而已，所以改进以下，诸如引入你文档频率。

score = c/e*idf

  以上的这个score本质上是可以采用TF-IDF 的思想进行统计得到，当然其他的任何热度惩罚的技术都是i可以采用的，这里的tf-idf只是灵机一动随意想的。
那继续改进，这次加入一些隐性信息，加入一些用户的行为信息，然后进行加权求和

score = c/e*idf + 收藏 x 权值1 + 点击 x 权值2 + 评论 x 权值3

  至于权值大小该如何给定呢？这就根据业务的理解自己给定了，很灵活，比如收藏可能表示用户很喜欢，权值就相对高一点。

诸如：权值1=5、权值2=1，权值3=3

  继续改进，现在想想，有些用户可能天然的会对有些tag有好感，比如一个24岁的男生，很可能会对体育更感兴趣，一个50岁的大叔可能会对历史更感兴趣，所以可以根据不同的用户对不同的tag给定一个初始的值base

score = base + c/e*idf + 收藏 x 权值1 + 点击 x 权值2 + 评论 x 权值3

这个base是根据业务需求自己随意diy设置的，下面我随意举个例子：

  现在看看，其实这已经能够应付大多数情况了，是不是已经改善得差不多了呢？改进的动机自然是看是否还有问题亟待解决。
  现在再仔细想一种情景，比如世界杯到来了，像我这种伪球迷为了赶赶气氛，赌赌球。自然对足球的兴趣迅速增加，如果利用上述的score计算公式来看，对足球的score也不会太高，因为时间太短了，用户对足球点击的比例相对整体来说还是太少。自然score不会高；当世界杯过去，用户的兴趣应该迅速降下来，但是同样的，用户的score依旧不能够很快降下来，因为短时间内任何事件的点击比例相对整体来说不会骤降和骤增。所以就出现一个问题就是：分数该高的时候不高，该低的时候不低，那咋整？
所以引入了一个ctr的变化率，这就好比考虑了加速度。虽然短时间内用户对这一类文章的行为数据很少，但是它的增长趋势很快(加速度\变化率)，那么这个分数也会很高。这样才比较合理。

score = base + c/e*idf + 收藏 x 权值1 + 点击 x 权值2 + 评论 x 权值3 +tag的c/e的变化速度

注：这个变化率：也很灵活，如果你想要反应更快，那么就把时间缩短，就好比北京奥如果只持续20天左右，那么你设置这个变化率的时候，时间基数就可以设置短一点，比如一天：那么计算变化率的时候：
变化率= (用户今天在这个分类下的点击数量 - 昨天用户在这个tag下的点击数量) / 用户昨天在这个tag下的点击数量

啊，最后再改进一波，就不改了，这次改的是ctr的计算上，ctr=c/e，这又有啥子问题咧？考虑这么几个问题：

1. 对于用户没有任何点击的tag该如何计算ctr呢？不可能粗暴给个0吧，不合适不合适；
2. 有一个tag曝光100次，点击50次；有一个tag曝光10000次，点击5000次，根据c/e那ctr都是0.5，显然不合理，明显曝光10000次的tag的可信度要高一些。

综上考虑，可以考虑改进ctr的计算方式：

ctr=(c+α)/(e+β)

贝叶斯平滑

上面的α和β就是一个超参数，具体该如何给定呢？这其实就是一个参数估计的问题，可以利用一切参数估计的方法进行估计，推荐算法上常用的就是贝叶斯估计。由于点击率天然符合beta分布，所以只需要用贝叶斯估计估计出参数即可，利用这样方式对点击率进行修正的方法也叫做贝叶斯平滑。具体的估计过程不讲了，直接给出两个公式：

这里的X表示用户这一段时间以来的平均点击数量，S表示点击数量的方差。

实际工程示例

  在实际工程中，如果画像是一周一更新，那么可以在每天的数据中计算每件商品或广告的点击率，之后求出这些点击率的均值和方差，带入公式(9)和公式(10)，可以得到每天的α 和β 最后求这段时间α和β的均值作为最终的平滑参数。
如果画像是一天一更新的话，那么就拿前一天的点击率数据，通过计算均值和方差，然后带入公式求得参数。

所以最终改进后的score的计算逻辑为：

score = base + (c+a)/(e+b)*idf + 收藏 x 权值1 + 点击 x 权值2 + 评论 x 权值3 + tag的c/e的变化速度

以上就是特征的开发和score的计算

现在已经学会了特征工程的开发了，开始引出另一个问题了哦

用户画像的生命周期

  什么是生命周期呢，通俗理解就是你的用户画像是要用多少天来更新呢，比如要用前30天的数据来跟新，30天就是生命周期，这是最朴素的生命周期的理解，当然这里对生命周期的理解其实更宽泛，

现在想想，有了以上的score就能准确把握用户的喜好吗？显然差点意思，比如世界杯这种，不管是否考虑了变化速率，其分值的变化占比依旧很小。所以改进的办法是什么呢，那就是制作多个用户画像：通常分为短期画像，中期画像，长期画像。

画像类型	更新周期(主观制定)
短期画像(表示近期的兴趣点)	3-6小时
中期画像(表示一直来的兴趣点)	3天-1个月
中期画像(表示更长期的兴趣点)	1-3个月

以上的更新周期其实是很主观的，可以根据自己的业务来制定更新周期。

画像存储

以上算是搞定了所需要计算的画像以及计算原理，所以最后当然就是如何存储提取好的特征？

通常是Hive+redis/Hbase的存储方式，下面是所存储的位置和具体的目的。

画像存储位置	目的
所有画像都应该在Hive存储一份	用户模型的训练
另一份应该存在redis/Hbase中，其中短期画像通常存在redis中，中期和长期通常存在Hbase中	提供实时消费

题外思考

以上讲了画像的具体开发过程，根据每个人的行为计算出了每一个tag的分值，但是这种千人千面的计算量
实在太大了，很难落地哦，那如何思考改进呢？

1.千人一面：简单利用文章的热度信息；
2.千人白面：先给用户分群，可以在用户画像或者embedding上，通过聚类或者哈希等给用户分群，然后
在再小群体上计算具体的score。

讲完了，累，再见。