去年第四季度，一家中型消费品企业的供应链总监在内部会议上拍着桌子问我：“为什么我们的需求预测总是在节假日前两个月开始跑偏？每年都偏，每年都要手动修正。”我调出他们过去三年的销售数据，把BI平台里的时间序列分解图投在屏幕上。趋势线稳健向上，但季节分量像心电图一样剧烈波动，春节囤货高峰、618大促前置、双十一脉冲，三个周期叠加在一起，让任何不处理季节性的预测模型都成了“算命骰子”。那次分析之后我开始系统地研究一件事：在BI平台的时间序列分析中，剔除季节性因素到底对预测准确率有多大影响？什么场景该剔？什么场景不该剔？剔错了有什么后果？

这篇文章不是教科书式的理论复述，而是基于我在帆软九数云、FineBI等项目交付中遇到的真实案例，结合多个行业的预测复盘数据，试图回答上面的问题。如果你想提升BI看板里预测曲线的可信度，或者想搞清楚什么时候该做季节调整、什么时候该保留原始信号，这篇内容应该能给你一些可落地的判断框架。

一、核心结论：剔除季节性不是“标准动作”，而是“决策选择”

先直接给出我在实际项目中的基本判断，方便你快速抓住主线：

1. 剔除季节性因素，在绝大多数情况下能显著降低预测模型在训练集和验证集上的误差指标。在云仓物流日订单量预测、零售周销售额预测等典型场景中，剔除季节分量后的ARIMA、Prophet模型，其平均绝对百分比误差下降幅度普遍在15%-35%之间。
2. 误差下降不等于预测结果一定更“有用”。如果业务决策的核心诉求是“捕捉旺季峰值、提前备货”，那么保留季节信号（甚至放大它）可能比剔除后平滑的曲线更具有实战价值。
3. 剔除方法和剔除程度的差异，会导致完全不同的预测走向。简单地用同比减法剔除季节性，和用STL分解后移除季节分量，对残差信号的保留程度完全不同。
4. 在BI平台上操作时，工具的能力边界决定了剔除动作的上限。大多数BI工具（包括Power BI、Tableau、九数云、FineBI）只提供了移动平均、同比差分等简化方法，真正能完成STL或X-13ARIMA-SEATS分解的，需要借助Python/R集成或外部ETL流程。

所以结论不是一个“要不要剔除”的二选一问题，而是一个“在什么业务目标下、用什么方法、剔到什么程度、如何还原”的多决策链条。下面我们会逐一拆解。

二、背景和真实场景：季节性究竟在BI预测里扮演什么角色

1. 经典视角：季节性是“噪声”，需要被剥离

时间序列分析教科书会告诉你：一个时间序列可以被分解为趋势、季节、周期和残差四个成分。预测模型的理想状态是学习到稳定的趋势和周期规律，而季节性是“可预见的重复波动”，它不应该占用模型的参数容量。这个观点在统计学上是成立的，也是ARIMA模型要求序列平稳化的理论基础。我在2019年第一次接触供应链预测时，带我的技术负责人也是这么教的：“先把季节性干掉，让模型专心学趋势，学好了再把季节加回去。”

但真实业务场景比教科书复杂得多。云仓行业的日订单量，既受电商平台大促影响（618、双十一、年货节），又受天气、疫情封控、直播爆单等随机事件冲击。这些事件中，只有平台大促勉强算“季节性”，它固定日期、固定周期、每年重复。而直播爆单可能只出现在某个头部主播的档期里，根本不具备规律性。如果你机械地套用季节差分或STL分解，模型会把这些非规律性事件也当作“季节”来处理，导致剔除了不该剔的信号。

2. 真实场景：云仓行业的预测痛点

我在服务洁识供应链和先飞数智物流的过程中，观察到云仓行业预测的三个典型困境：

• 多SKU波动差异极大。一件代发的小商品（日用品、美妆）有很强的季节性，但品牌代工的大件（家电、家具）季节波动近乎为零。
• 入仓和出仓节奏分离。商家入仓预测需要按周或按月做，但出仓节奏是按日甚至按小时（直播发货），两个时间粒度上的季节性完全不同。
• 计划与实际偏差的归因困难。月初做了入仓计划，月底发现偏差30%，但说不清楚是备货策略问题、季节性估计不准、还是突发爆单。没有季节分量剥离，就无法进行分层归因。

这意味着：云仓行业既需要季节调整来分解误差来源，又不能无脑调整，因为某些SKU的季节性本身就是核心预测信号
不是噪声。

3. BI平台上的实际操作限制

