企业官网建设流程全解析

简介：IJCAI2017 天池大赛客流量预测 rank 9th 的完整代码与方案，面向数据科学竞赛玩家及时间序列预测学习者，基于口碑网商家客流数据解决未来时段用户访问量预测问题。压缩包共十七个文件，以十二个 Python 脚本为核心，辅以算法说明文档 docx、英文版讲解 PPT、README 和数据集说明文本，整体约 5.05MB，目录划分清晰，便于按模块复现与二次开发。已有一百九十八人学习浏览。代码覆盖天气、位置、星期等多维特征工程，提供 cluster.py、predict_type.py、Model_Plot.py 等脚本，分别实现聚类分析、预测类型处理与结果可视化；算法说明文档中进一步阐述了 ARIMA、LSTM 等时间序列模型及 XGBoost 集成方法的调优思路，并针对缺失值处理、平滑差分、交叉验证和 SMAPE 评估指标给出了可落地的操作经验。从数据预处理到模型对比，再到预测体系搭建，为理解大赛 Top 方案、完善个人项目提供了详实的参考资料。

1. 客流量预测为什么难做：从 IJCAI2017 天池大赛第 9 名的经验说起

排班排多少人、火锅店备多少份毛肚、奶茶店提前多久通知兼职到岗，这些运营动作背后要的唯一数字就是"明天这个时段会有多少客人"。但把这个问题丢给标准时序模型的时候，大多数人会翻车：客流不像网流量那样平稳，它叠加了工作日周末、节假日、天气、店铺商圈甚至平台活动多种节奏，而且每个店铺的波动形态完全不同。这也是我当时打 IJCAI2017 天池大赛客流量预测赛的体会，最终排在第 9 名的方案并没有用什么新鲜模型，而是把"预测对象定义、数据规约、特征组织、残差校准"这条链子补完整了。这篇文章就按这条链子展开，适合正在做门店流量预测、零售销量预测，或者准备参加类似时序竞赛的从业者。

2. 先把数据规约做对：聚合粒度与样本窗口

客流量预测的基本链条是数据到特征再到模型，但大多数参赛方案死在了第一步：把 15 分钟粒度的原始数据直接扔给模型，或者反过来把所有时间全量聚合到天级。原始数据的时间片段越细，噪声占比越高，小店铺在半小时内可能只成交一两单，这种数据上训练出来的模型，预测值会被极端值拽着走。所以在碰任何模型之前，先想清楚一件事：你到底在预测什么粒度、用什么误差尺度来评价预测结果。

2.1 预测目标与评估指标：先弄清在优化什么

比赛数据来自本地生活平台的商家流水记录，每个店铺在连续时间片上会有一条表示客流或成交强度的数值字段。拿到数据后最关键的问题不是"用什么模型"，而是"预测哪个量、用什么误差来算分"。

常见评估方式有 MAPE 和 MAE 两类。MAPE 对低基数额外敏感：某店铺某个时段流量为 0，模型只要输出一个非零值，误差就变成无穷大；反过来，流量只有个位数的店铺，误差会被量级放大。我通常会先按流量量级把店铺分成几个桶，在每个桶里单独看误差表现，这比只看全局平均分更能定位是哪一类店铺拖了后腿。

样本权重也要提前想好。如果评估指标对低量级店铺惩罚更大，那训练损失就需要做适配。常见做法是给样本加一个与店铺日平均流量成反比的权重，或者改用 Huber 损失来减轻离群样本的影响。这个决策要写在数据验证的第一步，而不是等模型训练完再补救，否则后期你会发现自己一直在调参，却说不清模型为什么对某些店铺系统性偏移。

2.2 15 分钟聚合到小时：缓解稀疏与隐式平滑

原始数据一般是 15 分钟一条的小片段，一天 96 个点。对小店铺来说，15 分钟窗口里大量为 0，这些零值有两个坏处：一是目标分布变成大量 0 加少量正数，模型很难学到稳定规律；二是在按小时或按天评估时，15 分钟级的局部异常会干扰特征提取。

我一般的做法是先把数据聚合到小时级，保留日内峰值形态，同时把零值比例压下来。下面是聚合代码。

