大模型设计互补算法：高能耗企业能源优化的新路径

过去几年，高能耗企业的能源优化基本被两件事卡住：一是现场数据太脏、工况太复杂，传统机理模型建不准；二是算法工程师懂优化但不了解工艺，工艺专家懂现场但写不出可用的数学模型。我见过不少团队在这上面反复折腾，最后要么回到人工经验调度，要么上一套看起来很智能、实际上只在报告里智能的优化系统。直到有朋友尝试了一种新玩法：让大模型去设计互补算法，而不是逼着大模型直接替掉原有优化引擎。

这个思路听起来反直觉。很多人以为大模型进入工业节能，就该是“我问它怎么省电，它给我一套方案”。真这么干，大概率会被现场工程师喷回去。互补算法的核心是分工，不是替代。大模型负责生成那些传统算法难写、难维护、难解释的部分，比如把现场老师傅的模糊经验转成结构化约束、把复杂工况下的调度策略拆成可执行片段、把目标函数和约束条件翻译成代码或配置。原来的优化内核、控制闭环、设备接口继续保留，大模型只做“设计”和“辅助生成”，生成的结果还要经过校验和仿真才能进系统。这篇文章就把这条路线怎么落地、有哪些坑、哪些环节必须自己扛，讲清楚。适合正在做能源管理平台、工厂调度优化、双碳数字化的团队参考。

1. 高能耗企业的能源优化为什么难在这里

1.1 老问题：模型不准、约束太多、边界波动大

高能耗企业，尤其是钢铁、水泥、化工、造纸这类流程工业，能源系统往往是多介质耦合的。电、蒸汽、压缩空气、循环水、天然气，各系统之间还有转化关系。水泥窑的余热发电、化工装置的热集成、钢铁厂的高炉煤气柜平衡，这些都是典型的非线性、多约束、强耦合问题。

传统做法分两派。机理派喜欢搭机理模型，把设备特性曲线、物料平衡、能量平衡全写进去，理想情况下很准。问题是一旦工况偏移，比如原料批次变化、环境温度变化、设备老化，模型参数就得重新标定。标定一次少则两周，多则两个月，现场根本等不起。数据派则靠历史数据训练回归或机器学习模型，预测能耗趋势还行，但一到约束处理就露馅。设备有启停顺序、负荷有爬坡率、煤气管网有压力上下限，这些约束用纯数据模型不好表达，强行塞进神经网络里又会牺牲可解释性。现场工程师不信任黑盒，数据派方案往往死在信任这一关。

1.2 大模型真正能补的不是预测，而是“建模与生成”

我第一次听到“让大模型做能源优化”，第一反应也是，这东西哪敢让大模型直接控制设备。后来团队拆解了一下实际工作流，发现真正耗人精力、容易出错的环节不是算法本身，而是三个前置动作：把业务规则转成数学表达、把工况模式转成算法分支、把策略逻辑转成可维护的代码或配置。

这三个动作恰恰是大模型的强项。大模型擅长从自然语言里抽取结构化信息，擅长把模糊规则翻译成伪代码，也擅长根据给定模板补全逻辑细节。于是我们调整了定位：大模型不是优化器，是优化算法设计师，同时是现场经验与数学模型之间的翻译官。这个定位一改，整个技术路线就顺了。

2. “互补算法”的设计思路拆解

2.1 什么叫互补算法：机理底座加数据驱动再加LLM生成层

互补算法不是指某一种特定算法，而是一种算法组织方式。我在项目里习惯把它拆成三层。

底座是机理模型和传统优化内核，比如线性规划、混合整数规划、模型预测控制或者动态规划。这一层负责数值求解和跟控制系统对接。中间是数据驱动层，负责从历史数据中辨识工况、修正机理模型参数、预测未来一段时间的负荷和产出。最上层是大模型生成层，负责把业务约束、工艺规则、评审意见转换成可执行的算法片段、配置项和约束表达式。

三层之间不是串行流程，而是反馈关系。数据驱动层发现模型偏差，会标记异常工况并触发大模型重新生成修正建议；大模型生成的调度逻辑要先经过仿真验证，验证结果再反馈给生成层做迭代。这种结构的好处是，传统优化算法依然是系统内核，大模型只在边界处发力，不会引入不可控的黑盒风险。

2.2 互补闭环的三个环节：翻译、生成、校验

互补算法落地时，我习惯把它压缩成三个环节。

