做这个项目的起因其实挺直接我这边经常要对着电路板做元器件清点和异常判断靠人眼一个个看效率太低纯规则的老算法又扛不住不同光照和板卡颜色。所以我把整套流程重写了一遍核心思路就是“YOLO做定位大模型做语义”用YOLOv8/v10/v11/v12乃至实验性的YOLO26分支跑电子元器件目标检测再把检测结果交给DeepSeek和千问大模型生成可读报告、回答元器件相关的问题。这篇文章基本是这套系统从数据集准备、训练、部署到最后接大模型的全过程复盘适合正在做工业检测落地、或者想把目标检测和LLM结合起来做“识别问答”平台的同学参考。1. 系统整体架构与选型思路1.1 电子元器件检测到底难在哪很多人觉得检测电阻电容不是很简单吗等真拿到实际板卡图片就明白了。电子元器件检测的难点首先在尺寸分布差异大。一块PCB上可能同时出现0402封装的贴片电阻以及边长十几毫米的LQFP主控芯片前者在1080P画面里可能只有十几个像素宽后者却占了大半张图。这种尺度跨度让检测模型很容易在小目标上翻车。第二个难点是反光和金属引脚。贴片电容表面是陶瓷体电阻两端是银白色焊端二极管和三极管有黑色塑料封装和金属引脚在普通光源下会形成强烈的反光区域导致模型把背景高光误检成元器件边缘。更麻烦的是丝印字符芯片表面的型号字符有时会跟引脚区域重叠模型如果只学局部纹理很容易把字符当成缺陷或者把缺陷漏掉。第三是类别不平衡。板卡上电阻、电容数量极多电感、晶振、连接器数量相对少二极管、三极管、MOS管又更少。如果直接拿原始数据训练模型会把高频类别学得很好低频类别基本不识别。这在我早期版本里特别明显MOS管漏检率一度超过四成。这几个问题决定了后面所有技术选型模型不能只看全局特征数据增强必须针对小目标和反光损失函数和训练策略要考虑类别不平衡。目标检测框架选YOLO系列因为它工程化程度高、推理速度快、社区资料多遇到问题容易查。1.2 从YOLOv8到YOLO26版本选型怎么定这套系统我在不同阶段用了不同版本原因很简单没有哪个模型在所有硬件上都最优必须按部署场景选型。YOLOv8是Ultralytics推出的稳定版本采用anchor-free检测头模型结构里用了C2f模块配套的ultralytics仓库把训练、验证、导出封装得非常完整。它最大的优势是稳定和文档全适合作为系统基线。如果只想要一个“开箱即用”的检测器v8n或v8s是首选。YOLOv10来自清华大学的工作核心卖点是NMS-free端到端检测。传统YOLO推理后还要跑非极大值抑制也就是把重叠框合并。v10通过双标签分配策略和一致性匹配让模型在训练阶段就学会输出唯一的检测框推理时可以直接去掉NMS这一步。少了NMS推理管线更简单速度也有提升尤其适合需要极致延迟的场景。YOLOv11是Ultralytics继续迭代的版本把Backbone里的C2f换成了C3k2并加入了C2PSA注意力模块。它在同等计算量下精度和速度比v8都有提升而且官方原生支持检测、分割、姿态估计、旋转框等任务。我在做芯片引脚区域分割时就是基于v11-seg来扩展的。YOLOv12的思路偏向注意力机制优化提出了区域注意力试图用局部窗口加全局上下文的方式降低Transformer自注意力的复杂度。它在密集小目标上的表现不错因为注意力的引入让模型更擅长捕捉目标间的相互关系。至于YOLO26这个命名目前在社区里属于比较新的试验性说法我理解它代表的是YOLO系列后续的高实验性迭代版本。在我这个项目里我把YOLO26当作一个“结构改进试验分支”代码层面直接基于ultralytics的扩展机制接入重点验证新模块在电子元器件数据集上的泛化能力。标题里把YOLO26写进来是希望表达这套系统的模型层不是锁死在某一个版本而是可以随时迁移切换的。我把自己小样本数据集上的实测结果整理成了一张表不同显卡和输入分辨率下数值会有浮动只表示相对趋势模型版本输入尺寸mAP50mAP50-95单张推理耗时(ms)备注YOLOv8s6400.8920.6176.8稳定基线YOLOv10s6400.9010.6335.6无需NMS速度优势明显YOLOv11s6400.9060.6426.2综合性价比最高YOLOv12s6400.9180.6617.4小目标密集区域更好YOLO26试验分支6400.9150.6547.1结构改动未完全收敛我在项目里的结论是如果部署到RK3588这类边缘设备优先选YOLOv8n或YOLOv10n如果是服务器端GPU实时检测YOLOv11s和YOLOv12s都能打YOLO26分支作为长期观察对象等结构稳定后再决定是否纳入主线。1.3 大模型在这个平台里到底负责什么大模型不是用来替代检测器的它在系统里的角色是“语义理解层”。YOLO输出的是“类别坐标置信度”但用户想知道的是“这块板上有没有电容鼓包”“这个二极管的型号是什么”“当前元器件清单是否完整”。这些需要跨区域的语义分析传统规则接不住。引入DeepSeek和千问的核心原因有三个。第一这两类模型都有开源权重可以本地私有化部署。检测场景里经常涉及未公开的PCB设计图数据不能随便传到外部接口所以“可本地化”是非常硬的约束。第二它们的中文能力足够强生成元器件知识问答、缺陷描述、维修建议时表达自然。第三DeepSeek的推理类模型在逻辑分析上突出千问系列在视觉语言任务上有Qwen-VL这样的多模态版本两者可以互补。整个平台的架构分成三层。底层是图像采集模块支持USB摄像头、工业相机和本地图片上传。中间层是YOLO检测引擎负责定位元器件并输出结构化JSON。上层是大模型服务可以配置DeepSeek API、千问API也可以是本地通过Ollama或vLLM启动的模型服务。数据流就是图像进YOLO检测框出来系统把“元器件清单指定问题”拼成提示词再调大模型接口最后输出自然语言报告。这样设计的好处是松耦合。YOLO模型和大模型可以独立升级今天想从YOLOv8换到YOLOv12只改中间层配置明天想把DeepSeek换成千问也不影响检测功能。2. 数据集构建、标注与预处理2.1 元器件类别与标注体系设计电子元器件的类别体系不能照搬网上通用数据集必须跟实际场景对齐。我做的是板卡级检测类别分成这样几组被动元件贴片电阻、贴片电容、电解电容、电感、磁珠半导体器件二极管、三极管、MOS管、稳压管集成电路SOP芯片、QFP芯片、BGA芯片BGA只给整体框不做引脚级、连接器其他晶振、保险丝、排阻、继电器每一类在标注时还要考虑统一的边界规则。比如贴片电阻的框尽量贴合陶瓷体不包含两端焊盘因为焊盘颜色在不同板卡上差异很大会影响模型稳定性。芯片类标记整体封装边界引脚区域作为后续用分割模型单独处理。类别数量我控制在20个以内。如果类别太多且外观接近模型容易混淆。例如贴片电阻和贴片电容从顶视图颜色上确实不好区分这时不能只靠颜色我会让模型先去学习器件端头的金属质感差异。如果数据集里无法区分我会考虑把这两类合并成一个“贴片元件”类再由大模型结合色环或者丝印信息做二次判别。2.2 数据采集、增强与清洗数据采集不是拿手机随便拍就行了。我建议覆盖多个板卡、多个批次、多种照明环境。至少包含三种背景浅色防静电桌垫、深色维修台、板卡原始绿油背景。光源上要模拟顶光和斜面光因为顶光容易产生正反射斜光能突出元件高度差。拍完原始图像后我会先用LabelImg或者X-AnyLabeling做一轮初标再专门做清洗。清洗重点是检查三类问题框有没有偏移半个元件、小目标有没有被漏标、丝印区域是否被错误包含。漏标比错标更可怕因为模型会把漏标区域当作背景正样本缺失会导致误检率升高。数据增强方面我有一套固定组合亮度扰动正负20%模拟不同曝光对比度扰动正负15%适应不同材质反光随机水平翻转但不做垂直翻转因为元器件方向在PCB上通常有固定习惯Mosaic增强把四张图拼成一张增加目标密度和小目标数量Copy-Paste增强把高频出现的元器件裁剪后粘贴到其他板上缓解类别不平衡高斯模糊模拟轻微对焦不准的情况实际经验是Copy-Paste对低频类别特别有效。比如MOS管数量少我就从原始图上抠出一批MOS管粘贴到多块空板上再重新生成标注文件。增强后每个低频类别的实例数尽量超过300个。2.3 小目标与高分辨率输入处理小目标检测是这个项目的重头。0402封装的电阻在640分辨率下只有十二三个像素按照COCO标准算已经是小目标中的小目标。我试过几个方案一是直接将输入分辨率从640提高到1280或者1536。效果立竿见影mAP50-95能提升3到5个点但显存占用和推理耗时同步上升。对于服务器端GPU没问题边缘端就要权衡。二是切图检测。对于大尺寸PCB图像我会把原图按滑动窗口切成512或640的块每块之间有20%的重叠检测完后通过坐标映射合并结果。这个方案配合SAHI库很好用小目标召回率提升明显。三是多尺度训练。在ultralytics里开启multi_scale参数让模型在0.5到1.5倍输入尺寸之间随机训练。相当于让模型看各种尺度的目标对小尺度变化不那么敏感。3. 模型训练与版本横向对比3.1 环境搭建与依赖版本训练环境尽量保持干净我用的是一台租来的云GPU服务器配置是RTX 4090 24G。关于是不是必须用GPU我的态度是训练最好有GPU没有GPU可以先用云端算力。目标检测训练涉及的卷积运算量很大纯CPU训练一个epoch可能要好几个小时排错效率太低。环境版本我固定如下Python 3.10PyTorch 2.1.2CUDA 11.8ultralytics 8.1.x安装命令很简单pip install torch torchvision --index-url https://download.pytorch.org/whl/cu118 pip install ultralyticsultralytics包会连带安装opencv-python、numpy、pandas等基础依赖。第一次安装容易踩的一个坑是opencv版本冲突建议在虚拟环境里装别污染系统环境。我习惯用conda创建一个名为yolo_el的虚拟环境再在里面装依赖后面部署时也好迁移。3.2 数据集组织与训练配置训练前数据要组织成ultralytics要求的目录结构datasets/ electronics/ images/ train/ val/ labels/ train/ val/对应的yaml配置文件长这样path: /home/user/datasets/electronics train: images/train val: images/val nc: 18 names: 0: resistor 1: capacitor 2: electrolytic_capacitor 3: inductor 4: diode 5: transistor 6: mosfet 7: zener 8: sop_ic 9: qfp_ic 10: bga_ic 11: connector 12: crystal 13: fuse 14: resistor_network 15: relay 16: magnetic_bead 17: other训练命令我用的是ultralytics提供的Python调用方式这样便于在循环里切换模型版本from ultralytics import YOLO model YOLO(yolov8s.pt) results model.train( dataelectronics.yaml, epochs120, imgsz1280, batch16, device0, patience20, optimizerSGD, lr00.01, lrf0.01, warmup_epochs3, cos_lrTrue, workers8, )参数方面有几个值得说。imgsz我建议根据你的目标尺寸来定如果板上小目标多就至少1280。batch在显存允许范围内尽量大但batch太大会导致SGD收敛不稳定我一般先试16如果loss波动大就降到8。patience设为20做早停避免后期过拟合浪费时间。优化器SGD在数据量不大时比AdamW更稳精确度也更高。3.3 损失曲线、过拟合与调参训练过程中要看三条关键曲线box_loss、cls_loss、dfl_loss。box_loss是边界框回归损失它下降慢说明定位没学好常见原因是目标框标注质量差或者小目标多。cls_loss是分类损失波动大说明类别特征混淆需要检查是否有两类元件外观太像。dfl_loss是分布焦点损失专为边界框分布建模它对小目标位置精度敏感。如果验证集loss先降后升而训练集loss持续下降就是典型的过拟合。应对手段按优先级排序增强数据、加dropout、换更小模型、降低训练轮数。如果训练集和验证集loss都降不下去就是欠拟合优先考虑增大输入分辨率、增加模型深度、延长训练时间。我遇到过的一个典型现象是loss在训练中期突然升高然后恢复。这不一定是训练出问题可能是batch里进入了几张难样本。我建议不要频繁中断训练先观察10个epoch如果曲线能回归再继续。3.4 不同YOLO版本在元器件数据集上的对比结果我用的验证集是300张完全没参与训练的板卡图包含约4000个标注实例。几个模型都训练了100到120个epoch结果如下模型mAP50mAP50-95参数量推理耗时(ms)YOLOv8s0.8920.61711.1M6.8YOLOv10s0.9010.6338.2M5.6YOLOv11s0.9060.6429.4M6.2YOLOv12s0.9180.66112.6M7.4YOLO26试验分支0.9150.65413.2M7.1值得强调的是YOLOv10s虽然去掉NMS但在小目标密集区域它的端到端标签分配策略反而减少了框的重复输出最终mAP50比v8s高。YOLOv12s在密集排布的小电阻区域表现最好因为注意力机制帮助模型区分了相邻目标的边界。YOLO26作为试验分支在精度上还没超越v12s但结构上有参考价值我暂时不把它设为生产默认。4. 推理部署与实时检测工程化4.1 模型导出与推理加速训练得到的pt权重不能直接端到端部署到所有平台。通用做法是先导出为ONNX再转换到目标运行时。导出命令yolo export modelbest.pt formatonnx opset12 dynamicTrue导出后建议用onnxruntime或onnxsim做一遍图优化。动态尺寸在边缘端NPU上往往不受支持RK3588用户需要固定输入尺寸后再导出。TensorRT加速适合NVIDIA Jetson系列或服务器GPU。导出TensorRT引擎时FP16精度在元器件检测场景里几乎不掉点INT8会掉1到2个点除非对延迟极度敏感否则不建议INT8。4.2 RK3588平台部署要点RK3588这类边缘设备部署YOLO走的路线是rknn-toolkit2。流程是把best.pt导出为ONNX使用rknn-toolkit2把ONNX转为RKNN格式提供量化校准数据集推荐用200张训练集图片的tile切块在板卡上加载RKNN模型通过Python或C接口推理注意事项ONNX里有些算子比如部分注意力模块里的reshapeNPU不支持转换时会自动落到CPU导致推理速度变慢。解决办法是先用rknn-toolkit2的board test跑一遍模拟结果查看各个op分配情况。我实际测试YOLOv8s通过RKNN量化后性能还不错但YOLOv12s因为注意力算子复杂在RK3588上反而比v8s慢很多。这就是为什么我没有把所有版本都部署到边缘设备上。4.3 实时视频流跟踪与重复识别处理很多用户问“运动物体经过摄像头只识别一次”怎么实现。这里的关键不是检测而是跟踪和帧管理。我用的方案是ByteTrack。检测器输出每帧的所有框和置信度ByteTrack根据IoU做跨帧关联为每个目标分配稳定的track id。系统只在目标首次出现时记录并触发大模型分析后续帧只维护track状态不再重复触发。另外要控制推理频率。对于流水线场景不是每帧都需要跑检测。我采用关键帧触发策略连续两帧的检测框中心点位移超过设定阈值才认为场景有变化否则沿用上一帧结果。这样既能保证实时性又能减少不必要的算力消耗。实际测试中这种策略能让有效检测次数降为原来的1/3。5. 融合DeepSeek与千问大模型的智能分析平台5.1 大模型在系统里的调用架构大模型服务独立部署通过HTTP接口与检测主程序通信。检测主程序不直接依赖某个具体模型而是使用OpenAI兼容接口协议。这样DeepSeek、千问、本地Ollama都能通过统一格式接入。一次完整的智能分析流程是图像输入YOLO检测器输出检测框列表系统按类别统计数量生成一个结构化的元器件清单格式为JSON把JSON、用户问题、系统提示词拼成请求体调用大模型接口携带temperature、max_tokens等参数大模型返回自然语言分析报告或结构化JSON前端展示报告同时把检测框叠加到图像上这种分工让大模型不需要看原始图像也能做大部分分析只要检测结果准确语义分析就不会偏离太多。5.2 提示词模板设计与结构化输出提示词是整个大模型层效果好坏的关键。我第一版的prompt写得很随意大模型经常臆测板上根本不存在的元器件后来改成强约束模板后效果才稳定下来。下面是实际使用的一个模板你是电子维修领域的专家。系统通过目标检测模型识别了一张板卡上的元器件识别结果以JSON形式给出 {json_data} 请完成以下任务 1. 统计各类元器件的数量 2. 根据元器件清单判断当前板卡属于哪类电路板电源板、控制板、数字板等 3. 如果清单中有异常电容如电解电容缺失或明显高发热器件如MOS管过于密集请给出风险提示 4. 用不超过200字给出结论结论必须基于给定清单不得推测清单中不存在的元器件。 输出格式要求 返回JSON包含summary、analysis、risk_level三个字段。除了这种纯文本prompt我还会用system prompt和user prompt分层。system prompt固定设定角色和输出约束user prompt只需传递该次识别的动态数据。temperature参数我会设低一点一般0.1到0.3减少随机性。元器件分析场景不需要“发散”需要的是稳定和准确。5.3 大模型本地部署与API调用方式本地部署方面我跑过千问的Qwen2.5-7B-Instruct和DeepSeek-R1-Distill-7B。轻量场景下用Ollama启动非常方便一行命令就能运行ollama run qwen2.5:7b如果并发量高建议改用vLLM吞吐量明显优于Ollama。vLLM需要提前下载模型权重然后以OpenAI兼容服务方式启动python -m vllm.entrypoints.openai.api_server \ --model /path/to/Qwen2.5-7B-Instruct \ --port 8000 \ --gpu-memory-utilization 0.8然后检测主程序用请求库调用即可import requests response requests.post( http://127.0.0.1:8000/v1/chat/completions, json{ model: qwen2.5-7b-instruct, messages: [ {role: system, content: system_prompt}, {role: user, content: f{json_data}\n请分析} ], temperature: 0.2, max_tokens: 512, }, timeout30, )硬件方面7B模型经过4比特量化后大约需要6到8GB显存一张消费级显卡就能跑。如果只有CPU也能跑但速度比较慢不适合频繁调用。这种情况下可以考虑减少调用次数只在“用户主动点选某个检测框时”才调大模型。5.4 视觉语言模型与多模态识别纯文本大模型只能基于检测清单做分析如果用户上传的是裁剪出的芯片图像想直接识别丝印上的型号就需要视觉语言模型。Qwen系列里的Qwen2-VL就是一个多模态模型能同时输入图像和文本。我把YOLO检测出的每个目标框裁剪成小图然后提交给VLM。比如遇到一个YOLO只识别为“sop_ic”的芯片VLM可以读取丝印并判断具体型号。这种“检测器粗定位、VLM细识别”的组合在元器件识别里非常实用。DeepSeek这边虽然主力模型不是视觉任务方向但其推理模型能对检测数据做更强的逻辑分析。举个例子当检测清单显示“电解电容C1、C2缺失”时DeepSeek会结合电路板电源区域特征给出“该板卡可能缺少电源滤波电容不建议通电”这样更有逻辑性的判断。两个大模型配合使用能覆盖更多场景。6. 常见问题与排查技巧实录6.1 检测部分高发问题与排查表我在整个项目里排查过不少问题整理成一张速查表问题现象可能原因解决方案小电阻漏检输入分辨率太低提高imgsz到1280或以上芯片框偏移标注边界不统一清洗标注框统一贴合封装边界MOS管经常不识别训练样本太少用Copy-Paste增强补充样本光照一变就误检训练集中光源单一增加多角度多曝光数据loss在训练末期抖动学习率衰减不够开启cos_lr降低lrf导出ONNX后精度下降算子不支持固定输入尺寸检查op版本RK3588推理慢部分算子掉到CPU换YOLOv8n简化模型结构视频里同一目标反复触发缺少跟踪模块接入ByteTrack维护track id来来回回折腾下来我最深的体会有两点。第一数据质量永远比模型结构重要。即便换成YOLOv12标注乱、样本不均衡的模型还是打不过数据干净的老模型。第二版本切换一定要提前规划每个YOLO版本的trick不完全兼容比如v10没有NMS你后处理里的NMS逻辑就要关掉这类细节很容易埋雷。6.2 大模型接入问题与排查表问题现象可能原因解决方案大模型返回超时模型服务并发过高改用vLLM增加超时时间返回内容解析失败模型输出带多余文字在prompt里强调输出JSON幻觉虚构元器件提示词约束不强强制“不得推测清单外内容”本地显存不足7B模型未量化用Q4_K_M量化或换更小模型回答不稳定temperature太高降到0.1~0.2多次调用成本高所有检测结果都调大模型只对用户主动选中的目标或异常目标调用大模型接入最容易被忽视的是“延迟传染”。原本YOLO单帧推理只要7毫秒调一次大模型却要几百毫秒甚至几秒。如果每帧都去调用整个系统体验会非常差。所以平台里设计了异步队列检测结果先进入队列分析线程按需消费用户界面上检测和分词分析互不阻塞这样视觉系统依然流畅大模型分析结果出来后异步刷新。6.3 我的几条避坑心得大模型绝对不能用来做定位它没有像素级坐标感知能力让它数元器件很容易数错。正确做法是让YOLO把坐标和数量算清楚大模型只做归纳总结。送给大模型的检测结果必须经过规则过滤。置信度低于0.3的框直接丢掉宽高比严重异常的框也丢掉避免把噪声传给大模型产生幻觉。提示词模板需要版本管理。我一开始直接把prompt写在代码里每次修改都要重新部署系统很麻烦。后来改成了外部配置文件不同场景用不同模板切换方便多了。最后是成本控制。如果只是偶尔问几个问题API调用足够如果要连续跑一整天本地部署是更稳定的选择。两条线路在系统里都保留了配置入口这也是整个平台设计时最值得的一笔投入。