简介：面向水体实例分割与目标检测任务的数据集，集中于waterbodies单类别，含训练集390张、验证集38张、测试集18张，共446张航拍或环境监测图像，以YOLO格式的多边形坐标点标注每个水体实例，能够精确勾勒水域边界。数据集划分合理，可直接用于训练和评估实例分割模型，适用于环境监测、水资源管理、农业灌溉规划及洪水风险评估等场景，也适合GIS、遥感和人工智能交叉领域的研究教学。压缩包共894个文件，主体为446张jpg原始图片与对应的446个txt标注文件，并附带1个yaml配置文件和1个docx说明文档，便于配置模型与快速上手，整体约27.97MB。目前已有99人学习/下载。对需要带标注水体数据开展算法验证、项目落地或教学实验的开发者与研究人员而言，这份数据集能显著降低数据准备成本，支持快速开展精准分割模型的实验与部署。
1. 拿到水体实例分割压缩包后，先确认这三件事
“水体实例分割数据集_20251116_162130.zip”这个命名透露了不少信息：时间戳20251116_162130大概率是导出时刻，也就是这批数据是截止到 2025 年 11 月 16 日 16:21:30 的快照版本。做过数据项目的人都知道，带时间戳的 zip 往往意味着“这套集子还会更新”，后续很可能出现_20251201_xxx.zip、_20260101_xxx.zip，所以第一件事不是急着解压，而是把这个版本号和你的模型实验记录绑在一起——你后面所有 mAP、mask IoU 数字，都得写清楚“这是基于哪个数据版本跑出来的”，否则换了新包旧结果全部作废。
这个包的核心内容是水体实例分割，也就是要把图像里的河流、湖泊、水库、养殖塘、甚至洪水淹没区逐像素抠出来，并且区分开“这是第 1 个水体，那是第 2 个水体”，不是简单地标成“水体/非水体”二分类。对比语义分割只输出一个类别掩码，实例分割额外要求实例编号，所以做排水口监测、汛期淹没范围评估、河湖“四乱”遥感核查这类工作的团队，最需要的就是这种带实例级标注的数据。其次是做目标检测或关键点检测的人，也能从这套数据里抽出 bbox 和轮廓点来复用，未必非得跑 mask 分支。
适合谁？两类人：一是手里有无人机或卫星影像、但要给水体目标做精细分割的算法工程师，二是准备从语义分割切到实例分割、需要一个干净数据集来跑通训练链路的新手。这篇文章就按“解压看结构 → 转成训练要用的标注 → 跑通 YOLOv8-seg → 排掉常见坑 → 验证效果”这条线，把这个 zip 用彻底。
2. 拆开 zip 看数据：文件结构、命名规则和标注的坑
拿到手别急着一把梭解压到桌面。先ls -lh看大小，再用unzip -l列目录，确认里面有没有嵌套压缩包、是不是伪加密、有没有 README。这个动作能帮你避免后面训练到一半发现标注文件缺了一大半的尴尬。
2.1 解压后常见的目录结构长什么样
水体实例分割数据集没有行业强制标准，但大多数标注团队会按“图像 + 掩码 + 标注文件 + 说明”这套结构组织。我用unzip -l看过不少类似包，一般会看到这样的布局：
unzip -l 水体实例分割数据集_20251116_162130.zip常见的内部结构是：
水体实例分割数据集_20251116_162130/ ├── images/ │ ├── train/ # 训练图像 │ ├── val/ # 验证图像 │ └── test/ # 测试图像（可能没有标注） ├── masks/ │ ├── train/ # 与 images/train 同名的 PNG 掩码 │ ├── val/ │ └── test/ ├── annotations/ │ ├── train.json # COCO 风格标注 │ ├── val.json │ └── class_names.txt ├── README.md └── splits.txt # 有些团队用这个记录图片划分先说命名规则这一个细节。很多包的图像名是DJI_20250812_093045_0014.jpg（无人机原文件名）或scene_00124.png（处理后的统一命名）。掩码文件通常和图像同名，只是扩展名换成png，而且和原图分辨率一致。你最好亲手验证一两个样本，别信 README 里的“保证一一对应”，因为不少包在流转过程中被 Windows 的压缩工具处理过，文件名大小写、路径分隔符都可能出问题。
提示：先从 zip 里抽 10 张图和对应掩码出来检查，确认
images/train/abc.jpg与masks/train/abc.png是严丝合缝的一对，再谈解压全部数据。
2.2 掩码文件是 8 位灰度还是 24 位 RGB，这是个关键分岔路
水体实例分割掩码有两种常见编码方式：类别掩码（8 位灰度，像素值 0 表示背景、1 表示水体类别）和实例掩码（每个实例一个独立值，比如第一个水体像素值 1，第二个水体像素值 2，最多可到 255）。如果包里的掩码是 RGB 彩色图——很多遥感标注工具导出的是带颜色的可视化 PNG——你必须先量化成调色板索引，否则直接训练会崩。
判断方法很简单，用 Python 看通道数和唯一像素值：
from PIL import Image import numpy as np mask = np.array(Image.open("masks/train/DJI_20250812_093045_0014.png")) print("shape:", mask.shape) # (H, W) 是灰度；(H, W, 3) 是 RGB；(H, W, 4) 带透明度 print("unique values:", np.unique(mask)[:20]) # 如果是 RGB，量化成 8 位索引：把 RGB 三元组映射成整数索引 if mask.ndim == 3: rgb = mask.reshape(-1, mask.shape[-1]) # 用调色板颜色去重，生成 0..N-1 的索引 uniq_colors = {tuple(c) for c in rgb.tolist()} color2idx = {c: i for i, c in enumerate(uniq_colors)} idx_mask = np.array([color2idx[tuple(c)] for c in rgb.tolist()], dtype=np.uint8) idx_mask = idx_mask.reshape(mask.shape[:2]) Image.fromarray(idx_mask, mode="L").save("masks/train/quantized.png")这段代码做了什么：先检查掩码维度；如果是 RGB，就把每个像素的(r,g,b)元组映射成序号，生成 8 位灰度索引图。注意这里的color2idx是按颜色出现顺序生成的，不是按语义顺序——如果原图背景是黑色、水体是蓝色，背景会被标成 0，水体标成 1，这个顺序和你训练时的类别 ID 可能不一致。量化之后一定要把背景的像素值置为 0，否则背景不小心变成了 1，整个分割头学习全乱。
多数水体数据集里背景像素用0，地物类别从1开始。但有的包反过来，背景用255，这样从视觉上黑底白图比较直观，可训练时你要把所有像素值255的改成0，不然维度直接多一位。拿np.unique(mask)看一眼再说。
2.3 annotations 里到底是 COCO JSON 还是别的格式
如果包里有annotations/目录，最常见的格式是 COCO JSON。这种格式的顶层结构是images、annotations和categories三张表，对实例分割来说，每一条 annotation 里最核心的字段是segmentation（多边形点坐标或 RLE 编码）、bbox和area。看这个：
import json with open("annotations/val.json") as f: data = json.load(f) print("categories:", data["categories"]) print("image count:", len(data["images"])) print("annotation count:", len(data["annotations"])) # 拿一条实例出来看字段 sample = data["annotations"][0] print("keys:", sample.keys()) print("bbox:", sample["bbox"]) print("segmentation type:", type(sample["segmentation"]))多数时候多边形是[[x1,y1,x2,y2,...]]这种按外圈坐标排列的浮点列表，坐标原点是图像左上角，不是归一化坐标。少数包给的是 RLE 字符串，你需要用pycocotools解出 mask。还有一种情况是标注是Cityscapes 风格的polygons.json——每个文件一个 JSON，里面是label和多边形顶点。如果包里的标注是这种，你要么写转换脚本进 COCO，要么用支持 Cityscapes 的框架直接读。
注意：COCO 的
bbox是[x, y, width, height]，是左上角坐标加宽高；如果哪天你看到[x1, y1, x2, y2]这种两角坐标，别怀疑，那多半是有人把 COCO 和 YOLO 格式混着导出了。这个坑在数据集里几乎年年碰到。
2.4 样本质量抽查：五张图看出这套数据能不能用
解压之后不要直接进训练，花一个下午做质量抽查，这是整个流程里性价比最高的一步。我一般会写一个可视化脚本，把原图和掩码叠在一起，用随机颜色渲染实例，然后盯着看几类问题。
import random import cv2 import numpy as np def visualize_instance(img_path, mask_path, save_path): img = cv2.imread(img_path) mask = cv2.imread(mask_path, cv2.IMREAD_GRAYSCALE) h, w = mask.shape # 给每个实例值生成一个随机 RGB 颜色 color_map = {} overlay = np.zeros((h, w, 3), dtype=np.uint8) for val in np.unique(mask): if val == 0: continue color_map[val] = [random.randint(30, 255) for _ in range(3)] overlay[mask == val] = color_map[val] blended = cv2.addWeighted(img, 0.6, overlay, 0.4, 0) cv2.imwrite(save_path, blended)重点检查三点：一是遮挡和相邻水体，两条河挨在一起时掩码有没有把边界切割干净，这决定实例分割的上限；二是小目标，有没有面积只有几十像素的池塘被标成了独立实例，这会影响模型对小水体的召回；三是标注与图像边缘，如果掩码贴着图像边缘切掉半个水面，训练时模型会被迫学习这种“截断水体”的形状，换到实际无人机影像上，这种形状根本不会出现。
整套数据在水体场景里最常见的质量问题是“标注了水面漂浮物”——藻华、浮萍被误标成水体，或者反过来，水体上停着船，船体又被算成水体。这类噪声不会让训练直接失败，但会让 mAP 涨到一定程度就上不去，因为模型在反复学“这片绿色像素到底归谁”这种二义性问题。
3. 把 zip 里的数据喂给 YOLOv8-seg：转换脚本与最小训练命令
这个 zip 里如果带的是 COCO 格式标注，训练 YOLOv8-seg 其实是顺路的事——Ultralytics 官方就支持 COCO 格式直接训练。但问题在于这套数据多半是从某个遥感标注平台导出的，格式很可能跟 YOLO 的预期不完全一致，所以第一步永远是把标注统一成 YOLO 的 txt 格式，再做训练。
3.1 为什么要转成 YOLO 的 txt 格式而不是直接 JSON
YOLO 系列做实例分割使用的标签是每张图像一个同名.txt文件，每一行代表一个实例，格式是：
class_id x1 y1 x2 y2 ... xn yn其中x1 y1到xn yn是归一化坐标，数值在 0~1 之间，不需要保存类别名称。对比 COCO JSON，这个格式没那么多嵌套字段，读取和训练都快得多。更重要的是，Ultralytics 在加载数据时，如果检测到 labels 目录下没有.txt，就会尝试自己去跑一个格式转换，这个过程没准会给你把坐标归一化算错，所以自己动手转是最稳的。
转换脚本的思路是这样：读 COCO JSON → 取每个 annotation 的segmentation多边形坐标 → 把绝对坐标归一化到 0~1 → 写到labels/train/下同名 txt。
import json import os import numpy as np def coco_to_yolo_seg(coco_path, label_dir, img_dir): os.makedirs(label_dir, exist_ok=True) with open(coco_path) as f: data = json.load(f) # 建立 图像id -> 文件名 的映射，方便给 txt 命名 id2name = {img["id"]: img["file_name"] for img in data["images"]} # 记录每张图尺寸，用于坐标归一化 id2size = {img["id"]: (img["width"], img["height"]) for img in data["images"]} # 按图像 id 把 annotation 分组 from collections import defaultdict anns_by_img = defaultdict(list) for ann in data["annotations"]: anns_by_img[ann["image_id"]].append(ann) for img_id, anns in anns_by_img.items(): fname = id2name[img_id] stem = os.path.splitext(fname)[0] w, h = id2size[img_id] out_path = os.path.join(label_dir, stem + ".txt") lines = [] for ann in anns: # COCO segmentation 可能是多边形列表，也可能是 RLE，只处理多边形 seg = ann["segmentation"] if not isinstance(seg, list): print(f"skip RLE annotation in image {fname}") continue # 只取第一组点，通常就是外轮廓，needed to handle holes 另行处理 poly = seg[0] # 展平并归一化 poly_norm = [] for i in range(0, len(poly), 2): px = poly[i] / w py = poly[i + 1] / h px = min(max(px, 0.0), 1.0) py = min(max(py, 0.0), 1.0) poly_norm.extend([px, py]) line = f"{ann['category_id']} " + " ".join(f"{v:.6f}" for v in poly_norm) lines.append(line) with open(out_path, "w") as f: f.write("\n".join(lines) + "\n") coco_to_yolo_seg("annotations/train.json", "labels/train", "images/train")逻辑说明：这里用id2name和id2size建了映射，重点在于归一化时用的宽高必须来自images表里的记录，而不是你自己读图算出来的尺寸——如果图像在实际读取时被 EXIF 旋转过，宽高可能对不上，转出来的坐标全部错位。poly[0]只取了多边形第一组点，因为 COCO 允许一个实例有多个多边形（例如水体中间有个岛洞），大多数训练框架不支持这种带洞的多边形表示，先忽略洞是常见取舍。
3.2 数据集的 YAML 怎么写：路径、类别和掩码的映射关系
YOLOv8-seg 需要一份 YAML 来描述数据集的路径和类别。这里有个很常见的翻车点：Ultralytics 要求 YAML 里写的是图像目录的路径，masks 的路径不在 YAML 里显式出现——它靠“同名 txt 文件”对应到图像，txt 里存的就是掩码多边形。也就是说，你的train路径只指向images/train，labels目录要放在同级目录下，命名必须精确匹配。
# water_seg.yaml path: /path/to/水体实例分割数据集_20251116_162130 # 数据集根目录 train: images/train val: images/val test: images/test names: 0: water注意names这里的类别 ID 必须和转换出来的 txt 第一列数字完全一致，类别名叫什么都行，模型不关心，它只认数字。如果你的包里有多个水体类别（如river、lake、pond），就按次序列出：
names: 0: river 1: lake 2: pond很多人在这一步偷懒，直接把类别叫water，然后在推理时拿到 0 号类别就去二值化输出。这样当然也能跑，但如果你关心河流和池塘分别的精度，应该用多类别方案。从水体应用来看，多类别比单类别有用得多——你要统计的是“这段河道被淹了还是旁边池塘溢了”，不是“图里有水”。
3.3 最小训练命令：从 300 步开始，验证链路通不通
第一轮训练的目标不是刷高分，是确认数据链路的正确性。跑 300 步，如果在验证集上能看到 mask 输出不是一团黑，就值得继续。
yolo segment train \ model=yolov8n-seg.pt \ data=water_seg.yaml \ epochs=100 \ imgsz=640 \ batch=8 \ device=0 \ patience=20 \ project=runs/segment \ name=water_v0参数说明：yolov8n-seg.pt是 nano 级分割模型，权重文件最小、训练最快，用来跑通链路最合适；imgsz=640是输入分辨率，常见做法先按 640 跑通，后面要想提升小目标精度再上 960 或 1280；batch=8取决于显卡显存，12GB 显存跑 640 分辨率基本够，如果你的卡只有 8GB，降到 4；patience=20意思是连续 20 轮验证指标不涨就提前停，这能帮你省大量时间，尤其是数据量只有几千张的时候。
第一次跑完，打开runs/segment/water_v0/目录，先看results.png这张曲线图。重点看两条曲线：seg_loss和mask_loss是不是在下降。如果 loss 纹丝不动，先怀疑数据有问题，比如掩码值为 255 的背景没有清成 0；如果 loss 下降但验证集 mAP 一直是 0，那大概率是训练集和验证集有重叠，或者验证集的 txt 命名对不上。
提示：先跑通再优化。这个数据集命名带时间戳，说明它会持续更新，你应在第一轮就把数据处理脚本封装好，后面新版本只要改一下路径就能重新生成 labels，否则每次换数据都要手工转一遍，纯属浪费生命。
3.4 训练时你需要盯的三个参数：imgsz、overlap_mask、mask_ratio
在正式训练前，有研究者让我必须在参数上做选择。第一个是imgsz：水体分割的目标物往往边界不规则，但占图面积可能很大（一条河横穿整幅图），也可能很小（一个小水塘）。640 对大面积水体够用，但小水塘会被压成 10x10 的像素块，分割头根本学不出精细边界。建议第一轮用 640，第二轮视小目标情况提到 960。
第二个是overlap_mask，Ultralytics 在训练时默认把掩码下采样到低分辨率再上采样回来做 loss 计算，overlap_mask=True会让相邻实例的掩码在重叠区都参与计算，这对水体这种边界接壤的实例特别重要。默认值是 True，不用动。
第三个是mask_ratio，默认 4，意思是掩码在训练时被下采样到原始分辨率的 1/4。如果你特别在意水体边缘精度，可以改成 2，代价是显存增加、训练速度变慢。我自己一般保持 4 先跑，等验证集 mAP 到了 70 以上，再试mask_ratio=2看边界效果是否显著改善，没有明显改善就回到 4。
4. 水体实例分割常见的五个坑：现象、原因、解决办法
这一章是实战中翻车率最高的几个点，每条都是“现象 → 原因 → 解决”的结构，按踩坑频率排序。
4.1 训练 loss 正常下降，但推理时掩码与水体边缘严重锯齿化
现象：训练曲线一切正常，val mAP 也不低，但打开推理结果，水体的边缘是一条明显的锯齿折线，尤其在河流这种线性目标上特别严重。
原因：YOLOv8-seg 的掩码输出分辨率是imgsz / mask_ratio，默认 640/4=160。160x160 的掩码上采样回原图，边缘自然会锯齿。另外如果训练数据里掩码本身就有大量直角边（标注工具导出的多边形顶点取了整数像素），模型学到的就是折线边缘。
解决：推理时提高imgsz，验证阶段用 960 或 1280，并开启retina_masks=True（Ultralytics 的推理参数，通过高分辨率特征图来细化掩码）。如果还是不行，检查训练数据掩码是否太粗糙——用标注软件重新细化的成本远大于后期搞后处理。
4.2 同一片水域，两个相邻的实例被模型合并成一个
现象：模型输出的掩码里，原本应该是“两个相邻但独立的鱼塘”，结果被预测成一个大块连通域，实例 ID 只有一个。
原因：相邻水体的边界在图像上可能只有一条田埂的宽度（几个像素），模型在低分辨率特征图上把边界特征丢失了。另一个常见原因是数据里标注本身就把边界标成了同一个连通域——标注人员偷懒，把两个池子合成一个 polygon 来画。
解决：先检查数据。把 val 集的标注可视化出来，如果标注是分开的，那就调高imgsz到 960，让模型在更高分辨率下看到边界。如果标注本身是合并的，你需要重新标注或写脚本把连通域拆开——对掩码做cv2.connectedComponents，把不同连通域拆成不同实例 ID。
4.3 类别 ID 错位，导致训练时 loss 为 NaN 或在验证集上全部误判
现象：某次试验里，训练到第 2 个 epoch，loss 突然变成 NaN；或者训练正常，但验证时所有预测都归属类别 3，而数据根本没有类别 3。
原因：COCO JSON 里的category_id通常不是从 0 开始的，比如原始数据集用了1: water，转换成 YOLO txt 时没有减 1。Ultralytics 的类别编码是从 0 开始的，你给了它很多1，但没有0，分类头会崩溃。更有甚者，JSON里同时出现了0和1但含义不是“类别 0”而是“背景”和“水体”，这也会错乱。
解决：转换脚本里统一做category_id - 1，且保证编号是连续的0,1,2,...。更稳妥的办法是读 JSON 时先看categories表，重新建立一套从 0 开始的映射，不要直接用原始 ID。
4.4 zip 解压后文件缺失，尤其是掩码 PNG 比图像少几百张
现象：使用arcpy、QGIS 或干脆是人类手动拷贝，掩码文件在传输中丢失。训练到中途报FileNotFoundError: masks/train/xxx.png。
原因：很多数据集 ZIP 在 Windows 上压缩时，长路径会自动截断；还有一些压缩软件对中文文件名处理粗糙，导致解压出来一堆乱码文件名，和图像对不上。另一个高发原因是：掩码 PNG 的像素位数超出标准（比如 16 位 PNG），Python 的Image.open不报错，但后续 numpy 转 uint8 会把高 8 位丢掉。
解决：解压时用unzip -O UTF-8（Linux）或 Bandizip（Windows）这类处理 Unicode 文件名较好的工具。解压后跑一个校验脚本：遍历 images 目录所有文件名，检查 masks 目录是否有同名文件，缺失的输出到一个清单里，再回去 zip 里捞。
cd 水体实例分割数据集_20251116_162130 for img in images/train/*.jpg; do base=$(basename "$img" .jpg) [ -f "masks/train/$base.png" ] || echo "missing: $base" done4.5 掩码里的水体被分成了“标注噪声”：细碎多边形、单像素孤岛
现象：可视化标注时，发现同一个水体被拆成了几十个细碎多边形，有些多边形只有一个像素大小；训练出的模型把这些孤岛也预测成水体，导致最终的水体面积统计虚高。
原因：标注工具自动生成的掩码没有做后处理，把水面的反光、泡沫板、停靠船只当作独立的实例或者把边缘噪声画成了小多边形。这类数据如果直接训练，模型会学到“任何孤立绿色块都算水体”，这在河流监测里特别致命——你统计的淹没面积会被泡沫板污染。
解决：清洗标注，把面积小于阈值的实例删除。阈值取 50 像素（640 分辨率下约占总面积 0.01%）或根据你的图幅决定。用脚本统计每个 polygon 的面积，低于阈值的直接跳过；面积大于某个超大值（比如超过图像面积 80%）的也要检查——那多半是把整幅图的背景误标成了水体。
5. 验证水体分割效果：从 mAP 到“边缘质量”的完整检查清单
训练结束不代表数据集就真正用起来了。水体实例分割跟通用目标分割不一样，用户最关心的是边界准不准、面积对不对，而不是类别对不对。我一般会按下面这套流程做验证，每一步都能告诉你是模型问题还是数据问题。
5.1 跑验证，先看 mask mAP 再看 box mAP
yolo segment val \ model=runs/segment/water_v0/weights/best.pt \ data=water_seg.yaml \ imgsz=960 \ conf=0.25 \ iou=0.5 \ project=runs/segment \ name=water_v0_val输出里有两组关键指标：mask_mAP50和mask_mAP50-95。前者是宽松评价，只要掩码和真值有 50% 交并比就算预测成功；后者要求精确到像素级匹配，水体分割业务普遍用后者来考核。如果你的mAP50-95和mAP50差距过大（比如 0.9 对 0.55），说明边界定位能力弱，问题可能出在掩码下采样过猛（mask_ratio=4）或标注边界粗糙。
5.2 面积误差是水体分割特有的硬指标
对水体监测业务来说，算面积比算像素更实在。我在验证时习惯加一段面积统计脚本，把预测掩码和真值掩码分别计算连通域面积，再对比每个实例的面积误差。
import cv2 import numpy as np def area_error(pred_mask, gt_mask, pixel_size=1.0): """pixel_size: 单像素对应的实际面积，如遥感图 1 像素 = 0.25 平方米""" pred_areas = [] gt_areas = [] num_pred, pred_labels = cv2.connectedComponents(pred_mask, connectivity=8) num_gt, gt_labels = cv2.connectedComponents(gt_mask, connectivity=8) for i in range(1, num_pred): pred_areas.append(np.sum(pred_labels == i) * pixel_size) for i in range(1, num_gt): gt_areas.append(np.sum(gt_labels == i) * pixel_size) return sorted(pred_areas, reverse=True), sorted(gt_areas, reverse=True)注意connectivity=8，对水体这种可能只有 1 像素宽细长河流的目标，4 连通会漏掉很多斜向相邻的像素，8 连通更符合水体的实际连通性。面积误差先看大水体：面积排名前 5 的真值，对应预测面积和真值面积的误差百分比。如果大水体面积误差在 10% 以内，说明模型基本学到了正确尺度；如果小水体误差普遍超过 50%，那大概率是分辨率不够导致小目标缩水。
5.3 用测试集跑一次完整推理，保存可视化结果
训练完成不是终点，你最终要交付的是能跑的推理结果。把最佳权重在测试集上过一遍，输出叠加了掩码的图片和对应的 GeoJSON 或 Shapefile（如果后续要做 GIS 叠加分析）。
yolo segment predict \ model=runs/segment/water_v0/weights/best.pt \ source=images/test \ imgsz=960 \ save=True \ save_txt=True \ save_conf=True \ project=runs/segment \ name=water_v0_predictsave_txt=True会把每个实例的归一化多边形点保存成 txt，save_conf=True会附带置信度。这两个开关在数据集有更新版本时要重点用——后续新版的 zip 来了，你可以用旧模型跑一遍，对比新旧数据的难例分布，快速判断新版哪些场景被强化了，哪些被削弱了。
5.4 水体分割的边界质量评估：拉普拉斯方差与像素级边缘 F1
严格来说，水体分割的“好用”不止是 mAP 高，还要边缘贴合。我常用一个轻量评估：把预测掩码和真值掩码都提取边缘，计算边缘像素级别的 F1-score。水体边缘往往是直线（河岸）或光滑曲线（湖泊岸线），如果模型预测边缘飘在真值边缘外几个像素，F1 会掉得非常明显。
def edge_f1(pred_mask, gt_mask): pred_edge = cv2.Canny(pred_mask.astype(np.uint8), 100, 200) gt_edge = cv2.Canny(gt_mask.astype(np.uint8), 100, 200) pred_pixels = set(zip(*np.where(pred_edge > 0))) gt_pixels = set(zip(*np.where(gt_edge > 0))) tp = len(pred_pixels & gt_pixels) fp = len(pred_pixels - gt_pixels) fn = len(gt_pixels - pred_pixels) precision = tp / (tp + fp + 1e-6) recall = tp / (tp + fn + 1e-6) return 2 * precision * recall / (precision + recall + 1e-6)边缘 F1 建议结合可视化看，一条河预测得整体偏左 2 像素，F1 可能只有 0.5，但人眼看图觉得还行。水域面积误差和边缘 F1 这两个指标配合 mAP 一起用，才能说清“这套数据训练出来的模型合不合格”。
6. 用数据版本文件名做实验追踪，多跑两次 A/B 对比再下结论
最后一章落到一个我个人的实用习惯：把数据集文件名里的时间戳用起来。很多团队训练时 dataset 路径直接写死，换数据包之后结果全都对不上，等到写报告时才发现“上一个版本”到底用的哪套数据已经说不清了。我的做法是，每次实验记录里强制写上 zip 的完整文件名，包括时间戳；同时给训练的 YAML 加一个注释字段：
# water_seg_v2.yaml —— 对应水体实例分割数据集_20251116_162130.zip path: /path/to/水体实例分割数据集_20251116_162130 train: images/train val: images/val names: 0: water更硬核的做法是把数据版本号和模型的训练日志绑在一起，在训练命令里直接用name字段标上版本号：
yolo segment train \ model=yolov8s-seg.pt \ data=water_seg.yaml \ epochs=150 \ imgsz=960 \ batch=8 \ device=0 \ project=runs/segment \ name=water_20251116_imgsz960_s这样runs/segment/目录下每个实验文件夹都自带数据版本标识，几个月后再回来翻，一眼知道water_20251116用的是哪一套 zip。
另外一个建议是把第一轮结果当成基准，固定下来，之后所有参数调整都围绕它做 A/B 对比。比如你已经完成water_20251116_imgsz640_n这个 baseline，接下来想试更大分辨率。不要直接全量训一版 1280，那会花掉好几个小时还不一定有效。正确姿势是先挑 200 张难例样本（验证集里 mAP 最低的那些图），在 640、960、1280 三档分辨率下各跑 30 个 epoch，看难例集上的 mask mAP 提升是否成比例。如果 640→960 提升了 3 个点，960→1280 只多了 0.5 个点，直接选 960，省下来的时间够你多调两轮增强策略。
类似的 A/B 对比还应用在掩码后处理上。水体分割输出往往有一堆细碎小区域，很多团队的常规操作是过滤掉面积小于阈值的连通域。阈值定多少？没有放之四海皆准的值，按图像分辨率来：天空俯瞰视角的无人机图，一个 50x50 像素的小水塘是真实目标，别一刀切；如果是 0.5 米分辨率的卫星影像，50 像素已经是很小的水面了。用验证集分别跑 20、50、100 像素阈值，对比哪个阈值下面积误差最小，再定下来。
最后说一个我从踩坑里得来的习惯：任何模型更新之前，先把新的数据集 zip 解压到独立目录，跑一遍验证集的“新旧版本对比”——用旧模型跑新验证集，看 mAP 掉多少。如果掉了超过 10%，说明数据集本身内容变化大（新增了以前没见过的场景），这时候盲目换新模型训练大概率会过拟合新样本；如果 mAP 波动在 2% 以内，说明数据分布稳定，可以放心在新版本上继续迭代。这招帮我避开了不少“模型突然变笨”的悬案，希望也能帮到你。
本文还有配套的精品资源，点击获取
