种鸡 / 家禽智能监测从公开数据集到自己的检测实现

02+数据的种类、分类与清洗：我对 PIO 做的一次完整体检本人实测

① 数据有哪些种类

② 我的分组统计：数据不是均匀的

• 密度随周龄下降：商业鸡舍第 1 周每图约 502 只，第 6 周约 131 只。雏鸡小而挤，是最难的场景。
• 两种鸡舍差距大：商业鸡舍每图密度是原型鸡舍的 3–6 倍，适合分开报告指标。
• C-W5 严重偏少：只有 14 + 3 张，这一组的验证结果基本没有统计意义。

③ 我的清洗检查结果

这意味着什么：约 13% 的验证图模型在训练时已经「见过答案」，所以上文 1/3/5 轮以及 25 组基准的验证指标可能偏高。下一步：先去重、统一重复图的标注，再按「同一段视频/同一时间段整体归到同一边」重新划分，然后重跑 5 轮，对比去重前后的 mAP 差多少。

03+术语与工具：这些名词和脚本是什么、怎么用本人实测

上面几节里出现了不少专有名词和脚本名字，这里统一摊开讲清楚——既是给自己留的备忘，也是「我的什么能给别人用」的具体清单。

① 数据集里的术语

② 用到的工具，各自是干嘛的

③ 怎么上手：从零到跑出一次训练

# 建一个干净的环境（Anaconda Prompt 里执行）
conda create -n poultry python=3.10 -y
conda activate poultry

# 装训练依赖（RTX 50 系显卡必须用 cu128，其他显卡按官网选对应版本）
pip install torch torchvision --index-url https://download.pytorch.org/whl/cu128
pip install ultralytics

# 先体检数据集，确认标签没问题、没有泄漏，再训练
python check_dataset.py
python data_audit.py

# 改 train.py 顶部的 EPOCHS / BATCH / MODEL 这几行开关，然后直接运行
python train.py

完整的 PyCharm + Anaconda 保姆级教程（每一步截图、常见报错速查表、Conda 环境踩坑记录）在 种鸡智能监测 第 07–08 节，这里只摘环境搭建和常用命令。

05训练中的三个关键发现本人实测

① batch 受标注密度制约，不只看显存

RTX 5070 Ti（16 GB）上 batch=16 占用 11.5 GB 正常；batch=64 撑到 17.6 GB 崩溃。报错是具有欺骗性的 SystemError: cvtColor，顺异常链挖到底是 numpy 的 ArrayMemoryError。根子在单图平均 220、最高 1,151 个框。

② max_det 默认值会截断召回

框架警告「Dataset images contain up to 594 objects (val=594), but max_det=300」。把 max_det 从 300 改到 600，避免召回被人为压低。

③ 读 best.pt 实测出的结构细节

参数量 2.57M，步长 8/16/32，候选点 8400。reg_max=1：results.csv 表头是 l1_loss 而非 dfl_loss——源码中 use_dfl = reg_max > 1，DFL 分支被移除。还有 E2ELoss 与 one2many + one2one 双检测头，权重按轮数从 0.8:0.2 线性衰减到 0.1:0.9，标签分配用 TaskAlignedAssigner。

06复现流程与记录：我自己训练的数据本人实测

以下均为本机实测：J:\poultry\runs\detect\exp_yolo26n_1ep-4（yolo26n，1 epoch 冒烟测试，2026-09-17），用来验证流程跑得通，不是上面 25 组、200 轮的正式结果，两者不要混着比。

raw/images/train  1,035 张      raw/labels/train  1,036 个（含 classes.txt 误算）
raw/images/val      452 张      raw/labels/val      452 个
yolo26n.pt · cuda:0 · batch=16 · imgsz=640 · max_det=600

Precision 0.5725   Recall 0.6916   mAP@50 0.6445   mAP@50-95 0.2906
单 epoch 55.9 s    box/cls/l1 loss  2.486 / 3.240 / 0.0046

1 / 3 / 5 轮短训对比本人实测

同一配置（yolo26n · batch=16 · imgsz=640 · max_det=600）只改轮数。前 5 轮 mAP@50 从 0.645 升到 0.856；首轮约 34 s（含缓存与预热），之后每轮约 18.4 s，据此估算 200 轮正式训练约 1.0 小时（不含提前停止）。

踩坑：WORKERS=4 时两次在第 1 轮中途崩溃（numpy ArrayMemoryError / cv2 Insufficient memory——是内存而不是显存不足：每个数据加载进程都在做 mosaic 拼图，框极密时很吃内存）。降到 WORKERS=2 后正常跑完，该参数不影响训练结果。数据来源：J:\poultry\runs\detect\exp_yolo26n_3ep_b16 与 exp_yolo26n_5ep_b16。

完整训练：143 轮（手动停止）本人实测

在 1/3/5 轮短训基础上，正式跑了一次长训练：yolo26n · batch=16 · imgsz=640 · max_det=600 · workers=0。mAP@50 在 30 轮左右就基本走平，143 轮时精度已很接近收敛，于是手动停止，没有跑满 200 轮。

这次真正的踩坑记录：连续崩溃 3 次，报错都是同一个 cv2.error: Insufficient memory，但每次系统还有 14–17 GB 空闲内存——不是真的内存不够，更像是本机 OpenCV 5.0.0 + Python 3.14（非常新的组合）在长时间 mosaic 拼图下偶发的分配失败，分别发生在 WORKERS=4、WORKERS=2、WORKERS=0 三种配置下，说明和 worker 数无关。解决办法不是继续调参，而是写了个自动续训脚本：崩溃后用 resume=True 从 last.pt 接着跑，最终靠这个机制把 3 次崩溃都"渡过去"，没有丢失已训练的轮数。数据来源：本机实测，J:\poultry\runs\detect\exp_yolo26n_200ep_b16（2026-09-30 ~ 10-01）。