import pandas as pd import numpy as np # 读取原始数据，字段按常见竞赛格式假设: shop_id, timestamp(15min), flow df = pd.read_csv("flow_sample.csv") df["timestamp"] = pd.to_datetime(df["timestamp"]) # 按店铺 + 小时聚合，flow 取求和和均值 hourly = ( df.groupby(["shop_id", pd.Grouper(key="timestamp", freq="H")])["flow"] .agg(["sum", "mean", "count"]) .reset_index() ) hourly.columns = ["shop_id", "time", "flow_sum", "flow_mean", "sample_count"]

聚合用 sum 还是 mean 要看你最终的预测目标。如果业务侧要的是"这个时段总到店人数"，用 sum；如果要的是"这个时段店铺的活跃水平"，用 mean。count 这一列用来诊断数据完整性，某小时 sample_count 显著少于 4（假设原始是 15 分钟粒度），说明这段时间存在缺采样，需要标记出来而不是当作正常缺失。

聚合到小时只是第一步。店铺营业时间通常不是全天 24 小时，比如很多餐饮店只在 11:00 到 22:00 活跃。直接把 0 点 到 6 点的全零时段一起喂给模型，会增加特征稀疏度，还会让树模型在这些时段上学习到无意义的分裂。我一般会先按店铺的活跃时间裁剪样本窗口，只保留营业区间，预测时也只输出该区间内的结果，这样整个模型不需要处理"永远为 0"的时段。

2.3 店铺分桶与异常窗口处理

店铺之间的量级差异极大，高流量店铺一天几千人，低流量店铺一天不到几十人。所有店铺丢进同一个模型时，树模型会优先去拟合高流量店铺，因为它们的绝对误差贡献最大，低流量店铺被系统性低估。这可以通过店铺分桶来规避——分桶不改变模型输入，但用于分别评估和选择特征组合。

异常窗口是另一个隐蔽的坑。店铺临时停业、平台接口故障，都会造成某一天或某几个小时流量归 0。这种 0 是缺失值而不是真实值，如果直接留在特征序列里，滞后特征会把 0 当作正常模式学习，未来遇到类似条件时会输出偏低的结果。我的做法是：识别连续为 0 超过 N 个时间片的窗口，打上异常标记，并在这个窗口里用前后同均值填充，同时在特征矩阵里加一列"is_outage"来保留缺失信息。

店铺层面的归一化也需要在数据规约阶段完成。简单做法是给每个店铺的流量除以它的历史均值，让特征表示"相对水平"。但要注意，标签如果是绝对流量，特征归一化而标签不归一化，树模型的分裂阈值会被不同店铺的量级干扰，所以更稳妥的做法是特征层面做店铺均值中心化，标签保留原始量纲，把所有店铺样本放进一个模型训练，但在验证时按店铺分桶评估。

3. 特征体系设计：把时间模式拆成模型能用的形式

客流量预测的特征工程核心不是堆特征数量，而是把时间序列里天然存在的多重周期拆开。客流数据有三层周期性：日内峰谷、周内工作日与周末差异、节假日与大型活动的脉冲式冲击。这三层周期叠在一起，如果只用时间戳数值建模，树模型要自己在数据里挖这些规律，效率低而且容易过拟合。显式构造出这些特征之后，模型才能在有限深度内找到有效分裂点。

3.1 多周期时间特征：周、日、节假日

时间特征是这一类竞赛里最重要的特征组，比店铺编码、距离类特征都更直接。常见做法是从时间戳中拆出小时、星期几、是否周末、是否工作日、是否节假日，以及它们两两交叉的维度。比如"星期几"和"小时"的交叉项，比单独两个字段更有区分度，因为周五晚上和周日晚上的流量模式完全不同。

节假日不是简单一个布尔值就够了。节前和节后通常有持续的扰动，比如五一假期前一天的下午，很多店会出现一个明显的小高峰；假期的最后一天反而回落。常见做法是给每个样本算"距离最近假日的天数"和"节前节后方向"两个连续特征，让模型可以学习到临近效应。同时，本地生活平台的促销或补贴活动会产生类似节假日的脉冲，这类活动日期在训练集里如果存在，也要显式标记出来。

