1. 场景生成与削减到底在研究什么先明确技术定位和业务价值前阵子有同行在群里聊到一个课题名字叫“考虑时序相关性MC的场景生成与削减研究”。乍一看像纯粹的数学题但做过电力系统、综合能源或者碳交易相关研究的人应该马上能反应过来这是一个典型的“随机规划前置处理”问题。简单说就是当你要考虑风电、光伏、负荷这些不确定性因素时没法直接把连续的概率分布塞进优化模型里必须先把不确定性转化为一组有限数量的离散场景再用这组场景去驱动随机优化、鲁棒优化或者风险评估。MC指的是Monte Carlo也就是蒙特卡洛模拟。用蒙特卡洛生成大量场景再用削减算法抽出一小撮有代表性的场景已经是行业内最主流的技术路线。这个课题的核心价值在于解决两个痛点。第一个痛点是“怎么把不确定因素表达得足够真实”第二个痛点是“怎么让计算规模小到优化模型能跑得动”。这两个痛点天然相互拉扯场景越多分布刻画越细可计算量直线上升场景太少概率信息丢失优化方案失真。很多人一开始只盯着生成觉得蒙特卡洛抽样谁不会啊均匀抽样、拉丁超立方抽样不都行么结果跑到削减这一步才发现场景质量直接决定后续机组组合、储能容量配置、日前调度决策的成败所以“生成”和“削减”必须作为一个整体来看。这句话里的另一个关键词是“时序相关性”。这是这个课题区别于普通蒙特卡洛场景生成的点睛之笔。风电出力不是独立同分布的随机变量相邻时段的出力之间永远存在强烈的惯性关联白天风速爬坡的时候后一时段的出力大概率跟前一时段接近负荷曲线更是有明显的日周期性凌晨低、傍晚高。如果在场景生成阶段丢弃了这种时序耦合关系出来的场景就会像一串乱跳的噪声看似分布对实际做动态调度优化时完全不可用。这篇内容不打算写得像教科书我会把从蒙特卡洛抽样、时序相关性建模、场景削减到评价验证的完整链路拆开讲每步都会交代“为什么这么做”和我实际调试中的坑。适合正在做新能源出力不确定性建模、微电网容量配置、电力市场风险分析这三类方向的研究生和工程师参考。2. 先搭骨架蒙特卡洛场景生成的基础流程与实现细节2.1 蒙特卡洛生成场景的基本操作蒙特卡洛生成场景的思想并不复杂。先获取目标随机变量的历史数据拟合出概率分布然后从分布里反复抽样每次抽样得到一条完整的时间序列多条序列堆在一起就是“场景集合”。拿风电出力建模举例。历史风速数据通常用两参数Weibull分布拟合概率密度函数长得尖尖的右尾偏长风电功率跟风速之间又有非线性关系切入风速、额定风速、切出风速三段所以不能直接对功率分布抽样要先对风速抽样再带入风速-功率转换曲线得到功率序列。这是很多新手容易跳进去的第一个坑绕过物理环节直接拿功率历史数据拟合分布然后抽样结果功率大量叠加在额定功率附近场景多样性非常差。基础流程拆开是四步。第一步清洗历史数据剔除异常数据、填补恶劣天气缺失值第二步拟合边际分布风速用Weibull、光照辐照度用Beta分布、负荷用正态分布或者混合高斯分布这一步的拟合质量直接影响最终场景的统计特性第三步确定抽样方法。简单蒙特卡洛是直接对分布函数做逆变换采样均匀随机数映射到分位数函数上操作简单但样本可能在尾部稀疏。拉丁超立方抽样先把分布按概率等分区间再从每个区间里抽取一点覆盖性更均匀需要时我会优先用后者第四步把每一条采样点串成时间序列形成完整场景。2.2 一个标准场景生成算例的参数和步骤说个我实际跑过的例子。某风电场的风速历史数据有整整一年的小时级记录8760个点。用极大似然估计拟合出Weibull分布的形状参数k约等于2.1尺度参数A约等于8.5单位m/s。然后用逆变换法生成5000条风速日序列每条序列24小时。每条序列在t时刻的先采样标准均匀随机数带回到累计分布函数的逆函数里得到风速值再根据风机功率曲线折算成出力最终得到一个5000行24列的场景矩阵。这个例子里有几个细节值得交代。抽样时刻如果直接用普通随机数5000个场景的均值曲线很可能在高峰时段明显偏离历史均值为什么因为抽样是朝着分布均值收敛的需要样本量足够大而峰值时段恰好风速分布更宽收敛更慢。拉丁超立方抽样可以减轻这个问题因为分层抽样保证了每个分位区间都有样本被选中。如果发现均值曲线仍然有偏不要急着增加样本量先检查分布拟合是否准确尤其是尾部数据的拟合。缩减版伪代码如下方便对照实现import numpy as np from scipy.stats import weibull_min k, A 2.1, 8.5 wind_speed weibull_min.rvs(ck, loc0, scaleA, size(5000, 24)) # 风机功率转换忽略尾流效应简化三段函数 rated_speed, cut_in, cutoff 12.5, 3.0, 25.0 power np.zeros_like(wind_speed) power[(wind_speedcut_in)(wind_speedrated_speed)] ( wind_speed[(wind_speedcut_in)(wind_speedrated_speed)]) / rated_speed power[wind_speedrated_speed] 1.02.3 独立抽样为什么解决不了实际问题跑完上面这个流程你会得到一个看起来分布很合理的场景集。但如果把任意一条场景拉出来看时间轴大概率会发现它像一条疯癫的折线上一小时风速8m/s下一小时直接跳到2m/s再下一小时又飙到14m/s。这在物理上几乎不可能发生因为风的运动有惯性空气团的移动和气压场的演变决定风速变化是连续的。这个问题在优化阶段会暴露得特别明显。比如做储能调度优化独立抽样场景下储能会被迫频繁在大充大放之间切换因为场景内相邻时段出力突变系统误以为这种剧烈波动是常态优化结果会过于保守或者直接不可行。这就是这个课题要引入时序相关性建模的根本动机。3. 时序相关性是真正的分水岭建模方法对比与实践要点3.1 时序相关性的量化指标想要让场景具备时序相关性首先得有一个能描述“相关性”的指标。日常用的相关系数只能衡量两个变量之间的线性关联拿来衡量同一变量在不同时刻的关联就得用自相关函数。风电出力的自相关函数有个特征时间间隔越短自相关系数越高。小时级数据中相邻时刻自相关通常能到0.9以上间隔24小时则明显下降但可能存在日周期性峰值因为风电出力常带有昼夜节律。评价一个场景生成模型的时序保真能力最简单的方法是计算生成场景的平均自相关函数ACF把它跟历史数据的ACF画在同一张图里比对。如果生成场景在滞后1小时的自相关系数只有0.4而历史数据是0.93那这个场景几乎是废的无论概率分布多么精准都不能用于动态优化。3.2 马尔可夫链方法入门最容易的时序建模马尔可夫链是处理时序相关性最早、应用最广的方法。思路是把连续状态离散化比如把风速状态划为10档建立一个10乘10的状态转移矩阵。矩阵里第i行第j列元素表示“当前时刻风速处于状态i时下一时刻转移到状态j的概率”。一旦转移矩阵确定了场景生成就变成了一条向前的随机游走给定初始状态按转移矩阵逐时刻采样。这个方法的优点非常明显实现直观训练过程就是统计历史数据中状态转移的频次不需要复杂的参数估计。缺点同样不可忽视状态离散化会平滑掉分布内部的细节导致生成的场景在分布尾部失真状态数量少相邻状态之间的连续变化表达不出来状态数量太多统计转移频次时每个格子的样本数急剧减少转移矩阵变得稀疏且不稳定。实操中我踩过不少坑。状态划分就是其中一个关键点。风速的尾部概率很低如果把10个状态的区间等概率划分高速风被压缩到几个区间里低速风也一锅炖这会导致转移矩阵无法刻画极端风速的出现频率。更好的做法是等概率分位数划分让每个状态内样本数大致相同转移矩阵每个格子的统计可信度更高。状态数一般取8到15太少无法表达风速变化梯度太多转移矩阵就碎了。对风电场景我一般会把原始风速数据先按小时序列统计计算一天的初始状态分布与状态转移矩阵。生成场景时从历史状态分布里抽初始状态再循环24次每次按照转移矩阵抽样得到下一时刻状态再映射回风速值。这样得到的风速时间序列天然具备与历史一致的相邻时段转换频次。3.3 基于时间序列模型和copula的更精细方案马尔可夫链建模的是状态转移概率本质上是一阶时序依赖。如果历史数据里存在更长的记忆效应比如风速在连续多个小时内持续爬坡一阶模型就会表现出“忘记”前几时段状态的问题。复杂度高一点的方案是用ARMA或ARIMA时间序列模型先拟合时序结构再进行蒙特卡洛采样。拟合的套路是先对风速序列做差分使其平稳化然后用自相关和偏自相关函数确定ARMA的阶数估计参数。生成场景时从模型残差的分布通常近似高斯抽样递归递推得到模拟风速序列。这种方法能重现平滑爬坡和持续状态但缺点是模型形式偏线性生成序列可能丢掉原始数据的非线性特征和异方差性峰度不足。做研究需要更严格保真的场合我会选择copula方法。copula的思路是把“边际分布建模”和“时序依赖结构建模”拆成两件事。先用非参数核密度估计方法拟合风速的边际分布再用高斯copula或者t-copula拟合时序依赖结构。实际生成时构造一个24维的相关矩阵用高斯copula抽样得到一组时间上相关的标准均匀随机数再把这组随机数通过历史风速分布的逆累计分布函数映射回风速值。这种方法的好处显著边际分布保真时序相关性也保真而且相关结构是可调的想加强或者减弱时序惯性直接调整copula的参数矩阵就行。代价是数值操作比较复杂尤其是大的相关矩阵可能出现非正定需要做特征值修正。我自己在实验中更推荐这种方法做“研究级”场景因为可解释性和可控性都更强。3.4 三种方法怎么选一张对照表说清楚方法实现难度时序保真度边际分布保真度计算开销适用场景马尔可夫链低中等中等低快速验证、教学演示、粗粒度场景ARMA/ARIMA中等较高中等中风光时序建模、调度场景生成时序copula中高高高中高研究级场景、精细风险评估注意不要盲目追求高复杂度方法。如果只是做SAA样本均值逼近的粗粒度优化马尔可夫链已经够用要做分布鲁棒优化或者CVaR风险度量copula的细腻程度才真正有优势。工具选型从来都是跟着问题走的。4. 场景削减从数千场景到几十个场景的取舍艺术4.1 为什么要削减计算复杂度是硬约束生成5000个场景看起来不费劲但把这5000个场景塞进一个含大量0-1变量的混合整数规划模型里求解时间会以指数恶化。机组组合问题里每多一个场景二进制变量数量就直接加一个维度5000个场景意味着求解器可能要跑几十个小时甚至内存溢出。工程上普遍的做法是把场景数压到几十个以内10到50个是最常见的区间。场景削减的本质是从原始的大场景集中挑出一小部分代表性场景给每个被保留的场景重新分配一个概率权重使得削减后场景集与原始场景集的概率分布尽可能接近。这不是简单的随机抽样因为随机抽样剔除了大量位于概率密度中心的场景可能让削减后的场景分布出现不可接受的偏差。4.2 同步回代消除法最经典的削减算法同步回代消除法是我最常用的算法它属于启发式迭代削减逻辑清晰效果也稳定。算法步骤可以拆成这样第一步计算所有场景两两之间的距离。距离度量通常是欧氏距离也就是24维空间中的几何距离。第二步对每一个场景找到跟它距离最近的那个场景把这个“最近距离”作为它的指标值。第三步找出指标值最小的场景也就是最“冗余”的那个场景把它删除同时把它的概率加到距离它最近的那个场景头上。第四步重复第二和第三步直到场景数达到设定目标。每一步都核对了“哪个场景删掉对整体概率信息损失最小”这个目标并即时更新剩余场景的概率分布所以叫“同步回代”每删一个都要重新计算最近邻关系。当目标场景数降到预设值比如从5000降到30剩下的30个场景各自带一个概率权重组合起来就是削减后的场景集。这个算法的优点是实现简单、每一步都有明确的概率意义缺点也很明显计算复杂度是场景数的平方乘以削减轮次当初始场景数量是2万甚至5万的时候距离矩阵计算和迭代搜索非常耗时。实际工程中我一般先做一次粗削减比如用聚类把场景数从2万压到200再用同步回代从200精确削减到20两层配合效率和精度兼顾。4.3 基于K-means聚类的场景削减聚类路线是另一个主流方案。思想是既然要把N个场景砍到K个干脆把这N个场景按距离分成K个簇每个簇的中心场景就是代表性场景簇内场景的概率相加就是这个中心场景的新权重。K-means操作起来非常顺手初始化K个聚类中心迭代更新簇分配和中心位置直到收敛。比起同步回代消除聚类在处理初始场景数量极大时效率高出一大截。可K-means的缺点也是出了名的一是对初始聚类中心敏感不同的初始化可能收敛到不同局部最优二是均值中心可能落在实际场景空间之外的“虚点”上而场景必须是真实可能发生的时间序列输出一个实际不可能出现的出力序列在后续优化里会产生不切实际的可行域需要修正为簇内离均值最近的真实场景。4.4 削减前还是削减后考虑时序相关性一个容易被忽略的细节这一步特别容易栽跟头。如果只用逐点的欧氏距离来计算场景间距离那么一条场景的第3小时异常大另一条场景的第17小时异常大两条场景的欧氏距离可能很小但它们的时间动态形状差异很大。削减后场景集虽然保留了相近的边际分布和概率权重却把时序动态的多样性丢掉了这会让削减后的场景在优化模型里丧失爬坡约束的代表性。要解决这个问题距离度量必须升维实现“时序感知”。常见做法是使用动态时间弯曲距离。DTW通过允许时间轴上的非线性对齐来计算两条序列的相似度本质上是识别两条序列的形状模式哪怕出现小时级的时间位移也能计算出更合理的距离。代价是DTW计算比欧氏距离慢得多所以常被用在削减前的粗筛环节或者在距离矩阵计算时用降采样技巧先看整体形态再细看关键时段。5. 怎么证明场景削减有效评价指标与验证方法论5.1 用分布距离做定量评估削减之后必须回答一个问题削减后的场景集能不能代表原始的大场景集量化这个代表性的最直接指标是分布距离度量。最常用的是Wasserstein距离它衡量的是两个概率分布之间最优传输代价。跟KL散度相比Wasserstein距离即使两个分布的支持集不重叠也能给出有意义的数值而且计算过程相对稳定是学术论文中比较受认可的选择。KL散度也可以用来做辅助观测它衡量的是信息损失量但KL散度对分布尾部差异极其敏感在场景削减这种场景下计算值经常会发散。实操中的一种有效方法是对比概率分布图。画出5000个场景在某一时刻的经验累积分布函数和30个削减后场景的累积分布两条曲线的最大垂直距离就是双边单样本KS检验的检验统计量计算方便指标直观。当然这是工具层面的辅助手段学术评审更关注定量的分布距离和下游应用的稳定性测试。5.2 时序维度上的验证ACF曲线对比分布距离只能证明削减后的场景在统计分布上没有明显偏移但无法证明时序结构被保留了。所以还需要做ACF时序保真校验。具体做法很简单把削减后场景集全部拼接成一个长序列计算这个序列在不同滞后阶数上的自相关系数和原始历史数据的自相关系数对比如果两套ACF曲线能近似贴合说明削减后的场景集保留了关键时序惯性。我在项目中通常给出滞后1小时、2小时、4小时、12小时、24小时五个点的ACF数值做成表格这是评审时非常容易懂并且有说服力的信息。5.3 下游优化结果的稳定性终极验证最后也是最重要的一层验证是下游应用的逻辑一致性检验。场景削减得再好、分布指标再漂亮如果用它算出来的决策结果跟大场景集的决策结果差得离谱这个削减就没有实际价值。一般做法是分别用原始大场景集和削减后场景集求解同一个随机优化问题对比两者的目标函数值和关键决策量。以我常做的风电-储能联合运行优化为例目标函数是总运行成本与弃风惩罚大场景集算出的期望成本是125.3万元削减到30个场景后算出的期望成本是127.8万元偏差在百分之二以内但求解时间从4小时缩短到了12分钟这个结果就是可接受的。如果偏差超过5%我会回头检查距离度量是否忽略了时序感知或者削减目标场景数是否压得太狠。做削减研究时应该把精力集中在“分布不偏、时序不坏、下游稳定”这三件事上而不是追求单一的KS检验或者ACF指标好看。6. 实操经验与避坑指南从真实项目调试中踩过的坑6.1 数据清洗不干净再高级的算法都是白搭这个坑几乎所有人都踩过我自己也不例外。某次做算例时输入数据里混入了停机检修时段的风速记录那些时段风速和出力全部归零对分布拟合产生了极大的干扰。马尔可夫链的状态转移矩阵因此出现大量停留在零状态的转移生成场景中频繁出现全零时段跟真实物理过程严重不符。正确的做法是先对历史数据进行质量标记哪些时段是正常运营、哪些是计划检修、哪些是通信故障导致的假零值分别给标签。剔除或者修正这些假数据之后再做分布拟合。另外异常数据不一定是零值也可能是传感器饱和产生的截断值、长时间恒定不变的死值需要用滑动窗口标准差检测出来。6.2 场景数量的权衡不是越少越好有次我为了追求极致计算速度把场景从5000直接削减到10个结果下游随机优化问题收敛倒是快了但优化结果在风电预测误差尾部场景下出现了明显的过拟合决策过于激进。因为10个场景完全无法容纳极端但小概率的高影响事件比如连续多日大风的场景在削减过程中被当作冗余去掉了。做场景削减目标数设置的时候我有几个经验值可以参考用于启发式调度30到50个场景够用用于容量规划需要50到80个才能覆盖季节性差异用于风险评估至少要保持100个否则尾部风险根本无法可靠度量。经验法则不一定适合所有数据但起步点不会错得太远。6.3 马尔可夫链状态数选择数量太少丢动态、太多转移矩阵稀疏状态数的选择我给出的建议是先看数据的自相关强度。如果ACF滞后一阶大于0.9说明状态之间有很强的惯性状态数可以适当多设10到12个仍然能保持转移矩阵的统计可信度。如果数据本身噪声大、ACF低状态数超过6个就极度容易出问题因为每个格子的频次太低。还有一个隐藏很深的细节转移矩阵的行归一化时如果某一行在历史数据中从未出现过零行生成的马氏链可能在运行过程中卡死。处理办法是把零行替换为全局平均转移概率避免状态不可达。6.4 削减计算的性能优化分层削减策略当初始场景数是5万时直接跑同步回代消除单次迭代的最近邻计算量是n平方量级每一轮还有场景数的维度更新实际上非常慢。我常用的方案是先做聚类粗选把5万个场景聚类到500个再用同步回代从500削减到50。粗削减阶段损失的信息量很小因为聚类本身保护了分布形态而细削减阶段规模小迭代速度非常快。距离矩阵的内存管理也值得注意。5万个场景、24维数据两两距离矩阵是24乘以5万的平方也就是60亿个浮点数直接存下来会有内存问题。正确做法是非一次性计算而是按块迭代或者在近邻搜索时用KD树近似避免60亿量级的矩阵同时驻留内存。6.5 场景削减后的概率更新别忽略场景削减不只是删掉冗余场景必须同步更新保留场景的概率权重。我在代码评审时经常看到有人删完场景后不更新概率或者只简单地把被删场景的概率除以保留场景数这种做法必然导致削减后场景集的整体概率之和不再等于1或者在中心场景处概率堆积异常。正确的做法是每一次合并都要把删掉场景的概率完整加到它的最近邻场景头上且总概率始终为1。7. 后续扩展思路探讨这个课题再往下发展有几个方向值得关注。一个是跟深度学习结合用生成对抗网络或者扩散模型来学习历史数据的分布和时序结构替代传统参数化建模。深度学习的方法在边际分布刻画上有天然优势几乎不需要显式假设分布形式但代价是需要大量高质量历史数据来训练而且生成场景的可解释性比马尔可夫链和copula弱一些用在优化模型里时必要的是先做分布保真度验证。另一个方向是把削减算法跟优化目标耦合起来也就是所谓的“面向决策的场景削减”。传统的削减是追求原始场景集合的分布逼近但在实际决策问题中某些场景即便概率低也可能对最优决策方向有颠覆性影响这部分应该保留。目标引领下的场景削减方案研究方向很有意思会非常对口的解决新能源并网下极端条件与保守决策的平衡问题。结束语说说我个人的体会做得越多越发现场景生成与削减这件事最考验人的不是数学功底而是“信息取舍判断力”。生成阶段要做减法把历史数据里那些对决策无帮助的噪声剔除削减阶段又要做保护把尾部风险、极端气象这些稀缺但重要的信息保住。我自己在多数项目里最愿意使用的组合还是拉丁超立方抽样加时序copula加同步回代消除这一套组合的稳定性和可解释性都很强。再提醒一句不管选什么方法一定要把验证环节放在和算法设计同等重要的位置。每次生成和削减之后都问一下自己概率分布偏了多少时序特征还在吗下游决策变了吗。三个问题全过关你的场景集才算真正做到位而不是只在数学指标上漂亮。最后分享一个实用小技巧做场景削减前先把原始场景按季节或者按天气类型分成几个子集分组削减后再合并。这样能有效防止某个发生频率较低但影响重大的场景类别在削减中整个被清洗掉尤其是冬季大风光模式保证它在最终的场景集里始终保有一席之地。这个小习惯帮我在好几个项目中避免了优化结果偏保守的问题你们可以参考。