AI Forecasting、Demand Planning 与产品架构 Playbook

面向已具备 CBAP 级需求工程、金融零售业务理解与架构协作经验的读者。本 playbook 不讲 BA 入门方法，而是聚焦如何把 AI 预测能力设计成可审计、可运营、可落地的产品与架构资产。

Source Anchors

以下资料用于校准术语、模型边界与治理框架。本文不是论文复述，而是面向金融零售、零售、电商、客服与容量规划的产品架构转译。

一句话定位

Forecasting 产品架构的核心不是“把未来数值预测得更准”，而是构建一个可治理的 forecast-to-decision loop：把不确定性、约束、成本、服务水平、人工覆盖与审计证据连接起来，让预测稳定转化为库存、资金、客服、人力、产能和风险动作。

为什么重要

金融零售与零售业务中的预测不是孤立分析任务。一次预测会触发资金调拨、库存补货、营销节奏、呼叫中心排班、云资源扩容、门店现金配送、欺诈监控阈值、授信额度管理和管理层预警。如果架构只交付点预测，业务会在真正决策时自行补齐风险偏好、置信边界和例外处理，结果通常是：模型看似准确，运营仍然失控。

高级 AI 产品与架构视角下，forecasting 的价值体现在五个层面：

1. 决策前移：从月末复盘转向周内滚动、日内调度和事件前模拟。
2. 不确定性显性化：用 probabilistic forecasting 和 prediction intervals 表达风险，而非只给一个 P50 数字。
3. 层级一致性：通过 hierarchical forecasting 让 SKU、门店、区域、渠道、品类、国家级预测可加总、可解释、可问责。
4. 运营可闭环：预测结果进入 demand planning、capacity forecasting、资金计划、客服排班和异常处置流程，而不是停留在 dashboard。
5. 治理可审计：将数据版本、特征可用时间、backtesting、leakage 检查、人工覆盖与审批记录纳入 forecast governance。

Forecast-to-Decision 架构

Time-series forecasting product architecture 应从“业务动作”倒推，而不是从模型倒推。架构分为九层：

flowchart LR
    A[Decision Context<br/>库存/资金/客服/容量/风险] --> B[Forecast Contract<br/>粒度/周期/范围/延迟/服务水平]
    B --> C[Data Products<br/>交易/库存/事件/日历/价格/排班/宏观]
    C --> D[Feature Layer<br/>calendar holiday event features<br/>价格 促销 天气 工资日 账单日]
    D --> E[Model Portfolio<br/>Baseline Prophet DeepAR TFT TimesFM NeuralForecast]
    E --> F[Probabilistic Forecast Service<br/>P10 P50 P90 quantiles prediction intervals]
    F --> G[Decision Engine<br/>补货 现金调拨 人力排班 预算 容量]
    G --> H[Workflow Layer<br/>审批 覆盖 例外 协同计划]
    H --> I[Monitoring and Governance<br/>backtesting leakage drift audit]
    I --> B

1. Decision Context

每个预测产品必须先定义“预测会改变什么动作”。典型决策包括：

2. Forecast Contract

Forecast Contract 是产品与数据科学团队之间的“预测合约”。它比“需求说明”更硬，因为它决定了数据、模型、指标、SLA 和治理边界。

3. Data Product Layer

预测不是直接读取源系统表，而应读取面向预测的数据产品。金融零售环境尤其需要数据血缘、权限、可追溯与跨系统一致性。

关键数据域包括：

模型与方案选择

模型选择应由业务粒度、预测周期、数据规模、外生变量、解释要求与治理成本共同决定。高级团队通常使用 model portfolio，而不是押注单一模型。

方案选择矩阵

DeepAR 的产品架构定位

DeepAR 适合“许多相关序列共享模式”的场景，例如：

• 门店 SKU 日销量。
• ATM 或分行现金需求。
• 客服技能组每日 contact volume。
• 支付交易量和渠道负载。
• 账户余额或现金流类别的分组预测。

产品上应把 DeepAR 定位为概率预测引擎，而不是只输出均值的回归模型。它的核心价值是让 planning team 看到 P10/P50/P90，并据此选择不同服务水平。

