Chronos-2在电力现货日前价格预测中的实战应用

最近在做区域电力现货市场的日前价格预测时，我遇到了一个很常见又很头疼的需求：每天要在市场申报截止前，给出未来 24 小时、96 个时点的出清价格预测。以前遇到这类问题，我会默认选择 LSTM 时序预测，先做一堆特征，再从头训练一个模型。但这次我换成了 Chronos-2 这套预训练时间序列模型，整个建模思路几乎被重写了一遍。这篇文章就把这次实战的完整过程记下来，包括数据怎么清洗、特征怎么构造、模型怎么微调，以及在最后落地时踩到的一堆坑。

如果你也在做电量负荷、现货电价、新能源出力这类高频波动的时间序列预测，并且正在纠结“到底是用 LSTM 自己训，还是上预训练模型”，那这篇文章应该能帮你省下不少试错时间。我会按真实项目推进的顺序来讲，尽量把每一步的“为什么这样做”也讲清楚。

1. 为什么拿电价来验证 Chronos-2：三个反直觉的特点

1.1 电力现货价格的形成机制与预测用途

电力市场和其他大宗商品市场最大的区别在于，电不能大规模储存，供需必须实时平衡。电价并不是由某个机构主观制定的，而是市场出清的结果：发电侧报出各自可接受的卖出价，用电侧报出买入需求，交易系统把供需曲线一交叉，边际出清价就出来了。

所以电价序列的背后，是机组启停、燃料成本、碳价、可再生能源出力、通道阻塞、天气负荷等多种因素共同作用的结果。预测电价不只是为了预测一个数字，而是为了服务三类具体业务：

• 发电企业可以用预测结果决定次日申报策略，减少报价偏差；
• 售电公司和用电企业可以用预测结果安排购电节奏，规避尖峰时段买入；
• 储能运营商需要用预测结果决定充放电策略，在低价时段充电、高价时段放电。

我这次的项目属于第二类，目标是帮售电团队做一个日前价格预测工具，精度直接影响的是交易策略方案。

1.2 电价序列的三个反直觉特点

很多人刚接触电价预测时，会下意识觉得“这不就是个普通的时间序列吗，用 ARIMA 或者 LSTM 不就行了”。但实际跑起来之后会发现，电价序列和常见的社会消费品销量、网站访问量完全不是一回事，它有三个很反直觉的特点。

第一个特点是尖峰高频出现。电价在大多数时候维持在一个相对平稳的区间，但只要出现供需紧张，价格会在几个时点内飙到正常价格的 10 倍甚至几十倍。这种尖峰出现的概率不高，但它对模型的影响非常大，尤其是用均方误差类损失函数训练时，模型会为了迁就尖峰而牺牲大部分普通时点的精度，最后预测曲线变得非常“平”，峰谷全被削掉了。

第二个特点是多重季节性叠加。电价有非常明显的日内双峰规律，一般早高峰和晚高峰各出现一次；有明确的“工作日/周末”差异，因为工业负荷集中在这几天；还有春夏秋冬的年度季节规律，冬季供暖和夏季制冷都会推高负荷。更麻烦的是，节假日会打破“工作日”和“周末”的周期，导致本来很稳定的周周期被打断。

第三个特点是非平稳且事件驱动。电网检修、极端天气、突发机组跳闸、来水丰枯变化，都会让价格结构在短时间内发生改变。这种改变往往不是缓慢的漂移，而是断崖式切换，用过去几个月的统计规律去外推未来，往往会失准。

1.3 为什么“直接取前一天价格”往往能赢过新手模型

很多人不知道，电价预测领域一个很强的基线其实就是“直接复用前一天同时刻的价格”。原因很简单，电价的主要驱动因素，比如工作日节奏、气温大体趋势、工业企业开工情况，在相邻两天之间有很强的延续性。

