最近总有人拿着“工单分类、视觉质检、通用大模型”这三个词一起来问我是不是直接上一个大模型两个活都能干我先说结论能但没必要而且很多时候是给自己挖坑。企业场景里没有哪个方案是越“通用”越好的关键是让每一层技术干它最擅长的事。我这两年帮几家中型制造企业做过类似的智能化改造一开始团队都很兴奋觉得终于可以用上大模型了结果测下来发现工单分类用轻量模型微调视觉质检用传统CV加专用检测模型效果又稳又便宜大模型只在一个很小、但很关键的环节里出场——长尾语义兜底和难例样本筛选。这篇文章就把当时的测试过程、选型逻辑、踩坑记录拆开讲给正在纠结“要不要全面上大模型”的团队一个参考。1. 先拆清楚工单分类和视觉质检到底在解决什么问题别急着谈模型先想想业务本质。工单分类和视觉质检虽然都被划进“AI落地场景”但它们的问题结构完全不一样混在一起谈只能得出错误的结论。1.1 工单分类比“文案理解”更麻烦的是标签体系工单分类表面上是个文本分类问题给一段用户描述打个标签比如“硬件故障”“软件报错”“退款申请”“安装指导”。但做过的人都知道真正的难点根本不在理解话术而在标签体系本身。我见过一家企业工单标签有四十多个一级类目每个一级类目下面还有五到二十个二级类目形成了一棵很深的树。而用户报修的时候说话很随意同一个故障有三百种说法。比如“电脑开机之后风扇嗡嗡响”和“笔记本待机时突然变得很吵”其实都属于同一个叶子节点。如果你只做一个扁平的多分类模型那么标签之间的层级关系、近义关系、部分重叠关系都会被丢掉。更麻烦的是标签体系是动态的。业务部门可能每个季度新增一个产品线、拆分一个故障类型、合并两个责任部门这时模型要跟着改。如果用通用大模型做零样本分类改标签只需要改Prompt看起来确实爽但代价是每次推理都会带来随机性和不可控成本而且你没法向业务解释“为什么这个工单这周分到了A组、上周分到了B组”。我在模拟项目X里做过一次统计规则引擎能稳定解决的工单大约占65%这些工单的文本里有强关键词比如“死机”“蓝屏”“退款”。剩下35%是长尾模糊表达比如“用着用着就卡了重启也没用”这类才真正需要模型去理解语义。所以工单分类的第一性问题不是“模型够不够聪明”而是“怎么把确定性的部分和模糊的部分拆开”。1.2 视觉质检难的不是“看懂图”而是“稳定复现结论”视觉质检跟工单分类是两个世界。工厂里的缺陷检测不是要模型像人一样“看一眼觉得不对劲”而是要它在一个固定的工位上、固定的光照条件下、固定的拍摄角度下几千次、几万次地重复同一个判断产品表面有没有划痕有没有缺料焊接点有没有偏移。我在某电子配件厂见过一条产线质检相机每秒钟要处理两个零件每个零件拍四张图。这意味着模型要在一百多毫秒内完成判断而且漏检率和误检率都有严格考核。漏过一个缺陷件可能整批货被退货误杀太多产线良率数据又不好看。这种场景下最稳妥的方案往往是传统图像处理加专用检测模型的组合。传统CV负责定位区域、提取特征专用模型负责在限定框里判断缺陷类别。通用大模型当然也能看图但它本质是一个概率生成模型每次输出都可能有细微差异你怎么跟产线负责人解释“这次判断是模型基于上下文概率生成的置信度0.83所以它认为这里算缺陷”产线要的是确定性的规则不是概率性的解释。1.3 两者共有的隐藏成本数据流要能解释、能回滚无论工单分类还是视觉质检企业里最容易被忽略的是数据流的可追溯性。业务方会问这批工单为什么被分错这批不良品为什么漏检了如果答案是“模型觉得”这单就过不去。通用大模型的黑盒程度更高你投进去一段文本、一张图它内部做了几十亿参数的计算然后给你一个答案中间没有任何可检查的节点。相对而言轻量分类模型至少可以输出特征重要性传统CV可以输出缺陷轮廓和位置每一步都有据可查。所以我的经验是能解释的方案优先级永远高于不能解释的方案除非精度差距大到不可接受。2. 通用大模型的两个真实优势和两个硬伤我知道前面说了不少“泼冷水”的话但我也不是逢大模型就反对。它在某些点上的确是相当强的关键是别把它用错地方。2.1 优势一零样本迁移能力确实省钱省时间传统做法里要做一个工单分类模型得先整理几千条标注数据训练一个底座模型再评估、调参、上线。这一整套流程最少也要两周。但用通用大模型的零样本分类能力把工单分类规则写成Prompt先跑几百条真实工单试试半天就能出结果。当时我拿五十条长尾工单做测试提示词里写清楚“如果用户描述中包含退货或退款意图请归类到售后索赔”它基本都能正确分类而且理由写得明明白白。这种快速验证能力是传统NLP流程完全比不了的。如果你只是做一次性的数据清洗、历史工单打标、或者给新业务部门做冷启动分类用大模型做初步标注非常划算。2.2 优势二一个接口处理文本加图像省去系统集成通用多模态模型另一个吸引力在于你把工单文本和现场图片一起扔进去它能直接给结论缺陷类型、责任部门、建议处理方式全出来。对一个小团队来说这相当于用一套API就把原来需要两套系统的事情干完了。所以很多管理者一听这个能力就兴奋觉得不需要再维护两个模型、两套训练流程。这种想法不无道理尤其适合那种业务形态频繁变化、样本量又极少的小型团队。比如初创公司做设备运维前期工单量每天只有一百多条专门训练一个分类模型不现实这时候用大模型顶上去是合理的过渡方案。2.3 硬伤一幻觉和随机性在产线上是致命的但接下来我就要说硬伤了。大模型的本质是“根据概率生成下一个Token”它不是在“查规则”是在“创作回答”。这导致两个问题同一段输入可能因为Prompt里一个词的变化得到不同的分类结果更麻烦的是它可能一本正经地把一个不存在的故障类型生成出来。工单分类里幻觉表现为把“显示器闪烁”分到“电源适配器故障”理由写显示器供电不稳定可能由适配器引起——听着很合理但产品线根本没有这个适配器。视觉质检里更吓人。我见过一个测试把一张完全正常的零件图喂给通用视觉模型让它判断有没有划痕它意外输出了“轻微划痕位于左上角区域”但放大看那块区域只是模具留下的正常纹理。一次两次没关系但产线上每天八千个零件这种随机性会导致质检员不敢信任系统最后变成“模型说有问题我们总要复检一遍”效率反而下降。这类场景里宁可模型漏判也不能模型乱判因为乱判会破坏整个流程的信任基础。2.4 硬伤二时延、成本和安全边界都是账面上的现实问题说个实际数据吧。某次我做视觉质检测试用通用视觉模型分析一张图请求发送到云端接口平均延迟一点八秒。产线允许的判断时间是一百五十毫秒差了十倍以上。如果你把大模型部署在本地GPU服务器上单张图的推理延迟能压到三百毫秒但也很难进一百毫秒。同时一块工业级显卡大概两三万加上服务器、散热、机房改造一年成本十几万这还不算模型迭代时的人工成本。工单分类虽然没有时延压力但成本和安全边界同样存在。如果工单里包含客户电话、地址、设备序列号你把文本发送到云端大模型接口这些数据就等于过了第三方服务器。很多企业对这种数据外流是非常敏感的哪怕你费劲解释“数据只用来做分类不会存储”合规部门依然不会批。所以总结一下大模型在这两类任务里真正的定位它是一个优秀的“兜底队员”和“冷启动教练”但不是日常产线上的“主力球员”。3. 工单分类的正确打开方式先规则、再轻量模型、最后才轮到大模型工单分类这个场景线上高并发、标签体系稳定、结果必须可解释。按这个约束条件来反推最合适的架构其实是一个分层漏斗而不是一上来就套大模型。3.1 第一层用规则和强特征吃掉最确定的部分别瞧不起规则引擎它永远是工单分类的第一道防线。关键词、正则、词典匹配能把那些表达非常固定的工单直接分走比如包含“蓝屏”“死机”的归到系统故障包含“退货”“不想要了”的归到售后退款。我在模拟项目X里做了一套规则引擎用几百条正则规则覆盖了大约六成的工单准确率做到了百分之九十八。这不是模型聪明而是这些工单本身就很直白。规则引擎的好处是零延迟、零成本、绝对可解释业务人员自己就能维护。在规则后面加一个置信度判断命中关键词数量越多置信度越高低于阈值再往下层走这样就把最紧急、最好处理的活快速消化掉了。3.2 第二层用轻量预训练语言模型做语义匹配剩下四成工单进入第二层这里我推荐的是轻量级中文预训练语言模型微调分类而不是直接用通用大模型。原因是企业的标签体系是固定的不需要模型有太多的“创作欲”只需要它学会在这棵标签树上做选择题。具体做法是把历史工单描述作为训练文本标签作为分类目标在轻量模型上做微调。标注数据准备两千条左右就能有一个不错的基线准确率通常在百分之九十二到九十五。这个模型的推理速度在普通CPU上大约每秒处理几十条如果是GPU就更快完全能扛住企业工单量。有人会问为什么不用更小的经典的词频加机器学习模型我也试过词频模型在文本长且关键词密集的场景下表现不差但一旦用户描述里用了同义词、比喻、口语化表达它就跟不上了。轻量预训练模型能捕捉上下文语义在“开机电源灯亮但屏幕无显示”这种工单里能正确匹配到“显示故障”而不是“电源故障”这是词频模型做不到的。3.3 第三层大模型只在长尾模糊场景里兜底第二层模型仍然会有百分之五左右的低置信度样本这些样本通常夹杂着特殊行业术语、多故障复合描述、或者非常冷门的表达。把这些样本交给通用大模型处理效果反而很好。关键在于怎么把“低置信度样本”筛出来。给轻量模型设一个输出概率阈值比如零点六以下就认为是模糊样本。测试下来这些样本只占总量的百分之十到十五拿这十分之一去调大模型接口成本完全可控而且准确率能再提升两到三个百分点。这里有一个很重要的技巧**不要让大模型直接给最终标签而是让它输出中间判断理由再由一套小规则做最终裁决。**比如用户说“电脑开不了机指示灯偶尔闪”大模型给出“可能原因电源板故障或主板故障”你再用规则把“电源板故障”匹配到对应部门。这样做的好处是即使大模型判断有偏差至少它的理由是可读的业务人员能看到完整链路而不是面对一个黑盒结果。下面是这套分层路由的简化逻辑写给大家参考def classify_ticket(text): # 第一层规则引擎 rule_result, rule_score rule_match(text) if rule_score 0.8: return rule_result, rule # 第二层轻量语义模型 model_result, model_confidence light_model.predict(text) if model_confidence 0.6: return model_result, light_model # 第三层大模型兜底 llm_reason llm_analyze(text) final_result reason_to_label(llm_reason) return final_result, llm3.4 别忽略的配套工作人工复核闭环分类系统上线后必须有一个人工复核闭环。我的习惯是每天抽百分之五的低置信度分类结果让业务人员在界面上确认“分对了还是分错了”每周汇总一次用来更新规则、补充训练样本。这套机制看起来慢但它是整个系统持续变好的关键。没有这个闭环任何模型上线三个月后精度都会悄悄下滑因为业务和用户语言的分布一直在变。4. 视觉质检的正确打开方式边缘小模型当主力通用模型只在不那么急的地方出现视觉质检的选型逻辑和工单分类不一样因为它不只是精度问题还牵扯整个产线的物理限制。下面按实际落地顺序来讲。4.1 工业质检的三个硬约束时延、误检成本、数据模态第一时延。产线上每个工件的检测时间是固定的相机拍了图模型必须在几十到几百毫秒内给出结果否则传送带就堵住了。第二误检成本。漏检和误检都是钱但两者的权重不同。漏检可能让不良品流向客户引发退货赔偿误检则直接降低产线良率造成浪费。第三数据模态。很多工厂的质检不是一张普通照片而是特殊光源下的成像比如红外、紫外、背光、同轴光这些图像的分布和自然图像完全不同。拿同轴光来说它拍出来的金属表面纹理看起来像一张艺术照片人类都很难一眼找出缺陷更别说让一个在自然图像上训练的通用视觉模型去判断了。通用模型见过猫狗、风景、人物但大概率没见过这种工业打光下的零件纹理效果自然不理想。4.2 主力方案传统CV加专用检测模型的组合我在实际项目里用的方案是两层结构。第一层是传统图像处理负责把工件区域从背景里分割出来裁剪出要检测的局部比如螺丝孔、焊点、边缘线。第二层是一个轻量的目标检测或分类模型在裁剪后的区域里判断缺陷类型和位置。传统CV用边缘检测、阈值分割、形态学操作就能把绝大部分背景噪声去掉这样模型只需要关注很小的区域精度和速度都能上去。有人觉得传统CV太“老土”但当背景变化不大、光源固定、工件位置固定的时候传统方法就是最稳定、最便宜、最容易调试的。你改一个阈值参数效果马上变化比重新训练一个模型快得多。专用检测模型的训练数据也不需要很多一个缺陷类别准备三百到五百张图就够了配合数据增强基本能上线。推理延迟在普通工业显卡上可以压到五十毫秒以内远能满足产线节拍。成本上一张消费级工业显卡就能扛住两到三路相机比云端大模型接口便宜得多。当年我做某图像处理Demo时对比过同一批标注数据专用模型对划痕检测的F1值是零点九五通用视觉模型提示词判断的F1值只有零点八四。更关键的是专用模型的误检集中在固定几类特征上你可以通过后处理规则再拦一道通用模型的误检则是零散分布的根本没法提前预防。4.3 通用多模态模型适合放在哪样本挖掘、难例分析、质检报告那通用模型在视觉质检里就完全没用吗也不是它适合放在不着急、不敏感的环节里。我常用的是三个位置。第一个是初始样本挖掘。一个新项目冷启动时可能只有几十张缺陷图先让通用视觉模型去扫描几万张历史图片把疑似有缺陷的图挑出来人工筛选后形成第一批训练集这种做法比纯人工翻图快得多。第二个是难例分析。当产线专用模型发生误检时把误检图喂给通用模型让它描述“你看到了什么”它的自由文本输出反而能帮你发现漏检的类型比如某一种新的划痕形态。第三个是生成质检周报。传统流程里质检员每天手动汇总不良率、缺陷类型分布用通用模型自动生成带摘要的报告能省不少时间而且这个场景对幻觉不敏感只要数据来源准确生成描述就算有偏差也没有严重后果。4.4 如果真要在产线上用通用模型必须做的三件事我理解有些团队确实想直接用通用模型跑产线质检比如产品种类太多、每种缺陷样本都很少专用模型很难训练。这种情况也不是绝对不能上但要先满足三个条件。第一做提示词模板锁定。把所有Prompt模板固定下来包括“你是质检员请判断以下区域的缺陷类别”不允许模型自由发挥。第二加规则约束。模型输出的每个判断都要经过后处理规则校验比如“如果置信度低于0.7一律转人工复检”。第三做线上Shadow测试。先让通用模型和专用模型并行跑两周统计两者在批量样本上的一致性高于百分之九十五再考虑切换。两周影子测试期间所有判断都以专用模型为准通用模型的输出只记录、不执行。用这套流程求稳虽然进度慢一点但至少不会因为一次随机误检把整条产线搞崩。5. 一套实用的分层决策框架与止损线说了这么多最后给一个可以直接拿去用的决策框架。每次有企业问“要不要上通用大模型”我基本都按下面这个思路过一遍几分钟就能有个初步结论。5.1 四象限判断按数据量和确定性选底座先看两个维度一是数据的确定性高不高二是样本量多不多。确定性高指的是输入表达标准、标签固定、规则清晰样本量多指历史数据有没有积累到千条以上。根据这两个维度可以分到四个象限里象限特点推荐方案高确定 多样本规则明确历史数据充足规则引擎加轻量模型微调高确定 少样本规则明确但数据刚起步规则引擎打底轻量模型冷启动后逐步微调低确定 多样本表达杂乱但历史数据够轻量模型微调为主大模型兜底长尾低确定 少样本表达杂乱数据又少先用通用大模型过渡同时积累数据工单分类绝大多数属于第三象限所以第二层用轻量模型、第三层用大模型兜底最合适。视觉质检多数属于第一象限或第二象限优先用专用模型大模型做辅助。只有那种新业务、新产线、历史数据几乎为零的冷启动阶段才值得把大模型放在主链路上。5.2 成本估算模板别把推理费用和隐性成本算错很多团队在选型时只算了API调用费忽略了三笔隐性成本。第一笔是开发调试成本。大模型的Prompt调优看起来简单但要调得稳定每次改动都要回归测试人力成本远高于微调一个轻量模型的训练时间。第二笔是基础设施改造成本。本地部署大模型要买显卡、改机房、配存储这部分钱比API调用费高一个数量级。第三笔是人工复核成本。大模型的误判往往没有规律你没办法用一条规则拦掉最终只能靠人去看而人工成本在公司里通常是最贵的。我自己有个估算公式如果每天需要判断的量级在几千条以下大模型总成本还能接受如果到了一两万条以上传统方案的优势就非常明显了。5.3 三个踩坑记录我踩过的你大概率也会遇到最后分享三个真实踩坑经历希望帮大家少走弯路。第一个坑是直接拿大模型当工单分类主力。当时某开发团队给工单系统接了大模型接口用了两个月之后发现分类准确率从最初的百分之九十四掉到了百分之八十八原因是大模型接口悄悄升级了版本输出格式变了而且分类逻辑也微调了。后来我们把规则引擎和轻量模型接回去大模型只做兜底再也没出过这种问题。第二个坑是视觉质检直接套通用视觉模型判断缺陷。测试阶段觉得效果还行一上线就被产线负责人打回来了因为模型经常给出“疑似缺陷”这种不确定判断这种人机交互方式在产线流程里根本没法处理。后来把所有判断改成二分类加坐标输出并让模型附带一个置信度数值低于阈值的图自动转人工复检产线才接受。第三个坑是忘了做数据回流。早期工单分类系统上线后我设置了一个置信度阈值低于阈值的样本直接走大模型但一直没有把大模型的处理结果回收成训练数据。三个月后我的轻量模型还是那么多样本精度没有提升。后来加了一个回流环节凡是走大模型的工单人工复核后都进入下一次微调的候选集模型的成长速度才明显加快。回头看这件事通用大模型更像是一个“请来的顾问”思路开阔、知识面广但真要让它每天都顶在产线上干重复性极强的固定工作它反而不如那些经验固定、行为可预期的小模型。工单分类和视觉质检的落地关键永远不是“选最厉害的技术”而是“选最能被流程信任的技术”。先把分层架构定好再考虑哪一层该用谁这个顺序别搞反。