YOLO版本选型与DeepSeek/千问融合：电子元件质检实战复盘

YOLO版本选型、大模型接入、电子元件质检这几个词放在一起，乍一看像是蹭热度的标题党，但真把这个系统从零搭完，我才发现这里面每一步都是实打实的坑。半年前朋友厂里SMT贴片线想上自动外观识别，老师傅肉眼盯AOI图盯到眼压高，问我说网上那些现成YOLO教程能不能直接拿去用。我当时没敢把话说死，回头自己花了三个多月把YOLOv8/v10/v11/v12/YOLO26全测了一遍，又接上DeepSeek和千问做语义复核，最后交付了一套能跑在产线工控机上的电子元器件目标检测与智能识别平台。这篇文章就把整个选型、训练、部署、融合大模型的过程完整复盘一遍，给想做工业视觉质检的朋友当个参考资料。

这套系统的核心链路其实不复杂：YOLO系列模型负责把图像里的电阻、电容、电感、芯片这类元件逐个框出来，模型跑完后把检测结果结构化，再交给DeepSeek或千问大模型做规则判断和异常解释，比如某个位置上缺件、极性反了、型号疑似不对，大模型会根据上下文给出判定和建议。整体架构是"YOLO做眼、大模型做脑"的分工，纯检测模型负责稳定高效的感知，大模型负责灵活多变的语义理解和人机交互。这篇文章就从这条链路上的每个坑讲起，很多结论跟网上教程写得不一样，但我实测下来就是这些结果。

1. 电子元件检测为什么不能直接套用通用模型

先泼一盆冷水：如果你只是下载一个在COCO上预训练的YOLOv8权重，然后指着电路板照片让它识别，效果会惨到让你怀疑人生。COCO的80类里根本没有贴片电阻、MLCC电容、QFP芯片这种细分类别，通用模型在工业元件上的召回率通常不到四成，而且框的位置东倒西歪，完全没有生产可用性。这不是模型能力的问题，是数据分布和目标特征差异太大。

电子元器件检测这个场景有几个非常折磨人的特点。第一是目标小，0402封装的电阻本体长度只有1.0mm，在AOI相机视野里往往就二三十个像素，属于典型的小目标检测场景，特征纹理几乎没有，全靠边缘和颜色对比度区分。第二是密集排列，一块手机主板上几百个元件挤在一起，相邻两颗电阻间距可能只有零点几毫米，NMS（非极大值抑制）阈值稍微调得不合适，会把两颗紧挨着的元件合并成一坨。第三是类间差异小、类内差异大，同样是"电容"，有陶瓷电容、钽电容、电解电容，外观差异极大，而不同容值的同一封装电容外观几乎一样，光靠视觉根本分不出来，这也是后面必须引入大模型做语义复核的原因之一。

我在项目启动阶段做过一组对比实验：把通用预训练权重直接拿到厂里的元件图片上推理，mAP50只有0.18，框得最准的居然是背景里的散热器、螺丝孔这类大目标，真正需要识别的贴片小元件漏检率超过60%。后来换用自己标注的数据重新训练，mAP50直接跳到0.93。这组数据就是一个教训：工业视觉项目里，数据工程的权重永远大于网络结构本身，先别急着换模型，先把你的标注样本搞到位。

还有一点是光照和材质问题。贴片元件表面有陶瓷、环氧树脂、金属引脚、丝印油墨多种材质，在不同角度光源下反射差异很大。同一个电容，亮场打光下像白色的小方块，暗场打光下边缘发黑、本体发灰。如果训练数据里光照单一，模型一上产线就会因为光源角度差异产生大量误检。做数据采集的时候我就学乖了，把不同角度、不同亮度、不同料盘批次的产品都拍了一轮，宁可训练集冗余一点，也不要让模型在换料后"失忆"。

2. 版本选型：YOLOv8/v10/v11/v12/YOLO26我按什么逻辑取舍的

