WXRedian | 人工智能与量化交易算法知识库 | 聊聊端到端与下一代自动驾驶系统

最近一个月由于众所周知的一些原因，非常密集地和行业内的各种老师同学进行了交流。交流中必不可免的一个话题自然是端到端与火爆的特斯拉FSD V12。想借此机会，整理一下在当下这个时刻的一些想法和观点，供大家参考和讨论。

[文章转载自

https://zhuanlan.zhihu.com/p/692302970]

如何定义端到端的自动驾驶系统，应该期望端到端解决什么问题？

按照最传统的定义，端到端的系统指的是一套系统，输入传感器的原始信息，直接输出任务关心的变量。比如在图像识别中，CNN相对于传统的特征子+分类器的方法就可以叫做端到端。在自动驾驶任务中，自然想到的一个定义便是，输入各种传感器的数据（相机/LiDAR/Radar/IMU…），直接输出车辆的控制信号（油门/方向盘转角）。为了考虑不同车型之间的适配问题，也可以将输出放宽为车辆的行驶轨迹。这便是一个传统意义上，或者我叫做狭义端到端的定义。在这样的一个基础上，也衍生出了例如UniAD这样模块化端到端的概念，即在最终输出控制信号或者路点之外，也引入了一些相关的中间任务的监督来提升性能。

然而，除了这样狭义的定义之外，我们还应该从本质上思考一下，端到端的本质是什么？我认为端到端的本质应当是感知信息的无损传递。我们先回想一下在非端到端系统中，感知和PnC模块的接口是什么样子的。一般我们会有针对白名单物体（车，人，etc）的检测/属性分析/预测，会有对静态环境的理解（道路结构/限速/红绿灯，etc），如果做的更细致一些的话，还会做通用障碍物的一些检测工作。从宏观的角度来讲，感知输出的这些信息，都是对复杂驾驶场景的一种抽象，而且是人工定义的显式抽象。然而，对于一些非常见场景中，现在的显式抽象难以充分表达场景中会影响驾驶行为的因素，亦或是我们需要定义的任务过多过琐碎，也难以枚举尽所有需要的任务。所以端到端系统，提供了一种（也许是隐式）全面表示，希望能够自动地无损地将这样的信息作用于PnC。我认为，所有能满足这样的系统，都可以叫做广义端到端。

至于其他的问题，比如对动态交互场景的一些优化，我个人的观点认为至少并非只有端到端才能解决这些问题，端到端可能也不是解决这些问题最好的一个方案。传统方法是可以解决好这些问题的。当然，在数据量足够大的时候，端到端可能会提供一个还不错的solution。关于这个事情是否有必要，会在后几个问题中展开讨论。

关于端到端自动驾驶的一些误区？

一定要输出控制信号和路点才是端到端

如果能认同上面所讲的广义端到端的概念，那么这个问题就很容易理解了。端到端更应该强调的是信息的无损传递，而不一定要直接输出任务量。这样狭义的端到端做法，其实带来和非常多不必要的麻烦，需要大量的兜底方案来保证安全，然而这样也会有很多的问题，在后面会展开。

端到端系统一定要基于大模型或者纯视觉

端到端自动驾驶的概念和大模型自动驾驶以及纯视觉自动驾驶没有任何必然的联系。这三个概念是完全独立存在的，一个端到端的系统不必一定是传统意义上的大模型驱动的，也不一定就是纯视觉。三者之间有一些关联，但不等同。

之前我有一篇文章详细阐述过这些概念之间的关系，详见：

Naiyan Wang：再来聊聊近期火爆的几个大模型和自动驾驶概念zhuanlan.zhihu.com/p/664189972?utm_psn=1762524175137247232

长远来看，上述狭义的端到端系统有没有可能实现L3级别以上自动驾驶？

其实我先想来吐槽一句，号称要用大模型来颠覆L4的人，都没有实际做过L4；号称端到端包治百病的人，也都从来没做过PnC。于是和很多对端到端狂热的人聊下来，就变成了一个纯粹的无法证实也无法证伪的宗教信仰之争。我们做前沿研发的同学，还是应该更实事求是，讲究证据一些。。。最起码对想要颠覆的东西有一些基础认知和了解一下其中棘手的问题，这是应该有的基本科学素质。。。

言归正传，目前来看，我是悲观的。暂且不论目前号称是纯端到端的FSD，性能还远远不能达到L3级别以上所需要的可靠性和稳定性，未来就算是统计意义上这个车辆和人是一样安全的，还要面临如何和人类驾驶员的错误做align的问题。更直白一点来说，就是说，一个自动驾驶系统想要让大众和舆论接受，关键可能不在于一个绝对的事故率和致死率，而是在于大众是否能接受有一些场景中，对于人类是相对轻松解决，而机器会犯错的。这个需求对于纯端到端系统来说更难以实现。更具体的在我21年的一个回答中有阐述，详见：

如何看待李彦宏朋友圈发表：无人驾驶肯定会出事，只是这个概率比有人驾驶低多了？www.zhihu.com/question/530828899/answer/2590673435?utm_psn=1762524415009697792

举在北美的Waymo和Cruise为例，其实分别都出过不少事故，但是为什么Cruise最后一次出现的事故让监管和大众尤为不能接受呢？这个事故发生了两次伤害，第一次的碰撞，对于人类驾驶员也是相当难以避免的，其实也是可以被接受的。但是在这一次的碰撞发生之后，发生了严重的二次伤害：系统错误地判断了碰撞位置和伤员位置，为了不阻塞交通，降级到了靠边停车的模式，将伤员拖拽很久。这样的一个行为，是任何一个正常的人类驾驶员都不会做出的事情，而且影响非常恶劣。这个事情直接导致了Cruise后续的一些动荡。这个事情其实也给我们敲响了警钟，如何避免这样的事情发生，应该是自动驾驶系统研发和运营中认真考虑的问题。

那么站在现在的这个时刻，下一代量产辅助驾驶系统中切实可行的方案是什么？

简单来说，我认为一个合适的系统应当是首先充分挖掘传统系统的能力上限，然后再去结合端到端的灵活和普适性，也就是一个渐进式端到端的方案。当然这两者如何有机地结合就是个付费内容了，哈哈。。。但是我们可以分析一下，现在所谓的端到端或者learning based planner实际落地在做的事情是什么。

以我有限的了解，目前所谓端到端模型在行车中使用的时候，在输出的轨迹之后都会去接一个基于传统方法兜底的方案，或者是这样的learning based planner和传统的轨迹规划算法会同时输出多条轨迹，再通过一个selector来选择一条执行。如果这样设计系统架构，这么一个级连系统的性能上限其实是被这样的兜底方案和selector限制住的。如果这样的方案仍然是基于纯feedforward learning的，仍会有不可预测的失效，本质上并不能达到兜底的目的。如果考虑在这样输出的轨迹上使用一个传统的规划方法再去优化或者选择，那相当于learning based方法出的轨迹，只是给这样的一个优化和搜索问题做了一个初始解，我们为何不直接去优化和搜索这样的轨迹呢？

当然有同学会跳出来讲，这样的一个优化或者搜索问题是非凸的，状态空间很大不可能在车载系统上跑到实时。我请大家在这里仔细想这样一个问题：在过去10年中，感知系统至少吃到了100x的算力红利发展，但是我们的PnC模块呢？如果我们同样允许PnC模块使用大算力，结合上近几年先进优化算法的一些发展，这样的结论仍然成立吗？针对这样的问题，我们不应该固步自封，路径依赖，而是应该从第一性原理思考什么才是对的。

数据驱动和传统方法之间关系如何调和？

其实和自动驾驶非常类似的一个例子就是下棋，刚好在今年2月份的时候Deepmind发表了一篇文章（Grandmaster-Level Chess Without Search https://arxiv.org/abs/2402.04494）就在探索只用数据驱动，抛弃AlphaGo和AlphaZero中的MCTS search是否可行。类比到自动驾驶中就是，只用一个网络直接输出action，抛弃掉后续所有的步骤。文章的结论是，在相当的规模的数据和模型参数下，不用搜索仍然可以得到一个还算合理的结果，然而和加上搜索的方法比，还有非常显著的差距。（文章中这里的对比其实也不尽公平，实际差距应该更大）尤其是在解一些困难的残局上，纯数据驱动性能非常糟糕。这类比到自动驾驶中，也就是意味着，需要多步博弈的困难场景或corner case，仍然很难完全抛弃掉传统的优化或者搜索算法。像AlphaZero一样合理地运用各种技术的优势，才是最为高效提升性能的方式。

传统方法 = rule based if else？

这个观念也是我在和很多人的交流中需要反复纠正的。按照很多人的定义，只要不是纯数据驱动，就叫做rule based。还是举下棋这个例子，去死记硬背定式和棋谱是rule based，但是像AlphaGo和AlphaZero一样通过搜索和优化赋予模型reasoning的能力，我认为并不能叫做rule based。这恰恰也是目前大模型本身所欠缺的，也是研究者通过CoT等方式试图赋予一个learning based model的。然而人开车每一个动作都是有明确的动机的，这和需要纯数据驱动的图像识别等无法清晰描述原因的任务不同。在一个合适的算法架构设计下，决策轨迹都应该成为变量，在一个科学的目标指引下统一优化。而不是通过强行打patch和调参去修各种case。这样的一个系统自然也不会存在各种hardcode的奇怪的rule。

总结

最终总结一下，端到端也许是一个很有希望的技术路线，但是这样一个概念如何付诸实践还有很多有待探索的事情。是不是狂堆数据和模型参数就是唯一正确的解决方案，目前在我看来并不是的。我觉得，任何时刻作为一个前沿研究的技术人员，我们都应该真正奉行马斯克所讲的第一性原理和工程师思维，从实践中思考问题的本质，而不是将马斯克本身变成第一性原理。想要真正遥遥领先，就不应该放弃思考，人云亦云，否则就只能在不断想要弯道超车。

编辑于 2024-04-20 19:34・IP 属地中国香港

自动驾驶

赞同 1142102 条评论

喜欢收藏申请转载

有句话非常赞同，端到端的本质应当是感知信息的无损传递，但我感觉这个只说了一半，另一半是ppnc通过行为对无损传递的感知信息的filter/attention/clea(反正怎么说的都有，核心是对感知任务和信息的选择，info selection)。

现在人类先验定义的感知任务，配合ppnc来用的这套系统我们可以称为人定系统吧，人定系统的主要问题就是在于感知任务传递给ppnc的时候信息经过高度压缩，bbox, point seq是很显然不够表征复杂现实世界的，因此想办法给ppnc提供更丰富感知信息是从19年IL抬头以后大家都想做的，像mp3或者uniad这种通过seg或者query直接加入implicit vector来增强instance representation的方法本质上就是为了传递更多的信息。但是呢，自动驾驶毕竟不是重建任务，传递更多信息只是提供了用上的可能，怎么用好就到了e2e真正本质的后半程，用行为定义感知需求，用行为去筛选真正行为相关感知信息，把整个自动驾驶方案从“全知全能的非人类天神模式”改变为“啊不去的话我就看不了一点”的拟人lazy模式，这样可以降低信息学习空间容量，帮助实现感知信息下传在整个e2e系统中的可学习性。

纯隐式的方法例如kendall他们一直搞得那套东西，实际上车效果有多烂这几年应该大家也看到了，在行为数据缺少的时候大家才会又想着去加入RL或者搜索解决behavior variety，因此L4公司在真正量产化之前做e2e是永远没法达到好效果的，tesla shadow mode从一开始run的时候就是以行为作为value/cost fitler来设计的，因此积累到去年，数据量是绝对够而且在数据分布和价值上也能支持e2e的训练，这点是跟国内非常不一样的地方，shadow mode从一开始就不是以全知全能的自动驾驶之神而是一个lazy human driver，国内现在量产方案上车的公司，即使是mmt的飞轮也不是严格按照behavior来驱动的。另一方面学界的工作，比如mp3,uniad这些方法妥协在数据源和标注信息上，为了充分利用手里不多的标注结果，只能以模块化和辅助监督在设计整套方案，这其实也限制了e2e对感知的红利即超脱人定任务，所以上限的话如果有足够数据喂进来，说不定能摸摸人定系统的天花板（如果pnc的老哥们愿意适配同时感知的兄弟们也愿意把自己的数据都重新洗一波)，但是再往真正走广义e2e的话现在的学界方案实际上没法做（除了基于仿真的，不过这类方案的domin gap也大到不可能直接抄作业）。

