大模型与启发式算法互补：高能耗企业能源优化新路径

高能耗企业的能源优化这件事，过去十几年基本是运筹学专家和工艺工程师的战场。线性规划、混合整数规划、遗传算法、粒子群、模拟退火，这些工具轮番上阵，效果也确实做出来了不少。但有个问题一直卡在中间：建模成本太高，场景迁移太慢。一个钢厂的高炉煤气系统调优模型，换到水泥窑炉上几乎要从头再来；一个电解铝的负荷调度方案，搬到多晶硅产线上，约束条件全变了，模型得推倒重写。这不是算法不够强，而是"人写规则"的速度跟不上"场景变化"的速度。

大模型进来之后，情况开始变得有意思了。它不是来替代启发式算法的，恰恰相反，它最有价值的地方是给传统优化算法当"副驾驶"——负责理解场景、生成候选结构、解释约束、动态调参，把原来需要专家花几周做的建模工作压缩到几小时。这就是标题里说的"互补算法"的核心含义：大模型负责语义层和策略层，启发式算法负责搜索层和收敛层，两者各干各擅长的事。

这篇文章面向的是做工业能源管理、综合能源系统优化、或者正在探索大模型落地工业场景的工程师和技术负责人。我会把这条路线拆开讲清楚：为什么传统方法会卡住、大模型具体补在哪个环节、互补架构怎么搭、实际跑起来会遇到什么坑、以及从哪些场景切入最容易出效果。不堆概念，讲能落地的东西。

1. 传统启发式算法在高能耗场景里到底卡在哪

1.1 建模周期长到场景等不起

高能耗企业的能源系统有个特点：拓扑结构复杂、约束条件多、工况变化频繁。一个典型的钢铁企业能源系统，涉及高炉煤气、焦炉煤气、转炉煤气、蒸汽、电力、氧氮氩等多种介质，每种介质有产、耗、储、转换四类节点，节点之间的耦合关系动辄上百条。用混合整数规划建模，光是变量定义和约束写全，一个有经验的运筹学工程师也要两到三周。

问题在于，能源系统的工况是动态的。季节变了、产线检修了、原料品位波动了，约束条件就得改。改一次模型，又是一轮建模-调试-验证的循环。很多企业做完一期优化项目之后，模型就慢慢废弃了，因为维护成本太高，没人愿意持续投入。

1.2 启发式算法的"参数敏感性"是个老大难

遗传算法、粒子群、蚁群这些启发式方法，本质上是在解空间里做随机搜索。搜索效果好不好的关键，很大程度上取决于参数设置：种群规模、交叉概率、变异概率、迭代次数、惯性权重。这些参数没有通用最优值，换一个场景就得重新调。

我见过一个案例，某水泥企业的窑炉温度优化用遗传算法，种群规模设200、交叉概率0.8、变异概率0.05，跑出来效果不错。后来同样的算法框架搬到另一条产线上，同样的参数，收敛速度慢了一半，解的质量也下降了。工程师花了两个月调参，才勉强达到可用水平。这两个月里，产线一直在用原来的经验规则运行，优化收益是零。

1.3 约束条件的"隐性知识"难以形式化

这是最要命的一点。高能耗企业的很多约束，不是写在图纸上的，而是老师傅脑子里的经验。比如"当高炉煤气柜位低于某个值时，优先保证热风炉用气，因为热风炉停了高炉就得休风，损失远大于其他用户"——这条规则，你在任何设计文档里都找不到，但它实实在在约束着调度决策。

传统建模方式要求把这些隐性知识全部显式化成数学约束，这个转化过程本身就损失了大量信息。而且不同老师傅的经验还不一样，到底听谁的，也是个问题。

1.4 多目标冲突下的决策僵化

能源优化从来不是单目标问题。成本要低、排放要少、设备寿命要长、供应可靠性要高，这几个目标之间是冲突的。传统做法是加权求和，把多目标变成单目标，然后调权重。但权重怎么定？定完了之后，不同工况下最优权重可能完全不同。

更麻烦的是，加权求和本质上是在帕累托前沿上找一个点，但很多实际决策需要的是一组可选方案，让调度员根据当前情况灵活选择。传统算法给不出这种"方案菜单"，只能给一个"最优解"。

2. 大模型补的到底是哪几个环节

2.1 场景理解与约束抽取：把自然语言变成数学表达

大模型最直接的价值，是把非结构化的场景描述转化成结构化的优化问题。你可以把设备手册、操作规程、历史调度日志、老师傅的口头经验整理成文本，喂给大模型，让它输出变量定义、目标函数、约束条件的初稿。

