企业官网建设流程全解析

1. 为什么OBB检测不是“换掉标签格式”就能跑通的

YOLOv8原生不支持旋转框（OBB），这是绝大多数刚接触这个任务的人踩进的第一个深坑。我见过太多人把DOTA或UCAS-AOD数据集下载下来，用labelImg标完旋转框，导出成YOLO格式的txt文件，然后兴冲冲地改几行配置、跑train.py——结果报错：ValueError: too many values to unpack (expected 5)，或者训练出来的模型连水平框都画不直。问题根本不在代码写错了，而在于整个数据流的底层逻辑被彻底忽略了。

OBB和HBB（水平边界框）的本质差异，远不止是多两个角度参数那么简单。HBB用(x_center, y_center, width, height, class_id)这5个数就能唯一确定一个矩形；而OBB需要至少6个参数：(x_center, y_center, width, height, angle, class_id)。但更关键的是，YOLOv8的整个训练管线——从数据加载、预处理、损失函数计算到后处理（NMS）——全部是围绕5维向量设计的。你强行塞进去6维，就像往只支持USB-A接口的电脑上硬插USB-C线，物理层面就不兼容。

更隐蔽的问题在于坐标系与归一化逻辑。YOLO系列默认所有坐标都是相对于图像宽高的归一化值（0~1范围），但旋转角度angle的单位是弧度还是角度？取值范围是[-π/2, π/2]还是[0, π)？不同OBB标注工具（如CVAT、SuperLabel、自研标注平台）导出的angle定义五花八门。我曾调试过一个项目，标注工具输出的是[0, 180)度的整数，而模型内部期望的是[-90, 90)度的浮点弧度，中间差了一个180度的相位翻转，导致所有预测框都朝反方向旋转——整整调了两天才定位到这个隐性转换层。

提示：不要假设任何标注工具的angle定义和YOLOv8训练器的期望一致。必须亲自打开几个txt标签文件，用Python脚本打印原始数值，再对照你的数据增强代码里rotate_bbox函数的输入输出，逐层验证。

另一个常被忽视的点是anchor机制的失效。YOLOv8的PANet结构依赖于预设anchor尺寸来匹配不同尺度的目标。但OBB目标的“尺度”概念变了：一个长条形飞机，其width和height可能相差5倍，而angle又决定了它在特征图上的投影形态。原版anchor聚类（k-means on HBB）完全不适用于OBB场景。我在某次无人机巡检项目中直接复用COCO的anchor，结果小目标召回率暴跌40%，后来用OBB-aware的k-means++重新聚类，把anchor从9组扩展到15组，并按angle区间分桶，才把mAP拉回合理水平。

所以，“训练自己的OBB数据集”这件事，本质是一次对YOLOv8训练框架的深度改造，而不是一次简单的数据格式迁移。它要求你同时理解计算机视觉中的几何变换原理、PyTorch的Dataloader数据流机制、损失函数的梯度传播路径，以及工业级数据增强的鲁棒性边界。接下来的内容，就是我把过去三年在多个OBB项目中沉淀下来的、真正能落地的改造方案，掰开揉碎讲清楚。

2. 数据准备阶段：从标注规范到格式校验的七道关卡

很多人以为数据准备就是“标完导出”，实际上这是整个OBB训练链条中最容易埋雷的环节。我总结了一套必须严格执行的七步校验法，漏掉任意一步，后续训练都会出现难以复现的诡异现象。

2.1 标注工具选型与参数锁定

首先明确：不要用labelImg、LabelMe这类通用标注工具做OBB。它们对旋转框的支持是半吊子的——要么angle定义模糊，要么导出格式不统一。必须使用专为OBB设计的工具。我们团队长期稳定使用的是CVAT（开源版），原因有三：

• 其OBB标注模式强制要求用户选择“矩形旋转”而非“多边形”，从源头杜绝了顶点顺序混乱；
• 导出YOLO-OBB格式时，angle明确定义为[-π/2, π/2]弧度，且中心点坐标严格归一化；
• 支持批量校验功能，可一键检查所有标注是否满足“width ≥ height”约束（这是YOLO-OBB格式的隐含约定，否则angle符号会反转）。

注意：CVAT导出的YOLO-OBB格式中，angle单位是弧度，取值范围为[-π/2, π/2]。如果你用的是其他工具（如SuperLabel），务必在导出后运行校验脚本，将angle强制映射到该区间。常见错误是angle落在[π/2, 3π/2]，此时需执行angle = angle - π if angle > π/2 else angle。

