简介这是一份基于随机森林模型的数据挖掘实战资源包面向有一定Python基础的初学者或研究者聚焦零售店库存数据的可视化与预测任务可直接用于课程设计、毕业设计或项目练习。包内共3个文件ipynb代码文件涵盖数据清洗、特征工程、随机森林建模与评估的完整流程csv文件提供真实的零售店库存数据集html文件则呈现分析结果的网页报告便于快速查看可视化图表和关键结论。压缩包整体仅2.31MB体积小、下载快目录结构简洁清晰。学习这份资源可以掌握随机森林在库存预测中的完整应用思路包括特征重要性分析、模型参数调优等常用操作并可将代码框架迁移到其他业务场景。目前已有109人学习下载适合希望以真实数据练习建模、快速上手数据挖掘项目的读者。1. 零售店库存预测为什么值得用随机森林模型跑一遍库存预测是一类很“接地气”的数据挖掘实战数据集往往就是一张零售店的销售明细表加一张库存快照但预测结果直接关系到门店要不要补货、补多少。随机森林在这个场景里属于性价比最高的选项它不像深度学习那样依赖海量样本也不像时间序列模型那样要求严格的分布假设几万行零售销售记录就能训练出可用的模型。这篇笔记适合正在做数据挖掘课设、需要一套能讲清楚的数据集加代码路径的同学也适合用 Python 做零售数据分析、想把库存预测从 Excel 表格换成模型的从业者。整个流程从理解字段开始经过特征工程、随机森林回归、可视化呈现最后落到参数调优和踩坑记录。先给一个反直觉结论这类项目最容易翻车的不是模型选型而是时间切分和滞后特征这些不起眼的细节。2. 随机森林在库存预测中的定位从数据字段到建模逻辑2.1 零售库存预测是一个回归问题随机森林的建模逻辑为什么匹配库存预测要回答的核心问题是给定门店编号、SKU 编码和预测起始日期估算未来一段时间需要准备多少库存。这里输出的不是“补货”或“不补货”的二分类结果而是一个具体数量因此这是一个回归问题。随机森林处理回归的思路是多棵决策树分别对目标值进行预测最后取平均值作为整体输出。每一棵树在训练时只随机使用部分样本和部分特征单棵树各自的“偏科”会在集成平均之后被抵消这也是随机森林在数据噪音多、字段杂的零售库存场景里表现稳定的主要原因。零售库存数据有三个特点恰好对应随机森林的优势。第一字段量纲差异大销量可能是个位数到几百库存周转天数可能是 0 到 60这些字段直接放进树模型不需要做标准化因为决策树只按特征值的大小做切分不受单调变换的影响。第二数据中存在异常值盘点差错导致库存数量突然翻倍、销售记录出现负数冲正等随机森林通过每棵树的局部切分降低单点异常对整体预测的破坏。第三特征间的关系是非线性的促销前两天销量上涨、断货后需求自然回落这类事件组合在树模型里会形成很自然的交互切分而在线性模型里需要手工构造交叉项才能捕捉。随机森林也有明确的边界。最突出的是它对外推无能为力训练数据里的销量区间如果集中在 0 到 200 之间模型预测值基本也不会跳出这个范围。假如一家门店因为迁址或者更换经营品类销量模式发生整体迁移随机森林大概率会沿用旧规律预测结果就会失真。其次是随机森林本身不感知时间顺序模型并不知道“日期先后”意味着什么必须把时间信息显式转化成特征喂进去。这两个边界在库存预测中必须提前意识到前者靠监控特征分布变化来缓解后者靠构造滞后特征和周几、月份等周期性特征来解决。2.2 哪些字段值得进模型销售明细、库存快照与时间上下文典型的零售店库存数据集里常见字段可以分成四类。第一类是实体标识门店编号、SKU 编号用于区分样本归属。第二类是业务数值日销量、当前库存量、进货量、售价、成本价。第三类是时间字段日期通常精确到天。第四类是状态字段是否促销、是否周末、门店规模等级等。这些字段单独拿出来有效但真正让随机森林模型变好用的是组合出来的特征。时间上下文特征是最重要的一类。零售业有很强的周期性对大多数快消品门店来说周一到周五的销量和周末销量差异明显月初月末受工资日影响也有波动。日期字段本身不能直接作为特征使用因为它只是一个字符串或者时间戳树模型很难从“2024-05-17”这种值里学到规律。我会把日期拆成 weekday星期几、day_of_month几号、is_weekend是否周末再根据业务日历加一列“是否法定节假日”。滞后销量特征承担了“趋势记忆”的任务。随机森林不像 ARIMA 那样对序列结构建模如果想让模型知道“上一周卖了多少”就得手动构造一个 lag_1w_sales 列把每个 SKU 在 7 天前的销量对齐到今天这条记录上。滞后期数的选择要和门店的补货周期成正比。周补货的门店至少构造滞后 1 周、2 周和 4 周的销量日补货的便利店滞后 1 天、3 天、7 天都值得尝试。这里有一个容易忽略的细节如果某 SKU 在前一周经历过断货那一周的销量可能为 0这个 0 并不是真实需求模型会被误导因此还要把断货标记当天库存触底、次日销量为零一并构造出来。库存周转特征是连接“销售”和“库存”两个域的桥梁。库存周转天数等于当前库存除以最近 7 天日均销量它表达的是“按现在的卖法这批货还能撑多久”。这个值小代表快售罄该触发补货了。有了当前库存量与未来预测销量的相对关系模型才能把库存状态纳入预测逻辑而不是只靠历史销量外推。特征数量不是越多越好我见过有人把十几个 SKU 属性、十几个时间窗口特征全部塞进去结果训练时间变长特征重要性被稀释预测精度反而没有提升。随机森林做特征筛选相对粗暴先跑一版全量特征读取 feature_importances_把重要性趋近于 0 的特征删掉再训练一次通常能拿到更稳定的模型。2.3 为什么是随机森林与线性回归、XGBoost、Prophet 的取舍做数据挖掘实战时最常见的选择题就是回归模型用哪个。线性回归最容易上手但库存销量数据几乎不满足线性假设促销日和非促销日的销量是跳跃式变化线性模型在这种场景里残差会非常大。Prophet 这类时间序列模型擅长提取趋势和季节性却对额外业务特征促销、节假日、断货支持不友好需要额外构造回归因子改动成本不低。XGBoost 和 LightGBM 这类梯度提升树模型在库存预测上精度更高但参数敏感度也高学习率、树深度、叶节点最小样本、特征采样比例之间互相影响新手调参很容易把模型调到“训练集完美、测试集崩盘”的状态。随机森林虽然单棵树的偏差消除能力弱于带 boosting 的树模型但胜在参数稳健默认参数的预测结果已经处在可用水平。从课程设计和数据挖掘实战的角度随机森林还有一个加分项它在 scikit-learn 中的实现只需要几行代码就能跑通模型能用 joblib 或 pickle 保存预测阶段可以直接在 Jupyter 里加载。后续如果要升级成 LightGBM沉淀下来的特征工程代码完全可以复用模型切换成本很低。所以在“数据集加代码”这类实战项目里我一般会把随机森林作为第一个交付版本确认特征和评估体系稳定之后再考虑换更强的模型。3. 从数据集到可视化界面随机森林库存预测完整实现3.1 数据加载与预处理把销售和库存对齐成一张宽表拿到零售店库存数据集之后第一件事不是建模而是把数据整理成“一行对应一个门店一个 SKU 一天”的宽表结构。很多原始数据里销售明细和库存快照是分开存放的需要按门店、SKU 和日期对齐。这里给出一个最小可运行的预处理流程import pandas as pd # 读取销售明细与库存快照日期都转成 datetime 类型 sales pd.read_csv(sales_data.csv, parse_dates[date]) stock pd.read_csv(stock_snapshot.csv, parse_dates[date]) # 按门店SKU日期对齐得到日粒度宽表 df sales.merge(stock, on[store_id, sku_id, date], howleft) print(合并后行数, len(df), 列数, len(df.columns)) # 销量缺失的记录直接删除库存缺失的用同SKU前一天值前向填充 df df.dropna(subset[sales_qty]) df[stock_qty] df.groupby([store_id, sku_id])[stock_qty].ffill() # 过滤异常记录销量和库存不允许出现负数 df df[(df[sales_qty] 0) (df[stock_qty] 0)] # 只保留营业满90天的门店剔除开业初期噪声 store_stats df.groupby(store_id)[date].agg([min, max]) valid_stores store_stats.loc[ store_stats[max] - store_stats[min] pd.Timedelta(days90) ].index df df[df[store_id].isin(valid_stores)].copy() df df.sort_values([store_id, sku_id, date]).reset_index(dropTrue) print(df.head())这段代码里有几个参数值得说明。merge的howleft表示以销售明细为主表库存快照可能比销售少一个频次缺失时保留销售的日期骨架。ffill()是针对库存字段的前向填充库存盘点通常不是每天都有把最近一次盘点值向后延续是零售库存分析里的常规做法。保留 90 天最小营业时长是为了剔除新店开业期销量剧烈波动造成的干扰这个阈值可以根据数据集的覆盖时长调整数据跨度短就降到 60 天。预处理阶段还要关注重复记录。同一门店同一 SKU 同一天出现两条销售记录多半是不同班次分别上报应该在建模前按门店、SKU、日期做一次聚合求和。如果数据集中存在“未来日期”的库存记录比如系统提前录入了计划到货一定要先筛掉否则特征会穿透到未来导致验证结果虚高。3.2 特征工程实操滞后销量、库存周转与事件标记预处理后的宽表还不能直接进入随机森林。我给模型准备的字段分三组销量记忆、库存状态、事件标记。销量记忆用滞后窗口表达“最近卖得怎么样”库存状态用周转天数表达“手头还有多少货”事件标记用促销和星期几表达“近期有没有突发需求”。代码把三类特征一次构造出来# 滞后销量7天前、14天前的销量作为趋势记忆 df[lag_1w_sales] df.groupby([store_id, sku_id])[sales_qty].shift(7) df[lag_2w_sales] df.groupby([store_id, sku_id])[sales_qty].shift(14) # 近28天滑动平均销量表达中期趋势 df[sales_ma_4w] df.groupby([store_id, sku_id])[sales_qty].transform( lambda x: x.rolling(28, min_periods1).mean() ) # 库存周转天数当前库存 / 最近7天日均销量分母加极小值防止除零 df[stock_turnover_days] df[stock_qty] / ( df.groupby([store_id, sku_id])[sales_qty].transform( lambda x: x.rolling(7, min_periods1).mean() ) 1e-9 ) # 事件标记周末、促销、月初 df[is_weekend] df[date].dt.dayofweek.isin([5, 6]).astype(int) df[is_promotion] df[promo_flag].fillna(0).astype(int) df[is_month_start] df[date].dt.day.le(3).astype(int) # 目标变量未来7天销量总和作为库存需求预测的标签 df[future_sales_7d] df.groupby([store_id, sku_id])[sales_qty].transform( lambda x: x.rolling(7, min_periods1).sum().shift(-6) ) # 标签缺失数据末尾的样本不参与训练 df_model df.dropna(subset[future_sales_7d]).copy() print(df_model[[lag_1w_sales, stock_turnover_days, future_sales_7d]].describe())这里最需要理解的是future_sales_7d的构造方式。rolling(7, min_periods1).sum()计算的是包含当天在内连续 7 天的销量之和shift(-6)把窗口结果向前平移 6 天让结果对齐到窗口的第一天。也就是说每一行样本的标签是“从当天起未来 7 天总销量”这正好对应补货决策需要的需求预测量。数据最后 6 天无法构造标签dropna会自动去掉这些样本。参数方面有两个细节容易出错。第一shift(7)的前提是数据粒度是“天”如果数据集本身是周粒度或月粒度要把滞后窗口改成shift(1)或对应周期数否则滞后的天数概念就错了。第二stock_turnover_days的分母加了1e-9这是为了防止 SKU 连续 7 天销量为 0 时出现除零错误这个坑在长尾商品上非常常见不加的话训练阶段会直接报 inf 或者 NaN。3.3 随机森林回归模型训练参数设置、评估指标与特征重要性特征构造完之后进入随机森林的训练环节。有一个关键原则要提前说库存预测本质是时间序列预测训练集和测试集不能随机打乱必须按时间先后切分。用未来的数据训练、过去的数据测试模型会偷看到“未来答案”指标好看但没有实际意义。常规做法是把数据最后 30 天作为测试集之前的数据作为训练集from sklearn.ensemble import RandomForestRegressor from sklearn.metrics import mean_absolute_error, mean_squared_error feature_cols [ lag_1w_sales, lag_2w_sales, sales_ma_4w, stock_qty, stock_turnover_days, is_weekend, is_promotion, is_month_start, store_id, sku_id ] # 类别字段转成数值编码sklearn 的随机森林不接受字符串 for col in [store_id, sku_id]: df_model[col _code] df_model[col].astype(category).cat.codes feature_cols [c _code if c in [store_id, sku_id] else c for c in feature_cols] cutoff df_model[date].max() - pd.Timedelta(days30) train df_model[df_model[date] cutoff] test df_model[df_model[date] cutoff] X_train, y_train train[feature_cols], train[future_sales_7d] X_test, y_test test[feature_cols], test[future_sales_7d] # 随机森林回归300棵树树深最多12层叶节点至少5个样本 rf RandomForestRegressor( n_estimators300, max_depth12, min_samples_leaf5, random_state42, n_jobs-1 ) rf.fit(X_train, y_train) pred rf.predict(X_test) print(MAE:, round(mean_absolute_error(y_test, pred), 2)) print(RMSE:, round(mean_squared_error(y_test, pred) ** 0.5, 2)) # 输出特征重要性用于判断哪些字段真有用 imp pd.DataFrame({feature: feature_cols, importance: rf.feature_importances_}) imp imp.sort_values(importance, ascendingFalse) print(imp.head(10).to_string(indexFalse))代码里最需要解释的是类别编码。store_id_code利用 pandas 的 category 编码把门店编号映射成 0 到 N-1 的整数随机森林可以读取这样的整数特征。门店编号经过编码后有数值大小关系但决策树只按阈值做切分不会像线性模型那样把编号当成连续值来斜着拟合所以这个编码方式不会引入排序偏差代价只是模型可解释性稍微下降。几个参数的作用要区分清楚。n_estimators300表示随机森林由 300 棵决策树组成数量越大预测越稳定但训练时间越长到达一定数量后精度增益会递减300 是零售数据量级下比较平衡的选择。max_depth12限制每棵树的深度避免单棵树过度拟合个别门店的极端销量。min_samples_leaf5要求叶节点至少包含 5 个样本是防止回归输出过于极端的主要手段。n_jobs-1代表使用全部 CPU 核心并行训练数据量不大时这个参数不明显数据量大了能明显缩短训练时间。MAE 和 RMSE 需要结合销量量级一起看。比如 MAE 等于 12意思是平均每个 SKU 的预测值和真实值相差 12 件。如果 SKU 平均销量是 30 件误差率 40%模型还有优化空间如果平均销量是 200 件误差率 6%已经相当可用。只看绝对值没有意义要拿误差和预测目标本身的均值做对比。3.4 可视化呈现预测值与真实库存的对比图怎么画库存预测的可视化重点不是把图画得炫而是让看的人一眼判断“模型准不准、库存紧不紧张”。实际项目里我一般至少画三类图模型预测与真实销量的时间序列对比、特征重要性排序、预测需求与当前库存的差距条形图。第一类图校验模型行为第二类支撑特征取舍第三类才是给运营做补货决策看的。可视化大屏是最终产品形态但起步阶段不要纠结大屏先把对比图画明白。import matplotlib.pyplot as plt # 选一个门店一个SKU的可视化样本 sample_store, sample_sku S001, SKU003 sample_df test[(test[store_id] sample_store) (test[sku_id] sample_sku)].copy() sample_df sample_df.sort_values(date) sample_df[pred_sales] rf.predict(sample_df[feature_cols]) fig, ax plt.subplots(figsize(12, 5)) ax.plot(sample_df[date], sample_df[future_sales_7d], label实际未来7天销量, color#1f77b4, linewidth1.5) ax.plot(sample_df[date], sample_df[pred_sales], label随机森林预测, color#d62728, linestyle--, linewidth1.5) ax.set_xlabel(日期) ax.set_ylabel(未来7天销量) ax.set_title(f{sample_store} / {sample_sku} 库存需求量预测对比) # 在图上标注真实库存低于预测需求的时间点 understock sample_df[sample_df[stock_qty] sample_df[pred_sales]] if len(understock) 0: ax.scatter(understock[date], understock[pred_sales], color#2ca02c, s40, label库存缺口点) ax.legend() plt.tight_layout() plt.show()这段代码最常见的坑是文本匹配。如果“S001”在数据集里的实际编号格式是整数 1 或者带前导零的字符串筛选出来的就是空数据框画布上只有坐标轴报错不明显。应对方法是从原始数据里先取几行唯一的store_id打印出来确认格式再写死到筛选条件里。绿色点标出的“库存缺口点”表示这些日子当前库存低于预测需求量是需要触发补货的时点这些点在业务上就是补货建议的重点关注对象。4. 避坑指南随机森林库存预测中常见的5个翻车现场4.1 预测结果基本等于同一个均值SKU差异完全没体现现象是模型跑完之后 MAE 看着不大但把预测曲线画出来几乎是直线不同 SKU 的预测值都向整体均值靠拢门店和单品之间的差异完全丢失。原因通常有两个一是max_depth和min_samples_leaf设置得太保守树太浅导致每棵树的输出都接近样本均值集成平均之后更加平滑二是特征与目标的相关性太弱模型找不到有效的切分变量只能靠全局均值兜底。解决办法是先做一个单特征基线测试只用lag_1w_sales一个特征训练如果曲线还是平的说明问题出在特征如果单特征有波动再把max_depth从 12 提到 18min_samples_leaf降到 2观察预测曲线敏感度。我的经验是这类问题八成出在特征没构造好而不是参数不对先回去检查滞后特征是否真的被正确对齐了。4.2 测试集指标好得反常特征里混进了未来数据我遇到过最典型的案例是训练集 MAE 8.2测试集 MAE 6.1测试误差比训练误差还低这在时间序列场景里非常不合理唯一的解释是特征和数据之间存在穿透。排查到最后发现库存快照表里包含了计划到货量把未来才会到货的库存提前算进了当天的当前库存字段模型等于提前看到了未来结果。随机森林只学习特征和标签的映射关系只要特征里存在“当天之后才知道的值”测试集指标就会虚高。解决方法是把特征构造拆成“截至当天”和“当天之后”两类逐列检查最简单有效的验证手段是把预测目标改成“未来第 8 天到第 14 天的销量”如果模型仍然预测得很准说明特征穿透已经非常严重必须回头清理字段。4.3 没按时间切分训练集测试集模型实际在“猜邻居”很多人用 scikit-learn 习惯了train_test_split默认参数里shuffleTrue库存预测照抄这个用法结果离线测试表现良好上线后一塌糊涂。原因是库存数据存在时间自相关随机打乱之后训练集和测试集互相包含相邻日期模型实际上是在“猜时间附近的样本”而不是“预测未来”。判断有没有踩坑很简单检查测试集中日期的最小值是否大于训练集中日期的最大值如果两者日期交叉就是切分错了。解决方法是按时间比例切分测试集直接取日期最后 20% 的样本进一步可以用时间序列交叉验证具体做法放在最后一章。4.4 滞后特征大面积NaN为省事填0反而带偏模型零售数据里很多 SKU 是长尾品一件商品一个月只卖出个位数单子。对这类 SKU 做shift(7)滞后大量行的lag_1w_sales就是 NaN。pandas 的 groupby 加 shift 产生 NaN 后直接进入随机森林scikit-learn 会报错为了省事把 NaN 全填成 0又会让模型把“过去没卖过”和“断货没卖”混为一谈预测结果自然偏小。更合理的做法是分层处理按近 30 天销量把 SKU 分成畅销品和长尾品两类长尾 SKU 单独建模或者把滚动窗口从 7 天放宽到 14 天、30 天减少零销量导致的稀疏。我这里习惯把min_periods调大比如rolling(14, min_periods5)宁可少要几行训练样本也不制造虚假的 0 特征干扰模型。4.5 预测曲线拟合很好但换算成补货量后不能落地最后一个坑常常出现在项目交付阶段。模型预测的是“未来 7 天销量”但运营要的补货量是“预测销量加安全库存减当前库存减在途库存”。我见过只看预测曲线判断项目成功的例子模型拟合得很漂亮但运营按公式一算发现大批 SKU 的补货量为负原因是很多商品当前库存高但即将过季随机森林只按历史销量推断了需求并不知道商品生命周期快结束了。随机森林预测的是需求不是补货决策。落地时需要在模型之外定义安全库存天数再把需求、当前库存、在途库存三个数合并输出补货建议。这一步在数据挖掘实战里经常被忽略但恰恰是决定模型能否被业务真正使用的最后一道坎。5. 让模型更可信滚动验证、参数调优与补货建议落地5.1 用滚动时间窗口验证不迷信一次性测试指标一次性切分测试 30 天只验证了一个时间段模型可能只是在那段时间恰好表现好。我常用滚动验证的方式评估稳定性以 30 天为一个窗口第一次用前 120 天训练、验证接下来 30 天第二次用前 150 天训练、验证之后 30 天不断推进。这样得到的 MAE 序列比单个一次性测试指标可信得多也能看出模型在促销旺季是否退化。# 简化版滚动验证依次推进训练集和验证集窗口 results [] for step in range(3): train df_model.iloc[0:120 30 * step] val df_model.iloc[120 30 * step:150 30 * step] rf.fit(train[feature_cols], train[future_sales_7d]) pred rf.predict(val[feature_cols]) mae mean_absolute_error(val[future_sales_7d], pred) results.append(mae) print(f窗口{step 1} MAE{mae:.2f}) print(平均MAE, round(sum(results) / len(results), 2))窗口边界参数最需要调。df_model必须先按日期排序如果数据集覆盖不到 200 天窗口要缩小到 60 天和 30 天。scikit-learn 其实有现成的TimeSeriesSplit但它默认用索引切分理解上不如这个直接写循环直观初学者先用显式窗口练手更稳妥。5.2 网格搜索调三个核心参数不追求最优只追求稳定随机森林调参最容易陷入“参数玄学”。我的经验是只调n_estimators、max_depth、min_samples_leaf三个核心参数搜索空间控制在 12 组以内。n_estimators从 100 到 500 按 100 步进max_depth从 8 到 24 按 4 步进min_samples_leaf从 1 到 10 按 2 步进。搜索完成之后再跑一次滚动验证确认不同窗口下误差波动不大参数才算可靠。调参必须排在特征工程收敛之后否则调出来的是对错误特征的过度拟合这个顺序反了基本就要吃后悔药。5.3 从预测销量到补货建议最后一步的换算公式模型输出的预测值是“未来 7 天销量”要把它变成门店能直接执行的动作还需要减去当前库存并加上安全库存补货建议量 max(0, 预测未来 7 天销量 安全库存天数 × 日均销量 − 当前库存 − 在途库存)安全库存天数一般取 2 到 7 天具体看 SKU 的补货周期和缺货成本。如果门店物流周期是 3 天安全库存设为 2 天销量补货建议就不会频繁触顶。把预测结果、当前库存、建议补货量三列导出成 Excel按门店和 SKU 分组排序这份文件就是运营能直接执行的补货清单。交给业务之前一定记得把预测周期从“未来 7 天销量”改写成“本次建议补货量”并把安全库存的假设写清楚。数据挖掘项目里模型再好落到补货单上的公式不对前面的工作都白费。这几年做下来我最大的心得是库存预测项目少折腾模型多花时间确认安全库存怎么定、预测周期是周还是月这两件小事。希望帮到你。本文还有配套的精品资源点击获取
