万字聊聊百度Apollo自顶向下的自动驾驶之路

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

自顶向下的自动驾驶之路的意思就是在早期弱化成本因素，利用最高性能的传感器和算力芯片，结合合理的ODD（功能设计开启区域）力争最早实现有条件的高级别无人驾驶，再通过技术的提升和降维打击，利用更具成本效应的解决方案持续拓展自动驾驶的实用性和使用范围最终达成完全自动驾驶的技术路线。这与Tesla的先从泛化和简单功能开始，利用规模优势不断提升技术能力最终达到自动驾驶可谓是殊途同归。

欢迎关注「智驾最前沿」微信视频号

而这条自顶向下的路实际上是更早形成规模的自动驾驶探索之路，行业的先行者如Waymo，Cruise，以及国内的百度等公司一度成百家争鸣之势，而国内之所以能孵化如此之多的以robotaxi为切入点的自动驾驶公司，百度作为先行者功不可没，无论是作为行业黄埔军校为业界贡献了大量的领军人才，还是Apollo开源项目客观上降低了很多初创企业robotaxi的技术准入门槛并一定程度上成为了行业标准都对行业发展贡献巨大。

时至今日，百度仍旧凭借其长年的行业积累，国内最大规模的运营车队及行驶里程，数个城市的商业化运营等成绩保持着第一流的行业影响力。外行看热闹，内行看门道，同样是技术分享，这次Apollo Day与之前其它一些自驾企业的技术分享比起来，对于技术的原理和思考也更加细致详尽，作为从业者的我看了也有颇多启发。

我一直认为，搞技术的人不应该拘泥教条主义，搞什么路线之争，而应该兼听则明，所以我们惊叹于Tesla AI Day对于数据驱动，技术泛化掌握的愈发炉火纯青的同时，也可以从国内最高水平之一的百度的技术路线上了解到这个国内自驾毫无争议的先驱在自动驾驶这条技术路线上多年来取得的成绩与行业思考。

多源融合的地图

百度等代表的自顶向下方案与Tesla最大的不同在于地图的运用上。而在Apollo Day的技术分享中，百度着重强调了轻成本，重体验这两大原则。

地图的核心价值是熟路

毫无疑问，人类驾驶离不开地图，无论是传统的纸质地图，手机里的导航地图，还是人脑海里由记忆构建的家附近的地图。自动驾驶也离不开地图，地图的核心价值在于将自动驾驶变成在熟路驾驶。一个人类司机能够游刃有余正是依赖对道路的熟悉，才能达成安全，舒适，高效的驾驶。而这里所说的地图并不特指高精地图HD Map，而应该是由自动驾驶需求出发，针对不同地图互补特性而专门设计研发的地图，他可以来自不同来源的地图融合，甚至可以来自车端实时的感知以及车云一体的V2X技术，而百度称之为自动驾驶地图。

百度的自动驾驶地图不仅包括静态图层，还包括融合实时感知信息以及交通信息的动态图层，还有结合大规模交通数据得到的驾驶员行为知识图谱信息的知识图层等。

而研发生产这样的地图是有着非常高的壁垒，这些壁垒既包括国家对地图等测绘信息严格管控的资质壁垒，还包括要高效低成本生产地图所需要的技术能力以及对自动驾驶行业的深刻理解。地图资质稀缺，但国内拥有地图资质的公司大大小小数十家，再进一步拥有完整地图研发生产能力的公司屈指可数，最后一步筛选，在这些有能力的图商中同时具备对自动驾驶行业深刻理解的公司恐怕就只有百度一家了吧。因此预先布局地图底图生产，拥有国内最广泛使用的地图APP，亿万用户，拥有庞大采图车队，开发过街景，并且最早开始高精地图探索研发，最早开始布局自动驾驶的百度无疑在自动驾驶地图方面拥有其独特的优势。

百度把熟路这个地图核心价值拆分为三点：安全，舒适，高效。

在安全方面，百度利用离线地图解决车端实时感知在面对遮挡物体，标识磨损，新旧重叠等问题时候的缺陷；同时利用融合在线感知和百度地图大数据交通信息，解决道路改道，交通事故等离线地图难以解决的动态问题。

在舒适性上，主要利用的地图的超视距能力，以及从大量百度地图用户驾驶行为数据和宏观交通数据来规划更合理速度，提前变道，平滑转向等。

在高效方面，利用百度APP的交通流速度估计，利用百度交通大数据，规划更合理高效的形成，缩短出行时间提高效率。

