RetinaNet stride 与小目标

1. 小目标在 stride-32 上只剩几个 pixel

仓库 AGV 检测二十乘二十 pixel 的托盘角点，换 ResNet101 后 mAP 几乎不动——问题不在 backbone 容量，而在最深层 stride-32 特征图上目标只剩不到一个 activation。感受野够大反而把邻域上下文混进来，小目标信号被背景淹没。先看 FPN 层级分配和输入分辨率，不是盲目换更大模型。

2. 感受野怎么累积

stacked conv 的有效感受野（RF）随 kernel $k$ 、stride $s$ 、padding 累积。粗略递推： $rf \leftarrow rf + (k - 1) \times jump$ ， $jump \leftarrow jump \times s$ 。深网络 RF 可达 input 大半，但小目标需要的是 spatial resolution，不是更大的 RF。

python

rf, jump = 1, 1
for k, s in [(7, 2), (3, 2), (3, 1), (3, 1)]:
    rf += (k - 1) * jump
    jump *= s

FPN 融合 P2–P5 让浅层高分辨率层参与预测；anchor 或 center 应分配到 stride 4/8 的层，而不是全堆在 stride 32。

3. 小目标检测的工程选项

提高 input resolution 是最直接手段——算力换 recall。多尺度训练（random resize）让模型见过不同尺度。专门的小目标层：在 P2 甚至 P1 上接 head；Tiled inference 对大图切片再 NMS 合并。

别只调 anchor size——anchor 落在 stride 过大的层上，匹配到的 positive 样本质量差，梯度信号弱。COCO small/medium/large AP 分开报，小目标 slice 不涨时查 stride 分配而非 backbone。

4. 与 backbone 选择的取舍

轻量 backbone 加高分辨率 input 有时优于重型 backbone 加低分辨率——latency 和显存也更好。Swin、ConvNeXt 等 hierarchical backbone 的 stage stride 设计不同，换 backbone 时重新算各层 output size 和 RF。

分割里小目标类似：deep supervision 在浅层、上采样路径保留高分辨率 skip，比单纯加深 encoder 更有效。

5. 案例：换 backbone 无效

某项目小目标 AP 长期个位数，连换三个 backbone 无改善——后来在 P2 加 head 并提高输入分辨率，small AP 翻倍。诊断时应先画各层特征图上的框占格数，再决定改结构还是改数据。

6. 验收

小目标 AP 单独报，不只看 overall mAP。
各 FPN 层 output size 与 anchor/center 分配一致。
提高 resolution 或加 P2 head 后 small AP 有改善。
换 backbone 后重新验证 stride 与 RF。
延迟与输入尺寸在 SLA 内。

7. 落地与衔接

小目标检测立项时先计算各特征金字塔层上目标占格数，再决定提高输入分辨率还是增加浅层检测头，而不是先换更大骨干网络。训练配置里固定输入尺寸、锚框分配与多尺度策略，并在小目标平均精度上单独设发版门槛。推理侧若延迟紧张，优先切片推理或浅层头，再考虑量化压缩。与标注团队对齐最小可检像素，避免数据侧目标过小而结构侧无法表达。结构改动前先输出占格热力图，把诊断脚本纳入合并前检查。

8. 案例复盘

某仓储自动导引车项目连换三个骨干网络，小目标平均精度仍是个位数。后来在步长八层加检测头并将输入从六百四提到九百六，小目标指标从四涨到十一。复盘发现此前锚框全堆在最深层，正样本梯度极弱。诊断脚本现在强制输出各层框占格热力图，结构改动前先过这一关，避免再花两周空跑大模型。该经验已写进检测项目启动清单，新人不再默认「换大模型就能救小目标」。

感受野决定「看多远」，resolution 决定「看多细」。小目标检测瓶颈常在后者——FPN 浅层和 input size 比 backbone 参数量更优先。把 small AP 与 latency 写进发版 checklist，结构、数据、推理三侧对齐后再动 backbone，比单点换模型更可控。上线后按场景切片复评小目标召回，防止总指标上涨却漏检关键目标。