举个具体例子。你输入这样一段描述："1号高炉煤气柜的柜位要保持在20%到80%之间，低于20%时禁止向外供气，高于80%时优先向电厂供气。2号高炉煤气柜与1号通过连通管连接，连通管的最大流量是每小时5万立方米。"

大模型可以输出这样的结构化表达：

# 大模型抽取的约束条件示例 constraints = [ {"type": "range", "variable": "gas_holder_1_level", "min": 0.2, "max": 0.8}, {"type": "conditional", "condition": "gas_holder_1_level < 0.2", "action": "supply_to_grid_1 = 0"}, {"type": "conditional", "condition": "gas_holder_1_level > 0.8", "action": "supply_to_power_plant = max"}, {"type": "flow_limit", "variable": "pipe_flow_1_2", "max": 50000} ]

这个初稿肯定不完美，需要工程师审核修正。但比起从零开始写，效率提升是数量级的。原来两周的建模工作，可能压缩到两三天。

2.2 算法选型与参数推荐：从"试错"到"有依据的初猜"

大模型可以根据问题特征推荐合适的算法和初始参数。它的训练数据里包含了大量优化问题的求解经验，虽然它不一定能给出最优参数，但能给出一个远好于随机猜测的起点。

比如你告诉它："这是一个含整数变量和连续变量的混合优化问题，变量规模约500个，约束条件约800条，目标函数非线性，要求求解时间在10分钟以内。"

大模型可能会建议：先用遗传算法做全局搜索，种群规模设100-150，迭代500代左右，然后用序列二次规划做局部精调。这个建议不一定最优，但比默认参数强得多。工程师在此基础上微调，调参时间可以从两个月压缩到一周。

2.3 约束松弛与可行性修复：当问题无解时怎么办

实际优化问题经常遇到"无可行解"的情况。约束条件太紧，或者数据有矛盾，算法跑不出来。传统做法是人工逐条检查约束，看哪条可以放松。这个过程很痛苦，尤其是约束多的时候。

大模型可以辅助做约束冲突定位和松弛建议。你把约束条件和求解器的报错信息给它，它能分析出哪些约束之间可能存在冲突，建议优先松弛哪些。比如它可能告诉你："约束C12和C35在变量x的取值范围上存在矛盾，建议将C12的上限从100放宽到120，或者将C35的下限从50降低到40。"

这个能力在实际工程中非常实用，因为很多时候不是问题真的无解，而是建模时某个参数写错了或者单位搞混了。

2.4 多目标权重的动态调整：让权重跟着工况走

前面提到多目标加权求和的权重难定。大模型可以根据当前工况描述，动态推荐权重组合。比如：

• 当能源价格处于高峰时段，成本权重调高；
• 当环保指标接近上限时，排放权重调高；
• 当某台关键设备接近检修周期时，设备寿命权重调高。

这个逻辑用规则引擎也能实现，但规则引擎需要人工写规则，而大模型可以根据历史调度记录和当前工况描述，自动生成权重建议。它的优势在于能处理规则没覆盖到的边缘情况。

2.5 方案解释与决策支持：让调度员敢用优化结果

这一点经常被忽视，但极其重要。优化算法给出的解，调度员往往不敢直接用，因为不知道这个解是怎么来的，万一出了问题谁负责。大模型可以把优化结果翻译成自然语言解释："本次调度方案将1号气柜的供气量提高了15%，原因是预计未来两小时高炉煤气发生量将增加，提前储气可以避免放散。同时将3号机组的负荷降低了8%，因为当前电价处于低谷，降低发电量可以减少亏损。"

这种解释让调度员理解方案的逻辑，信任度会大幅提升。而且调度员可以根据自己的经验判断解释是否合理，形成人机协作的闭环。

3. 互补算法的架构怎么搭

3.1 整体分层设计

互补算法的架构可以分成四层，从下到上依次是：

这个分层的关键在于：大模型不直接参与数值计算。它负责的是语义理解、策略建议、结果解释这些"软"任务，数值求解还是交给传统算法。这样既发挥了大模型的能力，又避免了它在数值精度上的短板。

3.2 大模型与求解器的接口设计

大模型和求解器之间的接口，是整个架构的核心。接口设计得好不好，直接决定了系统能不能跑通。

我建议采用结构化中间表示作为接口。大模型输出的不是直接可执行的代码，而是一个结构化的JSON或YAML描述，然后由一个"编译器"模块把它翻译成求解器能识别的格式。

