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

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

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

文章目录

• • 特征工程的概念
  • • 小例子引出特征工程应用
    • 为什么需要学习特征工程提取技术
  • 推荐系统常用特征
  • 特征工程的具体例子
  • • • score的计算过程
    • 贝叶斯平滑
    • • 实际工程示例
  • 用户画像的生命周期
  • 画像存储
  • 题外思考

特征工程的概念

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

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

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

小例子引出特征工程应用

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

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

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

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

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

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

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

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

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

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

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

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

推荐系统常用特征

1. 用户行为数据

2. 用户关系数据

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

4. 物品描述内容数据

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

6.后验信息

7.交叉信息

特征工程的具体例子

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

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

注：这个变化率：也很灵活，如果你想要反应更快，那么就把时间缩短，就好比北京奥如果只持续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的计算方式：

贝叶斯平滑

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

实际工程示例

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

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

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

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

用户画像的生命周期

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

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

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

画像存储

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

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

题外思考

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

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

讲完了，累，再见。

文章知识点与官方知识档案匹配，可进一步学习相关知识算法技能树首页概览33977 人正在系统学习中