对于国内的量产公司来说，现阶段肯定是想法拿已有的这一两亿标注数据把pnc的结果刷出来构成动静态+ppnc的数据集，先把狭义走通摸摸人定的天花板，这玩意儿估计基建好点的公司感知部门浪费一到两个Q就可以初见成效了，然后再按着PNC的头去集成一个Q联调，大家应该25年初就能看到初步的上线版本，这应该勉强算是国内特有的感知2.5版本。在这个credit基础上老板们才会同意去搞感知3.0实际上是广义e2e方案，这玩意儿的方案怎么搞，模型和系统怎么设计现在看还是其次，基础的几套方案都是很明确的，现在最不清楚需要摸的是基于行为能把感知的需求砍到多低，以及这套系统是不是真的可以自动balance对感知和ppnc的需求，这个确实没实际搞过e2e量产上车是很难估计的，跟shadow mode这种e2e的data close loop的经验直觉上我感觉是有gap的，这个估计只有tesla实际做fsd12 e2e集成的人才清楚（有资源social的佬们需要注意感知和pnc的算法开发同学，他们的集成经验没法回答这个问题）

最近也跟不少前沿的大佬小佬social了一轮，但是主要还是跟做量产的苦逼老兄弟们的互诉衷肠，所以以上基本是基于L2，L2+量产以及数据闭环产生的一些knowhow产生的观点，仅供量产的兄弟们参考。想发论文的同学们还是好好搞attention设计和多任务集成训练吧。有大佬真心想帮帮学界的话，想法开源个2kw frame左右的trajectory带图数据集，不带感知标注都没事，对e2e来说现在预刷的质量差不多够用了。搞e2e的量产公司可以先评估一下自己每天能不能至少拉出来10w条路口左右转数据，然后在这个数量级上再想怎么mining出来有价值的数据，咱至少得先赶上tesla几年前shadow mode的吞吐量不是。

