全文3.7万字，全部读完需要2-2.5个小时。
6月中旬，九章智驾跟辰韬资本、南京大学上海校友会自动驾驶协会联合发布了《端到端自动驾驶行业研究报告》，这份报告在行业引起了很多强烈反响。随后的两个月里，在这份报告的基础之上，笔者对端到端自动驾驶这个话题又有一些新的观察与思考，于是撰写了文本，作为对此前报告的修正及补充。
本文涵盖的内容见下方思维导图——
注：
九章撰文历来坚持“非必要，不废话”这一基本原则——任何不具备稀缺性的知识或信息都视为“废话”，尽量不予采用。不过，为了保证上下文的连贯性，也考虑到不同读者对该话题所掌握的背景知识参差不齐，本文第一章对废话的包容度比较高；其后的每章，也都包含了不同程度的废话。
为避免浪费读者时间，笔者会在废话含量比较高的章节的开头做个简单的提示，敬请谅解。
1. 端到端的定义及分类
1.1 端到端的基本定义
1.1.1 感知信息的无损传递
在此前的报告中，我们提到，端到端的核心定义应为：感知信息无损传递、可以实现自动驾驶系统的全局优化。
这个全局优化是如何实现的呢？具体地说，端到端模型通过神经网络的链式法则，从输出端（规划）向输入端（感知）贯通，输出结果可以将误差依次反向传播给所有模块，以最小化整体损失函数为目标，更加准确地更新每个网络层中的参数，从而达到全局最优。
1.1.2 不包括控制算法
值得注意的是，目前产业里大部分公司谈的端到端主要是指“感知—预测—决策规划”的端到端，而不包括控制。
何小鹏在此前的端到端发布会后就曾表示：“没有任何人敢说端到端都是神经网络。它是在一个体系里面完成的，就像刹车在哪里，它一定是有规则体系的。我们在规则体系里面有一个优势，能够把刹车控制器的算法沙盒做好。
1.1.2.1 关于“输出控制”的误解
有不少媒体称特斯拉的端到端系统包括了控制模块，能够实现「输入视频 + 输出控制」，但这是以讹传讹。
不过，据汽车之心在7月份的《端到端自动驾驶：谁在 All in，谁在观望》一文报道，蔚来汽车计划把控制代码也模型化，并纳入到端到端系统；而理想智能驾驶技术研发负责人贾鹏泽表示未来将把端到端、VLM 这两个系统继续合并成一个系统，“力大了之后 VLM 能跑实时了，直接输出 action”。这个该如何理解呢？
蔚来和理想讲的“控制”和“action”，很有可能就是指“规划轨迹”。
智加首席科学家崔迪潇说：action这个词是存在歧义的。比如，有的语境下，它指的是“是否超车”这样的决策；而在有的语境下，它指的是“刹车量”、“转向角度”等控制指令。 崔迪潇这个解释，也解答了一个困惑笔者很久的问题——早在三四年前，笔者就发现，通常，自动驾驶行业里的许多技术专家口中的“规控”，仅指决策规划，并不包括控制。 这些专家们并不在意自己说的东西会让别人产生怎样的误解，会造成怎样的“以讹传讹”，所以，已经习惯了这种不严谨，但我们作为听众或读者，一定要对此保持高度警惕。 |
1.1.2.2 把控制算法做进端到端的尝试
在2017-2018年那个阶段，有一些公司做到的端到端确实是包含了控制的，但后来就都把控制排除在外了。原因主要有如下几点：
•大家逐渐明白，控制部分，不同车型的差异比较大，很难将其做成标准化的接口；
•控制算法，传统Tier 1们做的东西已经很成熟了，自动驾驶公司做也没啥优势；
•把控制模块也纳入到一个具有不可解释性的黑盒里，实际上是把简单问题复杂化。
不过，产业界并未彻底放弃将控制算法做到端到端里面的尝试。比如，某主机厂正在做的端到端模型，就可以输出控制量（比如，方向盘角度、加速度、刹车力度等）。
为什么要直接输出控制量呢？原因有三——
•相比于行为轨迹，控制量要更接近最终结果。
•直接输出控制量，有助于模型摸清车辆的动力学模型和控制执行器的性能极限。
•在生成控制量的时候，可以把车辆动力学的一些约束给加进去——比如，在时速 100 公里的情况下，方向盘的最大转角不能超过多少。这样，最终采出来的状态空间就一定是车辆可执行的。
不过，端到端模型输出的控制量并不直接交给下游的控制算法，而是用于对轨迹做一次积分。
为什么要对轨迹做积分呢？ 因为，轨迹有可能会抖、会跳，这样的轨迹输出是没法直接给到控制算法去执行的，需要做后处理才行，而积分积出来的轨迹是平滑的，这就减少了对轨迹做后处理的需求。（某无人驾驶公司的算法总监说：这种做法违背了端到端的初衷。）
不过，零一汽车CEO黄泽铧说：“卡车的方向盘转45度，跟乘用车的方向盘转45度，是完全不同的概念。”笔者由此推断出，哪怕同样是乘用车，小轿车的方向盘转45度，跟大型SUV、MPV的方向盘转45度，也是不同的概念。可见，直接输出控制量，会影响到端到端系统的跨车型泛化能力。
1.2 两个类型及代表玩家
本小节的内容，在我们之前的报告中已经出现过，所列举的例子，在各媒体的文章中也出现过不少，但为了文章结构的连续性，在这里还是做个简单的提炼。对相关内容已经比较熟悉的读者可直接跳过。
模块化的端到端模型并没有完全抛弃传统的自动驾驶技术栈，它仍然包含可见的感知和规控算法模块，但改变了子模块连接的方式——传统自动驾驶系统下，感知模块和规控模块靠规则（显式）来连接，但在模块化的端到端模型下，感知模块和规控模块是用神经网络（隐式）连接起来的。
在传统自动驾驶系统中，显式连接的方式无法完成梯度传导，只能靠人工优化（必须对感知模块和规控模块分开调优）；但在模块化的端到端模型中，隐式链接的方式保证了整体网络的一致性，因而能够完成梯度传导——只要后面的结果不好，就可以对前面几个模块都进行训练。
正是跨模块的梯度传导，保证了对端到端模型的所有训练都有助于最终达到全局优化的效果。
上海人工智能实验室、商汤、地平线等机构/公司在2023年合作发表的CVPR最佳论文中提到的UniAD,就是模块化端到端自动驾驶方案的典型代表。事实上，UniAD也成为了模块化端到端自动驾驶方案的基准范式。
此外，华为在2024年4月份发布的ADS 3.0（感知部分采用GOD的大感知网络，预测决策规划部分采用PDP），小鹏汽车在2024年5月份发布的端到端大模型（由感知大模型XNet+规控大模型XPlanner+大语言模型XBrain三部分组成）、及大疆车载于宝骏云海上首发搭载的端到端模型，也属于此类。
需要注意的是，笔者在很多媒体的报道中看到了“两段式”“一段式”的说法，但按照我们此前报告中的定义，无论两段式还是一段式，只要不支持全局反向传播、且同时有具体模块功能作用划分的，都不能算是“One Model端到端”，而顶多只能算是“模块化端到端”。
如理想的端到端“系统一”，官方的说法是One Model端到端，但由于中间输出了BEV特征，因而，若按我们在此前报告中的分类标准评判，则是模块化端到端。
1.2.2 One Model端到端
One Model端到端中不再有感知、决策规划等功能的明确划分，从原始信号输入到最终规划轨迹的输出直接采用同一个深度学习模型。One Model端到端可以是基于大语言模型，也可以通过世界模型衍生而来。
1.2.2.1 基于大语言模型的One Model端到端
大语言模型具有很强的通识能力，所谓基于大语言模型做端到端，即感知信息被传输给大语言模型，大语言模型对这些信息进行解码，然后输出轨迹。
基于大语言模型的One Model端到端，最具有代表性的是Wayve（LINGO2)、理想（系统二）与零一汽车（ZSD方案）三家的方案。Wayve与理想的端到端方案已在媒体公开文章中被报道过很多次了，在这里，我们主要简单介绍一下零一。
1.2.2.2 基于世界模型的One Model端到端
世界模型是系统根据海量数据对物理世界的重建，它具备理解周围环境以及交互情况，并对其他道路交通的参与者的行为做预测的能力。
最关键的是，理论上，世界模型可以像人类一样“认知”世界、“理解”世界构成以及元素之间的关联关系，它不仅能够基于感知获取的信息预测结果，更重要的是，可以对新的、没有见过的数据也能形成泛化的“理解”，也根据它对世界的“理解”，从而对未来做出预测。
因而，理论上，只要对世界模型进行微小的调整或者增加一些输出链路及模块，就可以实现One Model端到端自动驾驶。
走这种路线的代表性公司有Wayve（GAIA-1)、蔚来。
(图片摘自公众号“雪岭飞花”）
基于世界模型的One Model端到端有一个任务是“预测驾驶场景的像素变化”。这个难度极高的任务，会逼迫模型不仅仅学习优秀驾驶员的行为，还必须广泛地学习交通知识与物理常识。
而蔚来在NIO IN上提出来的是一个难上加难的“世界模型PLUS”，它的复杂度更高、输出维度更多，这意味着可以和真值比对形成的监督信号更多，加速神经网络的训练，同时也可降低系统运行的黑箱程度。
不过，目前来说，将世界模型应用于车端的设想，更多地还停留在学术讨论层面，离落地还有一些距离。原因主要有如下几点：
•车端算力不足。当前的车端算力尚无法支持大的世界模型运行，至于后续是否可通过蒸馏或者其他降秩的方式在保持对真实世界理解的能力下最大程度地裁剪模型，还需要等待端侧硬件算力的持续迭代。
•网络带宽不足。世界模型涉及到的数据量非常大，而当前的网络带宽尚无法满足大规模数据实时传输的需求。
•运行速度太慢。由于输出图像需要的token比较多，所以，世界模型的运行要速度要比大语言模型慢得多。
商汤绝影智能驾驶副总裁石建萍、辰韬资本执行总经理刘煜冬等多位受访者均认为，世界模型在自动驾驶场景的应用，目前应该还处于很早期的探索阶段。当前，比较可行的是，用它来合成一些端到端模型所需要的数据。
一个典型案例是，理想在此前的端到端发布会上，提到了世界模型，但世界模型并不是直接用来做端到端方案的，而是作为闭环仿真工具的一部分提供合成数据。
此外，作为对世界模型在自动驾驶场景中的应用探索最早的公司之一，Wayve的第一个端到端模型GAIA-1是基于世界模型的，但第二代端到端模型LINGO-2则基于大语言模型，这也从侧面印证了将世界模型应用于One Model端到端还需要一段时间。
2. 端到端可降低自动驾驶系统的开发及维护成本
端到端对自动驾驶产品体验带来的提升，各路文章已经介绍得比较多了，本文就不再赘述。接下来的两章，我们主要梳理一下它对自动驾驶的研发工作带来的益处。 这种益处，可分为降本和增效两个方面。
2.1 降低了系统的复杂度
传统的感知-融合-预测-决策-规划架构可能涉及到十几个子系统和更多的软件模块，而端到端则可以将与之相关的子系统缩减为一个。由于模块数量大幅度减少，所以，系统设计的复杂度也大幅度减少了。
这一点是显而易见的，因此，无需赘述。
2.2 降低组织的内耗成本
本小节的内容，在之前的报告中已经出现过，已经看过报告的读者可以略过。
2.1里面提到，从模块化转向端到端，系统的复杂性大幅度降低。而子系统简化意味着研发团队的分工简化，进而可以大大减少部门墙对组织效率的影响。
很多时候，自动驾驶测试中遇到的问题，很难准确界定属于感知部门还是决策规划部门，也许无论哪个子系统的优化都可以解决这个问题，因而，在实际工作中这两个部门的接口也是最容易遇到责权不清的问题，这就间接地增加了系统工程、各个算法方向上的人力投入。而端到端的核心技术原理是全局统一优化，这同时也意味着组织目标的统一对齐。
2.3 减少了对数据标注的需求
5月中旬，零一汽车在发布会上提到，在采用端到端方案后，数据标注需求减少了90%。由于此前对这个话题关注不多，因此，对这个说法，笔者当时是相当惊讶，甚至是高度怀疑。这是真的吗？
随后，带着质疑与好奇，笔者向辰韬资本执行总经理刘煜冬等多位资深业内人士请教，在经过多个回合的交流后，最终梳理出的答案是：
从下图中的决策规划模型化阶段到模块化端到端阶段，再到One Model端到端阶段，模型训练对数据标注的需求依次降低。 |
•在模块化自动驾驶技术（上图中的阶段一、阶段二）中，由于感知模块跟规控模块之间是通过人为定义的规则连接，工程师们在做训练的时候，需要先让决策规划模块知道，感知模块看到的东西究竟是什么，所以，对感知的标注必不可少。
•在模块化的端到端（上图中的阶段三），每一个模块还是要先做一遍传统的训练，然后再合到一起做训练，因此，跟传统的自动驾驶算法训练一样，标注仍然是必不可少的（隐式表达特征这里需要标注）。只不过，由于感知和决策规划是连在一起的，在遇到问题后，系统可以通过被标注的决策规划数据来“反推”感知遇到了什么问题，所以，与阶段二相比，阶段三对感知数据的标注需求会有所下降。
•而在One Model端到端（上图中的阶段四）技术中，系统在输入感知信息后就直接输出了规划轨迹，不需要系统告诉“行人在哪里”、不需要做语义分割 ，所以，在理想的情况下，感知数据是一点儿标注都不需要。在这个阶段，面向感知的标注需求将会转向面向规划的标注需求。当然，规划的标注不涉及太多细节，就比感知的标注简单得多了。
尽管在理论上，One Model端到端的训练是不需要标注的，但在实践中，为了让模型能更快地收敛，同时确保其能真正理解那些它应该关注的目标，很多人会在模型中加入一些约束项（比如障碍物信息），让中间结果可视化。这些信息，是需要标注的。
对此，智加首席科学家崔迪潇说：
有些人说我在训练的时候，除了轨迹，我就不需要监督项，这种对训练和数据的要求是最简单的，但这里面的难点就是模型设计上，在不需要这些监督时，也能定义和寻找到驾驶任务中重要的信息。 |
许多公司都用到了多模态大语言模型的，会涉及到对一些信息的的处理，如果希望实现更强的交互能力，就还需要对这些信息做标注。
但无论如何，相比于原来的BEV那套东西来说，标注的内容已经简单得多了，工作量也大幅度下降了。
2.4 降低了代码管理工作的难度，并有可能降低人员离职带来的不利影响
在规则时代，代码管理的工作量特别大，而这块出的问题又特别多。
同一个公司内部的代码 ，不同Leader 的管理风格是不一样的，这导致有些模块的代码就很干净，而有些模块的就简直是“屎上雕花”（工程师语）。
并且，由于大部分的代码注释都写得不怎么样，因而，在写代码的人离职之后，后面再加入的人经常看不懂前面的人写的代码，甚至不明白当初写的规则是为了解决什么问题。因而，在工程师离职之后，很多研发成果就没有了。
尤其值得注意的是，哪怕离职的工程师并非团队的骨干成员，后续的研发工作也会受到很大的影响。
自动驾驶公司在上了端到端系统之后，代码量有望大幅度减少，那么，在训练框架完成之后，普通工程师的离职对研发工作带来的不利影响有没有可能被削弱？
多位受访者都认为，相比于之前的模块化方案，端到端确实更容易降低普通工程师离职对研发带来的不利影响。当然，这一效应要等研发体系收敛之后才更容易体现出来。
崔迪潇认为，在研发体系收敛之前，尽管上车的代码量减少了，但线下（模型的外围工作）的代码量是增加了；这个时候，普通工程师的离职对研发的影响也不小。而在研发体系收敛之后，代码量就很少了，这个时候，普通工程的离职就对研发没多大影响了。
【崔迪潇对“研发体系收敛”的定义：不仅包括设计、实施、应用，还要将应用中出现的问题，通过该套研发体系进行几轮的迭代、优化，发现和缓解了体系中的堵点和瓶颈。】
3. 端到端可倒逼企业提升数据闭环能力
“数据闭环能力，是自动驾驶下半场的入场券。”这是九章在2023年7月底的一篇文章的标题。现在，我们仍坚持这一观点。
在端到端成为自动驾驶新的技术范式后，产业界普遍认为，“数据壁垒将成为最重要的因素，主机厂等数据所有方的主导权将大大增强”。不过，对这一看法，笔者并不完全认同。
我们先来思考一个灵魂问题：同样是行万里路，为什么李白、苏轼这种人行万里路之后能写很多诗，而大部分人，行万里路则跟个当快递员没啥区别？为什么曹雪芹、王小波把自己受过的很多苦难转换成了写作素材，而对大部分来说，苦难就纯粹只是苦难而已？
笔者的观点是：数据闭环能力，要比获取数据的能力更稀缺。 掌握了海量数据、但不具备数据闭环能力的主机厂，跟既掌握了数据又掌握了数据闭环能力的公司的差距，就相当于快递员跟李白、苏轼、曹雪芹、王小波的差距。 可见，准确的说法应该是：在端到端时代，能做好数据闭环、能基于量产车上的数据训练端到端算法的公司，话语权会增大。 |
3.1 规则阶段，自动驾驶行业的数据闭环能力处于怎样的水平？
数据闭环能力补不齐，“量产车越多，数据量越大，就越有优势”这个法则就不成立。
去年年底（端到端成为共识之前），笔者曾向产业界的很多朋友问过一个问题：现在的数据闭环进展到什么水平了，真的能把量产车上的数据都用起来吗？ 得到的答案基本都是：哪怕是第一梯队的玩家，也都还没有基于量产车的数据做数据闭环的能力，目前，大家的算法训练，基本都是用测试车辆收集的数据做的。
甚至，还有个来自“绝对头部”玩家的自动驾驶产品经理说：能把测试车辆收集的数据利用好，对大多数公司来说，就已经很困难了。
笔者还反复追问过这样一个灵魂问题：在数据闭环时，是针对发现的每个corner case做“一事一议”的模型优化，还是把几十个corner case一次性输入进去做训练，然后，下一个版本的模型出来后，就把那几十个corner case全都解决了？
当时，笔者得到的答案都是：大都停留在“一事一议”的阶段（几个在当时被公认为是处在“第一梯队”的玩家也是如此），因为，大家的决策规划算法基本上都是用规则写的。
上述自动驾驶产业头部玩家的产品经理说：以当前的技术，别说一次性解决10个case了，就是解决一个，都特别难。
用“一事一议”的方式解决corner case，不仅效率极低，而且还存在“跷跷板效应”——应对Case B的新规则跟应对Case A的规则打架，你把Case B解决了，Case A可能又重新出问题了。
有一位规控算法工程师在听到笔者的问题后很激动地说：
这个问题，我之前在找工作面试的时候，向每一家都提过。大家都承认“一次性解决很多个case”这个思路更好，但大家又似乎都认为，在相当长一段时间里，还是会继续坚持用“一事一议”的方法，直到这种方法什么时候难以为继了（规则打架的问题太严重，改不下去了），再去升级到第一种方案。 |
3.2 从规则转向深度学习，数据闭环效率会大幅度提升
不过，今年4月份的北京车展期间，笔者拿同样的问题向包括鉴智机器人技术合伙人兼副总裁潘屹峰等人请教后，又得到了更进一步的答案：
如果采用的是端到端的架构，就有望一次性解决很多个Corner Case。 |
因为，工程师们本来是针问题 A补充数据，但由于补充的数据维度比较全，可能会顺便把问题B、问题C也给解决了。比如，工程师本只是打算解决车辆在乡村道路上左拐的问题，但由于采集的数据里面有雨天、黑夜这样的时间元素，然后，训练完之后，就把系统在雨天、黑夜情况下的效果也提升了。
出现这种进步的最根本原因在于——
在基于规则的方案下做算法训练，工程师要“要解决怎样的问题”“为了解决这个问题，需要使用怎样的数据”，并不完全由真实的驾驶场景来决定，而是需要由工程师来定义/描述，那么，如果工程师对这个问题的定义/描述得不准确、不全面，那对数据的选择就会出现差错， 并且，还会导致本来很有价值但跟工程师定义的特定问题“无关”的的数据会被排掉（浪费）。
工程师定义问题、准确地描述问题时的“吃力程度”，往往被低估了——笔者发现，很多工程师对日常生活中简单问题的描述，经常都是不准确的；尤其是，他们很容易把复杂问题过于简单化（最典型的问题是关键维度缺失）。尽管并没有拿到“实锤”，但仅凭常识，笔者就敢断定，在用规则来定义一些复杂的自动驾驶场景及应对方案时，工程师们肯定也经常会将复杂问题过于简单化。在这种情况下，数据的利用率显然是比较低的。
而在数据驱动的方案下做模型训练，工程师并不需要对“我需要解决怎样的问题”进行描述，他们顶多只需要在筛选问题的标准及技术手段上做一些工作， 这样，问题就没有被人为地“简化”，因而，被解决的往往就不是 单个问题，而是“系统级问题”。显然，在这种情况下，数据的利用率是比较高的。
简言之，在规则阶段，只有那些“被发现了”且“被准确地描述出来”的问题才能被“有意识地”解决；而在数据驱动的阶段，还会有很多 “尚未被发现”及“尽管已经被发现，但未能被准确地描述出来”的问题被数据闭环系统在“不经意间”给解决掉。 |
需要注意的是：上面几段写数据利用率、数据闭环效率的内容，并没有直接说“端到端相比于模块化自动驾驶的优势”，而是在说 “数据驱动相比于规则的优势”——即拿上图中的阶段二（决策规划模型化）、阶段三（模块化端到端）、阶段四（One Model端到端）跟阶段一（基于规则）相比的优势。
但有一个不争的事实是，端到端这种新的技术范式，确实是极大地加快了整个自动驾驶产业将决策规划由规则转向数据驱动的步伐——有不少公司公甚至司试图跳过上图中的“决策规划模型化”阶段，直接进入“模块化端到端”或“One Model端到端”阶段。
因而，也可以说，端到端正在倒逼产业链上的许多重点玩家加大在数据闭环上的投入，从而能大幅度提升数据闭环的效率。
3.3 从模块化到端到端，数据闭环效率进一步提升
从前面的《自动驾驶架构演进示意图》中的阶段二（决策规划模型化）到阶段三（模块化端到端），数据闭环的效率也有明显的提升。据智加首席科学家崔迪潇等人的分析，原因主要有如下几点：
3.3.1 数据在时间及空间上的一致性提高
在阶段二，对于哪些数据是最有价值的数据（最难搞定的场景），感知和规划的定义也不一样，这导致，对目标物信息的采集频率、处理频率及关键帧的定义，各个模块都没有拉齐。
但在端到端系统中，对哪些数据是最有价值的，感知和规划的定义是一致的（实际上也并不存在独立的感知和规划模块），这意味着，数据在时间及空间等维度上的一致性及关键帧的定义上会比模块化方案好很多。而这显然会大幅度减少测试验证的工作量。
3.3.2 从单任务处理到多任务处理
在阶段二，做数据闭环时，需要按ACC、左拐、车道线检测、图像质量评估等特定任务的形式理解场景，数据采集、数据标注、训练、测试验证登都要针对这个任务去做专门化的工作。
而进入阶段三，就不再需要按每个任务去理解了——一组数据进去之后，可能有好几个任务都被解决了。
3.3.3 对问题做“重复排查”的工作量大幅度减少
在阶段二，由于分了模块，有可能，哪怕要解决的bug是同一个，感知与规划各自所需要针对性优化评测的场景并不完全一致。这就会导致bug修复的工作量特别大。
比如，已经通过多轮仿真测试明确，感知在a、b、c三个场景最优，而规划在b、c、d三个场景最优, 但现在遇到的问题是，系统在d场景中的性能下降了，那问题出在哪了呢？经过几轮排查后才发现，是因为感知在场景d中的性能下降了，然后导致规划在场景中d的性能也下降了——规划是“无辜的”，本不需要拿在它场景d下做排查，但不排查，怎么能知道它是“无辜”的呢？
并且，在后续的排查中发现，规划尽管在场景d下是无辜的，但在场景a下却是有“软肋”的。然后，就需要再做针对性修复。
再拓展一下，如果感知关注的场景是abcde，而规划关注的场景是cdefg，这种情况下，做问题排查需要花的时间就更多了。
相比之下，到了端到端阶段，由于感知和规控的数据是完全打通的，就可以避免掉大量的重复劳动。
3.3.4 corner case数据被遗漏或被人为裁剪的情况大幅减少
在阶段二，感知模块跟决策规划模块之间依然是靠人为定义的规则来连接的，而只要存在人为一定义的接口，就大概率会存在一些本来对下一个环节有帮助但没有被清晰定义的数据被遗漏、甚至是被强制拦截或裁剪的可能。
人为定义接口，往往受限于写规则的人的抽象表达能力——一个老司机能讲出来的驾驶知识，远比他实际掌握了的驾驶知识少得多（李德毅语）。比如，本来，解决某个corner case需要A、B、C、D四类表征数据，但写接口的人可能认为，只需要A、B、C三类数据“就够了”。
在阶段二及之前的阶段，很多corner case的数据，已经被传回来了，但并没有被数据闭环系统充分地利用起来——是被规则（包括连接两个模块的规则）给“损失”掉了。
相比之下，到了阶段三，感知模块跟决策规划模块之间是通过神经网络连接的，就不存在上述问题了——它对数据的使用方式，让一些在之前的数据处理方式下很容易被漏掉的数据可以进入到数据处理链路里面去，然后被低损失地利用。
笔者是在跟崔迪潇交流之后再做出了上述分析，然后，笔者又拿上述观点跟零一汽车CEO黄泽铧做了交流。黄泽铧也表达了类似的观点——
驾驶其实是一个综合行为，并不是只有在看到目标物A的时候才能去做跟目标物A相关的决策，有可能在看到目标物B的时候就能做决策了。 在模块化方案中，目标物B可能被抽象的规则给过滤掉了；相比之下，端到端系统就可以捕捉到更多的东西。 |
崔迪潇说，他发现一个怪的现象：以往在谈数据驱动的时候，大家一方面强调数据闭环很重要，另一方面，又没有在数据闭环上面下很多功夫。“Andrew Karpathty说，他们有超过60%的时间都花在数据处理方面，那我们在数据上花了多长时间呢？”
在崔迪潇看来，做端到端最大的意义在于，把之前在数据闭环方面欠下的债都补上，比如，把数据的各种维度尽量拉齐。“哪怕最终端到端没有做成，这套数据闭环能力，再拿去服务模块化的自动驾驶，价值也是非常大的。”
4. “端到端需要更多数据”背后的概念混淆与真相
在本文3.3.4的写作过程中，笔者突然意识到：
从《自动驾驶架构演进示意图》中的阶段二（仍然是分模块，感知和规控之间通过规则连接，但决策规划已经采用了深度学习）到阶段三（模块化端到端，感知和决策规划之间通过人为定义的接口连接），由于需要解决的问题并没有增加，而数据的利用率却大幅度上升，所以，如果要达到同等的效果，则模型训练对数据量的需求应该不是上升了，而是下降了。 |
上述假设，最初来自于笔者对九章内部做研究报告及写文章的对比——九章的咨询团队花在写研究报告上的时间很多，尽管真正的有效产出少得可怜，但使用的原始调研数据的量却非常大；相反，笔者跟另外一位同事及一些兼职作者写文章，尽管有效产出量很高，但真正使用到的原始数据量并不多。
在相当长一段时间里，笔者一直将这种差异的主要原因归结为“水平差异”，认为文章的作者们更擅长将有限数据的价值“吃干榨净”；不过，在“端到端”与“模块化”这一组概念的对比开始深入人心之后，笔者突然意识，之前的解释尽管也没有，但并没有直击本质。
本质原因是——
咨询团队在做报告时，列调研提纲、电话调研、整理调研纪要、撰写初稿、编辑几个环节通常都是由不同的人进行的，也许有的人做了A环节后还会去做D或E，但比较是交替进行的，作业不连贯，这是一个典型的模块化的作业方式。这种方式导致数据的利用率极低，因而，哪怕最终的有效产出很少，对原始数据的需求量也非常大。 相比之下，我们在写文章时，从列采访提纲、采访、整理采访纪要、撰写初稿等几个环节（甚至还有修改环节）通常都是由同一个人完成的，这是一个典型的端到端的作业方式。在这种方式下，数据的利用率极高，因而，哪怕最终的产出量很高，对原始数据的需求量也不至于特别大。 |
另一组例子是，九章跟两家合作方在6月份发布的《端到端自动驾驶研究报告》与大家正在看的这篇文章的对比——上次的研究报告，总字数为3万字，但我们使用了来自32外受访者的32小时对话数据；这次的文章，在扣除掉引用的公开资料及笔者的主观评论后，总字数也是2.8万字左右，但仅用到了来自7位采访对象的大概7小时的对话数据。
原因也是在于，上次的报告是以模块化的方式完成的，因而，对数据的利用率很低（平均每小时的原始数据被采用了不到1000字），而这次的文章，则是用端到端的方式完成的，因而，对数据的利用率很高（平均每小时的原始数据被采用了4000字）。
诚然，报告对结构化的要求特别高，所以，天然需要裁剪掉更多不符合结构需求的素材，但总体上来说，九章的文章和报告，有效信息的密度是差不多的，所以，两者的“数据利用率”是具备一定的可比性；并且，根据这种对比来推演“自动驾驶从模块化转向端到端，对数据量的需求会不会下降”，也是可行的。
4.2 全栈方案与分开定点对数据量的需求差异
投资机构的朋友大都有过写报告和文章的经历，对笔者在上面的类比应该很有共鸣；产业内的朋友大多不写报告和文章，可能对上面的内容“无感”，那笔者就再追问一个问题：分开定点与选择全栈方案，哪种路线下供应商（在分开定点的情况下，是跟最终系统相关的“全体供应商”）对数据的利用率更高，对数据的总需求量更少？
任何一个诚实的人都会认为，全栈方案对数量的总需求量更少吧？
从逻辑上讲，端到端跟模块化方案的的区别，就类似于选择全栈方案跟分开定点的区别。
4.3 相比于模块化，要解决同样的问题，端到端对数据量的需求会减少
这次，在笔者提出“从阶段二（模块化，但决策规划已采用了深度学习）到阶段三，如果要达到同等效果，模型训练对数据的需求量应该会降低”这一假设之后，某受访专家做了一番推演——
在阶段二，由于分了模块，为解决同一个bug，有可能感知与规划各自需要优化评测的场景并不完全一致，比如，上游感知关注的场景是a、b、c，而下游规划关注的场景则是b、c、d，这种情况下，感知和规划两个环节都能做好优化的就只有b、c。 也就是说，场景a和场景d尽管数据都有，但并没有被用起来。而对数据利用率低就意味着，要解决同样的问题，需要的数据总量更多。 而到了阶段三，从数据上要求从感知到控制是时空联系的数据，所以各个部分关心的都是a b c d——在模块化方案对应的数据闭环体系，被拉齐的是对数据的抽象结果的表达形式，而在端到端方案对应的数据闭环体系里，大家拉齐的是数据本身。 |
可见，相比于模块化方案，在端到端方案下，数据闭环系统对数据的利用率要高得多；而对数据的利用率高就意味着，要解决同样的问题、达到同样的效果，需要的数据总量就更少。
进一步推演可知：如果端到端跟模块化方案所使用的数量相同，它所能解决的问题就更多、效果就更好。
【当然了，由于没有了中间结果作为提示，所以，从阶段二到阶段三，数据构造的难度也大幅度上升了。】
4.4 “端到端需要更多数据”背后的概念混淆
“既然端到端对数据的利用率上升了，那么，如果只要保证效果达到现有方案的水平的话，端到端对数据的需求量应该是下降了啊。可为什么会有很多人都在说端到端对数据的需求量上升了呢？”最近一段时间，在跟产业里的一些朋友交流时，笔者反复发出这个追问。
其实，如果不较真的话，“端到端对数据量的需求会大幅度上升”这个说法也没错。
当然，这背后存在一些概念混淆的问题。
4.4.1 拿深度学习跟规则比，而非拿端到端跟模块化比
如果拿《自动驾驶架构演进示意图》中的阶段三跟阶段一（也是模块化，但决策规划是用规则写的）相比的话，那端到端对数据量的需求肯定是升高了。
但这种比较，在本质上，并不是在拿端到端跟模块化方案比，而是在拿深度学习跟规则比。不过，多数人已经习惯了表达上的不严谨，自己在向别人介绍东西的时候很容易将混淆概念，所以，当别人混淆概念的时候，我们自己往往也没有“免疫力”。
所以，认同“端到端对数据量的需求会大幅度上升”，其实就是在认同“相比于规则，深度学习对数据量的需求会大幅度上升”，可这不是在认同一句正确的废话吗？
但如果要拿这句话正确的废话来指导工作的话，那阶段二（也是模块化，但决策规划是用深度学习做的）也不必做了吧？
4.4.2 把“我更舍得在你身上砸钱”混淆为“你更烧钱”
“我们在谈数据需求的时候，一方面是说模型训练需要多数据；另一方面说的是，模型的上限有多高、能用好多少数据。所以，准确地的说法应该是：端到端方案的上限更高，所以，它能够压缩更多的数据。”在笔者反复追问“为什么说端到端对数据的需求量是上升了”的过程中，辰韬资本执行总经理刘煜冬做出了这样的回答。
这个说法是很有启发性的。在听到这个答案后，笔者进一步确认：所以，本质上，并不是端到端“需要更多的数据”，而是‘它有能力用好更多的数据，所以，值得人们为它投入更多数据”？
在听到笔者的这个总结后，刘煜冬说：这个描述很准确。
如果还有人无法完全理解上述“颠覆常识”的观点，那就再看看下面几个“故事”——
故事一：
两个学生，一个智商低，一个智商更高。如果都两个孩子都只需要考70分，肯定是智商低的孩子，需要刷很多很多题才能达到目标；而智高的孩子， 只需要上课认真听讲，课后不需要刷题，或 只需刷很少的题也能轻而易举考个70分吧。
但通常情况下，智商高的孩子反而会更努力，更愿意花时间刷更多的题（因为能从刷题中获得乐趣）。然后，他们可能考了95分。于是，不明真相的人就会得出一个结论：智商高的人，需要刷更多的题。
故事二：
两个处于同一赛道、战略目标差不多的公司，A公司的老板不太擅长管理，因而公司的组织能力一般，然后人效也就不高，投资人也知道这一点；B公司的老板擅长管理，因而公司的组织能力很强，人效也就很高，且投资人也知道这一点。如果两个公司要达到同样的营收规模/盈利能力，显然B公司对来自投资方的资金支持的需求比A小。
但通常情况下，投资机构显然都更愿意投资B公司，因为，投资B公司，更有机会能拿到更多的回报。于是，不明真相的人会得出一个结论：做同样的业务，创始人能力更强的公司，需要烧更多钱。
故事三：
一个家里有两个孩子，老大智商稍微逊色一些，没那么爱学习，吊儿郎当；老二智商更高，也更爱学习、更努力。尽管两孩子的实力不同，但父母的目标是希望两个孩子考上同一个水平的211大学。
假如两个孩子能一直按家长设计的路线走的话，显然，父母需要在老大这边花更多的钱，比如，需要给他报课外辅导班、请家教，甚至还需要帮他支付“复读费”（第一年没考上）；相比之下，老二由于自己的能力强和进取心都强，所以，辅导班、家教、复读费这些东西他统统不需要，所以，家长不需要在他身上花太多钱。
但现在呢，老大参加了三次高考，连二本线都没上，于是，心灰意冷地进工厂打工了，这样，父母就不用再为他支付费了；而老二则在第一次参加高考时就上了985，后来还读了985的硕士、博士，并且，在他博士毕业之前，父母都要给他支付更多的学费和生活费。于是，就有一些亲戚得出一个结论：更聪明的、更爱学习的孩子，需要花父母更多的钱。
上面那三个标红的“结论”，是不是很滑稽？ 没错，“端到端需要更多的数据”，跟上述三个结论就是同样的逻辑啊。 |
4.5 不必理会特斯拉、理想等“既得利益者”的“恐吓”
“做端到端需要多少数据”这种论调能大行其道，还有一个很重要的原因是：特斯拉、理想等“既得利益者”，自己并没那么缺数据，所以，有足够的动力通过“你们没数据，肯定搞不成”这样的论调来劝退各种后入局者。
不过，这种“资源恐吓”，也就只能欺负一下“不明真相”的投资人罢了。真正有思考能力的从业者，岂能这么容易就被忽悠？
连笔者这样一个连代码都看不懂的外行，都能通过写报告跟写文章的对比来得出“如果只需要达到跟模块化同等的效果，端到端实际上会降低对数据总量的需求”这样的结论，有条件做测试的技术公司的老板们难道就搞不清楚吗？
零一汽车CEO黄泽铧说：
我们去年在做端到端研发的时候，最担心的问题就是数据量不够，担心需要上百万个小时的数据才能把demo跑出来，但实际上，我们只用了几千小时的数据就已经能做出不错的demo了。 |
对“数据短缺”的问题，晨韬资本刘煜冬和曾凡禹还做了如下分析——
•专注于矿山、港口这些封闭场景的公司，本来就不需要其他场景的数据，而在这些封闭场景内，通过反复采同质化程度比较高的数据实现模型的“过拟合”并不是什么难事，所以，这些赛道上的无人驾驶公司并不缺数据。
•乘用车赛道，主机厂缺的是数据闭环能力，而数据量，他们是不怎么缺的。
•乘用车赛道的自动驾驶初创公司，可以从各种公开的数据集里获得几千个小时的高质量数据集（端到端系统对不同格式的数据的兼容性很强），如果自己再采集几万小时的高质量数据，做个冷启动，有个初步的Demo应该是够了的。“有了Demo后，就可以跟主机厂谈合作。主机厂如果有兴趣合作，数据的合作共享一定是合作框架的一部分。”
5. 落地的诸多障碍逐渐被清除
一两年前，在谈起端到端应用于自动驾驶场景的可能性时，大家会发现还存在许多障碍，但随着实践的推进与思考更加深入，越来越多的人认为，障碍之前是被夸大了。实际上，很多我们之前认为是障碍的东西，都算不上是真正的障碍。
5.1 车端算力不是瓶颈
在关于端到端的讨论中，“车端算力不足”是一个被高频提起的问题。但这是一个真问题吗？
其实车端算力不足并不是个新鲜话题。
•早在2018年，笔者就注意到，在讨论双目摄像头应用于自动驾驶场景的可能性时，就有不少人认为“车端芯片算力不足”；
•后来，在讨论要不与上激光雷达的时候，有人说是“车端算力不足”（激光雷达能有多大的数据量，能消化多少算力？）；
•后来，在讨论要不要上800万像素摄像头时，也有不少人认为“芯片算力不足”；
•在后来，在讨论做BEV+Transformer时，还有不少人认为“车端算力不足”。
无论开发何种自动驾驶技术，算法工程师总是希望车载芯片算力越大越好。最关键的原因，也许并不在于“确实需要这么大的算力”，而是“算力越大，我做起来越省心”——不需要绞尽脑汁思考如何提高算力的利用率。
笔者甚至敢猜测，许多在工程师看来“许多更大的算力才能搞定”的事情，在老板的亲自指挥下，可能用现有的算力就搞定了。毕竟，工程师关注最多的是“怎么做我自己最舒服”，成本是不在他们的考虑范围之内的。
基于此，笔者大胆地认为：所谓算力不够用，在很多时候，只是一些“不愿走出舒适区”的技术人员“逃避思考”的说辞而已。
关关难过，但关关都能过，这次也一样——已经对端到端“蠢蠢欲动”的几家，大都不是基于更大算力的英伟达Thour来做，而是基于更具性价比的Orin来做。
为什么这些公司认为，Orin就足以满足端到端对车端算力的需求了呢？
一方面，对更高算力的渴望更多来自于模型参数量和模型性能的提升，而非来自于经典算法架构到端到端的转变。端到端的基础思想是整个算法处理流程的模型化，从经典架构到端到端，总的代码数量会显著降低，因此，端到端神经网络带来的计算资源消耗相比BEV模型并不一定会有显著的提升。
另一方面，软件与芯片一直是动态演化的，与其思考“端到端模型需要多少算力”，不如考虑“基于当前的芯片，应该如何优化端到端模型以实现高效的部署”。
5.2 数据瓶颈并非无解
尽管端到端对数据量的需求被特斯拉和理想等公司夸大了，但数据确实瓶颈是真实存在的。不过，这个问题并非完全无解。
对策主要有包括两个方面：用技术手段减少模型训练对数据量的需求；用合成数据来弥补真实数据的不足。
5.2.1 减少对数据量的需求
一些公司正在探索如何减少模型对数据量的需求。
如鉴智发现,由于为双目摄像头方案添加了“硬约束”（视差约束），降低了“解题”的复杂度，他们在用双目摄像头做占用网络时，对数据量的需求就只有用单目摄像头做的1%。
如零一的做法是，先在矿区这种对数据量的需求比较小的简单场景里面实现端到端的闭环；同时，通过量产车队收集其他场景的数据。
智加首席科学家崔迪潇的思路则是：重点并不在于需要多少小时的数据，而在于如何定义“有效数据”。
在数据有限的情况下，崔迪潇做过的探索是：针对某个场景先多采一些数据 ，并且，都做标注 ，然后，通过某种筛选准则把数据砍一半，再看模型在这组数据下测试时的关键指标有没有发生变化、发生了怎样的变化，以此来评估看自己的筛选准则是否能够把最有效的数据定义出来。
比如，原本有100小时的数据，现在，通过“车速有多大的波动”、“道路中间有多少及怎样的障碍物”这些筛选准则把数据从100小时筛选到10小时。然后，再看看模型在筛选后的数据下的性能跟在筛选前的数据下的性能相差大不大。 如果没有明显差异，那就证明筛选前的数据跟筛选后的数据对模型训练的价值是差不多的。
崔迪潇说：
关于数据如何筛选的思考是一个前置思考（因此还没有得到有效验证），不是事后总结；这是我们小公司做事情和大公司很大的差异，我们无法浪费很多资源去事后总结，更多是合理推演+广泛收集同行经验（尤其是教训），减少对资源的需求和不必要的浪费。 |
如果没有来自大规模车队的真实道路数据就做不了端到端自动驾驶，那就无法解释为何初创公司Wayve能成为端到端的代表性玩家了。
Wayve最重要的资本，就是他们基于世界模型生成的合成数据。
实际上，不仅是Wayve，就连真实数据的规模并不小的蔚来，甚至还有数据最多的特斯拉，都在大规模使用合成数据。
合成数据不仅具有无需标注、可高效生成corner case场景等特点，而且，还可以高效解决真实数据集中的场景多样性/分布问题，从而使模型更容易避免“过拟合”的问题。
合成数据及相关技术不仅可以弥补真实数据不足的问题，而且，还可以用来提升真实数据的使用效率。
对这个观点，光轮智能CEO谢晨此前的解释是：
在拿到主机厂或自动驾驶公司提供的真实数据后，光轮这样的合成数据服务商可以拿这些数据去基于NeRF技术做3D重建或泛化，并且加上Sim2Real（用Diffusion Model来提升数据保真度），这就把真实数据转换成了合成数据；然后，再在仿真系统里将这些合成数据跟真实数据“混搭”，通过这种“混搭”，以真实数据为主的数据集也间接地具备了“泛化能力”。 事实上，重建后产生新的数据，并且真实数据“混搭”，也是真实数据实现“泛化”的最有效方式。 |
通过这种“混搭”或泛化，真实数据的使用效率将大幅度上升。
真实数据跟合成数据“混搭”的比例，英伟达等多家公司实践的结果是，7：3（即合成数据占30%）的效果比较理想。
7：3这个比例，相当于在真实数据的基础上再增加了超过40%的数据量，但由于新增的那40%都是合成数据，有很强的泛化能力、可以做N多次排列组合，那么，最终用于算法训练的corner case的数量就不是增加了40%，而是增加了几十倍、甚至是几百倍！
由此可见，合成数据非但不是真实数据的“竞争对手”“颠覆者”，反而还可以给真实数据“加杠杆”“赋能”。
合成数据的批量化应用，还在客观上提高了算法/模型开发者 的地位。
以往，尽管数据也是为算法/模型服务的，但由于真实数据的筛选难度及使用难度大等的一系列弊端，算法/模型端尽管是“甲方”，他们在数据提供方面前其实行使不了多少“权力”——比较少谈“我需要怎样的数据”，更多地是“你有怎样的数据，我来迁就你”。
但在合成数据兴起后，算法/模型端就敢于去谈“算法的演进趋势是怎样的，这个趋势要求数据侧如何配合”。
5.3 闭环仿真测试的问题并非无解
端到端的仿真，难倒了一大批传统仿真公司。
一方面，传感器仿真一直很难，既无法通过真实数据回灌（缺乏可交互性）做，也无法通过WorldSim（保真度不足）做；另一方面，在数据驱动的阶段，规控算法的仿真既无法通过真实数据回灌，也无法通过WorldSim做。
【这个话题比较复杂，很难用一两句话解释清楚。我们后面会用一篇长文来解释。】
一年前，在跟光轮智能CEO谢晨交流时，笔者曾提出这样一个问题：在WorldSim中做规控算法的仿真已经很成熟了，却做不了感知算法的仿真，感知算法的仿真比规控算法的仿真难得多，这里面的逻辑是什么？
对此，谢晨的解释是：
当前，规控算法仍以规则为主，而WorldSim恰恰是基于规则来生成数据的，这样的数据用来测试验证基于规则的算法当然没问题；但是，感知算法已经是深度学习算法了，那用基于规则（WolrdSim）的数据来训练感知算法当然行不通了。 大的逻辑是“用规则来服务规则，用AI来服务AI”——更完整、更准确的说法应该是“用基于规则的数据（指由WorldSim合成的数据）来服务规则算法，用基于深度学习的数据（指由NeRF、Diffusion Model等生成式AI合成的数据）来服务深度学习算法”。 据此，由于感知算法是AI算法（深度学习算法），所以，能服务于感知算法训练的合成数据，应该也是“基于AI”的。 |
在谢晨这个解释的基础上，笔者还推导出一个观点：待规控算法以AI算法（深度学习算法）为主后，能服务于规控算法训练的合成数据，应该也是“基于AI”的。 这一推演，得到了谢晨的认可。
光轮的合成数据，正是“基于AI”的。
2024年6月份，谢晨在九章跟辰韬资本等联合举办的论坛上提到，在端到端阶段，我们需要的合成数据，应该同时满足高视觉/物理真实性、Agent交互性、及规模效率等特点。传统的WorldSim等手段生成的合成数据已无法满足这一标准。
光轮的做法是，将WorldSim跟NeRF、Diffusion Model等生成式AI结合起来，组成泛化能力很强的世界模型。此前，谢晨曾告诉笔者，光轮有一个使命是：用数据的创新推动算法/模型的创新。
光轮不仅提供基于生成式AI的合成数据，而且，也提供基于合成数据的仿真解决方案。
目前，光轮推出的合成数据集不仅用于CVPR 2024自动驾驶挑战赛，也应用于多家主机厂的研发项目中。
主机厂这一侧，据公开的信息，理想应该也已经开使用合成数据来做端到端算法的闭环仿真测试了。
理想自动驾驶负责人郎咸朋此前在接受云见Insight采访时说：理想学习特斯拉引入世界模型，搭建了一套跟原来不一样的考试系统，用仿真代替了研发人员自测，曾经在一周内迭代了 15 个版本，大大提升了系统的进化速度。
而据焉知的报道，理想还跟浙江大学合作开发了专门很对端到端的测试验证方法Street Gaussian。这一测试方法的最大亮点是可以将动态目标和静态目标进行分离。
这个引入了世界模型的合成数据，应该就跟特斯拉、Wavye、光轮的做法类似，甚至可能更复杂。
理想在端到端时代跑在了行业前面，跟他们积极拥抱基于生成式AI的合成数据不无关系。
总之，当大部分公司对合成数据还持观望态度的时候，那些老板有洞察力的公司，已经从中尝到了巨大的甜头。
5.4 大语言模型降低了端到端的落地门槛
尽管端到端与大模型并不必然相关——大模型更多关注模型的参数量以及涌现能力，而端到端更多强调的是结构上的梯度可传导以及全局优化，但这两个概念经常被放在一起讨论。
并且，Wayve、理想、零一等公司的One Model端到端中都用了视频语言大模型，小鹏的模块化端到端中也用到了大语言模型XBrain。
“那么，大语言模型是不是降低了端到端的落地门槛？” 笔者向零一汽车CEO黄泽铧提出了这个疑问。对此，黄泽铧的解释是——
端到端概念被提出来已经有七八年了，之前一直没有上车的可能性，最关键的原因就是，当时的深度学习模型无法只能理解相关性，却对事情与事情之间的因果关系缺乏足够的理解。 比如，车辆在看到红绿灯后停下来了，然后，自车也停下来了，但深度学习可能将自车停下的原因理解为“前车停下来了”，而非“红灯亮了”。在这种情况下，把这样的数据喂給深度学习模型，深度学习模型从中学到的东西并不是“我要看红绿灯”，而是“我要看前面的车是不是停了”。 大语言模型虽然也不能绝对理解因果关系，但由于训练数据的规模极其庞大，它已经对整个世界上的常识有了知识图谱级的理解（可以做二阶推理、三阶推理），已经非常了解世界是怎么运作的了。所以，像对车道线、交通规则的理解，在大模语言模型这个层面已经都消化了，不需要自动驾驶公司专门去训练了。 人开车，我们不是在上驾校的时候才开始学所有跟驾驶相关的知识——像对于道路的理解、对障碍物的理解，这些是人早就会了的。今天的大语言模型在干的事情就是，把世界上的很多知识跟驾驶任务建立了连接，利用一些基础知识帮自动驾驶系统开车。 |
此外，还有一位无人驾驶公司的算法总监说：
在大语言模型兴起之前，做端到端主要靠模仿学习，但模仿学习会遇到东施效颦的问题。如果引入了大语言模型，就可以让端到端系统具备一定的通识能力。 |
一个自动驾驶系统掌握的常识越多、能力越通用，它的落地障碍就越少，因而，确实可以说“大语言模型降低了端到端的落地门槛”。
其实，大语言模型跟端到端，是“相互成就”——在传统的模块化自动驾驶方案中，大语言模型的潜力并不能充分地释放出来，只有在端到端架构下，它才能“如鱼得水”。
因为，在传统的模块化自动驾驶方案中，规则人为地限定了系统性能的上限，这导致，很多大语言模型已经知道的东西，却被规则给拦截；但在端到端架构下，大语言模型就有条件去突破上限了。
6. 模型的“可解释性”问题尚未完全解决，但不影响大家继续前进
在上一章里，我们提到，端到端落地的多项障碍逐渐被清除，但仍然有一个问题悬而未决：模型的“可解释性”。
在过去一段时间里，Wayve、理想、Waabi等公司都宣称自己的模型是“可解释”的，但细究可发现，这几家说的“可解释性”，主要指面向用户的人机交互功能，而非学术界定义下的服务于产品开发/故障追踪的“可解释性”。
也许，在未来相当长一段时间里，学术意义上的“可解释性”都不能真正得到解决。不过，笔者在跟多位业内专家交流后认为，模型“可解释性”的进展，并不影响大家继续前进。
6.1 关于“可解释性”的三重定义
6.1.1 学术界对深度学习的“可解释性”的定义
学术界对深度学习模型的“可解释性”的定义，通常指的是“神经网络的推理过程能够被人类理解”。比如，对BEV感知的目标检测任务来说，输入图像上哪些像素和特征影响了对某个车辆的检测结果。
这意味着，模型的内部工作机制应该是透明的，或者至少可以通过某种方式进行解释，使得非技术专家能够理解模型为什么会产生特定的输出。例如，能够通过简单的规则、可视化或其他手段解释模型的决策过程。
可解释性也与因果性相关。解释模型的过程往往涉及理解输入特征如何影响输出结果，模型是否能够反映实际的因果关系，以及模型的决策是否合乎逻辑和经验。
追求这种可解释性的意义在于，帮助研究者理解模型的推理过程。但这类方法对产业界的应用价值还比较小。
6.1.2 产业界对模块化自动驾驶的“可解释性”的定义
现在，产业界谈端到端不具备可解释性时，通常也会提模块化算法的可解释性，但据辰韬资本执行总经理刘煜冬说，这个语境下的可解释性，跟学术界说的可解释性又不是同一个概念——
它指的是每一个模块的输入及输出，都是可以被观察到的，且推理的过程也是比较透明的；由于模块的分工比较清晰，因此，每一个模块的功能很容易被理解，出了问题也比较容易追踪。
尽管在出问题后也会遇到感知团队和决策规划团队互相踢皮球的问题，但最起码，在问题被定位清晰之后，究竟应该由哪个模块的人来解决，责任是比较清晰的。
6.1.3 产业界对端到端的“可解释性”的定义
Wayve关于“可解释性”的表述：
•LINGO-1视觉-语言-动作大模型是一款开环驾驶解说员，在具备生成驾驶行为评论和解说能力的同时，LINGO-1 还能够回答用户提出的有关驾驶场景的问题，帮助用户用自然语言理解模型的场景理解能力和推理逻辑。LINGO-2视觉-语言-动作大模型则更进一步，提供了驾驶模型决策过程的可见性。
•驾驶模型的语言解释让我们清楚地了解模型可能在想什么。然而，还需要做更多的工作来量化解释和决策之间的一致性。未来的工作将量化和加强语言、视觉和驾驶之间的联系，以可靠地调试和解释模型决策。我们希望在现实世界中展示，在“思路链”驾驶中添加中间语言推理有助于解决极端情况和反事实。
商汤关于“可解释性”的表述：
•动机解码器可用自然语言对多模态大模型的推理过程进行描述，输出一些决策信息，使得自动驾驶系统变得更加安全可靠可解释”。
•由于多模态大模型的出现，我们可以让模型在做出决策时，不仅是输出轨迹，还可以通过自然语言输出做出该决策的理由。这就像让ChatGPT来解析数学和物理题一样，不光是给到结果，而且要给出解题的过程。端到端大模型也可以做到这一点，它甚至可以发现当初做的某些决策是错误的，然后进行纠正。（商汤科技联合创始人、首席科学家、绝影智能汽车事业群总裁王晓刚在接受RoboX采访时说的）
鉴智关于“可解释性”的表述
•都大龙说：我们做端到端，也不是只输出一条轨迹，相应的动态目标、静态目标这些中间的感知的结果以及预测的结果，也会输出来。这些就是为了让模型具备可解释性。
多位受访的专家指出，目前，产业界对端到端自动驾驶的“可解释性”的定义，其实并不是模型本身的可解释性，它只是用大语言模型对端到端模型输出的内容做了个文字化的描述，但这个描述本身是否靠谱，也是很难说。
总的看来，产业界在提到端到端自动驾驶时说的“可解释性”，主要是通过可视化、过程透明来满足人机交互的需求，其主要目的是让机器的表现更像人，让用户对它有信任感。这样的“可解释性”，从产品设计的角度来看是很有价值的，但它跟学术界所说的“可解释性”不是同一个东西。 |
6.2 产业界不必被学术界的理念束缚
然而，我们在此前的报告中提到，大部分受访专家认为，缺乏学术意义上的“可解释性”并不会成为限制端到端模型应用的问题。主要原因有：
1.尽管端到端没有显式表达的中间结果，但是模块化端到端依然保留了各个主要功能模块，中间的特征输出可以被进一步提取为可解释的数据，帮助分析和理解模型是如何工作的。
2.对可解释性的担忧从AI在计算机视觉领域应用以来一直存在，但与其性能较传统算法的显著提升相比，可解释性成为一个次要考量因素。BEV感知解决不具备可解释性，但凭着性能的显著提升，它已经成为自动驾驶感知的主流技术方案，那端到端自然也不会受到可解释性的障碍。
端到端遇到的可解释性问题，比BEV会更严重一些——出现问题后，很难判定究竟是哪个环节出错了。不过，这个问题是可以通过更适合端到端的测试手段来解决的。
如鉴智CTO都大龙认为，死磕可解释性，可能还是停留在规则时代形成的思维里。“一个不具可解释性的黑盒，如果它的效果能够远远超越一个具备可解释性的白盒，那大家应该义无反顾都会选择那个黑盒。感知就是个最大的黑盒，但已经没有人讨论它的可解释性问题了。”
写到这里，笔者突然明白到，可解释性，并不是从自动驾驶从模块化转向端到端时才遇到的质疑，而是在从规则转向深度学习的过程中就一直需要面对的质疑。
由此看来，如果觉得“在可解释性得到解决之前就不能做端到端”的话，那么，在可解释性得到解决之前，就不能做用深度学习来做决策规划，而是依然用规则来做？甚至，在可解释性得到解决之前，感知算法也不应该用深度学习来做，而是用规则来做？如果是这样，那整个自动驾驶驾驶的技术栈就要回到三四十年前了。那我们干脆都把公司关掉算了？
零一汽车CEO黄泽铧说：
在遇到问题后，尽管不像规则系统那样容易解释，但一般的解决方案却是更加明确的——数据与算法；并且，这个解决方案的成本，要比原来的方案更低——原来的方案，尽管具有更强的可解释性，但解决单个问题的成本非常高。 |
而在都大龙看来，对可解释性问题，我们要分两个层次看：学界肯定是应该继续深究学术意义上的可解释性的，但更工业应该更多地从产品如何让用户放心的角度考虑。“如果我通过输出一些中间的结果，能够让用户更加放心，那就足够了。”
综合下来，笔者的结论是：可解释性的问题短期内很难解决，但产业界不必等这个问题彻底解决之后再投入实践。
不过，笔者还有一个疑问：假如学术定义下的可解释性问题没有解决的话，那端到端自动驾驶系统出了问题之后，追踪或者修复的难度是不是要比规则时代还要大很多？
对这个问题，都大龙的解释是：
不会。只要这个数据能够保存下来，在遇到问题后，我们就可以去做一些针对性的分析，虽然没法分析到究竟是哪块出现了问题，但肯定能够确定是这个模型出现了问题，然后，再把数据灌到模型里去训练，最终把这个 case 解决掉。 |
当然，只要条件允许，工业界还会尽量去追求学术定义下的可解释性。
7. 落地路径： 渐进式还是跨越式？
端到端将以怎样的路径在自动驾驶场景中落地？
笔者在跟多位从业者交流之后发现，在对原有技术积累的态度、技术架构的选择、对端到端系统的定位、对功能的覆盖、对场景的选择等多个层面上，端到端的落地节奏均分为渐进式和跨越式两种。
7.1 对原有技术积累的态度：是在模块化自动驾驶技术积累的基础上发展端到端，还是一步到位做端到端？
尽管大家都认可传统的模块化自动驾驶技术积累对做端到端的重要性，但因公司历史积累/历史包袱的不同，有的公司选择从传统自动驾驶过渡到端到端，还有些公司选择一步到位进入端到端自动驾驶。
A.渐进式——在继承传统自动驾驶能力积累的基础之上发展端到端
多数从业者认为，尽管端到端被认为是对传统自动驾驶技术路线的颠覆，但这并不意味着要对过去彻底“推倒重来”。
此前，42号车库援引一位从事自动驾驶算法研究的行业专家的观点称：
从行业落地的角度来看，特斯拉做端到端，并非是把以往的 FSD 算法成果完全抹去从头再来、从零开始，而很有可能是基于以往的算法成果进行了算法框架的结构性调整。 |
知乎博主EatElephant也在一篇文章中提到一个问题：端到端是对之前技术的推倒重来？
对这个问题，作者给出的答案是：
FSD V12保留了几乎所有之前的可视化内容，这表明FSD V12是在原本强大的感知的基础上进行的端到端训练，从2020年10月开始的FSD迭代并没有被抛弃，反而是成为了V12坚实的技术基础。 Andrej Karparthy之前也回答过类似问题，他虽然没有参与V12的研发，但他认为所有之前的技术积累并没有被抛弃，只是从台前迁移到了幕后。 所以，端到端是在原有技术基础上一步步去掉个部分的规则代码逐渐实现的端到端可导。 |
商汤绝影智能驾驶副总裁石建萍也持类似观点：
无论哪种技术路线的端到端，都需要有一些传统架构下的经验和方法论。比如，拐弯失败了，我们就得看系统输出的轨迹是不是合理、感知的信号有没有问题。在分析这些问题的时候，我们还是得用一些原来的方法论。 |
B.跨越式——跳过传统自动驾驶阶段，直接做端到端
尽管，基于传统自动驾驶技术积累发展端到端已是行业共识，但如果一个公司之前并没有启动传统自动驾驶技术研发，凑巧，在端到端趋势来临之前，他们刚好打算启动自动驾驶研发，那么，这个时候，他们是仍然要先做一套传统自动驾驶的东西“积累经验”，还是可以一步到位——直接做端到端呢？
对这个问题，零一汽车给出的答案是：一步到位做端到端。
在5月中旬的发布会上，零一汽车CEO黄泽铧说：我们没有尝试过任何传统的自动驾驶路线，所有资源都在集中在端到端，也做出来了成果。
当然了，零一跳过传统自动驾驶直接做端到端，好处远不止是资源更聚焦。
通常来说，自动驾驶的技术路线从模块化转向端到端，必然要经历人员与组织架构的调整，而历史包袱越重，调整的阻力就越大。远川汽车频道熊宇翔在一篇文章中提到：
在这个过程中，有一个不容忽视的矛盾是，理论上对智驾表现最终负责的是规控负责人，但由于技术分工的历史沿革，大多数智驾企业中更懂神经网络的往往是感知负责人。在端到端的趋势下，以传统算法为核心工作的规控部门容易被整合、降权或者优化。 |
相比之下，零一越过传统自动驾驶直接做端到端，最明显的收益是：可以轻装上阵，不用耗费精力去做组织架构的调整，更不用耗费精力去应对组织变革所带来的一系列人事问题上的矛盾。
当然了，零一自动驾驶团队的成员们之前也都在其他公司做过传统自动驾驶。因此，可以说，在公司层面，零一是跳过传统自动驾驶直接进入到了端到端自动驾驶；但从技术人员个人的角度来看，大家仍然是继承了之前做传统自动驾驶时积累的能力。这相当于把跨越式路线和渐进式路线的优势都发挥出来了。
7.2 对技术架构的选择：先做模块化端到端，还是一步到位做One Model端到端？
多数从业者认为，模块化端到端只是一个过渡方案，One Model端到端才是终局。那么，究竟应该是走渐进式路线，先做模块化端到端，还是应该走跨越式路线，一步到位做One Model端到端呢？不同公司的选择不同。
A.渐进式——先做模块化端到端，待时机成熟时再做One Model端到端
本文在2.1.1里面已经提到，小鹏、华为、大疆、商汤等均选择了模块化端到端。
先从模块化端到端做起的好处显而易见：
•有UniAD的开源方案作为参考，上手比较快；
•可以最大限度地继承传统自动驾驶架构的很多经验和方法论（如由于大的架构比较一致，所以，BEV感知模块的很多知识就可复用）；
•“可解释性”问题没有One Model端到端严重，出问题后更方便溯源（跟下图中提到的“阶段二”差不多）。
鉴于关注可解释性问题的人特别多，我们在这里稍微展开一下。
据辰韬资本执行总经理刘煜冬介绍，模块化端到端中，尽管感知和决策规划之间是用神经网络连接的，但如果需要对模型的中间结果做解释，是可以把隐式表达特征转换成类似于上图阶段二中的人为定义接口的，然后就可以分模块做测试验证了。
简单地说就是，模块化端到端方案，在需要做故障回溯时可以在一定程度上进行“白盒化调整”。
此外，系统架构师达木在 发于《汽车电子与软件》上的一篇文章中解释“为什么选用模块化端到端”的原因时说：
规控有很多的功能交互逻辑，涉及到车道线等感知输入、用户和故障聚类后处理，不一定难，但是需要大量的时间积累，打磨和完善的，如果直接token，这些逻辑如何设置和验证代价其实不小，最好的方式就是先优先解决关键问题，逐步过渡。 |
简言之，先从模块化端到端起步，可以避免在经验不足的时候就被规控环节复杂的功能交互逻辑设置和验证工作给绑架。
不过，特别有意思的是，笔者发现，有几家公司，从官方在之前公布的信息可以判断，他们做的是模块化端到端，但正儿八经地去聊，他们又都会改口说是One Model，但这种One Model又提到了感知和决策规划的“单独训练”——这实际上仍然是模块化端到端。 看来，对这些公司而言，模块化端到端已经成了一种“我正在做这个，但我不好意思让别人知道我做的就是这个”的方案了。莫非，这是变相地承认，模块化端到端不如One Model端到端了？ |
尽管One Model端到端存在遇到问题后更难追踪（黑盒化程度更高、更难解决“可解释性”问题）等挑战，但理想、蔚来、零一等公司却依然坚持一步到位做One Model端到端。
因为，模块化端到端仍然保留了之前的模块化架构的痕迹，提升有限，相比之下，One Model端到端的最终效果则具有更高的天花板（至少在理论上如此）。具体原因如下：
•由于彻底取消了模块划分，信息损失的问题就被彻底消灭；
•对数据标注的需求比模块化端到端少许多；
•具有更强的泛化性。
One Model端到端具有比模块化端到端更强的泛化性，这一点特别重要，但究其原因，公开的文章里很少涉及。在这里，笔者将做个简单的解释：
One Model端到端之所以具有更强的泛化性，是因为它掌握了更多的常识。而One Model端到端之所以掌握了更多的常识，一方面，是因为它可用的训练数据更广泛；另一方面，则是因为它可以更好地跟已经训练得很成熟的大语言模型相结合。 |
先说说训练数据的问题。
模块化端到端方案，由于BEV Featrure无法处理声音信号、无法处理车辆的状态信息，所以，实际可用的数据维度有限（主要就是图像类数据）。
而One Model端到端，由于没有把数据强行划分为感知类数据和决策规划类数据，所以，无论具体的技术路线是哪种，都可以将更多维度、更广范围的数据纳入训练系统，因而，学到了更多的常识。
这里说的“更多维度，更广范围”是指，One Model端到端的训练数据包括不仅包括摄像头、毫米波雷达等传感器的信息，而且还包括车辆所有的状态信息、某个事件发生前10秒的信息，甚至还包括了大量来自非驾驶场景的数据。
再说说跟大语言模型结合的问题。
模块化端到端不能很好地跟大语言模型结合，因为，不能用所谓的“中间输出”将大语言模型分割成两段——如果勉强把大语言模型跟感知或规控结合起来，那就相当于“高射炮打蚊子”，并不能将大语言模型的优势充分发挥出来。（零一汽车CEO黄泽铧的观点）
而One Model端到端则可以将多模态大语言模型的优势更充分地释放出来，因而，可以学到更多的常识。
相比于上述一系列优点，“不可解释性”只能算是“次要矛盾”，因而，“不可解释性”并不足以成为大家继续One Model端到端的障碍。 |
不同的公司对端到端系统的早期定位是不一样的。比如，有的公司认为，端到端系统应该先做影子模式、冗余系统，等条件成熟之后再做主系统；但还有的公司认为，端到端应该一步到位做主系统。
A.渐进式——端到端先做影子系统、冗余系统，等条件成熟之后再做主系统
关于这个观点，公众号“雪岭飞花”在一篇文章中已有比较详细的阐述。这篇文章指出， “端到端”模型在车上落地会分为三个阶段——
1）第一阶段：“端到端”模型的下限会低于行车安全限值，仅依靠“端到端”模型会带来安全风险。此时“端到端”模型需要以影子模式运行，或者和规则同时运行，规则负责安全兜底（负责什么行为不能做），“端到端”模型负责探索性能上限（负责什么行为可以做）。该阶段中，“端到端”模型主要以隐式连接的“Two Model”方案为主。
2）第二阶段：“端到端”模型的下限高于行车安全限值，但是仍然低于规则。该阶段中，传统模型比重逐步降低，兜底策略逐渐减少。该阶段中，“端到端”模型已经有“One Model”方案应用，随着数据量的累积，算法性能不断提升。
3）第三阶段：“端到端”模型的上限和下限均高于规则。该阶段中，传统模型彻底取消，自动驾驶仅依靠“端到端”模型，实现彻底的数据驱动。不过，在冗余度要求较高的L3/L4系统中，两种系统仍然有可能共存，互为备份冗余。
据黄泽铧在发布会上讲的内容，零一的端到端落地，也是先从跑影子模式开始，然后再逐渐升级为主系统。
B.跨越式——端到端应该一步到位做自动驾驶的主系统
特斯拉、小鹏等并未公开提及其端到端系统的落地是否先从跑影子模式开始，因此，是否存在一步到位直接用端到端系统做主系统的案例，我们暂时还没有答案。
7.4 对功能的覆盖，是分模块，还是一步到位？
在一些公司的理解中，端到端技术应用于自动驾驶的不同功能的难易程度并不相同，所以，他们会选择先从最容易落地的功能切入，然后再依次拓展到最难的功能；还有一些公司，则是一开始就直接用端到端做更难的功能。
A.渐进式：先实现某一两个功能模块的“端到端”，再逐步实现整套功能的“端到端”
这种做法的典型代表是蔚来。7月中旬，在发布“端到端”AEB时，蔚来宣称自己走的是“渐进式端到端”路线，后续将逐一完成各功能模块的“端到端”，并组装为端到端的完整拼图。
多位业内专家都指出，用端到端做AEB这种做法并不常见，并且，可能意义也不大。“这种很基础的功能，拿规则写就行了啊。”
笔者想起，某明星自动驾驶公司，此前曾有一段时间把数据驱动当成“宗教”、当成“政治正确”，甚至连AEB也用数据驱动来做。结果，效果做得特别差，并导致产品交付延期6个月。
在笔者看来，AEB目前的痛点并不是“上限不够高”（漏检），而是“下限太低”（误报率太高），用端到端去做AEB，肯定会提高AEB的上限，但会不会也进一步拉低了其“下限”？
据大蒜粒7月11号在微博上发的速记，蔚来在发布“端到端”AEB时，宣称“端到端”的应用在使得AEB的场景覆盖率提升5倍的同时，误报率几乎没有增加。这里的“误报率几乎没有增加”的潜台词是，误报率确实是“有一点点上升”，即下限“降低了一点点”？
如此看来，用端到端做AEB，会不会是“捡了芝麻丢了西瓜”？
B.跨越式：一步到位实现整套功能的“端到端化”
大部分公司都直接拿端到端做行车功能，也有一些公司用其做泊车功能。
7.5 对场景的选择：需要由易到难，还是可一步到位做最难的？
端到端自动驾驶技术在不同场景中落地的难度并不相同，但在落地场景的顺序选择上，各家的策略并不一样：有的公司选择由易到难，有的公司选择一步到位做最难的。
A.渐进式：先从比较简单的场景开始，再逐步拓展至复杂场景
这里讲的“渐进式”，是先将端到端技术应用在落地难度比较低的场景，再逐步向比较难的、更难的场景拓展。
有意思的是，哪个场景算是“简单场景”，哪个场景算是“复杂场景”，答案并不是固定的，而是有“时代性”的。
比如，在决策规划还用规则来做的阶段，高速场景比城区场景简单（需要写的规则更简单，数量也更少）；但在决策规划用深度学习来做的阶段，高速场景就比城区场景更复杂（高速场景，更难以承受深度学习算法带来的“不确定性”）。
所以，我们看到，特斯拉等多家主机厂的端到端，都是先从城区NOA开始，避开了高速场景——特斯拉的FSD，在高速场景下依然会切换到V11的方案。
零一汽车CEO在5月份的发布会上提到，场景渐进是商用车自动驾驶发展的有效途径。零一的端到端落地，也正是先从封闭区域（矿区）开始，然后再拓展至半封闭区域（短倒专线、高速专线等），再逐步拓展到开放场景（国道、高速公路）。
零一将端到端自动驾驶从封闭场景向半封闭场景、再向开放场景拓展的计划，底气主要在于One Model端到端的跨场景泛化能力。
One Model端到端具备更强的跨场景泛化能力的原因，我们在本文的7.2那有一小节里已经解释过：其训练数据涵盖了大量驾驶场景之外的数据，甚至是大量人类社会的常识；并且，它还可以跟多模态大语言模型（也涵盖了人类社会的大量常识）结合。
由于海外的作业场景往往跟国内有很大差异，因而，出海也是跨场景的一种特殊形。这意味着，就技术层面而言，今后，使用One Model端到端方案的自动驾驶公司有更强的出海拓展业务的能力。
对商用车无人驾驶来说，拓展场景，往往同时也意味着要拓展到新的车型；并且，对零一来说，自动驾驶不仅用在自家的车上，还用在生态联盟中的一些合作伙伴开发的车型上。这一计划又得益于One Model端到端的跨车型泛化能力。
那么，One Model端到端为什么具备更强的跨车型泛化能力呢？
除了对人类社会常识的充分吸收外，One Model端到端还可让信息实现完全无损的传递，因而能够把自车和障碍物的关联关系，他车障碍物（交通流）的关联关系，障碍物和地图的关联关系，以及历史经验和未来预测的时空关联关系，按照已有的六自由度位姿信息无损传递，有效利用起来。（摘自系统架构师达木发在“汽车电子与软件”上的文章）
当然，跨车型泛化能力，主要是指在形状、尺寸等大体相当的车型之间的泛化，也就是， “乘用车跨乘用车”、“商用车跨商用车”，而不包括乘用车跨商用车。这意味着，One Model端到端并不能成为助力乘用车自动驾驶公司向商用车场景迁移的武器。
此外，抛开技术的泛化能力不说，在战略层面，这种从简单场景逐步向复杂场景迁移的“农村包围城市”之路也具有非同寻常的意义。
前段时间，在零一内部的一次战略会上，有位合伙人问黄泽铧：端到端系统是一个上限特别高的东西，我们为什么要将它应用于矿区这么简单的场景？
对这个问题，黄泽铧是这么解释的：
如果一上来就做一个比较大的端到端系统，然后去做复杂场景的业务，一旦出错了，纠错成本会非常高；甚至，我们都不知道自己错在哪了。但先找一个要求低、确定性高的场景做出一款可用的产品，有利于快速实现研发系统、产品系统的闭环，并实现商业闭环，这对我们打磨团队的价值是非常大的。 任何一个闭环都是不简单的——即使这个场景是简单的，闭环的过程也是不简单的，而在这个闭环的过程中，我就可以了解到哪些事情做对了、哪些事情做错了，哪些人很优秀、哪些人不合适。 |
可见，有了在简单场景中完成闭环的经历，零一在迈向下一个阶段/向更复杂的场景拓展就时，就能少踩不少坑。
B.跨越式：一步到位做最复杂的场景
前面说过，在数据驱动的时代，高速场景其实是最复杂的场景，对这个场景，乘用车自动驾驶公司在做端到端方案时都避开了。
那么，有一步到位用端到端做高速场景的公司吗？ 干线物流赛道的无人驾驶公司，车辆的主要驾驶场景就在高速路上，因而，这些公司如果做端到端了，大概率就是一步到位直接做高速场景。
8. 对兜底策略的思考
由于彻底取消了规则（连做为接口的规则也取消了），端到端让已经习惯了规则所带来的确定性的人们难以适从。因而，一提到端到端，大家总会本能地想到“兜底策略”。不过，关于兜底策略，仍存在不少争论。
8.1 关于“要不要用规则兜底”的争辩
A.主张用规则给端到端兜底
特斯拉、Wayve还是理想，都在用/会用规则给端到端系统兜底。特斯拉的兜底策略，是升级版的AEB；Wayve的兜底策略，除了占用网络和VLM，还有一套用于检查系统的安全性的规则；理想的兜底策略，据说是在端到端模型后面接了一个时空联合规划的安全策略——这个安全策略，其实就是规则。
主张用规则来给端到端兜底的原因很简单：深度学习的下限比规则低、端到端到的下限比模块化自动驾驶低。
深度学习模型并不具备像人一样的认知能力——它的学习方式归根结底是死记硬背，哪怕把题做对了，往往也是“知其然，但不知其所以然”；事实上，深度学习模型很容易把相关性混同为“因果关系”。
去年年底，一位先后在主机厂及头部自动驾驶公司做过规控算法工程师的朋友跟笔者举过这样一个例子：
我们做测试的时候发现，明明模型是同一个，但白天测还是晚上测，系统的表现不一样。比如，白天无论路边的障碍物多少，车都开得慢，但晚上开得贼快。 原因是，在模型最初的训练数据中，白天车很多，晚上车少，然后，系统就理解成了“白天应该开快一点，晚上应该开慢一点”，而不是“高峰期应该开慢一点，车少时应该开快一点”。 |
这个例子中的自动驾驶系统，并非端到端系统，而仍然只是模块化系统，但决策规划已经使用了深度学习模型了。显然，这样的深度学习模型，如果没有规则兜底，肯定会有很多用户不敢放心地使用。
到了端到端阶段，由于连以接口的形式存在的规则也取消了，那系统的不确定性势必进一步上升，也就是说，尽管上限更高了，但下限也更低了——至少在短期内如此。
关于终端用户对端到端系统“上限更高了，但下限也更低了”的接受度，Naiyan Wang此前在《聊聊端到端与下一代自动驾驶系统，以及端到端自动驾驶的一些误区？》一文中特别强调：
一个自动驾驶系统想要让大众和舆论接受，关键可能不在于一个绝对的事故率和致死率，而是在于对于一些人类司机可以“轻松搞定”的场景，如果机器会犯错，那公众能否接受？ 这个需求对于纯端到端系统来说更难以实现。 |
对这个观点，笔者深有同感。
但为什么自动驾驶行业里的专家在讨论大众对一个自动驾驶系统的接受度时，往往只拿事故率、系统性能的上限说事儿，却对系统的下限及消费者的主观感受避而不谈呢？ 原因很简单——行业里的专家大都是“直男”，他们忽略了了一个问题：舆论是感性的，甚至是“不讲理的”。 |
在上述文章里，Naiyan Wang结合Deepmind于今年2月份发的文章（Grandmaster-Level Chess Without Search https://arxiv.org/abs/2402.04494）认为，在解一些困难的残局上，纯数据驱动性能非常糟糕。需要多步博弈的困难场景或corner case，仍然很难完全抛弃掉传统的优化或者搜索算法。
言外之意是：需要用规则来给端到端兜底。
而在另一篇文章中，Naiyan Wang更是直接提到，用规则兜给端到端模型兜底，其实是自动驾驶行业里的常态。
以我有限的了解，目前所谓端到端模型在行车中使用的时候，在输出的轨迹之后都会去接一个基于传统方法兜底的方案，或者是这样的learning based planner和传统的轨迹规划算法会同时输出多条轨迹，再通过一个selector来选择一条执行。 |
商汤绝影智能驾驶副总裁石建萍在接受笔者采访时说，商汤的安全兜底策略，相当于一个“升级版的AEB”。
“端到端的模型上线之前一定会有 ‘护栏’。它像是未来会成为博士的学生，但成长过程中需要小学、初中老师去带，需要时间成长。” 英伟达汽车事业部负责人吴新宙认为，端到端模型成为主流之前，还需要和原有模型配合工作，保证安全。
石建萍所说的“升级版的AEB”及吴新宙所说的“原有模型”，应该就是指规则。
在此之前，商汤绝影总裁王晓刚也曾提到，现阶段，智驾行业并不存在一个纯神经网络的量产方案，为了给安全兜底，要么选择端到端与传统方案并行，要么是在端到端网络后接一些后处理模块或者强安全的代码。神经网络的进与规则的退会是一个渐进的过程。（摘自远川汽车熊宇翔的文章）
通常，兜底系统也不是从零做起的，而是基于原有的某个规则系统修改而来。
B.不赞成用规则给端到端系统兜底
当然，用规则兜底也有一系列弊端。
首先，被抨得最多的是，规则兜底会拉低系统性能的上限，导致端到端的优势被牺牲。
比如，知乎博主EatElephant就在一篇文章中提到：
无论是感知后处理代码，还是规划的候选轨迹打分，甚至是安全兜底策略，一旦引入了规则的代码，有了if else的分支，整个系统的梯度传递就会被截断，这也就损失了端到端系统通过训练获得全局优化的最大优势。 |
某无人驾驶公司感知算法总监的观点也与EatElephant类似：
做端到端模型，无法就是要做能超越模块化方案的一套东西，如果你设计又这么一套规则给它兜底，这不就是会牺牲掉端到端模型所带来的一些优势吗？ |
Naiyan Wang也在知乎上的博文中提到：
如果这样设计系统架构（用传统规则方法兜底），则系统的性能上限其实是被这样的兜底方案和selector限制住的。 |
8.2 规则和模型之外的第三条路：原则
去年年底，一位自动驾驶公司的规控算法工程师在跟笔者交流时说：“在模型和规则之外，应该还有第三路：原则”。
相比于模型，原则也是用来解决确定性比较高的问题的，这点它比较接近规则，但原则要比规则更抽象、也更具有灵活性。
这位工程师举例解释道：
比如，车从这条路上往过走，“原则上不准压线”。即如果不压线也能通过，我就尽量不压线；但如果不压线就过不去，或者很危险，那我就就可以压线。 |
什么时候该坚持“原则的坚定性”，什么时候该坚持“策略的灵活性”，这已经超出规则的能力范围了。似乎，只有消化过足够多的场景数据的AI才能具备这样的能力？
那么，用AI来给本身就是AI的端到端模型兜底，是否可能？这个问题，我们暂时还没有答案。
8.3 关于“用能力更弱的系统给能力更强的系统兜底”
在跟零一汽车CEO黄泽铧交流的过程中，笔者还提出了这样一个困惑：
有个比较麻烦的地方是：尽管两者都不完美，但总体上，端到端系统是一个综合能力更强的系统，而兜底系统是一个综合能力更弱的系统。 在公司里，通常，上司的能力比下属强，对下属搞不定的问题，上司帮给他们兜底，这是一个比较正常的逻辑；但在谈端到端到时候，我们却希望让一个能力更弱的系统给能力更强的系统兜底。 那么，一个能力更弱的系统，能否及时检查出来能力更强的系统“要掉链子了”并及时给对方纠错？我们是否需要给兜底系统也做一个兜底系统？ |
对这个问题，黄泽铧的看法是：
要限制兜底系统的责任——让它成为一个专家系统，只关注并处理一些极为有限的任务，但在这些有限的任务上又绝对不会出错。这个专家系统的能力，最好能被抽象为原则（比规则具有后更强的通用性）。比如，“在这些场景下，卡车的方向盘不应该转180度”。 |
8.4 注意避免兜底系统跟主系统同时失效
智加首席科学家崔迪潇提到了如何避免兜底系统跟主系统同时失效的问题：
•兜底系统需要跟主系统有方法论上、架构上的差异，这样才可以避免在同样的问题上失效。
•兜底系统的开发团队应该跟主系统的开发团队相互独立，并且，这两拨人平时要尽可能少交流。因为，一交流，就会把一些东西共享，这样，两个团队对一些问题的假设就会一致，而这种一致就会导致，在最极端的情况下，兜底系统可能会跟主系统同时失效。
零一汽车CEO黄泽铧也表达崔迪潇类似的观点。“端到端系统，理论上，应该是一套跟主系统垂直的东西。”所谓垂直，就类似于崔迪潇提到的“架构上有差异”，甚至还要“开发团队相互独立”。
8.5 不必过分依赖兜底系统
不过，黄泽铧认为，目前，整个行业还没有到谈"如何给端到端兜底"的阶段。
黄泽铧说：
可以谈兜底的前提是，端到端作为主系统已经足够成熟了，它的问题究竟在哪里已经很清晰了，然后，兜底策略就可以设置得很有针对性。 而现在谈兜底，遇到的问题是：如果我能说得出来端到端作为主系统的问题在哪里，我为什么不能直接在原系统里解决它；如果说不出来，那我该“兜怎样的底”呢，我又怎能知道如何避免兜底系统跟端到端系统同时犯错呢？ |
黄泽铧认为，在当前阶段，如果端到端系统出问题了，我们的第一反应应该是，如何在端到端系统里直接把问题解决掉，而不是靠兜底系统来解决。
去年年底，某先后在主机厂和头部算公司供职过的规控算法工程师在跟笔者交流时说：
用规则来给模型兜底，如果模型输出来的结果不对的话，在追责的时候，大家的第一反应不会说“模型没做好”，而是会说“用来兜底的规则没做好”；但如果模型没做好，而下游规“把底给兜住了”，那做模型的人可能都不会意识到“模型没做好”。 |
也就是说，如果搞砸了，锅都是兜底规则的；但如果做好了，功劳都是模型的。这已经不是一个纯技术问题，而是管理问题了。
笔者也很认同这一观点，因为，从人性的角度看，如果过分依赖兜底系统，就会让主系统的开发团队有“我做不好也没关系，有人给我们兜底”的侥幸心理，因而可能会松懈——毕竟，大多数人都是在“没有人给我兜底”的时候才会有足够的使命感。
9. 【未尽之语】比技术更值得探讨的，是游戏参与者们的思维方式
9.1 关于侯晓迪对端到端的质疑
侯晓迪最近有个抨击端到端的观点：
现阶段，端到端还是一个需要老师傅手工打磨的一个工艺，并不是完全输入信息，输出结果的自动工厂。如果哪些细节性能需要提升，先把网络其他无关部分冻结，然后“喂”数据训练，再不断训练、测试迭代。这个逻辑很像初中物理学的控制变量。最后结果是不是像人们想象的那样，还不确定。 |
笔者在向多方请教之后确认，侯晓迪的说法是属实的。
不过，所有受访者也都提到，“先冻结一部分变量”是做几乎所有物理学实验时都要遵循的方法，BEV感知模型的训练也不例外，因此，这种手段本身并没有什么可以被指责的地方。
所以，如果侯晓迪提到的“需要先冻结一部分变量”足以成为“端到端不可行”的理由的话，物理学界、经济学界几乎所有的研究都不能做了？
9.2 在一件事情尚未形成共识的时候就“为它而生”的团队，会更有竞争力
八年前，笔者从喜马拉雅创始人兼CEO余建军口中听到这么一句话：“在创办喜马拉雅之前，我做了很多调研，发现大多数人并不看好做个音频类APP，这个反馈，让我挺兴奋的。”
这句话，对笔者有很大的启发性。笔者由此得出一个结论：对自己做的事真正有认知的人，是敢于“违反共识” 的。
在国内自动驾驶行业，综合竞争力最强的两家初创公司是地平线跟禾赛，恰好，这两家家公司的创始人也是对“敢于反共识”强调比较多的老板——
•余凯在2015年那个时间点做AI芯片，就是反共识的；实际上，“反共识”是余凯的思维方式的一部分——我不仅在地平线的办公室看到过印在彩色纸上的“反共识”，而且，还看见过余凯给别人点赞时称对方“反共识”。
•李一帆则在2024年4月的一次发布会上列举了“禾赛历史上做过的几件反共识的事情”。事后看，禾赛能取得今天的成绩，在很大程度上就源于核心团队在当年“敢于反共识”。
零一汽车CEO黄泽铧，也是这样一位“敢于反共识”的老板。
在5月中旬的产品发布上，黄泽铧口说：“2023年底，我跟行业里很多人聊,大家当时普遍不太看好端到端，但我们很看好，于是就坚定地投入资源去做。”（是不是跟余建军那句话很像？）
对大多数人在当时并不看好端到端的理由，黄泽铧的解释是：
对一个新的技术，它的问题，我们能看出来100个；而它的好处，其实是需要等这个系统真的做出来以后才能看到的。” |
上纲上线地说，“敢于反共识”的先行先试者们通常都是“因为相信，所以看见”；而观望者们则是“只有看见了，才肯相信”。
商界的实践已经一次又一次证明了一点：相比于“只有看见了，才肯相信”的人，那些“因为相信，所以看见”的人更容易成功。原因有如下几点：
1.在一个事情在大众眼里还“未形成共识”的时候就敢去做，意味着创始人乃至整个核心团队往往具有较强的洞察力、具备遥遥领先于他人的认知，能提前看见别人看不见的东西。
2.在大多数都对这个事情不看好的时候就敢投入、并且还能坚持做，甚至，哪怕明知自己投入过早有可能成为“先烈”也在所不惜，那么，这个公司的创始人甚至核心团队，一定是有很强的理想主义情结、并且有很强的战略定力。
3.在大多数人都对这个事情不怎么看好的时候却专门为了这件事组建了一个团队，这证明，老板的画饼能力（描绘使命和愿景的能力）超强，这样的老板，不仅具备强大的沟通能力，甚至还具有强大的心力，在日后，几乎没有任何困难可以阻挡他们胜利前进的步伐。
4.在大多数人都对这个事情不怎么看好的时候就成立的团队，被迫在市场对这个事情还处于早期的时候就去做用户教育，那他们的首批用户，一定是对新鲜事物的接受度很高、且对他们犯的错误包容度很高的人；这批绝对优质的客户，会在相当长一段时间内陪伴该公司发展，给他们提供高质量的反馈，帮他们迭代产品。
9.3 悲观者往往“更正确”，但乐观者更容易成功
这一小节的内容，本来是应该放在第三章（“落地的障碍逐渐被清除”那一章）的开头的，但笔者在修改的过程中越看越觉得本节内容的重要，就将它调到结尾处来“压轴”了。
在看一些技术博客及采访交流的过程中，笔者无意间了一个有意思的规律：总体上，对端到端的落地前景，技术一线的人更习惯于“摆困难”，甚至是比较悲观；而老板们则更习惯于看收益，以及有哪些障碍已经被消除，还有哪些障碍虽然尚未被解决但其实是有办法解决的。
原因应该是这样：一些技术人员因为“知道得太多”，所以更容易被困难吓倒；而老板们“反正不懂”，所以更容易“无知者无畏”。 |
•消极的人看到的都是困难，积极的人看到的都是办法。
•悲观者往往正确，但乐观者往往成功（准确地说，是“乐观者更容易成功”）。
不过，将对端到端的前景的两种态度简单地定性为“技术人员与老板的不同”，并没有触及问题的本质；并且，上纲上线地将技术人员说成“消极的人”“悲观者”，而将老板说成“积极的人”“乐观者”也不准确。
那么，问题的本质是什么呢？这其实是纯技术思维与商业思维的对比——哪怕同样是做技术的人，商业思维强的技术人员，也要比只懂技术的人更积极、更乐观。
关于纯技术思维与商业思维的对比，笔者在此前的文章中已经说过不少，在这里再摘录两段：
•纯技术思维的人，习惯自我设限。在做一件事情之前评估的重点并不是这个事情“有没有必要做”，而是“条件是否成熟”“我有没有这个能力”，那么，哪怕这个事情“非常有必要做”，但只要他在主观上认为“条件不成熟”“我没有这个能力”，那他就可能放弃。
•商业思维强的人，习惯于以终为始。在做一件事情之前评估的重点并不是“条件是否成熟”“我有没有这个能力”，而是“有没有必要这么做”，那么，一旦认为“有必要做”，哪怕他并不具备这个条件/能力，他就会加紧创造条件、培养能力，然后把它给做出来。
思维上的这种差异又会进一步导致结果上的差异——
•纯技术思维的人往往是先用条件/能力锁死目标，再用目标锁死条件/能力——这意味着，他们不仅会因为暂时的条件不成熟/能力欠缺就放弃比较高的目标，而且，还会因为目标过低而导致条件/能力得不到发育的机会。
•相反，商业思维强的人则往往是先设定一个自己最想要的目标，再让条件/能力则会跟着目标而发育/成长；等条件/能力提升后，他再设定更高的目标，带动条件/能力的新一轮发育/提升。
那么，为什么纯技术思维的人习惯于自我设限，而商业思维强的人更习惯于以终为始呢？笔者的答案是这样的：
•纯技术思维的人，在看问题时，思维往往是静态的——只要有个困难当下无法解决，他就觉得那个是“巨大的困难”；只要当下还欠缺某个条件，他就觉得不“这事儿搞不了”。
• 相反，商业思维强的人，看问题是，思维是动态的——现在遇到的困难，如果在未来某个确定的时间点之前能解决，他就不再认为那是困难；现在不具备的条件，两三年之后能搞定，他就觉得“这事儿可以干”。
通常，在同一家公司里，纯技术思维的人要被商业思维强的人“指挥”；而在公司与公司之间的竞争中，纯技术思维的老板领导的公司是“鱼肉” ，而商业思维强的老板领导到公司则是“刀俎”。一个关键原因就藏在本小节的内容里。 |
3.3和3.4两个小节里都谈到了在端到端模型训练中引入合成数据的必要性。在这里，我们再跳出技术本身，从人的思维方式的角度再做一些延伸。
尽管特斯拉及理想等尝鲜者已经从对合成数据的使用中尝到了巨大的甜头，但还有更多公司的技术工作者们仍然是将信将疑。
最根本性的原因在于——
螺丝钉们普遍只关注对具体的知识和技能的学习，却对认知的提升并不怎么关注。而不关注认知提升的人有一个共同点是：只相信蛮干，所以就一直沉迷于各种低质量的勤奋，并为之感到自豪；他们甚至连“机智地偷懒”的意识都没有。
毫无疑问，合成数据就是擅长“机智地偷懒”的人的一个重要法宝。
事实上，在学习合成数据的过程中形成的思维方式，已经成为笔者解释学习效率、工作效率、洞察力等问题的“第一性原理”。 |
先看看这个：古人常说的“读万卷书，行万里路”，其实就是合成数据跟真实数据的关系。
行万里路的过程是“积累真实数据”，而读万卷书的过程则是是“使用合成数据”——书中，传递的是作者积累的数据和相关算法，而在读者的角度，作者的算法其实也是读者用来训练算法的“数据”而已。
康德一生都没有走出他生活的那个小镇，却最终成为成为哲学大家。这其实就是使用少量真实数据+大量合成数据来做思维训练的结果。
笔者自己既没有行过万里路，也没有读过万卷书（读书少得可怜，连“百卷书”都达不到），等于对真实数据和合成数据掌握得都比较少，但认知水平并不输于很多读了万卷书的人。因为，笔者读书时基本只读“哲学味”比较浓的书——这种合成数据的特点是“泛化能力强”。
为什么“读万卷书”在“行万里路”的前面？因为，如果没有读万卷书，一个人哪怕行了万里路，也只是相当于一个邮差而已。同理，一个人如果不善用合成数据，但他所收集的真实数据，也大都是死数据，利用率有限。这样的人，也不可能有大的作为。 |
在此前的《管理者如何训练出“花一秒钟就看透事物本质的能力”？》一文中，我提到这样一组观点：
1.洞察力的本质是，“无需很多真实数据就能快速做判断，并得出一个相当靠谱的结论”。
2.在真实数据有限的情况下还能提出高质量的结论，需要有演绎法思维。
3.演绎法思维的精髓是“小样本泛化”，小样本泛化的精髓则是“用合成数据弥补真实数据的不足”。
把这几项结合起来，我们就可以得出这样一个结论：有洞察力的人跟没有洞察力的人的最根本区别就是，是否掌握了使用合成数据的能力。
可见，多数人之所以哪怕花一辈子也看不透事物的本质，就是会因为他们缺乏使用合成数据的能力（甚至缺乏时使用合成数据的意识）。
9.4.3 “道理懂了很多，可依然过不好这一生”的最根本原因是：不擅长使用合成数据
“不相信仿真”、“不会在仿真系统中做算法训练”，是普通人跟高手的一个重要差距。
此话怎讲呢？
普通人，有一个典型特点是“不撞南墙不回头”“道理懂了很多，可依然过不好这一生”。
一个最常见的原因是，那些道理，基本都是别人告诉他的“大道理”，他还没有从亲自实践中尝到甜头/苦头，所以，他不信；然后呢，他当然也不会用这些“空洞的大道理”来指导自己的实践了。
真正能帮助他们提升认知的，是“撞南墙”之后的痛苦经历。
还有一种可能的原因是，即便是他真的相信大道理，他也不知道如何在大脑中尽可能多地模拟一些“任务”，更不会思考如何将大道理跟特定“任务”适配，因而只会生搬硬套。
或者呢，他确实也在大脑中做了一些模拟，但这种模拟，只是将之前发生过的事情“原汁原味”地回放了一遍，却没有修改过任何一个关键参数，没有尝试一种新的可能性；或者，只是做了一些轻微的修改，新的模拟任务跟之前的真实实践差别并不是很大。
我们拿自动驾驶仿真中的语言来做解释，他这种低水平的模拟，相当于用真实道路数据做简单的“回灌”，或者是，他自己也在大脑中生成了一些“合成数据”，但这些合成数据的泛化能力实在太弱了。
泛化能力弱就会导致，数据集中有效的样本量太少，无法代表真实世界的多样性，基于这样的数据训练出来的模型就很容易“过拟合”——跟之前的真实实践经历高度耦合，但难以用来指导其他事情。
我们经常看到两种现象：对过往失败教训反思的结果是“一朝被蛇咬，十年怕井绳”；轻易将过往成功经验的无限拔高，认为可以将这个经验复制到其他事情上，结果翻车了。 这两种错误的背后都有一个共同原因：他之前在大脑中做模拟的时候，没有把“场景泛化”做好。 虽然在这里列的是两种现象，但笔者敢断定，这两种现象经常发生在同一种人身上，就是“仿真能力弱”的人身上。 |
那高手基于大模型生成的“合成数据”，泛化能力当然要比普通人用来做仿真的数据强得多。因此，高手在仿真系统中使用的数据，在多样性上就要强得多，相应地，基于这些数据训练出来的算法或认知，泛化能力也要强得多。
PS：“比技术更值得探讨的，是游戏参与者们的思维方式”这一章节的内容摘自我的小号“九章AI产业管理咨询”——这是一个专注于思维方式方面内容的公众号。
甘愿永远做螺丝钉的人只关注对具体知识和技能的学习，而有成长诉求的人更关注的是对思维方式的培养。欢迎扫码关注。