第一个环节叫翻译。把业务人员的话变成算法工程师能用的东西。比如现场工程师说，“后半夜谷电的时候，尽量把原水处理往上提，但别让清水池溢出，同时注意水泵不能频繁启停”。这句话里有目标、有约束、有段位限制。大模型要把它转成目标函数中的分时电价系数、约束条件中的液位上下限、以及启停惩罚项。这个翻译过程最难的是歧义处理。“尽量”到底是多尽量？“频繁”是指一小时几次？这些需要细化追问，靠一次性提示词很难做好，得设计多轮追问模板。

第二个环节叫生成。生成不是让大模型随手写一段代码，而是给固定的模板和槽位，让模型填充具体内容。比如我给模型一个“设备调度策略生成器”的模板，里面包含设备类型、调度周期、目标函数、约束条件、默认参数这几个槽位，模型只负责根据输入场景填槽。这样一来，生成结果天然是结构化、可解析的。

第三个环节叫校验。所有生成内容必须过三关：语法解析、规则校验、仿真回测。语法解析保证代码或配置能运行；规则校验保证不触碰硬性约束，比如安全联锁、环保限值；仿真回测用历史数据和离线模拟器验证效果，至少要达到人工基线水平的90%以上，才允许进入候选池。校验这一关做得越重，后面上线越省心。

2.3 关键选择：为什么优先考虑私有化部署而不是调用公开API

能源数据的特点是敏感、分散、不允许出园区。高能耗企业的能源管理数据往往和执行层生产数据绑在一起，谁也不敢把产线负荷、设备状态、工艺参数传到外部接口去。所以在大模型部署形态上，项目优先选择私有化部署。

行业中成熟的路径是用开源底座模型，配上推理框架自己架服务。比如底座用Qwen或Llama这一级别，推理层用Ollama或vLLM，再在外面包一层权限管理和审计日志。对能源优化这类场景，模型参数量并不需要冲到千亿级，70亿到140亿量级通常已经够用，关键是让上下文窗口覆盖得足够长，把调度周期内所有规则一次性塞进去。私有化部署的额外收益是可重复性，同一个提示词、同一个模型版本，产出结果稳定，出了问题也好回溯，这在工业现场是保命的需求。

3. 落地路线图：从数据到算法再到上线

3.1 第一步：把能源数据和工艺数据先做成干净的时间序列

不用怀疑，这个环节至少要占整个项目40%以上的工作量。能源优化场景里最常见的悲剧是，算法模型还没开始调参，数据质量先崩了。仪表掉线、通信中断、历史库乱序、时区不统一，每一条都能让训练集变成笑话。

数据治理的第一件事是时间对齐。电力数据可能是秒级或分钟级采样，蒸汽流量可能是分钟级，生产计划可能是小时级，错位是常态。我们做法是建立统一的时间基准，做重采样和插值，并在数据表里保留一个质量标记字段，记录每条数据的来源和可信度。第二件事是工况切片。不同工况下能耗关系完全不同，比如说正常生产、低负荷保温、停机检修、启炉升负荷，必须打标签分开建模，绝不能混在一起训练。

第三件事是参数补齐。很多能耗异常其实是因为缺了关键解释变量，比如环境温度、物料水份、设备运行时长，这些参数平时没人关注，但模型推理时非常敏感。补齐这些参数往往需要查DCS历史库点表，费时费力，但这一步做扎实了，后面模型精度能上一个台阶。

3.2 第二步：场景选型，从小闭环而不是全厂开花

高能耗企业能源系统盘根错节，一上来就想做全厂级优化，十有八九要烂尾。我见过一个项目，最开始规划做全厂蒸汽系统、压缩空气系统、电力需量控制三个模块，结果做了半年连数据接口都没打通。后来把范围砍到只做压缩空气系统，两周上线，一个月看到节电率，才慢慢把团队信心攒起来。

选场景有几个标准。第一，数据基础好，现场仪表齐全且有历史数据。第二，能耗占比高或者电费结构复杂，有明确的优化空间。第三，控制自由度适中，至少有2到3台设备可以调节，但又不至于让搜索空间爆炸。第四，安全风险低，调错了不会导致停产或质量事故。我比较推荐先从余热回收、循环水系统、空压机群控这类场景切入，收益见效快，风险也在可控范围。

3.3 第三步：给大模型搭一套面向能源优化的提示词工作台

这一步是整个路线里最有操作性的部分，也是网上少有人写清楚的部分。直接给大模型一句“帮我优化空压机群控策略”，模型给出来的东西大概率是通用套话，没法用。需要搭一个面向能源调度场景的提示词工作台，把业务知识转成模型能稳定执行的任务。

