1. 从一张点菜单说起：餐厅销量预测到底在预测什么
很多人第一次接触“餐厅销量预测”这个题目，脑子里浮现的画面是：拿一堆历史流水，丢进某个模型，然后输出明天卖多少份宫保鸡丁。真做过餐饮数据的人会告诉你，事情没这么简单，也没这么玄乎。它本质上是一个时间序列预测问题，而且是一个被大量现实噪声包裹的时间序列问题。
我在一个模拟项目里做过完整的餐厅销量预测链路，从原始小票数据到最终给店长看的备货建议，中间踩过的坑比模型本身多得多。这篇文章就把这条链路完整拆开，讲清楚每一步为什么这么做、参数怎么定、哪些地方最容易翻车。适合两类人看：一类是刚学完时间序列分析课程、想找个真实场景练手的同学；另一类是在餐饮或零售行业做数据、运营，想自己搭一套预测逻辑的从业者。
先说清楚这个问题的边界。餐厅销量预测通常分几个粒度：菜品级（每个SKU每天卖多少份）、品类级（凉菜、热菜、主食、饮品）、门店级（全天总营业额或总单量）。粒度越细，噪声越大，预测难度越高。菜品级预测受限于菜单更替、临时沽清、厨师手感，波动极大；门店级相对稳定，受天气、节假日、周边活动影响更明显。所以做之前第一件事不是选模型，而是确定你要预测的粒度和决策用途——是为了备货（菜品级）、排班（时段级），还是做营收预估（门店级）。用途不同，整个技术方案完全不同。
关键词里提到的“数据挖掘”和“时间序列分析”，在这个场景里是两套互补的工具。数据挖掘负责从原始数据里挖出特征——星期几、是否节假日、天气、促销活动、历史滑动平均；时间序列分析负责建模时间依赖结构——趋势、季节性、自相关。只做时间序列，你会漏掉外部变量；只做数据挖掘式的回归，你会忽略序列自身的记忆性。真正好用的方案，是把两者缝在一起。
下面我按实际做项目的顺序展开：先讲数据从哪来、怎么清洗，再讲特征怎么构造，然后是模型选型和参数，接着是评估与调优，最后是落地时那些文档里不会写的坑。
2. 数据获取与清洗：小票数据比你想的脏十倍
2.1 餐厅数据的三个来源与各自的坑
餐厅销量数据一般来自三个地方，每个地方的脏法都不一样。
POS收银系统导出是最常见的来源，通常是一张订单明细表，字段包括订单号、下单时间、菜品名称、数量、单价、桌号、支付方式。坑在于：退菜和赠菜会以负数或零价出现，如果不处理，你的销量会被低估；套餐会把多个菜品打包成一个条目，需要拆解；改价、打折会让单价字段失真，但销量字段一般还是准的。我一般会先做一次订单状态过滤，只保留已完成且未退菜的记录。
外卖平台后台是第二个来源，字段结构和POS不同，时间戳精度可能只到分钟，菜品名称和堂食菜单对不上（比如“招牌红烧肉（小份）”和“红烧肉”）。这里必须建一张菜品映射表，把不同渠道的名称归一到同一个SKU。这张表是手工维护的，别指望自动匹配能100%准确。
手工台账或排班表是第三个来源，用来补充外部信息，比如当天是否有包场、是否临时停业、厨师请假。这些信息往往不在系统里，但对销量影响巨大。我见过一个案例，某天销量骤降40%，模型完全无法解释，后来查台账才发现当天中午停电两小时。这种事件如果不标注出来，会严重污染训练数据。
2.2 缺失值与异常值的处理逻辑
时间序列最怕两件事：缺失和异常。餐厅数据里，缺失通常不是真的没卖，而是没记录。比如某天POS故障，整天的数据都没了；或者某个菜品当天沽清，销量为0，但这是“不可售”而非“需求为0”。这两种情况必须区分。
我的处理原则是：先判断缺失机制，再决定填充策略。如果是随机缺失（比如个别订单漏记），可以用前后几天的均值或中位数填充；如果是系统性缺失（整天没数据），直接填充会引入偏差，更好的做法是标记为缺失并让模型跳过，或者在特征里加一个“数据可用性”指示变量。
异常值检测我用得最多的是IQR法和滚动Z-score。IQR法适合整体分布，滚动Z-score适合捕捉局部突变。比如某天某菜品销量是平时的5倍，可能是团购大单，也可能是录入错误。这时候不能一刀切删掉，要先看订单明细：如果是一笔大额订单，那是真实需求，应该保留但标注为“大单事件”；如果是多笔正常订单，那可能是促销带来的真实峰值，更要保留。异常值不等于错误值，这是新手最容易搞反的地方。
提示：清洗阶段一定要保留原始数据的一份快照，所有清洗操作都记录成可复现的脚本。后面模型效果不好时，你一定会回头怀疑是数据问题，没有快照就只能重来。
2.3 时间粒度的对齐
原始数据是订单级的，时间戳精确到秒。但预测通常按天或按小时。这里要做重采样。按天聚合时，要注意营业时间的定义：是自然日0点到24点，还是营业日（比如凌晨2点打烊，那凌晨1点的订单算前一天）？餐饮行业普遍用营业日概念，如果不统一，跨天订单会算错日期。
按小时聚合时，要处理营业时间外的数据。比如门店10点开门，但9:50有预订订单，这个算哪个时段？我的做法是定义一个营业时段映射表，把每个时间戳映射到对应的营业小时，非营业时段的数据单独存放或丢弃。这一步看起来琐碎，但直接影响后续季节性特征的准确性。
3. 特征工程：让模型看懂“今天为什么特殊”
3.1 时间特征：不只是星期几
时间序列预测里，时间特征是最基础也最容易被低估的。很多人只加一个“星期几”就完事，实际上餐厅销量的时间模式至少有四层。
星期效应是最强的。周一到周四通常平稳，周五开始爬升，周六周日是峰值。但注意，不同品类的星期模式不同：商务区餐厅工作日午餐旺，周末反而冷清；社区餐厅周末家庭聚餐多。所以星期特征要和门店类型结合看。
月份和季节效应体现在菜品结构上。夏天凉菜和饮品销量上升，冬天火锅和汤类上升。这个用月份或季度特征可以捕捉，但更细的做法是用气温直接建模，因为季节的本质是气温变化。
节假日效应分两类：法定节假日（春节、国庆）和商业节日（情人节、双十一）。法定节假日要区分“节前”“节中”“节后”，因为节前可能备货囤积、节中可能闭店、节后可能反弹。商业节日更多是促销驱动，需要和营销日历对齐。
发薪日效应是我在实际项目里发现的一个隐藏规律。很多门店在每月10号或15号前后销量会小幅上升，因为周边上班族发工资了。这个特征不加，模型在月中会有系统性偏差。
3.2 滞后特征与滑动窗口：给模型装上记忆
时间序列之所以是时间序列，核心在于当前值依赖过去值。滞后特征就是把过去的值作为当前的特征。比如预测今天销量，可以用昨天、前天、上周同一天的销量作为特征。
滞后阶数怎么选？看自相关图（ACF）和偏自相关图（PACF）。如果ACF在7阶处有显著峰值，说明周季节性存在，滞后7是必要的。一般餐厅日销量数据，我会加滞后1、2、3、7、14这几阶。滞后1捕捉短期惯性，滞后7捕捉周周期，滞后14捕捉双周模式。
滑动窗口特征是滞后特征的升级版，用过去N天的均值、中位数、标准差、最大值、最小值。窗口长度通常取7和14，对应一周和两周。滑动均值比单点滞后更稳健，因为它平滑了随机噪声。但要注意，滑动窗口必须严格只用预测时点之前的数据，否则就是数据泄露。我见过有人用全量数据的均值做特征，模型在训练集上表现完美，上线后一塌糊涂，就是这个原因。
3.3 外部变量：天气、活动、竞品
餐厅销量受外部因素影响极大，但这些数据往往不在你的数据库里，需要额外采集。
天气数据可以从公开气象接口获取，字段包括温度、降水、风力、天气类型。对餐厅来说，降水和极端温度是关键：下雨天堂食减少、外卖增加；高温天饮品销量上升。我一般会把天气做成分类特征（晴/阴/雨/雪）加连续特征（温度、降水量）的组合。
周边活动包括商场促销、演唱会、体育赛事、学校考试周。这些信息需要人工维护一张事件日历。事件的影响通常是短期的、脉冲式的，可以用一个二值特征加一个“事件强度”评分来表示。
竞品动态比较难获取，但可以用一些代理指标，比如周边同类餐厅的开业/闭店、外卖平台上的竞品促销力度。这个在实际项目里往往靠运营人员的主观判断，做成一个低/中/高的有序特征。
3.4 特征构造的常见陷阱
第一个陷阱是未来信息泄露。所有特征在预测时点t必须只使用t之前的信息。滑动窗口、滞后、累计统计都要严格遵守这条。检查方法很简单：把数据按时间切分，训练集用早期数据，验证集用后期数据，如果验证集效果远差于训练集，大概率有泄露。
第二个陷阱是特征过多导致过拟合。餐厅日销量数据通常只有几百到几千条，特征加到几十个就容易过拟合。我的经验是特征数量控制在样本量的1/10以内，优先保留业务上可解释的特征。
第三个陷阱是类别特征编码不当。星期几、天气类型这些类别特征，如果用独热编码，维度会膨胀；如果用序号编码，会引入虚假的大小关系。我一般用目标编码或嵌入，但目标编码要注意用交叉验证的方式计算，避免泄露。
4. 模型选型：从朴素基线到集成模型
4.1 先建一个朴素基线，别急着上深度学习
我见过太多人一上来就LSTM、Transformer，结果连“上周同一天卖了多少”这个基线都打不过。朴素基线是必须的，它告诉你问题的难度下限。
最简单的基线是昨天销量（lag-1），稍好的是上周同一天销量（lag-7），更好的是过去四周同一天的均值。这三个基线在餐厅日销量预测上往往能解释60%到80%的方差。如果你的复杂模型连这个都超不过，说明特征或数据有问题，不是模型不够强。
基线的另一个作用是设定评估标准。比如MAPE（平均绝对百分比误差）在基线是15%，你的模型做到12%，那就是有意义的提升；如果基线是8%，你做到12%，那就是退步。
4.2 统计模型：SARIMA和指数平滑
SARIMA（季节性差分自回归移动平均）是时间序列的经典模型，适合有明确趋势和季节性的数据。它的参数是(p,d,q)(P,D,Q,s)，其中s是季节周期（日销量数据s=7）。定阶方法：先看ADF检验确定d，再看ACF/PACF确定p和q，季节部分同理。
SARIMA的优点是可解释性强，参数有明确的统计含义；缺点是无法直接纳入外部变量，而且对缺失值和异常值敏感。如果数据干净、外部因素影响小，SARIMA是个稳妥选择。
指数平滑（Holt-Winters）比SARIMA更简单，适合趋势和季节性平稳的数据。它的三个平滑参数（水平、趋势、季节）可以用网格搜索或极大似然估计。实际用下来，Holt-Winters在短期预测（1到7天）上表现往往不输SARIMA，而且计算快、调参少。
4.3 机器学习模型：梯度提升树是主力
梯度提升树（如XGBoost、LightGBM）是我在餐厅销量预测里用得最多的模型。原因有三：能直接吃外部变量、对缺失值和异常值鲁棒、特征重要性可解释。
用树模型做时间序列，核心是把序列问题转化成监督学习问题：用滞后特征、滑动特征、时间特征、外部特征作为X，当前销量作为y。这样就能用所有标准的回归流程。
关键参数上，我一般这样起步：树的数量500到1000，学习率0.05，最大深度4到6，子采样0.8，列采样0.8。餐厅数据样本量小，深度一定要浅，否则很容易记住噪声。早停（early stopping）是必须的，用验证集监控，连续50轮不提升就停。
4.4 深度学习：什么时候值得上
深度学习（LSTM、GRU、Temporal Fusion Transformer）在餐厅销量预测上不是不能用，而是性价比通常不高。它需要大量数据才能发挥优势，而单店日销量数据往往只有几百到几千条。如果要做多门店联合预测，数据量上来了，深度学习才有意义。
如果一定要用，我的建议是：先用树模型跑一个基线，再用LSTM做对比。LSTM的输入是滑动窗口序列，输出是未来N天预测。注意要做差分或归一化，否则梯度不稳定。训练时用早停和Dropout防过拟合，序列长度一般取14到28天。
4.5 模型融合：简单平均往往就够了
多个模型各有优劣，融合能提升稳定性。最简单的是加权平均，权重用验证集上的误差倒数。复杂一点的是堆叠（stacking），用一层元模型学习各基模型的组合方式。但在餐厅销量这种小数据场景，简单平均通常和堆叠差不多，而且更不容易过拟合。
我的做法是：SARIMA或Holt-Winters负责捕捉线性季节结构，LightGBM负责捕捉非线性外部影响，两者按6:4或7:3加权。这个组合在多个模拟项目里都比单模型稳定。
5. 评估与调优：别只看一个误差指标
5.1 时间序列的交叉验证怎么做
标准K折交叉验证在时间序列上不能用，因为它会打乱时间顺序，导致未来信息泄露。正确做法是滚动窗口交叉验证（walk-forward validation）：用前N天训练，预测后M天，然后窗口向前滑动。
具体参数：训练窗口至少覆盖两个完整季节周期（日销量数据就是14天以上，最好28天），验证窗口取7天（一个完整周）。滑动步长取7天。这样能得到多个验证结果，看均值和方差。
如果数据量很小，可以用扩展窗口：训练集从固定起点开始，每次增加新数据，验证集始终是紧接着的下一段。这样训练集越来越大，更接近实际部署时的情形。
5.2 误差指标的选择与解读
常用的误差指标有四个：MAE（平均绝对误差）、RMSE（均方根误差）、MAPE（平均绝对百分比误差）、SMAPE（对称平均绝对百分比误差）。
MAE最直观，单位就是销量，但受量纲影响，不同菜品之间不好比较。RMSE对大误差惩罚更重，适合关注极端情况的场景。MAPE是百分比，跨菜品可比，但当真实值接近0时会爆炸——餐厅里某个菜品某天只卖1份，MAPE可能到100%以上。SMAPE对MAPE做了对称修正，但解释性稍差。
我的建议是主指标用MAE或RMSE，辅助看MAPE，但要把销量为0或极低的样本单独处理。另外，一定要看误差的时间分布：如果误差集中在周末或节假日，说明模型对峰值的捕捉不够，需要加强相关特征。
5.3 调参的优先级与实操
调参不要盲目网格搜索，按影响从大到小排优先级。
第一优先级是特征。加一个有效的滞后特征或外部变量，效果往往超过调参半天。我一般先固定模型参数，把特征集调到一个合理水平，再调参。
第二优先级是学习率和树的数量。这两个是耦合的：学习率低，树要多；学习率高，树要少。我一般先设学习率0.1，用早停确定树的数量，再降到0.05看效果是否提升。
第三优先级是树的结构参数：最大深度、最小叶子样本数、子采样比例。餐厅数据样本少，最小叶子样本数要设大一点（比如20到50），防止叶子节点记住个别样本。
第四优先级是正则化参数：L1、L2、Gamma。这些在过拟合明显时才需要调。
5.4 残差分析：模型没告诉你的秘密
残差是真实值减预测值。残差图能暴露很多问题：如果残差有趋势，说明模型没捕捉到趋势；如果残差有周期性，说明季节性没建好；如果残差在某些时间段特别大，说明有未建模的事件。
我习惯把残差按时间画出来，再按星期几、月份、天气分组看。有一次我发现残差在雨天系统性偏负，说明模型高估了雨天销量，回头检查发现天气特征用的是前一天的数据，而不是当天的预报数据。这种问题不看残差根本发现不了。
6. 落地部署：从Notebook到店长的备货单
6.1 预测流程的自动化
模型在Notebook里跑通只是第一步，真正有用的是每天自动出预测。流程一般是：定时任务拉取最新数据、清洗、构造特征、加载模型、预测、输出结果、推送给店长。
定时任务用cron或调度框架都行，关键是失败要有告警。数据拉取失败、特征构造异常、预测结果超出合理范围，都要能通知到人。我见过一个系统因为某天数据源改了字段名，静默失败了一周，店长拿到的还是旧预测。
模型文件要版本化，每次训练保存模型和对应的特征列表、参数。预测时加载指定版本，避免“今天用的模型和昨天不一样”这种问题。
6.2 预测结果怎么呈现给店长
店长不关心MAPE，他关心的是“明天备多少货”。所以输出要转化成决策语言：每个菜品建议备货量、置信区间、风险提示。
我一般会输出三列：预测销量、建议备货量（预测销量乘以一个安全系数，比如1.1到1.2）、风险等级（根据预测区间宽度和近期波动）。风险高的菜品标注出来，提醒店长人工复核。
另外，预测要可解释。店长会问“为什么明天预测这么多”，你要能回答“因为明天是周六、天气晴、上周同期销量高”。把特征重要性或类似案例附上，能大幅提升店长的信任度。
6.3 人工反馈闭环
再好的模型也会有偏差，关键是建立反馈机制。店长实际备货和销售后，把真实销量回传，用于下一轮训练。同时，店长可以标注“今天有特殊情况”，比如临时团购、设备故障，这些标注作为事件特征进入模型。
这个闭环跑起来后，模型会越来越贴合门店实际。我做过的一个模拟项目，跑了三个月闭环后，MAPE从18%降到了11%，主要提升来自对本地事件的捕捉。
7. 那些文档里不会写的坑
7.1 菜单更替导致的历史数据断裂
餐厅换菜单是常事，但这对时间序列是灾难。旧菜品的销量历史在新菜品上不可用，新菜品没有历史。我的处理方式是：按菜品类别建模，而不是按单个SKU。比如“川味热菜”这个类别，即使具体菜品换了，类别的销量模式相对稳定。新菜品上市后，先用类别预测，积累几周数据后再单独建模。
7.2 促销活动的滞后效应
促销当天销量高是常识，但促销后几天销量往往会下降，因为需求被提前透支了。这个滞后效应如果不建模，促销后的预测会系统性偏高。我的做法是加一个“距上次促销天数”的特征，让模型自己学习衰减模式。
7.3 数据频率与预测粒度的匹配
用日数据预测日销量是自然的，但如果你想预测时段销量（午餐、晚餐），日数据的粒度就不够了。这时候要么用小时数据重新建模，要么用日销量乘以一个时段分布比例。后者简单但粗糙，前者需要的数据量更大。我的建议是：如果时段分布稳定，用比例法；如果时段模式在变化，老老实实用小时数据。
7.4 模型更新频率的权衡
模型多久重新训练一次？每天、每周还是每月？频率太高，计算成本大且可能过拟合近期噪声；频率太低，模型跟不上模式变化。我的经验是：每周重新训练一次，用最近3到6个月的数据。同时保留一个“在线更新”机制，每天用新数据微调，但每月做一次全量重训。
7.5 预测的不确定性沟通
预测永远有误差，关键是管理预期。我一般会给店长一个区间，而不是一个点估计。比如“明天宫保鸡丁预计卖80到110份，建议备100份”。区间宽度反映不确定性，宽区间提醒店长留出调整空间。同时，定期回顾预测准确率，让店长知道模型在什么情况下靠谱、什么情况下要人工介入。
8. 一个可复现的最小实现路径
如果你现在想动手做一遍，我建议按这个顺序来，不要跳步。
第一步，找一份餐厅销量数据。没有真实数据就用模拟数据，但模拟时要加入星期效应、季节效应、随机噪声和偶尔的脉冲事件，这样才有真实感。
第二步，做数据清洗和探索性分析。画出时间序列图、ACF/PACF图、按星期分组的箱线图。这一步的目的是建立对数据的直觉。
第三步，构造特征。先做时间特征（星期、月份、节假日），再做滞后和滑动特征，最后加外部变量（天气、事件）。每加一组特征，用简单的线性回归看效果变化。
第四步，建基线。用lag-7和过去四周均值做基线，记录MAE和MAPE。
第五步，上LightGBM。用滚动窗口交叉验证，调学习率和树的数量，看特征重要性。
第六步，对比SARIMA或Holt-Winters，做简单加权融合。
第七步，做残差分析，找出系统性偏差，回头补特征。
第八步，把流程脚本化，输出预测结果和备货建议。
这条路径走下来，你对餐厅销量预测的理解会比看十篇论文都深。模型只是工具，真正决定效果的是你对业务的理解和对数据的敏感度。我在实际项目里最大的体会是：花在数据清洗和特征构造上的时间，应该占总时间的70%以上。模型选型那一步，反而没那么关键。