理论归理论，实际在BI平台上做时间序列预测时，操作路径往往是非常受限的。多数BI工具的第一步是让你选择“预测方法”：移动平均、指数平滑、线性回归。稍微进阶一些的会内置ARIMA或Prophet。但这些模型对季节性的处理方式各不相同：

• 移动平均和指数平滑，实际上已经对季节波动做了平滑处理，等于“软剔除”，但无法还原。
• ARIMA通过`d`差分参数和`D`季节差分参数来控制，需要在建模前手动指定。
• Prophet会自动检测季节模式，你可以通过`yearly.seasonality`参数控制强度，但调节逻辑不直观。

更重要的是，BI平台上的“一键预测”按钮背后，往往隐藏了季节调整的逻辑，用户根本不知道模型到底剔没剔、剔了多少。这种黑箱操作在需要解释预测结果的业务场景里会带来很大的信任问题。

三、常见误区：我踩过的四个坑，以及它们如何影响预测准确率

接下来我想具体讲几个在项目中真实遇到的误区。这些误区不是理论推演，而是我或者我的同事在实际交付中踩过的，后来复盘时才发现根因都在季节处理上。

1. 误区一：“用对了模型就不用管季节性”

2019年我在一个快消品牌做预测项目时，技术团队坚持用Prophet，理由是“Prophet内置了季节建模，不需要人工干预”。第一批预测结果出来，MAPE大约22%，不符合验收标准。查了两个礼拜才发现：该品牌每年3月和9月有两次大型订货会，这是固定的商业日历事件，但Prophet把它和自然月份的季节性混在一起学习了。3月的预测严重偏高，9月又偏低，因为模型没有区分“订货会带来的脉冲”和“自然季节波动”。

判断逻辑：任何自动季节检测算法，都基于“频率×周期”的假设。如果你的业务季节性是人为定义的（比如订货会、招标周期、预算发放周期），算法很可能会误判。这种情况下反而需要手动剔除这些事件因素，或者把它们作为外部回归变量加入模型。

2. 误区二：“季节性是噪声，剔得越干净越好”

这是另一个极端，常见于有统计学背景的分析师。我在云港物流项目中见过一个案例：分析师用了极端的季节差分方法（连续两次季节差分），把时序变得非常“干净”，模型训练误差也降到了个位数。但问题来了：当需要把预测结果还原时，叠加上去的季节分量是“算法拟合出来的季节”，而不是“真实的商业季节”。结果是：预测值完美错过了春节前的入仓高峰，因为算法拟合的季节形态已经把2020年疫情冲击下的异常波动当成了“正常季节”的一部分。

判断逻辑：季节分量本身也有信噪比。如果你剔除季节性的方法过度拟合了历史数据中的“异常季节”，那么剔除反而引入了新的偏差。正确的做法是：只在季节模式稳定的情况下做剔除，且保留残差供人工判断。

3. 误区三：“同比或者环比就够了，不需要做分解”

很多BI用户习惯在公式栏里写“销售额同比增长率”，觉得这就是在做季节调整了。同比确实消除了年周期效应，但它有两个致命问题：一是只能和历史同期比，无法预测未来；二是把趋势变化也一并抹掉了。如果你的业务处于快速成长期，同比会说“增长了30%”，但时间序列分解会告诉你：趋势贡献了20%，季节贡献了10%。这种区分对于预测至关重要。

4. 误区四：“季节调整是一次性的数据预处理”

很多人以为季节调整做一次就行了，建模前处理一遍，然后模型跑下去就行。现实中季节模式是会变的。我在包装行业的精益生产项目中观察到：工厂的OEE（设备综合效率）原本有稳定的夏季低谷（高温导致设备散热问题），但产线做了自动化改造之后，这个季节规律被打破了。如果用改造前的季节参数去做调整，未来的预测会持续高估夏季效率。

判断逻辑：季节调整不是一个离线的预处理步骤，而是需要周期性验证和更新的动态过程。如果业务结构发生了重大变化（产线改造、渠道重组、产品换季），必须重新评估旧的季节参数是否仍然成立。

四、专业判断逻辑：一个四维框架帮你决定“剔不剔、怎么剔”

基于以上误区的复盘，我后来抽象出了一个四维判断框架。每当遇到新的预测项目时，我会依次过这四个维度，决定季节性处理的策略。

1. 维度一：预测的时间跨度

预测窗口越短，越需要保留季节信号（甚至故意不剔）。

如果你的预测用于下周的入仓计划、明天的出仓排班，那么季节性（甚至更短周期的星期效应）就是你要预测的核心信号本身。此时你做季节调整等同于把自己的预测目标给删了。

