大模型不是万能的：工单分类与视觉质检的混合架构实践

最近半年，我前前后后聊过不下十家想上"大模型能力"的制造和客服团队，几乎每个项目立项时都会甩给我一句话：我们工单分类和视觉质检，能不能直接全上通用大模型？每次听到这个，我都先按住对方，连问三个问题：你们工单一天多少张？标签体系是几十类还是几百类？产线质检节拍是多少秒、缺陷样本有多少张？因为这几个问题的答案不同，技术方案完全是两回事。

先把结论放在这儿：没必要，也不建议。不是说通用大模型没有用，而是工单分类和视觉质检这类企业场景，天生是"规则化、高频、局部长尾"的混合体。一上来就把所有流量全交给通用大模型，成本高是其次，最怕的是延迟、幻觉、不可控，最后业务一验收，返工成本更吓人。真正划算的做法，是做一个分层分流架构：规则模型接高频，小模型接中频，通用大模型只接长尾疑难case。这篇文章就是把这本账摊开，分场景、分成本、分坑，一次说清楚。

1. 先搞清楚：工单分类和视觉质检，到底难在哪里

很多老板以为"分类"和"质检"都是简单活，找个大模型就能干，但真正落地过的人知道，这两个场景的难度结构完全不同。不理解难度结构，选型一定是错的。

1.1 工单分类：不是"阅读理解"，是"高频精准分拣"

工单分类本质上是短文本的意图识别和内容归类，但它和普通的闲聊对话完全不是一回事。工单的特点是：格式相对固定、行业术语集中、类别体系是确定的。一家客服中心的工单，标签通常几十到几百个，比如"退换货""物流延迟""发票问题""设备故障"，这些类别在业务上早就被定义好了，缺的不是"理解能力"，而是又快又准的分拣能力。

我拿快递分拣做个类比。快递员每天处理几千件包裹，大部分地址格式规规矩矩，系统一扫就知道送到哪个站点；但总有那么几个包裹，地址潦草、电话错了、收件人信息写了一半，这时候才需要人工介入判断。工单分类也一样，真正制造区分度的不是那70%的正常case，而是后面30%的长尾：用户用口语吐槽"东西坏了根本没法用"、把"退款"写成"把钱还我"、在工单里夹带了好几段无关内容。头痛的永远是这种"语义漂移"的case。

所以工单分类的技术难点不在于"理解语言本身"，而在于：如何在极低成本下覆盖长尾表达，同时保持高频case的极速响应和稳定准确率。通用大模型对长尾的覆盖能力确实强，但高频case也用大模型，就属于大炮打蚊子，又慢又贵。

1.2 视觉质检：不是"看图说话"，是"稳定复现缺陷"

视觉质检是另一个维度的难题。它不是让模型去"描述图片里有什么"，而是要在固定光源、固定角度、固定产品型号的条件下，把极小、极不显眼的表面缺陷找出来。一个连接器针脚上的划痕，一个冲压件边缘的毛刺，一个屏幕Panel上的暗点，这些缺陷的特征空间非常窄，而且和产品、工艺、材料深度绑定。

传统视觉和专用小模型在这个场景里已经跑了很多年，算法从最简单的灰度阈值分割、边缘检测、模板匹配，一路进化到基于深度学习的轻量目标检测和异常检测。它们真正的优势就四个字：稳定可控。同样一张图，今天跑和明天跑结果一致；产线节拍2秒一件，模型推理必须控制在50毫秒内；漏检率要求万分之一，那就得反复调阈值、反复校准。

通用视觉大模型在这类任务上有个致命弱点：它太"泛"了。你对一张产线图片调用通用视觉大模型，它能告诉你"这是一个金属零件"，但它不一定知道你工厂里"第7号缺陷"长什么样，因为那种缺陷特征只存在于你们自己产线积累的几百张样本里。换句话说，视觉质检的难点不是"看懂物体"，而是"记住你们家工厂独有的那类瑕疵"，这恰恰是通用模型最不擅长、专用小模型最擅长的事。

1.3 通用大模型的能力边界：强在开放，弱在约束

通用大模型的强项是开放域理解、跨场景泛化、零样本推理，你给它一句没见过的说法、一张没见过的图，它大概率能给你一个"差不多对"的结果。但企业场景恰恰是强约束场景：标签体系是固定的、缺陷类型是固定的、成本预算也是固定的。

