lss-1138
commented
6 months ago 感谢您的问题，这个问题非常值得讨论。
Q1：论文中的baseline方法结果是自己复现的吗？还是从对应论文中获取的呢？ 都是从对应官方论文获取的，而非自己复现。
Q2：SegRNN用的是720长度的输入序列，为什么别的baseline不是？ 每个baseline都有自己最适合的长度，更改别的baseline的长度不一定会提升表现。我在同期工作PETformer中，是复现了所有baselines，分别用96、192、336、720的输入长度运行，然后取得最好一个作为baseline的报告结果。结果是，所有这些baselines的最佳结果，几乎跟原论文的固定长度的结果持平。
Q3：如果输入序列长度不同，对比是否公平呢？ 我个人觉得是公平的，如上所述。相反，非要固定长度来比较，才更不公平。比如有不少方法，在96的长度上去和Dlinear和PatchTST比性能。但是很明显，在96的长度下，这两个baseline的表现非常糟糕，所以这样的对比更不公平吧？ 此外，也有不少文章是在不同的输入长度下比较的，比如FITS。所以，这种比较个人认为也算是权衡之下的公平吧。
最后顺着回答几个问题吧。 Q4：那为什么SegRNN要用720的长度？ 一方面，是为了追求更好的预测表现。从落地的角度看，当前模型预测效果都不太出色，尤其是在96的短输入长度下。所以想要提升预测表现，需要保证足够的输入长度来驱使模型建模时序数据的长期依赖。输入长度720≥输出长度{96、192、336、720}是一个较为理想的设置了。 另一方面，SegRNN足够轻量，在720的长度下运行速度也很快。
Q5：那假如SegRNN要用短点的输入长度，表现如何？
比如在96的输入长度下，SegRNN仍然具有出色竞争力。比如在etth1和weather数据集中，SegRNN仍然是SOTA性能（对比iTransformer）。其他数据集您也可以自行验证下。
ownnaruto
您好，非常感谢您的工作，我有几个问题想问一下您。 论文中的baseline方法结果是您自己复现的吗？还是从对应论文中获取的呢？我看到您用的是720长度的输入序列，baseline是否有刻意控制这个输入序列的长度相同呢？如果输入序列长度不同，这样的对比是否公平呢？
谢谢！