我给一个特征构造的框架，这个框架在比赛里用了，决赛阶段也没有删掉任何一组特征，因为它们各自都在验证集上带来了正向贡献。

def build_time_features(df): t = df["time"] df["hour"] = t.dt.hour df["weekday"] = t.dt.weekday df["is_weekend"] = (df["weekday"] >= 5).astype(int) df["is_workday"] = ((df["weekday"] < 5) & (df["is_holiday"] == 0)).astype(int) df["hour_weekday"] = df["hour"].astype(str) + "_" + df["weekday"].astype(str) df["days_to_holiday"] = (df["holiday_start"] - t.dt.normalize()).dt.days # 节前为负、节后为正，方向信息很有用 df["holiday_direction"] = np.sign(df["days_to_holiday"].fillna(0)) return df

这段代码里 hour_weekday 是类别特征，后续可以直接给 LightGBM 的 categorical_feature 参数使用。days_to_holiday 要小心边界：如果样本发生在两个节日中间，需要取"最近的一个假日"来计算差值，而不是简单地把所有假日当成同一天处理。我在初赛阶段犯过这个错，后来统一改用"前后最近假日距离"双特征之后，验证集上的节假日窗口误差明显下降。

3.2 店铺个性化特征：量级、稳定性与近期趋势

店铺之间的差异，光靠一个 shop_id 让模型去学是低效的。显式构造店铺维度的统计特征，能帮助模型在小样本条件下快速泛化。常用的是三类：历史均值代表量级、历史标准差代表稳定性、最近 N 天的趋势代表当前所处周期。

# 按店铺分组计算长期统计量 shop_stats = data.groupby("shop_id")["flow"].agg( shop_mean="mean", shop_std="std", shop_cv=lambda x: x.std() / (x.mean() + 1e-3), ).reset_index() # 与原始数据合并 data = data.merge(shop_stats, on="shop_id", how="left") # 近期趋势: 最近7天均值相对历史均值的偏移 recent = data[data["time"] >= cutoff].groupby("shop_id")["flow"].mean().rename("recent_mean") data = data.merge(recent, on="shop_id", how="left") data["trend_offset"] = data["recent_mean"] / (data["shop_mean"] + 1e-3)

变异系数 shop_cv 这个特征容易被忽略，但它很关键：一个 CV 为 0.3 的稳定店铺和一个 CV 为 1.2 的波动店铺，即使均值相同，预测策略也完全不同。模型在分裂时如果能直接看到"这个店铺的波动有多大"，就不会把均值型的规律套在波动型店铺上。

trend_offset 的含义是最近 7 天的平均流量相对全历史平均水平是高了还是低了。这个特征能够捕捉店铺的新开业期、装修后重新营业、周边修路这类中周期变化。但这些近期窗口类特征要注意时间泄漏：计算近期均值时只能使用预测点之前的数据，不能用未来信息。

3.3 滞后特征与差分：给模型装上序列记忆

滞后特征是时序预测的标配，但在店铺粒度的数据上有一个最常见的错误：跨店铺做 shift。不同店铺的序列是独立的，如果整体 DataFrame 直接 shift，上一个时刻的样本可能是另一家店铺的，模型会学到一个毫无意义的"上家店流量"。正确做法是 groupby 之后再 shift。

# 先按店铺排好时间顺序，再做滚动特征 data = data.sort_values(["shop_id", "time"]).reset_index(drop=True) grp = data.groupby("shop_id")["flow"] data["flow_lag1"] = grp.shift(1) data["flow_lag7"] = grp.shift(7) data["flow_lag14"] = grp.shift(14) data["flow_ma7"] = grp.transform(lambda x: x.rolling(7, min_periods=1).mean()) data["flow_std7"] = grp.transform(lambda x: x.rolling(7, min_periods=1).std()) data["flow_min7"] = grp.transform(lambda x: x.rolling(7, min_periods=1).min()) data["flow_max7"] = grp.transform(lambda x: x.rolling(7, min_periods=1).max())

lag1 捕获的是"昨天同一时刻的水平"，lag7 捕获的是"上周同一天同小时的水平"，lag14 用于捕获更长期的小趋势。ma7 是最近 7 天的均值，std7 是波动度，min/max 用于标记异常峰值。滚动窗口的窗口长度选择是有讲究的：如果是按小时预测，7 天的滚动均值大致对应 7×营业时长个样本，足够平滑日内的周期波动，同时不至于拖入太长的历史趋势。