我提供一个简化版模板，真实项目里会在外面再套一层用户权限和版本管理：

[角色] 你是工业能源系统专家，熟悉压缩空气系统群控策略。 [输入] 设备清单：空压机A（额定功率250kW，变频）、空压机B（额定功率200kW，工频） 负荷曲线：未来8小时用气量预测序列 运行约束：单台空压机最小加载率不低于40%；每台设备连续运行不超过12小时 目标：综合电费最低 [任务] 1. 给出每个小时的设备启停组合建议。 2. 生成调度约束方程，使用LINGO或Python MIP语法表达。 3. 列出需要重点监控的安全边界参数。 4. 指出人工经验中可能的反直觉点。 [输出格式] 表格列出启停组合，JSON格式输出约束方程，附录说明安全边界。

用这个模板跑出来的结果，专业度和稳定度都远超自由提问。需要注意的是，模板里的设备参数、约束条件必须真实具体，模型才能给出可用的结果。条件模糊时模型会臆造，这是大模型在专业场景最大的坑，后面我会专门讲怎么防。

3.4 第四步：仿真回测与在线部署的灰度节奏

生成出来的算法或配置不能直接接进控制系统。我们的流程是先做离线仿真，用过去半年的历史数据做回测，比较优化策略和历史人工策略的能耗差异。仿真通过后，进入影子模式，也就是系统只算不动，给调度员展示“如果按这个策略操作，现在应该怎么调”，让调度员在界面上对比判断。影子模式跑2到4周，收集足够多的可信度和效果数据后，才进入半自动模式，先对风险最低的设备下发建议，人工确认后执行。最终再过渡到闭环自动控制。

这套灰度节奏看上去比一步到位慢，但省下来的是现场信任和时间成本。能源优化项目的常态是胜率看长期，一旦因为一次误操作坏了口碑，后面想再推任何算法都会被打上“不靠谱”的标签。

4. 我在项目里踩过的坑和总结出来的独门技巧

4.1 大模型生成的内容必须过“语法加库存”双重校验

早期测试时，我们让大模型生成一段混合整数规划的约束表达式，它看着写得有模有样，实际一编译直接报错，变量名不匹配、索引越界、单位没换算，各种幺蛾子都有。后来我们总结出一套双重校验机制。

第一重是语法校验，代码用编译器过一遍，配置用JSON Schema校验一遍，保证至少能跑起来。第二重是库存校验，我把单位映射表、设备能力参数、安全约束限值做成一个“规则底库”，生成内容里涉及到的每个设备和参数，都去底库核对一遍。比如模型写了一个“空压机A加载率下限40%”，但底库实际记录是35%，就必须标记异常。这个底库是项目最核心的知识资产，它比模型本身值钱得多，需要持续维护。

4.2 幻觉不是靠提示词解决，是靠强制纠偏机制

很多人说大模型有幻觉，问怎么设计提示词避免幻觉。做了几个能源项目后，我的结论是提示词只能缓解，不能根治。真正要依赖的是强制纠偏机制。

强制纠偏有两种做法。一种是在输出阶段做结构约束，要求模型严格按照给定JSON Schema输出，字段类型、枚举值、取值范围全部预设好，模型想乱编都没地方插进去。另一种是在输入阶段做信息约束，把设备参数、工艺限值直接拼接在提示词里，不让模型从训练记忆里猜测参数，它只能引用我们给的上下文。这两种方法一组合，幻觉概率能大幅下降，剩下的违规项交给规则校验兜底。

4.3 时间同步问题能把一个优秀策略活活憋死

有个项目出现过很诡异的现象：仿真效果很好，一上线效果就腰斩。后来排查发现，调度建议是按某时点能耗数据算的，但数据采集链路有时延，控制系统执行时用的却是20分钟前的信息，等于一直在给过去做优化。这个问题的根子不在算法，在数据管道。

解决办法是在实时数据库侧引入统一的时延标签，每个数据点除了时间戳之外，还要记录采集时延。推荐控制器做优化计算时，只采用时延低于阈值的输入，并且输出策略要带“建议执行时间窗”，超过时间窗则自动作废。很多算法团队忽略这个细节，会误把工程问题当成算法能力不足，白测好几周。

4.4 指标设不对，优化就会变成负优化