# 大模型输出的中间表示示例 problem: type: "mixed_integer_nonlinear" variables: - name: "gas_holder_1_level" type: "continuous" range: [0, 1] - name: "boiler_1_status" type: "binary" objective: sense: "minimize" expression: "0.6*cost + 0.3*emission + 0.1*equipment_wear" constraints: - "gas_holder_1_level >= 0.2" - "gas_holder_1_level <= 0.8" - "boiler_1_status * 100 <= boiler_1_output" solver_hint: algorithm: "genetic_algorithm" population_size: 120 max_iterations: 500

这样做的好处是：中间表示是可读、可审核、可修改的。工程师可以在大模型输出和实际求解之间加一道人工审核，确保约束条件没有遗漏或错误。而且中间表示与具体求解器解耦，换求解器只需要改编译器，不用改大模型的输出。

3.3 反馈闭环：让大模型从求解结果中学习

互补算法不是单向的"大模型给建议、求解器执行"，而应该是一个闭环。求解器跑完之后，把结果反馈给大模型，大模型根据结果调整下一轮的策略。

反馈信息包括：求解是否成功、求解时间、解的质量、哪些约束是紧的、哪些约束是松的。大模型根据这些信息，可以调整下一轮的算法参数建议。比如如果发现求解时间过长，可以建议减少种群规模或迭代次数；如果发现解的质量不够好，可以建议增加种群多样性。

这个闭环可以用少样本学习的方式实现：把历史求解记录作为示例，让大模型从中学习"什么样的参数配置适合什么样的场景"。

3.4 人机协作的审核节点

在实际部署中，不能完全让大模型自动决策。需要在关键节点设置人工审核：

• 约束抽取审核：大模型抽取的约束条件，必须由工艺工程师确认；
• 算法配置审核：大模型推荐的算法和参数，由运筹学工程师确认；
• 优化结果审核：最终调度方案，由调度员确认。

审核节点不是阻碍效率，而是建立信任。随着系统运行时间增长，审核可以逐步放宽，但初期必须严格。

4. 实际跑起来会遇到哪些坑

4.1 大模型的"幻觉"在约束抽取中很危险

大模型在抽取约束时，可能会"编造"一些原文没有的约束，或者遗漏一些关键约束。这在能源优化场景中是很危险的，因为一个错误的约束可能导致调度方案不可行，甚至引发安全事故。

我的经验是：大模型抽取的约束，必须逐条与原文对照。可以设计一个自动化的对照工具，把大模型输出的每条约束，反向翻译成自然语言，然后与原文做相似度匹配。相似度低于阈值的，标记出来人工重点审核。

另外，对于安全相关的约束（如设备压力上限、温度上限），建议不要依赖大模型抽取，而是从设备台账中直接读取，确保准确。

4.2 大模型的上下文长度限制

高能耗企业的能源系统描述可能非常长，设备手册、操作规程、历史日志加起来可能几十万字。大模型的上下文长度有限，不可能一次性全部输入。

解决方案是分层摘要+按需检索。先用大模型对文档做分层摘要，生成一个"场景知识库"。然后在具体优化任务中，根据任务描述检索相关的知识片段，只把相关片段输入大模型。这样既控制了输入长度，又保证了信息的针对性。

4.3 大模型输出格式不稳定

大模型的输出格式经常不稳定，同样的提示词，这次输出JSON，下次可能输出YAML，再下次可能输出一段自然语言。这对自动化流程是很大的挑战。

解决办法有两个：一是用结构化输出约束，在调用大模型时指定输出格式，很多大模型API支持JSON mode；二是加一层格式解析和修复，用规则或小模型把输出统一成标准格式。我通常两个都用，先约束，再修复，双保险。

4.4 求解器与大模型的"语言不通"

大模型输出的约束表达式，语法上可能正确，但语义上求解器不认。比如大模型可能写"gas_holder_level between 0.2 and 0.8"，但求解器需要的是"gas_holder_level >= 0.2"和"gas_holder_level <= 0.8"两条约束。

这个问题需要在编译器模块中处理。编译器要能识别常见的表达方式，并转换成求解器标准格式。对于无法识别的表达，要给出明确的错误提示，而不是静默失败。

4.5 实时性要求与推理延迟的矛盾

能源优化有些场景是实时性的，比如分钟级的负荷调度。大模型的推理延迟通常在秒级到十秒级，对于实时场景可能不够快。

我的建议是分场景处理：对于实时性要求高的场景，大模型只做离线的策略预生成，实际运行时用规则引擎快速匹配；对于实时性要求不高的场景（如日前调度、周度检修计划），大模型可以参与在线决策。

5. 从哪些场景切入最容易出效果

5.1 场景选择的原则

不是所有能源优化场景都适合用大模型+互补算法。选择切入场景时，我建议考虑三个维度：