2.2 标签文件的原子级校验

拿到CVAT导出的labels/目录后，不能直接扔进训练。必须对每个.txt文件做原子级扫描。我写了一个轻量校验脚本（核心逻辑如下），每天训练前必跑：

import numpy as np def validate_obb_label(file_path): with open(file_path, 'r') as f: lines = f.readlines() for i, line in enumerate(lines): parts = line.strip().split() if len(parts) != 6: raise ValueError(f"Line {i} in {file_path}: expected 6 values, got {len(parts)}") try: coords = list(map(float, parts[:5])) # x,y,w,h,angle cls_id = int(parts[5]) # 检查归一化范围 if not (0 <= coords[0] <= 1 and 0 <= coords[1] <= 1): raise ValueError(f"Line {i}: center out of [0,1]") if not (0 < coords[2] <= 1 and 0 < coords[3] <= 1): raise ValueError(f"Line {i}: w/h out of (0,1]") # 检查angle范围 if not (-np.pi/2 <= coords[4] <= np.pi/2): raise ValueError(f"Line {i}: angle {coords[4]:.3f} not in [-π/2, π/2]") except Exception as e: raise ValueError(f"Line {i} parse error: {e}")

这个脚本会揪出90%以上的数据污染问题。最常触发的错误是：某张图里有个极小目标（w=0.001, h=0.0005），在float32精度下被截断为0，导致后续除零错误；或者angle因浮点误差变成-1.5707963267948966（即-π/2），而某些版本的OpenCV旋转函数对此边界值处理异常。

2.3 图像与标签的严格配对

YOLOv8的dataset.yaml要求train和val路径下图像与标签一一对应。但OBB场景下，必须确保同一张图的jpg/png文件名与txt文件名100%相同（包括大小写和空格）。Windows系统不区分大小写，但Linux服务器会；某些标注工具导出时自动把空格转成下划线，而你的图像名里有空格——这种细微差异会导致训练时FileNotFoundError，且错误堆栈指向Dataloader内部，极难定位。

我们的解决方案是：在数据拷贝到训练服务器后，执行强制重命名脚本：

# 将所有空格替换为下划线，统一小写，删除特殊字符 for file in *.jpg; do newname=$(echo "$file" | tr ' ' '_' | tr '[:upper:]' '[:lower:]' | sed 's/[^a-z0-9_.]//g') mv "$file" "$newname" done # 同步处理txt标签 for file in *.txt; do newname=$(echo "$file" | tr ' ' '_' | tr '[:upper:]' '[:lower:]' | sed 's/[^a-z0-9_.]//g') mv "$file" "$newname" done

2.4 类别ID的连续性与一致性

YOLOv8要求类别ID从0开始连续编号（0,1,2,...）。但CVAT导出时，如果项目里删过某个类别，ID可能出现空洞（如0,1,3）。这会导致模型最后一层分类头的输出维度与实际类别数不匹配，训练时loss突然飙升。

解决方法不是手动改txt，而是用dataset.yaml里的names字段做映射。例如你的yaml写：

train: ../datasets/myobb/train/images val: ../datasets/myobb/val/images nc: 3 names: ['car', 'plane', 'ship']

那么所有标签文件里的类别ID必须是0,1,2。如果原始标注是1,2,4，必须用脚本批量替换：

# mapping_dict = {1:0, 2:1, 4:2} for txt_file in Path("labels").rglob("*.txt"): content = txt_file.read_text() for old_id, new_id in mapping_dict.items(): content = content.replace(f"{old_id} ", f"{new_id} ") txt_file.write_text(content)

2.5 训练/验证集划分的OBB感知策略

随机划分图像会破坏OBB数据的分布特性。比如你的数据集中，90%的飞机目标angle集中在[-10°, 10°]，而[80°, 90°]只有10个样本。如果随机划分，验证集可能恰好抽到那10个极端角度样本，导致评估指标严重失真。

我们采用angle-aware stratified split：先将所有目标按angle分成5个桶（[-45°,-15°),[-15°,15°),[15°,45°),[45°,75°),[75°,90°]），再在每个桶内按比例抽样，最后合并成train/val集。这样保证各角度区间的样本分布与全量数据一致。代码实现用scikit-learn的StratifiedShuffleSplit配合自定义angle分桶函数即可。

2.6 数据增强的OBB安全边界

YOLOv8默认的albumentations增强对OBB是危险的。RandomRotate90会让angle突变90度，但width和height未交换，导致几何矛盾；HorizontalFlip后angle符号必须取反，否则框会镜像错误。

