Ultralytics YOLO：工业级目标检测的最短路径

从 12 条产线的人工目检，到单卡 TensorRT 实时质检

去年接手的是一个很典型的场景：一家做汽车冲压件的客户，三条产线、每班 6 个质检工位，靠人眼在传送带末端看表面缺陷——划痕、凹坑、油污。件流节拍 2 秒一件，单班 8 小时要过 1.4 万件。问题不是"看不见"，而是人到了第 6 个小时就开始漏，内部抽检统计漏检率长期在 8% 左右，客诉一次就是整批退货。

需求方给的话很直白："能不能做成相机拍一下、屏幕上画个框，超阈值就报警。"没有预算做算法团队，也没有半年时间做研究。这就是我选 Ultralytics YOLO 的全部背景——这是工业级目标检测最短的那条路。

需求拆解

• 数据：现场只有产线历史视频和 300 多张零星标注过的缺陷图，没有成规模的数据集。需要一套能快速扩标注、快速迭代的训练流程。
• 性能：单件检测必须在 300ms 内出结果，才能跟上 2 秒节拍并留出 PLC 分拣动作时间。缺陷最小只有 6~10 像素，小目标召回是硬指标。
• 成本：硬件预算单线不超过一台工控机 + 一张消费级卡（RTX A2000 级别），不接受云端推理。
• 部署约束：必须离线运行、开机自启、不依赖 Python 环境依赖地狱；同时产线环境不能联网更新模型。

方案设计：为什么是它

备选有三条路：Detectron2/MMDetection 自训、买商用视觉软件、或者 YOLO 系。

Detectron2 的精度上限确实更高，但对这个项目是负收益——配置文件分层、注册机制、导出链路都要自己写，一个工程师两周内跑不出可交付的 demo。商用软件（本地几家做视觉的厂商）报价在六位数，且规则型算法对"油污"这种灰度渐变的缺陷几乎无解，改一次规则要重新走商务流程。

YOLO 的优势不在精度，在闭环的完整度：ultralytics 一个包把数据校验、训练、验证、导出、推理、多任务（检测/分割/分类/姿态）全串好了，CLI 和 Python API 双入口。目前仓库已经到 62,154 star，YOLO 主线更新到 YOLO26/YOLO27，社区问答和踩坑记录密度极高，这在工业项目里比多 1 个点 mAP 值钱得多。

取舍上我们做了一个明确的决定：先锁 YOLO11s，不追最新最大的模型。原因是这个规模的缺陷检测，瓶颈在数据和输入分辨率，不在骨干网络；YOLO11s 的 TensorRT 导出路径最成熟、坑最少。第二阶段再评估迁移。

另一个必须提前说明的点：仓库协议是 AGPL-3.0，这个和精度无关，但会直接决定项目能不能卖——后面踩坑章节展开。

落地实现

步骤一：数据准备（Labelme → YOLO 格式）

现场先用 Labelme 标了 1,200 张，再写脚本转 YOLO 的 txt 格式。注意 Labelme 的矩形标注取 points 的前两点即可：

import json
from pathlib import Path

CLASSES = {"scratch": 0, "dent": 1, "stain": 2}