地图的核心竞争力是轻成本

地图的上述优点基本已经是行业常识，而地图的致命伤在于其采集的成本，以及更新维护的效率。针对这一点百度则是利用自己的技术积累尝试予以应对。

这次Apollo Day上对百度建图技术的核心竞争力总结了三点：

1. 基于路网拓扑的多层次划分，并通过局部地图优化，保证每个子图块内的地图是连续精确的，再对优化后的局部地图进行关联匹配，进行合并，形成更大的地图，最终保证整个高精地图是相互关联且连续准确的，整个过程可以当作是运用一个分而治之的策略，在逐渐自底向上逐层合并的过程。

2. 针对局部地图间的关联上，百度训练了场景分类器来识别不同的场景，再根据场景识别结果，使用差异化的匹配策略来更好的找到匹配关系，例如城市场景的匹配因为城市GPS多径效应可能不能过度依赖GPS位置先验信息，隧道场景横向约束比较容易找到，纵向则存在歧义，因此不同场景需要定制的策略来更好的获得正确的匹配和关联。

3. 利用learning based方法来识别重叠区域，以及仅对重叠区域进行关联配对的预测，这样可以更有针对性的找到正确的匹配管系。例如上图右下角模型不仅预测了两块子图的重叠区域（红色部分），还给出了可能的匹配特征点对（绿色箭头）。

上述技术实现了高效准确的地图几何图层构建，接下来就是模型从几何图层自动提取语义信息，包括道路元素识别，特征矢量提取，语义特征与几何图层关联等步骤，最终形成具有几何层、语义层和拓扑层的高精地图。

另外由自动驾驶的需求出发，为了进一步提高自动驾驶地图的生产，更新效率，百度同样利用了自动驾驶汽车车端感知能力来进行在线建图，这样将传统采图流程从多次多趟采集缩短成单趟采集，同时能够利用众包建图的办法弥补传统高精地图时效性不足的问题。这里就体现了百度对于自动驾驶需要的地图的更好的理解，并不是一味追求地图全局精度，而是强调地图局部连续，以及语义的丰富程度。例如在L2的自动驾驶里只需要使用Landmark进行定位，这样L2的车辆就不需要使用更重的点云图层，节省了车端流量，同样随着车端感知能力的提升，车端可以判断红绿灯所掌管的左转，执行，右转方向，这样就不用在建图时候人工关联每个红绿灯和对应的车道，而只需把红绿灯与相关的停止线绑定。

在利用车端感知实时建图方面，百度也分享了比较详细的模型方案。如下图所示可以看出，百度的BEV静态道路场景重建融合使用了类似华中科大的MapTR类似的Instance Query和Point Query来进行道路元素以及元素轮廓定点的检测，以及类似清华的VectorMapNet中Auto-regressive decoder的办法来输出特征点之间拓扑关系，而这两个paper都是2022年比较具有影响力的BEV静态感知论文，可见百度的BEV方案还是十分具有先进性的。

文心云端大模型

超大模型近两年逐渐成为炙手可热的研究前沿，在NLP领域里，GPT-3等超大规模语言模型在图灵测试以及通用AI上都取得了令人瞩目的进展。而在自动驾驶领域大模型的应用也开始逐渐兴起，自动驾驶大模型主要包括两类，例如以Tesla方案为主的多头车端大模型，将原本分散在小模型中的众多任务用一个统一的大模型 + 多任务Head进行处理，另一个则是云端大模型在弱化车端计算能力以及延时限制的前提下尽可能的提高模型性能。Apollo Day上百度分享的便是文心云端大模型技术。

云端大模型降维增强车端能力

文心大模型的第一个主要作用在于通过云端大模型增强车端小模型性能。这个主要体现在两方面：

1. 利用云端大模型进行将无标签数据转化为有标签数据来对车端模型进行训练，从而提高小模型能力。从下图可以看到，整个训练，标注过程采用迭代的多轮方式进行，逐步提高大模型输出伪标签的准确度，从而针对无标注数据生成有效标注，丰富数据集，从而提高车端小模型能力。

2. 利用蒸馏等技术将大模型能力向下迁移车端小模型。从下图可以看出这里百度在多尺度特征，2D检测头，3D检测头三个位置使用了蒸馏技术来训练车端小模型，从而使小模型能力趋近于大模型。模型蒸馏技术来自于人工智能泰斗Geoffrey Hinton的研究，可以理解为用大模型的特征层以及2D，3D输出的Soft编码来作为监督信息，强制车端小模型在同样输出的前提下尽量逼近云端大模型的输出以及中间结果的分布，从而获得趋近于大模型的能力，但同时计算量仍保持小模型的计算量。

