摘要
在这款回合制战棋游戏里，战场是六边形格子棋盘，双方的“部队”（一堆同种生物，称为一个兵堆）站在格子上。要让程序看懂战局，第一步是从截图里把每个活着的兵堆框出来。本实验把这件事当成单类别目标检测：输入一整张原始分辨率的战场截图，输出若干个方框，每个方框框住一个活着的兵堆，不管它是什么兵种。
我们用同一份数据比较了四个公开检测模型的训练配方。按预先冻结的规则（验证集上的 AP 最高）选出的是 FCOS，测试 AP50:95 为 70.67%；YOLO26s 的一个配方测试精确率/召回率 96.60%/96.80%，常驻推理中位数 11.85 毫秒，AP 只略低（70.21%）。RT-DETRv2 在这里表现差很多。这些都是开发候选，没有接入生产流程。
要回答的问题
- 现成的检测模型，在本项目已审核的战场截图上微调后，能把活体兵堆框得多准？
- 不同模型在速度上差多少？
- 在“尽量少误报”的工作点上，还能保留多少召回？
数据与来源
- 数据来自上一项研究（B12）中由用户认可的助手目视审核标注：722 张已审核截图、7,651 个带身份的框。只有 619 张“穷尽标注”（画面里每个活体都被框了）且场景可用的原图、共 7,289 个框进入检测数据集；另外 103 张被排除（70 张场景不可用，33 张没有完成穷尽审核），排除原因都有记录。
- 标签是助手目视审核、用户接受的结果，不是独立的盲标基准。测试集标注时参考过旧检测器的候选框再人工修正，所以本实验做到了“按视频来源隔离”，但不是盲测。
- 整段录像不拆分，划分在训练前冻结：
| 分区 | 原图 | 活体框 | 用途 |
|---|---|---|---|
| 训练 | 401 | 4,588 | 训练 |
| 验证 | 54 | 715 | 选检查点和置信度阈值 |
| 测试 | 75 | 969 | 选择冻结后的最终评估 |
| 历史审计 | 89 | 1,017 | 旧测试来源，不参与训练和选模 |
验证集来自 9 月 5 日和 9 月 6 日的两段录像，测试集来自另外两段同期录像；它们都比上一代检测器训练时的数据新。原图尺寸有 2560×1440（491 张）、1920×1080（20 张）和 1920×1078（108 张）。
另外有 36 个零散的“非活体”区域（21 个尸体、13 个地形、1 个棋盘外英雄、1 个界面头像），只用于额外检查误检，不算完整的多类别标注。
方法
四个配方都从公开的 COCO 预训练权重开始，不使用旧的战场微调模型，同一个随机种子，最多 30 轮：
| 配方 | 输入处理 | 训练方式 |
|---|---|---|
| FCOS ResNet50-FPN | 保持长宽比，短边 800、长边上限 1333 | 冻结骨干网络和特征金字塔，只训练检测头，batch 4 |
| YOLO26s（nbs64） | 整图补边缩放成 960×960 | 全部微调，batch 8，混合精度，轻度几何增强和拼图增强 |
| YOLO26s（nbs8） | 同上 | 与上一行只差“名义 batch”这一项 |
| RT-DETRv2 R18 | 整图缩放成 640×640 | 全部微调，batch 4 |
“名义 batch”（nominal batch size, nbs）是 YOLO 框架的一个设置：默认 nbs=64 时，每攒 8 个 batch-8 的前向才更新一次参数（梯度累积）。审计训练代码时、尚未做任何测试推理之前发现了这一点，于是加了一个 nbs=8 的对照配方（每个 batch 更新一次），其他设置不变。两个 YOLO 配方都留在最终表里，但 YOLO 一族的代表仍按验证集 AP 选出。
这些配方的输入像素数、增强方式和参数各不相同，因此这是工程配方对比，不是等计算量的架构对比。
评价指标：
- AP50:95：标准 COCO 检测分数。把预测框与参考框的重叠程度（IoU，交并比）阈值从 0.50 到 0.95 逐级提高，分别算平均精度再取平均；越高表示框得越准。AP50 只要求 IoU ≥ 0.5。
- 精确率 P：程序给出的框里有多少是真的活体；召回率 R：真实活体里有多少被找到。一对一匹配，IoU ≥ 0.5 才算命中。
- 每个模型在验证集上固定两个阈值：一个让 F1 最大；另一个“精确率优先”，即在验证集精确率 ≥ 98% 的点里召回最高的那个。两个阈值都在测试前冻结。
设置
速度在同一块 RTX 5080 GPU 上测，batch 1、FP32。每个配方开 3 个独立进程，每个进程把 30 张验证原图各跑 3 遍，共 270 次“常驻”测量（模型已加载，含预处理、传输、推理和坐标后处理），直接合并原始耗时算中位数和 p95；另外单独测 90 次“解码 PNG + 检测”。测速时没有训练任务在跑。训练耗时只是开发中观测到的时间，有一段时间两个训练任务共享 GPU，不能当吞吐对比。
结果
测试集检测质量：
| 配方 | 验证 AP | 测试 AP | 测试 AP50 | F1 点测试 P / R | 精确率优先点测试 P / R |
|---|---|---|---|---|---|
| FCOS ResNet50-FPN | 74.66% | 70.67% | 96.53% | 95.39% / 93.91% | 98.96% / 78.64% |
| YOLO26s · nbs64 | 68.80% | 69.32% | 98.47% | 95.03% / 96.59% | 96.87% / 95.67% |
| YOLO26s · nbs8 | 69.19% | 70.21% | 98.69% | 96.60% / 96.80% | 97.99% / 95.77% |
| RT-DETRv2 R18 | 52.93% | 52.81% | 82.98% | 84.76% / 62.54% | 100.00% / 1.34% |
前三个配方在验证集上都能找到精确率 ≥ 98% 的阈值；RT-DETRv2 找不到，只好用它能达到的最高精确率点。
速度与训练：
| 配方 | 完成轮 / 最佳轮 | 训练秒数 | 常驻推理 中位 / p95（ms） | 解码+检测 中位 / p95（ms） | 三次进程启动到首个结果（秒） |
|---|---|---|---|---|---|
| FCOS | 19 / 9 | 768.82 | 37.83 / 44.70 | 72.67 / 79.88 | 84.875, 3.462, 2.954 |
| YOLO26s · nbs64 | 30 / 23 | 1024.12 | 13.37 / 18.85 | 51.00 / 68.05 | 9.572, 2.150, 2.031 |
| YOLO26s · nbs8 | 30 / 21 | 1257.36 | 11.85 / 15.29 | 46.34 / 56.45 | 2.396, 2.021, 1.977 |
| RT-DETRv2 R18 | 30 / 3 | 1241.38 | 18.08 / 30.50 | 52.87 / 64.06 | 23.153, 4.766, 4.566 |
按预先冻结的规则（验证集 AP 最高，测试结果不参与重选），总体选中 FCOS；YOLO 一族选中 nbs8。
尸体误检的小检查：测试集里只有 5 个被明确标注的尸体区域（来自同一段录像的两张图）。在各自 F1 阈值下，四个模型都没有在这 5 个区域上产生误检框。这只是很小的定向检查，不是“尸体误检率”。
失败与负结果
- RT-DETRv2 的“精确率优先”测试精确率 100%，实际是 13 个正确、0 个误报、956 个漏检，召回只有 1.34%，没有实用价值；它在验证集上也没达到 98% 的目标。
- FCOS 第一次进程启动花了 84.875 秒（导入与准备 30.918 秒、模型加载 48.551 秒、首张推理 5.276 秒），后两次只要 3 秒左右。原因没有查清，所以保留这个异常值，不把它归因于架构本身。
- nbs8 比 nbs64 推理略快，但 nbs 只改训练过程，不改推理结构，这两个延迟数字不能说明“梯度累积会加速推理”。
局限
- 只有一个随机种子，留出视频很少；所有图都来自同一游戏版本、相近的地图和画面风格。
- 标签是助手审核、用户接受的，不是独立盲标；测试标注参考过旧模型候选。
- 只比较“从整图里框出活体”这一步；场景判断、兵种身份识别、跨帧修正都不在本实验内。
- 训练时 YOLO 框架内部验证用的是矩形补边批次，而最终验证、测试和测速都用 960×960 正方形输入，这是公开说明的配方差异。
- 验证集达到 98% 精确率不保证测试或真实使用时也达到。
结论与下一步
在本项目数据上，FCOS 和 YOLO26s 都能把活体兵堆框得比较好（测试 AP50 约 96–99%），其中 YOLO26s（nbs8）在精度接近的同时快得多，适合需要速度的场景；RT-DETRv2 这个配方不适用。实验结果只作为开发候选，是否接入生产需要另外的验证和新的、未被查看过的测试数据。
Comments