Temporal Fusion Transformer 的产品架构定位

Temporal Fusion Transformer 适合多变量、多步预测，尤其适合同时使用：

• 静态特征：门店类型、区域、SKU 类别、客户等级、技能组。
• 历史观测特征：销量、价格、库存、等待时间、交易量、余额。
• 未来已知特征：节假日、促销计划、账单日、营销排期、计划价格、排班。

TFT 的价值不只是精度，也包括变量重要性、时间段关注权重和对业务解释的支持。面向金融零售落地时，TFT 应配合模型卡、特征审查和回测证据，否则复杂度会压过收益。

TimesFM 与 foundation models 的定位

TimesFM/foundation models 更适合作为以下能力：

• 原型阶段的快速 benchmark。
• 长尾序列、短历史序列的候选基线。
• 新市场、新门店、新品类上线早期的冷启动辅助。
• 与本地模型形成 ensemble，提升异常周期的稳健性。

它们不应被包装为“免治理预测”。所有 foundation model 输出仍必须通过本地 backtesting、prediction intervals 校准、业务例外审查和数据合规评估。

NeuralForecast 的工程化定位

Nixtla NeuralForecast 的价值在于把神经预测模型纳入统一训练、预测和评估流程，适合构建企业级实验矩阵：

• 同一批序列上对比 DeepAR、TFT、N-BEATS、NHITS 等模型。
• 同一套 rolling-origin backtesting 对比不同 horizon。
• 输出统一格式供预测服务、dashboard 和决策引擎消费。
• 将模型实验结果进入 model registry 和 forecast governance。

数据、特征与层级预测

预测粒度设计

粒度不是越细越好。粒度选择要匹配决策动作、数据密度和治理能力。

Calendar、Holiday 与 Event Features

高级预测架构要把 calendar/holiday/event features 当作正式数据产品管理，而不是在 notebook 中临时拼接。

关键原则：预测时点不可使用未来才知道的信息。促销计划可以作为未来已知特征，实际销售后才确认的促销执行效果不能在训练样本中以未来口径回填到预测时点。

Hierarchical Forecasting

金融零售和零售预测天然是层级问题。高级架构应同时处理业务层级与时间层级。

业务层级示例：

Company
  Region
    Store
      Channel
        Category
          SKU

财务现金流层级示例：

Enterprise Liquidity
  Currency
    Legal Entity
      Bank Account
        Cashflow Type
          Product Segment

客服容量层级示例：

Customer Operations
  Market
    Channel
      Skill Group
        Queue
          Interval

三种常见策略：

层级预测的产品价值是减少“总部 forecast 和门店 forecast 对不上”的计划摩擦。架构上需要保留每层原始预测、调整后预测、调整方法和影响量，供财务、供应链、运营共同审阅。

概率预测与 Prediction Intervals

Point forecast 只能回答“最可能是多少”。金融零售决策更需要回答：

• 如果需求高于预期，缺货成本是多少？
• 如果现金流低于预期，需要准备多少流动性缓冲？
• 如果 contact volume 达到 P90，SLA 是否还能守住？
• 如果交易量落在 P95，支付通道和风控队列是否有容量？

输出格式

推荐输出至少包含：

评估指标

概率预测要避免只看 MAPE。更完整的评估组合包括：

高级产品负责人要坚持“预测指标”和“决策指标”双轨评估。模型误差下降但库存周转变差，说明 forecast-to-decision loop 没有真正优化。

Backtesting 与 Leakage 治理

Backtesting 设计

时间序列不能随机切分。推荐 rolling-origin backtesting：

Train: Jan-Mar  Predict: Apr week 1
Train: Jan-Apr  Predict: May week 1
Train: Jan-May  Predict: Jun week 1

每个 backtest fold 都应模拟真实预测时点：

• 只使用预测时点已经可用的数据。
• 未来已知特征必须来自冻结计划版本。
• 库存、价格、促销、财务到账等修正数据要按 as-of 时间重建。
• 指标按 horizon 分层展示，例如 D+1、D+7、W+4、M+3。
• 对新品、长尾、缺货、异常活动、高价值实体分别切片。