除了图像感知模型的蒸馏外，大模型还利用了特征蒸馏增强了车端激光雷达Encoder部分的能力，并且在BEV感知中也利用大模型在图像平面2D、3D的检测结果对BEV模型的中间特征使用了Side Loss方法进行了监督。这里Side Loss可以理解成一种正则化约束技巧，通过添加与输出无关但能辅助模型进行训练的中间过程Loss，来督促模型学习到有意义的中间结果，从而提高最终模型输出的性能，这里要学习的中间层结果就是图像平面感知结果，而最终模型输出结果就是BEV坐标系下的感知结果。

大模型构建数据挖掘能力

文心大模型的另一个重要作用在于赋能了云端数据挖掘。我们都知道百度是一个以搜索引擎技术为核心的公司，而自动驾驶云端数据挖掘与搜索引擎技术则有着十分紧密的联系，这也使得百度在这一领域的投入和成果变得顺其自然。而文心大模型在这里的使用方法我个人觉得很受启发，其方案见下图：

这里首先利用云端大模型对关联的文字和图像对进行一个一个与训练，这里其实是一个弱监督的训练，因为这里使用了对比损失（Contrastive Loss），这个理念由另一位深度学习泰斗Yan LeCun提出，其思想可以这么烈，属于同一语义的物体虽然可能有不同的表征，但是他们本质上蕴含统一的内在语义，好比一张小狗的图片和小狗这个词语虽然表征形式差异极大，却蕴含某种语义上的一致的含义。而通过模型编码器，把物体表征进行降维，得到物体的Embedding向量（可以理解成降维后的编码）后，使用Constrastive Loss保证两种不同表征的关联物体具有近似的Embedding向量，这样来迫使模型学到物体的内在语义信息。

这一思想用在自动驾驶数据挖掘上，就是将相关联的图像/视频与其描述文字进行配对（描述文字可以来自人工标注，可以来自公开数据集例如ImageNet的标签，也可以来自于百度搜索的关键字和图像），然后通过云端大模型利用对比损失做Loss进行训练，保证模型可以提取文字和图像的共同内在语义信息，这个语义信息特征向量就作为数据的标签用来构建数据底库。

这样在数据构建阶段，例如通过跟自动驾驶关联紧密的百度街景数据图像，以及大模型在街景图像上识别出的物体标签就可以获取语义特征向量，然后将图像数据和特征向量一起存储在数据底库中。在对数据进行定向检索挖掘的时候，可以使用文字描述，例如塑料袋，然后利用云端模型得到塑料袋的语义特征向量作为索引信息，给进数据底库进行搜索就可以得到相关的图像数据（这个就很像于百度的文字搜图嘛）；也可以利用一个corner case的图作为种子，同样得到语义特征向量，也给进底库搜索也能搜到类似的数据（这个就类似于百度以图搜图嘛）。

数据闭环

近几年行业上基本达成的共识是数据驱动已经是推动自动驾驶实现最不可或缺的核心驱动力，而随着深度学习为代表的人工智能技术逐步迭代深化，顶级企业已经在研发方面代替了高校和研究机构走在了行业的最前沿，其根本原因就是当技术突破已经无法依赖非盈利目的的小规模公开数据集的时候，那些真正拥有数据的头部企业才能够走在数据驱动大趋势的最前列。而为了迅速高效积累数据，构建功能完善的数据闭环就成了每个自动驾驶公司努力的方向。自动驾驶能力表现在车端，性能提升则集中在云端，因此云端不仅包括了数据回传，挖掘，还要包括数据消化，模型迭代训练等。

数据的质量大于数量

数据的质量大于绝对数量，这个结论显然是对于那些已经迈过第一道门槛，让数据飞轮初步转起来可以获得源源不断真实数据的企业来说的。百度之所以开始关注数据质量或者叫做纯度，也是因为百度不断扩大运营L4车队的数量和范围，已经具有了较强的数据收集能力作为基础。这里虽然百度车队数量无法和Tesla这样的车厂抗衡，但是凭借更丰富完善的传感器设备布置，车端高精定位能力，长期商业化运营，百度的数据收集能力还是Robotaxi公司中最强的一档，如此大量的数据如果全量回传云端，显然对于通信，流量以及云端存储都是不可能接受的重担。因此提高数据质量的第一步就是对于数据进行筛选。这里数据筛选其实有两道门槛，分别是车端提取，以及云端提取。