做能源优化最容易犯的错误是把“能耗最小”当唯一目标。实际上对高能耗企业来说，能耗最小不等于能源成本最小，更不等于系统最安全。有个月度项目为了追节电率，把空压机加载率压得过低，结果管网压力波动加大，下游气动阀门动作频次上升，产线废品率悄悄增加了0.3个百分点，节下的电费还不够赔的。

我们后来把所有优化目标都改成综合成本口径，把电费、设备损耗、产量质量损失、环保排放成本全部折算成统一货币单位，再在这个口径下做优化。这么做得到的结果，不一定是最省电的，但一定是经营上最划算的。这个理念需要在项目一开始就跟企业管理层对齐，否则算法团队很容易被KPI绑架，做出看似漂亮、实际添乱的结果。

5. 常见问题速查与选型参考

5.1 模型底座选多大、用哪个，别迷信参数

先给一个适合能源优化场景的选型基准参考：

能源优化场景通常不建议一上来就追求最大模型。模型大了推理慢、部署贵、维保难，收益往往不明显。更重要的是把知识底库、提示词模板、校验规则这套周边设施建好，模型本身只是其中一个执行单元。

5.2 私有化部署还是API调用，怎么权衡

一个相对稳妥的判断标准：只要数据会关系和工艺运行状态，优先私有化，哪怕答案API更成熟。理由不只是泄密风险，还有连续性与可解释性，私有化部署的模型版本固定、参数不变，出了问题可以完全复现。云端API模型频繁更新，上一周能稳定输出的提示词，这周可能行为就变了，这对工业项目是致命伤。

如果确实想做云端API验证思路，我建议先跑通流程再切私有化，注意选那些承诺数据不留存的商用接口，同时做好数据脱敏。脱敏方案至少要做到，设备编号、厂区名称、工况描述里的敏感字段全部替换成通用编号。

5.3 效果验证的参照系怎么定

能源优化项目最怕没有基线。上线前一天就应该摸清历史能耗水平，用过去12个月的电费单和能源管理报表做归一化处理，消除产量和天气因素影响后，作为对比基线。我建议效果报告里同时列出三个参照：优化周期与去年同期对比、优化前后同工况对比、影子模式建议值与实际人工决策对比。

顺便说一句，很多项目验收时只展示“节省比例”，这个数字容易被动手脚。比如碰上暖冬，采暖能耗自然下降，系统顺水推舟记成自己的功劳。行业里真正讲规矩的团队，都会先做等多因素修正，再谈优化收益，这也是投资方能持续信任的关键。

5.4 大模型和优化算法工程师怎么配合不打架

团队配合上有个常见矛盾：算法工程师觉得大模型生成的东西不够精炼，不够优雅。这个问题本质是用错了分工。传统算法工程师应该负责设计底座优化内核、校验规则、仿真体系，大模型负责的是把业务经验批量转化为算法可用的素材，两者之间是上下游关系，不是竞争关系。如果团队里有资深优化工程师愿意把精力花在打磨规则底库和校验逻辑上，项目稳定性会明显提升，因为大模型的生成质量上限，往往取决于输入知识的结构化程度。

6. 几条掏心窝的建议：动手之前先看清

如果只让我给一条最有用的建议，那就是从小场景做起，建立完整闭环，再扩大范围。能源优化这个领域，技术瓶颈早就不是算法本身，而是数据和工程化能力。大模型设计互补算法最大的吸引力，在于它能把过去被卡在沟通和理解环节的生产力释放出来，让工艺专家和算法工程师之间的翻译成本大幅下降。但这一切的前提是，你有一个干净的、可回溯的、被校验过的知识底座。

我也必须提醒，大模型不是这个方案里最复杂的技术单元。真正复杂的是，你敢不敢让模型生成的内容进入仿真、进入影子模式、最终进入控制闭环。每一步都考验工程纪律。我见过太多团队在Demo阶段惊艳全场，一到影子模式就被现场专家挑出一堆之前没考虑的边界情况，死在最后一公里。务实的做法是，把每次模型生成的内容都当作文档和人共同评审的初稿，而不是最终答案。

这个方向后续可以往两个地方延伸。一是把设备的CBM预测模型接进来，让互补算法同时考虑设备健康状态，从单纯能耗优化扩展成用能设备全生命周期优化。二是把调度策略生成的结果做成可解释的知识卡片，让每一套优化策略都能回溯到具体业务规则和现场经验，这样老师傅退休了，经验也留在了系统里。这些当年想都不敢想的事情，现在确实是拿一台本地部署的开源模型就能干起来的。