Leakage 类型与治理

回测报告最低结构

产品决策与运营闭环

Forecast-to-decision loop 的成熟度决定预测系统是否真正进入组织肌肉。

闭环步骤

1. Define decision：明确预测影响的动作和成本函数。
2. Generate forecast：输出点预测、分位数、prediction intervals 与情景版本。
3. Optimize decision：将预测输入补货、现金调拨、排班、容量扩容或预算分配模型。
4. Human review：业务负责人按规则覆盖，并记录原因与影响。
5. Execute：进入 ERP、WMS、资金系统、排班系统、客服平台或云资源编排。
6. Observe actuals：收集实际销量、现金流、contact volume、SLA、库存、资金占用。
7. Evaluate decision：同时评估 forecast accuracy 与 business impact。
8. Learn：把覆盖理由、异常事件和决策结果反馈到数据产品、特征和治理规则。

产品界面应展示什么

预测界面不应只是折线图。高级界面应包含：

人工覆盖不是失败

在金融零售落地中，人工覆盖是治理设计的一部分。关键不是禁止覆盖，而是让覆盖可学习：

• 覆盖理由结构化，例如“已知大客户流失”“门店装修”“监管窗口”“促销临时加码”。
• 覆盖影响量化，例如对补货金额、现金缓冲、SLA 或容量成本的影响。
• 覆盖后评估，例如覆盖是否比模型更接近实际，长期是否存在系统性偏差。
• 覆盖权限分层，例如高金额现金调拨、高风险库存决策需要双人审批。

风险治理与审计

Forecast governance 要把 NIST AI RMF 的治理语言落到可执行控件上。

模型卡要覆盖的高级问题

关键控制点

1. Use-case tiering：现金流、授信、监管报送、客户服务水平等高影响用例必须进入增强审查。
2. Data lineage：每次预测都能追溯数据快照、特征版本、模型版本和运行参数。
3. Leakage scan：每次训练前检查未来特征、修正数据和聚合窗口。
4. Interval calibration：预测区间失准时触发重新校准或限制使用。
5. Human override review：高频覆盖、高金额覆盖、方向性偏差覆盖进入治理会议。
6. Model fallback：高级模型失败时切回 baseline 或上一稳定版本。
7. Decision audit：审计关注的不只是预测值，也包括预测如何改变业务动作。

金融零售、零售、电商、客服与容量规划场景

场景 1：Financial Liquidity / Cashflow Forecasting

目标：预测资金流入、流出、账户余额、现金需求和流动性压力，用于 treasury、门店现金、ATM 补钞、支付清算和监管缓冲。

架构要点：

产品洞察：现金流预测的低估成本通常高于高估成本，因此目标不是最小化平均误差，而是控制低分位风险和 liquidity buffer 的资本效率。

场景 2：Retail Demand Forecasting

目标：预测门店、渠道、品类、SKU 的需求，用于补货、采购、调拨、促销和库存健康。

架构要点：

产品洞察：零售需求预测要同时预测“需求”和“可观测销售”。缺货时销售数据被库存上限截断，直接训练会把缺货误学成低需求。

场景 3：E-commerce Demand Planning

目标：预测流量、订单、转化、退款、履约压力和营销活动效果，用于预算、仓配和前台体验保障。

架构要点：

产品洞察：电商活动期的预测误差通常来自“计划版本变化”，不是模型本身。产品架构必须保存每次活动计划版本，才能解释预测偏差。

场景 4：Queue / Contact Volume Forecasting

目标：预测客服 contact volume、渠道分布、技能组量和到达模式，用于排班、外包、机器人分流和 SLA 管理。

架构要点：

产品洞察：客服预测不是只预测一天总量。真正影响 SLA 的是 15 分钟或 30 分钟 interval 到达量、技能组匹配和平均处理时长。

场景 5：Capacity Forecasting

目标：预测系统、仓配、支付通道、人力、机器人、风控队列和云资源的容量压力。