滞后特征在高流量大店上非常有效，但在小流量店铺上会引入噪声，因为原始值本来就波动剧烈。我的处理方式是：用小流量的滞后特征时，先对 flow 做一次 3 小时滚动平均再构造 lag，这样可以减少单点噪声的影响。这个细节未必会对全局分数产生巨大变化，但在小流量店铺桶里的验证集 MAE 有明显改善。

4. 模型选型与融合：LightGBM 为主线，后处理补残差

客流量预测任务里，主流方案几乎是树模型一统天下。原因是这种表格型时间特征场景里，样本量中等、特征含有大量类别和缺失值，树模型对特征尺度和缺失值的容忍度远优于深度学习。在打这个比赛的过程中，我主要用的是 LightGBM，偶尔用 XGBoost 做对照，最后再按店铺残差做后处理校准。差异化的分数提升更多来自后处理和特征组织，而不是换了更"高级"的模型。

4.1 先跑一个简单基线：理解数据的可预测性

在堆特征之前，先做一个最简单的基线：用最近 7 天同时段的平均值作为预测值。这个基线的误差水平告诉你数据的噪声底在哪里，如果连历史均值都打不过，说明特征或目标定义出了问题。

# 按 shop_id + hour + weekday 分组，用前7天同一时段均值预测 base_train = data[data["time"] < test_start] pred = {} for (shop, hour, wd), grp in base_train.groupby(["shop_id", "hour", "weekday"]): pred[(shop, hour, wd)] = grp["flow"].tail(7).mean() data["baseline_pred"] = data.apply( lambda r: pred.get((r["shop_id"], r["hour"], r["weekday"]), r["flow"]), axis=1 )

这个基线的效果很直观：高流量店铺表现尚可，因为日均值本身相对稳定；波动大的中流量店铺误差会比较大；极低流量店铺的预测几乎是错的，因为历史均值本身没有意义。基线的主要价值是把数据里"能预测的部分"和"噪声主导的部分"分开——前者交给特征和模型去拟合，后者就要考虑做幅度压缩或直接输出区间。

4.2 LightGBM 核心参数与训练流程：回归任务要盯 MAE

LightGBM 适合这个场景的核心原因是它对"大量类别特征 + 少量数值特征 + 缺失值"的表格数据非常友好，而且训练速度快，可以快速迭代特征。下面这个参数组合是我在这个比赛中用下来比较稳的一组，也是常见的竞赛通用参数。

import lightgbm as lgb features = [c for c in data.columns if c.startswith("f_")] X = data[features] y = data["target"] # 时序切分，不能用随机切分 split_idx = int(len(data) * 0.8) X_train, X_valid = X.iloc[:split_idx], X.iloc[split_idx:] y_train, y_valid = y.iloc[:split_idx], y.iloc[split_idx:] params = { "objective": "regression", "metric": "mae", "learning_rate": 0.05, "num_leaves": 63, "min_data_in_leaf": 30, "feature_fraction": 0.8, "bagging_fraction": 0.8, "bagging_freq": 1, "verbose": -1, "seed": 42, } model = lgb.train( params, lgb.Dataset(X_train, y_train), num_boost_round=1000, valid_sets=[lgb.Dataset(X_valid, y_valid)], callbacks=[lgb.early_stopping(100), lgb.log_evaluation(100)], )

参数说明：metric 用 mae 而不是默认的 l2，因为客流量预测的评估指标通常更接近 MAE，L2 会对高流量店铺的离群值产生过度惩罚，导致模型为了降低大店误差而牺牲小店。num_leaves=63 在这个特征规模下是够用的，继续增大到 127 可以在验证集上看到轻微过拟合；min_data_in_leaf 这个参数要重点调，它控制叶子节点的最少样本数，对噪声大的时序数据来说，调高到 50～100 往往比找 num_leaves 更有效。feature_fraction 和 bagging_fraction 我习惯都设在 0.8，能显著提升泛化能力。

