简介本资源为面向计算机视觉与目标检测学习者的电池识别数据集聚焦9伏电池、纽扣电池与干电池三类常见电池的检测任务适合从事YOLO系列模型训练、工业分拣或智能回收场景的开发者与研究人员使用。压缩包内共2000个文件以1999个txt标注文件和1个yaml配置文件为主txt文件对应每张图像的YOLO格式标注框信息yaml则用于定义数据集路径与类别名称整体包大小约65.72MB便于快速接入训练流程。数据集包含2030张原始图像分辨率统一为640×640采用yolov7标注格式官方给出正确识别率可达97.7%可直接用于模型微调与性能验证。目前已有48人学习下载适合需要快速构建电池检测基线、对比不同检测算法效果或补充小目标样本的读者参考使用。1. 电池数据集上手2030 张原始图与 97.7% 识别率意味着什么产线上混料是电池行业最头疼的问题之一。9V 方形电池、CR2032 纽扣电池、5 号干电池外形差异看着大但一旦散落在料框里、被反光铝箔或传送带阴影干扰人眼分拣的效率和准确率都会掉得很快。这份电池数据集就是冲着这个场景来的2030 张 640×640 分辨率的原始图按 YOLOv7 格式标注覆盖 9 伏、纽扣电池、干电池三类目标官方给出的正确识别率是 97.7%。它不是一份玩具级 demo 数据而是能直接拿去训练、验证、部署到分拣工位上的工程素材。适合谁用做工业质检、电池回收分选、智能仓储的算法工程师以及正在找真实场景数据练 YOLO 系列模型的学生和独立开发者。如果你手上只有 COCO、VOC 那类通用数据集想验证自己的检测 pipeline 在细长目标、密集小目标上的表现这份数据能帮你省掉大量采集和标注成本。下面从数据本身的结构讲起一路落到训练、验证和踩坑。2. 拆开这份电池数据集YOLOv7 标注格式与 640×640 预处理链路拿到一份标注数据第一件事不是急着训练而是搞清楚它的目录结构、标签格式和图像预处理方式。这份数据集的文件命名里带着.rf.哈希串说明它经过了一轮增强或版本固化处理原始视频帧被抽帧、缩放、重命名后统一成 640×640。理解这条链路才能判断训练时要不要再做额外的 resize 或 letterbox。2.1 目录结构与标签文件对应关系从项目正文给出的文件列表看图像和标签是成对出现的命名规则是「图像名 .rf. 哈希 .txt」。比如IMG_0889_jpeg.rf.c74f78590a360739c070f2876fa85ffd.txt对应IMG_0889_jpeg.rf.c74f78590a360739c070f2876fa85ffd.jpg。带-E9-9B-BB...前缀的那批是 URL 编码的中文文件名解码后是「电池」相关的视频抽帧mp4-t-9、mp4-t-10表示来自不同视频的第 9、10 帧。标准 YOLOv7 数据集目录长这样battery_dataset/ ├── images/ │ ├── train/ │ ├── val/ │ └── test/ ├── labels/ │ ├── train/ │ ├── val/ │ └── test/ └── data.yamlimages和labels下的子目录必须同名同结构YOLOv7 靠路径替换找标签把images换成labels、.jpg换成.txt。如果标签和图像不在对应位置训练时会出现「找不到标签」或「全部当背景」的情况这是新手最常见的翻车点。2.2 YOLO 标签格式与类别索引每个.txt文件里一行一个目标格式是class_id x_center y_center width height后四个值都是归一化到 0~1 的相对坐标。三类电池的class_id通常是 0、1、2具体顺序要看data.yaml里的names列表。假设顺序是[9v, button, aa]那么一行1 0.512 0.634 0.087 0.121表示图中有个纽扣电池中心在图像宽 51.2%、高 63.4% 的位置框宽占 8.7%、高占 12.1%。纽扣电池在 640×640 图里往往只占几十个像素归一化后宽高可能只有 0.05 左右。这种小目标对 anchor 匹配和正样本分配很敏感后面训练参数那节会专门讲怎么调。2.3 640×640 预处理的两种做法原始图已经是 640×640理论上可以直接送进网络。但 YOLOv7 默认输入是 640×640 且带 letterbox如果你在 dataloader 里再 resize 一次等于二次缩放小目标会更糊。常见做法是确认图像真实尺寸from PIL import Image import os img_dir battery_dataset/images/train sizes set() for name in os.listdir(img_dir)[:50]: with Image.open(os.path.join(img_dir, name)) as im: sizes.add(im.size) print(sizes) # 期望输出 {(640, 640)}如果输出全是(640, 640)就在data.yaml里把rect设为False让所有图统一 resize 到 640避免 letterbox 引入灰边。如果混入了非 640 的图就保持rect: True让 YOLOv7 按 batch 内最长边做 padding。这一步判断错了mAP 可能差好几个点属于典型的「玄学掉点」来源。提示先跑一遍尺寸统计再决定rect取值不要凭感觉设。3. 用 YOLOv7 训练电池检测模型data.yaml、超参与小目标调优数据摸清楚了接下来是把它喂给 YOLOv7。这一章按「配置文件 → 启动命令 → 关键超参 → 小目标处理」的顺序走每一步都给可抄的代码和参数解释。训练环境建议 PyTorch 1.12、CUDA 11.3 以上显存 8G 起步batch size 先设 8 试水。3.1 写对 data.yamldata.yaml是训练入口路径写错直接报错退出。参考配置# battery_dataset/data.yaml train: ./battery_dataset/images/train val: ./battery_dataset/images/val test: ./battery_dataset/images/test nc: 3 names: [9v, button, aa]nc是类别数必须和names长度一致也和标签里的最大class_id 1一致。三者对不上时YOLOv7 会在 loss 计算阶段报 index 越界或者把某类全部漏检。train/val用相对路径时是相对于你执行训练命令的工作目录不是相对于data.yaml所在目录这点和 YOLOv5 一致容易搞混。3.2 启动训练与关键参数YOLOv7 官方仓库的训练命令python train.py \ --weights yolov7.pt \ --cfg cfg/training/yolov7.yaml \ --data battery_dataset/data.yaml \ --hyp data/hyp.scratch.p5.yaml \ --epochs 150 \ --batch-size 8 \ --img-size 640 640 \ --device 0 \ --workers 4 \ --name battery_yolov7逐项说明--weights yolov7.pt用 COCO 预训练权重做迁移2030 张图从零训容易过拟合--hyp选hyp.scratch.p5.yaml如果显存吃紧可以换hyp.scratch.tiny.yaml配合 tiny 模型--img-size 640 640和数据集分辨率对齐--workers在 Windows 上设 0 或 2设大了容易卡死--name决定runs/train/下的输出目录名。150 epoch 是经验值。2030 张图、3 类目标通常 100~200 epoch 收敛。看results.txt里的mAP0.5连续 20 epoch 不涨就可以停。3.3 小目标与类别不平衡的处理纽扣电池是小目标干电池和 9V 相对大。如果直接训模型容易偏向大目标纽扣电池的 recall 会偏低。三个可调点第一改 anchor。用 k-means 在自家数据上重新聚类python utils/autoanchor.py \ --data battery_dataset/data.yaml \ --img-size 640 \ --anchors 9输出的 9 个 anchor 替换cfg/training/yolov7.yaml里的anchors字段。小目标多时最小的 anchor 可能从默认的(12,16)缩到(8,10)左右。第二调 loss 权重。在 hyp 文件里把box从 0.05 提到 0.07~0.08让回归损失占比更高小框定位更准。cls保持 0.5 左右obj保持 1.0。第三过采样。如果某一类样本明显少可以在train.txt里重复列出该类图像路径或者用--image-weights开启按类别频率加权采样。2030 张图里三类分布如果不均这一步比调 anchor 更直接。注意改完 anchor 和 hyp 后先用--epochs 10跑个短训确认 loss 正常下降再开长训别一上来就 150 epoch 等结果。4. 验证 97.7% 识别率mAP 指标、混淆矩阵与推理脚本训练完拿到best.pt下一步是验证它到底有没有 97.7% 的水平。这里的「正确识别率」在目标检测里通常指mAP0.5或分类准确率两者口径不同必须自己复现一遍才算数。这一章讲怎么用官方test.py跑指标、怎么看混淆矩阵、怎么用detect.py做单图推理。4.1 跑 test.py 拿 mAPpython test.py \ --weights runs/train/battery_yolov7/weights/best.pt \ --data battery_dataset/data.yaml \ --img-size 640 \ --batch-size 8 \ --task val \ --device 0 \ --name battery_eval--task val用验证集--task test用测试集。输出里关注三行mAP0.5、mAP0.5:0.95、每类的P/R。如果mAP0.5在 0.97 附近说明和官方给的 97.7% 对得上如果只有 0.85先别怀疑数据检查data.yaml的val路径和标签是否真的加载了。4.2 混淆矩阵怎么读YOLOv7 会在runs/val/下生成confusion_matrix.png。横轴是预测类纵轴是真实类对角线越深越好。常见问题纽扣电池被大量预测成背景最后一列说明小目标漏检干电池和 9V 互相混淆说明两类特征区分度不够可能需要更多 9V 侧面角度的图。import matplotlib.pyplot as plt import matplotlib.image as mpimg img mpimg.imread(runs/val/battery_eval/confusion_matrix.png) plt.figure(figsize(8, 8)) plt.imshow(img) plt.axis(off) plt.show()看矩阵时重点盯非对角线的大块。如果某一类的漏检率超过 10%回到训练阶段补该类样本或调conf阈值。4.3 单图与批量推理python detect.py \ --weights runs/train/battery_yolov7/weights/best.pt \ --source battery_dataset/images/test \ --img-size 640 \ --conf-thres 0.25 \ --iou-thres 0.45 \ --device 0 \ --save-txt \ --name battery_infer--conf-thres 0.25是置信度阈值低于它的框不输出。工业分拣场景如果追求高召回可以降到 0.15~0.2代价是误检增多如果追求高精度提到 0.4~0.5。--iou-thres 0.45控制 NMS 合并密集小目标场景可以降到 0.3~0.4避免相邻纽扣电池被合并成一个框。--save-txt会把预测结果按 YOLO 格式存下来方便和真值做逐图对比。提示conf和iou这两个阈值没有万能值按你的业务是「宁可错杀」还是「宁可放过」来定定完在验证集上跑一遍看 P/R 曲线。5. 电池检测落地避坑从标签错位到小目标漏检的 5 个排查点数据、训练、验证都跑通了真正部署到产线或集成到系统里时坑才集中冒出来。这一章列 5 个我实际遇到过的翻车场景每条按「现象 → 原因 → 解决」写方便你对照排查。5.1 训练 loss 正常但 mAP 极低现象loss 一路下降mAP0.5却卡在 0.1 以下。原因标签路径没对上YOLOv7 把图当成了全背景样本loss 靠obj项在降但学不到任何目标。解决检查labels/train下.txt数量和images/train下图片数量是否一致文件名除扩展名是否一一对应。用脚本快速核对import os img_dir battery_dataset/images/train lbl_dir battery_dataset/labels/train imgs {os.path.splitext(f)[0] for f in os.listdir(img_dir)} lbls {os.path.splitext(f)[0] for f in os.listdir(lbl_dir)} print(缺标签:, imgs - lbls) print(缺图像:, lbls - imgs)5.2 纽扣电池 recall 明显低于其他类现象干电池和 9V 的 recall 都在 0.95 以上纽扣电池只有 0.7~0.8。原因小目标在 640 分辨率下像素太少默认 anchor 匹配不上正样本分配不足。解决按 3.3 节重新聚类 anchor把最小 anchor 缩小同时把hyp里的box损失权重提到 0.07~0.08并在验证时把conf-thres降到 0.2 观察 recall 变化。5.3 推理时同一颗电池出多个框现象一张图里一颗纽扣电池被画了 3~4 个重叠框。原因NMS 的iou-thres设太高比如 0.7相邻框没被合并。解决把--iou-thres降到 0.3~0.45密集场景可以到 0.3。如果降了还不行检查是不是训练时同一目标被标了多次标签文件里出现重复行。5.4 换一批新图后准确率暴跌现象验证集 97%换产线新拍的图只有 70%。原因训练集和实际场景存在域偏移光照、背景、拍摄角度不一致。解决从新场景里抽 100~200 张按同样规范标注后加入训练集做微调学习率调到 0.001 左右训 30~50 epoch。别指望一份数据覆盖所有产线。5.5 显存溢出或训练中途卡死现象CUDA out of memory或--workers设大后进程卡住。原因batch size 或 workers 超过机器承受能力Windows 下多进程 dataloader 尤其容易出问题。解决--batch-size从 8 降到 4 或 2--workers在 Windows 上设 0Linux 上设 4~8。显存还是不够就换yolov7-tiny精度掉一点但能跑起来。6. 把电池检测模型压到产线ONNX 导出与 TensorRT 加速的实操细节训练和验证都过了最后一步是让模型在产线工控机上跑得动。PyTorch 原生推理在 CPU 上单图要几百毫秒跟不上传送带节拍。常见做法是导出 ONNX再用 TensorRT 或 OpenVINO 加速。这一章给导出脚本、精度对齐方法和一个我踩过的坑。6.1 导出 ONNXpython export.py \ --weights runs/train/battery_yolov7/weights/best.pt \ --img-size 640 640 \ --batch-size 1 \ --simplify \ --include onnx--simplify会调用 onnx-simplifier 去掉冗余节点--batch-size 1对应产线单图推理。导出后在同目录得到best.onnx。验证 ONNX 和 PyTorch 输出是否一致import onnxruntime as ort import numpy as np import torch # 随机输入 x np.random.rand(1, 3, 640, 640).astype(np.float32) sess ort.InferenceSession(best.onnx) onnx_out sess.run(None, {sess.get_inputs()[0].name: x}) model torch.load(best.pt, map_locationcpu)[model].float().eval() with torch.no_grad(): torch_out model(torch.from_numpy(x))[0].numpy() print(最大绝对误差:, np.abs(onnx_out[0] - torch_out).max())误差在 1e-3 以内算正常超过 1e-2 说明导出有问题重点查--img-size和--simplify是否和训练时一致。6.2 TensorRT 加速与精度对齐工控机有 NVIDIA 显卡时用trtexec把 ONNX 转成 enginetrtexec \ --onnxbest.onnx \ --saveEnginebest.engine \ --fp16 \ --workspace2048--fp16开启半精度速度能提 1.5~2 倍精度通常掉 0.1~0.3 个点。如果业务对精度敏感去掉--fp16用 FP32。--workspace是显存上限单位 MB按显卡调整。转完后用同一批测试图对比 engine 和 PyTorch 的检测框重点看纽扣电池有没有因为 FP16 量化而漏检。我遇到过 FP16 下小目标置信度从 0.6 掉到 0.3 的情况最后退回 FP32 才稳住。6.3 一个血泪教训最早部署时我图省事直接拿训练时的conf-thres 0.25上产线结果纽扣电池漏检率偏高。后来在验证集上画了 P-R 曲线发现 recall 要到 0.98 得把阈值降到 0.12代价是误检多了 3%。产线能接受误检人工复核一遍但不能接受漏检混料流出所以最终定了 0.12。从那以后我每次部署前都强制走一遍「P-R 曲线定阈值」的流程不再拍脑袋设参数。希望这份电池数据集和上面的流程能帮你少走几段弯路。本文还有配套的精品资源点击获取
基于YOLOv7的电池检测实战：2030张数据集训练、97.7%识别率验证与产线部署
简介本资源为面向计算机视觉与目标检测学习者的电池识别数据集聚焦9伏电池、纽扣电池与干电池三类常见电池的检测任务适合从事YOLO系列模型训练、工业分拣或智能回收场景的开发者与研究人员使用。压缩包内共2000个文件以1999个txt标注文件和1个yaml配置文件为主txt文件对应每张图像的YOLO格式标注框信息yaml则用于定义数据集路径与类别名称整体包大小约65.72MB便于快速接入训练流程。数据集包含2030张原始图像分辨率统一为640×640采用yolov7标注格式官方给出正确识别率可达97.7%可直接用于模型微调与性能验证。目前已有48人学习下载适合需要快速构建电池检测基线、对比不同检测算法效果或补充小目标样本的读者参考使用。1. 电池数据集上手2030 张原始图与 97.7% 识别率意味着什么产线上混料是电池行业最头疼的问题之一。9V 方形电池、CR2032 纽扣电池、5 号干电池外形差异看着大但一旦散落在料框里、被反光铝箔或传送带阴影干扰人眼分拣的效率和准确率都会掉得很快。这份电池数据集就是冲着这个场景来的2030 张 640×640 分辨率的原始图按 YOLOv7 格式标注覆盖 9 伏、纽扣电池、干电池三类目标官方给出的正确识别率是 97.7%。它不是一份玩具级 demo 数据而是能直接拿去训练、验证、部署到分拣工位上的工程素材。适合谁用做工业质检、电池回收分选、智能仓储的算法工程师以及正在找真实场景数据练 YOLO 系列模型的学生和独立开发者。如果你手上只有 COCO、VOC 那类通用数据集想验证自己的检测 pipeline 在细长目标、密集小目标上的表现这份数据能帮你省掉大量采集和标注成本。下面从数据本身的结构讲起一路落到训练、验证和踩坑。2. 拆开这份电池数据集YOLOv7 标注格式与 640×640 预处理链路拿到一份标注数据第一件事不是急着训练而是搞清楚它的目录结构、标签格式和图像预处理方式。这份数据集的文件命名里带着.rf.哈希串说明它经过了一轮增强或版本固化处理原始视频帧被抽帧、缩放、重命名后统一成 640×640。理解这条链路才能判断训练时要不要再做额外的 resize 或 letterbox。2.1 目录结构与标签文件对应关系从项目正文给出的文件列表看图像和标签是成对出现的命名规则是「图像名 .rf. 哈希 .txt」。比如IMG_0889_jpeg.rf.c74f78590a360739c070f2876fa85ffd.txt对应IMG_0889_jpeg.rf.c74f78590a360739c070f2876fa85ffd.jpg。带-E9-9B-BB...前缀的那批是 URL 编码的中文文件名解码后是「电池」相关的视频抽帧mp4-t-9、mp4-t-10表示来自不同视频的第 9、10 帧。标准 YOLOv7 数据集目录长这样battery_dataset/ ├── images/ │ ├── train/ │ ├── val/ │ └── test/ ├── labels/ │ ├── train/ │ ├── val/ │ └── test/ └── data.yamlimages和labels下的子目录必须同名同结构YOLOv7 靠路径替换找标签把images换成labels、.jpg换成.txt。如果标签和图像不在对应位置训练时会出现「找不到标签」或「全部当背景」的情况这是新手最常见的翻车点。2.2 YOLO 标签格式与类别索引每个.txt文件里一行一个目标格式是class_id x_center y_center width height后四个值都是归一化到 0~1 的相对坐标。三类电池的class_id通常是 0、1、2具体顺序要看data.yaml里的names列表。假设顺序是[9v, button, aa]那么一行1 0.512 0.634 0.087 0.121表示图中有个纽扣电池中心在图像宽 51.2%、高 63.4% 的位置框宽占 8.7%、高占 12.1%。纽扣电池在 640×640 图里往往只占几十个像素归一化后宽高可能只有 0.05 左右。这种小目标对 anchor 匹配和正样本分配很敏感后面训练参数那节会专门讲怎么调。2.3 640×640 预处理的两种做法原始图已经是 640×640理论上可以直接送进网络。但 YOLOv7 默认输入是 640×640 且带 letterbox如果你在 dataloader 里再 resize 一次等于二次缩放小目标会更糊。常见做法是确认图像真实尺寸from PIL import Image import os img_dir battery_dataset/images/train sizes set() for name in os.listdir(img_dir)[:50]: with Image.open(os.path.join(img_dir, name)) as im: sizes.add(im.size) print(sizes) # 期望输出 {(640, 640)}如果输出全是(640, 640)就在data.yaml里把rect设为False让所有图统一 resize 到 640避免 letterbox 引入灰边。如果混入了非 640 的图就保持rect: True让 YOLOv7 按 batch 内最长边做 padding。这一步判断错了mAP 可能差好几个点属于典型的「玄学掉点」来源。提示先跑一遍尺寸统计再决定rect取值不要凭感觉设。3. 用 YOLOv7 训练电池检测模型data.yaml、超参与小目标调优数据摸清楚了接下来是把它喂给 YOLOv7。这一章按「配置文件 → 启动命令 → 关键超参 → 小目标处理」的顺序走每一步都给可抄的代码和参数解释。训练环境建议 PyTorch 1.12、CUDA 11.3 以上显存 8G 起步batch size 先设 8 试水。3.1 写对 data.yamldata.yaml是训练入口路径写错直接报错退出。参考配置# battery_dataset/data.yaml train: ./battery_dataset/images/train val: ./battery_dataset/images/val test: ./battery_dataset/images/test nc: 3 names: [9v, button, aa]nc是类别数必须和names长度一致也和标签里的最大class_id 1一致。三者对不上时YOLOv7 会在 loss 计算阶段报 index 越界或者把某类全部漏检。train/val用相对路径时是相对于你执行训练命令的工作目录不是相对于data.yaml所在目录这点和 YOLOv5 一致容易搞混。3.2 启动训练与关键参数YOLOv7 官方仓库的训练命令python train.py \ --weights yolov7.pt \ --cfg cfg/training/yolov7.yaml \ --data battery_dataset/data.yaml \ --hyp data/hyp.scratch.p5.yaml \ --epochs 150 \ --batch-size 8 \ --img-size 640 640 \ --device 0 \ --workers 4 \ --name battery_yolov7逐项说明--weights yolov7.pt用 COCO 预训练权重做迁移2030 张图从零训容易过拟合--hyp选hyp.scratch.p5.yaml如果显存吃紧可以换hyp.scratch.tiny.yaml配合 tiny 模型--img-size 640 640和数据集分辨率对齐--workers在 Windows 上设 0 或 2设大了容易卡死--name决定runs/train/下的输出目录名。150 epoch 是经验值。2030 张图、3 类目标通常 100~200 epoch 收敛。看results.txt里的mAP0.5连续 20 epoch 不涨就可以停。3.3 小目标与类别不平衡的处理纽扣电池是小目标干电池和 9V 相对大。如果直接训模型容易偏向大目标纽扣电池的 recall 会偏低。三个可调点第一改 anchor。用 k-means 在自家数据上重新聚类python utils/autoanchor.py \ --data battery_dataset/data.yaml \ --img-size 640 \ --anchors 9输出的 9 个 anchor 替换cfg/training/yolov7.yaml里的anchors字段。小目标多时最小的 anchor 可能从默认的(12,16)缩到(8,10)左右。第二调 loss 权重。在 hyp 文件里把box从 0.05 提到 0.07~0.08让回归损失占比更高小框定位更准。cls保持 0.5 左右obj保持 1.0。第三过采样。如果某一类样本明显少可以在train.txt里重复列出该类图像路径或者用--image-weights开启按类别频率加权采样。2030 张图里三类分布如果不均这一步比调 anchor 更直接。注意改完 anchor 和 hyp 后先用--epochs 10跑个短训确认 loss 正常下降再开长训别一上来就 150 epoch 等结果。4. 验证 97.7% 识别率mAP 指标、混淆矩阵与推理脚本训练完拿到best.pt下一步是验证它到底有没有 97.7% 的水平。这里的「正确识别率」在目标检测里通常指mAP0.5或分类准确率两者口径不同必须自己复现一遍才算数。这一章讲怎么用官方test.py跑指标、怎么看混淆矩阵、怎么用detect.py做单图推理。4.1 跑 test.py 拿 mAPpython test.py \ --weights runs/train/battery_yolov7/weights/best.pt \ --data battery_dataset/data.yaml \ --img-size 640 \ --batch-size 8 \ --task val \ --device 0 \ --name battery_eval--task val用验证集--task test用测试集。输出里关注三行mAP0.5、mAP0.5:0.95、每类的P/R。如果mAP0.5在 0.97 附近说明和官方给的 97.7% 对得上如果只有 0.85先别怀疑数据检查data.yaml的val路径和标签是否真的加载了。4.2 混淆矩阵怎么读YOLOv7 会在runs/val/下生成confusion_matrix.png。横轴是预测类纵轴是真实类对角线越深越好。常见问题纽扣电池被大量预测成背景最后一列说明小目标漏检干电池和 9V 互相混淆说明两类特征区分度不够可能需要更多 9V 侧面角度的图。import matplotlib.pyplot as plt import matplotlib.image as mpimg img mpimg.imread(runs/val/battery_eval/confusion_matrix.png) plt.figure(figsize(8, 8)) plt.imshow(img) plt.axis(off) plt.show()看矩阵时重点盯非对角线的大块。如果某一类的漏检率超过 10%回到训练阶段补该类样本或调conf阈值。4.3 单图与批量推理python detect.py \ --weights runs/train/battery_yolov7/weights/best.pt \ --source battery_dataset/images/test \ --img-size 640 \ --conf-thres 0.25 \ --iou-thres 0.45 \ --device 0 \ --save-txt \ --name battery_infer--conf-thres 0.25是置信度阈值低于它的框不输出。工业分拣场景如果追求高召回可以降到 0.15~0.2代价是误检增多如果追求高精度提到 0.4~0.5。--iou-thres 0.45控制 NMS 合并密集小目标场景可以降到 0.3~0.4避免相邻纽扣电池被合并成一个框。--save-txt会把预测结果按 YOLO 格式存下来方便和真值做逐图对比。提示conf和iou这两个阈值没有万能值按你的业务是「宁可错杀」还是「宁可放过」来定定完在验证集上跑一遍看 P/R 曲线。5. 电池检测落地避坑从标签错位到小目标漏检的 5 个排查点数据、训练、验证都跑通了真正部署到产线或集成到系统里时坑才集中冒出来。这一章列 5 个我实际遇到过的翻车场景每条按「现象 → 原因 → 解决」写方便你对照排查。5.1 训练 loss 正常但 mAP 极低现象loss 一路下降mAP0.5却卡在 0.1 以下。原因标签路径没对上YOLOv7 把图当成了全背景样本loss 靠obj项在降但学不到任何目标。解决检查labels/train下.txt数量和images/train下图片数量是否一致文件名除扩展名是否一一对应。用脚本快速核对import os img_dir battery_dataset/images/train lbl_dir battery_dataset/labels/train imgs {os.path.splitext(f)[0] for f in os.listdir(img_dir)} lbls {os.path.splitext(f)[0] for f in os.listdir(lbl_dir)} print(缺标签:, imgs - lbls) print(缺图像:, lbls - imgs)5.2 纽扣电池 recall 明显低于其他类现象干电池和 9V 的 recall 都在 0.95 以上纽扣电池只有 0.7~0.8。原因小目标在 640 分辨率下像素太少默认 anchor 匹配不上正样本分配不足。解决按 3.3 节重新聚类 anchor把最小 anchor 缩小同时把hyp里的box损失权重提到 0.07~0.08并在验证时把conf-thres降到 0.2 观察 recall 变化。5.3 推理时同一颗电池出多个框现象一张图里一颗纽扣电池被画了 3~4 个重叠框。原因NMS 的iou-thres设太高比如 0.7相邻框没被合并。解决把--iou-thres降到 0.3~0.45密集场景可以到 0.3。如果降了还不行检查是不是训练时同一目标被标了多次标签文件里出现重复行。5.4 换一批新图后准确率暴跌现象验证集 97%换产线新拍的图只有 70%。原因训练集和实际场景存在域偏移光照、背景、拍摄角度不一致。解决从新场景里抽 100~200 张按同样规范标注后加入训练集做微调学习率调到 0.001 左右训 30~50 epoch。别指望一份数据覆盖所有产线。5.5 显存溢出或训练中途卡死现象CUDA out of memory或--workers设大后进程卡住。原因batch size 或 workers 超过机器承受能力Windows 下多进程 dataloader 尤其容易出问题。解决--batch-size从 8 降到 4 或 2--workers在 Windows 上设 0Linux 上设 4~8。显存还是不够就换yolov7-tiny精度掉一点但能跑起来。6. 把电池检测模型压到产线ONNX 导出与 TensorRT 加速的实操细节训练和验证都过了最后一步是让模型在产线工控机上跑得动。PyTorch 原生推理在 CPU 上单图要几百毫秒跟不上传送带节拍。常见做法是导出 ONNX再用 TensorRT 或 OpenVINO 加速。这一章给导出脚本、精度对齐方法和一个我踩过的坑。6.1 导出 ONNXpython export.py \ --weights runs/train/battery_yolov7/weights/best.pt \ --img-size 640 640 \ --batch-size 1 \ --simplify \ --include onnx--simplify会调用 onnx-simplifier 去掉冗余节点--batch-size 1对应产线单图推理。导出后在同目录得到best.onnx。验证 ONNX 和 PyTorch 输出是否一致import onnxruntime as ort import numpy as np import torch # 随机输入 x np.random.rand(1, 3, 640, 640).astype(np.float32) sess ort.InferenceSession(best.onnx) onnx_out sess.run(None, {sess.get_inputs()[0].name: x}) model torch.load(best.pt, map_locationcpu)[model].float().eval() with torch.no_grad(): torch_out model(torch.from_numpy(x))[0].numpy() print(最大绝对误差:, np.abs(onnx_out[0] - torch_out).max())误差在 1e-3 以内算正常超过 1e-2 说明导出有问题重点查--img-size和--simplify是否和训练时一致。6.2 TensorRT 加速与精度对齐工控机有 NVIDIA 显卡时用trtexec把 ONNX 转成 enginetrtexec \ --onnxbest.onnx \ --saveEnginebest.engine \ --fp16 \ --workspace2048--fp16开启半精度速度能提 1.5~2 倍精度通常掉 0.1~0.3 个点。如果业务对精度敏感去掉--fp16用 FP32。--workspace是显存上限单位 MB按显卡调整。转完后用同一批测试图对比 engine 和 PyTorch 的检测框重点看纽扣电池有没有因为 FP16 量化而漏检。我遇到过 FP16 下小目标置信度从 0.6 掉到 0.3 的情况最后退回 FP32 才稳住。6.3 一个血泪教训最早部署时我图省事直接拿训练时的conf-thres 0.25上产线结果纽扣电池漏检率偏高。后来在验证集上画了 P-R 曲线发现 recall 要到 0.98 得把阈值降到 0.12代价是误检多了 3%。产线能接受误检人工复核一遍但不能接受漏检混料流出所以最终定了 0.12。从那以后我每次部署前都强制走一遍「P-R 曲线定阈值」的流程不再拍脑袋设参数。希望这份电池数据集和上面的流程能帮你少走几段弯路。本文还有配套的精品资源点击获取
 函数全解析：逻辑向量、缺失值与数据校验避坑指南)