架构要点：

产品洞察：capacity forecasting 的失败通常不是预测均值错，而是峰值区间低估。P90/P95 预测和 stress scenario 比 P50 更接近运营价值。

模板

模板 1：Forecast Product One-Pager

模板 2：Feature Availability Matrix

模板 3：Model Selection Decision Record

模板 4：Backtesting and Leakage Review

模板 5：Forecast Governance Review

30 天高级训练计划

第 1 周：Forecast-to-Decision 基础架构

第 2 周：模型组合与概率预测

第 3 周：层级、回测与治理

第 4 周：金融零售落地案例

面试答案

1. 如何设计一个 time-series forecasting product architecture？

30 秒回答：我会从业务动作倒推，而不是从模型倒推。先定义预测影响的库存、资金、排班或容量决策，再定义 Forecast Contract、数据产品、特征可用性、模型组合、概率输出、人工覆盖、回测和治理闭环。

2 分钟回答：一个成熟的 forecasting 产品架构包含九层：Decision Context、Forecast Contract、Data Product、Feature Layer、Model Portfolio、Probabilistic Forecast Service、Decision Engine、Workflow Layer、Monitoring and Governance。模型层可以包含 baseline、Prophet、DeepAR、TFT、TimesFM 或 NeuralForecast 组合，但模型只是中间层。真正的产品价值来自 forecast-to-decision loop，例如预测进入补货、现金调拨、客服排班或容量扩容，并通过实际结果反哺回测和治理。

追问处理：如果面试官问“如何证明价值”，我会同时看 forecast accuracy 和 decision impact，例如缺货率、库存周转、SLA、资金缓冲成本、资源利用率，而不是只看 MAPE。

2. DeepAR、TFT、TimesFM 怎么选？

30 秒回答：DeepAR 适合大量相关序列的概率预测；TFT 适合多变量、多步预测和未来已知协变量丰富的业务；TimesFM/foundation models 适合快速 benchmark、冷启动和少样本场景，但必须经过本地回测和治理校准。

2 分钟回答：如果我有很多门店 SKU、客服队列或现金流类别序列，并希望输出分布，我会优先评估 DeepAR。如果业务有丰富的静态特征、历史特征和未来已知特征，例如促销日历、价格计划、节假日、账单日，我会评估 TFT，因为它对 multi-horizon forecasting 和解释更友好。TimesFM 这类 foundation model 可以降低启动成本，尤其适合新市场或长尾序列，但它不是免训练、免审计的替代品。最终选择要基于 rolling-origin backtesting、prediction interval calibration、业务切片和上线治理成本。

追问处理：如果面试官问“是否一定用深度模型”，我的回答是不会。所有复杂模型都要先打赢 seasonal naive 或当前业务规则，否则没有上线理由。

3. 为什么 demand planning 需要 probabilistic forecasting？

30 秒回答：因为计划决策面对的是不确定性和非对称成本。低估需求会缺货或 SLA 失败，高估需求会库存积压或资源浪费，所以 P50 只是一个口径，P90/P95 才能支持服务水平和风险缓冲。

2 分钟回答：在 demand planning 中，点预测会把风险隐藏起来。零售补货要决定安全库存，客服排班要决定峰值人力，资金预测要决定 liquidity buffer，容量规划要决定扩容阈值。每个决策都对应不同风险偏好。因此我会输出 P10/P50/P90、prediction intervals 和 scenario forecasts，并用 coverage、pinball loss、calibration 和业务成本模拟来评估，而不是只报告平均误差。

追问处理：如果面试官问“业务不懂概率怎么办”，我会用决策语言翻译：P90 不是“更准确预测”，而是“为了 90% 服务水平需要准备多少资源”。

4. 如何治理 leakage？

30 秒回答：核心原则是模拟真实预测时点。训练、验证和特征生成都必须按 as-of timestamp 重建，未来才知道的数据不能进入预测时点。

