[落选]2021微信大数据挑战赛

滑窗提取特征：

首先是滑窗提取特征，即过去N天内，看过多少视频、点赞多少视频等等

baseline当中Ｎ取的是5，后续参考其他文献等改为7，有提升

这里的时间粒度都是天，也就是说，如果用户在当天内重复观看某条视频，那他只有一条数据行，只是在is_finish列为1，而在play_times列可能是2或者其他，在play列的时长要超过视频的时长videoplayseconds。但如果用户在另一天重复观看此视频，则会是一条新的数据行。两种情况的数据行在userid、feedid、authorid等列都保持一致，但在date_列则是两个数值。下面的计不计人重复，一般都是对当天内的重复观看的情况而言的。

然后这些滑窗的特征如下：

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

曝光数据
- 该用户看过多少个视频
  
  在天的尺度内，计量单位是个，也就是说当用户在某天内观看某个视频两次，在这里仍旧被记作一次，但如果在另一天再次观看，则被记为两次，下同
- 该视频被多少个人播放
- 该作者被多少个人播放
- 该用户看过该作者多少个视频
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

转化数据
- 该用户看完的视频个数在看过的视频个数当中的占比
  
  即对标记是否完整观看的is_finish列进行求平均，即为完成率
- 该视频被看完的次数在被看到的次数当中的占比
  
  此处同样不计入当天内的重复观看，同样对is_finish列进行求平均
- 该作者被看完的次数在被看到次数当中的占比
  
  同上
- 在该用户观看过的该作者的视频当中，看完的百分比
  
  同上
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
- 对于每个用户而言
  - 对其在过去N天观看单个视频的次数，play_times列
    
    此处计入当天内的重复观看的次数，即对同一个视频反复观看
    - 求平均
    - 求最大
  - 对其在过去N天对单个视频的观看时长，play列
    
    此处计入当天内的重复观看的情况，即观看时长超出视频时长的情况
    - 求平均
    - 求最大
  - 对其在过去N天在单个视频的停留时长，stay列
    - 求平均
    - 求最大
- 对于每个视频而言
  - 对其在过去N天被观看的次数，play_times列
    
    此处计入当天内重复观看的情况，即对同一个视频反复观看
    - 求平均
    - 求最大
  - 对其在过去N天被观看的时长，play列
    
    此处计入当天内重复观看的次数，即观看时长超出视频时长的情况
    - 求平均
    - 求最大
  - 对其在过去N天的停留时长，stay列
    - 求平均
    - 求最大
- 对于每个作者而言
  
  同上
- 每个观看过的每个作者
  
  同上
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
- 对每个用户而言，在过去N天内
  - 其点赞的视频数量的
    - 求和
    - 平均
  - 其查看评论的视频数量的
    - 求和
    - 平均
  - 其点击头像的视频数量的
    - 求和
    - 平均
  - 其转发的视频数量的
    - 求和
    - 平均
- 对每个视频而言，在过去N天内
  - 其点赞的数量的
    - 求和
    - 平均
  - 其查看评论的数量的
    - 求和
    - 平均
  - 其点击头像的数量的
    - 求和
    - 平均
  - 其被转发的数量的
    - 求和
    - 平均
- 对每个作者而言，在过去N天内
  
  同上
- 每个用户对每个作者，在过去N天内
  
  同上

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

全局提取特征

这里针对的是用户的所有历史数据。由于baseline当中在开头就把测试集和训练集放在一起做特征工程，所以这里其实统计的是过去15天的历史数据，即包含了将要预测的第15天的观看次数等。

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

曝光数据

此处计入不同日期的重复观看的情况
- 用户一共看过几个视频
- 该视频一共被多少人看过
- 该作者的视频一共被多少个人看过
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

用户与视频
- 对于每个用户而言，在所有历史数据当中，其看过几个视频
  
  此处不计入不同日期的重复观看，在所有历史数据意义上的个
- 对于每个视频而言，在所有历史数据当中，其被几个用户看过
  
  此处同样不计入重复，同上
用户与作者
- 对于每个用户而言，在所有历史数据当中，其看过几个作者
  
  此处不计入不同日期的重复观看，在所有历史数据意义上的个
- 对于每个作者而言，在所有历史数据当中，其被几个用户看过
  
  此处同样不计入重复，同上
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

用户与作者
- 用户在某一天内看某个作者多少次
  
  即按照userid和authorid进行groupby之后，对date_列进行计数。假设这种情况下，10在date_列出现两次，即意味着用户在第10天看过该用户2次。
- 用户看过的该作者作品在该作者所有作品当中的占比
  
  此处分母上有+1，不要清楚有什么作用，为了防止分母出现0?
- 用户看过的该作者作品，在该用户看过所有视频当中的占比
  
  此处分母上有+1，不要清楚有什么作用，为了防止分母出现0?同上
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
- 用户观看过视频的平均时长
- 作者创作视频的平均时长
- 作者创作过几个视频
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

改进-0

其实这个不算改进吧，就使用optuna⁴⁵对baseline进行了调参，大概上升了0.03%？

然后后面就没啥用了，可能是我代码的问题，做了新的特征之后调出来的参数竟然和之前一致，没有变化

改进-1

参考了文章⁶⁷，对特征进行改进