车端算力有限，却是数据回传的第一道门槛，使用车端已经拥有的小模型就可以对数据特征的相似性进行分析，从而在数据选择上更聚焦，主动筛选回传那些感兴趣的数据，而不至于造成流量和通讯的过载。

云端拥有计算能力更强大的大模型，因此可以对更大量的数据进行分析检索，数据挖掘检索方案可以参考文心大模型中国呢数据检索部分内容。

自动驾驶能力提升来自于数据使用的效率

有了高质量的数据还不足够提高自动驾驶能力，还需要高效的消化使用数据才行。百度对于数据的高效消化能力体现在三个方面：

1.持续自动的模型训练

持续学习首先要自动的获取训练数据，这就使用到之前提到的数据挖掘方面内容。例如下图，对漏检的小狗利用云端大模型进行特征提取，右图中每个圆点可以看做是数据在特征空间下的语义特征向量，我们有一些白色点是漏检的种子数据的特征向量，在特征空间中搜索与种子数据近邻的数据作为挖掘到的数据（图中蓝色圆点），另外在正负样本（左侧标有+号的为正样本，右侧标有-号的为负样本）分界线上对于特定模型有一些难以判断的数据（图中橘色圆点）则组成了不确定样本（由于不确定样本对于训练任务的难度较高，所以可以通过在训练中使用更高的权重进行梯度下降，以获得更好的判断结果，这一点凸显了不确定样本挖掘的重要性），把这些样本一同加入云端自动训练pipeline里，通过AutoML的方法自动搜索超参数和训练模型，就可以不断得到候选模型。这一自动持续学习流程的高效率一方面取决于挖掘出的数据的载入速度，另一方面取决于AutoML超参搜索和模型训练的计算效率。

为了提高数据消化效率，在数据载入方面百度利用了他们PaddlePaddle团队研发的PaddleFlow对数据载入速度进行优化，使云端数据读取速度提升了10倍。

而在提高模型训练的计算效率方面，则利用了基于AutoML的理念在云端利用PaddleCloud分布计算能力和云端强大算力对模型族，模型训练超参数，模型设计参数等进行搜索训练，而且这些训练的模型不仅包括车端小模型，还有云端大模型，以及实验阶段的候选模型等。这些模型共同构成了云端候选模型库，并且模型的存储包括模型的超参（决定模型训练的动态过程）以及模型的参数（模型静态参数），基于这样的模型库在不断有新数据加入的前提下，在云端持续通过指标对模型进行评估比较，就可以选用指标最优的模型应用在车端和云端。

百度在分享中提到，他们发现利用主动数据挖掘能力以及上述持续训练迭代，随着数据的积累，整个模型的性能是持续得到提升的，目前还未发现数据饱和的迹象。

2. 多模块联合优化

百度还分享了在多模块联合优化方面的心得。自动驾驶的目的是提高最终的自动驾驶性能，可是自动驾驶中由于不可微模块的存在，导致端到端的优化很难实现，因此自动驾驶技术被拆成可独立优化的上下游模块。而单独训练一个模块使用的优化目标函数与整个自动驾驶系统的目标函数存在较大的分布差异，因此训练一个单独模块获得更好的指标不能保证整个自动驾驶系统的性能提升。而多模块联合优化则是考虑模块自身目标函数的同时，也考虑系统评价指标综合进行优化，以期获得模块自己和整个系统相结合的最优解。

百度的技术人员分享了一个例子，以目标预测为例，目标预测处于自动驾驶系统的中游，它的训练目标是获得周围物体未来运动的准确轨迹，但是单纯考虑预测模块，获得更好的轨迹预测结果，并不一定能保证下游规控模块也能获得更好的规划结果，这里就需要在训练预测模块的同时，再引入异步评测的仿真规控评测指标，保证训练后的模型对两个目的函数取到联合最优解。

3. 分布提取

数据的分布提取包含几层不同的含义。首先是它的表示方式，可以利用标签化和场景化的分类对数据分布进行表征。其次如上面联合优化中提到，局部模块与整体系统可能存在目标函数不统一的问题，其根本原因在于局部模块与整体系统数据分布不一致。于是百度想到，可以利用标签和场景对数据加以表征，然后在最终自动驾驶评测指标中利用这些中间模块的表征对问题分布加以分析，以指导中间模块的模型训练。

