报警降99.8%、自控率98%：工业AI究竟能解决哪些问题？
1. 报警降99.8%：先搞清楚AI替控制室挡掉了哪类脏活
如果你在化工、冶炼、电力这类连续型流程行业待过，大概率见过这种场面：凌晨两点，DCS（集散控制系统）操作站上报警条像瀑布一样往下滚，操作员条件反射地按确认键，一晚上手都按酸了，但真正值得处理的那条报警，反而被淹没在几百条无效信息里。这就是行业里说的“报警洪峰”或“报警泛滥”——不是设备坏得太多，而是报警系统本身不会区分轻重缓急。
工业AI解决的第一个真问题，就是把这堆报警条理顺，让该响的响、不该响的自动消声。我记得有个项目是给某精细化工装置做报警治理，改造前单班报警量在3000条上下，操作员基本处于“报警响就随手确认”的麻木状态，联锁动作又不敢随便摘，整天提心吊胆。我们接入异常检测模型之后，核心业务报警收敛到个位数，单班有效报警从3000条降到个位数。这个变化不是靠屏蔽报警权限实现的，而是让AI干了三件事：
第一件事是报警归因。很多报警其实是一个根因引发的连锁反应，比如冷却水泵转速波动，会同时触发流量低报、压力波动报、出口温度高报，一个原因搅出四五条报警。传统DCS只能按测点独立判断，但AI模型把测点间的关系学出来了，知道哪些报警是同一个源头，直接打包成一条“根因报警”，其余降级为关联提示。
第二件事是报警预测。基于时序模型对关键工艺参数做前向预测，模型发现趋势异常后提前几分钟推送预警，操作员有充足时间去调整，等到联锁触发时反而是预测失灵的情况了。预测报警覆盖了原来“事后报警”的空档，真正做到了控制在前。
第三件事是报警分级。不是所有报警都需要操作员立刻干预，AI会根据当前工况、故障影响范围和可处理时间，把报警分成“立即响应、5分钟内处理、巡检确认、仅记录”四档。车间主任打开报警台账一眼就能看到今天哪些是关键报警、处理状态如何，而不是面对一千多条报警看谁都像大事。
说白了，报警降掉99.8%不是AI把报警删了，而是AI在中间当了一个“智能接线员”，把真正需要人管的少数问题挑出来摆到你面前。这背后涉及的是工况识别、异常检测、因果推断这三种技术能力的综合使用，单一模型很难同时做好，所以在工程上通常不要把报警治理寄托在“一个大模型包圆”上面，而是拆成多个小模型、多个算法模块协同完成。
2. 自控率98%是怎么打出来的：AI介入回路控制的正确姿势
自控率这个概念，在离散制造业里可能大家比较陌生，但在流程行业它是衡量自动化水平最硬核的指标之一。通俗讲，自控率就是生产装置在自动控制模式下稳定运行的时间占比。普通PID回路能跑出85%到90%的自控率已经不错了，很多装置长期依赖操作员手动干预，甚至有的老师傅凭经验手动调阀，自控率只有60%，加班多不说，产品质量波动还大。
把自控率从85%推到98%，靠的是工业AI里一个核心技术方向——先进过程控制（APC）和模型预测控制（MPC）。说人话就是：AI建了一个装置的虚拟模型，这个模型根据当前工况和未来一段时间的趋势，提前计算出一套最优控制参数，然后去设定PID回路的目标值，让底层PID去执行。底层的PID还是原来的PID，但上面多了一个“会算账的大脑”。
有一次我们做合成装置的优化项目，原料组分波动特别大，原来的串级回路经常因为进料变化引起温度失控，操作员只能频繁切换手动。我们用历史数据训练了一个基于梯度提升树的稳态模型，再用MPC做动态优化，核心逻辑其实就三步：
一是预测。模型基于最近两个小时的进料流量、组分、反应器温度等十几个变量，预测未来30分钟反应器出口温度曲线。
二是优化。在给定安全边界和产品质量目标的前提下，求解一个优化问题，找出一组最佳的进料流量设定值和加热炉负荷设定值。这一步用的是在线求解器，通常几秒钟就能出结果。
三是执行。把算出来的设定值下发给底层PID回路，PID按照新的目标去调阀门开度。整个链路是闭环的，不用操作员手工输入，系统每三到五分钟自动滚动计算一次。
用这个方案跑了一个月，自控率从82%提升到98%，更直观的收益是蒸汽单耗降了3%左右，产品合格率提高了1.2%。过程中也有翻车的时候——刚开始模型在进料组分突变时预测偏差偏大，我们给优化求解器加了“预测误差修正项”，也就是实时对比模型预测值和实际值之差，把这个残差反馈到下一次优化里，相当于让模型不断校准自己，这才稳下来。
这里要特别提醒想做同类项目的朋友：98%自控率不是靠AI模型单打独斗冲出来的。我总结了一个比例，大概是“设备基础40%、工艺优化30%、AI控制30%”。如果现场的调节阀动作迟滞、仪表漂移严重，AI算得再好执行不到位也是白搭。所以真正的工业AI项目，前期往往有大量的仪表校验、阀门检修工作要做，别把这部分工作量低估了，否则后面上线阶段会很痛苦。
另外，自控率指标本身也会玩文字游戏。有的项目把自动模式时间直接除以日历时间，这样算出来的自控率会虚高，因为停车检修期间哪里来的自控率呢？专业的算法要先把装置的运行状态识别出来，只在“可控制状态”下统计自动控制时长，这样98%才是有含金量的98%。我们做项目汇报时都会附上自控率计算口径说明，避免甲方后续审计时扯皮。
3. 工业检测面临的实际选型问题：端侧推理还是云上大模型，模型多大才算够
不少人听说工业AI，第一反应就是想到衣服布匹检测、零件表面缺陷检测这类视觉应用，然后就会问：这些跑在云上还是本地？是不是得上大模型？这两个问题，其实踩中了很多工厂做智能化改造时最容易纠结的环节。
先给个明确结论：大多数在线检测场景必须跑在本地，也就是边缘侧，云上只适合做模型训练和离线分析。核心原因有三个：
一是实时性。流水线速度稍微快一点，比如每分钟检测几百米布匹，相机拍一张图，系统要用几十毫秒给判定结果，如果拍照后把图传到云端、等模型算完再传回来，一张图往返几百毫秒，产线早就堆成山了。就算5G网络再快，也扛不住连续大图传输的带宽压力。
二是可靠性。产线检测如果突然断网，云上推理就彻底停摆，本地推理不受网络影响，断网也能继续跑。这在工厂环境中是硬需求，很多车间网络环境并没那么干净。
三是数据主权。有些工厂的工艺参数、产品照片涉及配方或设计细节，对方根本不愿意把图传到第三方云平台，本地部署是商务层面谈得拢的前提。
那本地端侧推理到底该用什么模型？这才是真正考验工程师判断力的地方。很多人被“大模型”三个字唬住了，一上来就想上最前沿的视觉大模型，结果部署起来发现GPU根本带不动，一张显卡几十万，推理延迟还压不下来，最后项目直接黄了。
按照我自己的经验，工业视觉检测的模型选型分三档：
第一档是简单缺陷识别，比如织物表面破洞、脏污、色差这类特征明确的缺陷，用传统图像处理加轻量级分类模型就够了，例如YOLO系列目标检测模型配合一个小的分类头，模型参数量在几百万到几千万级别，普通的嵌入式板卡或工控机就可以跑，而且识别速度能做到几十毫秒以内。
第二档是复杂纹理或多缺陷叠加场景，例如带花纹的服装面料、不规则金属表面，这时候用轻量化视觉Transformer或专门训练过的分割模型更靠谱。有些缺陷特征肉眼都很模糊，YOLO类模型可能漏检，需要换成像素级分割模型来提取缺陷轮廓。这类模型的参数量大概在几千万到一两亿，配合一块中端工业GPU，依然可以在端侧稳定跑。
第三档是真正需要语义理解的场景，比如服装版型是否与工艺单一致、工件类型判断，这些可以借助视觉基础模型做零样本或小样本能力增强。但要明确，基础模型是“底座”，最后还是要蒸馏成一个小模型部署到现场，不可能直接拿一个几十B的大模型在产线上实时跑。
至于大语言模型（LLM）在工业检测里的角色，我个人的看法是：它们更适合做检测报告生成、质量异常原因分析、以及运维知识问答这类“人机交互”任务。比如检测出布料上有连续色差条纹，让大模型根据工艺参数自动推断可能是印花辊温度波动，并生成一份解释报告推送给质量工程师。这种场景大模型是有价值的，但它不在检测主链路上，而是作为辅助决策工具存在。
顺便说一句，端侧推理也分“端”的规格。有些轻量检测任务，一个小盒子就能解决，比如RK3588这类边缘计算盒子，功耗低、性价比高，适合做成品外观检测；而复杂的多相机系统，就需要配一台带GPU的工业电脑来集中处理。选硬件之前一定要先把算法跑通，用性能分析工具看看模型的算力开销在哪个环节，再决定买什么样的硬件，否则很容易出现“算法很牛但硬件跑不起来”的尴尬局面。
4. 报警降99.8%、自控率98%这类指标，项目落地时怎么验证才不算吹牛
做工业AI项目汇报，领导最爱问的一句话是：“你说报警降了99.8%，这个数字怎么来的？拿什么验证？”如果答不上来，项目再漂亮也容易被质疑。我这些年踩过的坑总结下来，指标验证要做好三件事：定好计算口径、建好对照实验、留够持续观察期。
计算口径是第一个坑。报警降幅如果只拿“报警事件总数”做对比，其实是有点耍流氓的，因为很多工厂在上AI之前已经手动屏蔽了大量报警，基数本身就不真实。更靠谱的做法是用“监控点位覆盖率”和“报警负荷”两个维度双重验证。监控点位覆盖率指的是AI覆盖了多少原本产生报警的测点，占比越高说明治理越彻底；报警负荷是操作员单位时间内实际需要确认的报警条数，这个数降下来才是真正的减负。
第二个坑是对照实验设计。严格来说，要做A/B测试——把同样的工况、同样的时段分成两组，一组用AI辅助报警管理，一组保持原来的DCS报警逻辑，对比两组的误报率、漏报率、响应时间。但工厂不是实验室，不能为了对比让报警一直报下去，安全风险太大。实际项目中我们用的是前后对比加典型工况切片：选几个典型操作场景，比如开停车、负荷调整、原料切换，抽取同样场景下改造前后的报警数据做配对对比，这样说服力比笼统的平均值强很多。
第三个坑是观察期长度。报警治理模型和自控优化模型上线后，头两周的漂亮数据往往不可靠。因为现场人员和系统之间有一个磨合期，操作员前期会很谨慎地盯着AI的每一个输出，报警确认速度偏慢；等过了一个月，大家摸清了AI的脾气，信任度上去之后，行为模式才趋于稳定。所以我们的评估周期至少拉满一个完整的生产调度周期，比如某些化工装置需要连续运行28天做一次倒料切换，那就以28天为评估单元，对比上一个同周期数据。短期数据只拿来调模型，不能拿来对外汇报。
自控率这边同理，指标验证还有一个隐藏问题：98%到底是全天候98%，还是只算了白天操作员高峰时段？有些装置夜间负荷低、工况稳定，自控率天然高，白天原料波动大，自控率可能只有85%，平均下来96%，听起来不错，但白天实际体验还是很累。所以汇报自控率时最好拆分维度，把白天/夜间分开报，再附上关键时段（如进料切换前后）的自控表现，这才是负责的做法。
最后我想说，这些漂亮的数字指标最终都必须对应到业务价值上。报警降了99.8%，背后的价值是什么？是操作员终于有精力做精细化调整了，是事故风险降低了。自控率到了98%，价值是什么？是产品一致性提升了、能耗下降了、老师傅退休后知识不至于断层。每家工厂情况不一样，指标好看固然重要，但真正能让你在董事会上一页汇报PPT就打动所有人的，一定是“这条线用了这套东西之后，一年省了多少成本、多赚了多少利润”这类经营结果。所以做工业AI项目，从一开始就要盯住业务价值来设计指标，而不是先买一堆算法再回头找应用场景。
我自己在这类项目里最深的体会是，工业AI的价值从来不是“能用AI”本身，而是AI能不能在真实的温度、压力、振动和噪声里安静地干活，把那些重复的、高风险的、依赖老师傅手感的事情，变成一套随时在线的系统能力。报警数字会变，自控率会变，但这条判断标准不会变。如果你正准备推进自己工厂的AI项目，建议先从报警治理和自控率提升这两个最基础也最容易见效的方向切入，把团队的信心打出来，后面再往更深层的优化走就不难了。
