企业官网建设流程全解析

简介：一套面向印章检测任务的Pascal VOC与YOLO双格式标注数据集，共包含210张真实场景JPG图片，标注类别为seal（印章），总计488个目标框。数据集由labelImg工具绘制矩形框完成，标注规则统一，质量清晰，可用于训练YOLOv系、Faster R-CNN等常见目标检测模型，也可用于印章识别、文档图像处理等场景，适合目标检测入门者及算法工程师快速开展实验。整个资源包共632个文件，以jpg图片、xml标注和txt标注为主体，其中图片与VOC格式XML一一对应，YOLO格式TXT和辅助文本共同构成训练所需注释，压缩包仅36.47MB，内容紧凑、目录清晰，解压后即可按常见流程划分训练/验证集使用。目前已有919人浏览学习。数据集只保证标注准确合理，不附带训练权重或精度承诺，使用者可针对自己的模型结构做进一步调优，省去大量人工标注成本。

1. 印章检测数据集 VOC+YOLO 格式 210 张 1 类别：小样本目标检测的完整起点

很多人拿到一份 210 张的印章检测数据集，第一反应是「这么少能训出什么」。这话对了一半：靠 210 张确实刷不出比赛级精度，但它恰好是跑通 VOC → YOLO → 训练 → 部署全流程的低成本样本。VOC 负责把人能读懂的标注存成 XML，YOLO 负责把坐标归一化喂给模型，1 个类别让新手不用纠结类名映射，210 张让每次训练几分钟内出结果。适合刚入坑目标检测、想用 YOLO 训自己数据的从业者，也适合拿来做标注工具和转换脚本的练兵场。别急着加数据，先把两套格式的换算关系吃透，比多标一百张图管用。

2. VOC 与 YOLO 两套标注格式：坐标系、归一化与为什么小数据集要双格式共存

2.1 VOC 的 XML 到底存了什么：从 filename 到 bndbox 的关键字段

Pascal VOC 是目标检测领域最老牌的数据集组织方式之一，它把每张图的标注信息放在一个 XML 文件里。印章检测数据集采用这套格式，是因为 LabelImg 这类标注工具默认输出就是 VOC，而且 XML 的可读性比纯文本好太多：打开一个 XML，你能直接看到这张图叫什么、尺寸多大、框在哪儿、属于哪个类。对 210 张这种小数据集，人工抽检 XML 是排查标注错误最直接的手段。更关键的是，VOC 格式把「给人看的信息」和「给模型看的信息」分离了，这为后面转 YOLO 格式留出了清晰的中间层。

一个典型的 VOC XML 长这样：

<annotation> <folder>JPEGImages</folder> <filename>seal_001.jpg</filename> <size> <width>1024</width> <height>768</height> <depth>3</depth> </size> <object> <name>seal</name> <pose>Unspecified</pose> <truncated>0</truncated> <difficult>0</difficult> <bndbox> <xmin>312</xmin> <ymin>245</ymin> <xmax>689</xmax> <ymax>622</ymax> </bndbox> </object> </annotation>

这里真正影响训练的字段只有三个：filename 用于定位图片，size 里的 width 和 height 用于坐标换算，bndbox 里的四个值就是印章在图像上的像素位置。坐标系以图像左上角为原点，x 轴向右，y 轴向下，xmin/ymin 是框的左上角，xmax/ymax 是右下角，全部是绝对像素值。pose、truncated、difficult 在单类印章场景基本用不上，但转换脚本里建议保留 difficult 字段，因为半枚印章或严重遮挡的样本，你可以用它在生成 YOLO 格式时单独决定留还是丢。

需要注意，XML 里的 object 节点可以出现多个。一张扫描件上可能同时有公章、骑缝章、法人章，它们共享同一个 size，每个 object 各带一个 bndbox。读取时用 root.iter('object') 就能遍历全部目标，这也是第 4 章转换脚本的基础。小数据集上最常见的问题是标注时漏标了角落里的小章，而人工翻 XML 检查多目标恰恰比翻图片更高效——一眼扫过去就能数出每张图有几个 object，和原图对不上再回去补标。

