端到端时代下的自动驾驶感知有何变化？

编者语：后台回复“入群”，加入「智驾最前沿」微信交流群

原文链接：https://zhuanlan.zhihu.com/p/14173403896

不得不感叹的是，自动驾驶行业的技术的发展日新月异，技术热点已经从BEV迅速地转移到了端到端上。不管如何看待端到端，最近一年端到端的火热已经切实影响到了这个行业的每一个人。相比于在紧锣密鼓恶补各种模型知识的传统规划的工程师而言，大家似乎往往默认感知算法工程师在端到端时代是有优势的。

但实际上，和很多朋友交流下来，我发现很多人还是做着和以前类似的工作，专注于某个感知task来提升端到端性能，忽略了端到端时代下真正的感知红利。最近看到@Patrick Liu大佬(https://www.zhihu.com/people/patrick-llgc)分享了感知工程师如何恶补规划知识的文章，很受启发，因此想在这里结合我们ICLR 2025的工作SSR，分享一些从感知角度出发的思考。

arxiv: [2409.18341] Does End-to-End Autonomous Driving Really Need Perception Tasks?（https://arxiv.org/abs/2409.18341）

github: https://github.com/PeidongLi/SSR

端到端的复兴

而随着BEV感知的快速发展和Transformer架构的不断成熟，端到端终于又带着全新的架构卷土重来，尤其以UniAD为代表，把这项经典技术又重新带回了大众视野内。各家纷纷掏出自己的一段式、两段式方案，只要是能把规划模块NN化，就可以说自己已经端了（端到端风评被害:D）。

端到端的感知红利

在传统的感知-规划框架里，感知的目的是全量化尽可能多的获取精确的场景感知信息，让规划模块能有完备的输入以得出好的规划结果。这是由于传统框架模块化的设计使得感知无法获得规划的需求，所以只能尽可能多的提取有效信息给下游模块使用。目前主流的端到端方案也大都延续了这一思路，无非是把BBox，Map这些信息换成query来表征，把原来的各种感知任务当成auxiliary loss加进来做监督。当然还有那种把感知网络decode出来的感知信息，再重新encode又输入到规划网络的两段式方案。但一个一直被忽略的问题是，端到端时代下依然还需要这么多人为定义的感知任务吗?或者说，真的还需要全量的感知信息吗?

对于感知而言，端到端最大的意义在于"Planning-Oriented"，也就是从全知全量的感知到可以学习的的按需感知。我们以传统的检测任务打个比方，感知任务就相当于特征提取，轨迹生成则相当于特征处理。目前定义的各类感知任务就类似于SIFT这种手工特征，是人为定义的而非学习的。而端到端架构打通了从轨迹生成任务到感知模块之间的反向传播通路，为一种可学习而非人为设计的感知模块提供了可能。这正是端到端时代下感知最大的红利，也是目前主流端到端方法因循守旧所忽略掉的。扪心自问，这些人为定义的感知任务不恰恰就是感知模块自己的手工特征算子吗？

在端到端时代，不仅规划模块要革自己的命，感知模块也要有勇气革自己的命。也许端到端模型对于场景的理解方式和我们人类并不相同，基于人类先验知识定义的感知任务反而约束了端到端模型的上限。很多最新的用大模型来做自动驾驶场景理解的工作，同样也能不依赖于这些感知任务来实现很好的场景理解。

更何况，感知任务同样层出不穷，从2D检测3D检测再到Occ，我们也无法定义和穷举所有的有效任务。相反地，如果我们通过learning的方式在端到端模型中去除了这些人为定义的感知任务，得到的好处也是显而易见的。一方面，这将极大减少模型对于标注资源和训练资源的需求，提高端到端模型的Scalability；另一方面，按需感知的高效推理速度能使得端到端模型更快地走向大规模量产部署，真正让端到端模型在数据闭环下乘上Scaling Law的东风。

Navigation-Guided Perception

为了实现这一构想，我们设计了一个基于BEV特征的Scene TokenLearner(STL)模块，来实现对于场景特征的高效提取。我一直是一个BEV特征的支持者，这一点从我们之前的工作（DualBEV）可以看出，这是由于BEV特征集成了语义信息和几何信息以包含完备的场景信息。虽然task-specific query直接和图像交互可以在各个感知task上实现很好的效果，但是BEV特征仍然是我认为的感知乃至端到端的基石模块。

既然BEV特征包含着所有的场景信息，那么理论上我们就可以直接根据BEV特征来输出规划轨迹。然而，这种类似于BEV-Planner的做法无论在效率还是性能上都不能够满足我们的要求。因此我们继续沿用了我们在做DualBEV时候的思路，希望在BEV层面引入注意力机制，但与直接预测占据概率不同的是，我们的STL模块首先使用一个SE模块将导航信息引入到BEV特征中，再通过TokenLearner预测BEV注意力来将场景表征压缩为16个scene query。

而Planning Decoder只需要和这16个scene query做交互就可得到最后的规划轨迹。也就是说，我们发现在Navigation-Guided Perception模式下，仅仅只使用16个query就可以有效表征当前规划任务所需要的感知信息，这在原来的全量感知方案下是难以想象的——哪怕是号称Sparse的各种端到端方案，实际上也需要上百个query来表征感知到的场景信息。通过这种对感知模块的极致压缩和高效利用，我们的端到端方案SSR不仅在训练效率和推理速度上都成倍地提高了，在性能上同样也大幅超越了各种SOTA的方案。

世界模型——隐式特征监督的新方向

为了使模型进一步摆脱对于人为定义的感知任务的依赖，我们诉诸自监督的方式，通过时序上的信息来增强对场景的理解能力。具体来说，我们引入了一个基于BEV特征的世界模型，在训练过程中通过预测未来帧的BEV特征和实际的未来帧特征做自监督，来增强scene query对于场景的理解能力。这种方法在之前BEV检测的HoP，端到端任务的LAW中都是有出现的。但由于我们Navigation-Guided Perception的方案在每一帧上关注的区域是在不断变化的，就无法按照这些策略mask掉某一帧然后进行一一对应的scene query监督。

在经历了很多种失败的尝试后，我们最终提出了一种在sparse query上做轨迹规划，而在dense BEV上做世界模型的方案。由于世界模型只在训练时作为一种增强方式来提升性能，这种设计既能保证轨迹规划任务在推理时的高效，同样也能使得世界模型在自监督时具备一致性来实现模型的收敛。我们目前的设计还仍然比较简单，并不像广泛定义下的世界模型那样直接囊括掉原始数据如图片、点云等的生成。但随着世界模型的研究越来越成熟，我们认为它终将会完全替代掉目前人定任务在感知模块的作用，成为隐式场景表征最可靠的监督方式。

端到端感知的AlexNet时刻

我们设计的SSR框架，最终仅用16个自监督可学习的query来作为场景的高效稀疏表征，代替了传统端到端方案里成百上千个人为定义并标注监督的query，使得感知模块终于从handcrafted perception task解脱出来。

在nuScenes和Carla上我们分别进行了开环和闭环实验, 对比了大量SOTA方案甚至包括arxiv上还未正式发表的工作，都实现了效率和性能上的大幅超越。

为了探寻导航信息如何指引scene query自适应的感知场景中与驾驶意图相关的区域，我们通过特征图的方式，对这些scene query进行了可视化。可以看出，在不同的导航指令下，左图中红色星号代表的scene query最高亮特征位置会关注到对应的场景中最可能跟自车发生交互的区域。

同样地，如果在右图中对同一个路口场景输入不同的导航指令，scene query同样会自适应的调整自己的注意力来关注到不同的感知目标。而对比左右图中居中的图像，我们也可以发现对于相同的导航指令，在不同场景下，这种可学习的感知模块依然能够很好的做出调整。更多的实验细节和讨论分析可以直接翻阅我们的论文，这里就不再赘述。

尽管我们的方案摒弃掉了过去往往用作可视化的显式感知结果，但并没有放弃端到端模型的可解释性。就如同传统检测任务放弃了角点、特征点的提取显示，但仍然可以用特征图等方式可视化出CNN的热力图。我们今天给出的方案显然并不是端到端技术的终局，但我们希望它能够像AlexNet那样，成为可学习感知模块首次大幅超越人定感知模块的分界线，引导后续端到端任务的感知模块能够朝着可学习按需感知的方向大步地前进。我们也同样认为，一个可学习的而非人为定义的感知模块，才是在端到端时代下感知工程师真正应该发力的方向。而沉迷于某个具体感知任务的指标得失，则迟早会像手工设计的特征提取算子一样被时代淘汰。

-- END --

声明：内容源自知乎@PeidongL，文中观点仅供分享交流，不代表本公众号立场，如涉及版权等问题，请您告知，将及时处理！