for js in Path("raw").glob("*.json"):
    d = json.loads(js.read_text())
    h, w = d["imageHeight"], d["imageWidth"]
    lines = []
    for sh in d["shapes"]:
        (x1, y1), (x2, y2) = sh["points"][:2]      # 矩形标注取两点
        cx, cy = (x1 + x2) / 2 / w, (y1 + y2) / 2 / h
        bw, bh = abs(x2 - x1) / w, abs(y2 - y1) / h
        lines.append(f"{CLASSES[sh['label']]} {cx:.6f} {cy:.6f} {bw:.6f} {bh:.6f}")
    (Path("labels") / f"{js.stem}.txt").write_text("
".join(lines))

数据 YAML 里最容易被忽略的是 path 用绝对路径，否则换机器训练直接找不到文件：

path: /data/stamping
train: images/train
val: images/val
names:
  0: scratch
  1: dent
  2: stain

步骤二：训练

关键配置只有三个：imgsz=1280（小目标必须放大输入）、cache="disk"（数据集不到 3G，省掉每 epoch 的 IO）、close_mosaic=15（最后 15 轮关掉 Mosaic，让模型收敛到真实分布）。

from ultralytics import YOLO

model = YOLO("yolo11s.pt")
model.train(
    data="/data/stamping/defects.yaml",
    epochs=150,
    imgsz=1280,
    batch=8,          # A2000 12G，1280 下 8 是安全值
    device=0,
    workers=8,
    cache="disk",
    patience=30,
    mosaic=0.5,
    close_mosaic=15,
    project="runs/defect",
    name="v1",
)
m = model.val(split="val")
print(m.box.map50, m.box.map)     # 0.941 / 0.712

步骤三：导出与部署

不要用 PyTorch 权重上产线。导出 TensorRT FP16，推理延迟能降一个数量级：

yolo export model=runs/defect/v1/weights/best.pt 
    format=engine half=True imgsz=1280 dynamic=False batch=1

推理侧只保留一个薄封装，产线主程序用 PLC 触发拍照后调用：

from ultralytics import YOLO

model = YOLO("best.engine", task="detect")

def infer(frame):
    r = model.predict(frame, imgsz=1280, conf=0.35, iou=0.5, verbose=False)[0]
    return [
        {"cls": model.names[int(b.cls)], "conf": float(b.conf),
         "xyxy": [round(v, 1) for v in b.xyxy[0].tolist()]}
        for b in r.boxes
    ]

效果与数据

踩过的坑

坑一：验证集 mAP 0.96，上线漏检一堆

现象：训练日志漂亮得不像话，mAP50 冲上 0.96，但现场跑起来划痕类漏检明显。
排查：翻数据来源发现，训练集是从产线视频按帧抽的，相邻帧内容几乎一样。随机划分 train/val，等于把同一个缺陷的相邻帧同时塞进了两边——数据泄漏，验证集是"背答案"背出来的。
解决：改成按工单号/拍摄批次分组划分，同一批次的帧只能进同一侧。重训后 mAP50 掉到 0.941，但这才是真实水平。这个数字反而比 0.96 更让我踏实。

坑二：小目标召回只有 0.62

现象：scratch 类比其他两类低一截，可视化预测结果发现小于 10px 的细长划痕基本没框出来。
排查：把 GT 框尺寸统计出来，最小的一批只有 6×40 px。imgsz 640 时下采样 32 倍，特征图上只剩不到 1 个格子。
解决：两条腿。一是 imgsz 提到 1280；二是相机位置固定，直接裁 ROI——只把传送带上真正有料的那块区域送进模型，等效放大分辨率而且推理耗时不增反降。conf 阈值也从 0.25 提到 0.35，牺牲一点召回换误报可控。

坑三：AGPL-3.0，法务在验收前一周叫停

现象：内部产线自用时没问题，但客户想把这套检测能力打包进他们对外销售的设备控制软件里，法务审查时标红了整个仓库。
排查：Ultralytics 是 AGPL-3.0，网络服务分发同样触发开源义务。产品化分发场景下，要么整体开源，要么拿商业授权。
解决：最终走的是购买 Ultralytics Enterprise License。建议任何要把 YOLO 嵌进闭源产品的团队，在写第一行训练代码之前就把这件事对齐，别等到上线前一周。

复盘与扩展

做对的：一是没有一上来追最新最大的模型，YOLO11s 先把闭环跑通；二是把"输入分辨率"当成第一优先级，ROI 裁剪这个动作既是精度优化也是性能优化；三是训练超参全部固化在脚本里，换了三次数据都能一键复现。

做得不够的：没有做数据版本管理，第 4 版数据集和标注改动一度对不上账，后来才补了 DVC；另外 2.7% 的过杀率一直靠人工扛，没有建立误报样本回流 + 主动学习的机制，这是最该补的一块。

可扩展方向：缺陷边界对工艺分析有价值，下一步可以切到实例分割任务，同一套数据加多边形标注即可；产线连续件需要计数和去重，可以接 object tracking；边缘侧如果换 Jetson，TensorRT engine 可以复用，但要重新在目标设备上编译；最后，把过杀样本自动入库、每周增量微调，是整个系统真正从"能用"走到"好用"的关键一步。