其实也就是在相应的for循环当中加入了新的特征列名

baseline当中，滑窗类的特征主要做了以下四个：

用户
视频
作者
用户对作者

在上面的基础上追加特征：

背景音乐
背景音乐的歌手
用户对背景音乐
用户对背景音乐的歌手

在全局特征当中追加：

+++++++++++++++++++++++++++++

曝光数据

背景音乐被播放几次
歌手被播放几次

+++++++++++++++++++++++++++++

与用户与视频和用户与作者相并列的特征

用户与音乐

用户听过多少次这个音乐
这个音乐被多少个用户听过

用户与歌手

用户听过多少次这个歌手
歌手被多少个用户听过

+++++++++++++++++++++++++++++

与第二个用户与作者相并列的特征

用户与音乐

用户在某一天内看某个音乐多少次
用户看过的该音乐在该作者所有作品当中的占比

此处分母上有+1，不要清楚有什么作用，为了防止分母出现0?
用户看过的该音乐，在该用户看过所有视频当中的占比

此处分母上有+1，不要清楚有什么作用，为了防止分母出现0?同上

用户与歌手

同上

+++++++++++++++++++++++++++++

改进-2

加入device的特征，感觉这个没啥用

同时将全局特征的统计限定在前14天，也就是不统计测试集的观看数据

后来想想不太对，这个地方其实应该统计全部15天包含测试集的数据

是这样的，真实情况下，我们不知道第15天的行为对应的标签

也就是说，当我们去做推荐的时候，用户还没有对这个视频产生交互

但是在打比赛的时候不一样，打比赛的时候已经有标签了

那也就意味着，测试集当中的数据，应该是发生过的

是属于用户画像的一部分的

+++++++++++++++++++++++++++++

在时间滑窗当中加入：

设备，device
设备对作者
设备对歌曲
设备对歌手

+++++++++++++++++++++++++++++

在曝光当中加入：

设备，device

+++++++++++++++++++++++++++++

相应加入：

设备对视频

该型号看过几个个视频
该视频被几个型号的看过

设备对作者

同上

设备对歌曲

同上

设备对歌手

同上

+++++++++++++++++++++++++++++

设备与作者

设备在某一天内看某个作者多少次
设备看过的该作者作品在该作者所有作品当中的占比

此处分母上有+1，不要清楚有什么作用，为了防止分母出现0?
设备看过的该作者作品，在该设备看过所有视频当中的占比

此处分母上有+1，不要清楚有什么作用，为了防止分母出现0?同上

设备与歌曲

同上

设备与歌手

同上

+++++++++++++++++++++++++++++

改进-3

加入embedding

使用word2vec对keyword和tag进行编码，生成32维的向量，作为视频的特征数据
使用pca将feed_embeddings降维到32
对以词为单位的description、ocr、asr使用word2vec生成32维的向量，并计算两两之间的差距

改进-4

对以字为单位的description、ocr、asr使用word2vec生成32维的向量，并计算两两之间的差距
尝试统计用户点赞过、评论等操作的视频抽取其特征，形成用户的兴趣特征。但没有成功

结果

A榜当时好像0.659吧？我印象还在0.66挣扎，就差一点，B榜根本没提交

周周星³也用单模的树模型，都能干到0.675

参考

她来了她来了，乘风破浪的微信视频号推荐算法⁸
微信视频号推荐算法挑战赛baseline分享⁹
微信大数据挑战赛：LightGBM vs DeepFM¹⁰

更新

OTTO队伍的树模型方案，https://github.com/juzstu/WBDC2021_Tree_Solution

江离的方案，https://github.com/ji1ai1/202105-WEIXIN

关于NetworkX，用图构建用户和视频的关系，做协同过滤

定量分析方法第17讲：NetworkX基础

特征工程之tag-pooling，以微信大数据比赛数据为例

这个我好像用的是第二种方式，word2vec对每个视频的tag进行embedding之后求平均

微信大数据竞赛Trick–如何3ID上0.706+

这里好像是按照视频对用户进行groupby，将每个视频的观看用户理解为文档，将视频列表理解为文档列表，对用户进行TFIDF编码，然后使用TruncatedSVD降维。

该特征的本质就是希望找到基于视频的用户共现性，如果某些视频某些用户总是一起出现，那么就说明这些用户大概率有相同的爱好，就很可能一起转发，一起评论并且同时关注了。

下面这两个也有使用这个方法

中科大倪茹：感谢开源，我从入门竞赛到Top 10的经验分享

2020DCIC智能算法赛-智慧海洋建设TOP1方案

微信大数据挑战赛 ↩︎
[某比赛的baseline/线上0.63/Lightgbm] ↩︎
6.14周周星（第一名）分享 ↩︎ ↩︎
席卷Kaggle的调参神器，NN和树模型通吃！ ↩︎
【机器学习】Optuna机器学习模型调参(LightGBM、XGBoost) ↩︎
微信视频号推荐算法解题思路 ↩︎
微信大数据比赛我用树模型怎么从514到671 ↩︎
她来了她来了，乘风破浪的微信视频号推荐算法 ↩︎
微信视频号推荐算法挑战赛baseline分享 ↩︎
微信大数据挑战赛：LightGBM vs DeepFM ↩︎