关键词LightGBM 销量预测、Streamlit 数据看板、校园食堂销量预测、备餐建议系统、机器学习回归预测、时间序列特征工程、课程设计项目、Python 完整项目源码摘要校园食堂每天都要面对一个很实际的问题明天每个窗口应该准备多少份菜准备少了学生排队时发现热门菜已经售罄准备多了窗口又会出现剩菜、原料浪费和人工损耗。这个问题看起来像普通的业务排班问题本质上却是一个典型的结构化数据预测问题销量会受到星期、天气、温度、考试周、节假日、寒暑假、菜品类别、价格、窗口位置和历史销量共同影响。本文围绕一个可以直接运行的完整项目展开项目名称为Campus Canteen Sales Forecasting System。系统采用LightGBM Streamlit技术路线LightGBM 负责对菜品级销量进行回归预测Streamlit 负责把历史数据、模型效果、未来预测和备餐建议做成 Web 看板。项目内置模拟校园食堂数据生成器不需要用户手动下载数据集也不需要训练深度学习模型权重下载源码后执行python main.py --mode demo即可生成数据、训练模型、保存预测结果和结果图执行streamlit run app.py可以打开交互式看板。本文不是只讲概念而是围绕一个真实可运行的 Python 项目进行说明。文章会介绍业务背景、数据字段、特征工程、LightGBM 建模方法、模型评估方式、备餐建议生成逻辑、Streamlit 页面设计、项目目录结构、运行效果和扩展方向。项目适合用于 CSDN 技术博客、Python 课程设计、数据挖掘实践、机器学习建模项目、校园管理系统原型和二次开发。1. 项目背景为什么食堂销量预测适合做机器学习实战项目很多入门机器学习项目会选择房价预测、鸢尾花分类、泰坦尼克号生存预测等公开样例。这些项目适合学习 API但和实际业务距离较远。校园食堂销量预测更适合作为课程设计或项目实践因为它同时具备三个特点业务场景容易理解数据结构不复杂预测结果可以转化为明确的管理建议。从业务上看食堂窗口每天都要做备餐决策。比如米饭要蒸多少鸡肉要切多少蔬菜要清洗多少鸡蛋要备多少哪些菜应该提前半成品加工哪些菜应该少量多次补货。传统做法通常依赖窗口师傅经验经验当然重要但经验很难同时记住过去几百天中天气、星期、考试周、节假日、价格变化和菜品热度之间的关系。机器学习模型的价值并不是替代人工而是把历史规律量化出来给备餐人员一个参考值。校园食堂的真实经营场景中窗口供应、就餐时段和学生客流会互相影响。预测系统要解决的不是单纯画一条销量曲线而是把预测结果转成窗口可以执行的备餐份数和主料用量。从建模上看菜品销量属于结构化表格数据。每一行可以表示某一天、某个食堂、某个窗口、某个菜品的销量。特征可以来自日期、天气、价格、菜品属性和历史销量。LightGBM 正适合处理这类表格型回归任务。LightGBM 官方文档将其描述为基于树学习算法的梯度提升框架并强调训练效率、内存占用和大规模数据处理能力这也是本项目选择它而不是复杂深度学习模型的重要原因。参考资料https://lightgbm.readthedocs.io/前端展示方面食堂预测项目需要让用户看到数据趋势、模型误差、未来预测、备餐建议和主料汇总。Streamlit 的定位就是帮助数据科学和机器学习开发者快速构建数据应用官方文档也提供了streamlit run your_script.py的本地运行方式。参考资料https://docs.streamlit.io/2. 项目实现目标这个项目最终要解决的问题可以概括为一句话根据历史销量和影响因素预测未来几天每个菜品的销量并进一步转换为可执行的备餐份数和原料用量建议。为了让项目能够直接运行我没有依赖真实学校的隐私业务数据而是写了一个可复现的数据生成器。它会自动模拟 2025-02-24 到 2026-05-15 之间的校园食堂销量数据覆盖 3 个食堂、多个售卖窗口和 18 个菜品。每条记录包含日期、食堂、窗口、菜品、类别、餐段、口味、价格、天气、温度、降水、是否周末、是否节假日、是否考试周、是否寒暑假、学期周、单份原料用量和销量等字段。系统运行后会完成以下工作1. 生成 demo_data/canteen_sales.csv 2. 构造日期特征、周期特征、滞后销量特征和滚动均值特征 3. 按时间顺序切分训练集和测试集 4. 训练 LightGBM 回归模型 5. 输出 MAE、RMSE、MAPE、R² 等指标 6. 预测未来 7 天菜品销量 7. 根据安全库存比例生成备餐份数 8. 估算米饭、肉类、蔬菜、鸡蛋等主料用量 9. 生成结果图片和 Streamlit 看板项目不是只给一个训练脚本而是包含完整工程结构、主程序、Web 应用、配置文件、运行脚本、结果图、文档和博客 Markdown 文件。项目源码包解压后可以直接运行适合作为一个完整的“机器学习项目交付包”。3. 项目结构图与文件目录项目采用比较清晰的分层结构。数据生成、特征工程、模型训练、备餐建议和可视化分别放在不同模块中便于后续替换真实数据或增加新模型。完整目录如下campus_canteen_lgbm_streamlit/ ├── app.py ├── main.py ├── run_demo.py ├── blog.md ├── README.md ├── requirements.txt ├── configs/ │ └── config.json ├── src/ │ ├── data_generator.py │ ├── features.py │ ├── model.py │ ├── recommender.py │ ├── pipeline.py │ ├── visualization.py │ └── utils.py ├── demo_data/ │ └── canteen_sales.csv ├── models/ │ └── lightgbm_sales_model.joblib ├── outputs/ │ ├── metrics.json │ ├── test_predictions.csv │ ├── forecast_next_7_days.csv │ ├── prep_recommendations.csv │ └── ingredient_summary.csv ├── images/ │ ├── figures/ │ └── results/ ├── docs/ ├── weights/ │ └── README_WEIGHTS.md ├── run.bat └── run.sh其中main.py是命令行主入口适合一键训练和生成结果app.py是 Streamlit Web 看板src/data_generator.py用于生成模拟数据src/features.py负责特征工程src/model.py负责训练、评估、预测和模型保存src/recommender.py负责把销量预测转换为备餐建议src/visualization.py负责保存趋势图、预测对比图、特征重要性图和备餐建议图。4. 技术路线与流程设计项目流程可以拆成两个阶段。第一阶段是建模阶段从历史销量数据出发训练出一个能够预测菜品销量的 LightGBM 回归模型。第二阶段是应用阶段把预测销量转换成备餐建议并通过 Streamlit 看板给用户展示。在时间序列类预测任务中一个容易犯的错误是随机切分训练集和测试集。随机切分会把未来日期的数据混入训练集导致模型在测试集上看起来很好但实际上线后效果明显下降。本项目采用按日期切分的方法把最近 45 天作为测试集前面的数据作为训练集。scikit-learn 的 TimeSeriesSplit 文档也强调时间有序数据不应该用会让模型“看到未来”的方式进行验证。参考资料https://scikit-learn.org/stable/modules/generated/sklearn.model_selection.TimeSeriesSplit.html本项目没有直接使用 TimeSeriesSplit 做多折验证而是采用更直观的“最后 N 天测试集”方案原因是课程设计和博客演示更需要清晰可解释的训练集/测试集边界。真实业务中可以进一步扩展为滚动窗口验证。5. 数据设计一行数据代表什么项目生成的数据保存在demo_data/canteen_sales.csv。每一行表示某一天某个食堂窗口某个菜品的销量。下面是核心字段的含义。字段说明date日期canteen_id食堂名称window_name售卖窗口dish_name菜品名称category菜品类别meal_period早餐、午餐或晚餐price当日售价weather天气场景temperature温度precipitation降水量is_weekend是否周末is_holiday是否节假日is_exam_week是否考试周is_vacation是否寒暑假semester_week学期周sales_count当日销量也就是模型预测目标为了让数据更接近真实业务生成器不是简单随机生成销量而是把多个因素组合起来。例如周末客流下降节假日和寒暑假客流明显降低考试周米饭套餐和面食需求增加雨天到店消费更集中低温天气热汤面销量增加高温天气轻食类销量上升。这样生成出来的数据有规律、有噪声也有场景差异适合做模型训练和可视化分析。运行后生成的数据规模为8,028 条记录。这个规模不大普通 CPU 环境也可以快速训练适合放在 CSDN 项目源码包中交付。6. 特征工程从日期和历史销量中提取信息销量预测不能只把日期和菜名丢给模型。模型需要看到“今天是星期几”“当前处于学期第几周”“昨天卖了多少”“过去 7 天平均销量是多少”等信息。因此项目在src/features.py中构造了三类特征。第一类是日期特征包括星期、月份、一年中的第几天、ISO 周、季度、是否月初、是否月末等。pandas 提供了方便的日期属性例如DatetimeIndex.dayofweek会返回星期编号约定 Monday0、Sunday6。参考资料https://pandas.pydata.org/docs/reference/api/pandas.DatetimeIndex.dayofweek.html第二类是周期特征。星期和日期本身具有周期性比如星期一和星期日虽然数字差距大但在周期上是相邻关系。因此项目使用正弦和余弦变换构造dow_sin、dow_cos、doy_sin、doy_cos帮助树模型捕捉周期变化。第三类是历史销量特征。项目为每个食堂、窗口、菜品组合构造lag_1、lag_7、lag_14、lag_28分别表示前 1 天、前 7 天、前 14 天和前 28 天的销量。同时构造rolling_7_mean、rolling_14_mean、rolling_28_mean表示过去一段时间的平均销量。这些特征对销量预测非常重要因为食堂菜品的热度通常具有延续性。特征工程中的关键点是不能泄漏当前销量。项目在计算滚动均值时先shift(1)再计算 rolling mean确保模型只能使用当前日期之前的信息。7. 模型选择为什么选择 LightGBM项目选择 LightGBM 的原因很直接食堂销量预测是结构化表格回归问题而 LightGBM 对这类数据通常表现稳定训练速度快参数可控也方便解释特征重要性。相比神经网络LightGBM 不需要大量数据也不需要 GPU相比线性回归它能处理非线性关系和特征交互相比普通随机森林它在很多表格数据场景中有更好的效率和精度表现。项目中使用的是lightgbm.LGBMRegressor。LightGBM 官方 Python API 文档中明确提供了这个回归器接口用于构建梯度提升回归模型。参考资料https://lightgbm.readthedocs.io/en/latest/pythonapi/lightgbm.LGBMRegressor.html模型参数配置保存在configs/config.json中核心参数如下{n_estimators:180,learning_rate:0.06,num_leaves:25,subsample:0.88,colsample_bytree:0.85,reg_alpha:0.05,reg_lambda:0.15,random_state:42,n_jobs:2}这里没有刻意做复杂调参因为项目目标是提供一个稳定可运行的完整系统而不是刷榜式比赛。真实业务上线时可以加入 Optuna 或网格搜索对num_leaves、learning_rate、feature_fraction、bagging_fraction、min_child_samples等参数进行进一步优化。8. 训练与评估结果运行python main.py --mode demo后系统会自动生成数据、训练模型并保存结果。当前交付版本的验证结果如下MAE 7.1242 RMSE 9.6497 MAPE 7.99% R² 0.9316MAE 表示平均绝对误差可以理解为模型对单个菜品每日销量的平均偏差。RMSE 对大误差更敏感。MAPE 是相对误差指标scikit-learn 文档中说明其输出不是 0 到 100 的百分数而是相对值例如 0.08 大约对应 8% 的平均绝对百分比误差。参考资料https://scikit-learn.org/stable/modules/generated/sklearn.metrics.mean_absolute_percentage_error.html下面是历史日销量趋势图。可以看到数据中存在明显的周周期、假期下降和学期内波动。下面是真实销量和预测销量在测试集上的对比图。项目按日期聚合测试集数据后绘图便于观察整体趋势是否跟得上。从图中可以看到模型对整体趋势的拟合比较稳定。由于数据中包含随机噪声和假期波动单日误差不可能完全为零但预测曲线能够跟随真实曲线变化这说明日期特征、天气特征和历史销量特征起到了作用。9. 特征重要性分析LightGBM 的一个优点是可以输出特征重要性。虽然特征重要性不能等同于因果解释但它能帮助我们理解模型主要依赖哪些输入。在这个项目中通常排名靠前的特征会包括菜品名称、菜品基础热度、历史滞后销量、滚动均值、餐段、是否假期、是否周末和天气等。这和业务直觉是吻合的一个菜品本身热不热门昨天和上周卖得怎么样是否处于正常上课日这些都会直接影响明天销量。如果后续接入真实数据还可以增加更多特征例如1. 宿舍区距离和食堂位置 2. 当天课程数量或校历安排 3. 菜品是否新品 4. 菜品是否限时折扣 5. 食堂是否临时停电、装修或窗口关闭 6. 校园活动和考试安排 7. 菜品评分、投诉数量和复购率这些特征越贴近真实经营模型预测越容易转化为可执行建议。10. 从销量预测到备餐建议单纯输出“预测销量”还不够。食堂真正需要的是“该准备多少份”和“需要多少原料”。因此项目在src/recommender.py中做了二次转换。基本逻辑如下建议备餐份数 ceil(预测销量 × (1 安全库存比例))默认安全库存比例为 12%。例如某菜品预测销量是 100 份则建议备餐为 112 份。安全库存不是越高越好比例过高会增加浪费比例过低会增加售罄风险。项目在 Streamlit 看板中提供了滑块用户可以在 0% 到 30% 之间调整。项目还为每个菜品配置了单份原料用量例如单份米饭用量、单份肉类用量、单份蔬菜用量和单份鸡蛋数量。根据建议份数系统可以进一步计算每天每个食堂需要准备多少米饭、肉类、蔬菜和鸡蛋。下面是运行后生成的备餐建议图。当前预测周期内建议备餐量最高的几个菜品如下日期食堂菜品建议份数风险等级2026-05-18East CanteenBeef Noodles185high_demand2026-05-18East CanteenBraised Chicken Rice185high_demand2026-05-19East CanteenBraised Chicken Rice184high_demand2026-05-19East CanteenBeef Noodles184high_demand2026-05-20East CanteenBraised Chicken Rice177high_demand风险等级分为high_demand、normal和low_demand。如果预测销量明显高于菜品基础热度系统会建议提前备菜如果预测销量明显偏低系统会建议减少首批出餐量采用少量多次补货方式。11. Streamlit 看板设计项目的 Web 看板在app.py中实现。Streamlit 的好处是代码量相对少不需要自己写复杂前端也不需要单独搭建 Vue 或 React 工程。官方文档中提供了安装和运行方式常用命令就是pip install streamlit和streamlit run app.py。参考资料https://docs.streamlit.io/get-started/installation看板主要包含四个页面1. Data overview展示历史销量趋势、食堂销量、菜品类别占比和原始数据 2. Model performance展示测试集真实值与预测值、特征重要性和误差较大的记录 3. Preparation plan根据未来天气、温度和安全库存比例生成备餐建议 4. Single dish explorer查看某个菜品在不同食堂的历史销量走势下面是实际启动 Streamlit 后截取的 Data overview 页面。左侧筛选区可以同时控制食堂、菜品类别、预测天数、天气情景、温度和安全库存比例主页面先给出训练记录数和模型指标再展示历史销量趋势。模型效果页把测试集真实销量和预测销量放在同一张趋势图中并列出特征重要性和误差较大的记录方便判断模型是否只是指标好看还是确实跟上了销量波动。备餐建议页则把预测结果转成窗口可执行的建议份数并继续提供主料汇总和明细表下载。这个页面设计的重点不是追求复杂而是让用户一眼看到“模型是否靠谱”“未来要备多少”“哪些菜风险较高”。对于课程设计或项目展示来说这种看板比只输出 CSV 文件更直观。12. 关键代码说明项目最核心的训练逻辑位于src/model.py。训练过程包括构建特征、按日期切分训练测试集、建立预处理管道、训练 LightGBM、保存模型和输出预测结果。简化后的逻辑如下feat_dfbuild_features(df)feature_columnsget_feature_columns(feat_df)train_df,test_dfsplit_by_date(feat_df,test_days45)pipelinemake_pipeline(train_df,feature_columns,params)pipeline.fit(train_df[feature_columns],train_df[sales_count])test_predpipeline.predict(test_df[feature_columns])metricsevaluate_predictions(test_df[sales_count],test_pred)项目使用ColumnTransformer OneHotEncoder LGBMRegressor构建 sklearn 管道。这样做的好处是类别特征和数值特征可以统一处理保存模型时也能把预处理步骤一起保存到models/lightgbm_sales_model.joblib中。后续预测时只需要加载这个 joblib 文件不需要重新写编码逻辑。备餐建议逻辑位于src/recommender.py核心代码如下df[suggested_servings]np.ceil(df[predicted_sales]*(1buffer_ratio)).astype(int)df[rice_kg](df[suggested_servings]*df[rice_kg_per_serving]).round(2)这段代码看起来很简单但它完成了从模型输出到业务建议的关键转化。很多机器学习项目停留在预测值层面而实际项目更需要把预测值变成可执行动作。13. 运行方式首先安装依赖pipinstall-rrequirements.txt一键运行训练和预测python main.py--modedemo或运行python run_demo.py启动 Streamlit 看板streamlit run app.py也可以使用统一入口python main.py--modeapp--port8501Windows 用户可以双击或执行run.batLinux/macOS 用户可以执行bashrun.sh项目首次运行后会生成以下文件demo_data/canteen_sales.csv models/lightgbm_sales_model.joblib outputs/metrics.json outputs/test_predictions.csv outputs/forecast_next_7_days.csv outputs/prep_recommendations.csv outputs/ingredient_summary.csv images/results/sales_trend.png images/results/actual_vs_pred.png images/results/feature_importance.png images/results/prep_recommendation.png14. 如何替换成真实食堂数据如果要把项目改成真实校园食堂版本最重要的是保持数据字段稳定。真实数据至少应该包含日期、食堂、窗口、菜品、价格和销量。如果没有天气、温度、考试周和假期字段可以先填默认值再逐步接入外部数据。推荐的真实数据表结构如下date,canteen_id,window_name,dish_name,category,meal_period,price,weather, temperature,precipitation,is_weekend,is_holiday,is_exam_week,is_vacation, semester_week,sales_count如果学校能提供点餐系统、刷卡系统或窗口销售系统导出的数据可以按日聚合到菜品级别。如果只有订单明细则需要先按date canteen_id window_name dish_name分组统计销量。真实业务中还要注意菜单变更问题新菜品没有历史销量模型可能预测不稳定可以通过菜品类别、价格、窗口、相似菜品热度来缓解冷启动问题。15. 可扩展方向这个项目可以继续扩展成更完整的食堂智能经营辅助系统。比较实用的方向包括1. 增加真实天气接口自动读取未来天气预报 2. 接入学校校历自动标记考试周、运动会、节假日和寒暑假 3. 增加库存管理模块结合现有库存计算采购建议 4. 增加损耗成本优化“缺货损失”和“浪费损失”的平衡 5. 增加多模型对比例如 RandomForest、XGBoost、CatBoost、Prophet 6. 增加菜品冷启动策略用相似菜品估算新品销量 7. 增加数据库把 CSV 替换成 SQLite 或 MySQL 8. 增加用户权限区分管理员、食堂经理和窗口员工 9. 增加报表导出自动生成每日备餐 Excel 10. 增加模型定期重训脚本支持每周自动更新模型如果用于课程设计可以把重点放在数据生成、特征工程、模型训练和 Streamlit 看板如果用于工程展示可以继续补充数据库、登录权限和导出功能如果用于论文实验可以增加模型对比、特征消融实验和不同预测窗口的误差分析。16. 总结本文完成了一个基于 LightGBM Streamlit 的校园食堂销量预测与备餐建议系统。项目从模拟数据生成开始经过特征工程、模型训练、测试集评估、未来销量预测、备餐建议生成和 Web 看板展示形成了一个完整可运行的机器学习实战案例。相比只写一个模型训练脚本这个项目更接近真实交付它有清晰的目录结构有一键运行入口有模型文件和结果文件有图表和看板有 README 和文档也有可直接发布到 CSDN 的博客 Markdown。对于想做 Python 课程设计、机器学习项目实践、数据分析系统、校园管理系统原型的同学来说这个选题具备较好的实用性和可展示性。最终可以得到这样一条技术路线校园食堂历史销量数据 → 日期/天气/菜品/历史销量特征 → LightGBM 回归模型 → 未来菜品销量预测 → 安全库存比例修正 → 备餐份数与主料用量建议 → Streamlit 可视化看板项目不依赖外部模型权重不需要联网下载大文件CPU 环境即可运行。后续只要替换真实数据并补充业务字段就可以继续扩展为更完整的校园食堂经营辅助系统。参考资料LightGBM 官方文档https://lightgbm.readthedocs.io/LightGBM LGBMRegressor APIhttps://lightgbm.readthedocs.io/en/latest/pythonapi/lightgbm.LGBMRegressor.htmlStreamlit 官方文档https://docs.streamlit.io/scikit-learn TimeSeriesSplit 文档https://scikit-learn.org/stable/modules/generated/sklearn.model_selection.TimeSeriesSplit.htmlWikimedia Commons 校园餐厅场景图https://commons.wikimedia.org/wiki/File:College_dining_hall.jpg
基于 LightGBM + Streamlit 的校园食堂销量预测与备餐建议系统实战
发布时间：2026/6/2 1:53:12
关键词LightGBM 销量预测、Streamlit 数据看板、校园食堂销量预测、备餐建议系统、机器学习回归预测、时间序列特征工程、课程设计项目、Python 完整项目源码摘要校园食堂每天都要面对一个很实际的问题明天每个窗口应该准备多少份菜准备少了学生排队时发现热门菜已经售罄准备多了窗口又会出现剩菜、原料浪费和人工损耗。这个问题看起来像普通的业务排班问题本质上却是一个典型的结构化数据预测问题销量会受到星期、天气、温度、考试周、节假日、寒暑假、菜品类别、价格、窗口位置和历史销量共同影响。本文围绕一个可以直接运行的完整项目展开项目名称为Campus Canteen Sales Forecasting System。系统采用LightGBM Streamlit技术路线LightGBM 负责对菜品级销量进行回归预测Streamlit 负责把历史数据、模型效果、未来预测和备餐建议做成 Web 看板。项目内置模拟校园食堂数据生成器不需要用户手动下载数据集也不需要训练深度学习模型权重下载源码后执行python main.py --mode demo即可生成数据、训练模型、保存预测结果和结果图执行streamlit run app.py可以打开交互式看板。本文不是只讲概念而是围绕一个真实可运行的 Python 项目进行说明。文章会介绍业务背景、数据字段、特征工程、LightGBM 建模方法、模型评估方式、备餐建议生成逻辑、Streamlit 页面设计、项目目录结构、运行效果和扩展方向。项目适合用于 CSDN 技术博客、Python 课程设计、数据挖掘实践、机器学习建模项目、校园管理系统原型和二次开发。1. 项目背景为什么食堂销量预测适合做机器学习实战项目很多入门机器学习项目会选择房价预测、鸢尾花分类、泰坦尼克号生存预测等公开样例。这些项目适合学习 API但和实际业务距离较远。校园食堂销量预测更适合作为课程设计或项目实践因为它同时具备三个特点业务场景容易理解数据结构不复杂预测结果可以转化为明确的管理建议。从业务上看食堂窗口每天都要做备餐决策。比如米饭要蒸多少鸡肉要切多少蔬菜要清洗多少鸡蛋要备多少哪些菜应该提前半成品加工哪些菜应该少量多次补货。传统做法通常依赖窗口师傅经验经验当然重要但经验很难同时记住过去几百天中天气、星期、考试周、节假日、价格变化和菜品热度之间的关系。机器学习模型的价值并不是替代人工而是把历史规律量化出来给备餐人员一个参考值。校园食堂的真实经营场景中窗口供应、就餐时段和学生客流会互相影响。预测系统要解决的不是单纯画一条销量曲线而是把预测结果转成窗口可以执行的备餐份数和主料用量。从建模上看菜品销量属于结构化表格数据。每一行可以表示某一天、某个食堂、某个窗口、某个菜品的销量。特征可以来自日期、天气、价格、菜品属性和历史销量。LightGBM 正适合处理这类表格型回归任务。LightGBM 官方文档将其描述为基于树学习算法的梯度提升框架并强调训练效率、内存占用和大规模数据处理能力这也是本项目选择它而不是复杂深度学习模型的重要原因。参考资料https://lightgbm.readthedocs.io/前端展示方面食堂预测项目需要让用户看到数据趋势、模型误差、未来预测、备餐建议和主料汇总。Streamlit 的定位就是帮助数据科学和机器学习开发者快速构建数据应用官方文档也提供了streamlit run your_script.py的本地运行方式。参考资料https://docs.streamlit.io/2. 项目实现目标这个项目最终要解决的问题可以概括为一句话根据历史销量和影响因素预测未来几天每个菜品的销量并进一步转换为可执行的备餐份数和原料用量建议。为了让项目能够直接运行我没有依赖真实学校的隐私业务数据而是写了一个可复现的数据生成器。它会自动模拟 2025-02-24 到 2026-05-15 之间的校园食堂销量数据覆盖 3 个食堂、多个售卖窗口和 18 个菜品。每条记录包含日期、食堂、窗口、菜品、类别、餐段、口味、价格、天气、温度、降水、是否周末、是否节假日、是否考试周、是否寒暑假、学期周、单份原料用量和销量等字段。系统运行后会完成以下工作1. 生成 demo_data/canteen_sales.csv 2. 构造日期特征、周期特征、滞后销量特征和滚动均值特征 3. 按时间顺序切分训练集和测试集 4. 训练 LightGBM 回归模型 5. 输出 MAE、RMSE、MAPE、R² 等指标 6. 预测未来 7 天菜品销量 7. 根据安全库存比例生成备餐份数 8. 估算米饭、肉类、蔬菜、鸡蛋等主料用量 9. 生成结果图片和 Streamlit 看板项目不是只给一个训练脚本而是包含完整工程结构、主程序、Web 应用、配置文件、运行脚本、结果图、文档和博客 Markdown 文件。项目源码包解压后可以直接运行适合作为一个完整的“机器学习项目交付包”。3. 项目结构图与文件目录项目采用比较清晰的分层结构。数据生成、特征工程、模型训练、备餐建议和可视化分别放在不同模块中便于后续替换真实数据或增加新模型。完整目录如下campus_canteen_lgbm_streamlit/ ├── app.py ├── main.py ├── run_demo.py ├── blog.md ├── README.md ├── requirements.txt ├── configs/ │ └── config.json ├── src/ │ ├── data_generator.py │ ├── features.py │ ├── model.py │ ├── recommender.py │ ├── pipeline.py │ ├── visualization.py │ └── utils.py ├── demo_data/ │ └── canteen_sales.csv ├── models/ │ └── lightgbm_sales_model.joblib ├── outputs/ │ ├── metrics.json │ ├── test_predictions.csv │ ├── forecast_next_7_days.csv │ ├── prep_recommendations.csv │ └── ingredient_summary.csv ├── images/ │ ├── figures/ │ └── results/ ├── docs/ ├── weights/ │ └── README_WEIGHTS.md ├── run.bat └── run.sh其中main.py是命令行主入口适合一键训练和生成结果app.py是 Streamlit Web 看板src/data_generator.py用于生成模拟数据src/features.py负责特征工程src/model.py负责训练、评估、预测和模型保存src/recommender.py负责把销量预测转换为备餐建议src/visualization.py负责保存趋势图、预测对比图、特征重要性图和备餐建议图。4. 技术路线与流程设计项目流程可以拆成两个阶段。第一阶段是建模阶段从历史销量数据出发训练出一个能够预测菜品销量的 LightGBM 回归模型。第二阶段是应用阶段把预测销量转换成备餐建议并通过 Streamlit 看板给用户展示。在时间序列类预测任务中一个容易犯的错误是随机切分训练集和测试集。随机切分会把未来日期的数据混入训练集导致模型在测试集上看起来很好但实际上线后效果明显下降。本项目采用按日期切分的方法把最近 45 天作为测试集前面的数据作为训练集。scikit-learn 的 TimeSeriesSplit 文档也强调时间有序数据不应该用会让模型“看到未来”的方式进行验证。参考资料https://scikit-learn.org/stable/modules/generated/sklearn.model_selection.TimeSeriesSplit.html本项目没有直接使用 TimeSeriesSplit 做多折验证而是采用更直观的“最后 N 天测试集”方案原因是课程设计和博客演示更需要清晰可解释的训练集/测试集边界。真实业务中可以进一步扩展为滚动窗口验证。5. 数据设计一行数据代表什么项目生成的数据保存在demo_data/canteen_sales.csv。每一行表示某一天某个食堂窗口某个菜品的销量。下面是核心字段的含义。字段说明date日期canteen_id食堂名称window_name售卖窗口dish_name菜品名称category菜品类别meal_period早餐、午餐或晚餐price当日售价weather天气场景temperature温度precipitation降水量is_weekend是否周末is_holiday是否节假日is_exam_week是否考试周is_vacation是否寒暑假semester_week学期周sales_count当日销量也就是模型预测目标为了让数据更接近真实业务生成器不是简单随机生成销量而是把多个因素组合起来。例如周末客流下降节假日和寒暑假客流明显降低考试周米饭套餐和面食需求增加雨天到店消费更集中低温天气热汤面销量增加高温天气轻食类销量上升。这样生成出来的数据有规律、有噪声也有场景差异适合做模型训练和可视化分析。运行后生成的数据规模为8,028 条记录。这个规模不大普通 CPU 环境也可以快速训练适合放在 CSDN 项目源码包中交付。6. 特征工程从日期和历史销量中提取信息销量预测不能只把日期和菜名丢给模型。模型需要看到“今天是星期几”“当前处于学期第几周”“昨天卖了多少”“过去 7 天平均销量是多少”等信息。因此项目在src/features.py中构造了三类特征。第一类是日期特征包括星期、月份、一年中的第几天、ISO 周、季度、是否月初、是否月末等。pandas 提供了方便的日期属性例如DatetimeIndex.dayofweek会返回星期编号约定 Monday0、Sunday6。参考资料https://pandas.pydata.org/docs/reference/api/pandas.DatetimeIndex.dayofweek.html第二类是周期特征。星期和日期本身具有周期性比如星期一和星期日虽然数字差距大但在周期上是相邻关系。因此项目使用正弦和余弦变换构造dow_sin、dow_cos、doy_sin、doy_cos帮助树模型捕捉周期变化。第三类是历史销量特征。项目为每个食堂、窗口、菜品组合构造lag_1、lag_7、lag_14、lag_28分别表示前 1 天、前 7 天、前 14 天和前 28 天的销量。同时构造rolling_7_mean、rolling_14_mean、rolling_28_mean表示过去一段时间的平均销量。这些特征对销量预测非常重要因为食堂菜品的热度通常具有延续性。特征工程中的关键点是不能泄漏当前销量。项目在计算滚动均值时先shift(1)再计算 rolling mean确保模型只能使用当前日期之前的信息。7. 模型选择为什么选择 LightGBM项目选择 LightGBM 的原因很直接食堂销量预测是结构化表格回归问题而 LightGBM 对这类数据通常表现稳定训练速度快参数可控也方便解释特征重要性。相比神经网络LightGBM 不需要大量数据也不需要 GPU相比线性回归它能处理非线性关系和特征交互相比普通随机森林它在很多表格数据场景中有更好的效率和精度表现。项目中使用的是lightgbm.LGBMRegressor。LightGBM 官方 Python API 文档中明确提供了这个回归器接口用于构建梯度提升回归模型。参考资料https://lightgbm.readthedocs.io/en/latest/pythonapi/lightgbm.LGBMRegressor.html模型参数配置保存在configs/config.json中核心参数如下{n_estimators:180,learning_rate:0.06,num_leaves:25,subsample:0.88,colsample_bytree:0.85,reg_alpha:0.05,reg_lambda:0.15,random_state:42,n_jobs:2}这里没有刻意做复杂调参因为项目目标是提供一个稳定可运行的完整系统而不是刷榜式比赛。真实业务上线时可以加入 Optuna 或网格搜索对num_leaves、learning_rate、feature_fraction、bagging_fraction、min_child_samples等参数进行进一步优化。8. 训练与评估结果运行python main.py --mode demo后系统会自动生成数据、训练模型并保存结果。当前交付版本的验证结果如下MAE 7.1242 RMSE 9.6497 MAPE 7.99% R² 0.9316MAE 表示平均绝对误差可以理解为模型对单个菜品每日销量的平均偏差。RMSE 对大误差更敏感。MAPE 是相对误差指标scikit-learn 文档中说明其输出不是 0 到 100 的百分数而是相对值例如 0.08 大约对应 8% 的平均绝对百分比误差。参考资料https://scikit-learn.org/stable/modules/generated/sklearn.metrics.mean_absolute_percentage_error.html下面是历史日销量趋势图。可以看到数据中存在明显的周周期、假期下降和学期内波动。下面是真实销量和预测销量在测试集上的对比图。项目按日期聚合测试集数据后绘图便于观察整体趋势是否跟得上。从图中可以看到模型对整体趋势的拟合比较稳定。由于数据中包含随机噪声和假期波动单日误差不可能完全为零但预测曲线能够跟随真实曲线变化这说明日期特征、天气特征和历史销量特征起到了作用。9. 特征重要性分析LightGBM 的一个优点是可以输出特征重要性。虽然特征重要性不能等同于因果解释但它能帮助我们理解模型主要依赖哪些输入。在这个项目中通常排名靠前的特征会包括菜品名称、菜品基础热度、历史滞后销量、滚动均值、餐段、是否假期、是否周末和天气等。这和业务直觉是吻合的一个菜品本身热不热门昨天和上周卖得怎么样是否处于正常上课日这些都会直接影响明天销量。如果后续接入真实数据还可以增加更多特征例如1. 宿舍区距离和食堂位置 2. 当天课程数量或校历安排 3. 菜品是否新品 4. 菜品是否限时折扣 5. 食堂是否临时停电、装修或窗口关闭 6. 校园活动和考试安排 7. 菜品评分、投诉数量和复购率这些特征越贴近真实经营模型预测越容易转化为可执行建议。10. 从销量预测到备餐建议单纯输出“预测销量”还不够。食堂真正需要的是“该准备多少份”和“需要多少原料”。因此项目在src/recommender.py中做了二次转换。基本逻辑如下建议备餐份数 ceil(预测销量 × (1 安全库存比例))默认安全库存比例为 12%。例如某菜品预测销量是 100 份则建议备餐为 112 份。安全库存不是越高越好比例过高会增加浪费比例过低会增加售罄风险。项目在 Streamlit 看板中提供了滑块用户可以在 0% 到 30% 之间调整。项目还为每个菜品配置了单份原料用量例如单份米饭用量、单份肉类用量、单份蔬菜用量和单份鸡蛋数量。根据建议份数系统可以进一步计算每天每个食堂需要准备多少米饭、肉类、蔬菜和鸡蛋。下面是运行后生成的备餐建议图。当前预测周期内建议备餐量最高的几个菜品如下日期食堂菜品建议份数风险等级2026-05-18East CanteenBeef Noodles185high_demand2026-05-18East CanteenBraised Chicken Rice185high_demand2026-05-19East CanteenBraised Chicken Rice184high_demand2026-05-19East CanteenBeef Noodles184high_demand2026-05-20East CanteenBraised Chicken Rice177high_demand风险等级分为high_demand、normal和low_demand。如果预测销量明显高于菜品基础热度系统会建议提前备菜如果预测销量明显偏低系统会建议减少首批出餐量采用少量多次补货方式。11. Streamlit 看板设计项目的 Web 看板在app.py中实现。Streamlit 的好处是代码量相对少不需要自己写复杂前端也不需要单独搭建 Vue 或 React 工程。官方文档中提供了安装和运行方式常用命令就是pip install streamlit和streamlit run app.py。参考资料https://docs.streamlit.io/get-started/installation看板主要包含四个页面1. Data overview展示历史销量趋势、食堂销量、菜品类别占比和原始数据 2. Model performance展示测试集真实值与预测值、特征重要性和误差较大的记录 3. Preparation plan根据未来天气、温度和安全库存比例生成备餐建议 4. Single dish explorer查看某个菜品在不同食堂的历史销量走势下面是实际启动 Streamlit 后截取的 Data overview 页面。左侧筛选区可以同时控制食堂、菜品类别、预测天数、天气情景、温度和安全库存比例主页面先给出训练记录数和模型指标再展示历史销量趋势。模型效果页把测试集真实销量和预测销量放在同一张趋势图中并列出特征重要性和误差较大的记录方便判断模型是否只是指标好看还是确实跟上了销量波动。备餐建议页则把预测结果转成窗口可执行的建议份数并继续提供主料汇总和明细表下载。这个页面设计的重点不是追求复杂而是让用户一眼看到“模型是否靠谱”“未来要备多少”“哪些菜风险较高”。对于课程设计或项目展示来说这种看板比只输出 CSV 文件更直观。12. 关键代码说明项目最核心的训练逻辑位于src/model.py。训练过程包括构建特征、按日期切分训练测试集、建立预处理管道、训练 LightGBM、保存模型和输出预测结果。简化后的逻辑如下feat_dfbuild_features(df)feature_columnsget_feature_columns(feat_df)train_df,test_dfsplit_by_date(feat_df,test_days45)pipelinemake_pipeline(train_df,feature_columns,params)pipeline.fit(train_df[feature_columns],train_df[sales_count])test_predpipeline.predict(test_df[feature_columns])metricsevaluate_predictions(test_df[sales_count],test_pred)项目使用ColumnTransformer OneHotEncoder LGBMRegressor构建 sklearn 管道。这样做的好处是类别特征和数值特征可以统一处理保存模型时也能把预处理步骤一起保存到models/lightgbm_sales_model.joblib中。后续预测时只需要加载这个 joblib 文件不需要重新写编码逻辑。备餐建议逻辑位于src/recommender.py核心代码如下df[suggested_servings]np.ceil(df[predicted_sales]*(1buffer_ratio)).astype(int)df[rice_kg](df[suggested_servings]*df[rice_kg_per_serving]).round(2)这段代码看起来很简单但它完成了从模型输出到业务建议的关键转化。很多机器学习项目停留在预测值层面而实际项目更需要把预测值变成可执行动作。13. 运行方式首先安装依赖pipinstall-rrequirements.txt一键运行训练和预测python main.py--modedemo或运行python run_demo.py启动 Streamlit 看板streamlit run app.py也可以使用统一入口python main.py--modeapp--port8501Windows 用户可以双击或执行run.batLinux/macOS 用户可以执行bashrun.sh项目首次运行后会生成以下文件demo_data/canteen_sales.csv models/lightgbm_sales_model.joblib outputs/metrics.json outputs/test_predictions.csv outputs/forecast_next_7_days.csv outputs/prep_recommendations.csv outputs/ingredient_summary.csv images/results/sales_trend.png images/results/actual_vs_pred.png images/results/feature_importance.png images/results/prep_recommendation.png14. 如何替换成真实食堂数据如果要把项目改成真实校园食堂版本最重要的是保持数据字段稳定。真实数据至少应该包含日期、食堂、窗口、菜品、价格和销量。如果没有天气、温度、考试周和假期字段可以先填默认值再逐步接入外部数据。推荐的真实数据表结构如下date,canteen_id,window_name,dish_name,category,meal_period,price,weather, temperature,precipitation,is_weekend,is_holiday,is_exam_week,is_vacation, semester_week,sales_count如果学校能提供点餐系统、刷卡系统或窗口销售系统导出的数据可以按日聚合到菜品级别。如果只有订单明细则需要先按date canteen_id window_name dish_name分组统计销量。真实业务中还要注意菜单变更问题新菜品没有历史销量模型可能预测不稳定可以通过菜品类别、价格、窗口、相似菜品热度来缓解冷启动问题。15. 可扩展方向这个项目可以继续扩展成更完整的食堂智能经营辅助系统。比较实用的方向包括1. 增加真实天气接口自动读取未来天气预报 2. 接入学校校历自动标记考试周、运动会、节假日和寒暑假 3. 增加库存管理模块结合现有库存计算采购建议 4. 增加损耗成本优化“缺货损失”和“浪费损失”的平衡 5. 增加多模型对比例如 RandomForest、XGBoost、CatBoost、Prophet 6. 增加菜品冷启动策略用相似菜品估算新品销量 7. 增加数据库把 CSV 替换成 SQLite 或 MySQL 8. 增加用户权限区分管理员、食堂经理和窗口员工 9. 增加报表导出自动生成每日备餐 Excel 10. 增加模型定期重训脚本支持每周自动更新模型如果用于课程设计可以把重点放在数据生成、特征工程、模型训练和 Streamlit 看板如果用于工程展示可以继续补充数据库、登录权限和导出功能如果用于论文实验可以增加模型对比、特征消融实验和不同预测窗口的误差分析。16. 总结本文完成了一个基于 LightGBM Streamlit 的校园食堂销量预测与备餐建议系统。项目从模拟数据生成开始经过特征工程、模型训练、测试集评估、未来销量预测、备餐建议生成和 Web 看板展示形成了一个完整可运行的机器学习实战案例。相比只写一个模型训练脚本这个项目更接近真实交付它有清晰的目录结构有一键运行入口有模型文件和结果文件有图表和看板有 README 和文档也有可直接发布到 CSDN 的博客 Markdown。对于想做 Python 课程设计、机器学习项目实践、数据分析系统、校园管理系统原型的同学来说这个选题具备较好的实用性和可展示性。最终可以得到这样一条技术路线校园食堂历史销量数据 → 日期/天气/菜品/历史销量特征 → LightGBM 回归模型 → 未来菜品销量预测 → 安全库存比例修正 → 备餐份数与主料用量建议 → Streamlit 可视化看板项目不依赖外部模型权重不需要联网下载大文件CPU 环境即可运行。后续只要替换真实数据并补充业务字段就可以继续扩展为更完整的校园食堂经营辅助系统。参考资料LightGBM 官方文档https://lightgbm.readthedocs.io/LightGBM LGBMRegressor APIhttps://lightgbm.readthedocs.io/en/latest/pythonapi/lightgbm.LGBMRegressor.htmlStreamlit 官方文档https://docs.streamlit.io/scikit-learn TimeSeriesSplit 文档https://scikit-learn.org/stable/modules/generated/sklearn.model_selection.TimeSeriesSplit.htmlWikimedia Commons 校园餐厅场景图https://commons.wikimedia.org/wiki/File:College_dining_hall.jpg