预测窗口越长（季度、年度），越有必要剔除季节，让模型聚焦在趋势上。

因为长周期预测的核心价值是判断“整体方向向上还是向下”，季节波动只是噪声。

2. 维度二：季节模式的稳定性

用历史数据滚动验证：取出前3年的数据，分别拟合季节分量，看3年间季节峰值是否出现在同一时段、幅度是否稳定。如果答案是肯定的，放心剔除。如果季节模式年际变化大，说明你的业务可能正在经历结构性变化，或者存在大量一次性事件冲击，此时机械剔除反而有风险。

我在包装行业设备OEE数据上做过这个验证：改造前3年的夏季低谷非常稳定（6-8月OEE下降7%-9%），改造后这个规律消失。如果在改造后继续按旧参数剔除，预测偏差会逐年累积。

3. 维度三：预测结果的使用者是谁

这是经常被技术团队忽略的维度。预测结果的使用者不同，对“季节性是否应该在最终结果里体现”的要求完全不同：

• 给仓库运营看的预测必须包含季节波动。仓库经理需要知道11月入仓量会翻倍，才好提前招人、租仓。给他一条平滑向上的趋势线等于没给。
• 给财务做预算的预测可以剔掉季节波动。财务需要判断全年总量，然后按月加权分配。先给出剔季节后的年总量，再用历史季节因子分配回各月，是他们习惯的路径。
• 给高管的战略看板建议保留趋势线同时标注季节区间。让他们一眼看到“正常情况下全年走势这样，加上季节波动范围在XX-YY之间”。

4. 维度四：数据质量和颗粒度

如果数据只有2-3年的历史，且颗粒度是“月”级别，总共也就24-36个数据点。这种体量下，季节分解的可靠性本身就不高（STL需要至少2-3个完整周期才能稳定）。这个时候强行剔除季节性，大概率是在“用噪声拟合噪声”。不如保留原始序列，在解释预测结果时口头说明季节性影响。

如果数据颗粒度是“日”级别、历史覆盖3年以上（1000+数据点），季节分解的效果会稳定很多。

五、案例和数据观察：云仓日订单量预测的对照实验

为了不空谈框架，我想完整复盘一个在云港物流做过的预测对照实验。这个实验没有发论文级别的严谨控制，但胜在用的是真实业务数据和真实业务决策环境，能反映BI平台上的实际表现。

1. 实验设置

数据：某区域云仓2020年1月-2023年6月的日订单量，共1278天。数据包含两个完整的大促周期（2021、2022），以及2020年上半年的疫情冲击异常值。

预测目标：预测2023年7-12月的日订单量。

模型：统一使用ARIMA(2,1,2)。

处理方案：

• 方案A（对照组）：不处理季节性，直接建模。
• 方案B：一阶季节差分（lag=7，处理星期效应；lag=365，处理年周期）。
• 方案C：STL分解后移除季节分量，用趋势+残差建模，预测后还原。
• 方案D：先用STL分解，移除季节分量后建模，预测后叠加“近两年平均季节分量”还原（而非直接用分解出的季节分量）。

方案D的设计初衷是：分解出的季节分量可能被2020年异常值污染，改用近两年平均季节分量更稳健。

2. 结果对比

几个关键发现：

1. 所有处理了季节性的方案都优于不处理的方案。MAPE差距在5-9个百分点，这在日订单量预测中意味着每月少错配数千件库存。
2. 大促月的改进远大于非大促月。这说明季节调整的核心价值恰恰在于“稳住大促预测”，而这正是业务最关注的场景。
3. 方案D在11月大促月表现最突出。原因就是它用“正常年份”的季节形态替换了被2020年异常值污染的季节分量。这印证了前面维度二和维度四的判断：季节分量的质量直接影响预测准确率。

3. 一个额外的发现：星期效应不能忽略

在这个实验中，我们用lag=7的季节差分处理了星期效应。如果不处理，周一和周六的订单量差异能到30%以上（周一少、周六多，因为是直播发货的集中节点）。这种“周内季节”在月粒度分析中会被平均掉，但在日粒度预测中如果不处理，误差会系统性偏高。BI平台上做日预测时必须检查星期效应，这是很多用户忽略的细节。

六、不同情况下的行动建议：从BI操作到预测体系建设

这一节我想给出可直接落地的操作指南。不同阶段、不同资源的团队可以从中选取适合自己的部分。

1. 如果你只有BI工具，没有代码能力

能做的事：