必须禁用所有可能改变几何关系的增强，并启用OBB专用增强库。我们团队封装了一个OBBCompose类，只允许以下操作：

• RandomBrightnessContrast（像素级，不影响几何）
• GaussianBlur（同上）
• Mosaic（需重写，确保四个子图的OBB坐标映射正确）
• CopyPaste（需重写，粘贴区域的OBB必须做仿射变换）

其中Mosaic的重写最复杂：要分别计算每个子图在最终大图中的坐标偏移，再对每个OBB的(x,y)做平移，对angle保持不变（因为Mosaic不旋转子图）。这部分代码超过200行，但它是保证mAP不掉点的关键。

2.7 标签可视化：最后也是最重要的防线

在启动训练前，必须人工抽检至少50张图的可视化效果。不是看图片，而是看叠加了预测框的GT图。我们用自研的obb_visualizer.py，输入图像和对应txt，输出带红框（GT）和绿框（dummy prediction）的对比图。

重点检查三类错误：

• 角度翻转：GT框顺时针转30°，绿框却逆时针转30°（angle符号错误）；
• 宽高倒置：GT框是细长矩形（w=0.3,h=0.05），绿框却是矮胖矩形（w=0.05,h=0.3）（未做w/h约束）；
• 中心漂移：GT框中心在(0.5,0.5)，绿框中心在(0.48,0.52)（归一化计算误差累积）。

这一步耗时，但能避免70%的训练失败。我坚持这个习惯后，单次训练成功率从45%提升到92%。

3. 模型改造核心：YOLOv8-OBB的四层侵入式修改

YOLOv8官方代码库（ultralytics）对OBB的支持是实验性的，且仅限于yolov8n-obb.pt等预训练权重。要训练自己的数据集，必须对源码进行四层深度改造。这不是打补丁，而是外科手术。

3.1 第一层：数据加载器的OBB适配（dataloader.py）

原版LoadImagesAndLabels类只解析5维HBB。我们要注入OBB解析逻辑。关键修改点在__getitem__方法：

# 原代码（HBB） cls, x, y, w, h = line.split() # 新增OBB分支 if len(line.split()) == 6: cls, x, y, w, h, angle = line.split() # 强制w>=h，angle映射到[-pi/2, pi/2] if float(w) < float(h): w, h = h, w angle = str(float(angle) + np.pi/2 if float(angle) < 0 else float(angle) - np.pi/2) # 归一化angle到[-pi/2, pi/2] angle = float(angle) % np.pi if angle > np.pi/2: angle -= np.pi

这里有两个精妙设计：

1. 宽高强制约束：当w<h时，交换w/h并调整angle。这是YOLO-OBB格式的黄金法则，确保angle唯一性；
2. angle模运算归一化：用% np.pi再条件修正，比简单np.arctan2更鲁棒，能处理浮点误差导致的微小越界。

实操心得：不要在标注阶段就做w/h交换，而要在加载时做。因为标注员视角下“长边”是主观的，而模型训练需要数学上严格的定义。我们在加载层统一处理，既保证一致性，又不增加标注负担。

3.2 第二层：损失函数的OBB重构（loss.py）

YOLOv8的DetectionLoss类计算box_loss时，用的是CIoU（考虑中心点距离、宽高比、重叠度）。但CIoU对OBB完全失效——它把旋转框当成水平框计算IoU，结果是负数。

我们必须替换为OBB专用IoU。我们选用poly_iou（多边形IoU），基于Shapely库实现：

from shapely.geometry import Polygon def poly_iou(poly1, poly2): # poly1/poly2: [(x0,y0), (x1,y1), (x2,y2), (x3,y3)] p1 = Polygon(poly1) p2 = Polygon(poly2) if not p1.is_valid or not p2.is_valid: return 0.0 inter = p1.intersection(p2).area union = p1.union(p2).area return inter / (union + 1e-16)

但直接用Shapely在GPU上计算太慢。我们的优化方案是：CPU预计算IoU矩阵，GPU只做加权求和。在每个batch加载时，用多进程提前算好该batch内所有GT-pred组合的IoU，存入iou_matrix张量，训练时直接索引。实测速度损失<5%，但mAP提升12.3%。

3.3 第三层：后处理NMS的OBB化（postprocess.py）

原版non_max_suppression只处理5维框。OBB NMS必须用旋转框NMS。我们弃用torchvision.ops.nms，改用cv2.dnn.NMSBoxesRotated：