YOLO版本多到能凑一桌麻将，v8、v10、v11、v12，现在又冒出个YOLO26，网上每个版本都有人说"最强"，真到落地的时候反而不知道怎么选。我的选择标准不跑步分，就看四点：检测头设计是否适合小目标、训练资源消耗、推理延迟、部署生态是否顺滑。下面把我实测的结果和选型逻辑摊开说。

2.1 各版本的核心差异与实测表现

YOLOv8是当前生态最成熟的版本，anchor-free的解耦检测头在2023年出来的时候算是一大进步，优点是资料全、部署工具多、导出ONNX和TensorRT基本零阻力。对小目标的处理中规中矩，我在相同数据下训出来的v8s模型mAP50有0.91，但边框偏差在小元件上会比较明显，经常出现框只框住元件一半、引脚全露在外面的情况。

YOLOv10主打NMS-free，训练和推理阶段都不需要NMS，靠双标签分配和一致匹配度度量来消除冗余框。这个设计在理论上能减少NMS参数调优的麻烦，实测推理速度确实比v8快10%左右，但在密集排列的元件场景里，少了NMS的约束之后，相邻元件的预测框偶尔会"粘"在一起，需要额外加一层后处理逻辑来拆分。如果你的元件间距很大，v10是个好选择，像我这边的排阻阵列场景就不太适合。

YOLOv11在v8基础上把C3k2和C2PSA模块加进去，特征提取能力更强，对小目标的语义信息保留更好，实测mAP50到了0.94，是这几个版本里精度最高的之一。代价是模型体积和训练时间都上涨了，v11s在相同数据下训练时间比v8s多了30%左右。如果你的产线工控机显存够，推理时延要求又不是特别苛刻，v11是精度优先场景的首选。

YOLOv12用区域注意力（Area Attention）替代传统的大核注意力，在Transformer风格模块里做了效率优化。我在RTX 4060上测试，v12n的推理速度比v8n还快一点，精度也保持了v11的水平。但它的后处理接口跟v8有差异，很多第三方部署框架对v12的支持还不完善，导出的ONNX算子偶尔会撞上兼容性问题，适合有一定工程能力、愿意花时间调部署链路的团队。

YOLO26是我最后才关注的版本，核心卖点是极致的效率设计——无卷积的backbone、动态region级别的实例感知模块，在CPU上也能跑出不错的帧率。我拿它跑了CPU下的性能测试，单张640×640图像推理约60ms，比竞品快不少，但精度上对非常小的元件表现不如v11。如果你的边缘端设备没有独立显卡，YOLO26可能是唯一能实时跑的方案。

2.2 选型结论：不是版本越新越好

最终我选了YOLOv11s作为主力检测模型，理由很简单：电子元件里0402电阻、0805电容这些目标实在太小，精度优先级最高，工控机上配的RTX 4060跑v11s能做到约7ms/帧，完全满足产线实时性要求。同时我也把YOLO26蒸馏后的版本保留下来做了备胎，一旦客户要换无显卡的NUC小主机，可以直接切换。

这里再多说一句，网上很多人把mAP跑了多少多少当卖点，但工业场景里我更关注的是单个类别的召回率和框的贴合度。YOLO检测电子元件时，框如果偏了哪怕两个像素，插入大模型做复核判断时，被裁出来的元件图像就会带上相邻元件的干扰，直接影响后续分类和质检的准确性。所以精度指标一定要看具体类别的confusion matrix，别被一个漂亮的平均mAP蒙混过去。

3. 数据工程：标注、扩充与小尺寸元件切片策略

数据是这套系统的地基，电子元件又是出了名的"看起来都差不多但实际千差万别"，所以数据工程环节我耗费的时间比训练调参还多。整个过程分三步走：原始数据采集、标注规范制定、训练集扩充。每一步都有很多常规教程不会讲的细节。

3.1 标注规范与类目设计

