企业能用数据预测未来吗
能，但可预测性因事而异，差别极大。预测分析在有稳定重复规律的场景上（销量、用电负荷、设备故障）已经成熟；在参与者会根据预测调整行为的场景上（股价、竞标）效果有限；在没有历史先例的罕见事件上基本无效。判断一个预测项目值不值得做，看的是数据条件与场景类型，不是模型有多先进。
预测分析：先看这件事属于哪一类
「能不能预测」这个问题问得太粗。同样叫预测，预测下个月的门店销量和预测下个月的股价，难度不在一个量级上，原因也不是”因素多少”那么简单。
| 场景类型 | 典型例子 | 可预测性 | 决定因素 |
|---|---|---|---|
| 有稳定周期与趋势的重复现象 | 月度销量、用电负荷、话务量、季节性需求 | 较高 | 历史模式会重复出现，且外部干预有限 |
| 由少数可观测因素驱动 | 促销带来的销量波动、温度对能耗的影响 | 较高 | 驱动因素能被记录成数据，因果关系相对清楚 |
| 由物理规律主导的退化过程 | 设备故障预警、部件寿命、质量漂移 | 中等 | 规律稳定，但需要足够多的故障样本才学得到 |
| 依赖大量人的独立选择 | 客户流失、投诉升级、逾期风险 | 中等 | 个体不可预测，但群体层面有统计规律 |
| 参与者会根据预测调整行为 | 股价、竞标报价、对手定价 | 低 | 预测一旦被使用就会改变被预测的对象本身 |
| 罕见且缺乏先例 | 突发政策变化、极端事件、全新产品首年销量 | 很低 | 没有可供学习的历史样本，本质上不是建模问题 |
「因素太多所以难预测」是常见的解释，但不是根本原因。真正的难点在于:当预测被参与者使用时，它会改变被预测的对象本身。所有人都预测某只股票会涨，买入行为立刻让价格变化，原来的预测随之失效。
竞标报价、对手定价、市场博弈都属于这一类。这类场景不是”数据再多一点就能做好”，而是结构性地不适合用历史模式外推。企业里如果有人提出这类需求，值得先把这层说清楚，而不是接下来试试看。
预测分析：立项前必须确认的四件事
确定场景属于可做的那几类之后，接着看数据条件。下面四条建议在立项前逐项确认，任何一条不满足，工期与效果的估计都要重新算。
- 历史有多长，什么粒度。有明显季节性的业务，通常需要两到三年的完整历史，模型才学得到周期规律。粒度也要先定下来：按月还是按周，按大类还是按单品，按全国还是分区域。粒度越细，每一格里的数据越稀疏，结果越不稳定。多数情况下「按月、按产品大类、按大区」是能出结果的起点，先粗后细比一步到位更容易成功。
- 这几年口径变过没有。这是最常见的拦路虎，也最容易被忽略。产品线重组过、渠道调整过、大区划分改过、统计口径换过 – 只要发生过，历史数据就不可比，直接拿来训练等于让模型学一堆噪声。处理这个问题属于数据工程，不是建模，但它往往占掉整个项目一半以上的工作量。
- 除了目标值，还留了什么。价格、促销活动、渠道库存、大客户订单节奏，这些有没有按时间记录下来。如果只有一列历史销量，模型能学的就只有「过去像什么样」，遇到促销或调价就会失准，而且失准了也解释不清原因。
- 预测出来做什么用。这一条决定前面三条要做到多严。用来备货，关心的是不缺货不压货，预测偏高和偏低的代价并不对称；用来定销售指标，更要紧的是口径服众、算法能讲明白，否则一线不认；用来做预算，月度大盘的准确度就够，不需要细到单品。用途不明确的预测项目，交付时没有验收标准，几乎必然扯皮。
预测分析：项目失败的六个真实原因
下面六条按实际出现频率排列。共同点是:没有一条跟”算法不够先进”有关。
一、口径中途变过，但没人记得
模型在训练集上表现很好，上线后系统性偏离。回头查才发现某年的产品分类做过调整，前后两段数据本来就不可比。这类问题在数据准备阶段花半天核对就能发现，等到上线后再查，前面的工作基本要重做。
二、用了当时根本拿不到的字段
这是技术性最强、也最隐蔽的一个坑，业内称为数据泄漏。举个具体的例子：预测客户是否会流失，特征里放了「最后一次投诉时间」，但在真实预测的那个时点，这次投诉还没发生。模型因此在测试集上准确率高得反常，上线后一塌糊涂。
判断方法很简单：把每个特征拿出来问一句「做预测的那一刻，这个值取得到吗」。取不到的一律去掉。准确率高得不像话的时候，第一反应应该是查泄漏，而不是庆祝。
三、只看平均误差，不看代价不对称
备货场景里，预测少了会缺货丢单，预测多了会压库存占资金，两者的代价通常差好几倍。只用平均误差评估的模型，会在两个方向上均匀地犯错，结果是”看起来准，用起来亏”。评估指标要跟业务代价对齐，这件事在建模之前就该定。
四、粒度定得过细
业务方希望预测到单品单店单日，听起来更有用。但那一格里可能只有个位数的历史记录，噪声远大于信号。粗粒度上准确的预测比细粒度上不可靠的预测有用得多，而且可以先出结果建立信任，再逐步细化。
五、预测结果无法转化为动作
预测出下季度某区域销量会下滑，但采购、排产、人员都无法在那个时间尺度上调整，这个预测就没有用武之地。做预测之前先问：拿到这个数，谁会因此做什么决定。答不上来的话，项目多半会停在”报表做出来了但没人看”。
六、没有和朴素基线比过
最容易被跳过、也最能说明问题的一步。所谓朴素基线，就是最简单的猜法：用上个月的值当这个月的预测，或者用去年同期的值。很多花了几个月做出来的模型，最终并没有跑赢这两条简单规则。
先算基线，再做模型，用基线作为验收的最低门槛。这一步花不了一个小时，却能避免整个项目做完才发现不如不做。
怎么判断一个预测项目值不值得做
把上面的内容收成一个可以在会上直接用的顺序，四步走完基本就能给出结论。
- 第一步:定位场景类型。对照上面那张表，看它落在哪一行。落在最后两行的，先把可预测性的问题讲清楚，不要直接进入方案讨论。
- 第二步:核对四个前提。历史长度、口径变更、可用字段、最终用途。任何一条答不上来，先去查清楚再谈工期。
- 第三步:算朴素基线。用上月值和去年同期算一遍误差，这就是模型必须跑赢的线。跑不赢就没有做的必要。
- 第四步:确认结论可操作。问清楚拿到预测之后谁做什么决定、在什么时间点做。没有人因此改变行为的预测，做出来也只是一张报表。
预测项目里，数据准备通常占据最大比重:取数、口径对齐、缺失与异常处理、特征构造。建模本身往往是最短的一段，也是最容易被高估重要性的一段。
这也解释了一个常见现象:换更强的模型带来的改善，经常小于把数据口径理顺带来的改善。前者是几天的调参，后者是几周的梳理，但后者的收益更实在。
iModel 在这条链路上做什么
iModel 数据科学平台基于 KNIME 开源内核二次开发，增强部分为自主研发、源码可审查。在预测这类项目里，它承担的是数据接入与准备、特征构造、建模流程编排与结果复现这几段。
可视化工作流在这里的实际价值有两点。一是数据准备可查：每一步的中间结果都能单独查看，口径对不上时能定位到具体环节，而不是在一整段脚本里翻找。二是结论可解释：预测结果拿去开会、被销售和财务质疑时，能顺着流程图讲清楚这个数用了哪段历史、口径怎么对齐、参数是多少。销售预测最后是要被人质疑的，讲得清楚往往比多准两个点更重要。
建模环节可用内置的回归、时间序列与机器学习节点，也可以直接嵌入已有的 Python 或 R 脚本，不必为了建模换一套工具。相关能力见 统计分析和机器学习。
常见问题
先把数据这一层理顺
预测项目的成败大多在数据准备阶段就决定了。可以先用你手上的真实数据跑一遍口径核对和朴素基线，一两天就能判断这个项目该不该立。