通用大模型的弱项在约束场景下会被放得很大。第一是幻觉，它可能生成一个"看起来合理、但标签体系里根本不存在"的类别描述；第二是不稳定性，同一个case换一种说法、换一次调用，结果可能不一致；第三是不可解释，业务方要求你解释这条工单为什么分到A类，大模型给不出可追溯的证据链。

所以我的判断是：通用大模型在企业场景里的正确位置不是"主引擎"，而是"兜底专家"。它的价值在于处理那些规则和小模型都搞不定的模糊case，而不该把所有流量都灌给它。

2. 全部上通用大模型的成本与风险，可能超你想象

这一节来算账，全部用可量化的估算方式算，你会发现 "全上大模型" 的预算根本不是上线那一刻的API费用，而是一整套包括治理、纠错、合规在内的长期成本。

2.1 算一笔Token账：月成本从几千到几十万

工单分类如果用商用大模型API来做，计价单位是Token。一条工单少则几十字，多则几百字，平均按200到300字、约300到400个Token算。一家中等规模的客服中心，一天工单量大概在3万到5万条，我们按3万条、平均350 Token来算：

• 一条工单请求上线前，你还得把标签体系说明、示例、分类指令一起塞进上下文，这部分固定消耗再算500到700 Token。
• 单条总消耗大约900到1000 Token，按输入输出混合单价估算，单条成本可能在0.01元到0.03元之间。

一个月按30天、3万条/天计算，就是90万条工单，月成本约9000到27000元。看起来不高？但工单量过10万条/天的大企业，月成本直接到5到10万。这还是只算文本分类，还没算视觉质检。

如果是视觉质检，调用通用视觉大模型API按张计费，产线一天运转8到16小时，节拍2秒一件，一天就是1.4万到2.8万张图。按单张几分钱的价格估算，一天的视觉质检费用就能到几百元，一个月又是好几千到上万。两条业务线叠一起，一年光API调用费，七八十万就没了。这个钱用来干嘛不好？够养一个三人算法小组了。

2.2 算一笔效果账：大模型不总是更准

很多人默认"模型越大越准"，但那是通用benchmark。放到企业自有数据上，这个结论不一定成立。

工单分类里有一个很典型的规律：如果你们有5000到10000条人工标注好的真实工单，拿一个中小规模的预训练语言模型微调，在验证集上做到95%到97%的准确率并不难。通用大模型零样本推理，哪怕prompt写得再好，通常也就在85%到92%之间波动。为什么会这样？因为工单分布是"局部高度集中"的，高频类别反复重复出现，专用小模型只要见过足够多的同类样本，就能学到非常锐利的边界；而通用大模型为了迁就所有场景，它的决策边界是平滑的、保守的，反而不如专用模型"一刀切"来得准。

视觉质检更明显。产品缺陷数据往往是长尾中的长尾：某个缺陷在1000张图里只出现20次。通用大模型没见过这种缺陷，它只能凭"常识"猜测，而专用小模型可以在你们自己的缺陷样本上做数据增强、迁移学习、hard negative mining，把那一类缺陷的召回率从70%拉高到98%。我在实际项目里见过太多次：大模型在公开测试集上分数很高，一换成产线真实图，立刻被专用小模型按在地上摩擦。

2.3 数据合规和系统稳定性：隐形成本更要命

工单里通常带客户姓名、电话、地址、订单号，这些数据能不能传给第三方API，本身就是一道红线。很多企业合规部门会直接否掉"全部上大模型"的方案，因为数据出域这件事不可接受。视觉质检图虽然不一定涉及个人隐私，但涉及工艺参数、未上市产品外观，同样属于核心数据资产。你愿意为了省事，把产线实拍图传到外部推理接口去分析吗？反正我劝你不要。

系统稳定性也是一个被严重低估的坑。产线控制是闭环实时系统，视觉质检模块的响应时间不能波动。通用大模型的推理延迟是不稳定的，高峰期排队时间长、偶发超时，这在离线文本场景还能容忍，在产线上就是宕机事故。工单分类系统如果跑在业务主链路上，一次API故障可能导致整个工单积压。自建大模型集群又得考虑GPU运维、扩容、机房带宽，这个隐性成本比API费用更难算。我见过不止一个团队，把系统搭起来之后发现运维工作量接近一个小公司的基础设施团队，最后灰溜溜退回混合架构。

2.4 组织账：模型升级带来"行为漂移"

