问题概述
先来看看这冗长的赛题说明1
baseline
最早是参考麻婆豆腐AI2的baseline，跑了一遍。
这份代码用了LabelEncoder、OneHotEncoder，好像没做特征工程，直接丢进去了
后来在周周星的分享上找了一个baseline3，结构相对来说更清晰一点，就按照这个改进。
先聊一下这份代码的基础特征吧
详细描述如下：
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
-
滑窗提取特征：
首先是滑窗提取特征，即过去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
其实这个不算改进吧，就使用optuna45对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榜根本没提交
周周星3也用单模的树模型，都能干到0.675
参考
更新
OTTO队伍的树模型方案，https://github.com/juzstu/WBDC2021_Tree_Solution
江离的方案 ，https://github.com/ji1ai1/202105-WEIXIN
关于NetworkX，用图构建用户和视频的关系，做协同过滤
这个我好像用的是第二种方式，word2vec对每个视频的tag进行embedding之后求平均
这里好像是按照视频对用户进行groupby，将每个视频的观看用户理解为文档，将视频列表理解为文档列表，对用户进行TFIDF编码，然后使用TruncatedSVD降维。
该特征的本质就是希望找到基于视频的用户共现性，如果某些视频某些用户总是一起出现，那么就说明这些用户大概率有相同的爱好，就很可能一起转发，一起评论并且同时关注了。
下面这两个也有使用这个方法
560
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
