从数学建模到零售优化：蔬菜定价与补货决策实战解析

简介本资源是2023年全国大学生数学建模竞赛C题——蔬菜类商品自动定价与补货决策优化的完整参赛成果面向计算机、统计、运筹与管理科学等专业本科生及毕业设计群体聚焦生鲜供应链中损耗率高、需求波动大、定价与补货协同难等现实问题。压缩包共46个文件11.9MB含24个结构化Excel数据表如单品销售量、平均损耗率、ARIMA与GRU预测结果、9个Jupyter Notebook分析脚本覆盖聚类分析、箱线图可视化、混合整数规划求解、回归建模与时序预测、3个Python主程序含BONMIN求解器调用、1份PDF论文定稿及详细README说明文档。已有103人学习下载提供从原始数据清洗、多模型销量预测ARIMA/GRU、品类聚类与损耗建模到定价-补货联合优化的全流程实现代码可直接运行注释清晰适合作为毕设课题基础框架或建模能力进阶训练材料。1. 从竞赛题目到真实业务一次完整的数模实战复盘去年带队参加全国大学生数学建模竞赛我们组选的是C题“蔬菜类商品自动定价与补货决策优化”。说实话拿到题目那一刻感觉既兴奋又头大。兴奋的是这题目太“实”了直接戳中了生鲜零售行业的核心痛点——每天面对几百种蔬菜到底该卖多少钱该进多少货头大的是这问题背后是典型的“高维、动态、不确定”的商业决策难题从数据清洗到模型构建再到最后的策略输出每一步都是坑。比赛结束后我们团队把论文、代码和数据都整理了出来但总觉得缺了点什么。那些写在论文里的“假设”和“简化”在实际业务中真的行得通吗那些漂亮的模型曲线能经得起凌晨三点批发市场嘈杂人声和瞬息万变价格的考验吗今天我就以一个过来人的身份抛开竞赛论文的“学术滤镜”把这套“蔬菜定价与补货”的优化逻辑从理论到实践从代码到业务掰开揉碎了讲清楚。无论你是对数学建模感兴趣的学生还是对零售数字化运营有需求的从业者这篇文章或许能给你一些不一样的启发。2. 问题本质拆解定价与补货为何是“连体婴”在动手建模型、写代码之前我们必须先想明白蔬菜的定价和补货为什么必须放在一起优化这可不是出题老师故意为难我们而是生鲜零售业务内在的、无法割裂的孪生问题。2.1 定价与补货的耦合关系一个动态博弈想象一下你是一家社区生鲜店的店长。今天西红柿的进货价涨了你自然想提高售价来保证利润定价决策。但是如果你提价太高顾客可能就不买了导致晚上关门时还剩下一大堆这些西红柿明天就不新鲜了只能打折处理甚至扔掉反而造成更大损失。这里的损失专业术语叫“损耗”。反过来如果你为了清库存而大幅降价定价决策虽然卖得快了但单品的利润被摊薄总体营收可能还是上不去。同时你今天的销售情况和剩余库存补货决策的结果又会直接影响你明天该进多少西红柿补货决策。你看定价直接影响销售速度和库存结余而库存结余又直接决定了补货需求。这是一个闭环。在竞赛题目给出的场景里这种耦合关系被抽象为几个关键约束成本约束售价不能低于成本、需求弹性约束价格影响销量、库存容量约束货架和仓库就那么大、损耗约束蔬菜会随时间变质。我们的优化目标就是在满足这些约束的前提下最大化一段时间内的总利润或者更实际一点最大化“营收-成本-损耗”的综合收益。很多初次接触的同学容易把问题拆成两步先根据历史数据预测明天卖多少然后决定进多少货再根据进货成本和目标利润率定售价。这看似合理实则割裂了价格对需求的即时调节作用。正确的思路是建立一个联合决策模型让定价和补货量作为模型的两个输出变量同时被优化。2.2 从竞赛数据到业务数据我们缺失了什么竞赛提供的数据通常是清洗过的、结构化的比如过去N天各种蔬菜的销售流水、进货记录、成本变动。这已经比很多开放数据集要好了。但根据我们赛后和一些零售业朋友的交流真实业务数据要复杂和“脏”得多数据粒度问题竞赛数据往往是“天”级别但真实促销可能是“小时”级别的如晚市特价。蔬菜的新鲜度衰减曲线也不是按天计算的上午和下午的品相可能就有差异。外部因素缺失竞赛数据很少包含天气、节假日、周边竞品价格、社区活动等信息。而这些因素对蔬菜需求的影响可能比历史销量更大。比如明天预报有暴雨大家可能会囤菜叶菜类需求激增对面超市黄瓜打五折你的黄瓜定价就必须反应。损耗的量化难题竞赛中损耗可能用一个简单的线性或指数衰减模型来表示。现实中损耗与温度、湿度、摆放方式、翻拣次数都有关极难精确量化。通常业内会用“报损率”作为一个经验估计值。所以我们在构建模型时的第一个重要心得就是必须明确模型的边界和假设。我们的模型是在“给定数据条件下”的最优而不是“绝对真理”。在论文和代码中我们为损耗模型、需求函数都设置了可调节的参数就是为了让方案具备一定的适应性。接下来我们就深入模型内部看看具体是怎么实现的。3. 核心模型构建如何用数学语言描述生意这部分是整篇论文的精华也是代码实现的核心。我们采用了“数据驱动建模 运筹学优化”的混合框架整体思路分为三步需求预测、联合建模、策略求解。3.1 需求预测模型不仅仅是看昨天卖了什么定价的基础是预知需求。我们并没有采用复杂的深度学习模型如LSTM因为比赛时间有限且数据量可能不足以支撑深度网络训练容易过拟合。我们选择了集成树模型如LightGBM或XGBoost作为需求预测的核心。为什么处理混合类型特征能力强我们可以轻松地将类别特征蔬菜品类、星期几、数值特征历史价格、历史销量、成本以及构造的特征如过去3天的平均销量、与上周同期的销量比、是否节假日一起扔给模型。可解释性相对较好虽然不如线性回归那么直观但树模型可以提供特征重要性排序。这让我们能知道影响黄瓜销量的最主要因素是自身价格还是西红柿的价格替代品或者是天气温度。特征工程是关键中的关键。除了上述基础特征我们重点构建了几个交叉价格弹性特征计算本品类价格与相关替代品如黄瓜和西红柿或互补品如辣椒和蒜价格的比例或差值。衰减特征对于叶菜类引入“已上架时间”作为特征模拟新鲜度下降对需求的影响。趋势与波动特征计算销量的移动平均和标准差捕捉需求的稳定性和趋势。预测的目标变量不是“明天销量”的绝对点估计而是价格-销量关系曲线。也就是说对于一种蔬菜我们训练模型预测的是在不同定价水平下可能的销量分布。这为后续的优化提供了输入。3.2 联合优化模型将生意逻辑转化为数学公式这是最考验运筹学功底的一步。我们建立了一个多周期、多品类的随机规划模型。听起来高大上其实核心思想就是为一个虚拟的“店长”制定一份未来几天的“作战计划”。决策变量x_{i,t}第i种蔬菜在第t天的补货量。p_{i,t}第i种蔬菜在第t天的销售定价。I_{i,t}第i种蔬菜在第t天结束时的库存量。目标函数最大化总期望利润Maximize Σ_t Σ_i [ E( p_{i,t} * D_{i,t}(p_{i,t}) ) - c_{i,t} * x_{i,t} - h * I_{i,t} - θ * S_{i,t} ]其中D_{i,t}(p_{i,t})就是上一步需求预测模型给出的、关于价格的需求函数通常是一个随机变量比如服从某个分布。E(...)表示求期望因为需求不确定。c_{i,t}是进货成本。h * I_{i,t}是库存持有成本资金占用、仓储管理。θ * S_{i,t}是损耗成本S_{i,t}是损耗量θ是单位损耗成本通常≥进货成本因为包含了处理人工和浪费。核心约束条件库存平衡约束I_{i,t} I_{i,t-1} x_{i,t} - D_{i,t}(p_{i,t})。今天的期末库存等于昨天的库存加上今天的进货再减去今天的销量。需求函数约束D_{i,t}(p_{i,t})服从预测模型给出的分布。这是连接预测与优化的桥梁。能力约束Σ_i x_{i,t} C总补货量不能超过物流或仓储能力I_{i,t} S_i单个商品库存不能超过货架容量。价格约束p_{i,t} c_{i,t} * (1 m)售价至少要比成本高出一个最低毛利率m保证不亏本。注意这里的需求函数D(p)是价格p的函数通常我们假设为线性递减D a - b*p或指数递减D a * exp(-b*p)的形式。参数a, b可以通过历史数据回归得到。在随机规划中a和b也可以是随机变量以表征预测的不确定性。3.3 模型求解策略化繁为简的实用技巧上述模型是一个含随机变量的非线性规划问题直接求解非常困难。在竞赛和实际应用中我们采用了一些简化技巧场景分析法这是处理随机性的经典方法。我们不直接处理随机变量D_{i,t}(p)而是为其生成多个可能的“场景”。例如基于历史误差分布模拟出未来需求“乐观”、“一般”、“悲观”的几种情况。我们的优化目标就变为最大化在所有场景下的平均利润或者更稳健一些最大化在最差场景下的利润鲁棒优化思想。我们的代码中实现了场景生成器。线性化与离散化如果需求函数是非线性的求解会很难。我们可以将价格离散化例如每种蔬菜只允许从几个预设的价格点中选择如[成本*1.3 成本*1.5 成本*1.8]。这样关于价格p的决策就变成了从有限集合中选择问题可以转化为一个混合整数线性规划问题。虽然损失了一些精度但求解速度大大提升可以用专业的求解器如Gurobi, Cplex或开源工具如OR-Tools, PuLP快速求解。滚动优化我们不会一次性制定未来一周所有日期的死计划。而是采用“滚动时域”策略每天开始时根据最新的库存和成本数据重新运行一次优化模型制定出当天和未来几天的计划但只执行当天的决策。第二天重复这个过程。这样能不断吸收新的信息调整策略更适应现实。我们的代码仓库里提供了基于Python和PuLP用于线性规划的实现示例。核心求解函数大约200行但围绕它的数据预处理、后处理和分析代码则有上千行。4. 代码实现与数据处理中的“坑”与“桥”论文里的模型描述可能看起来很美但代码实现过程才是“魔鬼细节”的聚集地。这里分享几个我们踩过的坑和搭建的“桥”。4.1 数据清洗异常值不是一删了之题目给的数据通常包含缺失值和异常值。对于缺失的销量或价格常见的做法是用前后天的均值填充。但对于异常值比如某天某种蔬菜销量突然暴增或为零处理需要谨慎。销量暴增首先查日历是不是节假日或者数据记录是否有误如单位是“斤”误录为“公斤”如果是促销导致那么这是一个宝贵的“价格弹性”样本不应该简单删除而应该将其与当天的价格信息关联起来用于需求函数的拟合。销量为零要区分是“真零”就是没卖出去还是“缺货零”因为没进货所以没得卖。这需要结合当天的进货记录来判断。如果是“缺货零”这个样本在训练需求预测模型时应该剔除或特殊标记因为它不代表零需求而是供应链中断。我们的做法是编写了一个数据诊断报告生成脚本。它会自动识别每种蔬菜销售序列的缺失、零值、突增点并关联进货数据给出可能的原因标注供我们人工复核。这个脚本后来被证明比盲目清洗有用得多。4.2 需求预测模型的评估陷阱在训练需求预测模型时我们犯过一个错误用全部数据训练然后用交叉验证评估得到了很高的R²分数沾沾自喜。但后来发现这存在严重的数据泄露问题。因为我们在特征中使用了“当天的价格”而在实际预测时第二天的价格是我们需要决策的未知量正确的做法是进行时间序列交叉验证。例如用第1-100天的数据预测第101天的需求用第1-101天的数据预测第102天的需求以此类推。这样才能模拟真实的滚动预测场景。评估指标也不应只看R²更要看在模拟滚动优化环境下使用预测结果做出的决策能带来多少利润。我们后来增加了一个“模拟回溯测试”模块用历史数据逐天模拟运行我们的定价补货策略与历史实际利润对比这才是最硬的评估标准。4.3 优化求解器的选择与调试我们最初使用SciPy的优化库但在处理几十种商品、多个场景、多周期的问题时速度慢且容易陷入局部最优。后来切换到PuLP调用CBC求解器开源处理线性化后的问题效率很高。对于更复杂的问题商业求解器如Gurobi有免费学术许可速度和稳定性是质的飞跃。一个调试技巧是先求解一个简化版问题。例如只选3种有代表性的蔬菜一个叶菜、一个果菜、一个根茎优化周期缩短到3天。确保模型逻辑正确、求解器能跑通、结果符合常识比如价格高时补货应谨慎。然后再逐步增加品类和周期。我们的代码中保留了多个版本的模型文件model_simple.pymodel_full.py就是为了方便调试和演示。5. 从模型输出到业务动作策略的可解释性与执行模型输出一堆数字未来每天每种菜的进货量和建议售价。如何让店长或采购员相信并执行这些“冷冰冰”的数字这就是模型可解释性和策略柔性化要解决的问题。5.1 生成“人话”报告不只是数字我们的代码最后会生成一份每日决策建议报告格式如下【日期2023-10-27】 【今日重点】 * 西红柿品类代码A01进货成本上涨15%但需求弹性较低。建议**小幅提价10%**预计销量下降5%但毛利额增加8%。可维持正常进货量。 * 菠菜品类代码B05库存周转较快且明日气温下降预计火锅需求增加。建议**增加20%的进货量**价格保持稳定抓住机会提升销量。 * 土豆品类代码C12库存较高且未来三天成本稳定。建议**启动“清库存”促销模式**降价5%目标在两天内将库存降至安全线以下。 【风险提示】 * 黄瓜A03与竞品价差已缩小至5%以内若竞品明日促销我方销量可能下滑20%。请采购部关注市场动态准备应急调价方案。这样的报告把模型的“为什么”讲了出来结合了业务常识天气、竞品给出了明确的行动指令和风险预警远比只给两个数字更容易被接受。5.2 设置人工干预接口尊重业务直觉再好的模型也只是辅助。我们必须在系统中预设人工干预接口。例如价格上下限锁定店长可以设置某种蔬菜无论如何不能超过某个价格基于顾客接受度。补货量修正系数如果店长预感到明天有团体采购他可以手动将某种菜的推荐补货量乘以一个系数如1.5。策略模式选择模型可以提供不同目标下的策略如“利润最大化”、“销量最大化”、“损耗最小化”由管理者根据阶段目标选择。在我们的代码框架中这些干预是在优化模型求解之前以修改输入参数如需求预测值、约束条件的方式实现的而不是在模型输出结果后强行修改。这保证了干预后的决策仍然是内部逻辑自洽的。6. 项目总结与扩展思考回顾整个项目从一道竞赛题出发我们几乎走完了一个小型数据科学项目的全流程业务理解、数据准备、建模、求解、评估、部署。最大的收获不是那个奖状而是对“运筹学如何落地”有了刻骨铭心的体会。几点核心心得业务第一模型第二。最开始花在理解“蔬菜定价补货到底在干什么”上的时间远多于写代码的时间。这个时间值。简单模型 好特征 复杂模型 差特征。我们最初想过用强化学习来模拟动态博弈但后来发现特征工程扎实的集成树模型线性规划在可解释性和求解稳定性上完胜“黑箱”复杂模型。不确定性是朋友不是敌人。通过场景分析、鲁棒优化等方式明确地处理不确定性得到的策略比假装未来是确定的策略要稳健得多。系统要为人服务。最终的输出必须是业务人员能看懂、能信任、能微调的建议而不是一个无法质疑的“AI圣旨”。这个框架的扩展性很强。它不仅可以用于蔬菜稍作修改就能用于水果、鲜奶、短保烘焙食品等所有具有短保质期、需求价格弹性、高损耗率特征的零售商品。模型中的“损耗函数”可以变得更复杂引入更精细的品相分级如A级、B级对应不同价格和需求。也可以和供应链上游打通将供应商的供货价格和稳定性作为变量纳入优化。最后我们开源了本次竞赛的核心代码和一份简化的示例数据集。代码仓库里包含了数据处理、特征工程、预测建模、优化求解和模拟回溯测试的完整流水线。它不是一套可以直接上线的生产系统但绝对是一个绝佳的学习框架和实验沙盒。你可以用它来验证自己的新想法比如换一种需求预测模型或者尝试不同的优化算法看看对最终“利润”这个硬指标到底有什么影响。在数据驱动的时代拥有将复杂业务问题转化为数学模型并求解的能力正变得越来越重要。希望我们的这次实战复盘和开源代码能成为你探索这条道路的一块有用的垫脚石。本文还有配套的精品资源点击获取