我在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，线上赛不能。