我之前见过一个新上手的朋友，花了大量时间构造特征，跑了一个复杂的 LSTM 模型，结果在测试集上的误差还不如直接复制前一天的曲线。这不是他模型写得不对，而是说明该场景下历史值本身携带了极高信息量。你做任何复杂模型之前，必须先把这个基线跑通。如果模型连这个基线都打不过，问题大概率出在数据准备或评估流程上，而不是模型结构上。我这次的所有实验，也都拿“前一天直接复用”当最底线来比。

2. Chronos-2 的建模逻辑，以及它和 LSTM 的差别

2.1 LSTM 在多步价格预测中的局限性

在换到 Chronos-2 之前，我一直在用 LSTM 做多步预测。最常用的框架是 seq2seq：把过去 72 小时的电价序列输入编码器，解码器逐步输出未来 24 小时的价格。训练过程不复杂，PyTorch 里手写一个两层 LSTM 加注意力机制就能跑。

但做了几个项目之后，我发现 LSTM 有三个绕不开的短板：

• 每个场景都要从零开始训练，准备数据和调参的时间比模型本身还长；
• 对尖峰这类低频但关键的模式，LSTM 很难学透，因为训练集里这种样本太少；
• LSTM 默认给出的是点预测，想要输出预测区间只能额外加 Monte Carlo Dropout 或分位数回归，工程复杂度直接翻倍。

这些短板在电价数据上尤其明显。电价尖峰一天出现不了几次，一年下来有效样本量也就几百个，靠从零开始训练一个十多万参数的模型去识别这种稀疏模式，确实有点强人所难。

2.2 Chronos-2 的核心：把连续价格序列变成 token 序列

Chronos-2 采用的思路和我们熟悉的 NLP 预训练模型很像。先设计一个分桶机制，把连续的数值序列映射成一组离散的 token，再把这些 token 输入一个类似 T5 结构的 Transformer 编码器-解码器，在海量时间序列语料上做预训练。预测时，模型输出的不是直接回归出的数值，而是下一个时点 token 的概率分布。

这个“把连续值离散化成 token”的操作，是 Chronos 系列最核心的设计。它把原本的回归问题变成了分类问题，模型学的是一个值落在哪个桶里的概率。这样做最大的好处是，模型可以表达多模态分布：比如某个时点价格要么是平稳低位、要么是尖峰高位，中间值概率很低，这在连续回归框架下很难表达，但在分桶分类框架下就能自然体现。

你可能要问：分桶会导致精度损失吗？确实会，但通过合理的桶宽设置，完全可以把精度控制在可接受范围内。更重要的是，分类目标天然对尖峰更友好，模型不用在“追求均方误差最小化”的压力下把尖峰都抹平。

2.3 微调阶段为什么是电价预测的重头戏

Chronos-2 这类模型的预训练语料主要来自公开的通用时间序列数据集，它们虽然覆盖面广，但并不会有电力市场特有的结算规则、短期供需博弈和峰谷价差结构。因此，直接使用零样本预测可以拿到一个不错的起点，但要达到业务可用级别，必须在目标市场数据上做微调。

微调的过程很轻量，不是重新预训练，而是在断电数据上继续训练，只需要很少的轮次。实际操作中，我只用了一个月的训练数据就看到了明显效果提升。这背后是迁移学习的核心逻辑：模型在通用语料里已经学会了时间序列的基本形态，比如季节、趋势、突变、周期，微调阶段只需要让它理解电力市场价格的具体分布规律即可。

这也是我建议团队里做预测的同学认真研究 Chronos-2 的原因：它把以往“每个场景一个独立模型”的重开发模式，变成了“通用基础模型加极少量场景数据适配”的轻量模式。场景越多的团队，这种模式带来的成本下降越明显。

2.4 我建立的技术方案总览

这次项目的整体技术路线分成三段：先做数据清洗和特征构造；然后用 Chronos-2 预训练权重做零样本预测，建立初版基线；最后在电价数据上微调，接入外部特征，输出未来 96 个时点的分位数预测。整个流程用 Python 编排，中间环节全部脚本化，方便每天定时执行。

