做了几年视觉分割方向的开发我最大的体会是看论文架构图时总觉得一切尽在掌握真到自己搭模型才发现每一步都是细节。Backbone选什么、普通ResNet和带空洞卷积的ResNet到底差在哪、要不要加Neck、数据集标签怎么转成训练格式、各种类别的IoU怎么算——这些环节单独看不难串起来就是一道坎。后来我大量使用MMSegmentation这个基于PyTorch的开源分割工具箱才慢慢把“模型”这两个字拆成了“Backbone、Neck、DecodeHead”这样的组件也终于搞懂了为什么一套代码能跑出U-Net、PSPNet、DeepLabV3、SegFormer这些风格完全不同的模型。这篇文章就以我实际使用和翻源码的视角把所有核心Backbone、Neck、数据集组织方式、主流算法族完整拆一遍。适合刚入门的开发者建立全局认知也适合已经跑通但想搞懂内部逻辑、想做自定义数据集和模型替换的读者。1. 三段式架构与config机制为什么分割模型能像积木一样组装1.1 从“整模型”到“组件化”的思路转变语义分割模型看起来五花八门但绝大多数可以抽象成一个固定流程输入图像经过Backbone提取特征Neck对特征做多尺度融合或增强最后通过DecodeHead产出逐像素分类的预测图。有的模型不显式设置Neck直接拿Backbone最后一层特征送进Head也有的模型把解码器做得很重比如U-Net那样逐层上采样拼接——但本质上仍然是“特征提取 特征处理 预测头”的架构。MMSegmentation正是按照这个逻辑把整个框架拆成了若干独立组件。Backbone负责前端特征抽取Neck处理主干输出和中间层特征DecodeHead负责最终的分割预测和损失计算。每个组件都通过配置文件声明而不是在代码里写死。所以我只要改一行配置就能把ResNet换成Swin Transformer或者把PSPNet的Head换成DeepLabV3的ASPP模块训练、验证、推理、可视化的整套流程都不用动。我最早接触这类工具箱时有个误区以为替换Backbone需要该模型的完整实现后来才发现只要组件接口对齐替换就像换汽车引擎一样简单。前提是你得理解MMSegmentation约定好的数据流图像进入Backbone后输出多个层级的特征图通常记为C2、C3、C4、C5Neck对这些特征图做融合得到更合适的多尺度特征DecodeHead再从这些特征中计算最终的分割结果。整条链路全部由config文件控制。1.2 config文件是所有选择的核心先看一个最小可用的配置骨架比空讲概念直接得多_base_ [ ../_base_/models/pspnet_r50.py, ../_base_/datasets/cityscapes_832x832.py, ../_base_/default_runtime.py, ] model dict( typeEncoderDecoder, backbonedict( typeResNetV1c, depth50, num_stages4, out_indices(0, 1, 2, 3), dilations(1, 1, 1, 2), strides(1, 2, 1, 1), norm_cfgdict(typeSyncBN, requires_gradTrue), norm_evalFalse, stylepytorch), neckdict( typeFPN, in_channels[256, 512, 1024, 2048], out_channels256, num_outs4), decode_headdict( typePSPHead, in_channels2048, in_index3, channels512, pool_scales(1, 2, 3, 6), num_classes19, loss_decodedict(typeCrossEntropyLoss, use_sigmoidFalse, loss_weight1.0)), auxiliary_headdict( typeFCNHead, in_channels1024, in_index2, channels256, num_convs1, concat_inputFalse, num_classes19, loss_decodedict(typeCrossEntropyLoss, use_sigmoidFalse, loss_weight0.4)), train_cfgdict(), test_cfgdict(modewhole))这个配置文件里有几个关键细节out_indices(0, 1, 2, 3)表示Backbone要输出全部四个stage的特征这是FPN等Neck能工作的前提。如果只用最后一层完全可以只保留out_indices(3,)。dilations和strides控制空洞卷积的引入位置。这里把后两个阶段的stride改为1同时设置dilation为1和2目的是让最终特征图保持相对高的分辨率。neck并不是每个模型都必需。PSPNet原论文其实没有Neck但很多成熟配置会在中间加FPN让backbone的中间层特征也被利用起来。auxiliary_head是辅助损失分支通常挂在backbone的第三层输出上训练时帮助梯度传播。我把这种文件驱动的设计当成“配置即代码”。好处非常明显实验管理变得极轻量每换一种Backbone或Neck组合只需要新建一个很小的配置而不用改动任何模型源码。对于新手先读一个配置再对照模型结构图往往比直接啃源码高效得多。1.3 数据流在组件间怎么传递理解MMSegmentation的训练流程我建议把一次迭代拆成四步看数据流水线从磁盘读取图像和标签做随机裁剪、翻转、颜色抖动等增强然后把图像归一化到指定均值方差。Backbone接收经过预处理的图像输出若干层特征。比如ResNet50在out_indices(0,1,2,3)时输出C2原图H/4、C3H/8、C4H/16、C5H/32。Neck接收这些特征进行融合。以FPN为例它会把C2到C5统一通道数自顶向下逐层上采样相加得到P2到P5每一个都包含多尺度语义信息。DecodeHead从Neck输出或Backbone输出中收集所需特征做金字塔池化、ASPP、逐层上采样等操作最终输出形状为(N, num_classes, H, W)的预测图再与真实标签计算交叉熵损失。整个过程中最容易出错的地方是in_index。它表示当前模块从Backbone输出列表的哪个位置取特征而不是特征图的实际尺寸。很多新手自定义模型时把这个数字配错导致通道数对不上或分辨率异常报错信息还往往很不直观。检查这类问题时我一般先打印各阶段特征的shape再回头看in_index。三言两语讲完数据流下面进入真正重头的部分Backbone的选择与原理。2. 核心Backbone全拆解ResNet、HRNet与Transformer三大家族的取舍2.1 卷积基线的双雄ResNet与ResNetV1cMMSegmentation里最常见的Backbone是ResNet和ResNetV1c。它们本质上都沿用残差结构输入经过一个stride为2的7x7卷积完成初始下采样再通过四个stage逐级降低分辨率并增加通道数。四个stage的深度不同ResNet50是[3, 4, 6, 3]ResNet101是[3, 4, 23, 3]。在分割任务里直接沿用ImageNet预训练的ResNet会有个问题C5的特征图已经缩小到输入的1/32语义信息强但空间细节几乎丢失这对逐像素分类非常不利。于是MMSegmentation在配置里提供了两种通行做法把最后一个stage的stride从2改成1同时引入空洞卷积。这样C5分辨率变成输入的1/16甚至1/8而感受野不缩小。使用ResNetV1c这种变体把stem部分原来的7x7卷积替换成三个连续的3x3卷积预处理能力更强也更容易对齐MMSegmentation预训练权重。空洞卷积是这里的核心概念我多用一句话解释普通3x3卷积感受野是3x3dilation2时卷积核仍只有9个参数但每两个采样点之间空一格实际感受野变成5x5。所以它能在大分辨率特征图上保持大感受野这也是DeepLab系列能持续提高分割精度的基础。我的经验是如果显存充足、追求精度优先ResNet101或更大深度的ResNet如果做快速验证或轻量部署ResNet18就能跑通流程但mIoU会低不少。在Cityscapes这类街景数据上ResNet50与ResNet101的差距通常在1到3个点左右具体取决于数据集复杂程度。2.2 HRNet靠并行分支保住高分辨率信息HRNet和ResNet完全不是同一条路线。ResNet是串联式下采样特征图一路变窄HRNet则是从第一层开始始终保持一个1/4分辨率的高分辨率分支同时逐步增加1/8、1/16、1/32的并行分支多个分支之间通过反复的特征交换模块互相融合。这样做的好处很直接高分辨率分支全程保留细节低分辨率分支提供强语义最后把多个分支的特征concat再送入Head边缘和小目标分割效果通常比普通ResNet好。代价也明显显存占用和计算量都更大训练速度会慢。我在实际项目中用到HRNet的场景大多是工业质检或者卫星遥感切图这类任务里小缺陷和细长目标很多高分辨率信息价值极高。但需要提前评估显存比如输入裁剪尺寸比较大的时候HRNet-W48比ResNet50要多占不少显存预算有限时常常被迫减小BatchSize或裁剪尺寸。2.3 Transformer阵营ViT、Swin与分层TransformerViT类Backbone直接把图像切成16x16的patch每个patch通过线性投影变成token再经过多层全局自注意力建模长距离依赖。分割任务里用ViT做Backbone并不新鲜SETR等模型就是典型代表。但纯ViT有两个问题一是全局注意力复杂度高高分辨率输入友好度低二是patch较大直接丢失细节需要专门的分割Head去恢复空间信息。相比之下Swin Transformer是日常实践里最常用的Backbone之一。它的核心改进是分层结构和窗口注意力图像先切成4x4的patch经过若干stage后通过Patch Merging把2x2的patch合并成一个实现和ResNet类似的分层下采样自注意力只在一个固定窗口内计算复杂度不再是全局平方级还能通过移动窗口实现跨窗口信息交互。从工程角度说Swin的优势是它能输出多尺度特征正好对应MMSegmentation里FPN、U-Net等Neck和Head的输入需求。替换Backbone时只需要配置typeSwinTransformer、embed_dim、depths、num_heads等参数。我在Imagenet预训练权重加载顺利时Swin-L的精度往往能明显超过ResNet101但推理速度也明显下降需要根据任务取舍。更轻量的选项是SegFormer里用的Mix TransformerMIT它去掉了位置编码允许不同输入分辨率直接使用预训练权重还有B0到B5多个复杂度档位。想要快速试用Transformer分割模型时我会优先选它而不是Swin因为配置简单显存占用相对友好。2.4 Backbone对比和选择建议为了直观对比我按自己的使用经验整理了一张表Backbone结构特点优势劣势适合场景ResNet18/34轻量残差训练快、显存小语义表达能力一般跑通流程、快速基线ResNet50/101深层残差空洞卷积可配精度稳、预训练权重丰富高分辨率特征细节一般通用分割基准HRNet多分支并行高分辨率边缘和小目标细节好显存高、训练慢工业质检、遥感、医疗Swin Transformer分层窗口注意力精度高、多尺度特征自然速度慢、权重体积大追求精度、资源充足MIT/SegFormer系列无需位置编码的分层Transformer轻量、分辨率适应性强超大模型仍需堆算力快速迭代、部署我不会一上来就说“必须用哪个”而是建议第一次跑通项目先用ResNet50把数据、Head、训练策略都调明白再根据瓶颈换Backbone。如果换上去精度没提升问题往往不在Backbone而在Neck或数据侧。做完Backbone替换后下一步就是Neck。3. Neck不是可有可无FPN与特征融合在分割里到底解决了什么3.1 分割里的多尺度矛盾很多分割模型直接拿Backbone最后一个stage的特征图做预测这样做的问题是深层特征语义强但分辨率低小目标和物体边界很容易糊在一起。浅层特征分辨率高但语义不够抽象容易把同类物体的不同实例和背景混淆。检测任务早就用FPN解决了多尺度问题分割任务同样需要。Neck就是要解决“不同层级的特征如何各取所长”。如果只在最后一层特征上接Head等于放弃C2、C3这些高分辨率信息如果简单把多层特征相加又会带来严重的语义不对齐。于是FPN等结构成为标准选择。3.2 FPN的工作机制与实际收益FPN的完整流程是Backbone输出C2到C5各自通过1x1卷积统一到相同通道数比如256然后从最深层开始每次把上一层特征上采样2倍与下一层特征逐元素相加得到P2到P5。这样P2到P5每层都融合了深层语义和浅层细节。在MMSegmentation里配FPN非常简单neck dict( typeFPN, in_channels[256, 512, 1024, 2048], out_channels256, num_outs4)之后DecodeHead可以从in_index为0到3的4个特征里做融合。比如SegFormer的Head就是这么干的把4层特征都上采样到输入分辨率concat后过MLP分类。我做过一组简单对比同样用ResNet50在不改Head的情况下加一个FPN整体mIoU大概能提升1到2个点而显存增加非常有限。对小目标和多尺度场景提升会更明显。但FPN也不是越多越好。有些简单任务用一层特征就够了强行加Neck反而让训练变慢、调参变量更多。3.3 语义FPN和Neck选型的经验与检测里的FPN不同分割领域还有一个常见的“语义FPN”典型实现是把多层特征分别上采样到相同分辨率并拼接再交给一个简单的分类层。它不做逐层自顶向下融合而更像“把蛋糕切块再摊平”的思路。Panoptic Segmentation和某些轻量分割模型经常用这种设计。我在自主搭建分割流程时Neck的选型准则是数据集目标尺度差异大、小目标多就上FPN医学图像等目标结构固定则直接使用U-Net的编码器-解码器跳跃连接不太需要单独强调Neck如果用Transformer类Backbone它们本身已经输出多层级特征Neck用轻量FPN或MLP就够了。一句话总结Neck不是每个模型都必须但它决定了Backbone提取出的多尺度特征能否被有效使用。忽略Neck等于只拿Backbone最粗的一层特征去做精细分割。4. 数据集类型盘点从Cityscapes到自定义数据的格式设计与评估指标4.1 内置数据集类型与各自特点MMSegmentation内置了大量数据集类型我常接触的有四个Cityscapes、ADE20K、PASCAL VOC和COCO Stuff。Cityscapes是街景驾驶数据集31个原始类别中通常只用19个进行评测图像分辨率高1024x2048但训练集只有2975张精细标注图像这导致模型很容易过拟合需要比较强的数据增强。ADE20K是场景解析数据集包含150个物体类别图像规模约2万多张类别极不均衡很多类在训练集中出现次数很少。PASCAL VOC是最经典的精标注数据集21类含背景虽然规模不如前面两个但接口简单我经常拿它做算法快速验证。COCO Stuff是COCO数据集的Stuff扩展增加了大量背景区域类别适合做全景分割或带有强大环境语义的任务。这些数据集的差异不只是类别数量标签文件格式也不同。Cityscapes的标注图是彩色PNG需要转成trainId才能作为训练标签PASCAL VOC则是单通道调色板PNGADE20K的label索引从0到149直接使用。刚开始自定义数据处理时最容易在这些格式上翻车。4.2 自定义数据集的标准流程与常见踩坑在实际项目中几乎没有人会直接用内置数据集跑业务都得自己做数据集。MMSegmentation支持两类常见格式VOC格式和COCO格式。我一般优先VOC格式目录结构如下data/custom/ ├── JPEGImages/ │ ├── img_001.jpg │ └── img_002.jpg ├── SegmentationClass/ │ ├── img_001.png │ └── img_002.png └── ImageSets/ └── Segmentation/ ├── train.txt └── val.txtJPEGImages放原图SegmentationClass放灰度标签图train.txt和val.txt里每行是图片名不带扩展名。注意标签图中的类别索引必须从0开始0通常代表背景255表示ignore区域训练时会跳过。如果漏掉这条模型会把背景当成第0类甚至误把255也算进loss里导致训练无法收敛。数据集配置要修改的字段主要包括data_root、img_dir、ann_dir、classes和palette。尤其是palette它决定可视化时每个类别的颜色顺序必须和classes一一对应否则会画出颜色错乱但mask索引正确的图肉眼难以发现却在定性评估时造成困扰。我强烈建议每次新数据集训练前先跑一个类别像素占比分析脚本。比如某些类只占全部像素的0.1%在交叉熵loss里几乎不产生梯度。遇到这种情况要么用class_weight放大稀有类的权重要么用OHEM损失要么干脆采集更多该类样本。只盯着总体accuracy很容易被大背景类骗过去。4.3 评估指标mIoU与mPA到底怎么算语义分割最常用的指标是mIoU和mPA。IoU是每个类别预测区域与真实区域的交集除以并集mIoU是所有类别IoU的平均。mPA则是每个类别预测正确的像素比例的平均。两者都不考虑类别像素占比所以对稀有类更敏感。举个小例子某类在图像中只有10个像素模型一个没预测对因为总像素中其他类占99%整体像素准确率可能依然很高但mIoU会被这类拉下来不少。这也是为什么论文和比赛几乎都说mIoU而不是单纯像素准确率。在实际训练时我会在验证集上逐类打印IoU优先看稀有类的表现。如果大多数类都有50%以上的IoU只有某个类接近0通常是标注问题、类别数过少、或者特征区分度不够需要具体分析而不是盲目调学习率。数据集这块是整个分割流程的地基地基不平模型再先进也没用。下面进入重头戏把几个有代表性的算法族逐个拆开看。5. 主流模型算法族逐类剖析U-Net、PSPNet、DeepLab与SegFormer5.1 U-Net家族编码器-解码器与跳跃连接的价值U-Net来自医学图像分割结构上就是一个对称的编码器-解码器编码器逐步下采样提取语义解码器通过上采样恢复分辨率每一层解码器都会和对应的编码器特征做拼接形成跳跃连接。这种设计让细节信息可以直接传到解码端对小结构、边界不规则的物体非常友好。MMSegmentation里的U-Net实现可以通过backbonedict(typeUNet, ...)加载配置灵活支持不同stage数、通道数和是否使用预训练权重。我在医学图像和工业小目标分割中多次使用U-Net它的最大特点是数据需求量相对小、训练稳定。但如果目标尺度极端多样或者背景非常复杂U-Net的拼接式解码器会显得笨重因为它所有中间特征都同等对待没有实现自动的重点特征选择。此时后续模型系列会更合适。5.2 PSPNet金字塔池化模块如何捕获全局上下文PSPNet的核心是Pyramid Pooling Module简称PPM。在Backbone输出的最后一层特征上PPM分别以1x1、2x2、3x3、6x6等不同尺度做全局平均池化池化结果经过1x1卷积压缩通道后全部上采样回原尺寸并和原始特征拼接最终得到一个融合了全局与局部上下文信息的特征。这种做法解决了一个朴素问题只看局部卷积特征时模型很难知道这是一个“广阔的停车场”还是一个“狭小的路口”。PPM用多尺度池化把不同范围的全局信息都塞进特征能显著提升场景理解能力。PSPNet还经常配合一个辅助损失分支在backbone中间层加FCNHead帮助中低层学到更多语义。我在比较PSPNet、DeepLabV3和SegFormer时会特别关注PPM对上下文信息的需求。若数据集中物体尺度差异大且场景语义依赖强比如无人驾驶和遥感PSPNet是性价比很高的选择。但它的感受野固定对极细小的物体边界仍有些吃力。5.3 DeepLab系列空洞卷积、ASPP与Encoder-Decoder的推进DeepLab系列经历了V1到V3的演进核心贡献是把空洞卷积用到了极致。DeepLabV3的主力模块是ASPP它对Backbone最后一层特征并行施加多个不同dilation rate的空洞卷积再并联全局平均池化分支最后把多分支结果concat。这样一片特征图中能同时看到不同感受野的信息。DeepLabV3在V3基础上加入了解码器把ASPP输出的低分辨率特征上采样后与Backbone早期的高分辨率特征拼接再通过卷积融合。这个改动让边界细节大幅改善因为浅层特征拥有更多空间位置和边缘信息。实践里DeepLabV3长期是语义分割的强基线我在很多公开数据上跑效果稳定且不容易炸。使用DeepLabV3时有一个关键点空洞卷积率的设置需要配合Backbone输出分辨率。如果原本Config里output_stride8直接把dilation rate调得过大感受野会覆盖太多无关区域甚至带来棋盘格式的特征空洞反之率太小则多尺度建模能力下降。一般默认的ASPP rate为6、12、18配合ResNet输出的下采样率已经比较稳除非有特别需求否则我不会随意改。5.4 SegFormer无位置编码的Transformer分割新思路SegFormer在结构上给出了更简洁的答案用Mix Transformer做分层Backbone不用位置编码解码器只做轻量的MLP融合把所有层级的特征上采样到同一尺寸后concat再过MLP直接预测。由于没有位置编码测试时即使输入分辨率和训练时不同也不需要调整位置编码插值模型显得非常“自在”。SegFormer的MLP解码器看起来简单但它能充分受益于TransformerBackbone提供的多尺度特征。整体上SegFormer在精度和速度之间的平衡很好B0到B5可以覆盖移动端到高性能服务器的需求。我试过用SegFormer-B3替换DeepLabV3的ResNet101mIoU大致相当甚至略高但推理速度和显存占用更友好。需要注意的是SegFormer在较大输入尺寸下依然需要足够计算资源B4/B5配合高分辨率小作物时GPU内存占用会飙升。如果资源有限建议从B2开始试再根据效果往上顶。5.5 模型选型对比与建议下面这组对比来自于我跑过的多个项目具体数值会随数据集变化但规律比较稳定模型核心模块典型优势典型不足适用场景U-Net编码器-解码器跳跃连接小数据友好、边缘恢复好大尺度场景特征融合弱医疗、工业小目标PSPNetPPM多尺度池化全局上下文强边界细节一般街景、场景解析DeepLabV3ASPP空洞卷积多尺度鲁棒、稳定解码器弱、边缘偏粗通用分割基线DeepLabV3ASPP解码器多尺度边缘细节兼顾计算量较大通用精度优先SegFormerMITMLP解码器轻量高精度、分辨率适应好超大模型推理慢综合权衡、部署选型的真正逻辑是看“任务短板”。小目标多先考虑HRNet或更深的解码器上下文严重依赖场景PSPNet和ASPP效果好需要快速迭代和部署SegFormer轻量版本最舒服。没有万能模型只有合适与否。6. 训练配置与我最常踩的坑参数、标签、显存和可视化细节6.1 训练参数与学习率策略怎么定MMSegmentation默认采用的训练策略效果很稳优化器用SGD或AdamW初始学习率通常设为0.01配合SGD或6e-5配合AdamW并结合Poly学习率衰减即学习率按(1 - iter/max_iters)^power逐步下降power默认0.9。整个训练过程跟随迭代次数而不是epoch轮数max_iters一般设成160k或320k。对于常见分割任务我习惯用SGDmomentum0.9配合权重衰减0.0005效果最稳定。Transformer类Backbone则更适合AdamW学习率更低。此外配置里还要添加warmup前1000次迭代逐步把学习率从很小的值升到预设值避免训练初期剧烈震荡。6.2 我踩过四次的高频坑第一次坑是标签类别数不匹配。自定义数据集标注时把0作为背景但配置了num_classes20背景又被算作有效类导致背景类IoU虚高、实际目标类别学不好。后来统一规则背景0有效但显式加入class列表或者用255做ignore区域并让num_classes19不包含背景二者选一绝不混用。第二个坑是同步批归一化在多卡训练时的依赖问题。SyncBN能在多卡训练时同步统计均值和方差对小BatchSize非常有用但某些PyTorch版本和GPU卡配置下会报错或收敛异常。做多卡训练前先确认环境和配置里的norm_cfg来源一致不要出现混合使用BatchNorm和SyncBN的情况。第三个坑是显存不足时乱调BatchSize导致模型退化。我一度把BatchSize从8降到2结果精度大跳水后来才意识到小Batch下BN统计不稳定。正确做法是优先缩小输入裁剪尺寸其次减少GPU上的评估批次而不是硬调训练BatchSize。如果一定要小Batch就换成GroupNorm或者启用SyncBN。第四个坑是数据增强里的类别不平衡放大。许多分割数据集默认配置里包含随机裁剪、翻转和颜色抖动但如果我的小类别本来就少随机裁剪恰好容易把稀有类裁掉长期训练后稀有类完全消失。我现在的做法是统计类别覆盖面积给稀有类设定专门的最小保留比例或用Resize配合固定采样来降低这种随机风险。6.3 推理加速和TTA取舍推理阶段TTATest Time Augmentation可以带来明显提升。MMSegmentation支持多尺度推理和水平翻转推理通常把test_cfg里配置flipTrue并设置多组scale就能多拿1到3个mIoU点。代价是推理时间成倍增加。生产环境中我会关闭TTA只保留一个固定分辨率优先保证延迟稳定。加载模型进行推理时也容易被“加载完整模型dict”和“加载backbone预训练”搞混。如果是从头训练后再推理用load_from指定完整权重如果只是拿backbone的ImageNet预训练权重需要配置pretrained字段。两者混用会导致权重覆盖出问题训练效果反而不如随机初始化。6.4 可视化与日志检查的技巧训练过程中不要只盯loss曲线。我会同时开启TensorBoard的mIoU、准确率和每一类的IoU曲线因为loss下降不代表每个类别都均衡地变好。发现某个类曲线长期平走通常要先看是不是标签质量有问题比如图像边界标注不准、某些类别被其他类遮挡过度都会直接体现在单类IoU上。分割可视化的一个重要细节是palette对齐。MMSegmentation内置常用数据集的palette但自定义数据集必须自己给每个类别指定颜色。我习惯把颜色选成视觉差异大的RGB组合这样一眼就能看出模型是不是发生了混淆而不是把所有前景都预测成一个类别。最后说一个我沿用很久的工作习惯拿到任何一个新分割模型我都不直接把它塞进项目而是先用它默认配置里的Backbone和Head跑一次标准数据集得到baseline再逐项替换组件。替换Backbone时只改Backbone替换Neck时只改Neck绝不一次性变化太多变量。MMSegmentation这种“积木式”组装方式让我把精力重新放回“模型差异”和“数据本身”而不是每次换模型都要重写一遍训练测试流程。如果你正准备开始做语义分割我建议就从这套组件逻辑入手先把Backbone、Neck、Head各自的角色摸清楚再往里面填自己的数据和模型你会发现这条路比想象中顺很多。