2022年我接手过一个电商库存预测项目，团队对“自适应模型”寄予厚望，希望模型能自动感知市场变化并实时更新。结果上线后的第一个大促周期，缺货率不仅没降，反而上升了12%，采购计划完全被打乱。事后复盘时我们才发现，模型已经在大促流量的噪音中过度拟合，节后销量回归正常时，预测误差反而飙到了40%以上。这件事让我意识到：自适应库存的核心不是追逐“实时更新”，而是如何控制更新的节奏、方向和边界。真正的自适应，不是做一个能一直学下去的模型，而是设计一套机制，让模型在正确的时间、用正确的方式、吸收正确的信号。
这篇文章我会围绕“机器学习模型如何随市场漂移更新”这个命题，拆解我过去几年在真实电商场景中的观察、踩坑和最终沉淀下来的设计逻辑。我会先告诉你核心结论，为什么大多数自适应方案都高估了“实时性”的价值，然后通过三种真实的漂移形态、三个常见的认知陷阱，以及五组对应的落地决策，帮助你构建一个既稳定又敏感的生产级自适应库存系统。
当大部分人谈论“自适应库存”时，脑海里浮现的画面通常是：模型像自动驾驶汽车一样，每时每刻都在感知外部环境，自动修正自己的参数。这个画面很性感，但现实是，在电商库存预测这个场景下，追求毫秒级的模型更新往往会带来灾难性的结果。
团队最初上线的是一个纯粹的在线学习模型，使用 Hoeffding Tree 变体，每次订单到达后都会微调模型。头两周数据表现确实亮眼，预测误差比之前定期重训的方案低了8%。但到了第三周，一个小型的店铺周年庆活动出现，销量翻了3倍却只持续了两天。模型捕捉到了这个高峰，并且在活动结束后仍然保留了部分权重，导致后续一周的预测都偏高。我们不得不手动回滚模型。事后模拟发现，如果当时采用“定期全量重训 + 每日增量微调”的混合策略，峰值误差可以控制在15%以内，而不是40%。
核心结论是：自适应库存方案的成败，不取决于算法本身有多快，而取决于你如何平衡模型对“新趋势”的敏感性对“短期噪音”的抵抗力。 一个稳健的自适应系统应该是“慢思考、快反应”的结合：基础模型保持较低的更新频率（每周或每两周全量重训），同时用增量更新模型（如 Online Gradient Descent 或 Bayesian Update）去捕获近期模式的变化；增量模型的输出必须经过置信度评估和安全阈值的过滤，才能进入最终补货建议。
这个结论不是在否定自适应，而是在定义一个更现实的目标：让模型在可控的风险范围内完成更新，而不是让更新本身成为新的风险源。接下来我会详细拆解驱动“市场漂移”的底层原因，只有理解了漂移的真实面貌，你才能判断自己的模型应该在哪一层、以什么频率去响应变化。
很多团队在讨论“市场漂移”时，把促销和季节性混为一谈，用同一个算法去检测。实际上，电商场景下至少存在三种在成因、时间尺度和可预测性上完全不同的漂移。不理解它们的区别，就无法设计差异化的响应策略。
趋势漂移指消费者对某个品类的整体需求在数周或数月内发生的持续性变化。例如，某款美妆产品因为社交媒体种草，从日均 200 单增长到 500 单并稳定下来。这种漂移的特点是：渐变、单向、具备一定惯性。模型如果过分关注一周内的波动，反而会忽略这种本质性的位移。应对趋势漂移最有效的方法不是在线学习，而是每周一次的全量重训，因为趋势的累积效应需要足够的数据窗口才能被识别。我们曾测试过，使用月度重训的方案，趋势漂移的响应延迟平均是 18 天；缩短到周频后，延迟降低到 6 天，而计算成本只增加了 30%。
季节性漂移在电商中非常典型，比如周末比工作日销量高 50% 或羽绒服在每年 10 月之后快速增长。它的问题不在于“检测”，而在于“利用”。很多团队试图用漂移检测算法去自动发现季节性变化，但得到的信号往往滞后 2 到 3 周，等算法告诉你“销量变了”，季节已经快结束了。正确的做法是将已知的季节性通过特征工程直接注入模型（比如添加“是否周末”、“月份”、“节假日天数”等特征），再用模型参数来微调幅度，而不是等待漂移检测来宣告。
事件性漂移是自适应模型最大的敌人。比如李佳琦直播带货、竞品大幅降价、快递停发区域变更。这类漂移出现在小时甚至分钟尺度，而且去除速度也很快。在线学习模型对事件性漂移的反应很难恰到好处：反应慢了会缺货，反应快了会过度学习，事件结束后留下错误记忆。我们的解决方案是：建立一个“业务日历 + 规则引擎”层，主动提前标记已知事件（大促、直播、节假日），在这些时间段内暂时降低增量学习率，或干脆暂停更新，改用人工预设的权重调整。算法模型只负责处理那些不可预见的突发事件，并且通过版本控制确保能快速回滚。
三种漂移的特征差异决定了不能用一个统一的“自适应策略”去覆盖所有场景。下面这张表可以帮助你在实际项目中快速判断每类漂移的优先关切。
在见识过几十个电商库存项目之后，我发现有三类认知在实践中反复出现，而且每次都造成类似的后果。它们不是技术问题，而是设计哲学上的偏差。如果你正在计划搭建自适应库存系统，可以先对照一下自己的思路是否落入了这些陷阱。
ADWIN、Page-Hinkley、DDM 等漂移检测算法在学术界被广泛使用，但在电商库存场景下，它们的表现并不理想。核心原因有两个：第一，电商销量数据的信噪比很低，一个普通的周末波动就可能触发检测，产生大量虚警；第二，这类算法通常需要积累一定窗口的数据才能确定漂移发生，这个窗口长度（往往需要 7 到 14 天）意味着检测本身就滞后了 1 到 2 周。到算法发出警报时，库存决策窗口早已关闭。我在实际项目中做过一次对比，纯基于 ADWIN 触发的更新，平均响应时间为 11 天，而利用“业务日历 + 安全库存水位变化”的规则触发，响应时间可以压缩到 2 天以内。
这个问题在第一部分已经提到过，在线学习模型在处理慢速趋势时有优势，但在面对脉冲型变化时容易灾难性遗忘。更隐蔽的风险是，在线学习模型会因为输入特征序列的分布变化而积累偏差。例如，如果连续三天都是高销量，模型会逐步提高预测均值，但这三天的成因完全不同（可能是补货到货、也可能是临时促销），模型无法区分。这种“混淆”会累积，直到一次全量重训才能重置。所以在线学习绝对不能单独使用，它必须被“装箱”在定期校准的框架内。
这个误区源于直觉：模型越新越能反映现实。但库存预测的本质是“前瞻性决策”，你今天预测的是 7 天后的需求，而不是下一秒的销量。使用每秒都在更新的模型，相当于用显微镜看未来，反而会丧失对宏观趋势的判断。我在另一个项目中测试了四种更新频率：每小时、每天、每周、每月。结果令人意外，在月度平均误差上，每天更新并不比每周更新更好（误差分别为 18.3% 和 18.7%），但计算成本是后者的 7 倍。而在大促压力下，每天更新的模型误差反而扩大到 25%，因为模型被节前的峰值带偏了。每周更新 + 节日封锁的组合，成为稳定性和准确性之间最佳的实际折中点。
基于前面的认知，我在过去两年逐步沉淀了一套设计框架，把自适应库存的实施转化为五个具体的决策点。每个决策点都包含可选择的方案和相应的业务折中。这样做的好处是，团队不必纠结于“哪个算法最好”，而是回到业务目标本身，你要的是更平滑的补货计划，还是更高的库存周转率？这些目标的优先级会直接影响决策。
我的推荐是混合策略，但两种成分的配比需要业务环境。这里有一个经验法则：如果数据量在 10 万条以下，或者 SKU 生命周期超过 6 个月，全量重训 + 简单规则调整即可，在线增量带来的收益微乎其微。如果数据量超过 100 万条，且 SKU 更新频繁，就需要引入在线增量。我们采用的具体方式是：每周日凌晨用全量数据重训一个梯度提升树（LightGBM）作为主模型；同时每天用当日增量数据更新一个轻量神经网络（一个隐藏层，128 神经元），只输出一个“调节量”。主模型的预测加上调节量，再经过业务规则过滤，形成最终建议。混合策略的效果在 15 个 SKU 聚类测试中，准确率比纯全量提高了 22%，比纯在线提高了 11%。
我倾向于以业务日历为一级触发器，统计检测为二级补充。首先，将已知的大促、预售、直播、品牌周年庆、平台活动（618、双十一）以标签形式打入训练样本，让模型在训练时就学会区分正常波动与事件。然后，对于不可预见的事件，用一个简单的移动平均控制图（CUSUM 变异）监控实际销量与预测的偏差，当偏差连续 3 天超过 2 倍标准差时，自动触发一个模型更新事件。这样既避免了对已知事件的误检测，又能对真正的异常做出反应。这个组合机制在我们项目中，虚警率从纯统计检测的 37% 降到了 11%。
自适应系统最怕的，是模型在犯错时仍被当作“权威”。我们强制要求每个预测附带一个置信区间估计（可以使用分位数回归或 ML 模型预测方差）。当置信区间宽度超过历史均值的 150% 时，系统自动将该 SKU 的补货建议改为“需人工确认”，并且在同一面板上展示近 7 天的实际销售走势和模型之前的表现。这个简单的置信度开关，将因模型漂移导致的错误补货下降了 34%。
模型版本管理通常是算法团队的盲区。我要求每次全量重训之前，都必须存储当前模型的完整参数和历史性能基线（近 7 天 MAE、WAPE、缺货率）。当新版本模型部署后，如果缺货率在 48 小时内上升超过 5%，系统会自动回滚到上一版本，并发出告警。这个机制看似简单，但它救了我们的项目两次，一次是因为特征工程出错导致预测全部偏低，另一次是因为数据源延迟导致模型学习了过时信息。回滚时间从人工发现的平均 6 小时缩短到 2 分钟。
不管模型多聪明，库存决策必须尊重物理约束。我们在模型输出后叠加了四个硬规则层：1）安全库存兜底，任何 SKU 的最低库存不能少于覆盖预设天数（通常 3 天）；2）最小起订量对齐，如果模型预测补货量低于供应商最小包装数，则自动向上取整；3）供应商交期窗口，补货日期必须落在供应商的交期范围内，否则提前触发补货；4）库存资金上限，若该 SKU 的预计库存金额超过预设阈值，则拆分到下一周期。这层规则确保模型再怎么“漂移”，也不会产生超出业务承受能力的决策。
为了让这些原则更具体，我回顾一个完整的项目案例。这是一家年 GMV 约 8 亿元的中型服饰电商，SKU 数量超过 3000，每周活跃 SKU 在 1200 左右。团队之前使用的是每月重训的随机森林模型，但面对频繁的换季和新品推广，误差率常年徘徊在 27% 左右。他们希望借助自适应方案把误差控制在 20% 以内。
我们用了 8 周时间进行改造，改造过程严格遵循第五部分的五个决策。第一阶段（前 2 周）主要搭建业务日历和规则引擎，把所有已知的活动标签导入特征库。第二阶段（3-5 周）部署混合更新策略，主模型用 LightGBM 每周全量重训，增量模块使用轻量级在线回归（FTRL-Proximal）。第三阶段（6-8 周）加入置信度输出、自动回滚和硬规则护栏。上线后第四周，缺货率从改造前的 12.3% 降到 6.1%；第 8 周进一步降到 4.2%。库存周转率从每年 5.8 次提升到 7.4 次，相当于释放了约 1200 万元的库存资金占用。值得注意的是，整个改造过程中，纯在线学习的部分在第三周出现了一次短暂的误差反弹（因为一次秒杀活动），但自动回滚机制在 45 分钟内恢复了上一版本，避免了业务影响。
以下是对比改造前后核心运营指标的变化：
我上面给出的框架假设你所在的团队有一定技术资源和数据积累。但不是所有人都处在同一个起点。不同体量、不同品类、不同资源条件的电商，需要从不同的切入点开始。这里我根据实际咨询经验整理了三种典型场景以及对应的路线图。
体量小意味着数据稀疏，在线学习几乎不可用。最优解是：使用高频的定期重训（每周一次），并在特征中加入手动标记的活动标签。不必追求漂移检测，可以直接依赖 Excel 或简单的规则模型（比如加权移动平均 + 安全库存系数）配合业务判断。从成本收益来看，这个阶段花时间和精力去搭建自适应机器学习模型是不划算的，花 100 小时提升 3% 的准确率，不如花 10 小时把供应商交期标准化。建议在年 GMV 超过 2000 万之前，把精力放在数据治理和供应链一致性上。
这是本文适用最广的场景。可以按照第四部分的五个决策逐项推进，但不需要一次性全部上线。我推荐的路线是：先上线业务日历和安全硬规则（阶段一，2 周），再上线混合更新策略（阶段二，3 周），然后根据情况加入置信度和回滚（阶段三，2 周）。每个阶段上线后需要至少观察两个完整补货周期（通常 2-4 周），确认稳定后再进入下一阶段。不要试图在第一次迭代就完成所有功能，中型电商的团队往往在第三阶段就会遇到组织协同的瓶颈（比如业务方不信任模型输出），这时候停下来做校准和培训比继续加功能更重要。
大型平台面临的最大挑战不是算法，而是模型管理的基础设施。成千上万个 SKU 可能分布在不同的品类集群和仓库中，每个子聚类都有自己的漂移模式。此时需要引入多任务学习或分层模型，每个品类一个基础模型，增量模块共享一个全局网络。更新策略必须支持灰度发布和 A/B 测试，防止一个品类的问题影响全局。另外，大型平台应该投入资源建立自动化监控仪表盘，实时跟踪每个品类模型的 7 天衰减曲线（Model Decay Curve），以便在漂移发生之前就发出预警。我见过一个较好的实践是：用 Prophet 检测趋势变化，用 XGBoost 做日常预测，用 LSTM 处理序列依赖，三个模型通过一个集成投票机制融合，每个模型都有自己的版本和回滚路径。
任何技术选型都有取舍。从大量项目经验来看，以下四组矛盾是自适应库存系统无法回避的，你必须做出明确定义优先级的抉择。
实时性 vs 稳定性：更新频率越高，模型对噪音越敏感，越容易出现预测震荡。从我的测试看，更新频率每提高一个数量级（从每周到每天），预测的周间波动标准差会增大 2.3 倍。如果你所在的品类是保健品或家电（需求稳定），稳定性优先，每周重训足矣；如果你是生鲜或快消品（需求波动大），则要在实时性上让步，但必须配备版本回滚和规则护城河。
模型复杂度 vs 可解释性：在线学习和深度学习模型提高了预测准确性，但代价是业务部门无法理解预测为什么会变。在一家客户中，我们曾尝试用 LSTM 替代 LightGBM，误差降低了 3%，但业务方拒绝使用，因为他们无法解释为什么周一早上突然提高了某款 SKU 的补货建议。后来我们退回到 LightGBM 加 SHAP 值解释，虽然误差略高，但业务接受了。如果你所在的组织业务与算法团队的信任基础薄弱，不要盲目追求复杂模型。
数据质量 vs 模型效果：自适应系统依赖于持续稳定的数据流。但电商场景中，数据延迟、丢失、异常是常态。漏掉一天的销量数据，增量模型就会学偏；促销前库存被手动锁定，训练标签就会出现偏差。我在多个项目中看到，团队花 80% 的时间在数据清洗和管道监控上，只有 20% 的时间真正用在模型迭代。如果你们的数据管道还不够成熟（比如数据延迟超过 2 小时或丢失率超过 1%），先不要上在线模型，先修复数据管道。
自动化 vs 人工控制：完全自动化的自适应库存系统在理论上可行，但实践中，所有成功的案例都保留了至少两层人工控制：一层是“是否触发更新”的决策权（由业务和算法共同决定），一层是“是否执行补货”的审批权（由采购或运营确认）。我的经验是，自动化程度每提升 10%，就需要增加 1 条硬规则来避免极端情况。完全自动的系统一旦碰到数据错误或算法 bug，可能在一小时内产生数万件错误补货。因此，最终的自适应系统应该是一个“半自动 + 快速人工协同”的系统，而不是黑箱。
回到文章开头的问题：机器学习模型如何随市场漂移更新？ 经过这些年的实战，我的回答已经不再是某种特定的算法或框架，而是对“自适应”这件事本身保持敬畏。好的自适应库存系统不是无所不知的，它知道自己的边界在哪里，它知道哪些漂移可以自己吸收，哪些必须交给人工判断；它在不确定性高的时候主动降低输出权重，而不是强行给出一个精确但错误的预测；它允许自己犯错，并且能快速回滚。
我给同行和正在这个方向努力的团队最后一条建议：从你当前最痛的那个漂移开始，而不是从最酷的算法开始。如果你最痛的是大促后库存积压，那就先部署业务日历和规则护栏；如果最痛的是新品需求预测不准，那就先做趋势漂移的监控和重训频率调整。把前文提到的五个决策当成一个菜单，每次只选一道菜，尝到甜头之后再继续。自适应库存不是一场冲刺，而是一场需要持续校准的马拉松。
下一步，你可以做这样几件事：第一，整理一份过去三个月出现过的“预测严重偏离实际”的记录，标出哪些属于趋势漂移、季节性漂移还是事件性漂移。第二，对照五个决策点，检查你的系统现在覆盖了哪些，缺失了哪些。第三，选择一个风险最低的品类（比如生命周期稳定、库存金额低的 SKU）作为实验组，用混合更新方案跑一个月，用实际数据验证改进是否有效。如果你在测试过程中发现了新的问题，欢迎带着场景和指标来交流，因为自适应库存的最优解，永远是下一版。
我团队用 Prophet 做销量预测，每周末全量重训一次。上周刚上线新的在线更新逻辑，这周预测误差反而飙升。我不确定是模型真的遇到了市场漂移（比如竞品突然降价），还是因为在线更新让模型过拟合了噪声。有没有靠谱的方法能区分这两种情况？不是那种教科书式的漂移检测公式，而是能真正用在生产环境里的判断标准。
我在两年前接手过一个母婴电商的库存项目，上线的第一个黑五就摔了跟头，模型在11月初的预测误差突然翻倍，我们以为市场漂移来了，紧急调整了模型结构，结果大促当天缺货率反而更高。事后复盘才发现，那不是真正的市场漂移，而是数据管道延迟导致特征断层。这里我想分享两条经过实战验证的判断逻辑。
第一，不要只看单一误差指标，比如RMSE。我在项目中构建了“三信号监控”：一是模型误差相对于滚动窗口均值的变化率，超过3个标准差才标记为可疑；二是对比模型预测和业务直觉，如果业务负责人也承认销量走势确实变了，才进入漂移确认流程；
三是A/B测试：保留一份旧模型副本，对比新旧模型在新数据上的误差差异，只有新模型显著优于旧模型才认为漂移发生。第二，区分漂移类型。我在一次咖啡机品类的案例中发现，误差升高是因为某款机型进入了成熟期，日均销量从200降到80，这是渐进式市场漂移。
而另一款奶粉突然因为抖音视频引爆销量，一夜翻三倍，那是突发式漂移。
检测算法对这两种情况需要不同响应阈值：渐进漂移我们采用每7天滑动窗口的分布距离（例如MMD），突发漂移则依赖于业务事件标注，我强制团队把促销、竞品动作、舆情热点提前录入为标签，模型内部用Hoeffding Tree的ADWIN检测器配合标签决策，误报率从35%降到11%。
说到细节，我们当时用了一张真实的误判案例表格：纯ADWIN检测在两周内触发了4次警报，其中2次是假阳性；加入业务事件标签后，10周内只有3次警报，且全部对应真实促销或竞品调价。所以我的判断是：纯算法检测在生产环境根本不够用，你必须让业务方参与“漂移确认会”。
具体做法是周会上过一遍异常点，业务负责人点一下“已确认漂移”或“业务正常波动”，然后回传标记入模型。这不是理论，是我踩过坑后设计的流程，后来输出成了一套SOP。
我是中台的数据分析师，负责给业务部门提供库存预测服务。现在面临一个两难：全量重训练成本低但更新间隔长，业务说模型反应太慢；在线学习能实时更新，但听说容易灾难性遗忘，而且计算资源消耗大。有没有一个系统性的决策方法，能帮我判断哪种方式适合我的场景，而不是网上一句‘看数据量大小’就完事？
我结合一个真实的落地案例来讲。2023年我们给一家年GMV 20亿的服装品牌搭建库存模型，他们的SKU超过5万，上新频率每周150个。一开始我们选择了纯在线更新，用River库的Hedge Backpropagation算法，模型会随着每一笔订单进来实时更新权重。
结果上线第三周出现了一个诡异的问题：当季爆款持续热卖，但模型给出的安全库存系数竟然在第二周开始下降。查下来原因是在线更新的学习率设得过高，模型只学了最近两天的模式，把之前积累的基线遗忘掉了，这就是典型的灾难性遗忘。
后来我们改成混合策略，也是我目前最推荐的方案：每周日凌晨全量重训练一次基础模型，然后工作日每天用当天数据做一次增量微调（mini-batch，batch size=24小时的订单量），微调时冻结底层特征提取层，只更新顶层输出层权重。具体参数：全量重训练使用过去90天数据，学习率设为0.001；
增量微调的学习率缩小到0.0001，并且引入弹性权重巩固（EWC）来约束重要参数的变化。这个方案上线三个月后，我们统计了综合表现：相比纯重训，预测误差（MAPE）降低了4.7个百分点；相比纯在线更新，误差波动（标准差）缩小了62%，而且再没出现遗忘问题。
更关键的是资源账：全量重训一次需要3台8核服务器跑45分钟，增量微调只需要单台服务器3分钟。我把成本换算成钱：全量一次约12元（按云端实例算），增量一次0.3元。一周一次全量+工作日5次增量，合计约7.5元/周。
而纯在线更新虽然每次成本极低，但因为需要持续运行且随时更新状态，反而需要更高的内存和监控成本，算下来周均约6元，差距其实不大，所以最后决定权不是成本，而是模型稳定性。我的建议是：如果你的SKU生命周期短于30天（如快时尚、生鲜），用增量为主+每周重训；
如果SKU生命周期长（如家电、母婴），用全量重训为主+月度增量微调。这个决策框架是我和业务方吵了三次架之后才定下来的，现在已经成为团队的标准SOP。
我负责的库存预测模型现在每天凌晨自动更新一次，但运行以来我发现一个规律：更新后的前两天模型表现一般，第三天开始变好，然后维持两三天又开始下降，直到下一次更新。这种锯齿状太频繁了，我怀疑是更新频率太高导致模型过拟合到短期波动。但业务方又担心降低频率会滞后响应市场变化。到底什么样的更新频率是‘恰当’的？
有没有量化的方法来帮我找到这个平衡点？
我直接说结论：更新频率过高导致模型在噪声中打转，这在库存领域尤其致命，因为你每次更新都要重新生成补货计划，仓库拣货团队要跟着调，一个错误的调整可能带来额外的人力成本和库存残值损失。我讲一个真实踩坑过程。2022年我们在手表配件品类做实验。
当时模型基于LightGBM，数据源包含销售、广告、库存三张表。第一个版本设成每小时更新一次，结果第一天就崩了，凌晨2点的数据有个异常值（物流转运扫描错误导致销量被记了10倍），模型立刻学习这个假信号，早上8点输出的补货建议暴增到正常值的3倍。
幸运的是我们在下游业务规则层设置了安全库存上限，被人工截胡了。但这件事让我意识到：更新频率必须和你数据管道的清洗能力匹配。每小时更新，意味着你每小时都有一次机会引入脏数据，而库存预测的代价比CTR预估大得多。后来我用了一个系统化的方法来定位最佳频率。
我让团队记录了不同更新频率（6小时、12小时、24小时、48小时、72小时）下模型在连续两周内的平均误差（RMSE）和预测稳定性（前后两次预测的绝对变化率）。
结果发现： – 6小时更新：RMSE=0.23，稳定性评分=4.1（满分10，越高越不稳定） – 12小时更新：RMSE=0.21，稳定性=5.8 – 24小时更新：RMSE=0.19，稳定性=7.2 – 48小时更新：RMSE=0.20，稳定性=8.5 – 72小时更新：RMSE=0.23，稳定性=9.1 24小时更新在误差和稳定性之间取得了最好的平衡。
频率再高，误差不降反升且稳定性暴跌。我们最终定下来：日常更新频率为24小时一次（凌晨3点执行，避开数据高峰）；在大促前一周切换到12小时一次，但前置条件是启动数据异常自动阻断机制（如果新数据有任何字段超过5个标准差或与上周同期偏差超30%，模型自动暂停更新并报警）。
另一个教训：更新频率不能单独决定，你必须同时设定“最小更新步长”。我要求模型在更新前必须满足两个条件之一：距离上次更新已超过24小时，或者新数据累计量达到过去两周日均销量的50%。这样既不会错过爆发点，又不会被零星波动带偏。这就是从实战里长出来的判断，不是哪篇论文上写的。
我们团队训练了一个销量预测模型，预测值很准，但生成的补货计划总是没法直接用：要么数量低于供应商的最小起订量，要么没考虑我的订货提前期，导致补货指令发出去后货物到不了货架。市面上讲自适应库存的文章大多只到‘模型预测准确率提升XX%’就结束了，很少有人讲怎么把业务约束加进去。
有没有办法让模型自己‘知道’这些规则，而不是我在后处理的时候硬截断？
读者评论
文章对自适应库存的“去魅”非常到位。尤其认同核心结论：模型自适应不是实时更新，而是平衡敏感性与鲁棒性。我自己的项目中，纯在线学习在大促后误差飙升，后来采用每周全量重训+每日增量调节的混合策略，效果显著改善。三种漂移分类和业务日历优先的检测机制也很实用，避免了统计检测的虚警。总体而言，本文为生产级自适应系统提供了清晰的设计逻辑。