# 输入：preds: [N, 6] -> [x,y,w,h,angle,conf] boxes = preds[:, :5].cpu().numpy() # 转为opencv格式 scores = preds[:, 5].cpu().numpy() # cv2要求angle单位为度，且w,h为实际像素值（非归一化） # 所以需先反归一化 h, w = img_shape boxes[:, 0] *= w # x boxes[:, 1] *= h # y boxes[:, 2] *= w # w boxes[:, 3] *= h # h boxes[:, 4] = np.degrees(boxes[:, 4]) # rad to deg # 调用opencv NMS indices = cv2.dnn.NMSBoxesRotated(boxes, scores, conf_thres, iou_thres)

这里的关键陷阱是：cv2.dnn.NMSBoxesRotated要求angle单位为度，而模型输出是弧度。漏掉np.degrees()转换，NMS会完全失效——所有框都被抑制，因为angle被当作弧度传入，opencv误判为超大角度。

3.4 第四层：模型头的OBB输出扩展（head.py）

YOLOv8的检测头（Detect类）输出是[bs, c, h, w]，其中c=reg_max*4+nc（HBB）。OBB头需输出6维：(x,y,w,h,angle,cls)。

我们新增OBBDetect类，继承自Detect，重写forward方法：

class OBBDetect(Detect): def __init__(self, nc=80, ch=()): super().__init__(nc, ch) # 原HBB输出通道：4*(reg_max+1) + nc # OBB输出通道：6*(reg_max+1) + nc （多2个reg维度） self.cv2 = nn.Conv2d(ch[0], 6 * self.reg_max, 1) # 替换原4通道 # angle分支单独用sigmoid约束到[0,1]，再映射到[-pi/2,pi/2] self.angle_act = nn.Sigmoid() def forward(self, x): # ... 原逻辑 box = self.cv2(x).permute(0, 2, 3, 1) # [bs, h, w, 6*(reg_max+1)] # 分离6维：x,y,w,h,angle,cls xyo = box[..., :2] # 中心偏移 who = box[..., 2:4] # 宽高偏移 angle = self.angle_act(box[..., 4:5]) # sigmoid -> [0,1] angle = (angle - 0.5) * np.pi # 映射到[-pi/2, pi/2] cls = self.cv3(x).permute(0, 2, 3, 1) # 分类分支不变 return torch.cat([xyo, who, angle, cls], -1)

这个设计的精妙之处在于：angle用Sigmoid+线性映射，而非直接回归。因为angle是周期性变量，直接回归会导致梯度爆炸（-π/2和π/2在数学上等价，但网络认为它们相距π）。Sigmoid强制学习在[0,1]区间，再线性映射，让网络更容易收敛。

4. 训练调优实战：从第一次崩溃到稳定收敛的完整路径

即使完成了所有代码改造，OBB训练依然充满不确定性。我记录了某次典型训练的完整日志，还原从崩溃到稳定的全过程，这是书本上绝不会写的细节。

4.1 第一次训练：loss爆炸与梯度裁剪的临界点

启动训练后，第1个epoch的box_loss就飙到120+（正常应<5），cls_loss也异常高。n/s（每秒处理样本数）从预期的85骤降到12。nvidia-smi显示GPU显存占用100%，但利用率仅30%——典型的计算瓶颈。

排查发现是poly_iou计算中，某些退化多边形（三点共线）导致Shapely的intersection.area返回nan，进而使loss变为nan，反向传播时梯度爆炸。

解决方案是双保险梯度裁剪：

# 在train.py的optimizer.step()前 torch.nn.utils.clip_grad_norm_(model.parameters(), max_norm=10.0) # 并在loss计算后添加nan检查 if torch.isnan(loss): print("NaN loss detected! Skipping batch...") continue

但治标不治本。根本解法是在poly_iou中加入退化检测：

def safe_poly_iou(poly1, poly2): try: p1 = Polygon(poly1) p2 = Polygon(poly2) if not (p1.is_valid and p2.is_valid and p1.is_simple and p2.is_simple): return 0.0 inter = p1.intersection(p2).area union = p1.union(p2).area return inter / (union + 1e-16) except: return 0.0 # 任何异常都返回0，不中断训练

4.2 第二次训练：learning rate的OBB敏感区

修复nan后，loss下降缓慢，10个epoch后box_loss仍卡在8.5。学习率是罪魁祸首。YOLOv8默认lr=0.01，但OBB任务对lr更敏感——angle回归需要更精细的调整。

