钢铁研习所

← 全部场景

scenario s3 / 短期 · 生产研发侧

排程调度副驾驶

把调度员的自然语言约束翻译成模型约束、调用求解器、解释方案差异、校验硬约束冲突

数据可得性

中高

所需数据是否已在手、能否直接用于建模

工程难度

中高

从可行性验证到稳定上线的工程风险

实时性要求

中高

需要秒级响应,还是天级出报告

评级为面向学习者的教学性判断,用于横向比较场景特点,不构成采购或投资建议。

涉及工序 / 6 道 · 高亮项点击可跳章节

烧结·球团·焦化
高炉炼铁
废钢准备
冷轧与深加工
检测与判定

业务痛点,讲人话

调度员每天要回答的问题是:接下来几个小时,哪一炉钢先炼、走哪条精炼路径、进哪台连铸机、按什么顺序轧。

约束多到令人窒息:

  • 浇次连续性——连铸一旦开浇,同一浇次的几炉钢必须连续供上,断浇代价极高
  • 钢种相容——同一浇次内钢种要相近,成分差太多会造成过渡坯报废
  • 交期——这炉钢要赶下午三点的船
  • 设备可用性——2 号精炼位在检修,钢包 7 号包龄到上限了
  • 温度窗口——钢水在钢包里一直在降温,等太久就得回炉重加热
  • 轧制批次规则——轧辊磨损要求同一批次的宽度只能由宽到窄

现实中这件事高度依赖老调度员的经验。而经验有三个问题:难以传承、班次之间不一致、没法在几十种方案里比较优劣

正确的分工:LLM 编排 + 求解器决策 + 人工确认

ai engineer's view

  • LLM 不做决策,做翻译和解释

    让 LLM 直接输出排程表,等于让它心算大规模整数规划——既算不准,也无法保证硬约束满足。决策仍在求解器手里。

  • 四项职责

    ① 把「这炉要赶下午的船」翻译成模型约束;② 调用求解器;③ 把结果讲成人话并对比上一版差异;④ 无解时诊断是哪几条约束互相矛盾。

  • 人在环 ≈ 发布审批闸门

    Agent 出方案,调度员确认后才下发。这既是安全要求(容错率低是这个行业第一属性),也是让现场愿意用的前提——责任边界留在人身上。

调度员(自然语言)
   │  「H2024-105 这炉要赶 15:00 的船,优先安排」
   ▼
[LLM] 意图解析 → 转成模型修改
   │  add_constraint: completion_time("H2024-105") <= 15:00
   │  objective += 1000 * tardiness("H2024-105")
   ▼
[求解器] MILP / CP  ← 硬约束库(浇次连续性、钢种相容、设备可用)
   │
   ├─ 有解 → [LLM] 解释:与上一版的差异、代价、受影响的其他炉次
   │            ▼
   │         调度员确认 → 下发 MES
   │
   └─ 无解 → [LLM] 冲突诊断:「15:00 交期 与 2 号连铸机检修窗口 冲突,
                 可选:① 改走 1 号机(+40 分钟)② 交期放宽到 16:30」

数据长什么样

data shape / 本场景吃哪几类数据

01生产过程时序process time-series行业普遍成熟度 ·

各工序工艺参数、L1/L2 控制信号、设备状态、振动与电流、能源计量读数

瓶颈:跨工序时空对齐;数据往往在客户/产线侧,取数是授权问题而非技术问题

06知识文本knowledge text行业普遍成熟度 ·

技术报告、专利、论文、操作规程、设备手册、检修工单、报警日志

瓶颈:非结构化、密级混杂、时效性标注缺失(哪版规程还有效?)

07机理与仿真mechanism models & simulation行业普遍成熟度 · 中高

冶金机理专业模型、CALPHAD 热力学与相图库、CFD/FEM 仿真结果、数字孪生生成数据

瓶颈:模型未工具化封装、没有统一调用接口——对 Agent 而言等于不存在

样例结构 / 教学示意,非真实产线数据

# 排程模型的输入(教学示意)
heats:                          # 待排炉次
- id: "H-2024-105"
  grade: "Q355B"
  weight_t: 210
  due: "2024-XX-XX 15:00"
  route: [BOF, LF, CC2]       # 可行工艺路径
  ready_at: "13:10"
#
casters:
- id: "CC2"
  width_mm: 1250
  sequence_id: "SEQ-88"       # 当前浇次
  sequence_grades: ["Q355B", "Q355C"]   # 浇次内允许的钢种
  maintenance: ["14:20", "15:00"]        # ★ 与上面的交期冲突
#
hard_constraints:
- "同一浇次内相邻炉次的钢种必须相容"
- "浇次一旦开始不可中断"
- "钢包温降 ≤ 阈值,否则需回 LF 加热"
- "同一时刻一台设备只能处理一个炉次"
#
soft_objectives:
- {name: "交期延误", weight: 1000}
- {name: "钢水等待时间", weight: 50}
- {name: "电费(分时电价)", weight: 20}

注意硬约束与软目标的分离:硬约束交给求解器保证,软目标才是可以权衡的。LLM 修改的应该是软目标权重和新增的软约束,不能动硬约束。

七类数据全景见第 7 章 →

必懂概念 / 7 张

ai engineer's view / 换成你熟悉的说法

  • 排程 ≈ 约束求解,不是生成

    LLM 不负责算出排程,它负责把「这炉钢要赶下午的船」翻译成求解器能吃的约束,再把求解结果讲给人听。决策仍在 CP/MILP 求解器手里。

  • 浇次 ≈ 不可中断的事务

    连铸一旦开浇,同一浇次的几炉钢必须连续供上,中断代价极高。这是排程里最硬的硬约束。

  • 人在环 ≈ 灰度发布的审批闸门

    行业普遍共识是短期不做端到端自动决策——Agent 出方案,调度员确认,责任边界留在人身上。

延伸学习

相关场景