做算法测试这些年测过不少系统但要说哪种预测算法最难验证我第一反应还是烘焙订单预测。表面上看它就是个时间序列预测问题给模型扔一堆历史销量让它预测明天每个门店每款面包卖多少个。可真做起来你会发现天气、节假日、商圈客流、甚至隔壁奶茶店搞活动都会让预测翻车。更麻烦的是烘焙品大多是短保产品当天生产当天卖做多了是损耗做少了是缺货损失两头都是钱。这个项目总结我从数据准备、特征工程到模型评估、灰度上线整个流程都踩了一遍把订单预测算法测试的完整思路记录下来尤其是那些光看准确率看不出来的业务陷阱希望给正在做类似住宿餐饮场景预测的同学一些参考。1. 先搞清楚预测算法的边界业务问题拆解1.1 烘焙行业订单预测到底解决什么问题住宿餐饮这个大类下面烘焙门店的订单预测和其他餐饮业态有很大区别。正餐门店预测的是客流团餐预测的是份数而烘焙预测的核心是“SKU级别的生产量”也就是具体到某一款吐司、某一款可颂明天在某个门店该做多少个。这个核心诉求是由烘焙行业的经营模式决定的。面包蛋糕这类短保产品保质期通常只有1到3天很多门店甚至是凌晨生产、当天销售、晚上打烊报废。如果生产多了剩下的产品只能销毁直接变成损耗成本如果生产少了热门产品上午就卖光顾客买不到就会流失损失的是营业额和复购率。所以烘焙订单预测算法本质上是在做一个权衡在损耗成本和缺货损失之间找到利润最大化的生产量。这个业务特性决定了我们测试的重点不是模型拟合得有多漂亮而是预测结果放到门店生产计划里能不能真正降低“损耗率”和“售罄率”这两个业务指标。另外还有一个容易被忽略的点订单预测不是做单店总量预测而是要拆分到门店维度、SKU维度、日维度。我接手这个项目的时候算法团队给的 baseline 是一个全门店汇总的日销量预测误差看着挺小门诊一用就发现问题A门店和B门店的销量分布完全不一样汇总到一块每家门店都拿不准自己该生产多少。后面我们把预测目标改成门店 x SKU x 天维度一下从每天几十条数据扩到几千条但这才符合业务真实的决策场景。1.2 为什么这个场景的算法测试不能只盯着准确率做算法测试的同学应该都有体会模型指标和业务效果之间经常隔着一道鸿沟。这在烘焙订单预测里表现得尤其明显。比如 MAE平均绝对误差从 12 降到 10你看指标觉得不错但门店店长不会关心 MAE他关心的是今天可颂到底要做 80 个还是 100 个。误差从 12 降到 10可能只意味着少损失 2 个可颂的成本但如果误差分布不均匀某些高销量时段该多备货的时候预测低了顾客想买买不到这部分损失会远远大于算法指标提升带来的收益。还有一类问题也很典型即使模型的平均误差一样分布的形态也可能完全不同。有的模型是每天误差都稳定在正负 10% 左右有的模型是平时预测得很准一到周五就产生 30% 以上的偏差。对烘焙门店来说周末和节假日的备货策略本来就不同如果模型只在周五翻车那它在门店可用性就很差。所以我在设计测试方案的时候给自己定了一个原则离线评测不能只报一个“平均误差低”的结论必须把误差拆到门店层级、SKU 层级、星期维度、时段维度去看同时必须对照业务指标来解读。只有能说明“这个模型的误差在哪些维度变小了、在哪些维度变大了”这个测试报告才对业务有参考价值。2. 测试方案的整体设计与指标选型2.1 从业务指标倒推技术指标哪些数最能反映算法好坏做订单预测算法的测试第一步不是选模型也不是调参而是先把评测指标定清楚。我习惯从业务指标倒推技术指标因为只有知道业务上最关心什么才能知道离线评测要重点测什么。烘焙门店最关心的业务指标大致有三个。第一个是损耗率也就是当天生产但没卖完的产品占比。损耗率高说明预测值偏高生产做多了。第二个是售罄率或者说缺货率也就是产品在当天营业结束前就卖光的比例。售罄率高说明预测值偏低做少了。第三个是工时利用率预测总量影响排班和生产准备预测偏太多还会导致员工加班或者闲置。对应的技术指标上除了 MAE、MAPE 这些通用误差指标我更推荐重点观察两个东西一个是误差分布的偏度一个是高销量 SKU 的加权误差。误差偏度怎么看呢比如 MAPE 算下来是 15%很低对吧但如果把所有门店 SKU 的误差画成直方图你会发现大量的低销量 SKU 误差在 5% 以内少数爆款 SKU 误差能到 40%。爆款 SKU 对营业额的影响大测试报告里就不能只讲平均误差。所以我一般在评测报告里单独列一个“ Top 20 销量 SKU 的加权 MAPE”这个数更能反映模型对核心营收商品的表现。还有一个指标很容易被忽略预测值和实际值之间的相关性。有些模型输出的预测序列整体偏低但趋势跟实际值是一致的这种模型通过订单解读还能抢救一下有些模型输出值跟实际值基本不相关那即便 MAPE 看起来不错也不具备参考价值。相关性这个指标我每次测试都会加进去简单直接能快速发现模型是否学到了有效信息。2.2 数据集划分的坑时间序列不能随便 K 折如果把订单预测当作普通机器学习任务来处理随意用 K 折交叉验证很容易踩到一个大坑数据泄露。时间序列数据和普通表格数据最大的区别在于它是有严格时间顺序的预测目标是基于过去预测未来如果用未来的数据来训练模型那测试结果就完全失真了。我在项目里踩过一次这样的问题。最开始同事直接调了 sklearn 的 KFold 做交叉验证把每天的数据随机分到训练集和验证集中。结果验证集上 MAPE 只有 5%看起来效果非常好但部署到真实环境后效果一塌糊涂。原因很简单随机划分时验证集里的某一天数据它的前几天数据也在训练集里模型见过这段趋势等于“开卷考试”。正确的做法是使用时间序列的时序划分比如训练集取前 6 个月验证集取后 1 个月按时间顺序依次往后滑。我在这个项目里用的是滚动预测评估训练集从第 1 天到第 N 天预测 N1 天到 N7 天然后训练集延伸到 N7 天预测 N8 天到 N14 天这样模拟真实上线后的滚动预测流程。还有一点要注意节假日和大型促销活动会造成明显的数据偏移如果训练集里包含某个节假日的销售数据验证集恰好也包含对应的节假日就要小心模型是否过度依赖某个特定节假日的数据模式。我在划分数据集的时候会把节假日数据单独标记出来同时观察模型在节假日样本上的表现而不是简单地把所有日期混在一起算平均误差。3. 实操过程从基线模型到升级版预测的完整测试3.1 特征到底用了什么为什么是这些订单预测的特征工程决定了算法效果的上限。我在这个项目里把特征分成四类基础时间特征、历史销量特征、门店 SKU 属性特征、外部环境特征。基础时间特征包括星期几、是否周末、是否节假日、月份、季度等。烘焙产品有明显的星期周期性周一到周五的早餐面包销量好周末的下午茶蛋糕销量好。这些特征直接编码成 one-hot 或者数值特征丢进模型模型很快就能学到基本规律。历史销量特征是预测的核心特征包括过去 7 天、14 天、28 天的移动平均、上一天同一 SKU 的销量、上周同一天同一 SKU 的销量等。这里有个细节值得说一下不同门店适合的回看窗口不一样。旅游景区的门店受天气影响大近 3 天的移动平均比 28 天更有参考价值写字楼商圈的门店工作日销售额稳定28 天的趋势信息更重要。所以我们后面给门店做了聚类按门店类型分别生成不同的历史特征窗口效果比统一特征要好一些。门店 SKU 属性特征包括产品品类、价格带、是否新品、是否参与促销等。这些特征的作用主要是帮助模型理解“不同产品间的替代关系”比如某款芝士蛋糕缺货了顾客会不会转向买另一款芝士面包这种替代关系很难直接建模但通过品类和价格带特征模型可以从数据中隐式学到一部分。外部环境特征最常用的就是天气数据包括温度、降雨量、风力等级等。我可以直接说天气对烘焙销量的影响比想象中大得多。雨天会显著减少门店客流但对线上外卖订单影响不大。我把天气数据按门店周边 3 公里范围的气象站数据做匹配虽然在特征重要性排名里不是最靠前的但对降低雨天误差很有帮助。3.2 基线模型、进阶模型与验证流程测试一个预测算法的效果不能一上来就直接看最终模型的指标得先建立一个简单的基线模型拿它当参照系。否则你根本不知道复杂模型到底“好”在哪里指标提升是来自有效的特征还是纯粹的过拟合。我在这个项目里用的基线模型有两个一个是“上周同一天销量”直接作为本周预测值另一个是过去 7 天销量取移动平均后作为预测值。这两个基线模型完全没有任何机器学习成分但在很多门店的 SKU 上表现居然还不错尤其是那些销量稳定的家常品类。折线算下来基线 MAPE 大概在 28% 左右。然后我们在同样特征基础上对比了线性回归和 GBDT 类模型。经验上GBDT 类模型对表格类特征的处理能力更强也能自动学到一些非线性关系比如“下雨天且是周末”这两个条件同时满足时的销量衰减比单独下雨或单独周末时更大。最终我们选择了 GBDT 模型作为主模型在这套项目里大概把整体 MAPE 降到了 17% 左右。验证流程上我坚持每条产线都跑三遍一遍是当前迭代的模型快照一遍是上一个版本模型一遍是基线模型。跑完以后并行输出三份评测报告放到同一个对比表格里。很多团队的习惯是只报告新模型的指标其实少了对比就无法判断这个迭代到底是前进还是后退。评测报告里我会至少包含四张表整体指标对比表、分门店误差 Top10 表、分 SKU 误差 Top10 表、分星期误差汇总表。只有把误差定位到具体维度和具体样本上算法团队才能针对性地调整特征而不是盲目调参。3.3 核心环节分门店分 SKU 的误差分析分门店分 SKU 的误差分析是整个测试流程里最耗时、但也是最有价值的一步。平均误差会掩盖太多问题必须拆细了看。我举一个实际案例。某个景区门店的销量特点是平时很低、周末很高周末销量是平日的 8 到 10 倍。模型的 MAPE 测出来是 22%看起来不算差但拆开一看周一到周五的 MAPE 只有 15%周六周日的 MAPE 高达 45%。周末的预测值总是偏低导致门店周末频繁缺货这是直接影响营业额的。后来我们发现模型没能学到景区门店的“天气 周末”的交互效应晴天周末和雨天周末的销量能差 3 倍模型只看单一特征就漏掉了这个规律。再比如另一个案例同一款牛角包市区写字楼门店和社区门店的销量曲线差异很大。写字楼门店的销量集中在早上 8 点到 10 点社区门店的销量分散在下午和傍晚。模型把两类门店的同类 SKU 一起训练特征上只靠门店 ID 区分导致学习到的规律是“平均化”的两边都不太准。后面我们按门店画像做了模型分层或者把门店消费时段特征加进模型效果提升明显。误差分析的过程中我经常用到一个方法把预测值和实际值按星期、按时段画出对比折线用肉眼“扫描”一遍。这个方法听起来很笨但真的能发现很多统计指标发现不了的问题。比如某个 SKU 的预测值总是滞后实际值一天实际销量涨了第二天的预测才跟着涨上来这种滞后性在 MAPE 上不会特别突出但在折线图上一看就非常明显属于典型的特征工程没做够、模型学到的是“惯性”而非“驱动因素”。4. 上线前的验证与灰度测试不只发生在离线阶段4.1 离线测试通过之后先别急着全量离线测试只是第一关真正的考验是在线验证。离线指标好看不代表模型上线后就一定好用因为线上环境有太多离线数据里没有的情况门店手工调整过生产计划、促销活动临时上线、外卖平台做流量活动、产品原料临时缺货导致某些 SKU 停产等。这些都会让实际销量偏离模型预测的假设。因此我们采用了一套分阶段的灰度验证流程。第一阶段是影子模式模型并行运行在正式预测流程旁边但预测结果不直接流入门店生产计划只记录分值和店长手工预测值做比对。这个阶段能积累一个完整的“模型预测 vs 店长预测 vs 实际销量”三方对比数据用来判断模型是否真的具备落地价值。第二阶段是单门店试点选择 3 到 5 家不同业态的代表性门店用模型的预测值直接作为生产计划的一部分。试点期间测试工程师每天跟踪这些门店的生产量、实际销量、损耗量和售罄量并且和周边同期未试点门店的指标做横向对比。第三阶段才是区域放量。这里有一个经验可以分享灰度门店的选择不要全挑销量最大的门店因为大店的销量规律相对稳定容易被模型学好也不建议全挑社区小店小店样本少误差波动大容易误判模型效果。最好是头部、腰部、尾部门店各选一部分搭配商圈店、社区店、写字楼店、景区店等不同业态。4.2 追踪一版真实业务指标损耗率和售罄率上线后的业务验证阶段我跟踪的核心指标是损耗率和售罄率而不是模型误差。为什么要看这两个指标因为它们才是门店真正关心的结果变量。模型误差是手段指标损耗率和售罄率才是目的指标。具体统计口径要提前定义清楚。损耗率的计算是当日生产未售出产品数量除以当日生产总量售罄率的计算是当天营业结束前某一 SKU 已售罄的门店数比例。这里有个数据质量的坑很多门店在打烊时会把未卖完的产品做报损操作但如果店长忘记报损或者有些产品被内部员工买走数据就会失真。所以在验证的时候我们要找运营同事一起核对报损数据的准确性不能只依赖系统自动记录的数据。我们试点跑了 4 周和基线期对比试点门店的损耗率下降了约 2.5 个百分点售罄率基本持平个别主打产品线的售罄率略有上升。整体算下来单店每周减少的报损金额还是比较可观的。但我也得说实话这个提升并不是均匀分布的有的门店效果非常明显有的门店几乎没有变化。后面分析发现效果不明显的门店往往存在品项管理混乱、生产计划执行不到位的情况即模型预测得再准门店没有严格执行也是白搭。这一点在测试报告里必须如实写出来否则容易让业务方对算法能力产生不切实际的预期。5. 踩坑实录订单预测测试中最容易翻车的几个地方5.1 节假日预测失灵的经典案例节假日是订单预测算法最害怕的场景没有之一。烘焙产品在节假日的销量波动极其剧烈而且不同类型的节假日影响的方向和幅度完全不同。我遇到过一个经典案例母亲节当天的蛋糕类产品销量是平时的 6 到 8 倍但如果模型只学了历史数据它会给出一个相对平稳的预测值实际销量远超预测导致严重缺货。反过来清明节当天的门店客流会明显下降如果模型不具备节假日识别能力它会把清明节当天预测得和平常日子差不多结果门店生产多了损耗上升。处理节假日问题不能只靠算法团队在模型里加一个“是否节假日”的二值特征因为不同的节假日对不同类型的 SKU 影响差异太大。更合理的做法是为节假日单独建立一套预测逻辑或者使用节假日当天的相似年份数据、以及节前预售数据来做修正。测试阶段我们也专门设计了节假日回归测试集把过去一年的节假日数据单独保留反复检验模型在节假日样本上的表现。5.2 新品没有历史数据怎么办新品的销量预测是另一个老大难问题。烘焙店每个月都会出新品新品没有历史销量数据模型无法直接预测。如果测试方案里不考虑这个问题那么新品一旦上线模型输出就会直接失效门店店长只能靠经验拍脑袋决定生产量。我们当时的处理方案是按属性匹配“相似老品”。测试工程师先对新品打标包括品类、口味、价格带、目标人群、上市季节等属性然后从历史库里找到属性最相似的老品作为参考样本用老品的销量曲线做缩放处理再加上一个“新品效应”的调节系数。一般来说新品刚上市的头几天销量偏高因为顾客有尝鲜心理后面会回落到正常水平。这个调节系数可以从历史新品的表现数据中统计出来但并不总是稳定的。这是我觉得测试里比较有价值的部分我们做了一个“冷启动预测准确性”专项测试把新品数据单独切片验证模型在新品上的 MAPE 是否在可接受范围内同时观察调节系数是否需要按品类细分。整个专项做下来新品冷启动的预测误差从最初的 45% 以上降到了 25% 左右虽然依然比老品误差高但至少不会出现完全跑偏的情况。5.3 数据和特征里的“陷阱”最后整理几个数据层面的坑给做类似项目的同学提个醒。第一个坑是门店维度的销量数据并不都是真实的顾客需求。缺货的 SKU 当天销量是 0但这个 0 并不代表顾客不想买而是没货可卖。如果一个门店连续几天某款产品缺货那么历史销量数据就会一直低估真实需求模型学到这个低估信号接着预测低产量形成恶性循环。处理方式是在数据清洗时打上缺货标记或者用同商圈其他门店的销量做补充估算。第二个坑是促销记录不完整。烘焙门店经常做买一送一、第二件半价等活动促销期间的销量涨幅很大如果数据里没有标记这几天的促销状态模型会把促销的高销量当成常态导致后续预测偏高。所以我建议促销数据至少要记录“是否促销”“促销类型”“促销力度”三个字段缺一不可。第三个坑是门店营业时间变动。有些门店会在节假日调整营业时间或者因为设备检修临时关店半天这些都会导致销量异常低。如果不做处理模型可能会把这些异常值当成正常波动学进去。数据管道里最好设置一个布尔标记当天是否正常营业、营业时长是否发生变化把这些变化控制在特征空间里解释而不是让模型从销量值的噪声里乱猜。第四个坑也是最容易被忽视的预测目标和数据统计周期不一致。比如门店的生产计划通常在前一天晚上就要定下来那么预测的目标是“截至当天营业结束的全天销量”还是“截至当天下午 4 点的销量”如果生产决策只需要覆盖下午之前的销量而模型预测的是全天销量那门店执行的时候还需要自己折算非常容易出偏差。测试的时候必须明确预测目标的具体口径并和业务方反复确认避免模型上线后才发现口径对不上。回到这个项目本身烘焙订单预测的测试实践最终沉淀下来的不只是几个模型和指标更是一套“先理解业务、再设计评测、再追踪指标”的方法。我个人的体会是做预测类算法的质量保障最大的难点不是模型不够先进而是评测标准和业务需求之间容易错位。如果从一开始就把测试目标定义成“帮助门店降低损耗、减少缺货”而不是“把 MAPE 降到某个数字”后面所有的工作都会顺畅很多。最后再分享一个小技巧每次模型迭代记得保留旧版的预测结果和评测报告三个月后回头看你会从那些“历史错误”里学到比新模型更多的东西。