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 / 本场景吃哪几类数据
各工序工艺参数、L1/L2 控制信号、设备状态、振动与电流、能源计量读数
瓶颈:跨工序时空对齐;数据往往在客户/产线侧,取数是授权问题而非技术问题
技术报告、专利、论文、操作规程、设备手册、检修工单、报警日志
瓶颈:非结构化、密级混杂、时效性标注缺失(哪版规程还有效?)
冶金机理专业模型、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 张
ai engineer's view / 换成你熟悉的说法
排程 ≈ 约束求解,不是生成
LLM 不负责算出排程,它负责把「这炉钢要赶下午的船」翻译成求解器能吃的约束,再把求解结果讲给人听。决策仍在 CP/MILP 求解器手里。
浇次 ≈ 不可中断的事务
连铸一旦开浇,同一浇次的几炉钢必须连续供上,中断代价极高。这是排程里最硬的硬约束。
人在环 ≈ 灰度发布的审批闸门
行业普遍共识是短期不做端到端自动决策——Agent 出方案,调度员确认,责任边界留在人身上。
延伸学习
相关场景