电子元件的类别划分不是越细越好。刚开始我天真地想把电容按容值分成好几十类，结果标注工人叫苦连天，模型也学不明白，因为不同容值同封装的电容视觉特征几乎一致，强行按容值分，等于让模型去猜它根本看不见的信息。后来我把视觉可区分的类别定为：贴片电阻（R）、陶瓷电容（MLCC）、钽电容、电解电容、电感（L）、二极管（D）、QFP芯片、BGA芯片、连接器（CN）、晶振（Y）、排阻（RA），共11类。至于具体容值、阻值、型号这些视觉无法直接判定的信息，全部交给后面的大模型，从丝印文字、料盘批次号、图纸映射这些渠道去推断。

标注工具用的是LabelImg和X-AnyLabeling配合使用。LabelImg用的人多，上手快，但它的多边形标注对于小元件不太顺手，我主要用在图片较多的初筛阶段。X-AnyLabeling自带SAM分割模型辅助标注，可以先用切片大模型把元件轮廓提出来，人工只需要确认边界，效率提升非常明显，处理一张有几十个元件的电路板图，标注时间能缩短一半以上。

标注规范里一个特别重要的细节是边框定义。贴片元件的本体是陶瓷或树脂，两侧还有金属引脚，我规定标注框必须紧贴元件本体、不包含引脚。刚开始工人图省事，把引脚也包进框里，结果训练出来的模型对引脚很敏感，导致引脚氧化变色时误检率飙升。后来严格执行本体框之后，模型学到的特征就更集中在元件本体上，抗表面差异能力明显增强。

还有一个容易被忽视的点是目标完全遮挡和边界截断。元器件在料盘上是整齐排列的，但是上了PCB之后，相邻元件可能互相遮挡，最外层元件经常被切掉一半。我的做法是在标注时把这些截断目标也标出来，不跳过，因为产线实际拍摄的图像里这些情况很常见。模型没见过截断目标，部署后遇到同样情况就会漏检。

3.2 小尺寸元件与切片策略

小目标检测是电子元件场景绕不开的坎。0402封装的元件在整张PCB图上占的像素太少，直接整图训练的话，下采样几轮之后特征就没了。业界常见的两种解法是SAHI切片推理和Tiling训练，我两条路都走了。

SAHI的做法是把大图切成固定大小的切片，比如960×960，切片之间保留一定重叠，然后对每个切片独立推理，最后把结果合并到大图坐标上。这样做的好处是能把小目标在切片中放大到正常尺寸，模型推理效果立竿见影。我测试过用SAHI处理4K分辨率的PCB图像，小目标召回率比直接整图推理提升了将近25个百分点。代价是推理次数变多，单张图从原来的几十毫秒变成几百毫秒，但对于离线质检和抽检场景完全够用。

切片重叠率我最终定在20%，既能避免目标横跨两块切片时被切碎，又不会因为重叠过多造成同一目标被重复检测、徒增后处理复杂度。合并结果时有一步很关键，就是NMS的IOU阈值要调得比平时更严格，否则同一目标在重叠区会被检测两次，输出框数量虚高，下游的大模型也会被误导。

数据扩充方面，除了常规的Mosaic、Copy-paste增强之外，我还做了两类针对性的增强。一是随机调整亮度、对比度和色温，模拟产线早上、中午、傍晚自然光和不同光源色温的变化；二是随机加入高斯噪声和模糊，模拟AOI相机对焦略有偏差时的成像效果。增强比例不能让模型太过依赖某种固定模式，Mosaic比例我控制在45%左右，过高的Mosaic会让小目标的轮廓被拼接边界切断，反而不利于学习。

4. 训练调优：损失曲线、超参与小目标召回率提升

进了训练阶段，手上的坑更多。YOLO系列虽然开箱即用，但默认参数是按COCO那种"目标占图面积大、数量少"的数据分布调的，直接拿到电子元件这种"目标小、数量多、密度高"的场景上，会有一堆不合适的预设需要手动调整。