• 建模复杂度高：传统方法建模成本高的场景，大模型的优势更明显；
• 场景变化频繁：工况经常变化、需要频繁调整模型的场景，大模型的价值更大；
• 容错空间较大：优化结果即使不是最优，也不会造成严重后果的场景，适合先试点。

5.2 推荐切入场景

根据我的经验，以下几个场景比较适合作为切入点：

场景一：多能源介质的日前调度。钢铁、化工企业通常有多种能源介质，日前调度需要综合考虑次日生产计划、能源价格、设备状态等因素。这个场景建模复杂、变化频繁，但容错空间较大（日前计划可以在日内调整），适合大模型介入。

场景二：设备检修计划优化。检修计划涉及多台设备的协调，约束条件多（检修窗口、备件供应、人员安排），目标也多（检修成本、对生产的影响、设备可靠性）。这个场景传统方法建模很痛苦，大模型可以大幅降低建模成本。

场景三：异常工况下的应急调度。当某台设备故障或某条产线停运时，需要快速生成应急调度方案。这个场景时间紧、约束变化大，传统方法来不及重新建模，大模型的快速场景理解能力正好派上用场。

5.3 不建议一开始就碰的场景

实时闭环控制不建议一开始就做。实时控制对延迟和可靠性要求极高，大模型的推理延迟和输出稳定性还达不到要求。建议先从"人机协作"的场景做起，等系统稳定了再考虑闭环。

安全关键场景也不建议一开始就做。涉及人身安全或重大设备安全的优化，必须保证万无一失，大模型目前还不足以承担这个责任。

6. 几个实操层面的经验

6.1 提示词工程在能源优化中的特殊技巧

能源优化场景的提示词，和通用场景不太一样。我总结了几条经验：

第一，用"角色+任务+约束+示例"的四段式结构。角色设定为"能源系统优化专家"，任务描述要具体，约束条件要明确列出，示例要包含输入输出对。

第二，把领域知识嵌入提示词。比如告诉大模型"高炉煤气柜的柜位低于20%时禁止外供"，这比让它自己推理要可靠得多。

第三，要求大模型输出"推理过程"。让它在给出约束条件之前，先解释为什么这么抽取。这样即使结果有误，也能从推理过程中找到问题。

第四，用少样本示例引导格式。给两三个输入输出示例，大模型的输出格式会稳定很多。

6.2 大模型选型的考量

不是所有大模型都适合这个任务。我的经验是：

• 通用大模型（如GPT系列、Claude系列）在语义理解和推理上表现好，但成本和数据安全是需要考虑的问题；
• 开源大模型（如Llama系列、Qwen系列）可以私有化部署，数据安全有保障，但在复杂推理上可能稍弱；
• 领域微调模型如果有能源领域的微调数据，效果会更好，但微调成本高。

实际选型时，我建议先用通用大模型做原型验证，跑通流程后再考虑私有化部署。原型阶段用API调用，快速迭代；生产阶段根据数据安全要求选择部署方式。

6.3 效果评估的指标设计

怎么判断互补算法到底有没有效果？我建议从三个维度评估：

第三个指标最容易被忽视，但最重要。如果调度员不愿意用，再好的算法也是白搭。

6.4 团队配置建议

做这个方向，团队需要三类人：

• 能源工艺工程师：负责提供场景知识、审核约束条件；
• 运筹优化工程师：负责算法选型、求解器配置、结果验证；
• AI工程师：负责大模型调用、提示词工程、系统集成。

三类人缺一不可。我见过一些团队只有AI工程师，结果做出来的东西工艺上不可行；也见过只有工艺工程师的团队，做出来的东西技术上跑不通。

7. 关于未来的一点个人判断

我在这个方向摸索了一段时间，有一个越来越强烈的感受：大模型在工业优化中的角色，不是替代传统算法，而是降低传统算法的使用门槛。过去只有大企业的专家团队才能玩得转的优化技术，现在中小企业的工程师也能用起来了。这个"普惠化"的价值，可能比优化效果本身还要大。

另一个感受是，互补算法的关键不在算法本身，而在工程化。大模型调用、格式解析、求解器集成、人工审核、反馈闭环，这些工程细节决定了系统能不能真正跑起来。很多demo很漂亮但落地失败的案例，问题都出在工程化上。

如果你正在考虑这个方向，我的建议是：从小场景做起，先跑通一个完整的闭环，再逐步扩展。不要一上来就追求大而全，那样很容易陷入"什么都能做但什么都做不好"的困境。选一个建模痛苦、变化频繁、容错空间大的场景，把大模型+启发式算法的互补流程跑通，积累经验后再复制到其他场景。这个路径虽然慢，但稳。