• 在BI计算字段里计算7日移动平均，快速观察平滑后的趋势走向。这不是严格的季节调整，但可以作为预测的基线参考。
• 用同比指标（今年vs去年同一时间）来判断季节性是否稳定。如果连续多个月的同比偏差在一个小范围内，说明季节模式稳定，可以放心做调整。
• 用条形图或热力图展示历史各月/各周的订单分布，可视化季节模式，手工判断哪些月份是“高月”、哪些是“低月”。

不能做的事：

• 不要手动在数据表里删除或修改数值来“去季节”，这会导致其他报表失效。
• 不要仅凭一个月的同比变化就断定季节模式变了。

2. 如果你能在BI外使用Python或R做预处理

这是更理想的配置。流程建议如下：

1. 在Python中用`statsmodels.tsa.seasonal.STL`或`seasonal_decompose`进行分解，输出四个分量表。
2. 将趋势分量和残差分量传回BI平台，作为预测模型的输入。
3. 在BI或Python中完成预测后，在BI看板层叠加季节分量还原。还原时务必区分加法模型和乘法模型的选择。电商销售额通常适合乘法模型（季节效应随趋势增长而放大），而工业产量通常适合加法模型（季节效应绝对值稳定）。
4. 将还原后的预测值作为最终呈现，同时保留“剔季节后的趋势预测”在后台供分析使用。

# 示例：Python中STL分解的基本调用（示意，非完整生产代码）
from statsmodels.tsa.seasonal import STL

import pandas as pd

df为包含日期和销量的DataFrame，已设置日期为索引

stl = STL(df['sales'], period=365)  # 日数据的年周期

result = stl.fit()

df['trend'] = result.trend

df['seasonal'] = result.seasonal

df['resid'] = result.resid

df['deseasonalized'] = df['sales'] - df['seasonal']  # 加法模型

3. 如果你在建设预测体系

建议从三个层面设计：

• 数据层：建立季节因子表，按月/周/日粒度保存历史季节分量，随新数据滚动更新。设定更新阈值（如季节分量的年际变化超过15%时触发人工复核）。
• 模型层：同时维护“剔季节模型”和“含季节模型”，根据预测用途自动选择输出。提供给运营的用含季节模型，提供给财务的用剔季节模型。
• 看板层：展示预测曲线时，用色带或阴影区域标示季节波动区间，而不是一条死板的单线。

七、不同情况下的取舍：当“正确”和“有用”冲突时怎么选

这篇文章的标题问的是“对预测准确率的影响”，但经过前面六节的拆解，你应该已经意识到：准确率不是唯一的目标函数。这里我想展开讲几个在实战中经常遇到的取舍场景，以及我在类似情况下是怎么做的。

1. 取舍一：短期的“峰值捕捉”vs长期的“趋势稳定”

这是最常见的取舍。业务部门希望你在大促前告诉他“峰值会到多少”，他们需要的是点预测的峰值精度。而财务部门需要一条平滑的趋势线来判断全年收入规模，他们需要的是平均预测偏差最小。

我的做法是：不同部门看不同的预测版本，但底层只有一套模型。 模型输入的是剔季节后的数据，模型输出趋势预测，然后叠加两套不同的季节还原：

• 给业务运营看的，叠加“激进季节因子”（纳入最近一年大促峰值，即使这个峰值可能是异常值）。
• 给财务看的，叠加“稳健季节因子”（取近3年平均，去极值后计算）。

这不是在操纵数据，而是在用同一个模型服务于不同的决策需求。关键是在看板上标注清楚季节因子的选取口径，让使用者知道自己看的是什么。

2. 取舍二：手工判断 vs 算法自动

算法能处理规律性的季节性，但当业务发生结构性变化时，算法是无感的。2020年疫情初期，所有基于历史季节模式的预测全部失效。当时我们团队的做法是：暂停自动季节调整，改为每两周一次的手工调整，由业务运营根据最新发货数据和封控政策输入一个“季节修正系数”。这个系数本质上是人工经验对算法输出的矫正。

这听起来很“土”，但在剧烈变化期反而是最有效的。关键是要设计好“何时切换回自动模式”的触发条件，我们设定的是“连续4周自动预测MAPE低于20%时恢复自动模式”。

3. 取舍三：数据量少的SKU怎么处理

不是所有SKU都有好几年的历史数据。新品、长尾商品可能只有几个月甚至几周的数据。对这类SKU强行做季节分解毫无意义。我的建议是：

• 找到这个新品的品类归属，借用同品类成熟SKU的季节因子。
• 如果拉不到品类数据，就不做任何季节调整，把有限的模型容量全部留给趋势学习。
• 在预测看板上对这个SKU打上“数据不足，预测仅供参考”的标签，提醒使用者不要过度依赖。

