简介这是一份围绕2023年全国大学生数学建模竞赛C题“蔬菜类商品自动定价与补货决策优化”的完整资源包包含论文定稿、Python源码、数据处理及建模分析笔记面向参加数模竞赛的学生、数据分析学习者以及毕业设计开发者。压缩包共46个文件约11.9MB其中以xlsx数据表24个和ipynb分析脚本9个为主体另有py脚本、zbak备份、PDF论文及readme说明。代码覆盖第一问聚类分析、第二问回归与规划求解、第三问ARIMA/GRU销量预测和混合整数规划等内容数据文件经过预处理可直接运行。目前已有105人学习下载。配套论文与代码目录清晰从数据清洗到优化决策形成完整链路既可用于赛题复盘也可作为课程设计或毕业设计的参考模板适合不同基础水平的读者按需使用。1. 蔬菜定价与补货为什么一个看似简单的C题让队伍集体翻车蔬菜类商品的自动定价与补货决策优化是2023年全国大学生数学建模竞赛C题的核心主题。很多队伍拿到题后以为只是套个线性回归加个规划求解就能交差结果第一轮数据预处理就发现同一种蔬菜在不同日期的批发价波动能超过40%销量在周末翻倍、在雨天腰斩而损耗率又跟存放天数直接挂钩。定价和补货不是两个独立问题——价格定高了销量掉、损耗增加补货补多了烂在库里补少了又损失销售额。这篇笔记围绕C题的论文结构、代码实现和数据处理流程讲清楚从原始表格到可提交的优化方案中间到底有哪些绕不开的步骤和坑。适合两类读者一类是准备打数学建模竞赛的学生需要一套能复现的完整链路另一类是实际做生鲜零售SKU运营的从业者想看看这套经典模型能不能迁移到自己的品类上。文中所有代码基于Python数据逻辑参考C题常见的销售流水表、批发价格表和损耗率表结构。2. 先把数据码齐蔬菜品类日销数据的清洗、对齐与聚合2.1 原始数据长什么样销售流水、批发价格、损耗率三张表的对齐逻辑C题通常会给三张核心表销售流水表记录每个单品每天的销量和售价批发价格表记录每天各蔬菜品类的进货价损耗率表记录不同存放天数下的损耗比例。三张表的主键不同销售流水是“单品日期”粒度批发价格是“品类日期”粒度损耗率是“品类存放天数”粒度对齐它们需要两次关联。第一层对齐是把单品映射到品类。蔬菜单品数量多如果不先归到品类维度后面建模的样本量会被稀释到每个单品只有几十条记录回归根本跑不稳。第二层对齐是把售价和批发价放到同一行这样才能计算加价率。常见做法是保留销售流水里的实际售价作为零售价批发价表按日期关联若某天批发价缺失用前后两天的均值填充。import pandas as pd import numpy as np # 假设三张表已读入 sales pd.read_csv(sales_flow.csv, parse_dates[date]) wholesale pd.read_csv(wholesale_price.csv, parse_dates[date]) loss pd.read_csv(loss_rate.csv) # 单品到品类的映射表手工维护 category_map pd.read_csv(item_category.csv) # 第一步销售流水关联品类 sales sales.merge(category_map, onitem_id, howleft) # 第二步按品类日期聚合销量和平均售价 daily sales.groupby([category, date]).agg( qty(qty, sum), price(price, mean) ).reset_index() # 第三步关联批发价缺失用前后均值填充 daily daily.merge(wholesale, on[category, date], howleft) daily[wholesale_price] daily[wholesale_price].interpolate(limit2) # 第四步关联损耗率 daily daily.merge(loss, oncategory, howleft)这段代码的逻辑重点在第三步的interpolate。批发价格缺失如果直接删除行会让后续时间序列分析出现断点如果填充0会让加价率变成无穷大。limit2表示连续缺失超过两天就不填因为这些数据点本身可信度低留着反而干扰模型。聚合时用平均售价而不是中位数是因为后续定价模型要处理的是价格弹性均值对价格变化的敏感度更稳定。2.2 按“品类日期”聚合的最小脚本与参数说明有些队伍拿到数据后直接对单品建模一个单品一条回归线结果大部分单品因为数据量太少系数符号都是反的。我一般会先做一次品类维度的探索性分析确认每个品类的销量序列形态再决定建模粒度。聚合粒度有三个选择单品、品类、品类销售渠道。对于C题到品类粒度就够没必要拆渠道因为题目通常只给了单一渠道的数据。# 检查每个品类的数据覆盖天数和销量分布 coverage daily.groupby(category).agg( days(date, nunique), total_qty(qty, sum), avg_qty(qty, mean), std_qty(qty, std) ).reset_index() # 过滤掉覆盖天数不足30天的品类 valid coverage[coverage[days] 30] daily daily[daily[category].isin(valid[category])] # 输出品类清单确认建模范围 print(valid.to_string(indexFalse))参数说明days 30是经验值因为后面要做的星期效应分析至少需要4个完整星期才能看到稳定的周末峰值低于30天连季节性都看不出来回归系数方差会非常大。std_qty列是用来观察销量波动性的如果某个品类标准差是均值的两倍以上基本可以判断该品类存在明显的缺货断档或者价格剧烈调整这类品类后面需要单独处理。2.3 异常值的三个典型形态和处理阈值蔬菜数据的异常值比一般零售数据更麻烦因为“异常”不一定是错误可能是真实的促销、天气或者断货。直接删掉会丢失信息不处理又会让回归模型被少数极端点牵着走。我常用的策略是分三档处理。第一档是负值和零值。销量不可能为负出现负值通常是退货冲正这类记录直接删除。销量为0有两种可能真没卖出去或者缺货。如果某天销量为0但后面三天销量突然暴涨说明是断货后补货导致的积压需求释放此时0应该替换为前7天均值的一半表示“本来可以卖出的量”。# 处理负值和零值 daily[qty_clean] daily[qty].clip(lower0) # 断货判断连续3天以上销量为0 zero_run daily.groupby(category)[qty].apply( lambda x: x.eq(0).astype(int).groupby((x.ne(0)).cumsum()).cumsum() ) daily[zero_run] zero_run.reset_index(level0, dropTrue) # 替换断货日的销量为前7天均值的一半 mask daily[zero_run] 3 daily.loc[mask, qty_clean] daily.groupby(category)[qty].transform( lambda x: x.replace(0, np.nan).ffill().rolling(7, min_periods3).mean() ).shift(1) * 0.5第二档是价格异常。批发价比前一天的波动超过30%先别急着改检查当天是否是节假日或者极端天气如果无法验证就按前后3天均值平滑。第三档是销量尖峰某天销量是前后7天均值的3倍以上且当天没有促销记录或价格下调这种数据点大概率是录入错误直接cap在1.5倍均值。阈值为什么选3倍和30%因为蔬菜品类价格波动本身就大2倍波动太敏感会把正常的价格调整当成异常4倍以上又会漏掉真正的录入错误。3倍是经过多个品类样本对比后比较稳的折中值实际使用时可以先看一眼数据分布再微调。3. 需求预测把“销量”拆成趋势、星期效应和价格响应3.1 为什么直接对原始销量做线性回归会失败周末效应与断货截断很多队伍第一版模型就是qty ~ price一元回归结果发现价格系数是正的——价格越高销量越多完全违背经济学直觉。原因很简单蔬菜销量受星期因素影响极大周六日家庭采购需求暴涨此时价格往往也处于一周高位如果不控制星期因素价格和星期效应混杂在一起回归系数自然被带偏。另一个隐蔽问题是断货截断censoring。缺货日的销量记作0但真实需求不是0只是供给跟不上。把这堆0放进回归里会把需求曲线整体向下拉导致价格弹性被高估。前面数据处理阶段把断货日销量做了替换这一步就是为了缓解截断问题。我习惯先做一步可视化检查按星期几分组看销量均值再按价格四分位分组看销量均值。如果周二到周四的销量明显低于周六日同时高价日的销量并不低说明价格弹性可能被星期效应掩盖直接建模会翻车。3.2 用带价格弹性项的多元回归做日销量预测在控制星期效应的基础上销量模型至少需要四类变量趋势项长期增长或下降、星期哑变量周内季节性、价格项对数价格或价格水平、节假日哑变量例如大多数假期周围销量会升。对于蔬菜品类我一般用对数销量作为因变量这样价格系数直接就是弹性解释起来方便。import statsmodels.api as sm # 构造特征 daily[log_qty] np.log(daily[qty_clean] 1) daily[log_price] np.log(daily[price]) daily[dayofweek] daily[date].dt.dayofweek # 星期哑变量周一为基准 dummies pd.get_dummies(daily[dayofweek], prefixdow, drop_firstTrue) features pd.concat([daily[[log_price, log_qty]], dummies], axis1) # 趋势项用日期序号替代时间序列 features[trend] np.arange(len(daily)) / len(daily) # 加节假日哑变量假设holiday列已标记 features[holiday] daily[holiday].astype(int) # 拟合 model sm.OLS(features[log_qty], sm.add_constant(features[[log_price, trend, holiday, dow_1, dow_2, dow_3, dow_4, dow_5, dow_6]])).fit() print(model.summary())参数说明log_price的系数就是价格弹性一般蔬菜类目在-0.3到-1.2之间如果跑出来是正的基本可以断定星期效应没控制住。trend归一化到0-1区间是为了避免和常数项产生数值问题它的系数绝对值如果很大说明这个品类存在明显的生命周期要小心外推。dow_1到dow_6对应周二到周日基准是周一这样每个系数都表示相对于周一的增量。回归做完必须看两个诊断指标一个是R²蔬菜日销预测能到0.5以上就算不错别指望像工业品那样到0.9另一个是Durbin-Watson统计量如果远小于2说明残差存在强自相关意味着模型漏掉了重要的时间结构最常见的原因是没加入天气变量或促销变量。3.3 预测残差诊断什么时候该换模型残差诊断不是看R²就完事我习惯画三张图残差随时间的变化、残差对拟合值的散点、残差的自相关函数图。第一张图如果看到明显的聚类波动比如残差在某个时间段全是负的说明存在结构性变化可能是促销政策调整第二张图如果残差随拟合值放大成喇叭口说明对数变换不够需要改Box-Cox第三张图如果滞后1期和7期的自相关系数显著说明数据有周内自相关可以考虑加入销量滞后项。import matplotlib.pyplot as plt from statsmodels.graphics.tsaplots import plot_acf # 残差序列 resid model.resid # 自相关图重点看7阶滞后 fig, ax plt.subplots(1, 2, figsize(12, 4)) ax[0].plot(resid) ax[0].set_title(Residual over time) plot_acf(resid, lags14, axax[1]) # 若7阶自相关显著加入上周同日的销量作为特征 if abs(resid.autocorr(lag7)) 0.2: daily[lag7_qty] daily.groupby(category)[qty_clean].shift(7) print(建议加入lag7特征当前7阶自相关:, round(resid.autocorr(lag7), 3))lag7_qty会牺牲最早7天的数据但能明显吸收周内模式。加入后如果7阶自相关降到0.1以下说明模型结构对了如果降不下去问题大概率出在外部变量缺失——比如天气、促销、竞品价格这些C题数据里通常没有只能在论文里承认局限性或者用品类间的交叉效应来部分替代。4. 定价与补货联合优化从价格弹性到单品类利润最大化4.1 定价子问题价格弹性与成本约束下的最优加价率销量预测模型给出的是“在给定价格下能卖多少”定价优化的目标反过来在销量和价格的约束关系下找到让总利润最大的价格点。单品类利润表达式很简单利润 零售价 - 批发价 - 单位损耗成本× 销量。结合需求函数销量 A × 价格^弹性把价格设为自变量利润最大化问题就变成一维最优化。from scipy.optimize import minimize_scalar # 需求函数参数假设已经从回归中提取 A np.exp(model.params[const] model.params[trend] * 0.5 # 取趋势中位数 model.params[dow_6] * 1) # 周六基准场景 elasticity model.params[log_price] wholesale_cost 5.2 # 单位批发成本示例 loss_cost 0.3 # 单位损耗成本分摊 def profit(price): qty A * (price ** elasticity) return -(price - wholesale_cost - loss_cost) * qty # 价格搜索范围, 限制为批发价的1.2到2.0倍 bounds (wholesale_cost * 1.2, wholesale_cost * 2.0) res minimize_scalar(profit, boundsbounds, methodbounded) optimal_price res.x max_profit -res.fun print(f最优定价: {optimal_price:.2f}, 预期单日利润: {max_profit:.2f})优化目标取负号是因为minimize_scalar只能做最小化。价格搜索上下限的设定不是随意来的蔬菜加价率低于20%基本覆盖不了损耗和运营成本高于100%则会触发消费者的替代购买行为所以1.2到2.0倍是比较合理的区间。如果某品类弹性小于-1富有弹性最优解往往贴近下限说明这类菜适合走薄利多销弹性大于-1缺乏弹性时定价可以往上限靠。4.2 补货子问题日补货量与损耗率、保质期的权衡补货决策的核心矛盾是多补可以降低缺货损失但会增加损耗成本。C题给的损耗率表通常按存放天数给出阶梯比例——存放1天损耗2%存放2天损耗5%存放3天以上损耗15%。这意味着如果一次补足两天的量第二天卖剩下的部分要计提更高的损耗。# 补货优化模型: 单品类简版 def replenishment_cost(order_qty, forecast_daily, loss_schedule, holding_days): order_qty: 当天补货量 forecast_daily: 未来每天的预测销量 loss_schedule: 第n天的损耗率 {1: 0.02, 2: 0.05, 3: 0.15} holding_days: 最多存放天数 total_loss 0 remaining order_qty for day in range(1, holding_days 1): if remaining 0: break # 当天预计销量 sell min(remaining, forecast_daily[day-1]) # 当天损耗 当天剩余量按损耗率计提 day_loss remaining * loss_schedule.get(day, 0.2) total_loss day_loss remaining - sell return total_loss # 暴力搜索补货量: 从预测总销量的0.8倍到1.5倍 forecast [80, 100, 120] # 未来三天预测销量 loss_sched {1: 0.02, 2: 0.05, 3: 0.15} best_qty, best_loss 0, float(inf) for qty in range(int(sum(forecast)*0.8), int(sum(forecast)*1.5)1, 5): loss replenishment_cost(qty, forecast, loss_sched, holding_days3) if loss best_loss: best_loss loss best_qty qty print(f最优补货量: {best_qty}, 预期损耗量: {best_loss:.1f})这段代码的forecast是未来三天的独立预测值实际使用时我会把第2天和第3天的预测打个折扣因为越远的天数预测误差越大补货决策的置信度越低。暴力搜索步长选5的倍数是为了贴近蔬菜的订货单位按箱或按把连续整数搜索得到的解虽然更精确但在实际采购中不可操作。4.3 联合求解分品类滚动优化的实现框架定价和补货分开求解的问题是价格会影响销量而补货量又依赖销量预测两个子问题有耦合关系。更稳的做法是用一个滚动决策框架在同一套预测数据上迭代求解两个子问题得到一组“定价补货”的联合方案。# 滚动优化框架: 对每个品类依次求解 results [] for category in valid[category]: cat_data daily[daily[category] category].copy() # 步骤1: 用最近30天数据重新拟合需求模型 # 此处省略回归拟合过程直接用已有模型预测 # 步骤2: 求解最优定价 price_opt solve_price(cat_data, model, category) # 步骤3: 用最优定价更新销量预测 forecast_new predict_qty(cat_data, price_opt, category) # 步骤4: 求解最优补货量 qty_opt solve_replenishment(forecast_new) results.append({ category: category, price: price_opt, order_qty: qty_opt, expected_profit: compute_profit(price_opt, qty_opt, cat_data) }) result_df pd.DataFrame(results) print(result_df.head())联合求解的意义在于如果先定高价再补货销量预测会偏低补货量也随之偏低容易缺货如果先定补货量再定价又没法判断这个价格下的销量是否值得补那么多货。滚动框架把两个决策放在同一轮预测中互相校准虽然不保证全局最优但更接近实际运营节奏——每天的决策本来就是基于当天最新的预测。5. 避坑指南数学建模C题里最容易失分的五个细节5.1 坑一损耗率被当成固定参数实际是随存放天数变化的现象很多队伍在利润函数里用单一损耗率5%写到底结果论文里的利润虚高评委一问损耗怎么算就答不上来。原因C题给的损耗率表明确按存放天数区分蔬菜存放第一天和存放第三天的损耗天差地别。把损耗当常数等于假设所有存货当天全部卖完这明显不合常理。解决损耗率必须和补货量、预测销量联动。我用的方法是按天推算库存剩余量每天按对应天数的损耗率计提损耗然后才计算当日可销售量。如果存放超过保质期剩余库存直接按100%损耗处理这一步能防止模型把大量补货包装成“高利润”。5.2 坑二周六日销量翻倍但预测模型里没有星期哑变量现象回归模型的价格弹性为正或者预测残差按星期呈现规律性波动模型整体失效。原因蔬菜消费的星期效应非常强周末家庭采购量可以比工作日高50%到100%。如果不加星期哑变量星期效应会混入价格变量和截距项所有系数的解释都失去意义。解决在需求模型中强制加入6个星期哑变量以周一为基准并单独报告周末效应的大小。如果周末系数显著为正但价格弹性依然为正说明数据质量问题比模型问题更严重回到数据清洗环节检查是否有价格录入颠倒。5.3 坑三缺货日销量为0直接把均值拉低现象某品类一周7天里有2天销量为0但实际是因为断货不是没人买。把0放进训练集后预测值被系统性拉低补货量偏小形成“越缺货越预测少越预测少越缺货”的死循环。原因0销量在缺失数据语义下是“断货截断”而非真实需求。回归模型会把截断点当成真实的零需求点导致需求曲线下移。解决断货日的销量用前7天正常销量的50%替代同时把断货标记作为独立特征放入模型。替代比例50%是经验值不同品类可以微调但方向必须是“替代而非删除”删除会让时间序列出现缺口替代能保留趋势信息。5.4 坑四价格与销量同期回归存在内生性偏差现象价格弹性估计值异常大小于-2或者价格对销量的影响在不同时间段不稳定。原因价格和销量在同一期回归存在同步偏差——商家往往在销量差的时候降价在销量好的时候提价回归看到的是“价格跟着销量走”而不是“销量跟着价格走”。数学上这是联立方程偏差OLS估计量不一致。解决至少做两件事。第一价格变量用上一期的价格替代当期价格相当于假设今天的价格影响明天的销量这更符合蔬菜定价周期第二在论文里明确说明这是简化处理并用两阶段最小二乘法做稳健性检验工具变量可以用批发价批发价影响售价但不直接影响零售销量。5.5 坑五补货量约束被忽略最优解超出实际货架容量现象优化模型给出的补货量是当天预测销量的两倍看起来利润很高但现实里货架根本摆不下或者冷库容量不够。原因纯数学优化没有加货架容量、采购预算、单品最小起订量这三类现实约束。C题虽然不要求完全贴近运营但完全不提约束会让模型显得没有工程常识。解决在补货优化中至少加入两个硬约束单日补货量不超过该品类历史最大日销量防止囤货总补货金额不超过当日采购预算。这两条约束在论文里花两行字说明就能体现建模完整度得分差异往往就在这里拉开。6. 把结果落地用滚动回测验证定价补货策略的收益提升6.1 滚动回测框架训练窗口与决策窗口的划分模型做出来以后不能只看拟合优度必须做滚动回测。回测的意义是模拟“如果历史上每天按我的策略定价和补货累计利润是多少”。训练窗口选60天决策窗口选1天每次滚动1天重复30次取累计利润和缺货率的平均值作为策略效果的度量。# 滚动回测: 简化版 train_days 60 backtest_days 30 daily_results [] for t in range(train_days, len(daily) - 1): train_data daily.iloc[t - train_days: t] test_data daily.iloc[t: t 1] # 用训练窗口拟合模型 model fit_demand_model(train_data) # 在测试日求解定价和补货 price_opt solve_price(model, test_data) qty_opt solve_replenishment(model, price_opt, test_data) # 记录实际利润 actual_qty test_data[qty_clean].values[0] actual_profit (price_opt - test_data[wholesale_price].values[0]) * min(actual_qty, qty_opt) daily_results.append(actual_profit) print(f回测期平均日利润: {np.mean(daily_results):.2f})滚动回测要注意训练数据和测试数据的时间顺序不能乱每轮只能用到当前时间点之前的信息。train_days60是对样本量和时效性的折中——太短模型参数不稳太长会包含过时的价格关系。回测结果里利润波动很大是正常的重点看累计值和趋势而不是单日表现。6.2 对比基线固定加价率 vs 动态定价的毛利差异回测的另一个关键步骤是设置基线策略。最简单的基线是“固定加价率”所有品类统一按批发价的1.3倍定价补货量按前7天平均销量补。把动态定价策略的累计利润和基线做对比才能说清楚优化到底带来多少收益。我习惯输出三组对比数据累计利润、缺货天数占比、损耗率。动态定价在利润上的提升通常在5%到15%但缺货天数占比可能上升因为价格调高后销量预测下降补货量也随之减少。这时候要检查是否因为预测模型低估了价格高位的真实需求如果是说明价格弹性估计偏保守需要调整弹性系数。6.3 一个习惯每次跑完把模型参数和回测结果存档这是我从多次建模比赛中养成的习惯每次实验跑完把用的特征、回归系数、回测利润、数据清洗版本号存成一个字典再Json序列化落盘。原因很简单——建模过程会反复改参数如果没有存档两周后根本说不清当前结果对应哪组配置。存档文件名带上日期和实验序号比如exp_20231015_v3.json。import json experiment { date: 2023-10-15, features: [log_price, trend, dow_1, dow_6, holiday], elasticity: round(model.params[log_price], 3), backtest_profit: round(np.mean(daily_results), 2), data_version: v3, note: 加了lag7特征, 周末弹性分离 } with open(exp_20231015_v3.json, w) as f: json.dump(experiment, f, ensure_asciiFalse, indent2)这个习惯在写论文时帮了大忙。每次答辩被问到“你这里为什么用这个参数”直接打开存档解释当时的实验逻辑比现场回忆靠谱得多。如果哪天跑出来的结果比之前好但回看存档发现改动路径根本不清晰那这次改进就不能写进论文——因为无法复现的结果等于没有结果。希望这个滚动回测和存档的组合能帮到你至少让你在建模赛里少走我当年走过的弯路。本文还有配套的精品资源点击获取