IJCAI-17口碑商家客流预测实战：特征工程与模型选型全解析

简介时间序列预测是机器学习中最贴近业务场景的课题之一其核心难点往往不在模型结构而在于如何从充满噪声的真实数据中提取有效特征。客流量预测作为典型的多源数据融合问题既包含历史时序信息又涉及商家属性、POI空间特征和节假日脉冲效应对特征工程能力提出了极高要求。本文以IJCAI-17口碑商家客流量预测赛题为背景系统梳理了从基线模型到滚动窗口统计、目标编码、冷启动处理、时间序列验证等关键环节的实践经验并解释了为什么LightGBM等GBDT模型在结构化数据上通常优于纯序列模型。通过合理的特征体系构建与严格的时间隔离验证模型能够在商超、餐饮等本地生活场景中准确预估未来14天客流趋势为库存管理、营销排期提供决策支持。文章最后总结了时间泄漏、节假日失真等高频踩坑点为从事真实业务预测的开发者提供一份可复用的工程检查清单。 IJCAI-17口碑商家客流量预测是我当年认认真真跟完的一场机器学习比赛。如果你正在学机器学习想做点真实项目而不是天天跑教程里那些干干净净的样例数据这个赛题是个特别好的突破口。比赛由阿里口碑在IJCAI 2017上主办目标是利用口碑平台脱敏后的商家历史客流、商家属性、用户行为以及周边兴趣点信息预测每一个商家在未来连续14天里每天的客流量。我刚拿到题目的时候第一反应是“这不就是一个时间序列预测嘛上LSTM不就完了”。后来做进去才发现真正磨人的不是深度学习模型怎么调而是怎么把一个充满噪声、店铺形态五花八门的真实业务数据变成模型能理解的样本。这个赛题数据既有时间维度的历史客流又有商家静态属性和POI空间信息还得考虑节假日、天气、商圈效应这些外部因素。对想把机器学习从理论推向实战的人来说它是一个非常全面的训练场。这篇就把我当时从baseline到特征工程、从模型选型到各种踩坑的经验整理出来希望对后来者有点帮助。1. 赛题背景与核心问题拆解1.1 IJCAI-17口碑赛到底要做什么先把这个赛题的任务说清楚。官方提供了一批口碑平台商家的历史数据包括商家在一段历史时间内的每日客流量还有商家的类别、城市、价格带、评分等静态信息以及用户在商家内的浏览行为记录。参赛者需要预测这些商家在未来14天内每天的客流量到底是多少。初看就是“历史序列预测未来序列”但有几个细节让问题复杂得多。第一店铺不是同时出现的不同商家有各自的营业记录有些店铺在预测期之前才开张历史数据特别短。第二客流量这个数值非常“毛”有的店一天几千人有的店一天三五个人还有不少日子是0数据分布严重右偏。第三客流不单是时间序列它受到太多外部因素影响周末和工作日规律不同、节假日有脉冲效应、天气好坏直接改变出门意愿、所在商圈的人气也决定基础流量。所以这个赛题事实上是个多源数据融合的结构化预测问题而不是单纯的序列预测。我见过很多队伍一开始拿LSTM硬上效果反而不如把特征做好之后用GBDT类模型原因就在于这个问题的信号非常分散时间序列只是其中一部分大量有效信息藏在商家的空间和属性特征里。1.2 客流量预测的商业价值在哪讲技术之前先说说这个赛题为什么值得做。客流量预测对本地生活服务平台来说是刚需。平台要做优惠券发放、广告位排期、商家运营诊断都需要提前知道一个店未来的客流趋势。如果系统能提前判断某家店下周客流会明显上涨平台就可以提前建议商家备货、增加排班也能把营销资源投到最需要拉动的店铺上。对商家来说客流预测更直接关系到成本和收入。餐饮店要根据客流准备食材奶茶店要根据客流排班理发店要根据客流决定是否搞活动。预测准了既能避免高峰期接待不过来也能减少淡季的食材浪费。从商业角度看这个模型哪怕只比拍脑袋准10%带来的成本节省和营收提升也是实实在在的。这也是这个赛题和很多纯算法竞赛的本质区别它的评价指标是RMSE但业务落地时真正关心的是“趋势判断准不准”和“波动提醒及不及时”。理解了这一点你就明白为什么特征工程比模型结构更影响最终结果因为业务场景里的天气、节假日、商圈变化这些信息只能靠特征进到模型里。1.3 为什么这个赛题是机器学习的试金石说句实在话这个赛题放在今天来看依然不过时因为它踩中了机器学习项目里最核心的几个痛点。一是数据不干净店铺客流有大量缺失和异常值你不能像处理教科书数据那样直接丢进模型。二是特征来源多样既要做时序统计又要处理离散属性还要融合空间POI这对特征工程能力的锻炼非常充分。三是时间序列验证有讲究用普通的随机交叉验证会翻车必须按照时间顺序切分这个意识很多人是到这个赛题才建立的。另外这个赛题非常适合拿来检验一个人的综合能力。你不仅要会调库跑模型还要会写特征、做交叉验证、排查线上线下不一致的问题。如果你能把这场赛题从头到尾做明白基本上就具备了处理常见结构化数据竞赛的能力。接下来我就按当时做项目的真实流程从数据、特征、模型、实战细节这几个维度展开聊。2. 数据理解与特征工程体系2.1 先摸清数据家底字段与形态做特征之前先把数据看明白非常重要。当时拿到的数据主要分成几块商家属性表包含商家的店铺ID、类别、所在城市、商圈、人均消费、评分、开店时间等历史客流表就是每家店每天到店人数的时序记录用户行为表记录用户在店内的浏览深度、点击和收藏等行为另外还可以补充POI信息也就是商家周边一定范围内的其他商家的数量和类型。这个数据结构其实很典型它同时包含“这个人是谁”和“这个人过去表现如何”前者是静态画像后者是动态行为。做特征工程时我的经验是先分三个维度去思考时间切片上的规律、商家之间的相似性、空间位置带来的联动效应。不要一上来就堆几百个特征先想清楚每一类特征回答什么问题再动手构造。有一点特别值得提醒训练集和测试集在时间上是不完全连续的中间可能存在断裂。训练数据的最后一段日期和要预测的日期之间隔着一段只有部分数据或者完全没数据的时间。很多人在这里踩了坑——用的滚动窗口特征在训练时正常等到线上推断时特征取不到足够的历史窗口导致预测结果莫名其妙地变差。2.2 时间特征是客流预测的第一生产力做时序预测时间特征永远是先行的。基本的星期、月份、季节这些直接加上模型虽然能学到但信息不太够。真正的核心是把历史客流按照时间维度重构成统计特征。我当时用的比较有用的特征有几类第一类是“历史同期”特征比如预测日是周四我去看上周四、上上周四的客流因为这些日子具有相同的星期属性变化规律最接近。第二类是滑动窗口特征取预测日之前7天、14天、28天的客流均值、最大值、最小值、标准差。第三类是趋势特征比如近7天均值减去近28天均值用来表达近期是在涨还是在跌。这里有个细节值得展开讲。客流的周内模式非常强一般周末比工作日高周五晚上和周日午后也有明显波峰。如果直接对全部历史日期取均值会把星期差异抹平特征区分度反而不高。更稳妥的做法是“按星期对齐”要预测的是周二就用历史所有周二的值来算均值要预测的是周六就用历史周六来算。这样构造出来的历史参照特征和预测目标的周期性是一致的。除了日期本身节假日特征也得单独构造。中国本地生活商家的客流受节假日影响特别大。春节、国庆期间旅游城市和社区商家的客流走向完全不同。我们要自己在特征里标注预测日是否为节假日、是否为节假日前一天或后一天以及距离节假日的天数偏移。对树模型来说一个简单的“is_holiday”特征往往比一堆复杂统计特征带来的收益更大我实测下来线下的RMSE能明显下降。2.3 商家画像、POI与商圈特征如何榨出信息光有时间特征肯定不够因为不同店的客流基数完全不一样。同一个周末商场里的火锅店可能等位两小时社区楼下的早餐店可能只有平时一半的人。所以商家自身的属性特征决定了预测的基础水平。商家类别、城市、人均消费这些静态特征可以直接丢进模型但更好的用法是把它们转换成“统计值”。比如“同城市同类别商家的平均客流”“同商圈商家的平均客流”“该商家历史客流在城市同类别商家中的分位”。这些特征表达的其实是“这个店在同行的哪个水平”比单纯的绝对数值稳定得多尤其是在训练集和测试集商家重叠度不高的情况下。POI特征也很关键。一个店铺周围500米内有多少同类商家、多少餐饮商家、多少购物场所直接影响它的客流天花板。开在购物中心里的饮品店天然就比开在偏远路段的小店流量大。我当时按不同半径500米、1000米、2000米统计了周边POI的数量和类别占比这几个特征在模型的重要性排序中非常靠前。更进阶一点的做法是把“商圈效应”做成特征。同一个商圈里的店客流往往存在联动比如一家网红奶茶店排队可能会带动附近小吃店的客流。你可以构造商圈级别的日客流总量、商圈客流均值再把单个店铺的客流和商圈总量的比值作为相对强度特征。这个相对量能抵消掉商圈整体的涨落让模型更关注店铺自身的变化趋势。2.4 时序统计特征滑动窗口的正确打开方式滑动窗口特征看着简单实际操作中很多细节要注意。第一个是窗口长度的选择。7天窗口能反映最近一周的水平14天和28天窗口能反映中期趋势但窗口太长会把近期的变化稀释掉。我当时做了多个窗口的均值、标准差、最大值、最小值以及近期窗口相对远期窗口的变化率这些放到模型里可以让树模型自己选择什么时候用哪个特征。第二个细节是窗口内零值的处理。很多小店不是每天都营业客流记录里有不少0。如果窗口内包含大量0算出来的均值会明显偏低。我当时做了一版“只对非零日期求均值”的特征以及“窗口内零值天数占比”的特征效果比直接把0混进去求均值好不少。背后的逻辑是“这家店今天没营业”和“这家店今天生意惨淡”是两种完全不同的信息不能混为一谈。第三个细节是特征的时效性。在构造窗口特征时一定要确保只用预测日之前的数据。比如要预测7月20日那窗口就是7月13日到7月19日千万不能把7月20日当天的数据混进去否则就是未来信息泄露线下验证分数会异常高线上直接翻车。这个错误我在早期也犯过后来是靠严格的时间对齐检查才纠正过来。另外一个非常实用的技巧是“同比”概念。客流量有明显的季节性波动如果拿今年某一天的客流和上周比会受到季节整体趋势影响。更稳健的方式是用最近一周的均值与过去四周的均值的比值这样可以把店铺的绝对量级归一化突出相对变化。这类相对特征对商家个体差异有很强的适应性而且面对不同店铺时不需要重新建模。2.5 交叉特征与目标编码让模型看到个体差异树模型虽然能自动学习特征组合但提前做好交叉特征仍然能帮它省下不少复杂度。我当时构造了“城市类别”的交叉特征、“类别星期”的交叉特征以及“商圈是否为节假日”的组合。这些交叉特征的本质是抓住“某个城市的烧烤店在周末”这类多维度的规律模型自己学也行但效率不如直接喂给它。目标编码是另一个好用的工具。所谓目标编码就是用历史客流的统计量来替代某些高基数类别特征。比如商家ID有成百上千个如果直接作为类别特征树模型做分裂时会很慢而且容易过拟合。一个常见的做法是计算每个商家历史客流的均值做成一个“商家历史水平”特征。但要注意目标编码非常容易引入目标泄漏比如用全量数据的均值编码训练集测试集分布混杂线下验证会失真。正确的目标编码方式是对每个商家只用预测日之前的数据来统计它的历史均值或者用K折编码的方式在当前折内只使用折内训练数据计算。这么做虽然麻烦一点但能保证特征在训练和测试时口径一致。实话说我当时第一版目标编码就踩了泄漏的坑线下RMSE看起来特别漂亮结果提交线上分数惨不忍睹。后来把编码逻辑改成严格的按时间统计分数才恢复正常。3. 模型选型与训练流程3.1 先跑通一个baseline再谈优化很多人一上来就想堆最复杂的方法但我的经验是无论如何先跑一个最简单的baseline这样后面所有改进都能有一个参照系。这个赛题最简单的baseline是预测未来14天的客流等于历史最近一个同星期天的客流。比如要预测下周三就把上周三的客流作为预测值。这个方法很粗糙但能让你对数据量级有个基本概念。我当时先把baseline跑了出来计算了一下log1p后的RMSE然后在这个基础上一层层往上加东西。先加上“近7天同星期均值”RMSE降了一截再加上星期特征和节假日特征又降了一些等到完整的特征体系构建完模型输出的分数已经比baseline好出一大截。这个循序渐进的过程很重要它能帮你判断每一步的投入产出比知道哪些特征真正有效哪些特征加了等于没加。如果你在做这个赛题的时候一开始特征还没建起来不要急着调模型参数。先拿默认参数的LightGBM跑一版把特征的重要性打印出来看一看。你会发现排序靠前的往往是历史统计特征和时间特征这也验证了一个老生常谈的结论特征决定了上限模型只是逼近这个上限。3.2 为什么结构化数据上我首选LightGBM这个赛题的数据本质上是结构化的表格数据特征经过构造之后有成百上千维。对这种问题GBDT类的模型一直是最稳妥的选择我个人更偏向LightGBM。选择LightGBM有几个具体原因。第一它对高基数类别特征处理得非常好商家ID、店铺类别这类特征是树模型可以直接利用的。第二直方图算法让它训练速度很快特征调优迭代效率高。第三它支持缺失值处理数据里有一些没有POI信息或者天气缺失的情况不需要花费额外精力去填。第四LightGBM的正则化参数和早停机制比较成熟过拟合相对容易控制。给一组我实测下来比较顺手的参数参考import lightgbm as lgb params { objective: regression, metric: rmse, learning_rate: 0.03, num_leaves: 63, min_data_in_leaf: 50, feature_fraction: 0.8, bagging_fraction: 0.8, bagging_freq: 1, verbose: -1 }需要注意并不是num_leaves越大越好。这个赛题的数据噪声不小叶子节点太多容易学到局部波动导致线下验证还行、线上就露馅。我的经验是num_leaves控制在31到63之间配合min_data_in_leaf设大一点模型会更稳定。学习率设低一些配合多轮迭代和早停效果通常比大学习率跑几百轮要好。3.3 深度学习方案的经验与取舍当年很多人尝试LSTM、GRU这类序列模型我也不例外。说实话纯序列模型的效果并没有想象中好原因在于这个问题的有效信息不只是时间序列本身POI、商家属性、节假日这些外部信号很难塞进一个干净的序列模型里。如果你硬要做一种可行的方式是先把历史客流归一化再把静态特征做embedding后拼到每个时间步上但实现复杂度比GBDT高不少收益却不明显。我见过一些队伍用深度模型和LightGBM做了融合线上能提升一点点。原因是深度模型擅长捕捉连续几天的短期模式比如连续三天上涨后可能出现回落而GBDT更多依赖手工统计特征两者有互补性。如果你时间充裕可以训练一个轻量的LSTM或者GRU把归一化后的历史客流作为输入再和GBDT的结果做加权融合。但前提是GBDT的单模型效果已经足够好否则融合提升的空间非常有限。另外一个很多人忽略的点深度模型对序列的归一化方式要特别注意。客流量跨度非常大从0到几千都有不做归一化直接训练梯度很容易震荡。我当时做了min-max归一化但每个商家的量级不一样所以在样本维度做了分组归一化也就是每个商家的序列单独缩放效果会稳定很多。不过这样线上预测时也要按同样的方式处理增加了工程复杂度这也是我最终没有把深度模型作为主模型的原因之一。3.4 时间序列验证别用随机K折坑自己这是整个赛题里最容易犯的错误没有之一。普通机器学习问题里随机K折交叉验证是常态但在这个赛题里你一旦对样本做随机切分模型就会“看到”未来数据因为同一个商家的历史序列被打散了训练集里的某些样本可能比验证集里的样本时间更靠后。这样验证出来的指标会虚高你调参调的其实是一个幻觉。正确的做法是严格按时间顺序划分。比如把训练数据按日期升序排列取最后14天或者28天作为验证集之前的数据作为训练集然后模拟“用T日之前预测T1到T14”的流程。更贴近赛题的做法是滚动验证每次把训练窗口往前推预测下一个不重叠的14天阶段多滚动几次取平均的RMSE作为线下指标。除了验证集划分特征构造里也要避免使用验证集之后的信息。这个问题确实很隐蔽我当时在构造“商家历史均值”特征时顺手用了全部数据的均值导致线下分数异常优秀但线上差很远。后来我把所有统计特征改成只用“截至当前预测日”的历史窗口线下指标才真实起来。3.5 模型融合与后处理压分的关键一步单模型调到位之后融合是再进一步的关键。我当时用了LightGBM、XGBoost和CatBoost三个模型的加权平均权重是在线下验证集上用网格搜索定下来的三个模型预测结果相关性差异比较大融合后线下RMSE比最好的单模型还降了一些。融合之外后处理也不可忽视。客流量预测出来后要做expm1还原因为训练目标用了log1p。但还原后的预测值可能出现负值或极小值这时候要根据业务常识做一个简单的clip比如预测值不能低于0甚至可以结合商家的历史最低客流做一个底线约束。另外如果某些商家在预测期内明确没有营业记录它的客流预测直接置为0比模型硬预测一个数要合理得多。还有一个后处理技巧对时间粒度做平滑。因为预测目标是14天的日客流模型可能会把某一天的预测值拉得特别高这时候可以用“近3天滑动平均”做一下平滑能把单日异常脉冲抹掉。当然这个操作要在线下验证确认能够降低RMSE才采用不能为了平滑而平滑。4. 实战中的那些坑与关键细节4.1 数据稀疏与冷启动店铺的处理这个赛题里有些商家是刚开业的历史客流记录只有几天甚至没有。对这些店铺直接套用历史窗口特征是不行的因为特征缺失严重模型不知道该怎么预测。这就触及了冷启动问题实际业务里同样常见。我当时对冷启动店铺采用的思路是“借用邻居数据”。既然这家店没有足够历史就找同城市、同类别、同商圈的相似商家计算它们的平均客流和客流波动模式作为这家店的基础水平。具体做法是把这些相似商家的历史均值、星期波动系数、节假日效应做成特征喂给模型。模型在预测这家冷启动店的时候相当于参考了一群“同类平均水平”。另一个办法是在模型外单独做一套冷启动预测逻辑不走主模型。比如历史少于7天的商家直接用同商圈同品类的平均客流再根据星期系数调整。这样做的好处是可以对不同的数据量级分别对待毕竟冷启动本就是一个和普通商家差异很大的子问题硬塞进同一个模型里容易两头不讨好。当然这个策略需要在线下验证我当时对比了一下分桶处理比全部塞进主模型确实更稳。4.2 节假日与周期性脉冲的建模节假日是客流量预测里最大的“非平稳”因素。训练数据里可能只包含一两次春节或国庆模型很难从有限的样本里学到节假日的完整规律。所以不能完全依赖模型从数据里自动学习节假日效应得手工把节假日的先验信息注入特征。我当时的做法是构造了一组节假日相关的特征预测日距离节假日的天数正数表示节前负数表示节后、是否为节假日前一天、是否为节假日最后一天、节假日长度、节假日类型比如黄金周还是普通周末等等。这些特征本身不含历史客流但能让模型知道“这个日子很特殊不能按普通星期来推断”。还有一个容易被忽略的细节节假日对客流的影响并不是只在当天发生。很多人在节前就开始囤货节后又有一波回落这个“脉冲前移/后移”效应很常见。我当时专门做了“节前第N天”“节后第N天”的标签特征实测对节假日覆盖预测期的那几段样本帮助很大。如果你在预测期内没有节假日这些特征可能用处不大但一旦遇到收益会非常明显。4.3 日志变换与极端值处理客流量数据的长尾效应非常强。头部大店一天几千人尾部小店经常只有个位数如果用原始值计算RMSE误差主要被大店主导小店的预测准确性几乎没有区分度。官方把评价指标定为log1p后的RMSE其实就是在告诉我们这个比赛更关注相对误差而不是绝对误差。所以训练目标要取log1p也就是对原始客流传入log(1x)。预测结果出来后再用expm1还原。这个变换能让目标分布平滑许多模型的优化方向更符合评价指标。需要注意的一点是变换之后模型在log空间里误差是均匀的但还原到原始空间时大店和小店的误差比例会变得不同。如果业务上更关心大店的绝对客流可以对还原结果做二次调整但比赛场景下直接按log空间训练就好。极端值的处理也很关键。有些店铺可能因为促销活动某天客流暴增可能是平时的几十倍。这些点虽然数量少但对模型训练的影响很大会让模型为了拟合它们而扭曲整体形态。我当时先统计了每个商家历史客流的分位数把超过99.5分位数的值做截断缩尾然后再做log1p变换。这样既保住了大部分信息又避免了个别疯狂样本主导目标分布。4.4 从线下分数到线上排名的差距不要期望线下验证的RMSE和线上完全一致。模型做预测时经常出现线上比线下差一截。原因有几个一是样本分布变化测试期的商家集合可能和训练期不完全一致有些训练期没见过的店铺出现在了预测期二是节假日断档如果线下验证时覆盖了节假日而线上预测期是普通日期特征的重要性分布就会偏移三是特征口径不一致这一点只能通过严格的流程建设来避免。我的应对方法是线下验证协议尽量贴近赛题设定。具体来说我会做两个验证集一个覆盖普通日期一个覆盖待预测的特定时段。如果两个验证集上的特征重要性排序差异很大就说明特征体系可能过度拟合某一段时间的特殊规律需要重新审视。另外特征构造尽量使用相对量比如“近7天均值/近28天均值”这类特征对商家量级和整体水平漂移都不敏感更能保证线上线下分布一致。5. 高频问题与避坑速查5.1 新手最容易踩的五个坑我复盘了整个比赛的实战过程整理了五个高频问题每个都是真实踩过或者看其他人踩过的列成表格方便对照自查。问题现象可能原因解决办法线下RMSE很低线上突然变差特征里混入了未来信息比如使用了全量统计或预测日之后的窗口值所有历史统计特征严格按预测日截止验证集用时间切分预测结果天天都一样没有波动滑动窗口特征太多把近期波动平均掉了模型学不到周期细节增加星期对齐特征和“近7天相对近28天变化率”等趋势项冷启动店铺预测偏差巨大没有为短历史商家单独处理模型用全局规律硬套用同商圈同品类的相似商家统计特征替代缺失历史节假日期间预测完全失真节假日特征缺失模型把它当普通周末构造节前/节后/节假日天数等特征单独标记脉冲区间用了LSTM反而更差纯序列模型难以利用POI、商家属性等结构化信息以LightGBM为主模型深度模型仅做融合辅助5.2 特征工程质量自查清单特征工程是结构化数据竞赛的核心但质量比数量重要。我每次做完一批特征都会按下面这个清单过一遍能避免大部分低级失误所有时序特征是否严格使用了预测日之前的数据这一点再怎么强调都不过分。统计特征是否按星期对齐没有对齐的均值特征在周内波动明显的场景里会损失大量信息。目标编码是否做了时间隔离如果用了全量数据编码赶紧改成按历史窗口统计或K折编码。缺失值是怎么产生的是因为数据本身缺失还是因为窗口长度不足两者要区别对待。特征的时间口径是否一致比如有些特征按自然日有些按营业日混在一起会让模型很困惑。是否构造了足够多的“相对量”特征绝对水平特征在样本分布变化时容易失效相对量特征更稳健。如果你在跑这个赛题时发现线下验证一直调不上去大概率不是模型问题而是特征质量或者验证方式的问题。回到数据里再仔细检查一遍往往比换模型管用得多。5.3 一句话总结这个赛题留给我的经验要说这个项目给我留下最深印象的不是最后排名多少而是它让我彻底理解了“数据和特征决定上限模型只是逼近上限”这句话。面对真实的业务数据时间序列预测的难点不在算法精妙而在你能否把业务常识转化成模型能消化的特征能否在验证时不犯时间泄漏的低级错误。如果你打算拿这个赛题练手我的建议是先别急着上深度模型认认真真把baseline跑通把特征体系从零搭建起来你会在过程中学到比任何教程都多的实战经验。这个赛题放到今天依然是数据竞赛入门者最好的磨刀石之一。本文还有配套的精品资源点击获取