工业控制系统这行有个特点就是稳字当头。一个PLC程序跑在现场可能十年都不带改的因为每一次改动都意味着停机风险、产线波动、甚至安全事故。所以当大模型这波浪潮涌过来的时候工控圈的反应明显比互联网圈慢半拍——不是不想用是不敢乱用。但这几年情况在变我身边不少做DCS、SCADA、工业AI检测的朋友已经开始把大模型往产线里塞了有的做设备日志分析有的做工艺参数问答还有的做视觉质检的语义理解。这篇就结合我自己的观察和实操把人工智能大模型在工业控制系统中到底能干什么、现在干到什么程度、坑在哪里、往后怎么走这几件事聊透。1. 工业控制系统到底需要大模型解决什么问题1.1 传统工控系统的能力天花板在哪要理解大模型为什么会被引入工控得先搞清楚传统工控系统的能力边界。一套典型的工业控制系统核心是PLC、DCS、SCADA这几层底层负责实时采集和执行上层负责监控和组态。这套体系经过几十年打磨在确定性控制上已经非常成熟——PID调节、逻辑联锁、顺序控制这些活儿它干得比任何AI都稳。但问题出在非确定性的场景上。我举个实际例子一条化工产线上有几百个测点温度、压力、流量、液位每秒都在产生数据。传统SCADA只能做阈值报警超过设定值就响铃。可实际操作中很多异常是组合式的——A点温度略高、B点流量略低、C点压力波动单独看都在正常范围合在一起就是事故前兆。这种多变量耦合的隐性异常靠人工写规则根本写不完靠传统统计方法又容易误报。再比如设备维护。一台大型压缩机振动频谱、油液分析、温度趋势数据维度多到吓人。老师傅能凭经验听声音判断轴承状态但这种经验没法复制人一退休就断了。传统做法是建专家系统可专家系统的规则库维护成本极高工况一变就得重写。还有一类是人机交互的问题。现场操作员遇到报警得翻手册、查历史、问班长一套流程下来十几分钟。如果有个系统能用自然语言回答这个报警上次是怎么处理的效率能提升一大截。这些恰恰是大模型擅长的地方——它不是替代PLC做实时控制而是补上传统工控在语义理解、知识沉淀、多模态分析上的短板。1.2 大模型切入工控的三个真实需求点我把目前看到的落地需求归成三类这三类也基本对应了热词里工业AI检测大模型部署多模态大模型这些方向。第一类是工业知识问答与辅助决策。工厂里沉淀了大量非结构化知识——操作规程、事故案例、维修记录、工艺卡片。这些文档散落在各个系统里检索靠关键词找不全还找不准。大模型做RAG检索增强生成之后操作员用大白话提问系统能精准定位到相关段落并给出综合回答。我见过一个案例某电厂把十年的检修报告喂给本地部署的模型新员工问3号机组上次大修换了哪些密封件几秒钟就出结果以前得翻半天档案。第二类是多模态质检与异常识别。这就是热词里工业AI检测、服装检测那类场景。传统视觉质检用CNN做分类能判断合格/不合格但说不出为什么不合格。多模态大模型能结合图像和文本输出边缘毛刺长度约0.3mm超出标准0.1mm这种带语义的描述。更关键的是它可以用少量样本做微调换一个新产品线不用重新标注几万张图。第三类是工艺参数优化与预测性维护。这类场景对实时性要求高通常不是大模型直接输出控制量而是大模型做策略建议再由传统控制器执行。比如注塑成型大模型根据历史批次数据建议下一模的保压时间和温度曲线操作员确认后下发。这样既利用了模型的泛化能力又保留了人的最终决策权安全边界清晰。1.3 为什么不是上大模型就完事这里必须泼一盆冷水。工控场景和大模型的原生场景对话、写作、代码有本质差异。工控要求确定性、实时性、可解释性而大模型天生是概率性、高延迟、黑盒的。这三个矛盾不解决硬上就是灾难。我见过一个反面案例有人把大模型直接接到报警系统让它判断是否停机。结果模型因为训练数据里正常样本多把一次真实的轴承过热判成了正常波动差点酿成事故。后来改成模型只做建议最终停机指令还是由规则引擎和人工确认才稳下来。所以正确的定位是大模型在工控里是副驾驶不是主驾驶。它负责理解、归纳、建议实时控制回路还是交给PLC和DCS。这个边界想清楚了后面的技术选型和部署方案才不会跑偏。2. 大模型在工控场景落地的四种典型形态2.1 本地化部署为什么工控圈几乎不碰公有云API热词里本地部署大模型让个人电脑智能化ollama部署大模型大模型本地部署配置这些搜索量很高放到工控场景本地化不是可选项是必选项。原因很直接工厂的生产数据涉及工艺配方、产能、客户订单很多属于企业核心机密。把数据传到公有云API合规上过不去网络延迟也受不了。工控现场的网络往往是隔离的外网访问本身就不允许。所以工控大模型基本都走本地部署路线。本地部署的硬件选型有个经验公式。以7B参数模型为例FP16精度需要约14GB显存INT8量化后约7GBINT4量化后约4GB。如果要做RAG检索还得留出向量库和上下文缓存的空间。我一般建议模型规模量化方式最低显存推荐显存适用场景7BINT46GB12GB单点问答、日志分析7BINT810GB16GB多轮对话、文档理解13BINT410GB16GB复杂工艺推理32BINT420GB32GB多模态质检70BINT440GB48GB全厂知识中枢注意这是推理显存训练或微调要翻好几倍。工控现场通常用工业级GPU或边缘计算盒子消费级显卡不是不能用但7x24小时运行的稳定性要打问号。我实测过同样的模型在服务器卡上跑一个月不重启没问题在消费卡上跑一周就可能因为散热或驱动问题掉线。部署工具方面ollama适合快速验证一条命令就能拉起模型但它对并发和权限控制弱适合POC阶段。生产环境我更推荐vLLM或TGI这类推理框架支持连续批处理吞吐量能提升好几倍。如果现场是Windows工控机LM Studio这类带界面的工具对运维人员更友好。2.2 微调还是RAG工控知识注入的两条路热词里大模型微调实战大模型微调技术大模型学习路线这些词很热但工控场景到底该微调还是该用RAG很多人搞混。我的判断标准很简单知识是事实性的还是风格性的。如果是要让模型知道3号锅炉的设计压力是16MPa这种事实用RAG把文档切片存向量库提问时检索出来塞进上下文。如果是要让模型学会用我们厂的术语体系写检修报告这种风格才需要微调。工控场景90%的需求是事实性知识所以RAG是主力。RAG的好处是知识更新快——工艺改了改文档就行不用重新训练。而且RAG有引用来源操作员能看到答案出自哪份文件可解释性强这在工控里太重要了。微调在工控里的典型用途是领域术语对齐和输出格式约束。比如让模型输出结构化的报警处理建议固定包含现象、原因、处置、预防四个字段。这种用LoRA微调几百条样本就能见效。但要注意微调后的模型容易灾难性遗忘通用能力会下降所以通常是基座模型RAG轻量微调组合使用。实操上RAG的切片策略很关键。工控文档有大量表格和流程图按固定字数切会切断语义。我的做法是按文档结构切——操作规程按章节切检修报告按设备切报警列表按报警码切。切片后加元数据设备号、文档类型、生效日期检索时可以先按元数据过滤再做向量匹配准确率提升明显。2.3 多模态在质检环节的落地细节热词里像工业ai检测、服装检测这类ai用的是云联网还是单机的ai用的什么大模型足够这个问题问得很实在。我的答案是质检场景优先单机部署模型选7B到13B的多模态版本就够不必追大。为什么质检的节拍通常很快一条产线每分钟过几十个工件如果每个工件都要传云端推理网络延迟就受不了。而且质检图像往往包含产品外观细节也涉及保密。单机部署用边缘盒子推理延迟能压到几百毫秒。模型选择上多模态大模型做质检有两种用法。一种是端到端图像直接输入模型输出合格/不合格原因。这种对模型能力要求高适合缺陷类型复杂、样本少的场景。另一种是传统CV大模型语义层先用轻量CNN做初筛把可疑样本交给大模型做精细判断和描述。这种组合在产线上更稳因为CNN速度快大模型只处理少量疑难样本。我踩过的一个坑是直接用通用多模态模型做质检它对工业缺陷的尺度感很差。比如划痕0.1mm和0.5mm在模型眼里可能差不多。解决办法是用带尺寸标注的样本做微调或者在prompt里明确给出参照物。另一个坑是光照变化同一批产品在不同班次的光照下模型判断会漂移。所以质检工位的光源必须做标准化这个投入不能省。2.4 边缘计算与云边协同的架构取舍工控大模型的部署架构我见过三种纯边缘、纯云、云边协同。纯边缘适合单点场景比如一台设备配一个盒子数据不出厂。纯云适合集团级的知识管理多个工厂共享知识库。云边协同是趋势边缘做实时推理云端做模型更新和知识沉淀。云边协同的关键是模型版本管理。边缘盒子上的模型不能随便更新得经过测试验证。我的做法是建一个灰度发布流程新模型先在一条产线上跑一周对比准确率和误报率达标了再推全厂。这个流程听起来麻烦但工控场景经不起模型半夜自动更新导致全线误判这种事。网络架构上边缘和云端之间通常走工厂内网不直接连公网。数据同步用消息队列异步传输避免影响生产网络。如果工厂有多个厂区可以在每个厂区设一个边缘节点节点之间通过专线同步知识库这样既保证实时性又保证知识一致性。3. 落地过程中真正会卡住你的几个坑3.1 数据质量工控数据的脏超出想象做互联网AI的人转到工控第一个跟头往往栽在数据上。互联网数据虽然乱但量大总能筛出可用的。工控数据是量小且脏——测点命名不规范有的叫T101有的叫温度1有的叫TI-101单位不统一摄氏华氏混用时间戳对不齐不同系统时钟差几秒还有大量缺失和异常值。我做过一个项目光数据清洗就花了整个项目一半的时间。具体做了几件事建测点字典把不同命名映射到统一编码做单位归一化全部转成国际单位做时间对齐以PLC时钟为基准其他系统做偏移校正做异常值标记用3σ和箱线图结合但标记后不直接删而是让工艺人员确认是真实异常还是传感器故障。这里有个经验工控数据清洗不能全自动。因为很多异常其实是真实工况比如开停车阶段的参数剧烈波动自动清洗会把它当噪声删掉结果模型学不到开停车逻辑。所以清洗流程里必须有人工确认环节尤其是边界样本。3.2 实时性与模型延迟的矛盾工控的实时性要求分几档安全联锁是毫秒级过程控制是秒级优化建议是分钟级。大模型能插手的只有分钟级这一档。但即便是分钟级模型推理延迟也得控制住。我实测过7B模型INT4量化后在边缘盒子上单次推理约1-2秒加上RAG检索和上下文组装端到端3-5秒。这个延迟对于操作员提问场景可以接受对于自动生成优化建议就偏慢。优化手段有几个用更小的模型做初筛复杂问题再调大模型把常用问答缓存起来命中缓存直接返回用流式输出让操作员先看到部分结果。还有一个容易被忽略的点模型加载时间。冷启动加载一个7B模型要几十秒如果现场是间歇性使用每次都要等加载就很烦。解决办法是让模型常驻内存或者用支持快速切换的推理框架。这个在POC阶段不明显上生产就暴露了。3.3 幻觉问题在工控里的致命性大模型的幻觉在聊天场景是说错话在工控场景可能是出事故。我见过模型把关闭阀门说成打开阀门虽然只是建议但操作员如果没仔细看就执行后果严重。防幻觉的手段我总结了几条。第一RAG必须带引用答案里标注来源文档和页码操作员能核对。第二关键操作加确认涉及开关、启停、参数修改的建议必须二次确认且确认界面要突出显示操作方向。第三设置拒答机制检索不到相关内容时模型要明确说未找到依据而不是编一个答案。第四输出结构化把自由文本改成填槽式减少自由发挥空间。还有一个技巧是用规则引擎兜底。模型输出的建议先过一遍规则引擎如果和硬性安全规则冲突比如建议超过设备额定压力直接拦截。这层兜底不复杂但能挡住大部分低级错误。3.4 现场人员不信任技术之外的最大障碍这个坑不是技术坑但比技术坑更难填。老师傅对AI的态度往往是它懂什么我干了三十年。如果模型第一次给出的建议就是错的后面再想推就难了。我的经验是从小场景切入先建立信任。别一上来就搞全厂智能决策先从报警历史查询这种低风险、高频率的场景做起。操作员发现查历史快了慢慢就愿意试更复杂的功能。另外让老师傅参与知识库建设把他们脑子里的经验变成文档喂给模型他们会觉得这系统里有我的东西接受度完全不一样。界面设计也很重要。模型输出不要用AI建议这种标签用参考信息更中性。置信度低的建议要明确标注别让操作员误以为都是高可信的。我见过一个系统把所有建议都标成高置信结果错了一次之后操作员再也不看了。4. 从当前实践看未来的几个走向4.1 专用小模型会比通用大模型更早普及现在大家都在追大参数但工控场景我判断会走专用小模型路线。原因很简单工控任务边界清晰不需要模型会写诗、会聊天只需要它懂某类设备、某类工艺。一个针对注塑机优化的3B模型可能比通用70B模型在注塑场景表现更好而且延迟低、成本低、可解释性强。这个趋势在视觉质检已经显现了。通用多模态模型做质检准确率往往不如针对特定缺陷微调的小模型。未来工控领域会出现一批设备专用模型就像现在的专用芯片一样按需选型。4.2 大模型与机理模型的融合纯数据驱动的大模型在工控有个先天缺陷不懂物理规律。它可能建议一个在数据上合理、但违反热力学定律的参数。所以下一步一定是大模型机理模型的融合。具体形式可能是机理模型负责计算物理约束边界大模型在这个边界内做优化建议。比如锅炉燃烧优化机理模型算出空燃比的安全范围大模型根据历史数据和当前工况在这个范围内推荐具体值。这样既有数据驱动的灵活性又有物理规律的安全性。4.3 工控大模型的评测标准会独立出来现在评测大模型用MMLU、C-Eval这些通用榜单但工控场景需要自己的评测集。我期待看到的是包含真实工控问答、故障诊断、参数优化任务的评测基准而且要有安全违规率这个指标——模型输出违反安全规程的比例。这个评测集的建设需要工控企业和AI团队一起做。单靠AI团队不懂工控单靠工控企业不懂评测方法。谁先把这个标准建起来谁在工控大模型落地时就更有话语权。4.4 人才缺口在懂工控的AI人热词里人工智能训练师职业画像ai coding工程师属人工智能工程师吗这些搜索反映的是人才焦虑。工控大模型落地最缺的不是纯AI人才也不是纯工控人才而是两边都懂一点的复合型人才。这种人得知道PLC怎么编程也得知道Transformer怎么回事得能看懂工艺流程图也得能调prompt。培养这种人靠学校课程不够得靠项目实战。我建议想入行的朋友先在一个具体工控场景里扎下去把数据、模型、部署全流程走一遍比看十篇综述都有用。5. 给准备入场的团队几条实操建议5.1 第一个项目怎么选别选最难的也别选最没价值的。我的建议是选**高频、低风险、有明确验收标准**的场景。比如设备日志的智能检索操作员每天都要查查错了也就是多翻一次手册验收标准可以是检索准确率和平均查询时间。避免选安全联锁这种高风险场景也避免选全厂优化这种边界模糊的场景。第一个项目的目标是跑通流程、建立信任、积累数据不是一步到位解决所有问题。5.2 硬件投入的节奏别一上来就买顶配GPU服务器。先用现有设备或租用算力做POC验证场景价值。POC通过后再根据实际并发量和模型规模采购。我见过太多团队先买了几十万的卡结果场景没跑通设备吃灰。边缘部署的话工业级边缘盒子比消费级主机贵但稳定性好。如果现场环境恶劣高温、粉尘、振动这个钱不能省。如果只是办公室环境做验证普通主机加一张中端卡就够。5.3 团队配置的最小可行方案一个工控大模型项目最小团队配置是三个人一个懂工控业务的能定义需求和验收标准一个懂AI的能做RAG和微调一个懂部署运维的能搞定现场环境和网络。三个人里至少有一个要能横跨两个领域否则沟通成本会吃掉项目进度。如果团队里没有懂工控的建议先找业务专家做顾问别自己猜需求。工控场景的需求往往和表面看到的不一样比如操作员说想要智能报警实际需求可能是报警太多了想减少误报这两个方向的解决方案完全不同。5.4 上线后的持续运营大模型上线不是终点是起点。上线后要持续做几件事收集bad case定期更新知识库监控模型输出质量根据现场反馈调整prompt和检索策略。我建议建一个模型运营日志记录每次模型出错的情况、原因、修复方式。这个日志积累几个月就是团队最宝贵的资产。另外模型版本要管理好每次更新都要有回滚方案别出现新模型上线后效果变差但回不去的情况。工控这行讲究慢就是快大模型落地也一样。别追热点别堆参数把一个场景做深做透比铺十个半成品强。我在现场看到真正跑得好的系统往往不是技术最先进的而是最贴合操作员习惯、最稳定、最可解释的。这个道理放在大模型时代依然成立。