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

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

一、简介

我在2017年10月至12月参加该比赛,最终排名是 42/2845。写本文的目的,其一是总结与记录本次比赛的实现,其二是反省自身,因为我觉得自己对待比赛的态度有点消极,在连续很多天没有新进展的情况下,逐渐进入了弃疗的状态,尤其是后期乏力,没有竭尽全力,这绝对是不应该的,既然决定了参加比赛就应该有始有终。写下此文,以作警示。


二、赛题

2.1 赛题简介

赛题详情可以参考这里。赛题的业务背景是各大商场中用户使用支付宝消费的常见现象,然而有时候存在着消费店铺信息丢失等问题。赛题为我们提供了过去一段时间内(2个月)500个商场的消费记录,包含用户行为与商铺信息等,要求我们预测接下来一段时间(2周)内的消费记录对应的真实商铺。显然,这是一个分类任务,既可以处理成多分类,也可以处理成二分类。

2.2 提供特征

2.2.1 提供特征

赛题提供的原始特征字段包含两方面:用户在商铺的消费记录(包含WIFI、位置等),商铺信息(位置、类别、消费水平等)。复赛样本量大概在1000w左右。

消费记录
序号 字段 描述
1 user_id 用户ID
2 shop_id 商铺ID
3 time_stamp 消费行为时间戳,例如:2017-08-06 21:20
4 longitude 行为发生时位置-经度
5 latitude 行为发生时位置-纬度
6 wifi_infos 行为发生时Wifi环境,包括bssid(wifi唯一识别码),signal(强度),flag(是否连接)

wifi_infos 例子:
b_6396480|-67|false;b_41124514|-86|false;b_28723327|-90|false;

解释:以分号隔开的WIFI列表。对每个WIFI数据包含三项:b_6396480是脱敏后的bssid,-67是signal强度,数值越大表示信号越强,false表示当前用户没有连接此WIFI(true表示连接)。

商场商铺信息
序号 字段 描述
1 shop_id 店铺ID
2 category_id 店铺类型ID,共40种左右
3 longitude 店铺位置-经度
4 latitude 店铺位置-纬度
5 price 人均消费指数
6 mall_id 店铺所在商场ID

2.2.2 评估方式

  • 预测正确:给出的shop_id和标准答案的shop_id相等。

P=CN

其中P表示准确率,C表示预测正确样本数,N表示样本总量。
注意,若某些样本没有给出结果,那么也会被当成错误识别。

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接受这样的输入。

阅读更多
想对作者说点什么? 我来说一句

没有更多推荐了,返回首页