从架构上看，它没有把外部特征强行塞进模型内部，而是把外部特征作为在时间维度上对齐的辅助输入，与目标序列一起处理。下面会专门展开讲这一点。

3. 电价数据清洗与特征构造细节

3.1 公开数据长什么样

我这次用的是某区域现货市场的公开交易数据，数据字段并不复杂：时间、区域、实际负荷、新能源出力预测、市场出清价格。粒度是 1 小时一个点，一天 24 个点，但部分场景也会拆成 15 分钟一个点，一天 96 个时点。这次预测需求是 96 个时点，所以实际用的是 15 分钟粒度数据。

原始数据表长得大概是这样：

数据拿到手之后不能直接喂模型，必须先做三件事：统一时区、补全缺失时间点、剔除明显异常值。

统一时区很容易被忽略。如果数据源给的是 UTC 时间，而你的业务希望以北京时间预测，那必须先把时间转换到位，否则滞后特征会整体错位。缺失时间点的问题，我也会在第 5 章专门讲，这里先提一句：不要直接把缺失行删掉，那样会让后续对齐全部错乱。

3.2 时间特征与滞后特征怎么构造

在特征工程上，我最终采用的方案分三层。

第一层是时间日历特征。包括小时、星期几、是否周末、是否法定节假日。节假日这一点非常重要，因为节假日会改变负荷结构，从而直接影响电价。我用的节假日表是从官方发布的放假安排生成的，并且把“调休上班日”也额外做了一个标志位，因为调休日在负荷行为上和普通工作日非常接近。

第二层是滞后价格特征。这是整个特征里信息量最大的一块。我会构造出“前一天同时刻价格”“前一周同时刻价格”“过去 24 小时价格均值”“过去 168 小时价格均值”“过去 24 小时价格最大值”等多个特征。它们能捕捉到价格在短期和中周期上的自相关性。

第三层是负荷与新能源特征。包括当前时点的实际负荷、新能源出力预测，以及它们的滞后值。电力市场的供需关系是决定价格的底层逻辑，负荷越高、新能源越少，价格越容易上涨；反过来，如果光伏出力在午间大幅上升，价格往往会出现低点甚至负价。

特征构造完，下一步是把它们和价格序列放在同一时间轴上，确保每个时点都有完整的一组向量。

3.3 外部特征如何接入 Chronos-2

Chronos-2 本身主要接受目标序列，也就是价格序列的上下文。为了把外部特征用上，我在实现时采用了一个比较实用的做法：在每个时点上，将外部特征经过一层线性投影，加到对应位置的 token embedding 上。

这个思路类似 Transformer 中把 position embedding 加到 input embedding 上的操作，模型在编码时就能同时看到价格信息和相关的外部特征。这样做的好处是模型结构改动小，微调时新增参数量很少，不容易过拟合。

你可能遇到的情况会是：外部特征字段很多，但并不是所有特征都能带来收益。我建议不要一股脑全塞进去，先做一轮相关性分析，选出最重要的 3 到 5 个特征接入即可。特征过多会让模型在微调阶段陷入噪声拟合，泛化能力反而下降。

3.4 训练集、验证集和测试集的划分

时序预测和普通机器学习任务最大的区别是：不能随机打乱数据。我采取的划分方式是严格按照时间顺序：

• 训练集：前 720 天数据；
• 验证集：紧接着的 90 天数据；
• 测试集：最后 30 天数据。

这样划分是为了模拟真实场景：你永远是在用过去的数据预测未来，不可能看到未来样本。如果像普通分类任务那样把数据全部打乱再切分，模型会“偷看”未来信息，测试集上的误差会非常好看，但一到线上就立刻现出原形。

