★ FEATURED ARTICLE 1. 能耗管理这件事为什么现在绕不开大模型做能耗管理有些年头的人都有一个共同感受数据从来不缺缺的是把数据变成决策的那一层。楼宇自控系统里躺着几千个测点工厂配电柜后面挂着几十块电表园区里光伏、储能、充电桩各有一套平台可真正到了要回答“这个月电费为什么涨了”“哪台设备在偷偷吃电”“下个调度周期该怎么排产”的时候还是得靠人盯着曲线一条条翻。传统能耗管理平台做的是采集、存储、报表三件事本质上是个记账系统它告诉你花了多少但不告诉你接下来该怎么办。AI大模型切入这个场景解决的正是“从记账到参谋”的跨越。这里说的大模型应用不是把通用对话模型接进来聊两句就完事而是围绕能耗领域的数据特征构建一套能理解时序数据、能关联多源信息、能输出可执行策略的技术链路。它要做的事情很具体把非结构化的运维工单、设备手册、天气预警和结构化的电表读数、负荷曲线放在同一个语义空间里做推理最终给出“几点开几号冷水机组、负荷率控制在多少、预计省多少电”这样的答案。这套东西适合谁来参考我梳理了一下大致三类人用得上。第一类是园区、工厂、商业综合体的能源管理负责人关心的是怎么在不增加人力的情况下把能耗降下来第二类是做智慧能源平台的开发和实施团队需要知道大模型在哪个环节接、怎么接、接完效果怎么评估第三类是对时序数据加语言模型融合感兴趣的技术人员想看看这套组合拳在真实工业场景里到底怎么落地。下面我按自己实际参与过的一个园区级能耗优化项目为主线把设计思路、技术细节、实操过程和踩过的坑完整拆一遍。2. 整体方案设计与技术选型拆解2.1 为什么不是“一个大模型包打天下”刚接触这个方向的时候最容易犯的错就是想着找一个参数量足够大的模型把能耗数据一股脑喂进去让它出策略。实测下来这条路走不通原因有三个。第一能耗数据是典型的高频时序数据十五分钟一个采样点一个中等园区一年就是几十万条记录直接塞进上下文窗口既不经济也不现实。第二通用大模型对数值的敏感度远低于对文本的敏感度你给它一条负荷曲线它很难像专业时序模型那样捕捉到爬坡速率、峰谷差这些关键特征。第三能耗策略是有硬约束的比如冷水机组不能频繁启停、变压器负载率有上限这些约束必须用规则引擎兜底不能指望模型“记住”。所以实际采用的架构是分层解耦的底层是数据接入与清洗层中间是特征工程与时序预测层上层才是大模型负责的语义理解、多源关联和策略生成层最外面套一层规则校验与执行反馈。大模型在这里的角色更像一个“懂业务的调度参谋”它不直接处理原始读数而是处理经过特征提取后的结构化摘要、运维文本和预测结果然后做综合推理。这个分工是我试过几种方案后定下来的后面会详细说每种方案的问题。2.2 三层架构的具体职责划分把架构拆开看第一层数据层负责把电表、水表、气表、环境传感器、设备状态信号统一接入做时间对齐和异常值处理。这一层的关键不是采集本身而是时间戳对齐——不同厂商的设备时钟漂移能到几十秒不对齐的话后面做负荷分解全是错的。第二层特征层做两件事一是用轻量时序模型比如梯度提升树或者小型时序网络做短期负荷预测和异常检测二是把原始数据压缩成“时段摘要”比如每小时的均值、峰值、爬坡次数、与昨日同时段偏差这些摘要才是喂给大模型的原料。第三层策略层由大模型主导输入是时段摘要、预测结果、当前工况文本描述、电价时段信息和约束条件输出是调度建议和解释。这个划分的好处是每一层都可以独立迭代。时序模型换算法不影响上层提示词设计大模型换版本也不影响底层数据管道。我见过一些团队把预测和策略揉在一个端到端模型里调参调到最后根本不知道是数据问题还是模型问题排查成本极高。2.3 模型选型开源中等规模模型加领域微调选型上我们试过三条路。第一条是直接用闭源大模型的接口优点是开箱即用缺点是能耗数据涉及园区运行细节走外部接口有数据合规顾虑而且高频调用成本扛不住。第二条是用超大开源模型本地部署效果确实好但推理延迟和显存占用在边缘侧根本落不了地。第三条是中等规模开源模型做领域微调这也是最终采用的方案。具体来说选一个七十亿参数级别的开源模型做基座用园区历史运维记录、设备手册问答对、调度策略文本做指令微调。微调数据大概准备了八千多条其中调度建议类占一半故障归因类占三成能效诊断类占两成。微调方式用的是低秩适配在单卡上跑十几个小时就能完成一轮迭代成本可控。实测下来微调后的模型在“给定工况描述推荐运行策略”这个任务上人工评估可用率从基座的不到四成提升到七成以上这个提升幅度对于辅助决策场景已经够用了。提示微调数据里一定要包含“反例”也就是错误的调度建议以及为什么错。只给正例的模型容易过度自信遇到边界工况时给出的建议看着合理实则违规。2.4 规则引擎为什么必须保留有人会问既然大模型能出策略规则引擎是不是多余了。恰恰相反规则引擎是这套系统的安全底线。我们把设备启停间隔、负载率上下限、峰谷时段禁操作项这些硬约束写成规则大模型输出的策略先过规则校验不通过的直接拦截并回传原因让模型重新生成。这个机制救过好几次场有一次模型建议在电价尖峰时段启动大功率设备做蓄冷逻辑上是为了避开后面更高的峰段但违反了设备最小启停间隔约束规则引擎直接拦下并提示了替代时段。规则引擎还有一个作用是给模型提供“约束上下文”。我们把规则以自然语言形式写进提示词比如“三号冷水机组两次启动间隔不得少于三十分钟”模型在生成时就会主动规避减少被拦截的概率。这个细节后面在提示词设计部分还会展开。3. 核心细节解析与实操要点3.1 数据清洗里最容易被低估的三个坑能耗数据清洗听起来是脏活累活但它直接决定上层模型的天花板。第一个坑是电表倍率问题。很多配电柜的电表读数要乘互感器倍率才是真实电量不同回路倍率不同有的实施方图省事统一按一个倍率算结果负荷分解全乱。我们的做法是给每个测点建一张元数据表记录倍率、量程、安装位置、所属回路清洗时按元数据换算绝不拍脑袋。第二个坑是缺失值的填充策略。能耗数据缺失不能简单用前值填充因为设备停机导致的零值和通信中断导致的缺失是两回事。我们的处理逻辑是先看同一回路上下游测点是否有读数如果有且变化平稳判定为通信缺失用插值补如果上下游都无读数且设备状态信号显示停机判定为真实零值保留。这个区分不做后面异常检测会疯狂误报。第三个坑是时间对齐的粒度选择。原始数据是十五分钟粒度但做负荷预测和策略生成时我们聚合到小时粒度。为什么因为十五分钟粒度噪声太大模型容易被单点波动带偏而小时粒度既能反映趋势又足够平滑。聚合时不是简单取平均而是同时保留均值、最大值和爬坡次数三个统计量这三个量对判断设备运行状态缺一不可。3.2 特征摘要的构造方法喂给大模型的时段摘要怎么构造直接决定模型能不能“看懂”当前工况。我们设计的摘要模板包含几个固定字段时段标识、总用电量、峰谷平各段电量占比、同比环比偏差、最大负荷出现时刻、负荷率均值、主要设备运行状态列表、异常事件标记。每个字段都用自然语言短句表达比如“本时段总用电量较昨日同时段上升百分之十二主要增量来自二号车间空调系统”。这里有个关键技巧数值要同时给绝对值和相对值。只给绝对值模型没有参照系只给相对值模型不知道量级。比如“最大负荷一千二百千瓦较昨日峰值高百分之八”就比单说一个数有用得多。另外异常事件标记要带上简要归因比如“三号空压机于十四时二十分触发高温报警持续十八分钟”这样模型在生成策略时会把设备状态考虑进去。摘要的长度控制在三百字以内太长了模型注意力分散太短了信息不够。我们做过对比三百字左右的摘要配合结构化字段模型输出的策略相关性明显好于纯文本长描述。3.3 提示词工程在能耗场景的特殊写法能耗场景的提示词和通用问答完全不是一回事核心区别在于约束多、参照系多、输出格式要求严。我们的系统提示词分四块角色定义、当前工况、约束条件、输出格式。角色定义不是简单说“你是能源专家”而是明确“你是一名园区能源调度员负责在满足设备安全约束的前提下最小化用电成本你的建议将经过规则校验后执行”。约束条件部分要把硬规则用自然语言复述一遍同时给出优先级。比如“设备安全约束优先于成本约束当两者冲突时以保证设备安全为准”。这个优先级声明很重要实测能显著降低模型给出“冒险型”建议的概率。输出格式我们强制要求结构化包含建议动作、执行时段、预期效果、风险提示四个字段。强制结构化不是为了好看而是为了后续程序解析和规则校验。早期我们让模型自由输出结果解析代码写了一堆正则还是经常挂改成强制格式后解析成功率接近百分之百。注意提示词里不要放太多示例三到五个足够。示例太多会挤占上下文空间而且模型容易机械模仿示例里的具体数值换一个园区就失灵。3.4 微调数据的构造与配比经验微调数据质量比数量重要得多。我们第一批数据是从历史工单和调度记录里扒出来的大概两千条直接拿去微调效果很差因为原始记录太口语化且信息不全。后来重新构造每条数据包含三部分工况描述就是前面说的时段摘要、约束条件、期望输出结构化的调度建议加解释。构造方式是先由业务专家写两百条高质量种子数据再用基座模型批量生成候选人工筛选修正后扩充到八千条。配比上有个经验值调度建议类占五成故障归因类占三成能效诊断类占两成。故障归因类不能少因为实际运行中模型经常需要回答“为什么这个时段能耗偏高”这类任务考验的是多源关联能力。能效诊断类主要是设备对标比如“同类型冷水机组在相似工况下哪台效率偏低”这类数据帮助模型建立横向比较的意识。还有一个细节训练数据里要刻意加入一些“信息不足时应该追问”的样本。比如工况描述里缺少某台关键设备状态时期望输出应该是“当前信息不足以给出完整建议请补充几号设备运行状态”而不是硬编一个策略。这个习惯养成了线上运行时模型胡说八道的概率会低很多。4. 实操过程与核心环节实现4.1 从数据接入到摘要生成的完整链路实操第一步是打通数据源。我们面对的是一个园区里面有楼宇自控系统、配电监控系统、光伏逆变器监控、储能管理系统四套独立平台。接入方式上楼宇自控走协议网关转成统一消息格式配电监控直接读数据库视图光伏和储能走各自提供的接口定时拉取。所有数据落到一个时序库按测点建索引。第二步是跑清洗管道。清洗管道用任务编排工具串起来顺序是时钟对齐、倍率换算、缺失值分类处理、异常值标记、小时粒度聚合。这里有个实操细节时钟对齐不是简单按接收时间戳而是以配电监控系统的主时钟为基准其他系统按偏差做平移。偏差值每天校准一次因为设备时钟会漂。第三步是摘要生成。摘要生成是个定时任务每小时跑一次读取上一小时聚合数据套模板生成自然语言摘要同时调用时序预测模型拿到未来四小时的负荷预测一起写入摘要记录。摘要记录同时存两份一份结构化字段存数据库供程序用一份自然语言文本存文档库供检索和喂模型用。整个链路跑通后从数据产生到摘要可用延迟控制在五分钟以内对于小时级调度场景完全够用。4.2 策略生成与规则校验的闭环策略生成环节的触发方式有两种定时触发和事件触发。定时触发是每个调度周期开始前半小时自动跑一次生成下一周期的建议策略。事件触发是异常检测模块发现负荷突增、设备报警或者电价时段切换时即时触发。生成流程是这样的取当前摘要和预测结果拼装提示词调用微调后的模型拿到结构化输出先做格式校验再做规则校验。规则校验分硬约束和软约束硬约束不通过直接打回重生成软约束不通过则在建议里附加警告但不拦截。重生成最多两次两次都不过就降级到规则引擎的默认策略同时记录一条人工复核任务。校验通过的建议推送到执行端。执行端不是全自动的我们保留了人工确认环节调度员在界面上看到建议、预期效果和风险提示确认后才下发到控制系统。这个设计是刻意的一方面积累人工反馈用于后续迭代另一方面避免模型在没见过的工况下做出危险动作。运行三个月后人工确认率从最初的六成提升到九成以上说明模型建议的可靠性在稳步提升。4.3 效果评估的指标体系效果评估不能只看省了多少钱那样太粗。我们建了一套三层指标。第一层是策略层指标包括建议采纳率、规则拦截率、重生成率这三个反映模型输出质量。第二层是运行层指标包括峰谷电量比、负荷率均值、设备启停次数这三个反映执行效果。第三层是经济层指标包括单位面积电费、需量电费占比、综合能耗成本这三个反映最终收益。评估周期上策略层指标每天看运行层指标每周看经济层指标每月看。为什么要分周期因为经济指标受电价政策、天气、生产计划影响大日度波动说明不了问题月度趋势才有参考价值。我们跑了半年单位面积电费下降约百分之九需量电费占比下降约五个百分点设备启停次数没有明显增加说明优化没有以牺牲设备寿命为代价。这里要提醒一句评估基线要选对。我们用的是去年同期加天气修正的基线而不是简单用上个月。能耗受季节影响太大拿夏天和春天比没有意义。4.4 一个完整的调度建议实例拿一个实际生成的建议来说明整个链路怎么运转。某日夏季午后摘要显示总用电量较昨日同时段上升百分之十五主要增量来自空调系统最大负荷出现在十四时十分负荷率均值百分之八十二三号冷水机组运行中四号备用光伏出力因云层遮挡较预测低百分之二十电价处于平段一小时后进入尖峰段。模型输出的建议是建议在十五时前将四号冷水机组投入运行与三号机组并联运行至尖峰段结束期间三号机组负荷率控制在百分之七十五左右四号控制在百分之七十左右建议将蓄冷罐放冷速率提高至中档优先保障尖峰段前段供冷风险提示为四号机组上次维护距今超过建议周期长时间并联运行需关注其振动和出水温度。这条建议过了硬约束校验启停间隔满足、负载率在范围内软约束提示了维护周期问题调度员确认后执行。事后复盘尖峰段需量没有创新高空调系统用电较未优化情景低约百分之十一。这个例子说明模型的价值不在于给出多复杂的策略而在于它能把天气、设备状态、电价时段、维护记录这些分散信息串起来给出一个有时序、有主次、有风险提示的完整方案。5. 常见问题与排查技巧实录5.1 模型建议“看着合理但执行不了”怎么破这是上线初期最高频的问题。表现是模型给出的建议逻辑通顺但执行端反馈设备不支持或者工况不允许。排查下来原因主要有三类。第一类是模型不知道某些设备的实际调节能力比如建议某台水泵调频到百分之六十但那台泵根本没有变频器。解决办法是在提示词的约束条件里补充设备能力清单把每台可控设备的调节范围写清楚。第二类是模型对时间粒度的理解有偏差比如建议“在十五时到十六时之间逐步降低负荷”但实际控制系统只支持整点设定。解决办法是在输出格式里强制要求时段必须是整点并在提示词里说明控制系统的设定粒度。第三类是模型忽略了隐性约束比如某台设备虽然参数上支持连续运行但实际因为散热条件限制需要间歇停机。这类约束很难穷举我们的做法是建立“隐性约束库”每次人工复核发现一条就补一条定期同步到提示词里。这个库现在积累了四十多条拦截率明显下降。5.2 负荷预测偏差大导致策略失准怎么办策略失准很多时候根子不在模型而在预测环节。我们遇到过连续一周预测偏差超过百分之十五的情况排查发现是园区新入驻了一家用户用电规律和历史数据完全不同而预测模型没有及时纳入新数据。解决办法是给预测模型加了一个在线更新机制每周用最近四周数据做增量训练同时监控预测偏差偏差连续三天超过阈值就触发告警并人工介入。还有一个常见原因是天气数据源的问题。我们早期用的天气接口更新频率低午后对流天气预测不准导致空调负荷预测偏差大。后来换成更新频率更高的数据源并且把实时气象观测数据也纳入特征偏差明显收窄。这个经验说明能耗预测这件事外部数据的时效性和内部数据同样重要。5.3 常见问题速查表问题现象可能原因排查动作解决方向建议频繁被规则拦截约束条件未写入提示词或表述模糊检查提示词约束段落对比拦截原因补充约束描述明确优先级模型输出格式解析失败输出格式约束不够强硬查看原始输出确认偏离点强化格式要求增加格式示例同时段建议前后矛盾摘要信息不足或存在歧义回溯摘要生成记录补充摘要字段消除歧义表述能耗下降但设备报警增多优化策略过于激进检查设备运行参数历史收紧软约束增加设备状态权重新接入设备建议质量差微调数据未覆盖该类设备检查训练数据设备类型分布补充该类设备的样本数据策略生成延迟高提示词过长或模型负载高统计提示词长度和推理耗时精简摘要错峰生成5.4 几条踩坑换来的实操心得第一条心得不要追求全自动。我们一开始想着模型出策略直接下发省掉人工确认环节结果第一个月就出了两次设备异常启停。后来老老实实加回人工确认反而因为有了人工反馈模型迭代速度更快了。辅助决策和自动控制之间有一条很清晰的线跨过去之前先问问自己能不能承担后果。第二条心得摘要模板要版本化管理。我们改过好几次摘要模板每次改完模型表现都会波动但因为没有版本记录排查时根本不知道是模板问题还是模型问题。后来给模板加了版本号每次变更记录变更内容和影响评估排查效率高了很多。第三条心得微调不是一劳永逸。园区用电结构会变设备会增减季节会轮转模型需要定期用新数据做增量微调。我们的节奏是每季度一次小版本微调每年一次大版本重构训练数据。这个节奏是根据实际效果衰减曲线定的供参考。第四条心得规则引擎的报错信息要写清楚。早期规则拦截只返回“违反约束”模型重生成时根本不知道错在哪反复犯同样的错。后来把拦截原因写成自然语言回传比如“建议启动时刻距上次停机仅十二分钟低于三十分钟最小间隔”模型第二次生成基本就能改对。这个改动很小但重生成成功率提升了一倍多。6. 这套方案还能往哪延伸跑通园区场景之后我们把这套架构往两个方向做了延伸尝试。一个是多园区横向对标把不同园区的摘要放在一起让模型做比较分析找出能效洼地。这个方向的关键是摘要字段要统一否则模型没法比。另一个是跟生产排程联动把电价时段和负荷预测结果喂给排程系统让高耗能工序主动避峰。这个方向难度大一些因为涉及生产约束但初步试下来模型给出的避峰建议有参考价值。我个人在实际操作中的体会是大模型在能耗管理里的价值不在于替代传统能源管理系统而在于补上“解释”和“建议”这两块短板。传统系统告诉你发生了什么大模型告诉你为什么发生、接下来怎么办、有什么风险。把这两者接好能耗管理才算真正从记账走向了参谋。至于模型选多大、微调数据怎么配、提示词怎么写这些细节没有标准答案得根据自己场景的数据特点和约束条件一点点磨。磨的过程中记住一条规则兜底、人工把关、持续迭代这三条守住了效果差不到哪去。
阅读完成 · 觉得有帮助？