2.2 YOLO txt 的归一化坐标：中心点、宽高和 VOC 的换算关系

YOLO 系列（从 v5 到 v8）用的是另一种标注：每张图对应一个同名 txt 文件，每行描述一个目标，格式是 class_id center_x center_y width height。和 VOC 的最大区别是坐标全部归一化到 0~1 区间——不管原图是 640 还是 4000 像素宽，统一换算成相对值。这样模型在训练时缩放到任意尺寸都不会被绝对坐标干扰，这也是 YOLO 训练框架普遍采用这种格式的原因。

换算公式并不复杂，设 xmin、ymin、xmax、ymax 为 VOC 框坐标，W 和 H 为图像宽高：

• center_x = (xmin + xmax) / 2 / W
• center_y = (ymin + ymax) / 2 / H
• width = (xmax - xmin) / W
• height = (ymax - ymin) / H

对应到上面那组 XML 数值，W=1024、H=768，算出来就是 center_x=0.489、center_y=0.564、width=0.368、height=0.491，写进 txt 就是一行「0 0.489 0.564 0.368 0.491」。注意 class_id 从 0 开始，单类印章就是 0，对应 classes 列表里的 seal。这就是 VOC 和 YOLO 两套格式间的映射关系。手工算一两次找感觉，剩下交给脚本，但心里要始终有这根弦：YOLO txt 里没有图像尺寸信息，所有数值都是相对值，任何一张图的标注必须配合它的原始分辨率才能还原出真实框位置。

提示：VOC 的 XML 是给人看的，YOLO 的 txt 是给模型吃的。数据集同时保留两种格式，意味着你既能用可视化工具做抽检，又能直接开训，不需要临时转换。

之所以强调「210 张也要双格式共存」，是因为小数据集迭代频繁：你很可能今天发现标注框画歪了一片，要改几十个 XML；也可能想换一种增强策略重新切分数据集。如果只有 YOLO 格式的 txt，改起来要靠肉眼读小数；有 VOC 原始标注在，改完 XML 重新跑一遍转换脚本就行。这套工作流在后续扩展到几百上千张时依然成立，属于一次投入长期受益的典型做法。想快速验证换算对不对，可以挑一张图手算一个框，再画回去对比，比写单元测试还直接。

3. 210 张 1 类别的数据集落地：目录结构、标注规范与训练集划分

3.1 目录规划与文件命名：给后续转换脚本少留一个坑

拿到原始图像后，第一件事不是急着标注，而是把目录结构定好。常见做法是建一个跟 Pascal VOC 对齐的文件夹骨架，即使你后续只跑 YOLO，也建议保留这套结构，因为多数开源转换脚本都按这个约定读路径。目录结构如下：

seal_dataset/ ├── Annotations/ │ ├── seal_001.xml │ ├── seal_002.xml │ └── ... ├── JPEGImages/ │ ├── seal_001.jpg │ ├── seal_002.jpg │ └── ... ├── labels/ │ ├── seal_001.txt │ └── ... └── ImageSets/ └── Main/ ├── train.txt └── val.txt

这个结构里，JPEGImages 放原始图片，Annotations 放 VOC 格式的 XML，labels 放转换后的 YOLO 格式 txt。ImageSets/Main 下放划分清单，每个 txt 一行一个文件名（不带后缀），训练框架按这个清单去找图和标注。名字上我习惯用字母加数字的组合，比如 seal_001，千万不要用中文、空格和特殊符号——从 LabelImg 到转换脚本再到训练框架，每一层都可能被路径解析卡住。这个习惯在你用 PyCharm 打开项目、跑 YOLO 训练时尤其重要，Windows 下中文路径加反斜杠转义，能一次性击穿你半天时间。