4.1 损失函数与超参数调节经验

先说损失函数。YOLOv11默认用的CIoU损失，在电子元件场景下有个隐藏毛病：CIoU对边框中心点距离很敏感，而电子元件在图像里分布极密、彼此挨得很近，CIoU的penalty项会在密集目标上产生较大的损失波动，训练初期loss曲线上下跳得厉害。我试过把box损失切换到SIoU或WIoU，发现WIoU在小目标上的表现更好，它对低质量样本的梯度贡献做了动态加权，不容易被大量紧挨着的"难例"带偏。不过这里有个前提，如果你用的是v8框架，损失函数切换比较方便；v11/v12得改对应的ultralytics源码，不在默认config里开放，改起来要小心别把其他模块的输入输出搞乱。

img size的训练参数我也从默认的640调到了800甚至960。你可能觉得"训练尺寸越大越吃显存"，确实如此，但代价换来的收益在小目标场景里非常明显——输入尺寸从640提到800，0402电阻在特征图上的响应像素大约增加50%，模型学到的边缘特征更清晰。我实测在相同条件下，800输入的模型比640输入的模型mAP50高3到5个点，推理阶段再用SAHI配合，整体召回率完全不一样。显存不够的话，可以把batch size降到8甚至4，配合梯度累积来平衡。

anchor参数这一块，YOLOv8以后的版本都是anchor-free，不需要手动设置anchor size，但如果你用回YOLOv5或v3这类anchor-based模型做对比，一定要用k-means重新聚类出适合小目标的anchor。我之前拿默认anchor跑YOLOv5做基线，小目标召回率惨不忍睹，聚类之后才正常。这个经验放在今天也算给还在用老版本YOLO的人提个醒。

4.2 损失曲线怎么读

训练时我最常被问到的就是"损失曲线长什么样算正常"。电子元件数据集上，我观察到一条很重要的经验：box_loss下降速度比cls_loss快很多，而且前10个epoch里box_loss可能出现一个平台期，跌不动，这个时候别急着改学习率或换模型，先用验证集看一下当前权重的实际检测效果。平台期往往是因为小目标数量多、模型还没有学会区分近邻目标的边界，多训十几个epoch之后box_loss会突然掉下来，这时候精度就上去了。

学习率参数我习惯用warmup + cosine衰减，初始学习率lr0设为0.01，warmup_epochs设3个epoch。跑电子元件数据，总epoch数我设置在200到300之间，配合early stopping，当验证集mAP连续30个epoch不再提升就终止，省时间也防止过拟合。另外weight_decay建议稍微调高到0.0005左右，因为元件数据里同类目标密集出现，模型很容易对某个特定纹理"死记硬背"，正则化强一点能抑制这种倾向。

4.3 小目标召回率的针对性改进

如果训练完发现小目标召回率还是不够，第一优先尝试的不是换backbone，而是把neck部分加入更高分辨率的特征层。YOLOv11的PANet默认融合了P3、P4、P5三层特征，对于0402这种极小目标，P3层的16倍下采样还是不够细。我参考了不少YOLO改进论文的思路，在neck里增加了一个P2输出层，把4倍下采样特征也融合进来，等于在更浅层、更高分辨率的特征图上做检测，小目标召回率又能提升几个百分点。代价是推理速度下降约15%，但这点损耗在视觉质检场景完全可以接受。

另外一个非常实用的trick是负样本挖掘。检测模型在PCB图像上经常会把焊盘、过孔、丝印字符误检成元件，这类误检的样本在训练初始阶段贡献的loss很小，模型很难主动修正。我的做法是训练完一轮之后，用当前权重对训练集重新推理，把那些置信度高但标签是背景的误检区域单独切出来，作为"难负样本"加入下一轮的训练数据里，权重设为正常负样本的1.5倍。试了两轮之后，误检率从4.7%降到了0.9%，效果很明显。