另一个容易踩的坑是归一化统计量的计算范围。我在第一次实验时犯了错，用了整个数据集去计算均值和方差，结果验证集和测试集上的误差明显偏低，但上线后立刻恶化。正确的做法是：所有统计量只在训练集窗口内计算，然后套用到验证集和测试集上。

4. 训练评估与实验结果

4.1 零样本预测和微调预测的流程

我用 Chronos-2 做预测时，流程分成两个阶段。

第一阶段是零样本预测。把最近一个时间窗口的价格序列作为上下文，直接调用预测接口，输出多个未来时点的采样结果。这里的“零样本”指的是模型没有在本市场数据上额外训练，完全依靠预训练得到的通用能力。

第二阶段是微调预测。拿过去三个月的电价数据做训练集，对预训练权重继续做几轮训练，然后再跑同样的预测流程。微调之后，模型对本地市场的价格分布形态、峰谷价差幅度会有更准确的认知。

贴一下核心推理部分的伪代码：

python复制# 根据你安装的 Chronos-2 版本选择具体接口
from chronos import ChronosPipeline

pipeline = ChronosPipeline.from_pretrained(
    "amazon/chronos-2-large",
    device="cuda"
)

# context 是过去336个时点的价格序列，形状为 [1, 336]
predictions = pipeline.predict(
    context=context_tensor,
    prediction_length=96,
    num_samples=5,
    temperature=0.2
)

# 多次采样后取中位数，作为最终点预测
forecast = predictions.median(dim=0).values

这里的逻辑有几个关键点：上下文长度选了 336，正好是最近两周的时点数；预测长度是 96，对应未来 24 小时；多次采样取中位数，是为了把随机性带来的抖动降到最低。

4.2 评估指标怎么定才不算“骗自己”

电价预测的评估指标，不能只盯着一个 MAPE 看。我同时跟踪三个指标：MAE、MAPE、峰值时段平均绝对误差。

MAE 好理解，就是真实值与预测值之间绝对误差的平均值。MAPE 是百分比误差，但它在价格接近 0 的时点会剧烈放大，比如真实值是 2 元/MWh，预测值是 5 元/MWh，误差就是 150%，这显然不能代表模型真实水平。所以我在计算 MAPE 时加了一个下限保护：当真实价格低于 20 元/MWh 时，按 20 元来算，这个叫 clipped MAPE。

峰值时段平均绝对误差是我特别关心的一个指标。我把每天价格最高的两个时点挑出来，单独计算误差。这个指标能直接反映模型是否真的抓住了供需最紧张的拐点。从业务角度看，峰值时段的预测准确率比普通时段更重要，因为交易风险大多集中在这些时点。

4.3 我和 LSTM 基线的对比数字

下面这组数字来自我这次项目的测试集，对比对象包括：前一天价格直接复用、LSTM seq2seq 模型、Chronos-2 零样本、Chronos-2 微调。所有结果都在同一测试集上计算，时间段也一致。

从结果可以清楚看到：Chronos-2 零样本就已经超过了 LSTM 从头训练的效果，而微调之后差距进一步拉大。尤其是峰值时段的误差，微调后比 LSTM 下降了接近 40%，这个提升对交易策略的意义非常直接。

我也要提醒一句：这里的数字只是我这个市场的结论，换一个市场、换一段季节，结果可能完全不同。但趋势是有共性的：预训练模型加少量微调，在数据样本有限的高波动时间序列预测上，确实比从零训练有优势。

4.4 参数清单与资源占用

微调阶段我使用的参数如下：

• 预训练模型：Chronos-2 large 版本；
• 上下文长度：336 个时点；
• 预测长度：96 个时点；
• 微调轮次：10；
• 学习率：5e-5；
• batch size：32；
• 优化器：AdamW；
• 硬件：单张 NVIDIA A10。

如果资源有限，用更小的 Chronos-2 版本也能跑，但微调速度和效果会有一些差距。模型主干参数量比较大的时候，梯度更新需要显存也更多，建议在实验初期先用小版本验证流程，再切到大版本跑正式结果。

