做电力数字化这行的人应该都有同感电力、数据、AI这三个词单独拿出来都熟悉但真要合成一个技术栈去落地不少人心里是没底的。去年我参与某区域电网的一个配网负荷预测试点数据不缺、算力不缺难的是把电力业务语言翻译成数据和AI能理解的工程链路。这篇就把我们当时整理和实施的技术栈思路完整写一遍适合电力行业的IT工程师、数据开发、算法人员以及准备进入这个交叉领域的同学参考。1. 为什么电力行业要单独讲一套数据AI技术栈1.1 电力数据不缺缺的是链路我经常听到一种说法电力行业不缺数据量测系统里每秒都在产生遥测数据。这句话对但也不全对。数据不缺缺的是能把数据从采集端接到模型端的完整链路。一个地市级供电企业可能有量测SCADA数据、用电采集数据、营销档案数据、气象服务数据、设备台账数据甚至还有巡检机器人的图像数据。这些数据分散在不同部门、不同系统里时间基准不统一、设备命名规则不统一、数据粒度也不统一。AI项目最怕的不是没有算法而是前期80%时间都在做数据对接和清洗。我们当时的试点范围只是几条配网线路就花了两周时间梳理量测点表。你要预测一条线路的负荷得先搞清楚这条线路在数据平台里对应哪些量测点主站的命名和终端侧的命名能不能对得上遥测变比是不是一致。这些活看起来是脏活累活但技术栈的选型恰恰主要由这些现实约束决定。1.2 电力业务对AI系统有三个特殊要求互联网行业做数据AI核心追求往往是高并发、低延迟、高转化。电力场景不一样至少有三个特殊要求会直接影响技术栈选型。第一是容错方向不同。互联网推荐系统预测错了用户偏好最多损失一次点击电力系统负荷预测错了可能影响备用容量安排异常检测漏报则可能让设备带病运行。所以系统的设计目标不是“绝对准确”而是“错误可控、可告警、可回退”。第二是可解释性要求强。调度人员和运检人员不会盲目相信一个黑盒模型。他们需要知道为什么报警、为什么预测值突然升高至少要能给出一两个可追溯的原因。这直接决定模型选型范围——完全不可解释的深度网络在电力业务系统里很难推广。第三是实时与历史并存时间维度特别重。电力数据本质上是强时间序列数据设备运行状态、负荷变化、发电出力都随时间连续变化且具有明显的周期性和季节性。这就决定了数据存储、特征构造、模型训练都要围绕时序展开和互联网主战场里的“用户行为日志实时点击流”模式有很大区别。1.3 为什么不能照搬互联网那一套有人问为什么不直接用常见的日志采集、数据仓库、机器学习平台那套成熟方案不是不能用而是直接照搬会水土不服。互联网数据大多是非结构化日志电力行业核心数据是结构化时序量测。互联网系统可以接受写多读少、最终一致电力系统很多场景要求强一致和可追溯。互联网模型可以快速A/B实验电力系统模型改动要过业务评审和接口变更流程。最典型的差异是互联网的数据“延迟”是秒级到分钟级电力数据的“时延”要求可能从毫秒级保护到小时级统计都有你没法用一套统一框架全包。我的建议是先按业务需求把数据分层再逐层选择工具不要从一开始就追求大而全的技术栈。2. 技术栈全景图从采集到决策的四层架构与选型我们当时把整个系统拆成四层采集接入层、存储治理层、计算分析层、模型应用层。每层选型都按电力场景做裁剪。2.1 第一层采集接入层重点不在协议转换而在数据质量前置电力数据采集会涉及多种规约比如变电站测控、配网终端、电表集中器等各自的上送机制和报文格式都不一样。常规做法是用专用的采集网关做规约解析再统一转换为内部标准JSON或二进制格式写入消息队列。选消息队列时我们对比过主流的几种。吞吐量不是主要矛盾电力遥测数据的规模远没有互联网日志那么大真正的痛点是数据乱序和重复上送。遥测终端本身没有强事务机制断点续传后数据可能延迟到达这会造成时间窗口内的数据乱序。所以消息队列的全局有序能力反而不重要下游做“按业务时间戳去重和缓冲”才是关键。采集层最容易踩的坑是只在接入端做了解析没有做数据合法性检查。坏数据一旦进入存储后面清洗成本会指数级上升。我们在接入端加了三道简单检查数值范围检查、时间戳单调性检查、变化率粗筛。宁可把可疑数据标记出来也不要让它在系统里悄悄流通。2.2 第二层存储与治理时序库加对象存储加关系库存储层我们最终采用三角结构时序数据库、对象存储、关系型数据库各管一摊。时序库主要存放量测数据和计算后的曲线数据这一层要重点评估写入性能、压缩比和聚合查询能力。当时对比了几个开源方案各有优劣。有的时序库分布式能力弱但单机写入和查询足够覆盖地市级规模有的时序库在聚合函数上做得更完善适合跨长时间窗口统计。我的建议是先按“单站/单区域规模”评估不要一上来就规划几十节点的集群大部分电力项目的数据量用单机或者双机加副本就够了。对象存储用于存放原始报文归档、模型文件、训练样本快照。为什么需要原始数据归档因为业务审计时可能要回溯某个时间段内某条数据是怎么来的如果只保留清洗后的数据没法自证清白。我们当时的做法是按月把原始报文压缩后放进对象存储保留两年成本极低。关系库则负责计量点台账、设备参数、模型版本、告警记录等结构化业务数据。这一块的建模要贴近电力业务习惯尤其注意一个量测点可能对应多个业务口径比如同一个“电流”可能是关口计量电流也可能是保护电流不能只用一张宽表硬塞。2.3 第三层计算引擎电力场景用不到太重的实时计算流计算和批处理之间电网数据分析现状是批处理占了绝大多数场景。负荷预测、设备趋势分析、线损统计这些基本都是小时级或天级任务用离线计算完全够。只有异常告警、负荷越限等少数场景需要秒级响应。所以我们没有构建复杂的流计算集群只用了轻量级规则引擎配合消息队列做实时告警把重量级计算交给批处理框架。这样做的好处是运维成本低、故障排查容易。如果现在让我重新选我依然会这么做——电力场景流的“实时性”更多是业务响应速度问题不是技术吞吐问题。2.4 第四层模型应用层模型服务要与业务系统解耦模型应用层常见的做法是训练环境、模型仓库、推理服务三个部分分开。训练可以放在离线计算集群上产出的模型文件统一注册进模型仓库推理服务只从仓库拉取模型并提供标准HTTP或gRPC接口。这层最容易忽视的是版本管理。电力业务系统对稳定性要求极高一个模型出了问题要能立刻回退到上一版本。所以我们每次发布模型都记录训练数据时间范围、特征版本、评估报告和审批人形成完整档案。有一次就是靠这个档案回退了三周前的模型避免了一次误报风暴。3. 数据治理才是重头戏遥测清洗、时间对齐与语义映射这一章我单独拿出来讲是因为我们团队在这个环节花的精力比算法本身多得多。业界有个说法数据治理占项目周期70%以上在电力场景绝对不夸张。3.1 死数、毛刺、漂移三类典型脏数据电力遥测数据第一类常见问题是死数也就是测点长时间返回同一数值。这可能是终端冻结、通道中断或者一次侧设备确实处于稳态。区分起来需要结合工况一个10kV馈线电流如果连续12个小时都精确等于同一个值十有八九是终端冻结。我们判断死数的规则是“连续N个数据点完全相等且其中至少一个点被标记为实时刷新成功”。如果N个点都完全一样且刷新标记正常就标为疑似死数交给人工核对。第二类是毛刺表现为单点或多点瞬间跳变后恢复幅度和前后值差异极大。原因可能是电磁干扰、对时异常或者终端重启。毛刺清洗不能只看绝对阈值因为负荷本身会在短时内大幅波动我们用的是阶梯限制例如两分钟内变化率超过每细分容量的一定比例先标疑似毛刺再用相邻窗口中位数替代。第三类是缓变漂移比如电压曲线整体平移或者变压器温度连续偏离预期区间。这种问题最难发现因为它不破坏曲线形态。我们通常靠设备间横向对比来识别同一母线下的两个同型号设备趋势相关系数低于设定阈值就会触发核查。3.2 缺失补全补错比不补更危险数据缺失在电力系统很常见通道抖动、终端离线都会造成。处理原则是区分缺失时长与场景。短时缺失比如几分钟到半小时用前后线性插值就行误差可控。长时缺失超过数小时就要小心了因为负荷变化往往和气象、日期类型强相关盲目插值会产生伪规律。更关键的是要识别“语义零值”。光伏电站在夜间出力天然为零这是正常的但如果系统把“通信中断导致的零值”当成真实零值补进去模型会把夜间规律错误泛化到白天。我们当时针对新能源站点专门建了一个“零值可信度”标记只有接收正常且一次侧电气量为零才算真实零值否则保留为空让下游模型自己决定处理方式。3.3 对齐比清洗更磨人的是时间基准不同系统的时间基准差异是数据治理里最磨人的地方。量测终端上送时间、采集网关存储时间、应用库接收时间三层可能都有偏差。如果直接用数据库的接收时间做分析乱序数据会把曲线搞得一团糟。我们最终做了两件事。第一是建立“业务时间戳优先”原则所有分析都基于终端业务时间戳而不是系统接收时间戳。第二是做时间对齐重采样把不同采集周期秒级、分钟级、15分钟级统一到标准分钟点。对齐时需要对重采样算法敏感简单求平均会把负荷峰谷磨平我们用的是“窗口内最后有效值前向填充窗口均值回调”的混合策略既保留真实阶跃变化又不至于把瞬时毛刺放大。3.4 量测点语义映射让我踩了最久的一个坑量测点映射是数据治理里我最想提醒大家的部分。同一个物理测点在主站系统、终端系统、营销系统里的命名可能完全不同。比如“1号主变高压侧A相电流”在三个系统里分别可能是“1B_HV_A_I”“T01_IA”“A相电流”。如果靠人工对照表维护新增一个站点就要改一遍根本不可持续。我们当时的解决方法是建一张“量测点语义字典表”包含物理对象、相别、量测类型、系统来源、原始字符串模式、单位、变比等字段。采集接入时按字典规则自动匹配匹配不上就进入人工确认队列。这张表建好后我们新增站点的接入时间从几天缩短到半天。这类基础设施工作做得越扎实后面算法试错的空间就越大。我见过不少团队急着上模型结果因为量测点匹配错误训练标签本身就是错的整个模型作废重来。这种返工成本比前期治理成本高太多。4. 模型落地实录负荷预测与异常检测的工程化细节4.1 为什么我先把神经网络放到一边说到电力AI很多人第一反应是深度学习。我们团队初期也尝试了常见的深度时序模型但后来在工程落地时主动降级了。不是深度模型不好而是电力场景的样本量和业务要求不支持它发挥优势。一条线路的负荷数据虽然按15分钟粒度一年有两万多条但真正影响负荷变化的强特征是高维离散的气象、节假日、检修计划数据量远不够深度学习充分拟合。而且调度侧要求模型能解释预测跳变的原因深度模型很难讲清楚。我们最终的主力模型是梯度提升树配合丰富的时序特征效果非常稳。和深度模型对比下来MAPE只差不到1个百分点但训练时间短一个量级推理可解释性也强很多。真实业务系统里这种“稍有妥协但长期可维护”的选择往往走得最远。4.2 特征工程清单电力负荷预测的输入到底有哪些特征工程决定了模型上限。我们按四类构造日历特征小时、星期、是否工作日、是否节假日、峰谷平段标识。这是电力负荷最基本的骨架一条负荷曲线天然有早晚高峰和午谷。气象特征温度、湿度、风速、辐照度以及它们的滞后值。温度和负荷之间存在明显的非线性关系制冷负荷和采暖负荷对温度的敏感度完全不同。我们特意构造了“温度舒适区间偏差”特征即温度偏离18到26度区间的距离效果比直接用原始温度更好。滞后特征过去24小时、过去168小时的负荷值。电力负荷有强自相关性昨天同一时刻、上周同一时刻的负荷是最强预测因子。相似日特征自动挑选近期工况相似日期同星期类型、同期气象的负荷曲线做均值作为当前时段的基准参考。特征不是越多越好。我们维护了一份特征清单每条特征都记录来源、计算方式和评估贡献度跑完一次训练就筛掉一批无关特征最终从一百多个砍到四十多个线上推理速度明显提升精度反而没掉。这段代码是我们线上主模型的特征构造示意def build_features(df, weather_df, holidays): df df.sort_values(ts) # 日历特征 df[hour] df[ts].dt.hour df[weekday] df[ts].dt.weekday df[is_holiday] df[ts].dt.date.isin(holidays).astype(int) # 气象滞后特征 merged pd.merge_asof(df, weather_df, onts, directionbackward) merged[temp_diff] (merged[temperature] - 22).abs() # 滞后与相似日特征 for lag in [24, 168]: merged[flag_{lag}h] merged.groupby(point_id)[load].shift(lag) merged[similar_day_mean] ( merged.groupby([point_id, weekday, hour])[load] .transform(lambda x: x.rolling(7, min_periods1).mean()) ) return merged.dropna()4.3 评价指标陷阱MAPE好不代表真正可用做完第一版模型我们看了整体MAPE在3%以内觉得不错。后来调度同事一句话点醒了我“平均误差有什么用我要知道明天早高峰预测准不准、会不会有偏差我需要的是高峰时段准。”确实电力系统最关心的是峰值时段。早高峰和晚高峰的负荷预测如果偏小备用容量安排不足这是有直接安全影响的低谷时段预测偏大又会导致不必要的机组启停成本。所以我们又加了三个指标一起看峰时段最大绝对误差、晚高峰连续偏差方向、全天最大单点误差。这几个指标比总体MAPE更能反映业务风险。模型评估报告里我们会固定输出一张对比表包含不同时段、不同季节、不同天气类型下的表现。这样业务评审时能快速定位模型在什么场景下不可信。如果某个台风天气样本下误差明显放大就不应该硬扛而是要考虑切换保守策略。4.4 异常检测无监督算法加规则兜底才是可解释的除预测之外设备异常检测是电力AI的另一个刚需。纯无监督算法在电力场景有个问题它能在历史数据里发现离群点但很难告诉运维人员“为什么异常”。让运维人员接受一个深度自编码器检测出来的报警需要花费大量解释成本。我们采用的方案是“无监督初筛规则兜底”。自编码器或孤立森林先把可疑时间窗口筛出来然后进一层规则引擎做二次验证规则包括电气量越限、三相不平衡度超阈值、谐波含量异常、温度与负荷的比值偏离历史区间。只有同时命中无监督异常候选和至少一条规则才正式生成告警。这个机制上线后误报率大幅下降。因为规则是运维人员自己参与制定的他们天然信任这套输出。无监督模型负责发现未知模式规则负责让告警有据可依两者组合比任何单一算法都更适合电力行业的生产环境。5. 部署上线后的事三种形态、模型漂移与灰度运维模型训练完成只是系统工程的一半上线运维阶段才是真正拉开差距的地方。5.1 云、边、端三种部署形态怎么分工电力AI应用的部署形态天然是云边端协同而不是单一云平台。云端承担的是离线训练、全局优化、综合研判比如全区域负荷预测、网架薄弱环节分析。云端算力充足可以跑复杂模型但通信链路长不适合毫秒级响应。边缘侧按区域或变电站部署承担区域负荷预测、就地异常告警、数据清洗前置。边缘节点会缓存原始数据网络中断时也能独立运行一段时间。这部分对硬件要求是可靠性优先我们当时选的是工控机加双电源方案。终端侧主要是智能电表、在线监测装置这类就地设备运行的是轻量级诊断规则或极简模型。终端算力有限但胜在靠近数据源掉线不影响判断。注意终端上不要部署复杂深度学习模型特别在通信代价高、设备管理分散的场景规则引擎反而更健壮。5.2 模型漂移一个真实的风电场案例模型刚上线时效果很好过一段时间开始悄悄变差这种情况就叫模型漂移。我们遇到的一个典型场景是风电场出力预测。某天开始风电场夜间出力预测持续偏大整体MAPE从8%一路涨到15%。我们最初怀疑是气象源数据问题检查后发现气象预报和实测都在合理范围。后来是数据同事提醒查看场站运行日志才发现其中一排风机因为变流器故障持续限功率运行。历史训练数据里没有这个工况模型不知道“风机没在出力”这件事依然按风速对应出力的曲线预测自然偏大。这个案例给我们的教训是模型漂移不一定来自统计形态变化也可能是设备工况或业务规则变化。所以漂移监控里要同时跟踪“外部特征分布”和“关键事件日志”。我们后来建了一个事件字典把检修、故障、限电、停运等事件自动关联到模型效果波动上告警时直接给出事件线索处理效率提高很多。5.3 灰度上线与失败回退不能只有部署脚本电力系统的模型更新必须带灰度机制。我们每次新模型发布先在旁路跑评估只记录预测结果与真值的偏差不影响正式出口。旁路评估通过后再切少量业务流量试运行比如只对某几条线路生效。稳定运行一周后再全量切换。同时每个新版本都要保留上一版本模型至少一个月保证随时可回退。回退不是简单换文件还要回退对应的特征版本和告警阈值否则新旧特征口径不一致接口数据会乱。我建议把这套流程固化成发布清单每个操作项都有人确认而不是靠经验临时操作。5.4 与调度、营销系统对接的合规细节电力行业系统对接不只是技术问题。数据出不出域、谁能访问、接口调用的审计留痕、变更审批流程这些都是上线前就必须谈清楚的。我们在接口设计上坚持几个原则接口只读优先除非必要不开放写操作所有调用走服务网关统一鉴权禁止裸连数据库每次调用记录调用方、时间和返回规模审计日志至少保存半年批量导出必须走申请流程。这些规则看起来增加了工作量但能避免后期很多扯皮。特别是涉及负荷数据和用户用电信息流程不合规会导致整个系统被叫停不是危言耸听。最后按我的个人经验留个尾巴。做电力数据AI这个交叉领域最大的体会是“业务先行、数据为重、模型在后”。技术栈里每一层的选型都应该先回答一个业务问题这个数据要用在哪个决策环节错了会有什么代价。先找一个最小的闭环跑起来比如先盯住一条线路的负荷预测把采集、治理、训练、部署、监控整个链路走通一次再横向扩展。另一条建议是每套模型都要配齐“数据字典、特征清单、评估报告、回退方案”四件套几个月后回头看你会感谢当时的自己。 
长河君 · 2026/10/17 23:51:58 · 阅读 1.2k 电力数据AI技术栈落地全解析：从采集治理到模型部署
做电力数字化这行的人应该都有同感电力、数据、AI这三个词单独拿出来都熟悉但真要合成一个技术栈去落地不少人心里是没底的。去年我参与某区域电网的一个配网负荷预测试点数据不缺、算力不缺难的是把电力业务语言翻译成数据和AI能理解的工程链路。这篇就把我们当时整理和实施的技术栈思路完整写一遍适合电力行业的IT工程师、数据开发、算法人员以及准备进入这个交叉领域的同学参考。1. 为什么电力行业要单独讲一套数据AI技术栈1.1 电力数据不缺缺的是链路我经常听到一种说法电力行业不缺数据量测系统里每秒都在产生遥测数据。这句话对但也不全对。数据不缺缺的是能把数据从采集端接到模型端的完整链路。一个地市级供电企业可能有量测SCADA数据、用电采集数据、营销档案数据、气象服务数据、设备台账数据甚至还有巡检机器人的图像数据。这些数据分散在不同部门、不同系统里时间基准不统一、设备命名规则不统一、数据粒度也不统一。AI项目最怕的不是没有算法而是前期80%时间都在做数据对接和清洗。我们当时的试点范围只是几条配网线路就花了两周时间梳理量测点表。你要预测一条线路的负荷得先搞清楚这条线路在数据平台里对应哪些量测点主站的命名和终端侧的命名能不能对得上遥测变比是不是一致。这些活看起来是脏活累活但技术栈的选型恰恰主要由这些现实约束决定。1.2 电力业务对AI系统有三个特殊要求互联网行业做数据AI核心追求往往是高并发、低延迟、高转化。电力场景不一样至少有三个特殊要求会直接影响技术栈选型。第一是容错方向不同。互联网推荐系统预测错了用户偏好最多损失一次点击电力系统负荷预测错了可能影响备用容量安排异常检测漏报则可能让设备带病运行。所以系统的设计目标不是“绝对准确”而是“错误可控、可告警、可回退”。第二是可解释性要求强。调度人员和运检人员不会盲目相信一个黑盒模型。他们需要知道为什么报警、为什么预测值突然升高至少要能给出一两个可追溯的原因。这直接决定模型选型范围——完全不可解释的深度网络在电力业务系统里很难推广。第三是实时与历史并存时间维度特别重。电力数据本质上是强时间序列数据设备运行状态、负荷变化、发电出力都随时间连续变化且具有明显的周期性和季节性。这就决定了数据存储、特征构造、模型训练都要围绕时序展开和互联网主战场里的“用户行为日志实时点击流”模式有很大区别。1.3 为什么不能照搬互联网那一套有人问为什么不直接用常见的日志采集、数据仓库、机器学习平台那套成熟方案不是不能用而是直接照搬会水土不服。互联网数据大多是非结构化日志电力行业核心数据是结构化时序量测。互联网系统可以接受写多读少、最终一致电力系统很多场景要求强一致和可追溯。互联网模型可以快速A/B实验电力系统模型改动要过业务评审和接口变更流程。最典型的差异是互联网的数据“延迟”是秒级到分钟级电力数据的“时延”要求可能从毫秒级保护到小时级统计都有你没法用一套统一框架全包。我的建议是先按业务需求把数据分层再逐层选择工具不要从一开始就追求大而全的技术栈。2. 技术栈全景图从采集到决策的四层架构与选型我们当时把整个系统拆成四层采集接入层、存储治理层、计算分析层、模型应用层。每层选型都按电力场景做裁剪。2.1 第一层采集接入层重点不在协议转换而在数据质量前置电力数据采集会涉及多种规约比如变电站测控、配网终端、电表集中器等各自的上送机制和报文格式都不一样。常规做法是用专用的采集网关做规约解析再统一转换为内部标准JSON或二进制格式写入消息队列。选消息队列时我们对比过主流的几种。吞吐量不是主要矛盾电力遥测数据的规模远没有互联网日志那么大真正的痛点是数据乱序和重复上送。遥测终端本身没有强事务机制断点续传后数据可能延迟到达这会造成时间窗口内的数据乱序。所以消息队列的全局有序能力反而不重要下游做“按业务时间戳去重和缓冲”才是关键。采集层最容易踩的坑是只在接入端做了解析没有做数据合法性检查。坏数据一旦进入存储后面清洗成本会指数级上升。我们在接入端加了三道简单检查数值范围检查、时间戳单调性检查、变化率粗筛。宁可把可疑数据标记出来也不要让它在系统里悄悄流通。2.2 第二层存储与治理时序库加对象存储加关系库存储层我们最终采用三角结构时序数据库、对象存储、关系型数据库各管一摊。时序库主要存放量测数据和计算后的曲线数据这一层要重点评估写入性能、压缩比和聚合查询能力。当时对比了几个开源方案各有优劣。有的时序库分布式能力弱但单机写入和查询足够覆盖地市级规模有的时序库在聚合函数上做得更完善适合跨长时间窗口统计。我的建议是先按“单站/单区域规模”评估不要一上来就规划几十节点的集群大部分电力项目的数据量用单机或者双机加副本就够了。对象存储用于存放原始报文归档、模型文件、训练样本快照。为什么需要原始数据归档因为业务审计时可能要回溯某个时间段内某条数据是怎么来的如果只保留清洗后的数据没法自证清白。我们当时的做法是按月把原始报文压缩后放进对象存储保留两年成本极低。关系库则负责计量点台账、设备参数、模型版本、告警记录等结构化业务数据。这一块的建模要贴近电力业务习惯尤其注意一个量测点可能对应多个业务口径比如同一个“电流”可能是关口计量电流也可能是保护电流不能只用一张宽表硬塞。2.3 第三层计算引擎电力场景用不到太重的实时计算流计算和批处理之间电网数据分析现状是批处理占了绝大多数场景。负荷预测、设备趋势分析、线损统计这些基本都是小时级或天级任务用离线计算完全够。只有异常告警、负荷越限等少数场景需要秒级响应。所以我们没有构建复杂的流计算集群只用了轻量级规则引擎配合消息队列做实时告警把重量级计算交给批处理框架。这样做的好处是运维成本低、故障排查容易。如果现在让我重新选我依然会这么做——电力场景流的“实时性”更多是业务响应速度问题不是技术吞吐问题。2.4 第四层模型应用层模型服务要与业务系统解耦模型应用层常见的做法是训练环境、模型仓库、推理服务三个部分分开。训练可以放在离线计算集群上产出的模型文件统一注册进模型仓库推理服务只从仓库拉取模型并提供标准HTTP或gRPC接口。这层最容易忽视的是版本管理。电力业务系统对稳定性要求极高一个模型出了问题要能立刻回退到上一版本。所以我们每次发布模型都记录训练数据时间范围、特征版本、评估报告和审批人形成完整档案。有一次就是靠这个档案回退了三周前的模型避免了一次误报风暴。3. 数据治理才是重头戏遥测清洗、时间对齐与语义映射这一章我单独拿出来讲是因为我们团队在这个环节花的精力比算法本身多得多。业界有个说法数据治理占项目周期70%以上在电力场景绝对不夸张。3.1 死数、毛刺、漂移三类典型脏数据电力遥测数据第一类常见问题是死数也就是测点长时间返回同一数值。这可能是终端冻结、通道中断或者一次侧设备确实处于稳态。区分起来需要结合工况一个10kV馈线电流如果连续12个小时都精确等于同一个值十有八九是终端冻结。我们判断死数的规则是“连续N个数据点完全相等且其中至少一个点被标记为实时刷新成功”。如果N个点都完全一样且刷新标记正常就标为疑似死数交给人工核对。第二类是毛刺表现为单点或多点瞬间跳变后恢复幅度和前后值差异极大。原因可能是电磁干扰、对时异常或者终端重启。毛刺清洗不能只看绝对阈值因为负荷本身会在短时内大幅波动我们用的是阶梯限制例如两分钟内变化率超过每细分容量的一定比例先标疑似毛刺再用相邻窗口中位数替代。第三类是缓变漂移比如电压曲线整体平移或者变压器温度连续偏离预期区间。这种问题最难发现因为它不破坏曲线形态。我们通常靠设备间横向对比来识别同一母线下的两个同型号设备趋势相关系数低于设定阈值就会触发核查。3.2 缺失补全补错比不补更危险数据缺失在电力系统很常见通道抖动、终端离线都会造成。处理原则是区分缺失时长与场景。短时缺失比如几分钟到半小时用前后线性插值就行误差可控。长时缺失超过数小时就要小心了因为负荷变化往往和气象、日期类型强相关盲目插值会产生伪规律。更关键的是要识别“语义零值”。光伏电站在夜间出力天然为零这是正常的但如果系统把“通信中断导致的零值”当成真实零值补进去模型会把夜间规律错误泛化到白天。我们当时针对新能源站点专门建了一个“零值可信度”标记只有接收正常且一次侧电气量为零才算真实零值否则保留为空让下游模型自己决定处理方式。3.3 对齐比清洗更磨人的是时间基准不同系统的时间基准差异是数据治理里最磨人的地方。量测终端上送时间、采集网关存储时间、应用库接收时间三层可能都有偏差。如果直接用数据库的接收时间做分析乱序数据会把曲线搞得一团糟。我们最终做了两件事。第一是建立“业务时间戳优先”原则所有分析都基于终端业务时间戳而不是系统接收时间戳。第二是做时间对齐重采样把不同采集周期秒级、分钟级、15分钟级统一到标准分钟点。对齐时需要对重采样算法敏感简单求平均会把负荷峰谷磨平我们用的是“窗口内最后有效值前向填充窗口均值回调”的混合策略既保留真实阶跃变化又不至于把瞬时毛刺放大。3.4 量测点语义映射让我踩了最久的一个坑量测点映射是数据治理里我最想提醒大家的部分。同一个物理测点在主站系统、终端系统、营销系统里的命名可能完全不同。比如“1号主变高压侧A相电流”在三个系统里分别可能是“1B_HV_A_I”“T01_IA”“A相电流”。如果靠人工对照表维护新增一个站点就要改一遍根本不可持续。我们当时的解决方法是建一张“量测点语义字典表”包含物理对象、相别、量测类型、系统来源、原始字符串模式、单位、变比等字段。采集接入时按字典规则自动匹配匹配不上就进入人工确认队列。这张表建好后我们新增站点的接入时间从几天缩短到半天。这类基础设施工作做得越扎实后面算法试错的空间就越大。我见过不少团队急着上模型结果因为量测点匹配错误训练标签本身就是错的整个模型作废重来。这种返工成本比前期治理成本高太多。4. 模型落地实录负荷预测与异常检测的工程化细节4.1 为什么我先把神经网络放到一边说到电力AI很多人第一反应是深度学习。我们团队初期也尝试了常见的深度时序模型但后来在工程落地时主动降级了。不是深度模型不好而是电力场景的样本量和业务要求不支持它发挥优势。一条线路的负荷数据虽然按15分钟粒度一年有两万多条但真正影响负荷变化的强特征是高维离散的气象、节假日、检修计划数据量远不够深度学习充分拟合。而且调度侧要求模型能解释预测跳变的原因深度模型很难讲清楚。我们最终的主力模型是梯度提升树配合丰富的时序特征效果非常稳。和深度模型对比下来MAPE只差不到1个百分点但训练时间短一个量级推理可解释性也强很多。真实业务系统里这种“稍有妥协但长期可维护”的选择往往走得最远。4.2 特征工程清单电力负荷预测的输入到底有哪些特征工程决定了模型上限。我们按四类构造日历特征小时、星期、是否工作日、是否节假日、峰谷平段标识。这是电力负荷最基本的骨架一条负荷曲线天然有早晚高峰和午谷。气象特征温度、湿度、风速、辐照度以及它们的滞后值。温度和负荷之间存在明显的非线性关系制冷负荷和采暖负荷对温度的敏感度完全不同。我们特意构造了“温度舒适区间偏差”特征即温度偏离18到26度区间的距离效果比直接用原始温度更好。滞后特征过去24小时、过去168小时的负荷值。电力负荷有强自相关性昨天同一时刻、上周同一时刻的负荷是最强预测因子。相似日特征自动挑选近期工况相似日期同星期类型、同期气象的负荷曲线做均值作为当前时段的基准参考。特征不是越多越好。我们维护了一份特征清单每条特征都记录来源、计算方式和评估贡献度跑完一次训练就筛掉一批无关特征最终从一百多个砍到四十多个线上推理速度明显提升精度反而没掉。这段代码是我们线上主模型的特征构造示意def build_features(df, weather_df, holidays): df df.sort_values(ts) # 日历特征 df[hour] df[ts].dt.hour df[weekday] df[ts].dt.weekday df[is_holiday] df[ts].dt.date.isin(holidays).astype(int) # 气象滞后特征 merged pd.merge_asof(df, weather_df, onts, directionbackward) merged[temp_diff] (merged[temperature] - 22).abs() # 滞后与相似日特征 for lag in [24, 168]: merged[flag_{lag}h] merged.groupby(point_id)[load].shift(lag) merged[similar_day_mean] ( merged.groupby([point_id, weekday, hour])[load] .transform(lambda x: x.rolling(7, min_periods1).mean()) ) return merged.dropna()4.3 评价指标陷阱MAPE好不代表真正可用做完第一版模型我们看了整体MAPE在3%以内觉得不错。后来调度同事一句话点醒了我“平均误差有什么用我要知道明天早高峰预测准不准、会不会有偏差我需要的是高峰时段准。”确实电力系统最关心的是峰值时段。早高峰和晚高峰的负荷预测如果偏小备用容量安排不足这是有直接安全影响的低谷时段预测偏大又会导致不必要的机组启停成本。所以我们又加了三个指标一起看峰时段最大绝对误差、晚高峰连续偏差方向、全天最大单点误差。这几个指标比总体MAPE更能反映业务风险。模型评估报告里我们会固定输出一张对比表包含不同时段、不同季节、不同天气类型下的表现。这样业务评审时能快速定位模型在什么场景下不可信。如果某个台风天气样本下误差明显放大就不应该硬扛而是要考虑切换保守策略。4.4 异常检测无监督算法加规则兜底才是可解释的除预测之外设备异常检测是电力AI的另一个刚需。纯无监督算法在电力场景有个问题它能在历史数据里发现离群点但很难告诉运维人员“为什么异常”。让运维人员接受一个深度自编码器检测出来的报警需要花费大量解释成本。我们采用的方案是“无监督初筛规则兜底”。自编码器或孤立森林先把可疑时间窗口筛出来然后进一层规则引擎做二次验证规则包括电气量越限、三相不平衡度超阈值、谐波含量异常、温度与负荷的比值偏离历史区间。只有同时命中无监督异常候选和至少一条规则才正式生成告警。这个机制上线后误报率大幅下降。因为规则是运维人员自己参与制定的他们天然信任这套输出。无监督模型负责发现未知模式规则负责让告警有据可依两者组合比任何单一算法都更适合电力行业的生产环境。5. 部署上线后的事三种形态、模型漂移与灰度运维模型训练完成只是系统工程的一半上线运维阶段才是真正拉开差距的地方。5.1 云、边、端三种部署形态怎么分工电力AI应用的部署形态天然是云边端协同而不是单一云平台。云端承担的是离线训练、全局优化、综合研判比如全区域负荷预测、网架薄弱环节分析。云端算力充足可以跑复杂模型但通信链路长不适合毫秒级响应。边缘侧按区域或变电站部署承担区域负荷预测、就地异常告警、数据清洗前置。边缘节点会缓存原始数据网络中断时也能独立运行一段时间。这部分对硬件要求是可靠性优先我们当时选的是工控机加双电源方案。终端侧主要是智能电表、在线监测装置这类就地设备运行的是轻量级诊断规则或极简模型。终端算力有限但胜在靠近数据源掉线不影响判断。注意终端上不要部署复杂深度学习模型特别在通信代价高、设备管理分散的场景规则引擎反而更健壮。5.2 模型漂移一个真实的风电场案例模型刚上线时效果很好过一段时间开始悄悄变差这种情况就叫模型漂移。我们遇到的一个典型场景是风电场出力预测。某天开始风电场夜间出力预测持续偏大整体MAPE从8%一路涨到15%。我们最初怀疑是气象源数据问题检查后发现气象预报和实测都在合理范围。后来是数据同事提醒查看场站运行日志才发现其中一排风机因为变流器故障持续限功率运行。历史训练数据里没有这个工况模型不知道“风机没在出力”这件事依然按风速对应出力的曲线预测自然偏大。这个案例给我们的教训是模型漂移不一定来自统计形态变化也可能是设备工况或业务规则变化。所以漂移监控里要同时跟踪“外部特征分布”和“关键事件日志”。我们后来建了一个事件字典把检修、故障、限电、停运等事件自动关联到模型效果波动上告警时直接给出事件线索处理效率提高很多。5.3 灰度上线与失败回退不能只有部署脚本电力系统的模型更新必须带灰度机制。我们每次新模型发布先在旁路跑评估只记录预测结果与真值的偏差不影响正式出口。旁路评估通过后再切少量业务流量试运行比如只对某几条线路生效。稳定运行一周后再全量切换。同时每个新版本都要保留上一版本模型至少一个月保证随时可回退。回退不是简单换文件还要回退对应的特征版本和告警阈值否则新旧特征口径不一致接口数据会乱。我建议把这套流程固化成发布清单每个操作项都有人确认而不是靠经验临时操作。5.4 与调度、营销系统对接的合规细节电力行业系统对接不只是技术问题。数据出不出域、谁能访问、接口调用的审计留痕、变更审批流程这些都是上线前就必须谈清楚的。我们在接口设计上坚持几个原则接口只读优先除非必要不开放写操作所有调用走服务网关统一鉴权禁止裸连数据库每次调用记录调用方、时间和返回规模审计日志至少保存半年批量导出必须走申请流程。这些规则看起来增加了工作量但能避免后期很多扯皮。特别是涉及负荷数据和用户用电信息流程不合规会导致整个系统被叫停不是危言耸听。最后按我的个人经验留个尾巴。做电力数据AI这个交叉领域最大的体会是“业务先行、数据为重、模型在后”。技术栈里每一层的选型都应该先回答一个业务问题这个数据要用在哪个决策环节错了会有什么代价。先找一个最小的闭环跑起来比如先盯住一条线路的负荷预测把采集、治理、训练、部署、监控整个链路走通一次再横向扩展。另一条建议是每套模型都要配齐“数据字典、特征清单、评估报告、回退方案”四件套几个月后回头看你会感谢当时的自己。