之前的pnc是要不重不漏地枚举所有规则，以后就是可重不漏地枚举各种类型的数据，不管是实测、摆拍还是仿真，什么获得数据的方式都一起上，总之起码得做到不漏。
剩下的模型能吃下多少数据，就看缘分了。

rule based这个词不知道什么时候开始流行的，其实是一个很差的词，再加上百度还是哪个公司宣扬过有几万个if else，更是洗不清了完全输出控制信号是个执念，或许庞大的数据量可以真的实现端到端，但其实有那个数据量但不纠结于端到端的话，效果一定会很好，也能更快的达到目的。
就规控而言，搜索和采样还是不能代替neural planner的吧，多大计算量都不可以我觉得，我觉得这里面还是有一点不方便建模的智能的

如果你认为这些case人的决策都有明确的理性的动机可以解释那基于科学建模和优化当然可以搞定。如果你相信有些case驾驶员完全无法解释他的行为纯粹出于无法言说的奇妙直觉那么此时大约靠数据拟合出的某些不可解释的东西是必不可少的。可惜对于开车后面这种情况即使存在也是极为稀少的

不排斥端到端，但rule base这个词确实恶心。传统决策规划里有那么多优美且泛化能力也很强的数学方法，而且越好的算法rule就越少，目标都是没有rule。明明是不合格的工程师才只会写if else，导致现在传统决策规划已经等同于if else了。。。话说传统的搜索优化算法，在当年也是被称作智能算法，甚至神经网络、强化学习（最优控制）也是传统算法几十年前就涉及的领域了。网络和传统算法只是适合的领域不同，可以有机结合，而不是对立的关系