最后算一笔组织账。商用大模型API的版本会频繁升级，今天用和三个月后用的同一个接口，底层模型换了，分类结果就可能变。你在系统里精心设计的few-shot示例、温度参数、后处理规则，全部要重新调。专用小模型锁死在你们自己的部署环境里，版本自己控制，行为永远稳定。对于追求"可预期"的企业系统来说，稳定性的价值远超那一点"智能感"。

3. 更务实的混合架构：三层分流，把大模型用在刀刃上

既然全上不行，那正确的做法是什么？我推荐一套漏斗式混合分流架构，核心思想是"让简单的case走最便宜的路，让复杂的case走最聪明的路"。

3.1 总体设计理念：漏斗式处理

这个理念不复杂，就三层：

1. 第一层：规则和关键词引擎，覆盖高频、确定性强的case，速度快、成本几乎为零。
2. 第二层：专用小模型，覆盖语义稍有变化、但类别已经见过的case，毫秒级推理，准确率最高。
3. 第三层：通用大模型，覆盖小模型低置信度、规则没命中的长尾case，能处理开放表达的疑难杂症。

关键点是每一层之间加"置信度判断"和"人工复核出口"。系统不是把所有case硬塞给某一层，而是让每一层只处理自己确定能处理好的样本，不确定的果断往下一层丢。这样整体准确率能逼近最高层的水平，成本却只略高于最低层的水平。

3.2 工单分类落地细节：规则层 → 小模型层 → 大模型层

我在真实项目里最常用的一套配置是这样跑的：

第一层是规则引擎。先统计历史工单里的高频词和固定句式，比如含有"退货""退款""运费险"关键词的，直接归入售后相关类目；工单编号以特定前缀开头、来自特定渠道的，直接映射到对应业务线。规则层一般能覆盖40%到60%的流量，命中规则的case确定性很高，准确率能做到99%以上，而且是完全可解释的。

第二层是小模型。给剩余未命中的工单，喂给一个基于预训练语言模型微调过的短文本分类模型。这里一定要选轻量的模型结构，部署在CPU上就能跑，单条推理时间控制在10毫秒以内。输入是归一化清理后的工单文本，输出是每个标签的置信度分数。

第三层才轮到通用大模型。当小模型的最大置信度低于某个阈值（比如0.85），说明这个case不在训练分布之内，才交给大模型做开放分类。同时，我会让大模型以"标签+理由"的形式返回结果，理由可以用于后续的人工抽检和样本沉淀。

这套流程的伪代码大概是这样的：

def classify_ticket(text): # 第一层：规则引擎 rule_result = rule_engine.match(text) if rule_result.hit: return rule_result.category, 1.0 # 第二层：专用小模型 pred_label, confidence = small_model.predict(text) if confidence >= 0.85: return pred_label, confidence # 第三层：通用大模型，只处理低置信度case return llm_classify_with_reason(text)

你可能会问：大模型的置信度怎么算？我的做法是不算置信度，而是看它的输出是否落在合法标签列表里，如果落在，就采纳；如果不在，就进入人工复核队列。因为LLM给出的概率不可靠，但"是否严格遵守了给定标签集合"这个约束，是可以硬核校验的。

3.3 视觉质检落地细节：传统视觉 → 专用检测模型 → 通用视觉大模型复核

视觉质检的混合架构要和产线实际情况绑定，一般也分三步走。

第一步是用传统机器视觉做"硬缺陷"筛查。尺寸超差、区域有无、边角破损这类问题，用固定阈值、模板匹配、连通域分析就能稳定检出。这类方法的优点是速度快、消耗资源低、完全可解释，你甚至可以量化到像素级别。很多产线的致命缺陷，其实80%靠这一步就能拦住。

第二步是训练专用的轻量缺陷检测模型，处理"软缺陷"。比如纹理异常、局部划痕、颜色偏差，这类缺陷特征不稳定，需要模型学一个"正常产品分布"的概念。这里推荐使用基于目标检测或异常检测的轻量模型，模型体积控制在几十MB以内，部署在工控机或边缘盒子，单图推理时间50毫秒上下。重点是做数据增强和策略调整，把漏检率压到万分之一以下。

第三步才是通用视觉大模型的位置。它不是上产线实时跑，而是做离线抽检和疑难复核。比如产线每天选5%的图像，定期送给通用视觉大模型做二次审视，看有没有发现专用模型没报出来的"新类型缺陷"；或者在专用模型判定为NG但又非常接近阈值时，把图像自动截留到复核队列，由大模型辅助判断，再配合人工最终确认。