2 分钟回答：我会从六类 leakage 入手：target leakage、future feature leakage、aggregation leakage、reconciliation leakage、human override leakage 和 data correction leakage。治理方式包括事件时间与入仓时间分离、特征可用性矩阵、冻结活动日历版本、rolling-origin backtesting、数据修正版本保留、人工覆盖锁定时间，以及上线前 leakage scan。尤其在金融零售中，实际到账、实际促销效果、实际缺勤、实际天气等数据很容易在历史训练集中被误用。

追问处理：如果面试官问“怎么发现 leakage”，我会看异常高的回测表现、活动期表现不合理、线上线下误差断裂、特征重要性异常，以及未来可用性审计失败。

5. 如何设计 financial liquidity/cashflow forecasting？

30 秒回答：我会按 currency、legal entity、bank account、cashflow type 和日期建模，输出 P10/P50/P90 资金流和余额，用于资金调拨、融资安排、现金配送和监管缓冲。

2 分钟回答：现金流预测的关键不是销量式准确率，而是低估风险控制和资本效率平衡。架构上需要整合账户余额、支付清算、贷款发放、还款、提现、工资日、账单日、节假日、监管窗口和宏观变量。模型上可以从 seasonal baseline 和 gradient boosting 开始，再评估 DeepAR、TFT 或 TimesFM benchmark。输出必须是概率区间和 stress scenario，进入 treasury workflow，并保留审批、覆盖和审计记录。

追问处理：如果面试官问“如何处理监管风险”，我会将该用例列为高影响 AI 用例，要求模型卡、数据血缘、人工审批、回滚机制和周期性治理审查。

6. Hierarchical forecasting 的价值是什么？

30 秒回答：它解决组织计划的一致性问题，让门店、区域、品类、渠道和集团级预测能够对齐，减少“各层数字都对但合起来不对”的管理摩擦。

2 分钟回答：零售和金融零售天然有层级结构。比如 SKU-store-day 是执行层，category-region-week 是采购和预算层，company-month 是管理层。可以采用 bottom-up、top-down 或 reconciliation。高级架构不会只保留最终数字，而会保留各层原始预测、调整后预测、调整方法和影响量。这样供应链、财务和运营可以围绕同一套数字协同。

追问处理：如果面试官问“何时不用最底层预测”，我会说当底层序列太稀疏、噪声太高或执行动作不在底层时，直接 bottom-up 可能放大误差。

7. Queue/contact volume forecasting 和普通销量预测有什么不同？

30 秒回答：客服预测更关注 interval-level 到达量、渠道和技能组组合，以及它们对 SLA、等待时间和排班的影响，而不是只预测一天总量。

2 分钟回答：queue/contact volume forecasting 需要按 market、channel、skill group、interval 建模，并把 contact volume 和 AHT 分开预测。特征包括账单日、还款日、系统变更、产品上线、政策调整、营销活动和节假日。输出应进入 workforce management，用 P50 做常规排班，用 P90 管理峰值和外包容量。评估指标除了 WAPE，还要看 SLA、平均等待时间、放弃率、occupancy 和 overstaffing cost。

追问处理：如果面试官问“机器人会不会改变预测”，我会将 bot containment、bot fallback、话题结构变化作为特征和反馈信号，而不是把机器人当成外部黑箱。

8. Forecast governance 如何落地？

30 秒回答：我会用 NIST AI RMF 的 Govern、Map、Measure、Manage 做治理骨架，把预测用例登记、风险分级、数据血缘、backtesting、leakage scan、人工覆盖和模型降级变成可执行控件。

2 分钟回答：forecast governance 的重点是控制预测如何影响业务动作。Govern 定义 owner、审批和模型卡；Map 明确业务影响和失败模式；Measure 做 backtesting、drift、coverage 和 leakage scan；Manage 定义上线闸门、灰度、回滚、覆盖审查和事件复盘。金融零售场景中，高影响预测如现金流、客户服务水平、授信和监管相关用例必须比普通运营预测接受更强审查。

追问处理：如果面试官问“治理会不会拖慢创新”，我会回答：治理不是把模型挡在门外，而是让模型可以进入高价值决策。没有审计和降级能力的模型，只能停留在分析看板。