还需要强调一点：这里的时序切分只是粗略的 80/20 划分。真实比赛里验证方式还要更严格，第 5 章会专门讲这个问题。训练时可以直接把 shop_id 当作特征，或者作为 categorical_feature 传入，让模型学习店铺本身的基准水平。

4.3 残差分析与后处理修正：模型输出不是最终答案

树模型的回归输出本质上是训练集目标的加权平均，这导致一个系统性现象：对于极端波动的店铺和极端时间段，预测值会向均值收缩——高峰期被低估，低谷期被高估。这不是模型的 bug，而是回归目标函数的固有倾向。所以拿到模型的原始预测之后，还要做一层后处理。

# 训练集上的残差 valid_pred = model.predict(X_valid, num_iteration=model.best_iteration) resid = y_valid.values - valid_pred # 按店铺和星期几分组，统计残差的p50分位数，作为偏差修正 calib_df = pd.DataFrame({ "shop_id": X_valid["f_shop_id"].values, "weekday": X_valid["f_weekday"].values, "resid": resid, }) bias_table = calib_df.groupby(["shop_id", "weekday"])["resid"].median().reset_index() bias_table.columns = ["shop_id", "weekday", "bias"] test_pred_df = pd.DataFrame({ "shop_id": X_test["f_shop_id"].values, "weekday": X_test["f_weekday"].values, "raw_pred": test_raw_pred, }) final_pred = test_pred_df.merge(bias_table, on=["shop_id", "weekday"], how="left") final_pred["pred"] = final_pred["raw_pred"] + final_pred["bias"].fillna(0)

这个残差校准的思路是：对每个店铺在每个星期几，统计模型预测值与真实值之间的系统偏差，然后把偏差加回到预测值上。如果某店铺在周三总是被低估 20，模型自身无法修正，但后处理可以直接把它加回来。这里用中位数而不是均值，是为了避免个别极端样本把偏差估计拉偏。

后处理的另一层是峰值修正。很多店铺的午餐高峰和晚餐高峰是明显不同的，模型往往在两个高峰之间取了一个平均水平的预测。我按"小时是否属于高峰时段"单独计算残差修正，效果比统一的店铺级修正更好。

# 按店铺+星期几+是否高峰时段分组修正 calib_df["is_peak"] = calib_df["hour"].isin([11, 12, 13, 17, 18, 19]) bias_table = calib_df.groupby(["shop_id", "weekday", "is_peak"])["resid"].median()

这种残差后处理本质上是在利用模型残差中残留的规律性信息。树模型拟合的是全局结构，残差里的店铺个性信息它没有完全捕捉到，通过分组统计再喂回去，就相当于给模型做了一次"微调"。我当时决赛阶段的有效提升，一大半来自这类后处理而不是模型本身的调参。

5. 避坑指南：数据泄漏、店铺偏移、节假日伪规律与线上掉分

从数据处理到提交流程，这中间处处有坑。以下是四个我亲身踩过、或者在复盘时确认会对结果造成实际伤害的问题，每条都写成"现象 → 原因 → 解决"的方式，方便你对照排查。

5.1 现象：随机 K 折交叉验证分数很高，提交后排名却大幅下滑

原因：时间序列数据里有严重的自相关性。相邻时刻的样本特征和标签高度相似，随机切分会把同一家店邻近时间的数据同时分到训练集和验证集，相当于让模型"背答案"。验证集里出现的模式，训练集里已经见过几乎一模一样的样本，所以分数虚高。

解决：统一改用时间序列切分。简单做法是按时间点排序后，以某个日期为界切分训练/验证，保证验证集中的所有样本在时间上晚于训练集。更严谨的做法是用 TimeSeriesSplit 做多折滚动验证，每一折只使用该折之前的数据训练。我在比赛中后段全部换成了滚动验证，分数可比性立刻恢复。

5.2 现象：高流量店铺预测得准，中低流量店铺误差贡献了总误差的 70%

原因：树模型回归在默认损失下，对大误差样本的惩罚更大，而大流量店铺的绝对误差天然就大。模型把主要容量花在了拟合大流量店铺上，中低流量店铺因为绝对误差小、梯度贡献弱，被模型忽略。这不是模型的问题，是目标函数与业务需求错配的结果。