我们做了lr-sweep实验，在[0.001, 0.01, 0.05]三个档位测试：

最优解是0.005。但更优策略是cosine annealing with warmup：前3个epoch从0线性warmup到0.005，之后余弦退火到0。这让我们在epoch30就达到mAP@50=0.45。

4.3 第三次训练：数据增强强度的阈值实验

启用Mosaic后，mAP不升反降3个百分点。原因是Mosaic对OBB的几何扰动过大——四个子图拼接时，边缘目标被裁切，其OBB坐标映射出现微小误差，累积起来破坏了监督信号。

我们做了增强强度梯度测试：

• mosaic=0.0（关闭）：mAP@50=0.45
• mosaic=0.5：mAP@50=0.43
• mosaic=1.0：mAP@50=0.40

结论：OBB任务中，Mosaic的收益远小于HBB。我们最终采用mosaic=0.3，并增加copy_paste=0.1作为补充，用实例复制替代全局拼接，在保持多样性的同时控制几何误差。

4.4 第四次训练：类别不平衡的OBB特化处理

数据集中car样本占70%，plane占20%，ship仅10%。原版Focal Loss对OBB的angle维度无效——它只作用于分类和定位，不作用于angle回归。

我们设计了OBB-Focal Loss：在总loss中，给稀有类别的angle loss加权：

# 计算每个样本的angle_loss angle_loss = F.mse_loss(pred_angle, gt_angle, reduction='none') # 按类别加权：ship类别weight=2.0, plane=1.5, car=1.0 weight_map = {0:1.0, 1:1.5, 2:2.0} # cls_id -> weight angle_weight = torch.tensor([weight_map[int(cls_id)] for cls_id in cls_ids]) weighted_angle_loss = (angle_loss * angle_weight).mean()

这个改动让ship类的召回率从0.28提升到0.41，整体mAP@50提升2.1个百分点。

4.5 稳定收敛：早停与模型融合的决策树

OBB训练极易过拟合。我们设定早停规则：

• 监控val/box_loss，连续5个epoch不下降则降低lr；
• 连续10个epoch不下降则保存当前最佳权重并终止；
• 最佳权重定义为：mAP@50最高，且mAP@50:95不低于该值的95%。

此外，我们采用模型融合提升鲁棒性：训练3个不同seed的模型，推理时对同一张图的3个预测结果做OBB-NMS融合（用cv2.dnn.NMSBoxesRotated的scores参数加权平均）。这让我们在测试集上mAP@50稳定在0.48±0.01，方差降低60%。

5. 推理与部署：从预测脚本到嵌入式落地的全链路

训练完成只是开始，OBB模型的推理和部署有更多隐藏挑战。我以一个无人机实时检测项目为例，展示如何把模型从pt文件变成能在Jetson AGX Orin上跑满30FPS的engine。

5.1 预测脚本的OBB专用化（predict.py）

原版model.predict()输出是Results对象，其boxes.xyxy是HBB格式。我们必须重写Results类，添加obb属性：

class OBBResults(Results): @property def obb(self): # 从模型输出中提取6维OBB if not hasattr(self, '_obb'): pred = self.pred[0] # [N, 6] # 转换为四点坐标：[(x0,y0), (x1,y1), (x2,y2), (x3,y3)] self._obb = [] for box in pred: x, y, w, h, angle, conf = box.tolist() # 用cv2.boxPoints生成四点 rect = ((x, y), (w, h), np.degrees(angle)) points = cv2.boxPoints(rect) self._obb.append(points) return self._obb def plot(self, *args, **kwargs): # 重写plot方法，用cv2.polylines画旋转框 img = super().plot(*args, **kwargs) for points in self.obb: points = points.astype(int) cv2.polylines(img, [points], True, (0,255,0), 2) return img

这样，用户只需调用results.obb就能拿到所有旋转框的四点坐标，无需自己写几何变换。

5.2 ONNX导出的OBB陷阱与绕过方案

YOLOv8的export(format='onnx')对OBB支持不完善。主要问题是：

• angle分支的Sigmoid+线性映射在ONNX中被拆成多个op，导致TensorRT解析失败；
• cv2.dnn.NMSBoxesRotated无法导出为ONNX op。

我们的解决方案是两段式导出：

1. 只导出主干网络（Backbone+Neck+Head），输出6维logits；
2. 在推理端用Python/C++后处理，调用cv2.boxPoints和cv2.dnn.NMSBoxesRotated。

导出命令：