我特别不建议让通用视觉大模型直接接入产线。通用视觉大模型处理单张图像的时间通常在秒级，而产线节拍是毫秒级，完全跟不上实时性要求。哪怕只做抽检，也要在图像下线之后异步跑，千万别让它阻塞主流程。

3.4 小模型的选型与训练要点

混合架构的成败，其实很大程度取决于第二层"小模型"够不够强。选型上有几个原则：

• 文本分类：优先选择轻量、但保留预训练语义能力的模型结构，参数量在几亿以内即可，再根据工单数据做领域自适应预训练，最后做分类微调。不要一上来就选超大模型，工单分类任务的语义复杂度没那么高，大参数只会拖慢推理。
• 视觉质检：缺陷样本通常非常少，优先使用预训练的目标检测或分类模型做迁移学习，别从零训练。如果缺陷形态近似"纹理异常"，也可以尝试无监督异常检测方案，只用正常样本训练，把缺陷当"偏离分布"来抓。
• 数据标注：工单分类标注5000到10000条一般就够看到明显效果；视觉质检至少要保证每个缺陷类别有50到200个正样本，如果不够，就用仿真渲染、数据增强补。

小模型训练好之后，要定期做bad case分析，把大模型处理过的case里"重复出现且有规律"的部分抽取出来，变成小模型的新训练样本。这样小模型会越来越强，需要交给大模型的长尾case会越来越少——这才是混合架构真正值钱的地方。

4. 实操过程：从零搭建一个分流式工单分类系统

前面讲的是理论，这一节用一个模拟项目X的实操流程，把上面那套架构完完整整走一遍。为了接地气，我们就设定：某客服中心，日工单量5万张，标签体系60类，历史工单100万条，人力紧张，希望把自动分类准确率从原先的85%提到98%，同时控制单条成本在0.005元以内。

4.1 第一步：先对历史工单做"难度分层"

很多人做项目一上来就急着训练模型，我建议先花一两天做难度分层。抽1万条历史工单，拿现有规则引擎跑一遍，看看能直接命中多少。在这个项目里，规则引擎命中率大概是52%，也就是5200条能直接归类，剩下4800条是规则覆盖不了、需要模型处理的。

再从这4800条里随机抽500条，让业务专家标一遍。标完你会发现两大类情况：一类是语义表达多变、但类别还是熟悉的，比如"物流太慢了"和"三天了还没送到"其实都是物流延迟；另一类是真正模糊的长尾，比如一条工单里又抱怨产品质量、又抱怨客服态度，这时候类别归属本身就存在争议。

这步做完，你就知道该把重心放哪。这个项目里，大约65%的未命中case属于"模型可学"的范畴，20%属于"确实需要大模型判断"的范畴，剩下15%属于"规则和小模型都不确定，得人工复核"。

4.2 第二步：用标注数据定阈值，而不是拍脑袋

接下来，用2000条人工标注好的工单训练小模型。训练完成后，关键一步是用验证集画出置信度-准确率曲线。你会发现，当置信度阈值取0.85时，小模型只处理了65%的流量，但这部分准确率在96%以上；当阈值降到0.5，小模型处理了90%流量，准确率却掉到88%。

不能为了多处理流量牺牲准确率，也不能为了准确率把太多case扔给大模型增加成本。我们的做法是：

• 置信度≥0.85时，小模型直接出结论；
• 置信度在0.5到0.85之间，进入大模型复核；
• 置信度低于0.5，直接进人工工单池。

跑了一周之后，统计结果是这样：56%的工单走规则，22%走小模型，12%走大模型，10%进人工。综合准确率做到了98.2%，单条综合成本约0.004元，满足预算。

这里有个细节：阈值不能只看准确率一个维度，还要看业务损失。有的类别分错了会造成严重的售后纠纷，那就要单独把这类别的阈值拉高。比如涉及退款金额的工单，阈值从0.85提到0.92，就是为了宁可多扔给人工，也不要分错。

4.3 第三步：搭流程、定监控指标

流程搭起来不复杂，但监控指标一定要在一开始就定好。我当时盯着看的核心指标有六个：

这些指标每周复盘一次，任何一个偏离基线都要拉出来查。特别是"大模型介入率"，如果它持续上升，说明前面的规则和小模型在退化，或者业务出现了新表达，需要补样本了。

4.4 第四步：持续迭代，让大模型流量越用越少