解决：两招并用。第一，在训练时给样本加权重，权重大致与店铺流量量级成反比；第二，分桶训练或者在后处理阶段做分桶校准。我最终采取的是"全局模型 + 分桶残差校准"的组合，比完全分开训练更稳，因为全局模型能借用大流量店铺学到的时间模式。

5.3 现象：模型在节假日预测上整体偏低，且节后第一天严重失真

原因：节假日样本在全年数据里占比很小，模型训练时几乎没有足够的样本学到节假日与平日不同的流量规律。同时，节假日通常和高流量、高峰值绑定在一起，模型天然的回归到均值倾向会把这些峰值压低。

解决：三个手段配合。第一，构造"距最近假日天数"和"节前/节后方向"两个连续特征，把节假日的影响从稀疏的布尔值变成平滑的连续变量；第二，在损失函数里对节假日样本加权；第三，做独立的节假日残差校正，也就是第 4 章里的分组修正逻辑，把节假日的系统偏差单独统计出来。这三个手段叠加后，节假日的误差基本被拉回正常水平。

5.4 现象：本地验证分数在涨，线上却一直不涨，甚至有时候下线涨线上跌

原因：最容易忽略的问题是验证集的构造方式与线上评估不一致。比赛的真实评估往往是跨天的多时间点预测，比如一次性预测未来 7 天，而本地验证如果只做单日滚动预测，两者的误差结构完全不同。另一个常见原因是特征里的滞后值在线上预测时取不到真实值——线上环境里"昨天的流量"是通过模型预测得到的，误差会顺着滞后链传递。

解决：在本地完整模拟线上流程，每一轮预测都用上一轮的预测值（而不是真实值）来构建滞后特征，再计算误差。这种方法叫自回归式滚动验证，虽然更慢，但它的分数才跟线上可比。我在比赛初期的排名波动，一半以上都能归因到这个问题。

6. 用分位数与残差校准逼近第 9 名：最后一公里的提升

做到第 4 章那些步骤之后，整体框架已经完整，但排名还停在几十名开外。复盘时发现，剩余的空间几乎全部集中在两个地方：模型输出去的是"期望值"而不是"条件分位数"，以及残差校准时分组粒度不够细。

先解决第一个问题。回归模型输出的预测是对条件的期望，但业务上你真正想要的是"最可能的那个值"，在偏态分布下两者并不重合。客流数据尤其是高峰时段呈右偏分布，期望值会被高流量的少量样本拽向偏大的方向，导致模型系统性高估高峰。常见做法是训练分位数模型，或者对目标变量取 log1p 变换后再训练，让模型拟合中位数而不是均值。

# 对目标做 log1p 变换，预测后 expm1 还原 y_train_log = np.log1p(y_train) model_log = lgb.train( params, lgb.Dataset(X_train, y_train_log), num_boost_round=1000, valid_sets=[lgb.Dataset(X_valid, np.log1p(y_valid))], callbacks=[lgb.early_stopping(100)], ) raw_pred_log = model_log.predict(X_valid, num_iteration=model_log.best_iteration) pred = np.expm1(raw_pred_log)

第二个问题，改进残差校准的分组粒度。之前是按店铺+星期几分组，后来发现同一家店铺在不同季节的流量基准完全不一样。改进做法是加入月份或季度分组，让偏差表更贴近当前时段的实际情况。具体做法是把样本按"店铺+星期几+月份"三重分组来统计残差中位数，虽然组内样本数量变少，但时间上足够接近，修正效果更好。

最后还有一个值得尝试的细节：对预测结果做业务约束。比如营业时段外流量必须为 0，比如非营业时段预测值直接置零；再比如正值的预测不允许超过该店铺历史峰值的某个倍数，超过就截断。这类约束不会提升模型分数，但它会让提交结果看起来更像一个正常人排班时会用的数字，在业务落地时价值不亚于分数提升。

这次的比赛经历让我养成一个习惯：每次模型迭代，先保存残差分布图，再保存分数。分数会骗人，残差不会——它告诉你模型在哪里产生误差、误差长什么样、是靠运气还是靠规律碰对。希望这篇笔记里能有一条对你当下的项目有用，也祝你在做客流量预测时少走我走过的弯路。

本文还有配套的精品资源，点击获取