端到端做初解，其实比较扯淡，如果是对初解要求质量不高的牛逼求解器，那其实压根就不需要端到端，我一个pid控出来的照样OK，如果是对初解质量要求比较高的傻逼求解器，那这个端到端的既不符合运动学又不平滑，反而起到反效果，总而言之就是没啥卵用

我感觉现在各家“端到端”其实不过仍然是各个子任务分别训练，然后合并部署为一个模型到车上其中的关键问题在于，决策模块如何提供反馈给上游。举例来说，人在路上开车90%的时间都只需要沿着中心线往前开即可，不需要关心环境；而剩下10%的场景里，9.9%的时间上游结构化的输出就能够满足下游的需求。所以真正能够为端到端上游任务训练隐式特征得场景占不到0.1%。所以从训练角度来说，只有把这0.1%的场景挖掘出来才能真正帮助训练端到端的模型；而只有在这0.1%的场景上端到端的模型才能看到真正的优势（相对于将每个子任务拆开训最后合一起的假“端到端”而言）。最后会发现，端到端需要最多精力的地方并不在于模型本身，而在于场景挖掘。

而至于无图、纯视觉、learning based planning其实是独立的topic,并不一定和端到端完全等同。

围棋要树搜索很自然，很可能n步之前的走法对现在有巨大的影响，自动驾驶决策更偏当下一些，感觉对mcts的需求并没有那么高。v12很明显缺少些长期规划，博弈能力很强，但不太会提前变道避免后面陷入加塞，感觉他们真的就是数据驱动的alphago

是的。在车载算力、时效和能耗制约下，mcts 根本就是条死胡同。除非未来突破了制约。

不严谨地说，直接搞个端到端学输入到输出的映射关系，就像查字典，把各种case和输出轨迹对应关系学会，模型越大就是字典越大，数据越多就是字典里记的内容越多，碰到具体case就用最近邻搜索给一个插值的结果，但是这么搞还是会有OOD问题。所以我觉得，端到端模型现在的正确解决思路，不是努力去提高模型容量和数据大小（当然这些东西也是必不可少的，但是不是当前首要矛盾），而是去提高模型的推理能力。模型不用很大很复杂，但是记住了抽象的推理关系，而不是只是记住简单的映射关系，这样做应该也会让模型泛化能力更强。比如有的用word model去做，有的想办法提高因果推理能力，有的去仿真中对抗学习。有机结合传统系统中的知识当然也是一种好方法，但是现在有亮点的工作不多（比如GameFormer这个工作就觉得很巧妙，learning出轨迹+传统优化的方法可行但是并不优雅）