QA-OCR:把 YOLO 和本地视觉大模型拼成一条质检闭环

终检这道工序一直很难标准化:同一块板子,换个人看结论就可能不一样,而且判定依据留在人脑里,事后追不回来。我想做一个全离线、图片不出厂的质检工具——既能出框标缺陷,又能给出一段说得清的成因分析,还要能追溯"当时是谁判的、按什么规则判的"。这篇记录 QA-OCR 的架构与几个关键取舍。

先认清硬件天花板

手上只有一张 8GB 显存的笔记本显卡,而且它同时也是我这台开发机在用的卡。这个约束基本决定了后面所有选型:

检测模型必须走 nano 级别——够快、够小,精度靠数据集质量补
分析模型必须走量化 GGUF,否则根本装不进去
检测模型和分析模型不能同时常驻,必须有一个明确的调度策略

双层架构:检测归检测,分析归分析

刻意把两件事拆开,不做端到端的"图进文出"——YOLO 负责确定性的部分(缺陷在哪、是什么类、置信度多少),视觉语言模型只负责解释性的部分(为什么会出现、工艺上怎么改)。这样检测能力可以单独训练和发布,分析能力可以单独换模型,互不牵连。

检测层:YOLO11n,四个场景模型可切换,毫秒级出框,输出类别 + 置信度 + 包围盒
分析层:llama.cpp 本地推理 Qwen 视觉语言模型,吃"原图缩略 + 标注图 + 缺陷清单",输出中文分析
调度:9B 常驻,秒级出结果;27B 按需加载做深度分析,约 10 分钟,用完自动换回 9B

四个场景,以及它们的真实成绩

steel · 钢材表面

公开数据集 1800 张,6 类缺陷(龟裂/夹杂/斑块/点蚀/氧化皮/划痕)

mAP50 99.0%

pcb · 电路板

公开数据集 1500 张,6 类缺陷(断路/短路/鼠咬/毛刺/残铜/缺孔)

mAP50 98.3%

harness · 线束装配

公开数据集 3354 张,连接器/卡扣/缝隙/扎带/标签/电缆

mAP50 78.7%

cable · 端子线束

真实缺陷图仅 92 张,8 类(缺缆/弯线/线序错/割伤/复合)

mAP50 60.9% ⚠️

小样本场景的 mAP 别当真。cable 的验证集每类只有 2 张图,60.9% 这个数字既不能说明它好用,也不能说明它没用——它只能说明"整条链路是通的"。实际策略是先把强项类推上线(缺缆、弯线这类接近 99%),割伤与复合缺陷继续攒数据,不上线,不让它拿到判定权。

这张表还说明另一件事:公开数据集上的高分很容易自欺。钢材和 PCB 都接近满分,但那是学术界清洗过的数据;真正要落地时会发现,现场光照、镜头脏污、工件姿态这些"数据之外的变量"才是主因。所以每个场景都留了自定义训练入口。

显存只有 8GB,于是做了三个取舍

用时间换显存:深度分析是低频动作,没必要为它常驻 27B。需要时加载,用完立刻换回 9B,后台线程负责切换,互斥锁保证不会并发启动两个 llama-server。
先缩小再喂:标注图在送进视觉模型前先缩到 640px。视觉 token 数是显存的直接开销,这一步省下来的显存比换更小的模型还划算。
把释放交给操作系统:推理子进程绑到主进程的作业对象上,关掉服务窗口就自动回收显存,不依赖"记得手动 kill"这种纪律。

检测完不是终点:把"为什么"也说清楚

只有包围盒的质检工具,一线是不买账的——他知道这里有划痕,但他想知道的是是不是上一道工序的刀具该换了。所以每次检测之后都会把结果送进视觉模型做一次成因分析:

秒级分析(9B):三段式输出——缺陷确认 / 可能成因 / 改进建议
深度分析(27B):四段式输出——缺陷复核 / 根因分析 / 工艺参数建议 / 预防与检验

提示词按场景动态化(每个场景登记自己的材料与工位描述),新增场景只要在模型表和中文类别映射里加条目,不用改分析流程。

质检闭环:三个版本必须能追溯

这是我坚持要做、而且认为比模型精度更重要的一块。质检系统只要说不清"这条判定是怎么来的",它在体系上就是不可用的。

模型版本化:训练完成后自动在测试集评估(mAP50、mAP50-95、精确率、召回率),登记为草稿版本;只有发布过的版本才会被检测接口使用。
规则版本化:判定规则不是写死在代码里的常量,而是可配置项——最小置信度、允许缺陷数、哪些类别直接判 NG、低置信度转人工复核。
版本快照落库:每次检测都固定写入"当时用的模型版本 + 规则版本 + 规则内容快照"。规则后来改了,不代表昨天的判定记录会跟着变。
复核回写:人工或上游系统可以对某次检测提交最终结论(PASS / NG / 人工复核)与备注,和原始检测记录关联在一起。

原图与标注图按日期分目录留档,追溯接口按检测号一次性把图片、缺陷明细、模型版本、规则快照全带回来。

自定义场景:一条从数据到模型的完整链路

# 自定义场景 = 四道人工闸,不是"传图就能识别"
1. 上传原始图片
2. 在线框选标注
3. 按 8:2 拆分数据集
4. 保存训练配置
5. 启动训练
6. test 集自动评估
7. 登记为草稿版本
8. 发布后检测接口才认

# 限制:单次 200 张、单张 20MB
# 支持 JPG / PNG / BMP / WEBP

标注页支持撤销上一个框、删除最近一个框、以及 Ctrl/Cmd+Z——这种细节不加,标注的人会烦到不愿意用第二次。上传入口只负责采集数据,没有标注的图片进不了训练集,这一点在文档里写死了,免得被误解成"传图即训练"。

让上游系统敢调:先把错误码说清楚

这套服务最终会被 MES 或人工工位调用,所以我把异常返回值收敛成一组固定语义,而不是让它抛一堆内部堆栈:

INVALID_IMAGE      图片读不了 / 格式不支持
MODEL_NOT_FOUND    请求的模型 key 不存在
GPU_OOM            显存不足
INFERENCE_TIMEOUT  推理超时
LLAMA_CRASH        分析模型进程挂了
DISK_FULL          留档目录写不进去

语义明确之后,调用方才能写对策略:哪些该重试、哪些该转人工复核、哪些要直接告警。健康检查接口会同时探模型文件、GPU、训练占用和存储可写状态,用一个 ok / degraded 表明服务是否还能承担检测。

当前状态

本地已经跑通:四场景检测、批量与随机样本、秒级与深度两档成因分析、统计看板与历史导出、在线标注与训练中心、模型/规则/检测三表追溯。下一步三件事——补端子线束场景的真实缺陷样本;把 27B 的深度分析改成异步任务队列(现在会阻塞一次请求十分钟);给规则加灰度机制,新规则先在历史样本上回放,确认不会误杀再上线。

写在最后:这个项目让我改了一个看法。以前觉得质检 AI 的难点在模型精度,做完才发现精度只是入场券——真正决定它能不能在产线活下来的是可追溯、可解释、可回退。判错的代价不是"准确率掉一个点",而是"出了一批不良品却说不清是谁放行的"。

← 返回博客列表