1. 产线异常工单这件事为什么值得单独拿出来聊我在制造业信息化这个圈子里摸爬滚打十来年做过MES实施、设备联网、质量追溯最近三年主要精力放在工业大模型跟业务系统的结合上。说实话产线异常工单这个场景是我见过被过度包装最严重的方向之一。几乎每一家做大模型落地的厂商PPT里都会放一页“智能异常处理”画一条从异常上报到根因分析再到自动派单的完美闭环底下配几个炫酷的指标什么“处理效率提升60%”“人工介入减少80%”。但真正在车间里跑过几轮的人都知道这条链路里能交给模型做的部分远比想象中窄。先把概念说清楚。产线异常工单指的是生产过程中设备故障、质量偏差、物料短缺、工艺参数越界等事件触发后由操作员、设备系统或质检环节生成的一张记录单。它通常包含异常描述、发生时间、工位/设备编号、异常分类、紧急程度、初步处置措施、责任人等字段。在传统MES或者EAM系统里这张单子靠人填、靠人分派、靠人跟进。工业大模型介入的价值点理论上在于把非结构化的异常描述转成结构化字段、根据历史工单推荐处置方案、辅助判断根因、自动匹配责任人和知识库条目。但这里有个关键前提——模型能做的事情受限于数据质量和场景确定性。产线异常工单的处理本质上是一个“信息补全决策辅助”的过程而不是“端到端自动化”的过程。我见过太多项目在立项阶段把预期拉到“AI自动处理异常”结果上线三个月后发现模型连异常分类都做不稳最后退化成“给操作员一个推荐框点不点随他”。这不是失败这是认清边界之后的正常落地形态。这篇文章想聊的就是这个工业大模型在产线异常工单场景里到底能做什么、不能做什么、边界在哪里、怎么设定合理预期。适合正在做相关选型的技术负责人、正在被业务方追问“为什么不能全自动”的项目经理以及想搞清楚这个方向真实水位的一线工程师。我不会给你画大饼只讲我踩过的坑和验证过的做法。2. 工业大模型在异常工单场景的真实能力边界2.1 模型擅长什么文本理解与模式匹配工业大模型最扎实的能力集中在自然语言处理这一层。产线异常工单里操作员填写的异常描述往往是口语化的、带缩写的、甚至带错别字的。比如“3线贴片机又报吸嘴异常了吸不起来料换了吸嘴还是不行”“注塑机第4段温度飘了产品有缩水”。这些文本进到传统规则引擎里关键词匹配很容易漏因为“吸嘴异常”可能被写成“吸嘴报警”“吸嘴故障”“吸嘴NG”而“温度飘了”跟“温度偏高”“温控不稳”是同一个意思。大模型在这里的价值是语义归一化。它能把五花八门的口语描述映射到标准异常分类体系上。我实测过在一个有12大类、87小类异常分类的注塑车间里用微调后的小参数模型做分类准确率能到85%到90%之间比纯关键词规则高出二十多个百分点。这个提升是实打实的而且落地成本不高——你不需要模型理解工艺原理只需要它把文本映射到标签。另一个擅长点是历史工单检索与相似案例推荐。当一张新工单进来模型可以把它的描述向量化在历史工单库里找最相似的若干条把当时的处置措施、根因、耗时一并推给当前处理人。这个功能听起来简单但在实际车间里非常有用因为很多异常是重复发生的老师傅凭记忆能想起来“上次也这样换了伺服驱动器就好了”但新员工没有这个记忆。模型做的是把老师傅的记忆变成可检索的资产。2.2 模型不擅长什么因果推断与实时决策边界的第一条也是最重要的一条模型不擅长做根因推断。产线异常的根因往往涉及多因素耦合比如“产品尺寸超差”可能是模具磨损、料温波动、保压时间偏移、环境湿度变化共同作用的结果。大模型能根据历史数据给出“可能原因列表”但它无法验证哪个是真正的原因。它没有物理模型没有设备机理知识它做的只是统计关联。我见过一个项目业务方要求模型“自动判断异常根因并给出处置方案”结果模型给出的方案是“建议检查模具、检查料温、检查保压参数、检查环境湿度”——这跟没给一样。后来调整预期改成“模型给出候选原因排序由工艺工程师确认”反而用起来了。因为工程师看到排序后能快速排除掉明显不可能的项决策效率确实提升了。第二条边界模型不能替代实时控制。产线异常处理里有一部分是要求毫秒级响应的比如设备联锁、安全停机。这部分必须由PLC、安全继电器或者边缘控制器来做大模型再快也快不到那个量级而且它的输出是不确定的不能用于安全相关决策。模型的位置在“事后分析”和“辅助决策”不在“实时控制”。第三条边界模型对数据质量极度敏感。如果历史工单里大量字段是空的、乱填的、或者复制粘贴的模型学出来的东西就是垃圾。我见过一个厂工单的“根因”字段有40%填的是“其他”问操作员为什么回答是“懒得选”。这种情况下你拿什么模型来都救不了。所以做这个场景之前先花两周时间清洗历史工单比花两个月调模型有用得多。2.3 边界背后的逻辑为什么不能全自动很多人会问既然模型能分类、能检索、能生成文本为什么不能把整个工单流程自动化答案在于责任归属和容错成本。产线异常处理是有后果的。如果模型推荐了一个错误的处置方案操作员照做了导致设备损坏或者批量报废这个责任算谁的在制造业里责任归属是非常严肃的事情不可能交给一个概率模型。所以任何涉及物理操作的决策必须有人工确认环节。模型可以做“建议者”不能做“决策者”。另一个逻辑是异常的长尾分布。产线异常里80%是常见问题20%是罕见问题。模型对常见问题处理得很好因为训练数据多但对罕见问题它要么给不出答案要么给出一个看似合理但完全错误的答案。而罕见问题往往才是造成最大损失的。所以模型不能覆盖全部场景必须有“我不知道”的机制把罕见异常交回给人。实操心得在系统设计时一定要给模型加一个“置信度阈值”。低于阈值的工单不展示模型建议直接走人工流程。这个阈值不是拍脑袋定的要用历史数据回测找到准确率和覆盖率的平衡点。我一般建议初始设在0.75左右上线后根据实际反馈调整。3. 落地实操从工单数据到模型输出的完整链路3.1 数据准备工单清洗比模型选型更重要在动手做任何模型之前先把历史工单捞出来看一遍。我通常的做法是随机抽500条逐条读记录以下问题异常描述字段的平均字数、有多少条是空白的、有多少条是复制粘贴的、分类字段的分布是否严重偏斜、处置措施字段是否可读。这一步的目的是建立数据质量基线。如果异常描述平均只有8个字那模型能提取的信息非常有限如果分类字段有60%集中在“其他”那分类体系本身就有问题需要先重构分类树。清洗的具体操作包括去掉纯符号和乱码记录、把明显复制粘贴的重复工单去重、对异常描述做最小长度过滤比如少于5个字的直接标记为无效、把分类字段里的“其他”重新人工归类。这个过程很枯燥但省不掉。我做过一个项目清洗前模型分类准确率只有62%清洗后同样的模型结构准确率直接跳到81%。数据质量的影响就是这么大。清洗完之后要做标注。如果历史工单的分类字段本身可信可以直接用作训练标签如果不可信需要抽一批出来人工重新标注。标注量不用太大每个类别有50到100条就能启动后续通过主动学习逐步补充。3.2 模型选型不是越大越好工业场景里我不建议一上来就用最大的通用模型。原因有三个成本、延迟、数据安全。成本方面产线异常工单是高频场景一个中型工厂每天可能产生几百到上千张工单如果每张都调用大参数模型token消耗非常可观。延迟方面操作员在工位上等结果超过3秒就会不耐烦大模型推理延迟很难压到这个水平。数据安全方面工单里可能包含工艺参数、产品型号等敏感信息很多工厂不接受数据出园区。我的建议是分层处理用一个小参数模型比如7B到13B级别的开源模型经过领域微调做第一层分类和实体抽取这部分覆盖80%的常见工单对于小模型置信度低的工单再路由到更大的模型做深度分析。这样既控制了成本又保证了长尾场景的处理能力。微调数据方面分类任务有500到1000条标注数据就能看到明显效果实体抽取需要更多一些大概2000条左右。如果标注资源有限可以先用提示词工程加少样本学习跑一版基线看看效果再决定是否投入微调。3.3 输出设计让模型说人话但别让它乱说话模型输出给到操作员或工程师时格式设计很关键。我见过一些系统模型输出一大段自由文本里面夹杂着不确定的推测操作员看完更迷糊了。好的输出设计应该做到结构化、可追溯、有置信度。具体来说分类结果用标签形式展示附带置信度百分比相似案例推荐列出3到5条每条包含工单编号、异常描述摘要、处置措施、实际耗时根因建议用排序列表每条标注“基于历史数据统计”或“基于相似案例”让用户知道这个建议的来源。注意绝对不要让模型直接生成处置指令。比如“请更换伺服驱动器”这种话必须由人来说。模型的输出应该是“历史上有3次类似异常其中2次通过更换伺服驱动器解决1次通过调整参数解决”把决策权留给工程师。3.4 系统集成别让模型成为孤岛模型跑出结果只是第一步关键是怎么把它嵌到现有工单流程里。我的经验是最小侵入不改动现有MES的工单创建和流转逻辑只在工单详情页加一个“智能辅助”面板展示模型输出。操作员可以采纳、可以忽略、可以反馈。反馈机制非常重要。每次操作员采纳或拒绝模型建议都记录下来作为后续模型迭代的训练数据。这个反馈闭环跑起来之后模型效果会持续提升。我做过一个统计上线三个月后模型建议的采纳率从最初的34%提升到了61%靠的就是反馈数据的持续微调。集成方式上如果工厂有边缘服务器可以把模型部署在边缘通过API跟MES对接如果没有可以用轻量级容器部署在厂区内的虚拟机上。不建议走公网调用延迟和稳定性都不可控。4. 预期管理怎么跟业务方说清楚“能做什么”4.1 立项阶段把指标定在“辅助”而不是“替代”跟业务方沟通时最容易出现的分歧是自动化程度的预期。业务方往往希望“上了AI之后异常处理不用人管了”而技术方知道这不可能。我的做法是在立项阶段就明确三个指标分类准确率、建议采纳率、平均处理时长缩短比例。分类准确率的目标可以定在85%到90%这是可验证的建议采纳率初期定在30%到40%后续逐步提升平均处理时长缩短比例根据场景不同10%到25%是比较现实的区间。这三个指标都是“辅助”性质的不涉及“替代人工”业务方接受度更高技术方也不会被逼着做做不到的事。4.2 上线阶段先跑影子模式不要一上来就让模型直接给操作员看结果。先跑两周到四周的影子模式模型在后台运行输出结果但不展示只记录。然后拿模型的输出跟实际处理结果对比看分类对不对、推荐方案是否被实际采纳、有没有明显的错误。影子模式的好处是你能在不影响生产的前提下拿到真实反馈发现模型在哪些场景下会出错。我做过一个项目影子模式期间发现模型对“设备报警代码”类异常处理得很好但对“产品质量缺陷”类异常几乎全错原因是质量缺陷的描述太模糊而且根因往往不在工单里记录。发现这个问题后我们直接把质量缺陷类异常从模型覆盖范围里拿掉了避免了上线后的尴尬。4.3 运营阶段建立模型效果的持续监控上线不是终点。需要建立一套监控机制跟踪模型每天的调用量、分类分布、置信度分布、采纳率变化。如果发现某个类别的准确率持续下降可能是工艺变了、设备换了、或者操作员的填写习惯变了需要重新微调。监控指标里我特别关注低置信度工单的占比。如果这个比例突然升高说明有新的异常模式出现模型没见过。这时候需要人工介入分析看看是不是需要补充训练数据。实操心得建议每个月做一次“模型复盘会”把当月模型出错最多的10张工单拿出来跟工艺工程师一起分析原因。这个会不用长半小时就够但坚持做下来模型迭代的方向会非常清晰。5. 常见问题与排查技巧实录5.1 模型分类总是偏向多数类怎么办这是最典型的问题。如果历史工单里“设备故障”占70%“质量异常”占20%“物料问题”占10%模型会倾向于把所有工单都分到“设备故障”因为这样整体准确率最高。但业务上你希望每个类别都分对。解决方法有三个一是在训练时做类别加权给少数类更高的损失权重二是在采样时做过采样把少数类复制多份三是调整分类阈值对少数类降低判定门槛。我一般先用类别加权如果效果不够再加过采样。实测下来加权能把少数类的召回率从30%提升到60%以上代价是整体准确率可能下降两三个百分点这个 trade-off 是值得的。5.2 操作员不信任模型建议怎么办这是人的问题不是技术问题。我的经验是先让模型在简单场景里建立信任。比如先只推“相似历史工单”不推根因建议。操作员看到“上次也是这个问题换了XX就好了”验证一次发现是对的信任就建立起来了。然后再逐步推分类建议、根因排序。另一个技巧是让老师傅参与模型验证。请车间里最有经验的几个人让他们看模型输出提意见。他们提的意见往往非常准而且一旦他们参与了就会主动帮你在车间里推广。5.3 模型输出不稳定同样输入结果不一样大模型有随机性同样的输入可能给出不同的输出。在工业场景里这种不确定性是致命的。解决方法是在推理时设置温度参数为0关闭随机采样。如果模型支持还可以用约束解码强制输出符合预定义的标签体系。另外对于分类任务可以用多次推理投票同一个输入跑5次取多数结果。这样能显著提升稳定性代价是推理成本增加5倍。如果成本敏感可以只对低置信度的工单做多次投票。5.4 历史工单里没有根因字段怎么办很多工厂的工单只记录“做了什么”不记录“为什么”。这种情况下模型无法学习根因推断。解决办法是从处置措施反推根因。比如“更换伺服驱动器”对应的根因是“驱动器故障”“调整保压时间”对应的根因是“工艺参数偏移”。可以先用规则做一轮映射再用模型做补充。如果连处置措施都记录得很粗糙那就只能先推动工单填写规范的改进。这件事没有捷径但可以从小范围试点开始选一个车间把工单字段标准化跑三个月积累一批高质量数据再推广到其他车间。5.5 模型更新后效果反而变差了这是灾难性遗忘。模型在新数据上微调后把旧数据上学到的知识忘了。解决方法是在微调时混合新旧数据新数据占70%旧数据占30%。另外每次更新前都要在保留的测试集上跑一遍确认效果没有下降再上线。我一般会维护一个黄金测试集包含每个类别的代表性工单每次模型更新都必须在这个测试集上通过才能发布。这个测试集不参与训练只用于验证。常见问题排查思路解决方法分类偏向多数类检查类别分布和混淆矩阵类别加权、过采样、调整阈值操作员不信任了解具体不信任的点从简单场景切入让老师傅参与验证输出不稳定检查温度参数和推理配置温度设为0多次投票约束解码缺少根因数据检查工单字段完整性从处置措施反推推动填写规范更新后效果下降对比新旧模型在测试集上的表现混合新旧数据微调维护黄金测试集6. 这套东西的扩展方向与个人体会产线异常工单这个场景跑通之后有几个自然的扩展方向。一个是跟设备预测性维护打通把设备传感器数据和工单数据结合模型不仅看工单文本还看设备实时状态根因推断的准确率会更高。另一个是跨工厂的工单知识共享把多个工厂的工单库联合起来做检索相似案例的覆盖面会大很多。还有一个是工单处理过程的自动化编排模型识别出异常类型后自动触发相应的检查清单、备件申请、人员通知这个属于流程自动化跟模型的关系不大但能显著缩短处理时长。我个人在实际操作中的体会是这个方向最大的挑战不在技术在预期管理。技术团队知道模型能做什么业务团队不知道中间的信息差会导致项目目标定得过高上线后达不到预期然后项目被砍。所以我现在做任何一个工业大模型项目第一件事就是跟业务方开一个“边界对齐会”把模型能做的、不能做的、需要人配合的一条条列出来双方签字确认。这个会看起来浪费时间但能省掉后面无数的扯皮。最后再分享一个小技巧如果你刚开始做这个方向不要贪大求全先选一个异常类型单一、历史数据充足、操作员配合度高的产线做试点。跑通一个点拿到真实数据再去说服其他产线。我见过太多项目一上来就铺全厂结果数据质量参差不齐模型效果上不去最后不了了之。单点突破逐步扩展在这个领域里是最稳的打法。