4. 取舍四：加法模型还是乘法模型

这个问题经常被忽略，但它直接影响预测准确率。加法模型假设季节波动幅度不随趋势变化（每年旺季比淡季多卖500件）；乘法模型假设季节波动随趋势成比例放大（每年旺季是淡季的1.5倍）。

识别方法很简单：把数据分成前后两半，分别计算季节波动的绝对值。如果前半段和后半段的波动幅度差不多，用加法；如果后半段明显更大，用乘法。

在云仓行业的日订单量数据上，我们验证的是乘法模型更优，因为随着电商体量增长，大促的脉冲绝对值也在增长。但在包装行业的OEE数据上，加法模型更合适，设备的季节性效率降低是绝对值固定的。

八、在九数云BI上做季节调整：一个可复用的操作思路

因为九数云是我们帆软自己的SAAS BI产品，我对它的能力边界比较清楚。这一节我会具体讲讲在这样一个零代码BI平台上，怎么把前面讲的季节调整逻辑落地。这些思路同样适用于FineBI或简道云的数据分析模块。

1. 在分析空间中用公式做“简易季节调整”

九数云的分析空间支持对数据表添加计算字段。你可以创建以下指标作为季节观测的基础：

• 当月占全年比例 = 月销售额 / 年销售额合计 × 100%，用来直观看到12个月的权重分配。
• 当月同比 = (今年月销售额 – 去年同月销售额) / 去年同月销售额，用来判断季节稳定性。
• 12个月移动平均值，近似趋势线，用实际值减去移动平均近似季节分量（仅适用于加法模型）。

这些公式在九数云里通过拖拽字段和简单函数就能实现，不需要写SQL。

2. 在仪表板上构建“季节看板”

我建议做一个专门的“季节稳定性监控”仪表板，包含以下组件：

• 12个月占比的环形图，展示年度季节权重分布。
• 各月同比变化率的折线图，横轴是年份，不同颜色的线代表不同月份。如果某条线的波动突然变大，说明该月的季节稳定性在变差。
• 关键月份（如11月大促）的实际vs预测偏差趋势，用于持续监控季节调整的效果。

这个看板不需要天天看，但建议每个季度（旺季前一个月）更新一次数据，判断季节参数是否需要调整。

3. 利用九数云的AI能力做异常归因

九数云最近上线的AI助手功能（可在仪表板右侧唤起），支持对异常波动做智能总结。当你发现某个月的实际值严重偏离预测时，可以直接让AI帮你分析可能的归因，它会自动关联你数据集中的维度字段，判断是促销活动影响、天气影响还是季节参数出了问题。这个功能目前还在内测，但在我们内部的几个客户项目里已经展现了不错的归因能力。

结合前文说的“手工判断vs算法自动”的取舍，AI归因可以帮你缩短从“发现预测偏差”到“定位原因”的时间，让手工修正更加高效。

回到文章开头那个拍桌子的供应链总监。我后来给他看了调整季节因子后的预测报表，11月的大促预测偏差从41%降到了15%左右。他问了我一句话：“这个准确率还能再提高吗？”我回答他：“能，但性价比不一定高了。剩下的偏差主要来自直播爆单这类随机事件，不是季节调整能解决的。”

这句话也是我整篇文章想传递的最后一条经验：季节性因素剔除是提升预测准确率的重要手段，但它有自己的天花板。识别出这个天花板在哪里，比盲目追求更高的准确率重要得多。

下一步你可以做的：

1. 从你负责的BI看板里拉出过去12-36个月的时序数据，做一个最基本的STL分解（哪怕先在Excel里画个12月移动平均线也行），看看季节分量的稳定性和强度。
2. 检查一下你当前的预测模型里有没有显式的季节参数设置，如果有，确认它是否还匹配当前业务状态（特别是如果业务在近两年经历了重大变化）。
3. 针对你最关注的一个核心指标（日订单量/月销售额/设备OEE），试着跑一次“剔除季节-预测-还原”的完整闭环，和现有预测结果做个对照，看看MAPE有多大差异。
4. 如果差异显著（超过5个百分点），值得把季节调整流程固化到日常的预测工作流里；如果差异不大，至少你收获了“我们当前的预测不需要额外的季节处理”这个结论，它本身也是有价值的。

预测这件事，从来不是算得越复杂越好。理解你数据里的节奏，比任何高级算法都更接近真相。

免费注册

咨询方案

扫码咨询方案