分享中举了一个例子，对于一批急刹车数据使用一些模块指标类标签，场景标签等进行分布表达，可以发现某类急刹的案例中具有较明显的特征，例如主车进入还岛标签（场景标签），以及旁边车辆预测不准标签（预测相关标签），根据这样的分布特征，可以知道为了提高这一类急刹场景的表现，可能需要增加环岛数据，增加旁车预测失败的数据来加以训练，才能提高这一类急刹场景中整个系统的最终表现。

仿真和MLOPS使迭代和测试变得高效

除了数据筛选和数据消化外，百度的云端工具链还包括仿真系统和MLOPS相关SaaS软件。

Apollo Day中提到百度的仿真系统具备场景生成能力，Log2Sim真实数据仿真能力，以及车辆动力学，传感器等仿真功能，仿真系统还具备丰富场景库，主要分为交通法规，行为安全，阻塞通行三大类。这些场景库提供了较高的自动驾驶场景覆盖率，利用这些场景可以实现算法模型在仿真环境中的高效迭代，以及仿真持续测试。

百度云端工具还具有较完备的SaaS产品，包括上述的数据闭环工具链以及与数据驱动相关的MLOps软件等，整个技术栈参考上图，这里不详细介绍。

L4/L2一体的软硬件解决方案

Apollo Day并没有特别详细的分享车端的技术细节，但是分享了一些百度自动驾驶团队在车端自动驾驶能力的演化过程以及最新新进展，同时还分享了一些L4/L2自动驾驶的技术思考。百度在今年来车端架构的最大调整应该算是逐步收敛L4/L2两条路线的技术方案，使二者拥有统一的感知方案，地图方案，以及共享数据和技术工具架构。而在整体技术思路上也走了一条与行业主流相一致的逐渐加大数据驱动比例，数据驱动方法与规则驱动方法相结合，数据驱动提高能力上限，规则驱动确保底线的思路。

多模态感知的迭代演进

百度自动驾驶的感知能力经过迭代已经从强调激光点云感知，视觉仅进行红绿灯识别的时代逐步进化到激光雷达，周视视觉前融合，同等重要，相互独立互为冗余的阶段。

感知架构由云端大模型蒸馏，主要利用视觉传感器解决远距离物体环境的感知，在自车周围使用多模态多传感器的前融合，利用今年主流的transformer技术将图像特征，Lidar特征以及毫米波雷达特征转到统一的BEV坐标系下进行感知。近距离利用鱼眼摄像头在近处观测无死角的特点补全近处盲区，生成freespace，这是一种类似于Tesla Occupancy Network输出的2D可通行区域检测。

具体来说，BEV动态物体感知方面，图像特征提取采用了跟Tesla类似的共用Backbone的方案，这也是当前自动驾驶在有限算力和众多感知任务的情况下主流的方案。在图像特征提取后采用了类似DETR及DETR3D中利用Object Query的办法结合Transformer获得了稀疏的BEV感知物体编码，然后再利用解码器结合里程计帧间运动信息以及历史帧query到的object信息，进行追踪BEV障碍物的追踪，最终得到BEV坐标系下时序一致的前融合感知物体。

而静态感知方案之前在地图一章已经介绍，方案结合了如今比较新的两篇paper的技术，这里不再重复，模型框架见下图。

从事过BEV感知研发的人应该了解BEV感知最大难点并不在于模型算法，反而在于BEV坐标系下真值的获取比较困难，人工标注几乎无法高效实现，必须依赖自动标注AutoLabeling技术。与Tesla采用基于NeRF的自动标注技术不同，这里百度的动态障碍物检测真值数据利用了百度L4车辆自带的激光雷达生成真值，作为BEV感知的标注数据。这也是据我了解目前很多国内厂商所尝试的BEV动态感知真值自动标注方案。

静态BEV感知的真值也同样使用了目前很多厂商所尝试的方案，那就是利用高精地图以及高精定位获取4D（x,y,z,t)的BEV静态道路元素标注，技术流程如下图。

Learning Based的预测与决策

Apollo Day百度分享了一个他们关于自动驾驶技术栈的架构思考，那就是百度将决策和规划拆开来，将预测和决策模块放在了一起，而把规划模块和最下游控制模块放在了一起。这一架构设计的原因我结合百度的分享和个人理解认为主要是因为预测与行为决策两项任务具有较大的相似性，一个是他车的行为预测，另一个是自车的行为决策，关系比较紧密。

