我在2017年10月至12月参加该比赛,最终排名是 42/2845。写本文的目的,其一是总结与记录本次比赛的实现,其二是反省自身,因为我觉得自己对待比赛的态度有点消极,在连续很多天没有新进展的情况下,逐渐进入了弃疗的状态,尤其是后期乏力,没有竭尽全力,这绝对是不应该的,既然决定了参加比赛就应该有始有终。写下此文,以作警示。
2.1 赛题简介
赛题详情可以参考这里。赛题的业务背景是各大商场中用户使用支付宝消费的常见现象,然而有时候存在着消费店铺信息丢失等问题。赛题为我们提供了过去一段时间内(2个月)500个商场的消费记录,包含用户行为与商铺信息等,要求我们预测接下来一段时间(2周)内的消费记录对应的真实商铺。显然,这是一个分类任务,既可以处理成多分类,也可以处理成二分类。
2.2 提供特征
2.2.1 提供特征
赛题提供的原始特征字段包含两方面:用户在商铺的消费记录(包含WIFI、位置等),商铺信息(位置、类别、消费水平等)。复赛样本量大概在1000w左右。
消费记录
wifi_infos 例子:
b_6396480|-67|false;b_41124514|-86|false;b_28723327|-90|false;
解释:以分号隔开的WIFI列表。对每个WIFI数据包含三项:b_6396480是脱敏后的bssid,-67是signal强度,数值越大表示信号越强,false表示当前用户没有连接此WIFI(true表示连接)。
商场商铺信息
2.2.2 评估方式
- 预测正确:给出的shop_id和标准答案的shop_id相等。
其中表示准确率,表示预测正确样本数,<script type="math/tex" id="MathJax-Element-80">N</script>表示样本总量。
注意,若某些样本没有给出结果,那么也会被当成错误识别。
2.2.3 关于赛题数据的思考
- 问题理解
问题可以理解为分类任务,既可以作为多分类(每个样本对应的商铺即为真实类别),也可以构造为二分类(构造每个样本对应的商铺为正例,其他商铺为反例),不管哪一种,都需要分商场(mall)来做,即可以认为各商场之间是相互独立的。从另一个角度看,这实际上要求我们构建一个推荐系统,为用户推荐他最可能去的商铺。 - 可能需要的数据处理
- 首先,样本的本质是消费记录,消费记录可能存在伪造现象。
- 其次,商铺的消费者中,新用户居多,即冷启动可能相对严重。
- 第三,WIFI环境复杂,可能存在数值不准,可能有特殊WIFI,比如个人热点。
- 特征提取方向
题目提供的信息其实并不多,特征的选择方向主要有两个,其一是围绕各商铺作出的统计,其二是围绕消费时的WIFI环境列表作出的统计。两者的核心都是去构造样本与商铺的表达,并找出它们的联系,比较它们的距离,从而做出分类或推荐。 - 模型的选择
作为一个分类任务,典型的方法无非梯度提升树GBDT,典型的工具无非xgboost和LightGBM。而赛题提供的ID类字段偏多,Onehot处理后使用LR或FFM也是考虑的范围。
考虑到复赛是平台赛,能用的方法应该以树模型及其bagging融合为核心,stacking为辅助选择。
我们这次的特征工程做的是不合格的,基本上只用到了Onehot编码过的WIFI列表,以及一些零星的特征。下面这个列表给出了用到了特征概述。可以看到里面有“候选shop”字样,这个东西与我们的模型有关,放到模型部分讲。总体而言,我们提的特征太少,这实际上也是后面成绩提不上去的原因,毕竟特征决定了模型能达到的上限。
WIFI特征
- WIFI强度Onehot后将dB转为mW
- 记录中是否有连接的wifi记录
- 记录中是含否有null(并且null处理为均值)
- WIFI列表排序位置(如最强、第二强、第三强…)上的bss_id在历史上出现过的总次数、候选shop在其中的占比
- 连接的bss_id在历史出现的总次数、候选shop在其中的占比
商店特征
- 商店经纬度
- 商店所在mall的总人流量、shop人流量在其中的占比
- 商店所在mall每小时人流量、shop每小时人流量在其中的占比
用户特征
- 消费时的经纬度
- 在候选shop的消费次数
- 与候选shop位置的GPS距离(L2)
- 与候选shop历史记录中心位置的GPS距离(L2)
- 与候选shop对应wifi信号强度的距离(L1、L2)
模型是我一直参与的部分,全程我一共尝试过四种模型:KNN、LR、梯度提升树单模型以及基于树的stacking。原本队伍并没有用提升树模型,直到我在出远门前往gitlab上传了一份未经调参的LightGBM训练代码,跑完之后惊觉成绩骤升,随后开启了调参之路。
4.1 KNN
核心思想是,各样本用Onehot过的WIFI向量进行表征,各商铺用历史样本作为表征,通过计算样本到商铺的距离,使用KNN,简单地取最近邻为预测商铺。距离度量使用过余弦距离和欧氏距离,欧氏距离更优。最终准确度与覆盖率(K=5的KNN中,前5位商铺包含真实标记)不及提升树,最终弃用。效果不佳的原因,我猜测是WIFI强度不准,欧式距离度量不准。
4.2 LR
核心思想是,将Onehot过的ID类(包含WIFI以及原始ID类字段)作为LR的输入,并让LR实现多分类。效果不佳(比不上树模型),猜测原因是提取的特征不够多,没有提供足够的区分性(许多不同类样本具有高度相似性)。
4.3 GBDT
主要使用工具为LightGBM和XGBoost,对于不同商场将店铺预测当成多分类任务训练,两个工具的准确度相近,但LightGBM比XGBoost快得多,后面仅仅利用调参成功地提升了2个百分点(从0.89到0.91级别),所调参数主要为抑制树模型过拟合的参数(例如min_data_in_leaf, feature_fraction等)。
4.4 二阶段Stacking
Stacking模型分为两个阶段,一阶段是多分类方案,旨在构造候选shop,二阶段是二分类方案,用于模型预测,本方法需要同时兼顾候选的覆盖率和预测的准确率。
- 首先,在第一阶段利用LightGBM实现分mall的多分类任务,并输出各shop概率,得到每个用户最可能去的前5个shop作为候选shop,覆盖率(5个候选shop包含真实标签)大概有96%。
- 然后,在第二阶段,将每一个测试样本扩充5行,每一行对应候选shop,拼接上shop的相关特征,并将真实shop打上正例的标签,作为二分类任务给LightGBM训练。
实际上,模型的扩充操作导致样本不均衡的问题(5比1),因此应该进行下采样的(保留正样本,随机抽取负样本),这样甚至可以训练多几个模型融合。
在之前的比赛中,我意识到一个问题,数据的观测与分析是非常重要的,因此在本次比赛中我花了较多的时间在这上面,主要使用的工具是matplotlib和mysql。原本企图找到一些线索,从而为队友提出更多的特征或者trick,然而最终并没有找到太多有价值的东西,以至于没有做出过多贡献。但是我不认为这是无用功,反而是每一场比赛都必须的,即使不能从中发现规律,也能提升对数据的理解,意识到模型的问题所在。
5.1 找出异常样本
使用sql进行统计可以很快地发现样本中的异常。
- 恶意刷单
统计各用户单月消费记录得到,有部分用户在一个月内在同一间店铺消费了400多单,在这么一个大多数用户都只在某商铺消费过1到2次的大环境下,这样的用户只能被认为是刷单的了。我们的处理是直接去除。 - 单值WIFI
部分WIFI列表中只有一个WIFI bss。 - 个人热点WIFI
在众多WIFI bss中,存在大量只出现过几次的bss,显然不可能是商铺中固有的WIFI热点,而很可能是其他消费者开启的热点(可以到大商场里打开手机WIFI列表看看,确实能搜到很多别人的热点)。我们的处理是去除出现次数低于20的WIFI bss(相当于降维)。 - WIFI缺失
WIFI列表中的强度字段为null,这个现象在复赛中特别严重,我们的理解是这些用户都是苹果手机或者没有root权限的安卓手机,支付宝没有权限获取信号强度。我们的处理是将null替换为均值。
5.2 用户和商铺的空间关系
原本企图通过空间关系,尝试基于距离还原出WIFI热点的空间分布,然而经过数据的可视化发现经纬度的可信度并不高。
-
- 用户在空间上并非呈现围绕着标签shop分布的规律
- 存在大量位置看起来不正常的用户(通过经纬度计算距离店铺上百公里)
5.3 模型的误判
- 模型的误判分布
商场m_1085的模型(GBDT)误判情形可视化如下,红色的点表示商铺,绿色的x表示消费者,青色的线连接消费者与正确的Label,红色的线表示模型的误判。
- 误判样本时间戳基本上是饭点
- 交易的相关特征(地理位置、时间戳)相近
- 误判商店的性质接近(类别、消费水平、历史样本量等)
总结一下,造成商场中各商铺之间误判严重的原因如下,也就是说提取的特征不足以提供足够的区分性,导致不可分。
(1)经纬度坐标接近
(2)商店类型相同
(3)训练集样本量接近
(4)样本时间戳分布相近(每天都有,而且每天分布一致)
(5)wifi 特征分布接近(bss重合度高)
(6)用户冷启动(大多是第一次来,没有历史信息可供参考)
本次比赛的难点主要在于线上赛难以复现线下赛的各种操作。
- 不能写循环
线下赛采取分mall多分类的方法,线上赛很难复现,因为SQL不能写循环,要写出500个mall的多分类脚本。解决方法:用python写了文本替换,生成了500个mall的特征生成和训练sql。 - Union报错
线上赛三个树模型中只有PSSMART支持多分类,跑起来特别慢。解决方法:把mall的代码分到16个窗口,同时跑,最后Union,但是平台UNION的对象个数过多会莫名报错,所以先小部分union后,在总体union。 - 复杂特征提取
wifi_id的离散化(onehot),希望只取出强度舍弃连接。线下赛可以用字典写循环assign,线上赛不能。