关于论文汇报指标的公平性

[xiuqhou]

作者你好，在测试代码后我对论文的指标有些疑惑，希望您可以解答：

1. RT-DETR和其他DETR（DINO、DeformableDETR等）使用的数据增强方式不一样，除了常规的crop和resize，还包括RandomPhotometricDistort、RandomZoomOut，另外使用的backbone是PResNet而不是其他DETR使用的ResNet，这样对比的指标是否公平？
2. 从代码中可以看到，RT-DETR是在DINO的基础上仅对最后一层feature map进行单层Encoder编码，并在Encoder后增加了PANet，Decoder则基本没变，FLOPs减少一半，为什么推理速度会快20倍？我在3090上测试DINO和RT-DETR的FLOPs和FPS，RT-DETR的FLOPs比DINO少约50%（和论文一致），但推理速度只加快2倍（和论文差很多），具体来说是DINO比论文汇报的（5FPS）要快、RT-DETR比论文汇报的（108FPS）慢很多，3090和T4的硬件差异应该不足以对推理速度影响这么大，能不能解释一下原因或给出你们测试推理速度的细节？
3. RT-DETR是将图片都裁剪为640*640输入网络，从而避免了pad和valid_ratio_scale的操作。如果按照DINO的方式把pad和valid_ratio_scale部分加回来，并且将图片输入尺寸也和DINO保持一致，RT-DETR的精度会比DINO差很多，这是不是说明RT-DETR的性能是来自图片输入尺寸的设计，而不是网络本身的优越性？

[lyuwenyu]

---