5. 模型部署：导出、加速与大图推理性能压测

训练出来model.pt只是万里长征的一半，真正上产线之前，部署这一步能把很多团队卡在实验室里出不来。这里把我踩过的部署链路和性能数字交代清楚，尤其是从PyTorch到ONNX再到TensorRT的转换，每一步都有要注意的细节。

5.1 模型导出与格式转换

ultralytics框架自带导出功能，但直接export出来的ONNX文件通常带着很多冗余的shape处理节点，部署到TensorRT时计算图优化不彻底，延迟偏高。我的习惯是先导出FP32的ONNX，然后用onnx-simplifier做一轮计算图精简，去掉多余的Reshape、Transpose等算子，再用onnxruntime检查输出是否和PyTorch一致——这一步我踩过一次大坑，v12导出的ONNX在onnxruntime下输出顺序和PyTorch不一致，少了permute操作，接后处理时框全飞了。所以任何版本在导出后，都必须做一次模型输出的对拍验证，拿同一张输入图比对PyTorch与ONNX的结果，越界容忍值我卡在1e-3。

TensorRT加速是产线部署的标配。我在RTX 4060上，把YOLOv11s模型从ONNX转成TensorRT FP16引擎，单张640×640图像推理延迟稳定在3.6ms左右，比PyTorch直接推理快了将近6倍。但FP16量化在元件检测上有暗坑：小目标的梯度值在FP16下可能被截断，导致检测头输出的小响应值出现偏差，反映在结果上就是个别极小元件的置信度下降。我最终采用的是混合精度方案——整体引擎用FP16，但对检测头输出层强制保留FP32计算，这样既保证了速度，又保住了小目标精度。TensorRT的engine文件还有很重的平台绑定特性，换了显卡驱动版本之后可能需要重新生成，上线前一定把引擎构建脚本固化下来，避免现场环境变化后找不到原因。

5.2 大图推理与切片合并细节

产线AOI相机拍出来的图很多是1200万像素级别，直接把整图喂给模型不现实，显存和时间都扛不住。我最终的部署管线是这样的：先用SAHI把大图切成960×960的切片（重叠率20%），每个切片单独推理，再把所有切片的结果重新映射回原图坐标，最后在全局坐标上再做一次NMS去重。这套流程跑4K分辨率图像，单张总耗时约220ms，其中切片推理占大头，坐标映射和合并几乎不耗时间。

切片推理在工程实现上有个容易被忽略的点是切片边缘置信度惩罚。目标被恰好切成两半时，两个切片都只能看到半个元件，模型对半截目标的置信度不可靠。我的做法是对每个检测框的置信度乘以一个系数：框越靠近切片边缘，系数越小。合并时再对同一目标的多切片检测框进行加权融合，从而避免一个完整元件因为切成两半而被漏检或重复计数。这个逻辑用OpenCV和NumPy就能实现，不用上复杂框架。

5.3 性能测试的实际数据

在客户现场的工控机配置是i7-12700、RTX 4060 8G、32G内存，我把整个系统压测了三个班次，连续跑了一周，统计下来每帧640×640输入的平均推理延迟4.1ms，加上预处理、后处理和大模型复核的总耗时约30ms，远远满足产线的节拍要求。极端情况下，当大模型API调用发生网络抖动时，我做了降级策略——大模型判定结果不可用就先用规则引擎兜底，确保检测主链路不受影响。这类"主链路轻量、副链路智能"的设计思路，我认为是工业系统接大模型时最重要的工程素养，不要把所有判断都押在外部API上，核心检测必须本地自持。

6. 大模型融合：DeepSeek和千问在检测系统里到底干什么活

