1. 从零到一为什么我选择死磕YOLOv7这条技术路线做视觉项目的朋友大概率都绕不开一个名字——YOLO。从v5到v8再到v11版本迭代快得让人眼花缭乱但如果你问我哪个版本最值得拿来练手、做落地、打比赛我依然会推荐YOLOv7。原因不复杂它的结构足够经典训练效率高社区资源丰富而且在边缘设备上的部署方案已经非常成熟。更重要的是YOLOv7的整个链路——从数据标注、模型训练、调优到最终部署——覆盖了一个完整视觉项目该有的所有环节走通一遍你对目标检测的理解会上一个大台阶。这篇文章面向的是那些手里有一个具体检测需求、想自己从头跑通一遍的开发者。不管你是学生做课题、工程师做产品原型还是爱好者想搞个自己的小项目只要你能装Python环境、能看懂基本的命令行操作跟着这个思路走就不会迷路。我会把数据标注的工具选型和格式转换讲透把模型优化的几个关键参数拆开算给你看最后把部署到不同平台上的方案和踩过的坑一并交代清楚。全文没有花哨的理论推导全是实操层面的经验总结你可以直接抄作业。先说说整体思路。一个完整的YOLOv7项目我习惯把它拆成四个阶段数据准备、模型训练、模型优化、模型部署。这四个阶段不是线性的而是螺旋上升的——部署后发现精度不够可能要回到数据阶段补充样本优化后发现速度不达标可能要换更轻量的模型结构。所以一开始就别想着一步到位留好迭代的余地。数据准备阶段的核心是标注质量和格式规范。我见过太多人拿着乱七八糟的标注文件去训练结果loss不下降还怪模型不行。标注这件事工具选对了能省一半力气格式转对了能避免一堆报错。模型训练阶段的关键是理解超参数的含义知道每个参数动了之后会发生什么而不是盲目调参。模型优化阶段要区分“精度优化”和“速度优化”两条线前者靠数据增强和结构微调后者靠剪枝、量化和推理引擎加速。模型部署阶段则要根据目标硬件选方案GPU服务器、边缘计算盒、树莓派每个平台的坑都不一样。提示如果你是完全的新手建议先把YOLOv7的官方仓库clone下来跑通一个最小的demo再回头来看这篇文章体感会强很多。2. 数据标注从工具选型到格式转换的完整实操2.1 标注工具怎么选LabelImg、Labelme还是CVAT数据标注是整個项目里最耗人力的一环工具选得好不好直接影响标注效率和后续的数据质量。我前后用过七八款标注工具最后稳定在三个选择上LabelImg、Labelme和CVAT。它们各有各的适用场景没有绝对的好坏关键看你的项目需求。LabelImg是最轻量的选择安装简单界面朴素适合做纯矩形框标注。它的输出格式支持Pascal VOC的XML和YOLO的TXT两种这对YOLOv7来说非常友好因为YOLOv7训练直接吃TXT格式。如果你只是做常规的目标检测图片数量在几千张以内LabelImg完全够用。它的缺点是功能单一不支持多边形标注也不支持多人协作。Labelme则适合需要做多边形分割标注的场景。比如你要检测的物体形状不规则用矩形框会带入大量背景这时候用多边形标注就更合适。Labelme输出的是JSON格式需要额外写脚本转成YOLO格式。它的安装比LabelImg稍微麻烦一点但在Windows和Linux上都有成熟的安装方案。CVAT是三者中最重的但也是功能最强的。它支持多人协作、自动标注、视频标注适合团队作战或者数据量特别大的项目。CVAT可以部署在本地服务器上通过浏览器访问标注效率比单机工具高不少。不过它的部署和维护成本也最高个人项目不太建议上CVAT。工具适用场景输出格式安装难度协作支持LabelImg常规矩形框标注XML/TXT低无Labelme多边形分割标注JSON中无CVAT团队协作、大规模标注多种高强我的建议是个人项目从LabelImg起步遇到不规则物体再换Labelme团队项目直接上CVAT。不要一上来就追求功能最全的工具工具越重学习成本和维护成本越高。2.2 标注规范那些没人告诉你但必须遵守的细节标注这件事最怕的就是“随心所欲”。今天心情好标得紧一点明天赶进度标得松一点最后训练出来的模型边界框忽大忽小置信度上不去。我总结了几条必须遵守的标注规范都是踩坑踩出来的。第一边界框要贴紧目标边缘但不要切掉目标本身。比如标注一个人框要包含头顶到脚底左右要包含肩膀和手臂的自然下垂位置。框太大引入背景噪声框太小丢失目标特征。这个“度”需要你在标注前就定好标准然后所有标注人员统一执行。第二遮挡目标的标注策略要提前定。一个目标被遮挡了30%标不标被遮挡了70%还标不标我的经验是遮挡面积小于50%的正常标注遮挡面积在50%到80%之间的根据项目需求决定遮挡超过80%的直接忽略。这个阈值不是绝对的但一定要在标注前明确并且写进标注规范文档里。第三类别定义要互斥且完备。什么叫互斥就是一张图里的同一个物体不能同时属于两个类别。什么叫完备就是所有需要检测的物体都有对应的类别不能出现“其他”这种模糊类别。我见过一个项目把“汽车”和“车辆”分成两个类结果标注人员完全凭感觉选最后模型学得一塌糊涂。第四标注文件的命名要和图片一一对应。YOLOv7训练时是根据图片文件名去找对应的TXT文件如果命名对不上训练时就会报“找不到标签文件”的错误。建议图片和标签文件同名只是扩展名不同放在两个平行的文件夹里。注意标注完成后一定要做一轮抽查随机抽10%的图片检查标注质量。我吃过亏五千张图标完直接训练结果发现有一千多张的框偏得离谱返工重标花了整整两天。2.3 格式转换从VOC XML到YOLO TXT的完整脚本LabelImg默认输出的是Pascal VOC格式的XML文件而YOLOv7训练需要的是YOLO格式的TXT文件。这两种格式的区别在于VOC存的是绝对坐标左上角和右下角的像素值YOLO存的是归一化后的中心点坐标和宽高。转换的核心就是坐标变换。转换公式是这样的假设图片宽度为W高度为HVOC格式的框为(xmin, ymin, xmax, ymax)那么YOLO格式的中心点x坐标为((xminxmax)/2)/W中心点y坐标为((yminymax)/2)/H宽度为(xmax-xmin)/W高度为(ymax-ymin)/H。所有值都在0到1之间。下面是我常用的转换脚本直接可以拿去用import os import xml.etree.ElementTree as ET def convert_voc_to_yolo(xml_dir, output_dir, classes): if not os.path.exists(output_dir): os.makedirs(output_dir) for xml_file in os.listdir(xml_dir): if not xml_file.endswith(.xml): continue tree ET.parse(os.path.join(xml_dir, xml_file)) root tree.getroot() size root.find(size) w int(size.find(width).text) h int(size.find(height).text) lines [] for obj in root.iter(object): cls_name obj.find(name).text if cls_name not in classes: continue cls_id classes.index(cls_name) bbox obj.find(bndbox) xmin float(bbox.find(xmin).text) ymin float(bbox.find(ymin).text) xmax float(bbox.find(xmax).text) ymax float(bbox.find(ymax).text) x_center ((xmin xmax) / 2.0) / w y_center ((ymin ymax) / 2.0) / h width (xmax - xmin) / w height (ymax - ymin) / h lines.append(f{cls_id} {x_center:.6f} {y_center:.6f} {width:.6f} {height:.6f}) txt_name os.path.splitext(xml_file)[0] .txt with open(os.path.join(output_dir, txt_name), w) as f: f.write(\n.join(lines)) classes [person, car, dog] convert_voc_to_yolo(annotations_xml, labels_txt, classes)这个脚本有几个细节需要注意。第一classes列表的顺序要和后续训练时的类别文件一致否则类别ID会对不上。第二坐标归一化时要用浮点数除法不要用整数除法否则精度会丢失。第三写入TXT时保留六位小数就够了再多也是浪费存储空间。转换完成后建议随机抽几张图用可视化脚本检查一下确保框的位置和类别都正确。我一般会写一个简单的OpenCV脚本把YOLO格式的框画回图片上肉眼确认无误后再进入训练阶段。3. 模型训练参数配置与训练过程监控3.1 环境搭建与依赖安装的避坑指南YOLOv7的训练环境搭建说简单也简单说麻烦也麻烦。简单是因为官方仓库的requirements.txt写得很清楚麻烦是因为CUDA版本、PyTorch版本、Python版本之间的兼容性问题能折腾死人。我推荐一套经过验证的组合Python 3.8或3.9PyTorch 1.12或1.13CUDA 11.6或11.7。这套组合在Ubuntu 20.04和Windows 10上都跑通过稳定性不错。安装步骤我习惯用conda来管理环境这样不同项目之间不会互相干扰conda create -n yolov7 python3.9 conda activate yolov7 pip install torch1.13.1cu117 torchvision0.14.1cu117 --extra-index-url https://download.pytorch.org/whl/cu117 git clone https://github.com/WongKinYiu/yolov7.git cd yolov7 pip install -r requirements.txt这里有几个坑要提前说。第一PyTorch版本和CUDA版本必须匹配装错了会报“CUDA不可用”或者“版本不兼容”。第二requirements.txt里的某些包可能会因为网络问题装不上可以换国内源重试。第三如果你用的是Windows建议把项目放在没有中文和空格的路径下否则某些脚本会报编码错误。验证环境是否装好可以跑一行简单的Python代码import torch print(torch.__version__) print(torch.cuda.is_available()) print(torch.cuda.get_device_name(0))如果输出显示CUDA可用并且打印出了你的显卡型号说明环境没问题。如果cuda.is_available()返回False先检查显卡驱动再检查PyTorch版本最后检查CUDA版本按这个顺序排查基本能解决。3.2 数据集配置文件data.yaml的每个字段都要搞明白YOLOv7训练前需要准备一个data.yaml文件里面定义了数据集路径、类别数量和类别名称。这个文件看起来简单但每个字段都有讲究写错了训练直接跑不起来。train: /path/to/train/images val: /path/to/val/images nc: 3 names: [person, car, dog]train和val分别指向训练集和验证集的图片文件夹。注意这里只写图片路径标签文件YOLOv7会自动去同级目录下找同名的TXT文件。所以你的目录结构应该是这样的dataset/ ├── train/ │ ├── images/ │ │ ├── 001.jpg │ │ └── 002.jpg │ └── labels/ │ ├── 001.txt │ └── 002.txt └── val/ ├── images/ └── labels/nc是类别数量names是类别名称列表。这两个必须和标注时的类别定义完全一致顺序也要一致。我见过有人把nc写成类别名称的数量结果names里多写了一个类别训练时直接报索引越界。还有一个容易忽略的点图片路径最好用绝对路径或者相对于项目根目录的路径。用相对路径时如果训练脚本的工作目录变了就会找不到图片。我一般直接用绝对路径省心。3.3 训练参数详解batch size、学习率和epochs怎么定YOLOv7的训练参数有几十个但真正需要你手动调的其实就几个batch size、学习率、epochs、img size。其他的用默认值就行除非你有特殊需求。batch size的选择取决于你的显存大小。显存越大batch size可以越大训练越稳定。我整理了一个参考表显存大小推荐batch size说明4GB4-8可能需要降低img size8GB16比较均衡的选择12GB24-32训练速度较快24GB64适合大规模数据集学习率是训练中最敏感的参数。YOLOv7默认用的是SGD优化器初始学习率0.01配合余弦退火调度。如果你的数据集比较小几千张图建议把学习率降到0.001否则容易过拟合。如果数据集很大几万张图以上可以用默认的0.01甚至更高。epochs的设置要看数据集大小和模型收敛情况。一般来说300个epoch是个不错的起点。如果验证集loss在200个epoch左右就平稳了可以提前停止。如果300个epoch还在下降可以加到500。我一般会开早停机制patience设为50连续50个epoch验证集指标不提升就自动停止。img size默认是640这个尺寸在精度和速度之间取得了不错的平衡。如果你的目标特别小可以提到1280但显存占用会翻四倍。如果追求速度可以降到416或320但小目标的检测精度会明显下降。启动训练的命令是这样的python train.py --weights yolov7.pt --cfg cfg/training/yolov7.yaml --data data/mydata.yaml --epochs 300 --batch-size 16 --img-size 640 640 --device 0--weights指定预训练权重强烈建议从官方权重开始训练收敛速度快很多。--device 0指定用第一块GPU多卡训练可以用--device 0,1,2,3。3.4 训练过程监控loss曲线怎么看什么时候该停训练启动后控制台会实时打印各种指标。很多人只盯着loss看其实loss只是其中一个维度。我一般关注四个指标box_loss、obj_loss、cls_loss和mAP0.5。box_loss是边界框回归损失衡量预测框和真实框的位置差距。obj_loss是目标置信度损失衡量模型对“这里有没有目标”的判断准确度。cls_loss是分类损失衡量类别判断的准确度。这三个loss都是越低越好但要注意区分训练集loss和验证集loss。mAP0.5是平均精度均值是目标检测最核心的评估指标。它综合考虑了精度和召回率数值越高越好。一般来说mAP0.5达到0.8以上就算不错了达到0.9以上就相当优秀了。判断什么时候该停止训练我一般看三个信号。第一验证集loss连续多个epoch不再下降甚至开始上升说明过拟合了。第二mAP0.5连续多个epoch不再提升说明模型已经收敛。第三训练集loss还在下降但验证集loss已经平稳这也是过拟合的典型表现。训练完成后权重文件会保存在runs/train/exp/weights/目录下其中best.pt是验证集表现最好的权重last.pt是最后一个epoch的权重。部署时一般用best.pt。实操心得训练过程中建议每隔50个epoch保存一次中间权重这样即使训练崩溃了也不用从头再来。YOLOv7默认只保存best和last可以在train.py里改一下保存逻辑。4. 模型优化精度与速度的平衡艺术4.1 数据增强策略让模型见过更多“世面”数据增强是提升模型泛化能力最有效的手段之一而且成本极低。YOLOv7内置了多种数据增强方式包括马赛克增强、MixUp、随机缩放、随机裁剪、色彩抖动等。这些增强方式在训练时自动生效你只需要在配置文件中控制它们的开关和强度。马赛克增强是YOLOv7的招牌功能它把四张图片拼成一张让模型在一个batch里看到更多样的场景。这个功能对小目标检测特别有效因为拼接后小目标的相对尺寸变大了。我建议默认开启除非你的数据集本身就很特殊。MixUp是把两张图片按一定比例混合标签也按比例混合。这种方式能提升模型的鲁棒性但也可能让训练变得更难收敛。如果训练前期loss下降很慢可以先把MixUp关掉等模型初步收敛后再开启。随机缩放和随机裁剪能提升模型对不同尺度和位置的适应能力。色彩抖动则能提升模型对光照变化的鲁棒性。这些增强的强度都可以在hyp文件中调整我一般用默认值只在过拟合明显时才加大增强强度。增强方式作用建议马赛克增强提升小目标检测、增加场景多样性默认开启MixUp提升鲁棒性前期关闭后期开启随机缩放适应不同尺度默认开启色彩抖动适应光照变化默认开启4.2 模型剪枝与量化让模型跑得更快训练出来的模型往往参数量偏大在服务器上跑没问题但要部署到边缘设备上就力不从心了。这时候就需要做模型压缩主要手段是剪枝和量化。剪枝是去掉模型中不重要的连接或通道减小模型体积和计算量。YOLOv7支持通道剪枝通过分析每个通道的权重重要性把贡献小的通道整条去掉。剪枝后需要做微调恢复一部分精度。我实测下来剪掉30%的通道模型体积能减小三分之一推理速度提升20%左右精度下降不到2个百分点。量化是把模型的浮点参数从FP32转成INT8这样模型体积直接变成原来的四分之一推理速度也能提升两到三倍。量化的难点在于精度损失尤其是对小目标检测量化后精度可能掉得比较明显。解决办法是使用量化感知训练在训练阶段就模拟量化的误差让模型提前适应。import torch from models.experimental import attempt_load model attempt_load(yolov7.pt, map_locationcpu) model.eval() # 动态量化 quantized_model torch.quantization.quantize_dynamic( model, {torch.nn.Linear, torch.nn.Conv2d}, dtypetorch.qint8 ) torch.save(quantized_model.state_dict(), yolov7_quantized.pt)这段代码演示的是动态量化操作简单但精度损失相对大一些。如果追求更高精度建议用静态量化配合校准数据集过程复杂一些但效果更好。4.3 推理加速ONNX、TensorRT和OpenVINO怎么选模型训练和优化完成后最后一步是选择推理引擎。不同的推理引擎针对不同的硬件平台做了优化选对了能获得数倍的加速效果。ONNX是一个通用的模型交换格式几乎所有的推理框架都支持。把PyTorch模型转成ONNX后可以在CPU、GPU、边缘设备上运行灵活性最高。但ONNX本身不是推理引擎它需要配合ONNX Runtime或TensorRT等后端使用。TensorRT是NVIDIA的推理加速库专门针对NVIDIA GPU优化。它能把模型中的算子融合、精度校准、内核自动调优推理速度比原生PyTorch快三到五倍。缺点是只支持NVIDIA GPU而且转换过程比较繁琐。OpenVINO是Intel的推理加速库针对Intel CPU和集成显卡优化。如果你部署在Intel的平台上OpenVINO是不二之选。它的转换工具很成熟精度损失也小。推理引擎适用硬件加速比转换难度ONNX RuntimeCPU/GPU通用1.5-2x低TensorRTNVIDIA GPU3-5x高OpenVINOIntel CPU/GPU2-3x中我的建议是如果部署在NVIDIA GPU上直接上TensorRT如果部署在Intel CPU上用OpenVINO如果需要跨平台兼容用ONNX Runtime。转换过程中要注意opset版本的选择YOLOv7一般用opset 11或12。5. 模型部署从服务器到边缘设备的落地实践5.1 服务器端部署Flask API服务的搭建服务器端部署是最常见的场景把模型封装成一个HTTP接口供其他系统调用。我用Flask搭了一个简单的推理服务代码不复杂但有几个细节要注意。from flask import Flask, request, jsonify import torch import cv2 import numpy as np from models.experimental import attempt_load from utils.general import non_max_suppression, scale_coords app Flask(__name__) model attempt_load(yolov7.pt, map_locationcuda:0) model.eval() app.route(/detect, methods[POST]) def detect(): file request.files[image] img cv2.imdecode(np.frombuffer(file.read(), np.uint8), cv2.IMREAD_COLOR) img cv2.resize(img, (640, 640)) img img[:, :, ::-1].transpose(2, 0, 1) img np.ascontiguousarray(img) img torch.from_numpy(img).to(cuda:0).float() / 255.0 img img.unsqueeze(0) with torch.no_grad(): pred model(img)[0] pred non_max_suppression(pred, 0.25, 0.45) results [] for det in pred: if det is not None and len(det): for *xyxy, conf, cls in det: results.append({ bbox: [float(x) for x in xyxy], confidence: float(conf), class: int(cls) }) return jsonify(results) if __name__ __main__: app.run(host0.0.0.0, port5000)这个服务有几个优化点。第一模型加载放在全局不要每次请求都加载。第二图片预处理用OpenCV比PIL快。第三推理时用torch.no_grad()关闭梯度计算节省显存。第四NMS的阈值要根据实际场景调0.25的置信度阈值和0.45的IOU阈值是比较通用的起点。如果要部署到生产环境建议用Gunicorn或uWSGI做WSGI服务器Flask自带的开发服务器性能太差。另外可以加一个请求队列避免高并发时显存溢出。5.2 边缘设备部署树莓派上的YOLOv7实战树莓派是很多人做边缘AI的首选平台价格便宜、功耗低、社区资源丰富。但树莓派的算力有限直接跑YOLOv7的PyTorch模型帧率只有个位数必须做优化。我的方案是把YOLOv7转成ONNX然后用ONNX Runtime在树莓派上推理。树莓派5的CPU性能比树莓派4强不少配合ONNX Runtime的优化YOLOv7的推理速度能到5-8 FPS勉强能满足实时检测的需求。转换步骤是这样的python export.py --weights yolov7.pt --include onnx --img-size 640 640然后在树莓派上安装ONNX Runtimepip install onnxruntime推理脚本和服务器端类似只是把PyTorch的推理换成ONNX Runtime的推理。注意树莓派上要用onnxruntime而不是onnxruntime-gpu因为树莓派没有NVIDIA GPU。如果帧率还是不够可以进一步降低输入分辨率到416或320或者用YOLOv7-tiny模型。YOLOv7-tiny的参数量只有标准版的十分之一速度能提升三到四倍精度下降在可接受范围内。注意树莓派的散热是个大问题长时间推理会导致CPU降频。建议加装散热片或小风扇否则帧率会越来越低。5.3 部署后的性能监控与迭代模型部署上线不是终点而是新的起点。上线后需要持续监控模型的推理延迟、吞吐量、准确率等指标及时发现和解决问题。推理延迟是最直观的指标我一般用Prometheus加Grafana做可视化监控。在推理服务里埋点记录每次请求的处理时间然后推送到PrometheusGrafana面板上就能看到延迟的实时曲线和 historgram 分布。准确率监控稍微麻烦一些因为线上数据没有标注。我的做法是定期抽样一批线上数据人工标注后计算准确率。如果准确率下降超过5个百分点就触发告警排查是数据分布变了还是模型退化了。模型迭代的节奏取决于业务需求。如果数据分布稳定模型可以几个月更新一次。如果数据分布变化快可能需要每周甚至每天更新。更新时建议用A/B测试新模型先跑一小部分流量确认效果后再全量切换。6. 常见问题与排查技巧实录6.1 训练阶段的典型报错与解决训练阶段最常见的报错是“CUDA out of memory”显存不够。解决办法有三个降低batch size、降低img size、用梯度累积模拟大batch。梯度累积的原理是多次前向传播后再统一反向传播效果上等价于大batch但显存占用不变。第二个常见报错是“找不到标签文件”。这通常是路径配置问题检查data.yaml里的路径是否正确检查图片和标签文件是否同名检查标签文件是否在正确的目录下。第三个常见报错是loss变成NaN。这通常是学习率太大或者数据里有异常值。先把学习率降一个数量级试试如果还不行检查标注文件里有没有坐标超出0到1范围的异常值。报错信息可能原因解决办法CUDA out of memory显存不足降低batch size或img size找不到标签文件路径配置错误检查data.yaml和文件命名loss变成NaN学习率过大或数据异常降低学习率检查标注mAP不提升过拟合或欠拟合调整增强策略或模型结构6.2 部署阶段的性能瓶颈排查部署阶段最常见的问题是推理速度不达标。排查思路是从上到下逐层分析先看模型本身的计算量再看推理引擎的配置最后看硬件资源的使用情况。模型计算量可以用thop库统计看看FLOPs和参数量是否合理。如果模型本身就很重那再怎么优化推理引擎也快不了需要考虑换轻量模型或做剪枝。推理引擎的配置问题包括有没有开启FP16或INT8推理有没有设置合适的线程数有没有启用算子融合。这些配置对速度的影响很大有时候改一个参数就能提升一倍性能。硬件资源的使用情况用nvidia-smi或htop查看。如果GPU利用率很低说明瓶颈在数据预处理或后处理上。如果GPU利用率很高但速度还是慢说明模型计算量确实大需要换更轻量的模型。6.3 精度不达标的排查思路精度不达标是另一个高频问题。排查思路是先看训练集精度再看验证集精度最后看测试集精度。如果训练集精度就低说明模型欠拟合。解决办法是增加训练epoch、增大模型容量、降低数据增强强度。如果训练集精度高但验证集精度低说明过拟合。解决办法是增加数据量、加大数据增强强度、加正则化。如果训练集和验证集精度都高但测试集精度低说明数据分布不一致。这时候需要检查测试集的数据来源和训练集是否一致如果不一致需要补充训练数据或者做域适应。还有一个容易被忽略的点是类别不平衡。如果某些类别的样本特别少模型对这些类别的检测精度就会很差。解决办法是过采样少数类别、调整损失函数的类别权重、或者用focal loss。7. 一些个人体会和后续扩展方向走完这一整套流程我最大的体会是YOLOv7的落地难点不在模型本身而在数据和工程。模型结构是开源的训练脚本是现成的但数据标注的质量、格式转换的正确性、部署环境的兼容性这些才是真正消耗时间的地方。我见过太多人把80%的时间花在调参上结果发现是标注数据有问题。另一个体会是不要追求一步到位。先跑通一个最小的闭环哪怕精度只有0.5哪怕帧率只有1 FPS先让整个链路跑起来。然后再逐个环节优化数据不够就补数据速度不够就换模型精度不够就调参数。这种迭代式的做法比一开始就追求完美要高效得多。后续如果想继续深入有几个方向可以扩展。一是尝试更新的YOLO版本比如YOLOv8或YOLOv9对比它们的性能和易用性。二是探索半自动标注用训练好的模型预标注人工只做修正能大幅提升标注效率。三是研究模型蒸馏用大模型教小模型在保持精度的同时减小模型体积。四是尝试多任务学习让一个模型同时做检测和分割提升整体效率。最后分享一个小技巧训练时把日志重定向到文件方便事后分析。我一般用python train.py ... 21 | tee train.log这样控制台能看到实时输出文件里也保留了完整日志。排查问题时翻日志比凭记忆靠谱得多。