来源：多模态视觉

原文链接：https://mp\.weixin\.qq\.com/s/9DDw5LZTBdYIR64l0lM2Bg

在遥感、无人机和港口画面里，目标大多是斜着的，水平检测框会框进一大堆背景，旋转框又因为角度周期性而难训、难收敛。中科大联合华为、清华提出的 RiO-DETR 把端到端旋转 DETR 第一次推进实时区间——最轻量模型只有 4.0M 参数、T4 上端到端延迟 2.7ms、DOTA 上 78.4 AP50，已被 ECCV 2026 接收为 Oral。这篇文章拆解它对应的三个底层设计，也说说开源代码那个容易被忽略的限制。

旋转框难的，从来不是"多一个角度"

你打开一张卫星图。码头停着的船、跑道上的飞机、跨海大桥，没一个是横平竖直的。

用水平框去框？框得住，但半个框是海水和地面，背景噪声全裹进来了。换旋转框（Oriented Bounding Box，OBB）吧，框得紧，可代价是检测器要多猜一个角度——而这个角度，是整类任务里最让人头疼的变量。

过去想把旋转检测做快，基本是 CNN 的天下，YOLO、RTMDet 这一档。DETR 路线看着香：端到端、连 NMS 后处理都省了。可一旦把水平框换成旋转框，笨重的注意力、角度的周期性歧义、再加上膨胀的匹配搜索空间，实时性基本就没了。论文表格里前代旋转 DETR——RHINO、Oriented-DETR 这一票——延迟普遍落在 30 到 90 毫秒，跟"实时"俩字不沾边。

2026 年 3 月挂在 arXiv 上的这篇 RiO-DETR，想解决的就是这件事。它据作者所知，是第一个把旋转检测 Transformer 真正跑进实时区间的工作，论文已被 ECCV 2026 接收为 Oral（Spotlight）。一作胡张驰是中科大博士生，也是当前检测领先模型 D-FINE 的重要贡献者；合作者来自华为、清华和合肥综合性国家科学中心人工智能研究院。

数字先摆出来。在 DOTA-1.0 单尺度设置下：

从 2.7ms 到 29.9ms，五个型号整整齐齐落在实时区间里，速度和同档 YOLO26-obb 基本同量级。

但比数字更值得看的是它的切入方式。它不是简单在 RT-DETR 屁股上接一个角度回归头。作者回过头问了个更根本的问题：角度，到底是个普通坐标，还是一个由图像内容决定、又活在圆周上的变量？

这个问题拆开来，是三个绕不开的麻烦。

第一个，语义和几何是拧着的。中心坐标和宽高回答的是"目标在哪、多大"，靠几何关系就能定；角度回答的是"目标朝哪"，你得看船头方向、机翼纹理、车辆的首尾布局。把角度和坐标一起塞进位置查询，等于让几何先验去干涉一个本该看内容的判断。

第二个，角度不在数轴上，在一个圆上。真实朝向接近 180 度、模型预测接近 0 度——两个框几乎重合，可 L1 损失会判它俩差了整整 180 度，然后推着模型绕最远的路去修正。越修越抖。

第三个，搜索空间被撑大了。多说一句免得误会：这个"搜索"只发生在训练阶段每轮的二分图匹配里——把预测框和标注框一一配对，多一个角度维度候选就更多；推理时角度是网络一次前向直接回归出来的，并不枚举、也不反复试角度（那是更早 RRPN 一类多角度锚框的老办法）。真正的麻烦在于，要是一张图里的船全都头朝一个方向，角度分支能拿到的监督信号稀得可怜，收敛自然慢。

RiO-DETR 的三个核心设计，正好一对一对应这三件事。

角度要"看内容"，别把它写死在位置里

大部分旋转 DETR 会把中心点、宽、高、角度这五个值一起塞进位置查询。这个做法默认了一个前提：这几样是同类几何信息。

作者不这么看。位置查询只留中心坐标和宽高，角度被单独拎出来，交给一个独立的内容查询（Content Query），让它依托图像特征自己去"看"出朝向。这就是内容驱动角度估计（Content-Driven Angle Estimation）。位置管几何，内容管朝向，两不干扰。

论文在 DIOR-R 上做了组消融，结论挺反直觉：只编码中心坐标时 AP50 是 72.56，把角度也塞进位置编码反而掉到 72.34；而只编码中心和尺寸、彻底不编码角度，能升到 73.81。往查询里塞更多几何参数并不总是好事，关键是让角度从对的线索里长出来。

光把角度分出来还不够。旋转目标既有长轴也有短边，如果所有注意力头都顺着目标主轴采样，模型会一个劲盯长度，把宽度方向的边缘特征漏掉。于是有了第二招——旋转校正正交注意力（Rotation-Rectified Orthogonal Attention）：把注意力头对半分，一半沿预测角度 θ 采样，另一半沿垂直的 θ+π/2 采样。

图片来源：论文 Figure 2

一个 4:4 的均衡划分，不引入额外参数，也不增加 FLOPs，AP50 从 73.81 提到 74.18。下面这张采样点可视化更直观——两组点没有糊在目标中心，而是分别沿着船身的长边和侧边铺开，桥、跑道这种长宽比悬殊的目标尤其吃这个机制。

图片来源：论文 Figure 4

顺带说一句，RiO-DETR 的底座是 RT-DETRv2，又引入了 D-FINE 的通用匹配策略和 DEIM 的 Dense O2O 训练范式。它不是从零另起炉灶，而是在一个已经很强的实时 DETR 基线上，专门为旋转几何动刀。