5. 实战中的坑：排查链路与解决方法

5.1 第一个坑：归一化里的时间泄漏

我第一次跑实验时，特征工程的代码里有一行做归一化的逻辑：我先在整个数据集上计算 price_min 和 price_max，然后用它们做 min-max 缩放，再切分训练集和测试集。表面上看代码语法没问题，但结果在验证集上特别漂亮，到了线上就崩。

排查过程花了我一个下午。我先把验证集上的误差按天拆开，发现误差并没有随时间推进而变大，而是始终很小，这很不正常。真正的问题出在统计量上：归一化用的是全量数据的 min 和 max，也就是说测试集的信息已经进了训练阶段。测试集里有哪些尖峰价格，模型在归一化时已经“知道”了，训练时模型被无形中校准过，线上自然就露馅。

解决方法是把归一化统计量限定在训练集上，验证集和测试集直接用训练集算出的 min 和 max 做转换。这个坑很隐蔽，因为你只检查代码，不检查数据流向，根本发现不了。

5.2 第二个坑：节假日标志带来的伪规律

我的第一个版本只用了“是否周末”作为日历特征，结果节假日那几天的预测误差特别大。后来加了“是否节假日”标志，误差有所下降，但又出现了一个新问题：模型学到的“节假日价格一定低”的规律，在部分长假前后并不成立。

排查后发现，节假日效应不是千篇一律的降低价格，而是“负荷结构变化”带来的价格形态改变。比如长假期间工业负荷下降，价格会整体走低；但节前最后一天，很多工厂赶工，价格反而会冲高。单纯用一个节假日标志位，模型无法区分节前、节中、节后。

解决思路是把特征细化成“节前第几天”“节中第几天”“节后第几天”，并在节假日表上手工标注这些位置。这样模型才能学习到不同的节假日阶段模式。这个经验确实来自实际数据排错，如果你在做类似预测，建议直接采用这种细粒度节假日特征。

5.3 第三个坑：缺失时点和时间轴错位

电力现货市场偶尔会出现某些时点没有出清价格的情况，比如极端天气下系统暂停交易，或者结算数据延迟发布。如果直接按时间序列的物理排列读进来，缺失时点会让后续所有滞后特征错位。

我一开始图省事，把缺失行删掉，结果训练出来的模型在测试集上误差忽大忽小。排查时我发现，某个时刻的前一天同时刻特征，实际取到的是前天之前的价格，所有滞后窗口都偏移了。

正确的做法是：先建立完整的 15 分钟时间轴，从业务开始时间一直排到当前时间，然后把价格表左连接到这个完整时间轴上，缺失值用前一个非空值填充。做完这个处理之后，所有滞后特征才真正对齐到正确的语义时点。

5.4 第四个坑：峰值预测总慢一步

无论用 LSTM 还是 Chronos-2，早期版本都出现了一个现象：预测曲线比真实曲线晚一个时点才进入尖峰状态。比如真实价格在 18:00 冲到高位，模型预测的尖峰却出现在 18:15 甚至 18:30。这个滞后在 MAE 上看不算离谱，但在峰值时段看误差非常大。

我一开始尝试增加上下文长度，从 168 拉到 336，效果有一定改善但没解决根本问题。后来我把问题定位到损失函数上：模型在训练时只优化绝对误差，它发现把预测值“抹平”一点，整体误差反而更小，于是尖峰就被主动削弱了。

解决方法是给损失函数加一阶差分惩罚项，让模型在相邻时点的变化率上也对齐真实趋势。修改之后，预测曲线的拐点位置明显更准。这也是我在这个项目里觉得最值得分享的一个技巧：不要只盯数值误差，时序趋势的误差同样重要。

5.5 第五个坑：天气特征越多，效果越差

接手项目时，团队希望把尽可能多的气象数据都塞进模型，比如温度、湿度、风速、风向、云量、降水概率、能见度、气压。我照着加了一轮，结果各项指标不升反降。