混合架构最妙的地方在于它是一个会自我优化的系统。每周末，我们把大模型处理过的2000条case拉出来，让业务专家快速复核一遍，把其中"大模型分对了、但小模型之前不敢分"的case抽出来，重新标注后加入小模型的训练集。一个月跑下来，小模型见到的数据越来越多，置信度阈值稍微降到0.82也能保持同样准确率，大模型介入率会从12%慢慢降到6%。

成本就是这样一点一点降下来的。原来单条综合成本0.004元，优化三个月后能降到0.0025元左右。如果一开始全上大模型，这个数字只会居高不下。

5. 常见问题、排查与避坑指南

最后这部分，我把这几年在工单分类和视觉质检项目里踩过的坑，整理成一份问题速查。这些坑，你在文档里几乎找不到，但每一个都让人头大过。

5.1 分类结果"看起来对"，但整个标签体系崩了

很多人以为分类模型只要"分得准"就行，其实工单分类真正难的是标签体系本身设计得不好。常见的问题有三个：

• 标签粒度不一致。有的标签是"售后问题"，有的标签是"退货退款"，层级混乱，模型想学都学不出来。
• 类别有交叉。比如"物流延迟"和"商家延迟发货"，业务上看似不同，客户话术里却几乎一样，强行分只会制造噪声。
• 正负样本极不平衡。60个标签里，前5个占80%样本，剩下55个加起来才20%，模型天然倾向于把新case分到头部的几个类里。

遇到这种问题，别急着调模型，先跟业务方把标签体系重新理一遍。把层级统一、交叉项合并、长尾类做归并或提升到一级，模型效果往往立竿见影。

5.2 大模型幻觉导致的"合理但错误"

这是全上大模型最危险、也最隐蔽的坑。大模型在工单分类里会生成一个"非常符合语义、但标签体系里根本没有"的类别描述，比如你把60个标签给它，它分出一个"客户表达不满情绪"——这个标签压根不存在，但因为看着合理，业务方很容易漏过去。

我的排查方法是每次从大模型返回结果里，做一层标签合法性校验，不合法就进人工。然后是例行抽样，每周抽100条大模型的输出，让业务人员只看"这答案能不能从工单原文直接推导出来"，如果推导不出来，就记为一个疑似幻觉case。重复出现三次，就把这类case捞出来，加进小模型的训练数据里，用有监督方式替代大模型。

5.3 视觉漏检比误检可怕得多

视觉质检里，误检顶多多报废几个良品，漏检却可能让批量不良品流出产线，这是完全不同的损失量级。所以调参的思路是"宁严勿松"：先保证缺陷召回率，再看精确率。

但这里有一个技术要点：不能只把阈值调低，那样误检会爆炸。正确的做法分两步，第一步调整模型输出置信度的判定策略，第二步在后处理里加"可疑样本自动复检"逻辑，也就是让模型阈值附近的图自动再走一次高精度模型或人工复核。在真实产线里，这种"高低精模型串联"的做法，能在漏检率不变的情况下，把误检率压下来两到三个数量级。

5.4 数据漂移：模型上线后效果下滑

任何模型上线后都会遇到数据漂移，但工单分类和视觉质检的表现形式不同。工单会出现全新话术、新业务活动带来的新问题（比如平台补贴规则变了，用户全在问补贴）；视觉质检会因光源衰减、机台震动、材料批次变化而准确率下降。

我的判断方法很简单，每两周做一次输入分布偏移检测，把小模型的输出置信度分布画出来，一旦发现"模型拒绝率显著升高"或"TOP类别的分布突变"，就要检查是不是业务侧发生了什么变化。如果是，及时补充标注数据、触发增量训练，别等着问题反馈到客诉部门才后知后觉。

最后再聊两句个人经验。我做过好几个这样的混合架构项目，最大的感受是：通用大模型确实把很多以前做不了的case变简单了，但它在企业系统里的正确用法是"专家会诊"，而不是"全科医生"。你让它在规则、小模型处理不了的边界case上发挥聪明才智，同时用严格的后校验和人工抽检兜底，它就是一个非常强的提效工具；你把它放到每一寸业务线上当主力，很快就会被运维成本、合规风险和不稳定性反噬。

如果你正在规划这类系统，我建议先把目标定小一点，哪怕只挑一个业务线、接5%的流量，用混合架构跑通闭环，拿到准确率和成本数据，再决定要不要扩大规模。这条路看起来慢，但每一步都稳。