文件名一致性是这里最隐蔽的坑：JPEGImages 里有 seal_001.jpg，Annotations 就必须有 seal_001.xml，转换后 labels 里必须有 seal_001.txt，三个目录同进同退。210 张图规模不大，建议先跑一条检查命令，缺哪个文件立刻补：

cd seal_dataset for f in JPEGImages/*.jpg; do base=$(basename "$f" .jpg) [ -f "Annotations/$base.xml" ] || echo "缺 XML: $base" [ -f "labels/$base.txt" ] || echo "缺 TXT: $base" done

这段脚本遍历所有 jpg，逐个检查同名 xml 和 txt 是否存在，缺失的打印出来。三条目录一条命令验完，问题暴露在训练开始之前。很多初学者在这步偷懒，结果训练到一半框架抛 FileNotFoundError，回头排查才发现是某张图的标注文件名多了个空格导致对不上，白等几十分钟训练。

3.2 标注规范：印章框怎么画才不把模型带偏

标注是整个数据集中最影响模型上限的环节。印章检测的难点在于形状和背景不统一：圆形公章、椭圆合同章、方形发票章，外框类型多样，而且印章经常压在文字或背景图案上，颜色在红、蓝、紫之间变。既然数据集只有 1 个类别，类名统一叫 seal，就不要再拆公章、合同章、发票章，那是多类别任务的玩法，单类别数据集硬拆只会让每个子类的样本量跌破训练下限。

画框的原则是紧贴目标边缘。圆形印章按外切矩形框，上下左右各切到印章色块最外侧；方形印章直接按边框走。常见错误是框得比印章大一圈，把背景文字圈进来，模型就会学着用「印章加周边文字」做特征，换一张干净的合同扫描件就漏检。骑缝章或半枚章这类难样本，我的经验是只框可见部分，并且在 XML 里把 difficult 标记为 1。转换时可以选择剔除或保留，至少留了后悔药，不用为了一两张图的取舍重标整个数据集。

标注工具上，LabelImg 是最常见的选择，它默认输出 VOC 格式 XML。在 PyCharm 里装一个就能直接跑起来：新建项目、pip 安装 labelimg、命令行启动，打开图片后按 Create RectBox 拉框，输入类名 seal，保存自动生成同名 XML。210 张两三个人一小时能标完，但别图快：框边缘是否贴紧、是否漏标角落里的半枚章，这些都会直接反映在训练后的漏检率上。标注这步偷的懒，后面调模型要加倍还回来。

3.3 划分 train / val：小数据集的切分比例不用太纠结

210 张规模，常见做法是 8:2 划分，即 168 张训练、42 张验证，不再单独切测试集。验证集兼任测试集，小数据集追求的是流程跑通和迭代效率，不是刷榜单。切分时要注意：同一份文档的两页扫描件很可能内容高度相似，随机打乱后大概率各分到训练和验证里，这样的验证集指标会虚高。最稳的做法是按文档来源分组再切，如果 210 张来自 30 份合同，就先分 30 个组，按组抽样。

import os import random from sklearn.model_selection import train_test_split xml_files = [f.replace('.xml', '') for f in os.listdir('Annotations') if f.endswith('.xml')] random.seed(42) train_files, val_files = train_test_split(xml_files, test_size=0.2, random_state=42) def write_list(path, files): with open(path, 'w') as f: f.write('\n'.join(sorted(files))) os.makedirs('ImageSets/Main', exist_ok=True) write_list('ImageSets/Main/train.txt', train_files) write_list('ImageSets/Main/val.txt', val_files) print(f'train: {len(train_files)}, val: {len(val_files)}')

这段脚本按 8:2 把文件名写入 ImageSets/Main 下的两个 txt。test_size=0.2 就是留 20% 做验证，random_state=42 保证多次运行划分结果一致——这一步在后续调参复现实验结果时非常关键，没有固定种子，每次划分不同，模型的指标变化就说不清是改动生效还是划分运气。注意这里划分的是文件名，不是直接移动文件，图片和 XML 仍留在原目录，训练框架按清单去取。如果验证集里难样本太少，比如 42 张全是清晰大章，模型对遮挡样本的泛化能力就完全没被评估到。这时候宁可牺牲一点训练数量，也要手动把几张文理骑缝章塞进验证集。

4. VOC 转 YOLO 格式：转换脚本与四个边界坑

4.1 转换脚本：从 XML 解析到 txt 生成的一站式代码

当 XML 标注完成、train/val 清单也切好之后，下一步是批量生成 YOLO 格式的 txt。下面这个脚本是实际项目里最常见的做法，一次遍历 Annotations 目录，解析每个 XML，计算归一化坐标，写入对应 labels 文件，同时处理越界和空标注两类边界情况：

import xml.etree.ElementTree as ET import os classes = ["seal"] def xml_to_yolo(xml_path, target_dir): tree = ET.parse(xml_path) root = tree.getroot() filename = root.findtext('filename') size = root.find('size') W = int(size.findtext('width')) H = int(size.findtext('height')) lines = [] for obj in root.iter('object'): name = obj.findtext('name') if name not in classes: continue difficult = obj.findtext('difficult') if difficult == '1': continue box = obj.find('bndbox') xmin = float(box.findtext('xmin')) ymin = float(box.findtext('ymin')) xmax = float(box.findtext('xmax')) ymax = float(box.findtext('ymax')) # 裁剪越界坐标，防止归一化后出现 >1 或 <0 xmin = max(0, min(xmin, W)) ymin = max(0, min(ymin, H)) xmax = max(0, min(xmax, W)) ymax = max(0, min(ymax, H)) if xmax <= xmin or ymax <= ymin: continue cx = (xmin + xmax) / 2 / W cy = (ymin + ymax) / 2 / H w = (xmax - xmin) / W h = (ymax - ymin) / H cls_id = classes.index(name) lines.append(f"{cls_id} {cx:.6f} {cy:.6f} {w:.6f} {h:.6f}") base = os.path.splitext(os.path.basename(xml_path))[0] with open(os.path.join(target_dir, base + '.txt'), 'w') as f: f.write('\n'.join(lines) + '\n') return filename, len(lines) label_dir = 'labels' os.makedirs(label_dir, exist_ok=True) xml_dir = 'Annotations' for xml_file in sorted(os.listdir(xml_dir)): if not xml_file.endswith('.xml'): continue fname, count = xml_to_yolo(os.path.join(xml_dir, xml_file), label_dir) print(f'{fname}: {count} object(s)')

这段脚本的核心是 xml_to_yolo 函数：先读 XML 里的 filename 和图像尺寸 W/H，然后遍历所有 object，对每个 bndbox 做坐标裁剪，再换算成归一化的中心点和宽高，最后写入与图片同名的 txt。classes 列表就是类名映射表，单类印章只有 seal，它的 class_id 是 0。中间四个 clip 操作负责把越界坐标拉回图像范围内，避免生成异常标注。difficult == '1' 的样本直接跳过，如果不想剔除，注释掉这两行即可。最后打印每个文件的目标数量，用来核对是否有文件漏转。

跑完脚本会看到类似「seal_001: 1 object(s)」「seal_014: 2 object(s)」的输出。假如某张图明显有两个章但打印出来只有 1 个，那就是标注时漏了或 difficult 被标记了，回 LabelImg 核对。转换脚本本身的正确性，建议先用两张图人工验算后再批量跑，我在第一次用这类脚本时就吃过「宽度当高度除」的亏，单个框的误差肉眼很难看出来，但模型训练时框的位置全偏了。

4.2 边界坑一：越界框必须裁剪，不能直接归一化

第一个血泪经验是标注时手滑把框拉出图像边界。LabelImg 里如果图像边缘有印章，拖框时很容易把 xmax 拖到超过图片宽度，保存到 XML 里的就是越界值。直接拿去做归一化，会出现 center_x 大于 1 或 width 大于 1 的异常标注，YOLO 训练时要么报错要么 loss 抖动剧烈。解决办法就是上面脚本里的四个 clip 操作。裁剪后还要再判断一次 xmax > xmin、ymax > ymin，因为整个框都在边界外时，裁剪后宽高会变成 0 或负数，这种框必须丢。

跑完转换后，用最笨也最有效的办法检查一遍：

grep -E '^[0-9] ' labels/*.txt | awk '{for(i=2;i<=NF;i++) if($i<0 || $i>1) print FILENAME": "$0}'

这条命令逐行读 labels 下所有 txt，检查第二列到第五列是否有超出 0~1 的数值，有就打印文件名和对应行。正常情况下输出为空；有输出就定位到具体哪张图的哪个目标异常，回 XML 修框或删框。这个 grep 检查花不到一分钟，但能省掉训练时排查 NaN 的几个小时。不少做目标检测的同行把坐标越界当成「训练报错再来修」的问题，等 loss 炸了再回头找数据问题，性价比极低。

4.3 边界坑二：空标注、类名顺序与文件对齐

空标注是最容易被忽略的坑。210 张图里总会有几张确实没有完整印章，比如只有半枚被遮挡得几乎看不见的骑缝章。如果一张图在 XML 里没有任何 object，转换脚本仍然会生成空的 txt——这一点在本脚本里通过始终写文件实现了。空 txt 一行都没有，但文件在，训练框架遍历 train.txt 清单时就找不到缺失文件的报错。稳妥的做法就是上面脚本那种：无论有没有目标都创建同名 txt，空文件也保留，别删。

类名顺序的坑则藏在多类别场景，但单类别也要提前养成习惯。YOLO 的 class_id 按 classes 列表的索引计算，转换脚本里 classes 的顺序必须和训练时 data.yaml 里的 names 顺序完全一致。印章只有 seal 一个类，无论放第几位都是 0；可一旦以后扩成 2 类、3 类，顺序写错就会导致类别标签错位——模型训练时看不出异常，推理时才发现 A 类预测成 B 类，这类问题最难定位。所以从一开始就把 classes 列表作为唯一真源，VOC 转 YOLO 和训练配置都引用它，别在两个文件里各写一遍。

最后是文件对齐问题：图片、XML、txt 三个文件同名，但可能在某个环节丢了一个。用第 3 章的差集脚本再跑一遍，缺文件的立即回补。标注阶段多花十分钟检查，训练阶段就能少熬几个小时的夜。这一整套「转换 + 校验」的流程，本质上是把数据质量的可信度建立起来，后续训练跑出来的任何 bad case，你都能快速判断到底是数据问题还是模型问题。

5. 用 YOLOv8 训练印章检测：配置文件、训练命令与损失曲线判断

5.1 data.yaml 怎么写：路径、类名与 train/val 目录

数据准备完毕，接下来就是把 YOLOv8 指向这份数据集。YOLOv8 的训练配置入口是 data.yaml，里面声明数据集路径、训练验证清单和类别名称。这个文件写错是新手翻车率最高的地方，尤其集中在 path 与 train、val 的拼接关系上。data.yaml 内容如下：

# seal.yaml path: D:/datasets/seal_dataset # 数据集根目录，建议绝对路径 train: ImageSets/Main/train.txt # 相对 path 的训练清单 val: ImageSets/Main/val.txt # 相对 path 的验证清单 names: 0: seal

这里 train 和 val 指向第 3 章生成的 txt 清单，每行一个不带后缀的文件名。YOLOv8 会自动把这些文件名拼上 .jpg 去 JPEGImages 里找图，再拼上 .txt 去 labels 里找标注。因此 labels 目录必须和 txt 文件名一一对应，且 labels 默认相对数据集根目录放在 labels/。很多初学者把 train 直接写成图片目录路径，框架会报 label not found，因为它在图片同目录找同名 txt 找不到——正确做法是让框架按清单取图片、按命名规则去 labels 取标注。

一个常见配置陷阱是 path 用了相对路径，而训练时工作目录不在项目根目录。在 PyCharm 里训练，默认工作目录可能是项目根目录，但如果你用系统终端、或者把项目移动了位置，相对路径就失效了。我一般直接把 path 写成绝对路径，不同机器间迁移时统一改这一个字段。names 的键从 0 开始，值必须是 seal，和转换脚本里的 classes 保持同一顺序。这文件总共就几行，写错一处，整个训练就跑偏。YOLOv5 和 YOLOv8 的 data.yaml 字段略有差异，但这份配置在 v8 下能直接跑，v5 的话把 names 改为 list 形式即可。

提示：训练前先执行 yolo detect train data=seal.yaml model=yolov8n.pt epochs=1，跑完一轮确认没有路径报错，再放开 epochs 正式训练。这个小步骤能拦截 80% 的配置问题。

5.2 训练命令与关键参数：imgsz、epochs、batch 的取舍

数据集小，模型就没必要上大号。YOLOv8 预训练权重里 n 和 s 对 210 张的印章场景足够，m/l/x 不仅训练慢，还容易在小数据上过拟合。我的实践顺序是：先用 yolov8n.pt 跑通流程，确认 loss 在降、验证集能检出框，再换 s 提高一点精度。直接上 l 在小数据集上通常不会带来精度提升，反而更容易记住训练集的背景噪声。

yolo detect train \ data=seal.yaml \ model=yolov8n.pt \ epochs=100 \ imgsz=640 \ batch=16 \ patience=20 \ device=0

最关键的是 epochs 和 patience。epochs 给 100 作为上限，patience=20 表示验证集指标连续 20 轮没有提升就自动早停。小数据集通常 30~50 轮就停，不会真跑满 100。imgsz 用 640 是 YOLOv8 的默认训练尺寸；如果原始图片分辨率普遍不高，比如 800×600 的扫描件，可以降到 512 提速，代价是检测小印章的能力变弱。batch 由显存决定，16 是 6~8G 显存的安全值，显存不够就降到 8。device=0 指第一张 GPU，没有 GPU 就改 device=cpu，但 640 尺寸下 CPU 训练一轮要几分钟，210 张图勉强能接受，适合先验证流程。

训练启动后，终端会打印每轮的 box_loss、cls_loss、dfl_loss 和验证集 mAP。前几轮 loss 快速下降是正常的，后面变平缓也在预期内。如果 loss 一开始就乱跳或出现 nan，基本是标注数据有问题，回第 4 章的检查脚本处理，不要在超参数上瞎调。我见过有人在 loss 不降时反复调学习率和优化器，折腾两周最后发现是某一张图的标注框写反了 xmin/xmax，这类教训不值得再踩一次。

5.3 训练完看什么：从 loss 曲线到置信度阈值调整

训练结束后，runs/detect/trainN/ 目录下会留下结果文件。先看 results.png，这张图把训练集和验证集的 loss、precision、recall、mAP50 都画在一起。小数据集的判断顺序：验证集 box_loss 是否持续下降、有没有在某个点反弹；mAP50 在第几轮见顶；如果训练 loss 一直走低而验证 loss 反弹，说明过拟合，回退到模型效果最好的那轮权重。YOLOv8 默认保存 best.pt 和 last.pt 两个权重，best.pt 按验证集指标自动选最优，直接用它做推理。

推理验证不要只看 mAP 数字，要直接拿几张没参与训练的真实扫描件测。命令如下：

yolo detect predict \ model=runs/detect/train/weights/best.pt \ source=test_pages/ \ conf=0.25 \ save=True

source 指向放测试图片的目录，conf 控制检测框的置信度阈值。印章红章在浅色背景上对比明显，conf 设 0.25 通常合适；如果画面里章的颜色很淡或背景杂乱，漏检多就把 conf 降到 0.1 先看输出，再根据可视化结果逐步调回。预测输出图会画出预测框和置信度数值，这一步的目的是人眼确认：框的位置和大小是否符合第 3 章的标注习惯。模型学到的特征就是标注习惯的投影——你框得松，它预测得松；你漏标半枚章，它大概率也漏。可视化检查是数据质量闭环里最容易被跳过、也最能说明问题的一环。

6. 印章检测数据集复现路上的常见问题与排查

6.1 训练时 loss 出现 NaN，第一反应查标注而不是调学习率

现象：训练跑到第几轮后 box_loss 变成 nan，终端报错或后续轮次全是 nan。很多人的第一反应是调小学习率，重训两三个小时后发现白跑。

原因：绝大多数情况下是标注坐标出了问题——越界值没裁剪干净，归一化后的 width 或 height 出现 0 甚至负数，模型在前向时对数值取 log 或开方就崩了。也有小概率是图像本身损坏，JPEG 解码出来的数据异常。训练框架的报错堆栈一般会指明崩在哪张图、哪个 batch，顺着索引去查就能定位。

解决：先用第 4 章的 grep 命令检查 labels 目录里有没有超出 0~1 的数值，再逐个打开报错对应的原始图片看能否正常解码。两者都正常才考虑调学习率。这条排查顺序是很多从 CV 大赛里出来的老手也容易犯的错——模型黑匣子一坏，第一反应总是调参，实际上小数据集上 80% 的 loss 异常源头在标注，不在超参。

6.2 训练完 mAP 很高，换批图片却一个印章都测不出来

现象：验证集 mAP50 有 0.7 甚至更高，但换一批新的扫描件做推理，一张图一个框都没有输出。

原因：过拟合加数据分布偏差。210 张图如果全部来自同一台扫描仪、同一批文档，模型学到的是「这种扫描参数下的印章」的特征；换一批不同亮度、不同背景色的图，特征就不匹配了。此外，训练集和验证集划分不当，比如同一份文档的两页分别进了两个集合，mAP 会虚高，推理表现自然失真。

解决：划分时按文档来源而非按图片文件切。210 张来自 30 份合同，就先按文档分组再抽样，保证训练和验证的图像来源不重叠。其次做数据增强，YOLOv8 默认开启的 mosaic 和 HSV 扰动对小样本数据集非常关键，如果你关掉了增强来「追求真实」，小数据集过拟合会来得更快。最后一步是补数据——推理失败的图收集起来，人工标注后加进训练集，这是迭代型项目真实的成长路径。

6.3 转换后 txt 里出现大于 1 的坐标

现象：运行完第 4 章的转换脚本，用 grep 抽查发现某些行的 width 或 center 值大于 1。

原因：原始 XML 的 bndbox 越界，而转换脚本里没有写裁剪逻辑。另一个隐蔽原因是 XML 里的 width 字段被误写成 0，除以 0 得到无穷大或异常大值。前者常见，后者在手工修改 XML 时容易引入。

解决：转换脚本里强制加 clip 操作，这是必须步骤不是可选优化。同时打印每张图的 size 字段，检查有没有 width 或 height 等于 0 的异常 XML。标注工具输出的 XML 很少出现这个问题，但批量重命名、脚本批量修改过后，各种意外都有可能。转完跑一遍 grep 已经是成本最低的保险了，别省。

6.4 PyCharm 里训练报错：找不到图片或找不到 label

现象：在 PyCharm 的终端里执行 yolo detect train，报错类似 image not found 或 label not found，但在系统终端里同样的命令却正常。

原因：data.yaml 里的 path 写的是相对路径，而 PyCharm 的默认工作目录不是项目根目录，路径拼接后指向了错误位置。PyCharm 的 Run Configuration 有自己的 Working directory 设置，不会自动跟随项目根目录。

解决：在 PyCharm 的 Run Configuration 里把 Working directory 改成数据集项目根目录，或者干脆把 data.yaml 里的 path 改成绝对路径。Windows 下还要注意路径分隔符：YAML 解析反斜杠转义时会出幺蛾子，D:\datasets 要写成 D:/datasets。这套配置问题在 PyCharm 里跑 YOLO 日常见不鲜，本质是「编辑器环境变量 + 框架路径拼接」双重不确定性的叠加，绝对路径能一次消除两个变量。

6.5 val 清单里的图片训练时也被用了，评估指标虚高

现象：训练日志显示训练集和验证集的 loss 几乎同步下降，mAP 高得离谱，但推理表现差了一大截。

原因：第 3 章的随机划分在文件层面是随机的，但如果原始图片有连拍或重复扫描，同一印章的相似图像可能被分到两个集合；也可能 train.txt 和 val.txt 生成时文件名有重叠。小数据集上同源图像泄漏会让评估指标完全失真。

解决：用 Python set 检查两个清单的交集，为空才说明划分干净：

with open('ImageSets/Main/train.txt') as f: train_set = set(f.read().split()) with open('ImageSets/Main/val.txt') as f: val_set = set(f.read().split()) overlap = train_set & val_set print(f'重叠文件数: {len(overlap)}') if overlap: print('\n'.join(sorted(overlap)))

这段脚本读取两个清单并求交集，重叠文件数为 0 才是干净划分。如果发现重叠，回到第 3 章按文档来源重新切分。小数据集上的评估本身有运气成分，单次 mAP 的涨跌不要过度解读——把训练集和验证集的数据分布搞干净，比纠结 0.03 的指标差更有意义。

7. 把 210 张的极限逼出来：数据增强、验证脚本与部署前的最后一公里

7.1 数据增强：对小数据集最有效的三个变换

210 张图数量有限，但 YOLOv8 默认开启的数据增强能把它等效放大好几倍。mosaic 拼图让小图里的印章上下文的干扰更丰富；HSV 色域扰动则直击印章检测的软肋——公章可能偏正红、偏橘红或偏暗红，让模型别死记颜色值，去学色块形状。我自己的习惯是从不关默认增强，除非你要做严格的消融实验。

7.2 验证脚本：随机抽样画框对比

训练前把 VOC 和 YOLO 两套标注画到同一张图上对比，确认转换后框没跑偏。核心逻辑是在图片上读取同名 XML 的 bndbox 和同名 txt 的归一化坐标，分别画两个颜色的框，人眼对比重叠度。这个小脚本 20 行就能写完，但它能在一分钟内暴露转换脚本的所有 bug——框不重合、偏移半个身位，一眼就能看出来。我的习惯是每次改完转换逻辑都跑一遍它，再进训练，绝不拿训练时长去赌转换正确。

7.3 导出 ONNX 时的注意点

如果要把模型部署到服务，需要把 best.pt 导出为 ONNX：

yolo export model=runs/detect/train/weights/best.pt format=onnx imgsz=640

导出时 imgsz 要和训练时保持一致，否则部署端图片缩放的尺寸和训练分布对不上，精度会打折扣。这一步没必要在训练初期做，等模型效果稳定后再动。我吃过一次亏：训练用 640 导出用 480，线上推理的框整体偏小了一圈，查了半天才发现是尺寸不一致。导出后建议用 onnxruntime 跑一次推理，对比 PyTorch 输出的框坐标，数值差在 1e-3 以内才算导出干净。整个小数据集项目的最后一公里，就是把验证脚本固定成习惯，每次改动数据或代码都先跑一遍再说。希望这份从标注到部署的路径能帮到你。

本文还有配套的精品资源，点击获取