yolo export model=yolov8n-obb.pt format=onnx opset=12 dynamic=True

关键参数opset=12（非默认17），因为TensorRT 8.6只支持到opset12；dynamic=True启用动态batch和分辨率。

5.3 TensorRT加速：从FP32到INT8的精度平衡

在Jetson上，FP32推理速度仅12FPS。我们尝试INT8量化，但发现angle精度损失严重：±1°误差导致框错位明显。

最终采用混合精度策略：

• Backbone/Neck用FP16（速度提升2.1倍，精度无损）；
• Head的angle分支用FP32（保留角度精度）；
• 其余分支用INT8。

用trtexec生成engine：

trtexec --onnx=yolov8n-obb.onnx \ --fp16 \ --int8 \ --calib=calibration_cache.bin \ --workspace=4096 \ --saveEngine=yolov8n-obb.engine

其中calibration_cache.bin用100张典型图生成，重点覆盖angle ∈ [-45°,45°]区间。

5.4 嵌入式部署：内存与延迟的终极博弈

Jetson AGX Orin只有32GB内存，而OBB模型+OpenCV+视频解码常驻内存达28GB。我们做了三项关键优化：

• 内存池复用：预分配cv2.UMat内存池，避免频繁malloc/free；
• 异步解码：用GStreamer pipeline分离解码与推理，解码线程将YUV帧送入共享内存，推理线程从中读取；
• ROI裁剪：对大图（3840x2160），先用轻量级HBB模型粗筛目标区域，再对ROI做OBB精检，延迟降低65%。

最终在4K@30fps视频流上，端到端延迟稳定在33ms（30FPS），CPU占用率<40%，GPU占用率<75%，热设计功耗（TDP）控制在25W以内——这是嵌入式落地的硬性门槛。

6. 故障诊断手册：OBB训练中95%问题的快速定位指南

OBB训练的问题有高度规律性。我把三年踩过的所有坑，浓缩成一张故障树，按现象反推根因，帮你5分钟内定位问题。

6.1 现象：训练loss为nan或inf

根因概率排序：

1. 标签angle越界（70%）：检查labels/*.txt中是否有angle > 1.5708或< -1.5708；
2. 退化多边形（20%）：GT框三点共线，poly_iou返回nan；
3. 学习率过大（10%）：box_loss在epoch1就>100。

诊断命令：

# 查找越界angle grep -r "angle.*[2-9]\." labels/ | awk '{print $5}' | sort -n | tail -5 # 检查nan loss来源 python -c "import torch; print(torch.tensor([1.5708]).sin())" # 应输出≈1.0

6.2 现象：预测框全部朝同一方向旋转（如全顺时针）

根因概率排序：

1. angle符号未翻转（80%）：HorizontalFlip后未执行angle = -angle；
2. w/h未约束（15%）：模型输出w<h，但boxPoints函数假设w>=h；
3. 单位混淆（5%）：模型输出弧度，cv2.boxPoints误当角度传入。

诊断技巧：
取一张图，用cv2.boxPoints手动绘制GT框，对比results.obb输出。若GT正确而预测错误，则问题在模型输出；若GT也错，则问题在标签或加载层。

6.3 现象：小目标检测率极低（<0.1）

根因概率排序：

1. anchor不匹配（60%）：原COCO anchor对OBB小目标失效；
2. Mosaic裁切（30%）：小目标在Mosaic中被裁掉一半；
3. NMS阈值过高（10%）：iou_thres=0.7导致小目标被大目标抑制。

解决方案：

• 用kmeans_obb.py重新聚类anchor，聚焦w,h < 0.05的小目标；
• 关闭Mosaic，改用CopyPaste；
• nms时对小目标单独设置iou_thres=0.3。

6.4 现象：验证集mAP远低于训练集（过拟合）

根因概率排序：

1. 数据增强过强（50%）：Mosaic+CopyPaste组合破坏OBB几何一致性；
2. 类别不平衡（30%）：稀有类别的angle loss未加权；
3. 学习率衰减过慢（20%）：cosine退火周期过长。

验证手段：
在验证集上运行obb_visualizer.py，人工检查100张图。若GT框清晰可见但预测框全无，则是过拟合；若预测框存在但角度/位置偏差大，则是泛化能力不足。

6.5 现象：推理速度远低于预期（<10FPS）

根因概率排序：

1. ONNX op不支持（70%）：cv2.dnn.NMSBoxesRotated未导出，回退到CPU；
2. 内存带宽瓶颈（20%）：