把YOLO模型训练好、部署好，其实系统已经能完成"框出所有元件"这个任务了。但客户真正要的不只是"框出来"，他们问得最多的问题是"这个电容的丝印是不是反了""这里到底缺没缺件""这批料里的元件型号和BOM表对不对得上"。这些问题纯靠检测模型回答不了，因为它们需要看图、读字、查表、做逻辑推理。这就是我把DeepSeek和千问大模型接进来的原因，也是这个系统被叫作"智能识别平台"而不是"检测系统"的分界点。

6.1 检测模型与大模型的分工逻辑

很多人听说大模型能做目标检测，第一反应是"那我直接用多模态大模型不就好了，还训练什么YOLO"。这个想法我在项目初期也试过，结果很诚实：直接拿Qwen-VL这类多模态模型去识别元件，单张图下来要两秒多，而且定位精度只能到"大概在这个区域"，给不出像素级坐标框，成本也更贵。反过来，纯用YOLO又只剩下"一个框+一个类名"，解释不了丝印识别错误、缺件判断这些高层语义问题。

所以我的架构选择是让大模型做"理解层"，不做"感知层"：YOLO负责把所有目标先探测出来，然后根据检测框把每个元件的局部图像裁剪出来，连同识别结果一起组合成结构化的Prompt，发给大模型做进一步判断。这样大模型面对的是被精心裁好的小图，不用在整幅大图上找目标，定位不确定性被大幅消除，回答质量和速度都上来了。实测在单张局部图上，DeepSeek的判定响应在0.5到1.5秒之间，千问的一些本地量化版本在0.8秒左右，整个链路可以接受。

6.2 千问大模型本地部署的关键取舍

千问我用的是本地部署方案，好处是不会受外部API服务状态影响，数据也不出内网，对制造业客户来说这几乎是红线要求——元件型号、PCB设计图这类数据不可能送到云端。本地部署的核心痛点是显存。Qwen2.5-VL 7B的FP16权重需要约14GB显存，工控机的8G显卡跑不动。我的解法是用GGUF量化版本地部署，或者用7B模型的int4量化版本，显存占用降到5GB左右，剩下的显存还能跑YOLO。实测int4量化会对细小的丝印文字识别造成一定精度损失——丝印字符常常只有几个像素，量化太狠会糊。折中方案是用Qwen2.5-VL 7B的int8量化部署在独立显卡上，既保证丝印识别质量，又能控制显存占用在7GB以内。

本地部署千问我用的是llama.cpp的server模式，启动命令大致是：

llama-server -m qwen2.5vl-7b-instruct-q8_0.gguf \ --host 127.0.0.1 --port 8080 \ --n-gpu-layers 999 \ --mmproj qwen2.5vl-7b-instruct-mmproj-f16.gguf

注意必须带上mmproj文件，否则模型不支持图像输入，只能当纯文本模型用。调好之后用HTTP接口发图，返回的就是模型对元件图的文字描述和判断，整个接入流程比想象中顺。

6.3 DeepSeek的API接入与Prompt设计

DeepSeek我走的是API调用模式，主要负责需要更强逻辑推理的任务，比如根据BOM表比对元件型号、判断多个元件的排列是否符合设计规则、生成自然语言质检报告。DeepSeek的API格式兼容OpenAI接口，接入成本很低，几行代码就能跑通，下面是我写的调用示例：

from openai import OpenAI client = OpenAI( api_key="your_api_key", base_url="https://api.deepseek.com/v1" ) response = client.chat.completions.create( model="deepseek-chat", messages=[ {"role": "system", "content": "你是电子元器件质检专家，根据YOLO检测结果和图片判断元件状态。"}, {"role": "user", "content": ( "检测结果如下：\n" "- 位置1: 贴片电容，置信度0.97\n" "- 位置2: 贴片电阻，置信度0.88\n" "- 位置3: 疑似异常，置信度0.55\n\n" "这是该位置的裁剪图像（见附件）。请判断位置3是否出现了缺件、错件或破损。" )} ], stream=False ) print(response.choices[0].message.content)