1. 提到这些都是提升模型效果的策略，而且不同模型间的对比也不是在消融试验的过程中，不同模型间对比用最终的精度和速度才是最公平的；( 我想没有人会质疑yolov3和yolov5的对比是否公平

---

2. RTDETR和其他模型的对比我们在v100、t4、3090等硬件平台测试过 表现都符合预期的；至于DINO 你可以测下按照你测的速度的条件下能否达到其论文的精度 ( 换句话说 为了公平对比你应该在其论文汇报的精度条件下去测其速度；模型的表现是两个维度同时定义的 对比的话只拿其中一个是不完整的没有意义的；

Furthermore, RT-DETR-R50 outperforms DINO-R50 by 2.2% AP in accuracy and about 21 times in FPS

---

3. 下面这句不太符合常识吧；***差很多的结论个人猜测更可能是代码层面的bug ( 原始模型也是参考DINO设计的 并没有发现精度差很多的现象 去掉你提到的操作更多的是从推理速度的角度考虑的

这是不是说明RT-DETR的性能是来自图片输入尺寸的设计，而不是网络本身的优越性？

---

如果还有其他疑问 欢迎继续留言

[xiuqhou]

感谢作者回复，您说的有一定道理，不过还是存在一些疑问。

1. 数据增强确实是提升模型的策略，但数据增强不一致的情况下对比出来的模型性能是不具有说服力的，甚至相同的模型在不同的数据增强下的性能都存在差异（我可以通过堆数据增强将DINO训出远高于SOTA检测其CoDETR的结果，那你觉得能说DINO性能高于CoDETR吗？）。所以我个人觉得，不能拿 A模型+数据增强1 > C模型+数据增强2 就得到 A模型 > C模型 的结论，这会给阅读论文的人带来误导。YOLOv3和YOLOv5的论文未经过同行评审，所以对他们之间的对比不作评价。
2. 对比模型性能需要考虑精度和速度两方面，这点你说的有道理。我疑惑的正是为什么精度和论文结果差不多的情况下，速度会和论文差异这么多。按照我测的速度，DINO可以达到其论文中的精度（我只测试了1x情况）。但为什么你论文中汇报的DINO速度会比我测的慢这么多（慢了2倍），而RT-DETR的速度会比我测的快这么多（快了3倍）？您导出的DINO和RT-DETR的tensorrt engine文件，能否分享一下我亲自测试看看速度。
3. 我也觉得这不符合常识，我推测是pad会导致模型部分模块的计算结果有偏差。因为有mask和valid_ratio，attention的计算结果是一致的，而backbone在pad前后是不一致的（可能是因为3*3卷积）。我复现代码的时候也是先实现了DINO（并确保和源论文精度对齐），然后参考您的代码在DINO的基础上实现了RT-DETR，而您的改进其实很简单（单层Encoder+PANet+VFL），所以我觉得复现错误的可能性不大。后续如果有时间我会将我复现的DINO和RT-DETR放在Github上，并确保他们都使用相同数据增强、backbone，都有pad和valid_ratio操作，从而在实验条件更一致的情况下对比性能，如果您有时间可以来检查复现的bug。

[lyuwenyu]

1. 当你对原版DINO做数据增强的时候 他就不是原版DINO了(原论文的) 或许应该叫 XX-DINO 那么XX-DINO的性能就是高于CoDETR 个人认为这逻辑没有什么问题的 （ XX + DINO == XX-DINO > CoDETR 比较的是始终是XX-DINO和CoDETR；我不知道DINO和CoDETR这个比较从何而来 或者 我们文章里那块有这样类似的论述

（我可以通过堆数据增强将DINO训出远高于SOTA检测其CoDETR的结果，那你觉得能说DINO性能高于CoDETR吗？）

2. 你这句我也是认同的 不过我没理解它和上下文的case有什么关系；

所以我个人觉得，不能拿 A模型+数据增强1 > C模型+数据增强2 就得到 A模型 > C模型 的结论，这会给阅读论文的人带来误导。

3. 我还是坚持上边个人的结论

YOLOv3和YOLOv5的论文未经过同行评审，所以对他们之间的对比不作评价。

4. 你测DINO的输入SIZE的多少？还有导出的TensorRT的Input Size；RTDETR测试我们有详细说明和代码，另外社区同学能够复现我们的效果的 建议先翻阅一下issue https://github.com/lyuwenyu/RT-DETR/issues/95 或者 网络资源(百度/知乎) 看他们测出的效果 trt-fp32都不至于慢3倍吧..

但为什么你论文中汇报的DINO速度会比我测的慢这么多（慢了2倍），而RT-DETR的速度会比我测的快这么多（快了3倍）？您导出的DINO和RT-DETR的tensorrt engine文件，能否分享一下我亲自测试看看速度。

[xiuqhou]

1. 如果不同数据增强算作新模型的话，RT-DETR也应该和其他DETR在相同的数据增强下的变体来对比，例如RT-DETR vs XX-DINO，而不是RT-DETR vs DINO。
2. DINO的输入size是800*1333，纯pytorch代码的情况下对比（而不是TensorRT导出）。我疑惑的并不是RT-DETR的推理速度（你也说了社区能够复现你们的效果），而是"RT-DETR比DINO加快21倍"这个结论，至少我在pytorch实现的代码上，RT-DETR(无论是640*640还是800*1333输入)都没有达到比DINO(800*1333输入)快21倍的效果。
3. 由于DINO并没有提供TensorRT的导出脚本，所以我暂时没法对比TensorRT情况下两者的速度差异，如果你有导出好的DINO和RT-DETR的TensorRT engine，可以分享一下不？

[lyuwenyu]

1. 我们首先是要和其他模型对比最终效果的 学术界有DINO 而并不存在XX-DINO；另外 这里不同模型间的对比 不是控制变量下某个消融试验验证某个模块的叙事；

例如RT-DETR vs XX-DINO，而不是RT-DETR vs DINO。

2. 这. 测速对不上这也是原因啊 ( 至于能不能对比-见1 , 测试条件-见3

我疑惑的并不是RT-DETR的推理速度（你也说了社区能够复现你们的效果）

而是"RT-DETR比DINO加快21倍"这个结论

但为什么你论文中汇报的DINO速度会比我测的慢这么多（慢了2倍），而RT-DETR的速度会比我测的快这么多（快了3倍）

但推理速度只加快2倍（和论文差很多），具体来说是DINO比论文汇报的（5FPS）要快、RT-DETR比论文汇报的（108FPS）慢很多

3. 文章里所有对比的速度数据都在在T4 TensorRT FP16下测的，论文里是有说明的

DINO的输入size是800*1333，纯pytorch代码的情况下对比（而不是TensorRT导出）

至少我在pytorch实现的代码上，RT-DETR(无论是640640还是8001333输入)都没有达到比DINO(800*1333输入)快21倍的效果。

4. 解释同3

由于DINO并没有提供TensorRT的导出脚本，所以我暂时没法对比TensorRT情况下两者的速度差异

5. 在不同硬件和软件环境下TensortRT优化的结果会有Diff的 为了避免误用和不必要的质疑 我们不会提供trt-engine文件； 建议在自己的环境下导出测试 参考资料见下

如果你有导出好的DINO和RT-DETR的TensorRT engine，可以分享一下不？

---

导出参考rtdetr文档 ( ppdet里不同模型导出onnx和tensorrt的流程基本都是一样的

• https://github.com/PaddlePaddle/PaddleDetection/tree/release/2.7/configs/dino
• https://github.com/PaddlePaddle/PaddleDetection/tree/release/2.7/configs/rtdetr
• https://docs.nvidia.com/deeplearning/tensorrt/quick-start-guide/index.html

[xiuqhou]

1. 我觉得论文不是比赛打榜，不是用tricks把精度堆地越高越好，论文的对比实验是需要(尽可能)控制变量的，像Backbone、data augmentation、epoch等，而RT-DETR在这三点上都没有和对比的其他DETR方法对齐（PResNet50 vs ResNet50，数据增强不同，用6x对比DINO的3x）。如果像你说的那样，只需要对比模型的最终结果，那为什么以50.9的精度作为DINO的最终结果参与对比，而不是DINO原始论文中汇报的63.1的结果？
2. 谢谢你给出的TensorRT相关的参考资料，我之前都没有注意到ppdet有开源DINO和RT-DETR的模型(支持一波~)，后续有时间我会在T4 GPU去导出TensorRT并实际测试DINO和RT-DETR的推理速度，看一看我自己的测试结果能否和论文对齐，并根据结果来留言issue。

[lyuwenyu]

---

1. 首先我们模型的出发点、创新点、试验、和分析文章里写的很清晰 <也得到了同行的专业review>；至于写作思路和风格我觉得是求同存异

论文的对比实验是需要(尽可能)控制变量的，像Backbone、data augmentation、epoch等，而RT-DETR在这三点上都没有和对比的其他DETR方法对齐（PResNet50 vs ResNet50，数据增强不同，用6x对比DINO的3x）

2. 具体参考上面block里的1；（我们这里是在做模型效果对比 不是消融试验

论文的对比实验是需要(尽可能)控制变量的，像Backbone、data augmentation、epoch等

3. 具体参考上面block里的1 ；（我也没说过这样的原话吧 看定语

如果像你说的那样，只需要对比模型的最终结果，

4. 首先实时检测模型一般分s m l x系列，没见过l和x比的；再者文章写的很清楚是和DINO-R50比 不是DINO；另外 也可以和63.1的模型比啊 比如我s模型和63.1的模型比 可以得到精度低几十个点 速度快几百倍的结论 没什么问题 但是这样的结论对读者来说有什么意义呢

如果像你说的那样，只需要对比模型的最终结果，那为什么以50.9的精度作为DINO的最终结果参与对比，而不是DINO原始论文中汇报的63.1的结果？

5. 你这句话有点歪楼了哈 几天都聊不完

   就零零碎碎回复几句：
   - 什么叫`tricks`？必须得用了什么高深理论、复杂网络、晦涩语言才能站到鄙视链顶端？
   - 什么是好(论文)？AI领域落不了地束之高阁的肯定不是；反之`yolov3`的写作丝毫不影响它的价值，`28061`的引用还需要什么`专业同行`质评嘛
   - 整体精度都做不起来，怎么证明优越性？`SOTA`这词价值何在？不成了自娱自乐了嘛
   - 论文和比赛打榜并不对立，反例太多了，不然各大学术会干嘛还举办比赛？个人认为 能取得top指标的肯定有其的高明之处 反而能写出论文的idea可能只是文笔好
   - 再看看现在LLM、MM-LLM领域的论文，大量用`所谓的tricks`把最终精度堆地越高就是越好，就是同行认可的好文章
   - 当然最终时间会用<引用量 开发者喜欢度 以及 带来的社会价值>来judge什么是好
   - ...
   - 求同存异

我觉得论文不是比赛打榜，不是用tricks把精度堆地越高越好，

[xiuqhou]

好的，非常抱歉浪费了你很多时间，我就不继续往下issue了，最后也只碎碎念几句。

1. 我首先想解释一下，我开的issue的初衷是交流探讨，而不是对工作价值有质疑。
2. 相反，RT-DETR启发了我今年CVPR的论文，其中就follow你和YOLO中使用的VFL损失和PANet。我的主要创新点和RT-DETR筛选特征图进行Encoder的思想也有些关联，所以我对RT-DETR工作的价值是很认同的。
3. 因为论文无法涵盖所有细节，才过来开issue探讨复现代码中存在的疑惑。我有反复阅读过你们paddlepaddle和pytorch版本的代码，如果你在我仓库中搜索RT-DETR，还可以找到我当时对你们paddle和pytorch版本差异的注释。
4. 我并不对tricks有鄙视，简单有效的方法更有影响力。我也借鉴了你们代码中的某些trick，比如你们代码推理时会缓存2d_sincos_position_embedding避免重复计算，我在我的PositionEmbeddingSine有类似的借鉴（我使用functools.lru_cache缓存的dim_t和dim_t，因为我的推理尺寸不是固定的640*640）。
5. 正是你们论文的精度和速度看起来太有吸引力了，我才想探究是什么改进带来了如此大的提升。经过从DINO逐步引入你们的改进后，我发现可能和pad、数据增强也有一定关系，这个反常的现象我原本想在CVPR poster环节当面交流的，但似乎你们没来现场，所以才来这里开issue。
6. issue交流的过程能看出你对论文写作和领域发展的某些思考，蛮有启发的。也许你比较侧重落地应用而我目前更偏向于研究，所以对论文写作方式的看法不同，求同存异~

[lyuwenyu]

是这样的 我们这边还是偏落地方向考虑多点；你这细节都比较严谨 挺好的

( 文字交流难免有个别不流畅的地方 没有别的意思 有机会当面交流