上周有位朋友把他自己标注的几百张图丢过来说训练日志里 mAP 已经涨到 0.9 了可拿几张新图去预测框出来的东西要么位置发飘要么干脆一个框都不给。我打开他的脚本一看问题不在模型而在他把“训练能跑通”当成了“预测能跑对”——权重路径是随手复制的、类别表压根没带、conf 还是默认 0.25、图像尺寸被强制拉伸。这几件事凑在一起模型再准也白搭。这篇就聊聊用 YOLO 目标检测算法跑自己数据集的预测环节。标题里“预测自己的数据集”这五个字其实包含两件事一是模型是你自己训出来的二是要预测的图像不在训练集里。前者意味着权重、类别表、输入尺寸这三样东西必须和训练时严格对齐后者意味着你得接受“泛化能力”这个天花板调参只能贴着天花板走不能突破它。适合刚训完第一个模型、准备把结果拿出去用的人看也适合那些“训练集上框得挺准一换图就崩”的同学对照排查。1. 训练跑通不等于预测跑对先厘清预测这一步在做什么很多人把训练和预测当成一条流水线的上下半段实际上它们是两条独立链路中间只靠一个权重文件连接。理解这一点后面所有的坑都能找到位置。1.1 权重文件里只存了三类东西一个训练产出的.pt权重拆开看无非三部分网络结构定义与超参、卷积层的数值、以及一小段元数据。真正跟“预测自己的数据集”强相关的是那段元数据——里面记着训练时的类别数量nc、类别名列表names、以及输入尺寸等基本信息。这意味着你在预测阶段其实不需要重新指定 data.yaml加载权重时类别名会自动带出来results[0].names就能拿到。反过来讲如果你在预测时手动覆盖了names或者传了一个类别顺序不同的 yaml模型输出的类别索引就会和你的预期错位。这是“框位置对但标签全错”的最常见原因比很多人想的要普遍。还有一点容易被忽略权重里存的是训练结束那一刻的参数不是你日志里最好那一轮的参数。如果你开了save_period或者只保留了last.pt实际落地的可能是过拟合的那一版。我一般会同时保留best.pt和last.pt用同一批图各跑一遍看哪个框得更稳再决定上线用哪个——这件事花不了五分钟但能省掉后面一堆返工。1.2 预测链路的四个输入必须同时成立把预测拆开输入其实只有四样输入项作用出错后的典型现象权重文件提供结构与参数报错、或输出全空待测图像提供像素图像读取失败、通道数不对类别表来自权重元数据把索引翻译成名字框对但标签张冠李戴推理参数控制筛选与缩放漏检、重复框、坐标偏移这四样里前两样出问题会直接报错反而好排查后两样出问题往往不报错只是结果不对这才是最费时间的。所以我的习惯是第一次在新数据上跑预测先用一张图、一个类别、conf0.01的极端参数跑一遍看看模型到底“看见”了什么。如果连 0.01 都出不来框那基本可以判定是权重或预处理出了结构性问题而不是阈值问题。这个“先看全量、再收紧”的思路比一上来就调参要高效得多。模型在极低阈值下输出的原始候选框能直观告诉你它关注的是图像哪个区域是不是压根没往目标身上看。很多时候问题就出在这里——比如训练时用的是俯拍图测试时给的是平视图模型确实什么都没学到。2. data.yaml 与实际标注的对齐预测阶段最容易埋雷的地方训练脚本能跑起来只能说明 yaml 格式没写错不能说明它和你的标注文件是同一套逻辑。预测阶段的所有类别混乱几乎都能回溯到这一步。2.1 类别顺序错位导致的“张冠李戴”假设你的数据集有三类安全帽、反光背心、绝缘手套。标注工具导出时按字母序排成gloves, helmet, vest而你在 yaml 里按业务重要性写成helmet, vest, gloves。训练时模型学的其实还是标注文件里的索引names只是给人看的标签。但预测时names会被用来翻译索引于是模型认作“第 0 类”的东西被显示成了helmet——而它实际是手套。这种错误非常隐蔽因为框的位置完全正确IoU 也正常只有文字标签错了。如果你拿去做人工抽检很容易被“框对了”这个表象骗过去。排查方法在预测脚本里打印model.names再拿一张只有单一类别的图单独测看输出的标签名和实际物体是否一致。三类就测三次成本极低。我自己的习惯是在标注阶段就把类别顺序固定下来写进一个classes.txt训练 yaml 和后续所有脚本都从这个文件读绝不手写第二遍。人手动抄写顺序这件事出错率比想象中高得多。2.2 标注格式与坐标归一化的换算细节自己标注的数据常见格式有两种一种是cls cx cy w h的归一化文本坐标都是 0 到 1 之间的小数另一种是cls x1 y1 x2 y2的绝对像素。YOLO 系列吃的是前者如果你直接拿后者去训损失会变得很奇怪模型学出来的框要么全图大小要么集中在一个角落。换算逻辑本身不复杂但有两个细节值得说清中心点坐标要除以图像宽高而不是除以长边。宽高比悬殊的图像比如长条形的工业质检图如果搞错了框会整体偏移。归一化必须在 letterbox 之前完成。如果你先缩放再归一化坐标映射回原图时会带上填充量结果就是系统性偏移。预测阶段的坐标不需要你手动还原。主流实现返回的xyxy已经是映射回原始图像尺寸的绝对坐标内部做了逆向 letterbox。这一点常被误解有人拿到坐标后自己又乘一遍缩放比例导致框越跑越偏。我的建议是先用一张已知尺寸的图跑一次把返回的坐标打印出来看看数值是否落在图像宽高范围内验证一次就不用再怀疑了。2.3 类别数与权重不匹配的冲突自己数据集最常见的场景是类别数很少比如单类检测。这时如果加载的是公开预训练权重继续训最后导出的权重里nc应该是 1。但有些人在预测时用了model YOLO(yolov8n.pt)这种通用权重而不是自己训出来的best.pt结果返回 80 类全是莫名其妙的名字。这个错误听起来低级但发生频率相当高——尤其在脚本里改了权重路径却忘了改另一处硬编码的名字。我的做法是加一行断言from ultralytics import YOLO model YOLO(runs/detect/train/weights/best.pt) expected_nc 1 # 你数据集的实际类别数 assert len(model.names) expected_nc, f类别数不符: {model.names}多写这一行能挡住后面至少半小时的困惑。如果你确实需要用通用权重做对比实验那就明确写死在另一份脚本里别混用。3. 加载自训练权重路径、设备与精度的取舍权重加载这一步看起来就是一行代码实际上路径解析、设备绑定、精度模式三件事都会影响结果而且在不同的机器上表现还不一样。3.1 权重路径与工作目录的隐性依赖训练产出的权重一般落在runs/detect/train/weights/这类相对路径下。如果你在项目根目录跑脚本没问题换到子目录或者交给别人跑就会报文件不存在。更麻烦的是有些实现会在找不到本地文件时尝试按名字去拉取同名模型于是你明明写的是best.pt最后加载的却是一个通用模型的缓存版本——不报错但结果全错。规避方式很简单一律用绝对路径并且在加载后立刻校验。import os from ultralytics import YOLO WEIGHT os.path.abspath(runs/detect/train/weights/best.pt) assert os.path.exists(WEIGHT), f权重不存在: {WEIGHT} model YOLO(WEIGHT) print(类别表:, model.names)我还会额外记录权重的文件大小和修改时间写进预测日志。多模型对比的时候你才知道这份结果到底是哪个版本跑出来的。这件事在单人项目里显得多余但只要涉及两三个人协作立刻就能体现出价值。3.2 设备选择与半精度推理的实测差异device参数决定计算落在 CPU 还是某张卡上。默认会优先用 GPU这在多数情况下是对的但如果同一台机器上还有别的任务在占用显存就可能出现显存不足的报错。显式指定设备比依赖默认值更稳妥。半精度推理halfTrue是我常开的一个选项显存占用大约能降到一半左右速度也有明显提升。但它有两个前提一是必须在支持该精度的设备上跑纯 CPU 环境传了也没用甚至报错二是精度下降对小目标检测有影响我在几个小目标占比较高的数据集上对比过半精度下低置信度的框会明显变少召回率有肉眼可见的下滑。模式显存占用速度小目标表现完整精度基准基准稳定半精度约一半提升明显低置信框减少结论是中大目标为主的场景可以放心开半精度小目标密集的场景先用完整精度把效果跑稳性能不够再考虑换更小的模型而不是直接压精度。3.3 权重版本与代码版本的兼容性自己训的权重配自己当前的代码环境一般不会出问题。真正容易出事的是隔了几个月再回来跑或者把权重拷到另一台机器的环境里。这时候如果代码库版本差得比较多加载权重时可能报字段缺失或者悄悄按默认值补全导致预处理逻辑变了而你毫不知情。我的处理原则是权重文件和训练时的配置文件一起归档目录里附一份记录环境版本和关键超参的说明文件。听起来有点重但一次归档能省掉未来无数次“这个权重到底是怎么训出来的”的追问。如果确实遇到了加载异常先看报错里提到的是哪个字段再决定是降级代码还是重新训练。实在不行用权重导出的中间格式做一次转换很多时候能绕过版本适配问题。4. 推理参数不是默认值就能用conf、iou、imgsz 的逐个拆解默认参数是针对通用场景调出来的放到你的特定数据集上十个里有八个需要动。但动之前得知道每个参数在干什么不然就是盲目试数。4.1 conf 与 iou 的物理含义及联动conf是置信度阈值模型对每个候选框给出一个分数低于这个分数的直接丢弃。它控制的是“敢不敢报”。调低会召回更多同时误报增加调高则相反。iou这个参数名字容易误导它不是预测框和真实框的重叠度而是NMS 阶段用来判定两个框是否为同一目标的阈值。同一个目标上模型可能输出七八个框NMS 会保留分数最高的把与它重叠度超过iou的其余框压掉。调低会让抑制更激进密集场景下容易把相邻的两个真目标合并成一个调高则抑制不足出现一堆重叠框。这两个参数要一起看。我常用的起步组合是conf0.25, iou0.7然后按现象调整漏检明显、框数量偏少 → 先降conf到 0.15 试试不要急着改模型同一目标出现多个重叠框 → 降iou到 0.5 左右密集小目标被合并 → 反而要把iou提高比如 0.8有个细节值得提醒conf的调整应该基于验证集上的统计而不是拿一两张图目测。我习惯在验证集上一次性扫一组阈值记录每个阈值下的召回和误报数量画成表格看拐点。这个动作大约十分钟比反复改参数瞎试靠谱得多。4.2 imgsz 对召回率和速度的影响imgsz是推理时的输入尺寸模型会先把图像缩放并填充到这个尺寸再做前向。它必须和你训练时用的尺寸对齐——如果你训练用 640预测时图省事传 320小目标的特征在图里只剩几个像素模型自然认不出来。但也不是越大越好。尺寸翻倍计算量大约翻四倍而精度提升往往只有一两个点边际收益递减很快。我自己在几个数据集上的经验是目标是画面主体的中大型物体640 基本够用目标在画面中占比小于 5%需要上到 960 甚至 1280极端情况比如远处的细小零件提升分辨率不如切片推理把大图切成小块分别预测再合并效果通常更好还有一个隐藏项是rect。开启后模型会尽量减少填充按图像原始长宽比来组织输入推理更快对拉伸变形也更友好。这个选项默认在部分场景下是关的自己数据集的宽高比如果和训练集差异较大值得手动打开试一次。4.3 max_det 与类别过滤的实际用法max_det限制单张图最多输出多少个框默认值是 300。在密集场景里这个数可能不够框会被截断而在只有几个目标的场景里300 又显得过于宽松容易混进大量低分框。classes参数用来只保留指定类别。如果你的数据集是多类但当前场景只关心其中一类直接过滤比事后筛选更省事也能避免其他类的框干扰 NMS。results model.predict( sourcetest_imgs, conf0.25, iou0.7, imgsz640, max_det100, classes[0], saveTrue, save_txtTrue, save_confTrue, )另外agnostic_nms在多类别、类别间容易混淆的场景下很有用。它让 NMS 跨类别执行避免同一个物体被同时判成两个类而留下两个框。代价是相邻的不同类目标可能被误合并所以只建议在“一个位置只可能有一个目标”的场景里开启。5. 把预测结果真正用起来坐标还原、结果导出与批量处理框出来只是第一步把结果落到业务里还得走一段。这一段很多人是靠截图完成的效率低还容易丢数据。5.1 从结果对象里取出需要的字段一次预测返回的是一个结果列表每个元素对应一张图。真正有用的字段集中在boxes里xyxy是绝对坐标conf是分数cls是类别索引。这几个都是张量取值时记得转成普通数值或数组否则后续写文件会报类型错误。for r in results: names r.names for box in r.boxes: x1, y1, x2, y2 box.xyxy[0].tolist() score float(box.conf[0]) cls_id int(box.cls[0]) print(names[cls_id], round(x1, 1), round(y1, 1), round(x2, 1), round(y2, 1), round(score, 3))names是字典用索引取名字。如果你的类别多建议提前把它反转成id - name的映射存起来别在循环里反复构造。还有一个常被忽略的点save_txtTrue输出的文本里坐标是归一化的不是像素值。如果你要拿去和业务系统的绝对坐标对接需要自己乘回宽高。很多人以为输出的是像素坐标结果框全部缩在左上角一小块区域。5.2 批量跑目录与视频流的工程写法预测整个目录和预测单张图代码几乎一样区别在于要不要开流式处理。目录里图片多的时候一次性把所有结果堆在内存里会撑爆加上streamTrue就能逐张产出、逐张处理内存占用平稳。视频同理但多了一个vid_stride参数用来跳帧。实时性要求高的场景隔几帧处理一次是常见取舍代价是快速移动的目标可能被漏掉。我的经验是目标移动速度中等时隔两帧一次基本不影响结果速度很快的场景就别跳帧了改用更小的模型提速度。for r in model.predict(sourcevideos, streamTrue, vid_stride2, conf0.3): frame_idx r.path for box in r.boxes: # 逐帧处理 ...批量跑的时候一定要加异常捕获。我自己踩过的坑是目录里混进一张损坏的图整个批量任务直接中断前面跑完的结果也没保存。后来改成单张 try 包裹坏图跳过并记日志任务就能完整跑完。5.3 结果落盘与可视化的一致性可视化保存saveTrue方便肉眼检查但它画出来的框和线宽是库内置样式业务展示往往需要自己重绘。自己重绘时最容易出的问题是坐标体系和颜色空间不匹配——比如读取时用了某个库默认的通道顺序绘制时又按另一种顺序解释结果图的颜色全反了。我的做法是统一在一处做读写读图、绘制、保存都走同一个库避免混用。绘制前把坐标转成整数并做边界裁剪防止某些框略微超出图像范围导致绘制异常。结果落盘我一般同时存两份一份是带框的可视化图供人看一份是结构化的表格供程序用。表格里除了坐标和分数还会带上文件名和模型版本号。后面做效果回溯的时候这两列信息比什么都重要。6. 预测不对时的排查链路从现象倒推原因前面讲的都是“怎么做对”但现实是大部分时间花在“为什么不对”上。这一节把我实际用的排查顺序摊开讲你可以照着走一遍。6.1 一条从“看得见”到“看不见”的排查顺序我的固定顺序是四步每一步都能把问题范围砍掉一半第一步确认权重加载正确。打印model.names和类别数和数据集比对。这一步挡住的是“加载了错权重”这类问题。第二步用训练集里的一张图跑预测。如果训练集上都框不出来那问题一定在权重或预处理跟泛化能力无关。这一步能快速区分“模型没学会”和“模型没泛化”。第三步用训练集的原图尺寸和测试图对比。把两张图的宽高比、通道数、位深都打印出来。差异大的话先做一次格式统一再测。第四步把conf降到 0.01看模型到底输出了什么。有框但分数极低说明模型“隐约看到”了但不确定通常是训练样本不足或类别不平衡完全没框说明特征层面就没匹配上得回头看数据分布。这个顺序的价值在于它从最确定的问题往最不确定的问题走避免一上来就怀疑模型本身。我见过太多人卡在调参上最后一查是权重路径写错了。6.2 五个高频现象与对应根因现象大概率根因处理方向框位置对但标签全错类别顺序与标注不一致核对 yaml 与标注文件的类别索引一个目标出多个重叠框NMS 阈值偏高下调 iou 到 0.5 附近小目标完全检测不到推理尺寸过小或切片缺失提高 imgsz或改切片推理框整体偏移一个固定量坐标归一化或填充量计算错误检查是否重复做了缩放还原换图后几乎全空训练集与测试集分布差异过大补充相似场景样本勿只调参最后一行值得多说两句。分布差异是调参解决不了的我遇到过训练集全是白天室内图、测试图全是夜间室外的场景参数怎么调召回都上不去。这种情况只有两条路补数据或者换问题定义。承认模型能力的边界比在参数里反复折腾要省时间。7. 推理性能与落地导出、批处理与显存控制效果跑稳之后剩下的就是让它跑得快、跑得久。这一段往往决定了这套东西能不能真的用起来。7.1 导出为推理专用格式的实际收益训练权重是给训练用的里面带着反向传播需要的信息推理时用不上。导出成推理专用格式后文件更小、加载更快前向速度通常也有提升。model YOLO(runs/detect/train/weights/best.pt) model.export(formatonnx, opset12, simplifyTrue, dynamicFalse)几个参数值得留意opset版本要和目标运行环境匹配版本过高可能不被支持simplify会做一次图优化通常能再提一点速度dynamic设为 False 会固定输入尺寸速度更快但失去了尺寸灵活性如果你确定推理尺寸不变就关掉它。导出后一定要做一次一致性验证同一批图分别用原权重和导出模型跑比对框的数量和位置偏差。我遇到过导出后框位置整体偏移的情况原因是填充策略在转换时行为不一致不验证根本发现不了。7.2 batch 与显存的平衡批量推理能提升吞吐但显存占用会随之上升。我的做法是从batch1开始往上加每次翻倍直到显存接近上限再退回一档。这个试探过程建议写个循环自动跑比自己盯着显存数字估要准。还有一点批量推理时如果一批里图像的尺寸差异很大内部会统一缩放小图会被放大填充反而可能变慢。这种情况可以按尺寸分组同组内批量处理效率更高。7.3 上线前的自检清单最后留一份我每次上线前都会过一遍的清单都是被坑出来的权重路径是绝对路径且文件存在性有断言类别数和类别顺序与标注严格一致且已打印验证推理尺寸与训练尺寸一致单张图、目录、视频三种输入都跑通过一次结果落盘目录有自动创建逻辑不会因目录不存在而失败坏图、空目录、超大图三种异常输入都有处理推理耗时和显存峰值记录在日志里便于后续对比我自己在实际操作中的体会是这套流程里最耗时的从来不是调参而是对齐——权重、类别、尺寸、坐标这四样东西任何一处没对上表现出来的现象都像是“模型不行”。所以在怀疑模型之前先把这四样逐一验证一遍往往十分钟就能定位问题。至于效果上限那是数据决定的参数只能让你更接近它不能越过它。