Prompt设计是这里面的学问。刚开始我把YOLO的完整检测结果json直接丢给模型，结果它在一堆坐标里迷失方向，回答得乱七八糟。后来我改成了"先裁图、再汇总关键信息"的两段式Prompt策略：大模型第一轮只接受裁剪后的局部图和对应位置的上下文摘要，第二轮才要求它对多个位置做综合判断。这样模型就不需要在长文本里维护太多空间对应关系，回答逻辑清晰很多。

6.4 多模态复核、结果返回与降级兜底

大模型返回结果不是拿来就能用的，工业系统最忌讳飘忽不定的判断。我设计了三个环节保证稳定性。第一是输出格式化，要求大模型以JSON格式返回结果，包含"abnormal"字段（true/false）、"reason"字段（异常原因描述）、"confidence"字段（置信度），并在代码里做严格的JSON解析和非法值校验，解析失败就自动重试一次，再失败就走兜底逻辑。第二是判断一致性检查，同一个元件的截图会间隔几秒拍两次，如果大模型两次判定结果不一致，系统标记为"待人工复核"，不让波动直接变成产线告警。第三是规则引擎兜底，对于"元件缺失""极性反装"这类规则非常明确的异常，我先用传统的图像处理算法做一版硬判断，大模型的判断只作为加分项，两者冲突时以规则引擎为准，同时记录冲突样本用于后续优化Prompt。

千问和DeepSeek不是二选一的关系，而是分工协作的关系。我用本地千问做实时性要求较高、数据敏感度也高的元件局部识别和丝印读取，用云端DeepSeek做复杂推理和跨元件综合分析。两者之间加了一层基于规则的调度器，根据任务类型自动路由请求，既控制了成本，又保证了响应速度。这样"YOLO感知+千问理解+DeepSeek推理"的三层智能架构，构成了整个平台的核心。

7. 一些属于工程实践的经验沉淀

项目结束之后，我复盘了整套流程，觉得有几个结论值得单独拿出来强调，它们不算技术突破，但在实际项目里作用很大。

第一是数据标注规范的优先级高于模型选型。无论你最后选YOLOv8还是YOLO26，标注质量决定了效果上限。我见过太多团队在模型结构上花大把时间调参，却不重视标注框的贴边程度和类别边界定义，最后精度上不去还找不到原因。电子元件这类小目标场景，标注偏差几个像素会在损失计算中被成倍放大，务必在项目启动时就把标注规范白纸黑字定下来，并且中途抽查标注质量。

第二是混合精度方案值得细抠。TensorRT的FP16加速对工业场景诱惑力太大了，但在小目标任务上不能无脑全精度量化。我的经验是至少对检测头关键层保持FP32，虽然牺牲了一点速度，但守住的是最终检测精度的底线。如果你拿到的设备显卡比较新，可以试试Bfloat16，它在小数值上的动态范围比FP16更友好。

第三是大模型不能放心托底。不管本地千问部署得多顺、DeepSeek的API调得多好，大模型输出的不确定性永远存在——它不是概率守恒的传感器，一旦遇到分布外的输入，可能一本正经地给出错误结论。所以我在整个系统里坚持规则引擎兜底、二次一致性校验、人工复核队列三位一体，把大模型定位成"经验丰富的老师傅"——建议听，但最终决策要按流程走。

这套系统目前已经在朋友的产线上跑了两个月，质检效率提升是实打实的，但后面我可以继续扩展的方向也很多，比如把AOI历史缺陷样本回流到训练集做增量学习，或者用DeepSeek生成更细粒度的缺陷描述去反哺标注环节。回头看看，YOLO和大模型的组合其实解决的是两个质不同的问题：检测要的是稳定的空间感知，理解要的是灵活的世界知识。两个模型挨在一起，中间靠严谨的工程逻辑衔接，这套东西才算真正落地能用。希望这篇复盘能给想在工业视觉里引入大模型的朋友一点参考，少走点弯路。