排查下来发现有两个原因：一是很多天气变量之间存在高度相关性，比如湿度和降水概率，同时输入会造成冗余；二是天气数据的质量参差不齐，部分变量在凌晨时段几乎全是填充值，模型学到的是填充规则而不是真实气象规律。

后来我把天气特征压缩成三个：温度、风速、云量，再加上新能源出力的预测值。模型效果立刻恢复并超过了之前的最好结果。数据质量永远优先于特征数量，这是我在多个时间序列项目里反复验证过的原则。

6. 从实验到生产：每日预测任务的落地要点

6.1 全流程自动化脚本怎么搭

模型在实验环境里跑通只是第一步，真正有价值的是把它变成一个每天自动运行的预测任务。我搭的流程大致是这样：

• 每天 15:00 自动拉取最新市场数据；
• 15:05 开始运行特征构造脚本，生成模型需要的输入；
• 15:15 加载预训练权重和微调权重，执行推理；
• 15:20 输出未来 96 个时点的预测结果，写入数据库；
• 15:25 把预测曲线和前一天预测误差推送给交易团队。

整个流程没有人工介入，失败时有告警通知。这个调度脚本我建议用最简单的方式实现，比如 crontab 或定时任务平台，不要一上来就上复杂的调度框架。预测任务的特点是逻辑清晰、依赖少，越简单越可靠。

6.2 误差回填和自动化重训

预测模型上线之后，需要持续关注误差变化。我设置了一个每日误差回填任务，在结算价格正式发布后，把预测值和真实值对比，计算 MAE 和 clipped MAPE，写入一个监控表。

我设的触发条件是：连续三天 MAPE 超过警戒线，就自动进入重训练队列。但重训练不能完全自动化，需要有一个人工审核环节，因为某些时段的价格异常可能是市场机制调整导致的，模型重训也无法解决。

另一个要注意的是，不同市场的结算价格发布时间不一样，有的当天发布，有的要隔一天。回填任务要按结算时间对齐，不能按自然日对，否则会把前后两天的数据错位比较。

6.3 上大模型前先问自己的三件事

最后我想说一点方法论层面的经验。如果你也准备把 Chronos-2 这类预训练模型引入自己的预测业务，不要在第一时间就跳到微调和调参。先用最简单的方法跑通基线，然后问自己三个问题：

第一，基线模型有没有明显 bug？如果一周前直接复用这种简单方法都能达到 10% 以内的 MAPE，说明数据本身的复杂度不高，先认真做特征工程，不要急着上大模型。

第二，实际业务对峰值预测要求高不高？如果业务场景只看全天均值和总量，那很多复杂模型带来的增益可能并不显著；如果像电价这样最怕峰谷判断错，那就值得用能输出分位数分布的方法。

第三，你的场景是否频繁变化？一个稳定的长周期预测任务，花大价钱微调大模型是值得的；但如果预测对象三天两头变口径、变数据源、变标签定义，那维护成本会很高，用轻量模型反而更快。

6.4 我的最终落地体会

这次项目从开始到最终上线，最大的收获不是模型精度的提升，而是对“时间序列预测该怎么做”有了更具体的判断：先用最简单的基线确认数据质量，再选择合适的模型范式和特征策略，最后用严格的评估指标驱动迭代。Chronos-2 在电价场景里的表现确实让我意外，但它本质上只是一个工具，真正决定结果上限的，仍然是数据清洗是否完整、评估流程是否严谨、业务理解是否到位。

如果你正打算尝试 Chronos-2，建议先拿一段不太复杂的历史数据跑通零样本流程，感受一下它在不同序列上的表现差异，再决定要不要投入到微调工程里。至少在我这里，从 LSTM 迁移到 Chronos-2 的整个过程，已经让团队把精力从“不断调网络结构”重新拉回到“理解数据和业务”上，我认为这才是它带来的最大价值。