阿里天池（蚂蚁金服）商场中精确定位用户所在店铺经验分享

阿里天池（蚂蚁金服）商场中精确定位用户所在店铺经验分享

一、简介

我在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相等。

其中$P$表示准确率，$C$表示预测正确样本数， N N <script type="math/tex" id="MathJax-Element-80">N</script>表示样本总量。
注意，若某些样本没有给出结果，那么也会被当成错误识别。

2.2.3 关于赛题数据的思考

1. 问题理解
   问题可以理解为分类任务，既可以作为多分类（每个样本对应的商铺即为真实类别），也可以构造为二分类（构造每个样本对应的商铺为正例，其他商铺为反例），不管哪一种，都需要分商场（mall）来做，即可以认为各商场之间是相互独立的。从另一个角度看，这实际上要求我们构建一个推荐系统，为用户推荐他最可能去的商铺。
2. 可能需要的数据处理
   
   • 首先，样本的本质是消费记录，消费记录可能存在伪造现象。
   • 其次，商铺的消费者中，新用户居多，即冷启动可能相对严重。
   • 第三，WIFI环境复杂，可能存在数值不准，可能有特殊WIFI，比如个人热点。
3. 特征提取方向
   题目提供的信息其实并不多，特征的选择方向主要有两个，其一是围绕各商铺作出的统计，其二是围绕消费时的WIFI环境列表作出的统计。两者的核心都是去构造样本与商铺的表达，并找出它们的联系，比较它们的距离，从而做出分类或推荐。
4. 模型的选择
   作为一个分类任务，典型的方法无非梯度提升树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数量较少的商场mall中，各商铺的空间分布，根据经纬度绘制。

  • 部分shop位置非常接近，甚至经纬度重合，推测是上下楼层关系
  • 存在远离大部分shop的噪声点，因此经纬度不完全准确
    

• 商铺与用户之间的空间关系
  以下是某商场中各商铺与用户之间的关系，看不清请谅解。紫色的圆点表示商铺，红色的x表示用户的位置，绿色的线将用户与他们消费发生的店铺（label）连接起来。

  • 用户在空间上并非呈现围绕着标签shop分布的规律
  • 存在大量位置看起来不正常的用户（通过经纬度计算距离店铺上百公里）

5.3 模型的误判

• 模型的误判分布
  商场m_1085的模型（GBDT）误判情形可视化如下，红色的点表示商铺，绿色的x表示消费者，青色的线连接消费者与正确的Label，红色的线表示模型的误判。
  
  • 误判样本时间戳基本上是饭点
  • 交易的相关特征（地理位置、时间戳）相近
  • 误判商店的性质接近（类别、消费水平、历史样本量等）

• 正确率偏低的商铺
  下图给出了几个模型正确率特别低的商场mall
  
  以其中最低的m_6803为例，分析其误判严重的原因。

  • 1. 商场冷启动
    大量商铺在训练集中从未出现，而在测试集中大量出现。大部分的错误由此产生。
    

  • 2. 样本太少学不到东西，无从判断
    

  • 3. 有东西学，也有误判，但是top3中都有
    

  • 4. 有东西学，但确实误判了，top3也救不了
    

• 商铺样本的时间分布
  以下是商场m_7168中两个相互误判最为严重的商铺的历史消费记录的时间戳分布。
  

总结一下，造成商场中各商铺之间误判严重的原因如下，也就是说提取的特征不足以提供足够的区分性，导致不可分。

（1）经纬度坐标接近
（2）商店类型相同
（3）训练集样本量接近
（4）样本时间戳分布相近（每天都有，而且每天分布一致）
（5）wifi 特征分布接近（bss重合度高）
（6）用户冷启动（大多是第一次来，没有历史信息可供参考）

六、比赛的难点

本次比赛的难点主要在于线上赛难以复现线下赛的各种操作。

1. 不能写循环
   线下赛采取分mall多分类的方法，线上赛很难复现，因为SQL不能写循环，要写出500个mall的多分类脚本。解决方法：用python写了文本替换，生成了500个mall的特征生成和训练sql。
2. Union报错
   线上赛三个树模型中只有PSSMART支持多分类，跑起来特别慢。解决方法：把mall的代码分到16个窗口，同时跑，最后Union，但是平台UNION的对象个数过多会莫名报错，所以先小部分union后，在总体union。
3. 复杂特征提取
   wifi_id的离散化（onehot），希望只取出强度舍弃连接。线下赛可以用字典写循环assign，线上赛不能。
   解决方法：用官方提供的SDK写了个MapReduce，提交到平台上作为工作流结点。输入是 row_id : mall_id : WIFI_info，mapper将row-mall-bss做key，mW-connect做value，reducer不做聚合，而是将他们分成5列，最终输出row-mall-bss-mW-connect的大幅扩充过的样本（每条样本扩充为WIFI列表长度），然后送给PAI平台生成kv表，得到row-mall-{bss:mW;vss:mW}这样的kv格式，PSSMART接受这样的输入。