角度活在圆上，更新就得走"最短路"

第二个麻烦是周期边界。这个问题用时钟打比方最清楚：23 点 59 分和 0 点 01 分，在数字上隔着近 24 小时，物理上只差两分钟。普通 L1 损失就是那个"按数字算距离"的笨办法，在 0/180 度这条接缝上，它会给模型指一条完全错误的路。

更麻烦的是 DETR 的解码器是一层一层迭代细化的，不是一锤子买卖。浅层一个小小的角度偏差，会在后面逐层被放大，几层兜下来整张旋转框都在抖。

所以作者没有只在最终损失上打补丁，而是把每一层的角度更新逻辑都重写了，叫解耦周期细化（Decoupled Periodic Refinement），分三步：

光用周期更新、或者光用最短路径损失都不稳，两个配合起来，AP50 从 74.18 提到 74.74。本质上是让角度的细化过程，终于和旋转几何本身对齐了——而不是让几何去迁就一个为直线设计的优化器。

让一张训练图同时出现四种朝向

第三个麻烦是收敛慢。水平检测只需匹配位置和尺度，旋转检测还要遍历朝向，候选空间一下子大了不少。DEIM 的 Dense O2O 本来是把四张图拼成一张大图来增加单批次目标数，可作者发现，对旋转检测来说，光增加目标数量是不够的——你得让模型在同一批里看到足够多样的朝向。

于是他们改成了 Oriented Dense O2O：拼接之前，四张子图各自独立从 0°、90°、180°、270° 里随机抽一个角度转一遍，再拼成一张高密度图。这样不增加推理开销，训练计算量几乎不变，却硬把角度多样性灌进了每一个批次。

效果在收敛速度上很直白。第一阶段训练达到最优 AP50：

Oriented Dense O2O：60 个

收敛快不快，不取决于你无差别地堆多少旋转变换，而在于你有没有把角度多样性真正融进一对一的密集监督里。

图片来源：论文 Figure 3

从 2.7ms 到 29.9ms，整条模型族都在实时区间

三个设计合在一起，结果落在三大基准上：DOTA-1.0、DIOR-R、FAIR1M-2.0。所有延迟都在单张 NVIDIA T4、TensorRT 10、FP16 下统一测得。有个口径得交代清楚：论文里 RiO-DETR 自己的端到端延迟不含图像预处理和后处理，对比模型则通过 BatchedNMSPlugin 统计了含 NMS 的工程延迟——这个差异要知道，但同档位的速度量级是对得上的。

图片来源：论文 Figure 1

主性能表能看出它的位置。在 DOTA-1.0 单尺度下，RiO-DETR-x 的 81.8 AP50 高于相近延迟的 YOLO26x-obb（80.4，30.5ms），也高于更慢的 RHINO-DETR（79.4，57.0ms）。轻量端 n 用 2.7ms 拿到 78.4。DIOR-R 上，x 在 17.31ms 跑到 77.43，略快于且高于 YOLO26x-obb 的 76.48、17.66ms；百万级实例的 FAIR1M-2.0 上，x 多尺度达到 47.4 AP50。

图片来源：论文 Table 1

最让我在意的是消融链路。作者先搭了个 73.47 AP50 的强基线，加入几何解耦查询到 74.18，再加正交注意力到 74.74，叠上周期细化和 Oriented Dense O2O 推到 75.73。整个过程中参数量、FLOPs 和延迟几乎没变。

这点很关键。它说明这些增益不是靠换更大骨干、堆更多算力换来的，而是靠重新设计角度怎么表示、怎么更新、怎么被监督——用更对的归纳偏置，而不是更多的电。

比起刷点，我倒觉得这篇最有迁移价值的是"把任务的几何约束写进注意力和损失"这个思路——它不只属于旋转检测。

不过，论文数字之外，有件事必须单独说。我去翻了官方 GitHub 仓库，作者在 README 里写得很坦诚：由于合作机构的知识产权限制，包含论文具体技术改进的那部分代码无法公开；目前放出的是一个基于 RT-DETRv2 重新整理的干净基线 RT-DETR-OBB 和部分预训练权重，和论文里完整的 RiO-DETR 之间存在性能差距。比如仓库里 DOTA 单尺度的基线，X 档是 80.63 AP50，而论文里的 RiO-DETR-x 是 81.8。作者同时透露不受 IP 限制的 RiO-DETRv2 已经在做了。

这不是要泼冷水。Apache-2.0 的仓库、训练日志、评估报告都放出来了，基线本身也能打。但如果你打算这周就 clone 下来复现 81.8，得知道自己拿到的是起点，不是终点。对做工程的人来说，这种事提前讲清楚，比事后对着数字对不上强。

回到开头那张卫星图。斜着的船、斜着的桥、斜着的跑道。旋转检测真正想要的，是让模型既看得准框得紧，又能在有限的时延预算里一直跑下去。RiO-DETR 给出的答案是：别把角度当成水平框后面多出来的一列数值，它是另一套语义和几何——把它的来源、它在圆上的结构、它该被怎么监督，挨个理顺了，端到端和实时，才不再是一道二选一的题。

至于你手里那张斜着的图，下一次也许就能在 3 毫秒内被框住了。

原文链接: https://www.leiphone.com/category/private/2OYuzJe6YdRomlh2.html