另外这两个任务比较适合使用Learning Based方法进行训练，因为无论是预测还是决策都比较容易高质量低成本的获得监督数据，其中预测的监督数据来自后续感知到的他车的真实位置轨迹，而决策真值则可以来自手动驾驶数据，也可以来自基于百度地图的大规模人类司机的真实驾驶数据。另外技术分享中也提到自车决策过程中也会适量引入基于规则的决策策略，这样当结合learning based和基于规则的决策行为进行决策树的最优策略搜索，就能保证即使learning based决策在某些少见的corner case下决策欠妥，仍能有基于规则的决策进行兜底。这一方案其实在今年AI Day上Tesla对其PNC技术的分享中也可以发现类似思路，可以说是目前在泛化性和安全可解释性都必不可少的情况下最主流的技术方案了。

而轨迹规划和控制则还是以传统方法为主，其核心在于在有限的算力和时延约束下，尽量优化算法效率以最高效的获得规划轨迹，并由下游执行器进行控制实施。这次Apollo Day上对规控没有特别详细介绍，这里也不做猜测了。

商业化战略布局

车端与云端结合的产品矩阵

这次Apollo Day上，百度提到自己的战略定位是汽车智能化赛道新兴，专业，本土供应商，在我看来百度自动驾驶至少能够提供两大有竞争力的产品矩阵给车厂以及其他潜在客户。

1. 车端软硬件一体结局方案，即ANP3.0

车端不仅包括据说可以实现连通停车场，高速，城市复杂道路的L2+导航辅助驾驶软件算法，还包括百度基于Nvidia Orin自研的自动驾驶控制器，以及集成整合的传感器平台。从ANP3.0宣传的可实现复杂城市场景的辅助驾驶的角度来看，这个功能无论对于车厂还是汽车消费者都会很有吸引力，但是城市辅助驾驶难度非常之高，城市地图采集，更新频率也非常有挑战，参考目前小鹏和华为都还只在一座城市有限制的发布，ANP3.0究竟可以达到什么水平则决定着这个产品整体的竞争力水平。

另外美中不足的是同样在Apollo Day上介绍的自研芯片昆仑芯介绍并不太多，我对芯片也不是特别了解，就没在前文详细介绍，然而根据技术分享中的信息，昆仑芯目前还是以云端计算芯片为主，应该还没适配车端。然而云端芯片目前看来主要是节约云计算成本，并不会带来如车端芯片一样巨大的市场影响力，因此如果昆仑芯能够尽快适配车端成功，成为继英伟达、地平线和高通等车端芯片厂商之外的新的选择，则会对百度Apollo ANP整体价值有着非常显著的加成。

2. 云端SaaS服务

地图MaaS(Map As A Service)服务，以及目前嵌入在百度地图内部的自动驾驶robotaxi服务MaaS(Mobility As A Service)

其中云端SaaS服务包括百度非常完整的云端数据闭环工具链，提供诸如数据挖掘，持续训练，MLOps以及仿真等一系列能力，这样完整的工具如果能够提高适配性，应该对很多车厂及潜在客户都有很强的吸引力。而地图和出行服务则具有稀缺性和足够强的技术壁垒，正如前文提到，百度拥有从采集，制图资质，标精地图，高精地图等完整的地图生态，再结合深耕自动驾驶的经验和行业理解，确实在地图服务上拥有很独特的优势地位，而robotaxi的出行服务目前能力和产品力也处于国内绝对的第一梯队水平。

基于L4、L2共生的战略布局

这次Apollo Day上百度提出了L4技术降维L2进行冷启动，然后利用L2（ANP3.0）数据反哺L4所需的长尾数据，最终实现二者融合共生的发展战略我个人认为是十分及时及必要的。前文所述百度自动驾驶众多十分突出的技术优势亮点固然优秀，然而在数据闭环方面虽然百度运营良久，也有着国内最大的自动驾驶车队，但与动辄销售数万台，且用户足迹遍布全国各地的车企比较，百度收集数据的能力毕竟还是受到绝对数量和ODD区域的限制，即使数据闭环工具链方面做的十分完善，也还是需要尽快通过落地L2产品提高数据的收集的能力。而一旦成功将一款有竞争力的L2产品落地大规模量产车型，甚至后续自己造车，那么L4/L2共生的正循环数据飞轮才真正运转起来，前述所说的众多技术优势也才能真正转化为商业上的优势。

转载自知乎@EatElephant，文中观点仅供分享交流，不代表本公众号立场，如涉及版权等问题，请您告知，我们将及时处理。

-- END --