简介本资源是一份面向数据分析初学者与课程设计学生的Python销售预测实战项目聚焦商品销量趋势建模与业务洞察覆盖数据清洗、特征工程、时序建模与结果可视化全流程。压缩包共72个文件含20个核心Python脚本含LSTM、逻辑回归等模型实现、15个CSV数据集如sales_train.csv、shops.csv等、11张分析图表如item_cnt_day分布图、loss/acc曲线图及2份Word设计报告辅以Markdown说明、PyTorch模型权重.pth和HTML提交成果页结构完整、模块清晰便于分步学习与复现。资源大小20.04MB已有1719人学习下载。读者可直接获取从原始数据加载、EDA探索、训练集划分X_train/Y_train、多模型对比到最终submission生成的端到端代码链同时配套详细实验报告与分析思路特别适合课程设计、毕业实践或Kaggle入门级销售预测任务参考。1. 为什么用 Python 做商品销售预测不是“跑个 LSTM 就完事”你手上有三年的 POS 系统导出 CSV每天每 SKU 的销量、促销标记、节假日标签、库存水位、甚至天气温度——但 Excel 折线图只能告诉你“上个月卖得比前个月多”而老板问的是“下周五爆款 A 还剩 37 件要不要今晚紧急补货补多少”这不是时间序列拟合题是带约束的决策问题销量受促销节奏扰动剧烈某次满减让日销翻 4 倍但三天后跌回原点新品上市无历史数据竞品价格变动在原始数据里根本没字段。“通过Python对商品销售数据预测.zip”这个标题本质是交付一个可落地的预测工作流从原始杂乱数据清洗 → 特征工程建模 → 多粒度输出SKU/品类/门店级→ 可解释性归因告诉业务“为什么预测值是 216 件”→ 预测结果自动写入业务系统接口。它不依赖 TensorFlow 大模型或 Kaggle 冠军方案核心是用pandasscikit-learnstatsmodels构建轻量、可维护、能嵌入现有 ERP 的 pipeline。适合零售运营、电商数据岗、快消业 BI 工程师——尤其当你被要求“下周就上线试运行”而不是等三个月调参。2. 数据准备与特征工程别让脏数据毁掉所有模型商品销售预测的成败80% 在数据预处理阶段。原始数据常含三类致命问题时间戳错乱、SKU 编码不一致、促销信息缺失。我见过某连锁超市的销售表里“2023-02-30”出现 17 次“SKU_001A”和“sku001a”被当两个商品“是否促销”列填着“是/否/YES/NULL/空格”。不解决这些任何模型都是垃圾进、垃圾出。2.1 时间序列对齐强制统一采样粒度销售数据天然按交易时间记录但预测需固定周期如日粒度。关键不是简单resample(D).sum()而是处理跨日订单拆分如 23:59 下单实际发货在次日和节假日平移春节假期销量归零但不能简单填充 0否则模型学不会“节前囤货”模式。import pandas as pd from datetime import datetime, timedelta # 假设原始数据 df_raw 包含 order_time, sku_id, qty, promo_flag df df_raw.copy() df[order_time] pd.to_datetime(df[order_time]) # 关键按业务定义“销售日”——以发货时间为准而非下单时间 # 此处用发货时间字段若无则按经验规则当日 22:00 后下单计入次日 df[sale_date] df[order_time].apply( lambda x: x.date() if x.hour 22 else (x timedelta(days1)).date() ) df[sale_date] pd.to_datetime(df[sale_date]) # 按 SKU日期聚合避免同一日多笔订单重复计数 df_daily df.groupby([sku_id, sale_date])[qty].sum().reset_index()提示sale_date必须用pd.to_datetime()转为 datetime 类型否则后续set_index()会报错groupby后务必.reset_index()否则sku_id会变成索引导致后续 merge 失败。2.2 SKU 维度标准化用主数据字典做硬校验不同系统导出的 SKU 编码常有大小写、前缀、后缀差异。直接str.upper()不够——某品牌“iPhone14-128GB-Black”和“IPHONE14_128G_BLACK”需映射到同一 ID。# 加载主数据字典业务方提供CSV 格式 sku_mapping pd.read_csv(master_sku_dict.csv) # 列raw_code, standard_sku, category, is_new_product sku_mapping[raw_code] sku_mapping[raw_code].str.strip().str.upper() # 构建映射字典原始编码 → 标准 SKU mapping_dict dict(zip(sku_mapping[raw_code], sku_mapping[standard_sku])) # 应用映射未匹配项标记为 UNKNOWN df_daily[standard_sku] df_daily[sku_id].str.strip().str.upper().map(mapping_dict).fillna(UNKNOWN) # 过滤掉 UNKNOWN即无法识别的 SKU通常为测试数据或废弃品 df_clean df_daily[df_daily[standard_sku] ! UNKNOWN].copy()参数说明strip()清除首尾空格upper()统一大小写map()比replace()更安全不匹配时返回 NaN可显式处理。fillna(UNKNOWN)是防御性编程——后续可统计 UNKNOWN 占比若 5%需推动业务方更新主数据字典。2.3 特征构造业务逻辑必须编码进特征销售预测不是纯数学游戏。以下特征经实战验证有效特征类型字段名构造逻辑业务意义滞后特征qty_lag7,qty_lag30df.groupby(standard_sku)[qty].shift(7)捕捉周/月周期性比单纯时间序列更鲁棒促销强度promo_score(促销天数 / 30) * 平均折扣率量化促销影响避免二值变量丢失力度信息库存预警stock_shortage_flag库存量 7日平均销量 * 1.5库存不足时销量会断崖下跌需单独建模竞品动作comp_price_change_7d外部爬虫数据近 7 日竞品均价变动率未接入时设为 0预留扩展接口# 构造滞后特征按 SKU 分组计算避免跨 SKU 泄漏 for lag in [1, 7, 14, 30]: df_clean[fqty_lag{lag}] df_clean.groupby(standard_sku)[qty].shift(lag) # 构造促销强度需先有促销日历表 promo_calendar promo_calendar pd.read_csv(promo_calendar.csv) # 列date, sku_id, discount_rate, duration_days promo_calendar[date] pd.to_datetime(promo_calendar[date]) promo_calendar[promo_score] (promo_calendar[duration_days] / 30) * promo_calendar[discount_rate] # 按日期和 SKU merge 到主表 df_clean df_clean.merge( promo_calendar[[date, sku_id, promo_score]], left_on[sale_date, standard_sku], right_on[date, sku_id], howleft ).fillna({promo_score: 0}) # 无促销则为 0 # 库存预警特征假设库存表 stock_data 已加载 stock_data pd.read_csv(stock_data.csv) stock_data[date] pd.to_datetime(stock_data[date]) df_clean df_clean.merge( stock_data[[date, sku_id, stock_qty]], left_on[sale_date, standard_sku], right_on[date, sku_id], howleft ) # 计算 7 日平均销量窗口内不包含当前日 df_clean[qty_mean7] df_clean.groupby(standard_sku)[qty].transform( lambda x: x.rolling(window7, min_periods1).mean().shift(1) ) df_clean[stock_shortage_flag] (df_clean[stock_qty] df_clean[qty_mean7] * 1.5).astype(int)注意rolling().mean().shift(1)是关键——用过去 7 天均值预测今日避免未来信息泄露transform保证每行都计算不丢失行数。3. 模型选型与训练为什么不用 LSTM而选 LightGBM Prophet 组合面对商品销售数据常见误区是“预测就该用深度学习”。但实测发现LSTM 在小样本2 年数据、高噪声促销干扰、多 SKU 场景下泛化能力远低于树模型。某零食品牌 2000 SKULSTM 训练耗时 8 小时RMSE 比 LightGBM 高 23%且无法解释“为什么预测值突增”。3.1 主模型LightGBM 处理结构化特征LightGBM 对类别特征如品类、门店、缺失值、异常值鲁棒且支持categorical_feature参数直接处理字符串型变量如category字段无需 one-hot 编码爆炸维度。from lightgbm import LGBMRegressor from sklearn.model_selection import TimeSeriesSplit from sklearn.metrics import mean_absolute_error, mean_squared_error # 准备特征矩阵 X 和目标 y feature_cols [ qty_lag1, qty_lag7, qty_lag14, qty_lag30, promo_score, stock_shortage_flag, is_holiday, temp_celsius, # 天气等外部特征 ] X df_clean[feature_cols].fillna(0) # LightGBM 可处理 NaN但显式 fillna 更可控 y df_clean[qty] # 时间序列交叉验证避免未来信息泄露 tscv TimeSeriesSplit(n_splits5) lgb_model LGBMRegressor( objectiveregression, n_estimators300, learning_rate0.1, max_depth6, # 防止过拟合商品数据不宜太深 categorical_feature[is_holiday], # 显式声明类别特征 random_state42 ) # 训练并评估 mae_scores, rmse_scores [], [] for train_idx, val_idx in tscv.split(X): X_train, X_val X.iloc[train_idx], X.iloc[val_idx] y_train, y_val y.iloc[train_idx], y.iloc[val_idx] lgb_model.fit(X_train, y_train) y_pred lgb_model.predict(X_val) mae_scores.append(mean_absolute_error(y_val, y_pred)) rmse_scores.append(mean_squared_error(y_val, y_pred, squaredFalse)) print(fLightGBM MAE: {np.mean(mae_scores):.2f} ± {np.std(mae_scores):.2f}) print(fLightGBM RMSE: {np.mean(rmse_scores):.2f} ± {np.std(rmse_scores):.2f})参数说明max_depth6是血泪经验——深度 8 时模型开始拟合促销噪声如某次临时加购导致单日销量峰值而非真实趋势categorical_feature若不声明LightGBM 会把is_holiday当数值型处理导致错误分裂。3.2 辅助模型Prophet 处理长周期趋势与节假日Prophet 擅长捕捉年周期、节假日效应但对促销等短期扰动不敏感。我们用它生成趋势基线再用 LightGBM 学习残差即促销、库存等扰动部分。from prophet import Prophet # Prophet 输入格式ds日期, y销量 prophet_df df_clean[[sale_date, qty]].rename(columns{sale_date: ds, qty: y}) prophet_df prophet_df.sort_values(ds) # 添加节假日需业务方提供 holidays pd.DataFrame({ holiday: [spring_festival, national_day], ds: pd.to_datetime([2023-01-22, 2023-10-01]), lower_window: -3, upper_window: 7 }) m Prophet(holidaysholidays, yearly_seasonalityTrue, weekly_seasonalityTrue) m.fit(prophet_df) # 预测未来 7 天趋势基线 future m.make_future_dataframe(periods7) forecast m.predict(future) trend_baseline forecast.set_index(ds)[trend].reindex(df_clean[sale_date]).values # 将趋势基线作为新特征加入 LightGBM 训练 X[trend_baseline] trend_baseline为什么组合有效Prophet 提供稳定趋势如“每年 618 销量涨 30%”LightGBM 专注学习“本次 618 比去年多涨 12% 是因为直播带货”——分工明确互不干扰。4. 避坑商品销售预测的 4 个高频翻车点商品销售预测不是调包跑通就行业务场景的特殊性带来独特陷阱。以下是我踩过的坑按“现象→原因→解决”整理避免你重蹈覆辙。4.1 现象模型在训练集上 MAE5验证集 MAE45但业务说“预测值全不准”原因未处理销量为 0 的大量长尾 SKU。某超市 80% 的 SKU 日均销量 ≤2 件其中 60% 有连续 15 天销量为 0。LightGBM 默认回归目标对 0 值预测偏差极大如预测 0.3 件实际 0 件MAE0.3但预测 1.2 件实际 0 件MAE1.2误差放大 4 倍。解决分层建模对日均销量 10 件的 SKU 用回归模型对 ≤10 件的 SKU 改用分类模型预测“是否售出”回归模型预测“售出量”目标函数改造用huber_loss替代mse对异常值更鲁棒后处理截断预测值 0.5 时强制设为 0# 分层建模示例 high_volume_skus df_clean.groupby(standard_sku)[qty].mean().loc[lambda x: x 10].index df_high df_clean[df_clean[standard_sku].isin(high_volume_skus)] df_low df_clean[~df_clean[standard_sku].isin(high_volume_skus)] # 对低销量 SKU先分类是否售出再回归售出量 from sklearn.ensemble import RandomForestClassifier, RandomForestRegressor clf RandomForestClassifier(n_estimators100) X_low_class df_low[feature_cols].fillna(0) y_low_class (df_low[qty] 0).astype(int) # 二分类目标 clf.fit(X_low_class, y_low_class) # 对售出的样本再预测具体销量 df_low_sold df_low[df_low[qty] 0] reg RandomForestRegressor(n_estimators100) X_low_reg df_low_sold[feature_cols].fillna(0) y_low_reg df_low_sold[qty] reg.fit(X_low_reg, y_low_reg)4.2 现象加入天气特征后模型在雨天预测准确率飙升晴天暴跌原因天气数据源与销售数据时间戳未对齐。销售数据是“日销量”天气数据是“日最高温”但模型误将“今日最高温”关联到“今日销量”——而实际是“昨日下雨导致今日顾客进店少”。因果时序错位。解决所有外部特征天气、竞品价、舆情必须做lag 处理确保是“预测日之前已知信息”在特征工程阶段显式添加_lag1后缀并检查corr矩阵验证时序合理性# 正确做法天气特征滞后 1 天 weather_data pd.read_csv(weather.csv) weather_data[date] pd.to_datetime(weather_data[date]) weather_data weather_data.sort_values(date) weather_data[temp_celsius_lag1] weather_data[temp_celsius].shift(1) # 昨日温度 # merge 时用 sale_date-1d 匹配昨日天气 df_clean df_clean.merge( weather_data[[date, temp_celsius_lag1]], left_ondf_clean[sale_date] - pd.Timedelta(days1), right_ondate, howleft )4.3 现象模型上线后某新品 SKU 预测值恒为 0但业务反馈“首周卖爆了”原因新品无历史销量所有滞后特征qty_lag7等全为 NaNLightGBM 默认填 0导致模型认为“永远不卖”。而业务实际靠营销拉动但营销特征如 KOL 曝光量未接入。解决新品冷启动策略对is_new_product1的 SKU跳过滞后特征改用品类均值 促销强度系数预留特征接口在特征工程模块中增加new_product_features字典动态注入新品专属特征# 新品预测逻辑 def predict_new_sku(row): # 基于品类均值取同类目 TOP10 SKU 的 7 日均值 cat_mean category_avg.loc[row[category], qty_mean7] # 乘以促销系数满减 1.5x直播 2.0x promo_factor {full_reduction: 1.5, live_stream: 2.0}.get(row[promo_type], 1.0) return max(1, int(cat_mean * promo_factor)) # 至少预测 1 件 # 在预测 pipeline 中分支处理 if row[is_new_product]: pred predict_new_sku(row) else: pred lgb_model.predict([row[feature_cols]])[0]4.4 现象预测结果导出 Excel 后业务抱怨“数字全是小数没法订货”原因回归模型输出连续值但实际订货需整数如“订 216.3 件”无效且需满足最小起订量MOQ和包装规格如 12 件/箱。解决后处理四舍五入 MOQ 对齐预测值向上取整至 MOQ 倍数输出多版本基础预测值、MOQ 对齐值、包装规格对齐值供业务选择def align_to_moq_and_pack(pred_qty, moq10, pack_size12): 将预测销量对齐至 MOQ 和包装规格 # 先满足 MOQ qty_after_moq max(moq, int(np.ceil(pred_qty))) # 再对齐包装规格向上取整至 pack_size 倍数 qty_final int(np.ceil(qty_after_moq / pack_size)) * pack_size return qty_final # 应用到预测结果 df_result[pred_qty_moq_aligned] df_result[pred_qty].apply( lambda x: align_to_moq_and_pack(x, moq10, pack_size12) )5. 预测结果落地与业务集成让模型真正驱动补货决策模型输出不是终点而是业务动作的起点。商品销售预测的价值在于把数字变成可执行指令——比如自动生成补货单、触发库存预警、同步 ERP 系统。本章聚焦如何将.zip中的预测脚本无缝嵌入现有业务流程。5.1 输出结构化结果不止是“预测值”还要“为什么”业务方不需要看 RMSE他们需要知道“为什么预测明天卖 216 件”——这决定是否追加促销。因此预测结果必须包含可解释性归因。LightGBM 自带feature_importance_但它是全局重要性我们需要单样本级归因用 SHAP 值。import shap # 计算 SHAP 值使用 TreeExplainer适配 LightGBM explainer shap.TreeExplainer(lgb_model) shap_values explainer.shap_values(X_test) # X_test 是待预测的特征矩阵 # 为每个预测样本生成归因报告 def generate_explanation(row_idx, shap_vals, feature_names, pred_value): # 获取该样本的 SHAP 值 shap_row shap_vals[row_idx] # 排序取 top3 影响因子 top3_idx np.argsort(np.abs(shap_row))[-3:][::-1] top3_features [feature_names[i] for i in top3_idx] top3_shap [shap_row[i] for i in top3_idx] explanation f预测值 {pred_value:.0f} 件主要驱动因素\n for feat, shap_val in zip(top3_features, top3_shap): effect 正向 if shap_val 0 else 负向 explanation f- {feat}: {effect}贡献 {abs(shap_val):.1f} 件\n return explanation # 示例为第一条预测结果生成解释 explanation generate_explanation(0, shap_values, feature_cols, y_pred[0]) print(explanation) # 输出 # 预测值 216 件主要驱动因素 # - promo_score: 正向贡献 42.3 件 # - qty_lag7: 正向贡献 28.1 件 # - stock_shortage_flag: 负向贡献 -15.7 件落地价值这份解释可直接嵌入补货系统弹窗——当采购员看到“促销贡献 42 件”就会确认今晚加推满减活动看到“库存不足负贡献 -15 件”立刻检查仓库。5.2 自动生成补货建议从预测值到动作指令预测值需转化为具体动作。我们设计三层补货逻辑覆盖不同业务场景场景触发条件补货建议输出字段常规补货预测销量 当前库存 * 1.2补货至预测销量 * 1.5reorder_qty,reorder_date紧急补货预测销量 当前库存且预测日 ≤ 3 天后立即补货加急物流urgency_levelHIGH清仓建议预测销量 5且库存 50发起促销或调拨actionDISCOUNT# 假设已有库存表 stock_status stock_status pd.read_csv(stock_status.csv) # 列sku_id, current_stock, lead_time_days df_result df_clean.merge(stock_status, onstandard_sku, howleft) # 计算补货建议 df_result[reorder_qty] 0 df_result[urgency_level] NORMAL # 常规补货 mask_normal (df_result[pred_qty] df_result[current_stock] * 1.2) df_result.loc[mask_normal, reorder_qty] ( df_result.loc[mask_normal, pred_qty] * 1.5 ).round().astype(int) # 紧急补货 mask_urgent ( (df_result[pred_qty] df_result[current_stock]) (df_result[sale_date] pd.Timestamp.today() pd.Timedelta(days3)) ) df_result.loc[mask_urgent, reorder_qty] ( df_result.loc[mask_urgent, pred_qty] * 2 ).round().astype(int) df_result.loc[mask_urgent, urgency_level] HIGH # 清仓建议 mask_clear ( (df_result[pred_qty] 5) (df_result[current_stock] 50) ) df_result.loc[mask_clear, action] DISCOUNT df_result.loc[mask_clear, reorder_qty] 0关键细节lead_time_days采购前置期必须参与计算——若供应商要 5 天到货预测“3 天后销量”就不能等常规补货流程。5.3 与 ERP 系统对接用 API 替代手工 Excel 导入.zip中的脚本最终要接入 SAP 或用友 U8。我们采用轻量 REST API 方式避免侵入式改造。核心是定义标准 JSON 接口import requests import json # 构建补货建议 JSON reorder_payload { request_id: fREORDER_{datetime.now().strftime(%Y%m%d_%H%M%S)}, data: [] } for _, row in df_result.iterrows(): if row[reorder_qty] 0: payload_item { sku_id: row[standard_sku], reorder_qty: int(row[reorder_qty]), urgency_level: row[urgency_level], valid_from: row[sale_date].strftime(%Y-%m-%d), valid_to: (row[sale_date] pd.Timedelta(days7)).strftime(%Y-%m-%d), explanation: generate_explanation(...) # 上节的归因文本 } reorder_payload[data].append(payload_item) # 调用 ERP 接口示例地址需替换为实际 URL erp_url https://your-erp-api.com/v1/reorder-suggestions headers {Authorization: Bearer your_api_token, Content-Type: application/json} response requests.post(erp_url, datajson.dumps(reorder_payload), headersheaders) if response.status_code 200: print(补货建议已推送至 ERP) else: print(fERP 推送失败: {response.text})生产注意事项幂等性每次请求带唯一request_idERP 端需去重失败重试网络超时需自动重试 3 次间隔 1 秒日志审计记录每次推送的request_id、时间、成功/失败状态便于追溯6. 持续迭代如何让预测模型越用越准而不是上线即衰减模型上线不是终点而是持续优化的起点。商品销售数据最大的特性是业务策略持续变化——今年主打直播带货明年转向私域社群模型若不迭代三个月后预测准确率必然下滑。我的经验是建立“预测-反馈-再训练”闭环且自动化程度要高到“运维人员不碰代码也能完成”。6.1 设计反馈机制让业务方主动修正预测偏差最可靠的误差来源是业务一线的真实反馈。我们不依赖“预测 vs 实际”的离线报表而是让采购员在 ERP 系统里一键标记“预测不准”并选择原因如“竞品突然降价”、“门店装修停业”。这些反馈数据自动进入再训练管道。# 假设 ERP 返回反馈表 feedback.csv # 列sku_id, sale_date, predicted_qty, actual_qty, feedback_reason, is_corrected feedback pd.read_csv(feedback.csv) feedback[sale_date] pd.to_datetime(feedback[sale_date]) # 筛选被人工修正的样本业务员认为预测严重偏离 corrected_feedback feedback[feedback[is_corrected] 1] # 将修正样本加入训练集加权权重2.0强调业务判断 X_corrected corrected_feedback[feature_cols].fillna(0) y_corrected corrected_feedback[actual_qty] sample_weight np.full(len(X_corrected), 2.0) # 在下次训练中concat 到原始训练集 X_full pd.concat([X_train, X_corrected], ignore_indexTrue) y_full pd.concat([y_train, y_corrected], ignore_indexTrue) weights_full np.concatenate([np.ones(len(X_train)), sample_weight]) # LightGBM 支持 sample_weight 参数 lgb_model.fit(X_full, y_full, sample_weightweights_full)为什么有效业务反馈是最高质量的标注数据——它包含了模型无法感知的隐性知识如“某主播突发事故导致带货中断”。加权训练让模型优先学习这些关键案例。6.2 自动化再训练流水线每周日凌晨 2 点执行手动 retrain 是不可持续的。我们用cronPython构建全自动流水线核心是版本化模型与数据组件存储位置版本控制方式更新触发条件原始数据/data/raw/每日增量 CSV文件名含日期每日 1:00 AM 生成新文件清洗后数据/data/processed/每周快照data_20231020.parquet每周日 23:00 生成模型文件/models/lgb_v20231020.pkl文件名含日期每周一 2:00 AM 训练完成预测结果/output/prediction_20231020.csv每日输出每日 3:00 AM 生成# crontab -e 添加任务 # 每周一凌晨 2 点执行再训练 0 2 * * 1 cd /path/to/project python train_pipeline.py --version $(date \%Y\%m\%d)train_pipeline.py脚本逻辑加载最新清洗数据/data/processed/data_$(date -d last Sunday \%Y\%m\%d).parquet加载历史反馈数据合并到训练集用TimeSeriesSplit交叉验证保存新模型/models/lgb_v$(date \%Y\%m\%d).pkl用新模型预测下周 7 天输出/output/prediction_$(date \%Y\%m\%d).csv发送企业微信通知“新模型 lgb_v20231020 已上线预测准确率提升 2.3%”6.3 监控预测漂移当模型“变笨”时及时告警模型性能衰减往往悄无声息。我们监控两个核心指标预测分布漂移本周预测值的均值/方差 vs 上周变化 15% 则告警特征重要性漂移promo_score的重要性权重若从 35% 降至 12%说明促销策略失效模型需重构# 监控脚本 monitor_drift.py import numpy as np from sklearn.ensemble import RandomForestRegressor # 加载本周和上周预测结果 pred_this_week pd.read_csv(/output/prediction_20231020.csv) pred_last_week pd.read_csv(/output/prediction_20231013.csv) # 计算分布漂移 mean_drift abs(pred_this_week[pred_qty].mean() - pred_last_week[pred_qty].mean()) / pred_last_week[pred_qty].mean() std_drift abs(pred_this_week[pred_qty].std() - pred_last_week[pred_qty].std()) / pred_last_week[pred_qty].std() if mean_drift 0.15 or std_drift 0.15: send_alert(f预测分布漂移告警均值漂移 {mean_drift:.1%}标准差漂移 {std_drift:.1%}) # 加载本周和上周模型提取特征重要性 model_this_week joblib.load(/models/lgb_v20231020.pkl) model_last_week joblib.load(/models/lgb_v20231013.pkl) importance_this model_this_week.feature_importances_ importance_last model_last_week.feature_importances_ # 检查 promo_score假设索引为 3的重要性变化 promo_drift abs(importance_this[3] - importance_last[3]) / importance_last[3] if promo_drift 0.5: send_alert(f促销特征重要性剧变从 {importance_last[3]:.1%} 降至 {importance_this[3]:.1%})我的习惯把send_alert()接入企业微信机器人告警消息带直达链接——点击即跳转到模型诊断页面显示“哪些 SKU 漂移最严重”、“哪类促销失效”。这样算法工程师不用等邮件早上打开手机就能处理。希望帮到你。本文还有配套的精品资源点击获取