数据增强

设置这些参数

数据增强参数就是普通的 train() 参数。

from libreyolo import LibreYOLO model = LibreYOLO("LibreYOLO9s.pt")model.train(    data="my-dataset.yaml",    epochs=100,    mosaic_prob=1.0,    mixup_prob=0.15,    hsv_prob=1.0,    flip_prob=0.5,    no_aug_epochs=15,)

# CLI 把 mosaic_prob 写作 mosaic，把 mixup_prob 写作 mixuplibreyolo train model=LibreYOLO9s.pt data=my-dataset.yaml \  epochs=100 mosaic=1.0 mixup=0.15 hsv_prob=1.0 \  flip_prob=0.5 no_aug_epochs=15

其中两个在 CLI 上有更短的写法：mosaic 对应 mosaic_prob，mixup 对应 mixup_prob。其余参数在两边的写法完全一致。

三种状态，而不是两种

一个参数是否真的起作用，取决于家族。库里维护了一张声明式的表，每一项都是三种状态 之一。

used 表示这个参数会进入流水线并改变样本。ignored 表示它根本进不了流水线，设了 也没用。gated_by_mosaic 表示它只作用于走了 mosaic 分支的样本，所以在 mosaic_prob=0 时，即使它已经接好了线也永远不会触发。

第三种状态才是让人意外的那个。在 YOLOX 风格的流水线上，仿射变换跑在 mosaic 画布 上，MixUp 混合的也是 mosaic 样本，所以 mosaic_prob=0 会一次性悄悄关掉 degrees、translate、shear、perspective、mosaic_scale、mixup_prob 和 mixup_scale。训练器只针对 MixUp 这种情况打了一条警告：

mixup_prob=0.15 has no effect for YOLOv9: mixup only applies to mosaic samples
and mosaic_prob=0. Set mosaic_prob > 0 to enable mixup.

CLI 也会对被忽略的参数发出警告，而且只列出你真正写了的那几个：

Warning: RF-DETR ignores these parameters: degrees, mosaic

四种流水线形态

各个家族归到四条训练流水线里，而流水线几乎决定了所有答案。

YOLOX 风格的 mosaic 流水线按样本做 HSV 抖动和翻转，然后在 mosaic 分支里跑仿射变换 和 MixUp。它覆盖 YOLOX、YOLOv7、YOLOv9 及其 E2E 和 P2 变体、RTMDet、PicoDet、 RT-DETR、RT-DETRv2 和 FOMO。

DETR 风格的直通流水线既没有 mosaic 也没有仿射变换。它的光度失真、zoom-out 和 IoU 裁剪都是配方里的常量，而不是配置参数，所以只有 flip_prob 和 no_aug_epochs 是 活的。它覆盖 D-FINE、Dome-DETR、DEIM、DEIMv2、RT-DETRv4、EC，以及改了一处的 RF-DETR。

分类的 ImageFolder 流水线忽略每一个检测参数。它的水平翻转是固定的 0.5，flip_prob 够不着。它有自己的一套参数，见下文。

YOLO-NAS 自成一种形态：完全没有 mosaic，逐样本的仿射变换始终开着，MixUp 是独立应用 的，而不是被门控的。它的 mosaic_scale 值被复用为仿射变换的缩放范围。

SegFormer 和 NAFNet 各自跑一条任务专属的流水线，其随机性写死在家族里，不可配置。对 SegFormer 来说，活的参数是类属性 semantic_scale_jitter 和 semantic_hsv_prob， 而不是 mosaic_scale 和 hsv_prob。NAFNet 的裁剪和翻转是输入与目标耦合的操作，概 率固定为 0.5。

哪个家族认哪个参数

下面这张表就是随库分发的 spec，位于 libreyolo/data/augment/spec.py，库自己的测试 会拿它和真实的流水线接线做断言。请直接去那里读，而不是从架构去推。

from libreyolo.data.augment.spec import AUG_KNOBS, aug_support for knob, description in AUG_KNOBS.items():    support = aug_support("yolo9")[knob]    print(f"{knob:16} {support.status:16} {support.note or description}")

from libreyolo.data.augment.spec import ignored_aug_params print(sorted(ignored_aug_params("rfdetr")))

按流水线汇总，只看基础参数：

这些列内部还有一些例外，全都是收窄的：

• RTMDet、PicoDet、RT-DETR、RT-DETRv2 和 FOMO 没有垂直翻转，所以 flipud 被忽略。 FOMO 的 mosaic 包装器构建时也不带 perspective。
• RF-DETR 原生的流水线没有 HSV 抖动，所以在 DETR 风格那一列之外，hsv_prob 也被 忽略。
• EC 认 hsv_prob、degrees 和 translate，但仅限 task="pose"，因为只有它那个 感知关键点的变换会读这些值。它的 detect 和 segment 路径用的是固定的光度配方。
• DINOv2 的 detect 和 semantic 任务遵循 DETR 风格那一列，并为 task="classify" 加 上分类参数包。

no_aug_epochs 在所有家族上都是 used，但它在各处的含义并不相同。在 mosaic 流水 线上，它会在最后几轮关掉 mosaic 和 MixUp。在 DETR 风格的流水线上，它会停掉光度、 zoom-out 和裁剪这几种增强，并改变调度的尾部。在分类和语义分割流水线上，它只改变尾 部。

分类参数包

有四个参数只驱动分类流水线，别的什么都不驱动。检测家族对这四个一律忽略。

from libreyolo import LibreYOLO model = LibreYOLO("LibreConvNeXtt-cls.pt")model.train(    data="my-classification-dataset",    epochs=50,    auto_augment="randaugment",    erasing=0.25,    mixup=0.2,    cutmix=0.2,)

auto_augment 接受 "randaugment"、"autoaugment"、"augmix" 或 None。 erasing 是 RandomErasing 的概率。mixup 和 cutmix 是按批生效的概率，产生软标 签；每批最多跑一个，MixUp 优先，所以两者是相加的，总和不应超过 1。

四个默认都是关的，所以除非你主动要求，分类训练不会有任何变化。

有一处命名冲突值得直说：在 CLI 上，mixup 是检测那个 mixup_prob 的别名。分类的 mixup 字段没有自己的 CLI 写法，只能在 Python 里通过 model.train(mixup=...) 才 够得着。

家族专属参数

有些参数挂在某个家族的配置子类上，而不是基类上，所以它们只对那个家族存在，也没有 CLI flag。

max_labels 是那个会悄悄丢数据的参数。超过上限的检测框会被直接丢掉，不报错，所以 航拍这类密集图像需要把它调大。

不管参数怎么设，旋转框训练都会禁用 mosaic 和 MixUp，因为针对旋转框、感知角点的增强 还没有实现。

相关

• 超参数：no_aug_epochs 作为调度参数，以及 train() 的其余部分。
• 数据集：这些变换消费的标注格式。