陈竞凯：依托坚实的AI技术底座打造自动驾驶技术体系

2022年11月29日，百度Apollo Day技术开放日活动线上举办。百度自动驾驶技术专家全景化展示Apollo技术实力及前沿技术理念。

自动驾驶行业没有弯道超车，多年技术积累才能实现全无人落地的临门一脚。百度自动驾驶技术专家陈竞凯介绍，百度Apollo依托坚实的AI技术底座，打造安全、智能、高效的自动驾驶技术体系，实现从全无人运营到规模商业化运营。

百度的学习型PNC方案是将预测和决策两个模块联合建模，然后送入到轨迹规划和控制模块中。学习型的PNC模块是自动驾驶学术和产业的技术前沿。学术界虽然提出了不少研究成果，但在产业界其实应用的案例并不丰富，甚至可以说只是在尝试阶段。百度此次提出的预测决策一体化模型，在底层设计上实现的创新，是行业在实现PNC范式变革上迈出的重要一步。

以下为演讲全文

陈竞凯：大家好，我是百度自动驾驶的陈竞凯。

众所周知，百度在自动驾驶领域已深耕多年，今天为大家分享百度在打造安全、智能、高效的自动驾驶体系中的一些思考。

自动驾驶系统，最重要的是安全，系统设计需要遵从汽车安全体系。百度从功能安全和预期功能安全两个方面来打造自动安全系统。

按照功能安全的设计要求，百度拆解了系统的安全框架和目标，通过适当的冗余，来降低失效带来的危害。在计算硬件、传感器、底盘、通讯的各个层面都构建了冗余，并且完善了故障检测和处理方案，实现全方位的安全。

传统的安全设计，主要是保障司机的可操作，即司机在故障发生的条件下，有能力处理相应的故障。在自动驾驶系统中，需要能够让自动驾驶系统处理这些故障，保证系统安全。

自动驾驶系统不仅仅要处理自动驾驶系统本身的故障，而且要对车辆的各个系统的问题，也作出相应的应对。

比如车辆的胎压系统出现问题时，需要能够检测出来，能够在车辆运动可能会出现异常的条件下，把车辆安全地停下来。带伤运行会让系统变得不够安全，百度的安全策略是让车辆在发生故障时，使之进入安全状态，而不是继续保持驾驶。

这时候就提出了一个不同于主系统的挑战，如何在各种各样的道路条件下，当发生故障的时候，把车辆进入安全状态。在复杂的道路条件下，是不能简单地一停了之的。故障方案必须与真实的道路环境相兼容。充分地利用了仿真的系统，去测试一下故障处理策略是不是能够应对当前的故障，去能够应对当前的道路条件。

进入安全状态所需要的能力，通常和完成自动驾驶全功能能力是不太一样的。往往需求相对小一点。这时候就能够平衡可靠性的要求和成本。合理的安全驾驶策略就特别关键，百度在仿真系统里进行了大量的测试，去调整安全处理方案，使得在两者之间取得一个比较好的平衡。

自动驾驶系统的能力演进，是按照预期功能安全框架去思考的，会从知道不知道、安全不安全这两个维度去推进自动驾驶技术能力提升，提高自动驾驶系统对复杂场景的适应。

一个合理定义的ODD是自动驾驶系统，尤其是全无人自动驾驶系统不可或缺的一个组成部分。需要通过大量的仿真和道路测试，来保障在ODD范围内的安全驾驶。

但是自动驾驶不是完美的，道路条件也很复杂，详细定义的ODD，尤其是包含动态交互的ODD通常是不太现实的，所以在一般的ODD的定义中，通常还是偏向于静态定义，很难去覆盖所有的道路交互状态。这时候就需要在车端有比较强的检测能力，去检测目前的系统是不是运行在ODD下，即使这样也会遇到一些超出自动驾驶能力的一些状况。

百度设计了一个系统，通过经验数据，以及通过针对目前驾驶能力，设计一个偏召回的风险预警策略，能够判断出目前的系统，是不是处在一个可能会不安全的状态。辅以一些云端和路测的手段来保障安全，使得系统从一个潜在不安全的状态变为一个更加安全的状态。当然了，这种工作一定会对自动驾驶效率有一定的折损。随着自动驾驶能力的提升，不安全的状态和场景会越来越少，对应的自动驾驶效率也会逐渐的提高。

在车端也会秉承这样的思路，来做出相应的处理。在主系统之外去构建一些安全的回路，保证在一些场景下，突发状态条件下的自动驾驶系统安全。

自动驾驶系统的能力目前还在不断提高的过程中，需要把更多不知道的问题变成知道的问题，把不能安全通过的场景变成能够安全通过的场景，并且能够预知一些可能出现的危险，通过策略规避掉一些复杂的危险场景。车端的持续演进，不断的去发现和改进自动驾驶能力的边界，需要在车端有相应的数据挖掘体系，帮助发现这些问题。通过车端的数据挖掘，会不断的发现自动驾驶系统中处理得不够好的，或者是一些不确定性问题，然后把这些数据上传到云端，通过云端系统，使用数据驱动的方式，训练、仿真等一系列的工作提升自动驾驶能力，提升自动驾驶的安全性。

自动驾驶系统该如何设计？一直都有两个思路：

一个是偏学术的

倾向于统一建模，端到端的解决问题；

另外一个思路是偏向工程的

去拆分系统，分治突破。

端到端的建模非常的简洁优美，从长远来看，也是一个非常有前途的方向。

在这种思路下，其他的领域里面百度取得了一些进展，比如说技术模型在NLP领域里面已经取得了统治性地位。在图像领域，大模型也带来很多的惊喜。同样，百度对于这种端到端的大模型的解决方案，在自动驾驶系统的发展也充满了期待。

这个方案的问题在于存在很大的不确定性。不能确定它究竟何时成熟，是两年还是十年，这是一个问题。

基于这样的认知，百度目前的主要的思路还是沿着工程化的路线在往前推进，同时也没有放弃在端到端方面上的一些探索，会把一些阶段性的成果应用到一些路线上。

百度的车载系统大体会分成四个部分：地图、感知、预测决策、规划控制。

地图，是在系统中一个非常重要的组成部分，自动驾驶系统是不能脱离地图的，因为交通系统本来就是规则约束下的系统，自动驾驶是运行在交通实际条件下，当然也不能脱离规则的约束，地图恰恰是规则系统表达的一个核心框架。

百度认为不管是有没有离线地图，或者说只用在线地图，地图总是自动驾驶系统的一个底层表达，离线地图是一个超视距的整体性的感知，地图在自动驾驶系统中间发挥着重要的作用。

在谈到离线地图的时候，外界有声音说，离线地图制作成本是不是很高？会不会成为普及的障碍？在实践过程中间我们发现，离线地图并不是一个高成本的障碍，反而是我们一个前进的助力。

地图的更新率其实不是一个问题，地图的实时性才是它的问题，而不是更新率或者成本。

在目前的实践中，目前车端实时生产的地图和规模化生产的地图其实还是有质量上的一些差距的，这种差距，需要通过自动驾驶策略去适应这两种地图的一些质量差异。但这种适应对自动驾驶能力来说是有折损的。

所以百度认为，在目前的条件下，一个规模化生产的高精地图还是不可或缺的，实时地图更多的会被应用在应对现实世界的变更，这时候会把自动驾驶的策略调整到一个更加安全谨慎的方式去通过。

感知系统，感知系统目前在整个业界的发展思路还是比较统一的，基本上是一个数据加模型驱动的系统。

目前主要的分歧是在于，大家讨论的一些主要分歧在于传感器的配置。

百度的判断是这样的，应该充分的发挥各个传感器的能力，从出发点来说，首先要把事情做成，然后再去追求更好、更低成本，再去充分地发挥各个传感器的能力，把感知做得更加可靠，更加稳定。

在具体的过程中，从后融合的方案转向前融合的方案，前融合的的方案，使得能够充分地发挥各个传感器的优势。另外，也会充分的利用百度大模型技术方面的一些积累，提升感知能力。

预测决策系统，预测决策系统是直接面对复杂外部环境的一个非常重要的部分，百度把这个系统的模块的分界线划到了预测决策和规划控制之间，主要的出发点是，决策问题其实是可以引入人工判断的节点，这时候可以在其中引入更多的人类智慧。

百度把预测和决策放在一起，其实也是有相应的思考的，百度认为预测是一个自标注的学习系统，在真实的世界里，主车是与现实世界是有交互的，这时候更倾向于认为预测和决策是一体的，预测很多是决策的预言实现。

规划控制

规划控制在传统方案中是一个优化问题，在真实的道路条件下，往往会面临一些求解空间和计算资源之间的冲突，百度也做了很多的探索。

正如我们前面提到的，驾驶能力的提升表现在车端，但是更多的工作是在云端完成的。

在车载系统的迭代中，如何能够从数据中学习，从问题中学习，尤其是自动学习，这是百度一直以来追求的目标。

为此百度构建了数据闭环的系统，并且在自动驾驶技术研发的过程中间就不断的迭代和完善这个系统。

仿真系统

仿真系统一直都是自动驾驶的话题中心之一，一个完美的仿真系统是自动驾驶开发者的梦想。尤其是在做一些端到端探索的时候，我们经常会感叹，如果有一个完美的仿真系统是多么的幸福。然而，做一个完美的仿真系统在目前是不切实际的，如果想在仿真系统中去模拟各种各样的驾驶风格，而且这种驾驶风格是和人类驾驶一模一样的时候，实际上就做出了一个有不同个性的自动驾驶系统，这一点在目前这个阶段还是很难的，不太切实际。百度追求的目标是做一个对我们的自动驾驶技术能力提升有用的仿真系统。

不管是车载系统还是云端系统，自动驾驶都需要算力的支持，这方面我们也会有一些持续的投入。

得益于自动驾驶技术的发展和自动驾驶体系的搭建，一方面我们会研发面向全无人自动驾驶系统，为大家更好的提供出行服务。另外一方面，也会落地一些高级辅助驾驶，给司机提供更好的驾乘体验。

百度最初的自动驾驶系统，预测和决策是分开的。预测是一个带有自标注的任务，一直都是数据驱动的，决策、规划、控制，当初沿用的都是偏规则的传统方案。

基于规则的方案：通常是把遇到的问题划分成各种场景，在每个场景下，针对不同出现的问题，再做相应的处理，为了不让各个规则之间发生冲突，通常会仔细地限定每个规则的作用范围，一层一层的拆分，如果做得好的话，会形成一个类似树形的拆分结构；如果处理得不好的话，就会变成一个补丁摞补丁的系统。尤其在后者的条件下，会遇到无法维护的问题，即使哪怕在前者我们一个高尖端好的树状结构，也会遇到一些认知升级导致目前的树状结构和认知不相匹配的一些问题。

规则系统在最初的时候，是可以最大化人类的经验和一些先验知识，能够迅速地去提升自动驾驶能力。但是随着时间的推移，有两个问题是不可避免的会出现。

第一，策略分叉，会导致每一个规则的迭代，针对的问题会越来越小，这时候投入产出比会迅速的下降。

第二、在面对城市扩展、场景变化的时候，需要调整规则去适应，而且这种调整的范围往往不是局限在叶子节点上的，而是需要从根到叶整个全面的调整。这种变化会使得规则系统在面临这种迁移变化的时候会非常难以维护。

出于这样的观察，百度认为学习型的PNC是实现全无人的一个必由之路。

正如我们提到的，预测和决策其实是一个问题的两面，预测是决策的自我预言实现。所以构造了一个预测和决策的多任务系统，联合处理这个问题。我们对道路元素、信号灯、自测行为、道路元素都做了一些建模和交互的处理，最后形成一个预测和决策的一个结果。

这个框架的思路还是比较基本的，但是在实践过程中间有很多有趣的问题。

因为每一个学习系统，都会面临着一个启动和迭代的问题。在这个过程中间，和原先的规则系统是什么样一个关系？在实践中间，百度采取了一种渐进式的改造思路，逐渐地去吸收规则系统。

打个比方，规则系统实际上是一台学习系统的学步车，百度要在规则系统的经验条件下去初始化我们的学习系统。然后再通过一些迭代使得学习系统要超过规则。

在过程中也会发现，在规则系统中的很多细小的地方，就隐含了一些决策的操作。这种决策的操作，其实在最初设计决策系统的时候，可能会有些漏掉的地方，需要后续再不停地去优化和改进。

百度最终的目标，也不是要把学习系统完全替代规则系统，因为两点：

第一，交通系统本来就是一个靠规则约束的系统；

第二，需要规则去守护最后的底线。

我们在端到端探索也做了很多很多的尝试。

比如，百度的搜索和推荐是发展领先的，在实际过程中也会把一些搜索和推荐的技术应用到自动驾驶系统中，而且还有一些意外的、超过我们预期的一些收获。

在学习系统中间，直接生成轨迹是比较困难的，如果没有一个合适的锚点的话，生成的轨迹往往比较难以尽如人意。但是在使用基于搜索的方法来做轨迹生成的时候会发现一个非常有趣的现象，在一般的场景里面，只需要搜索两条轨迹侯选，就可以给出99%以上场景的可行的答案。在一些相对困难场景下，其实也有不错的一些表现。

基于这个进展，把基于搜索的方案也整合到了系统里面。在对场景进行建模以后，再去构建一些场景的相似性的一些方案。通过搜索的技术，去生成一些轨迹的侯选，把它们作为规划系统的一个启发的输入。

从实践过程中百度发现，这种启发的方式能够大幅度降低在整体的搜索过程中间的一些计算开销。

回顾来看，整体的框架是比较契合人类的驾驶模式。首先在高层语义层次上做出一些决策。比如说在一些宏观的层面上作出了一些决策，但是在这个微观轨迹的层面上，人类并不是去做一个详细的优化，而是类似于直接出结果，而百度的检索系统恰恰又跟人类这种直接输出结果的方式，去追求可行而不是最优这种方式，有一种完美的一致。

百度追求的是做一个有用的仿真系统，应该满足我们对于问题迭代的需求。并需要在微观层面上，每一个场景上能够做到辅助迭代，而且要能够让它对整体自动驾驶能力作出一个完整的评价。

仿真系统实际上是百度在自动驾驶技术发展迭代过程中的一个有效的工具。

为了完成自动驾驶发展的迭代工作，百度在仿真系统的能力构建上做了很多大量的工作，比如说做了Worldsim系统，使得能够批量地构造大量的场景，去验证各种各样场景下的综合能力，另外也构造了一个L2W系统，能够精确地复现道路的场景，帮助去分析和验证路上的问题。

百度也通过一些动力学的仿真，使得能够比较精确的去模拟，去刻画车辆的行为。

在此基础上，构建了一个能够验证仿真系统和道路系统的一致性的系统，尤其是面临一些安全性判断的时候，对一致性有很高的要求，构建这样一个仿真系统是满足实际需要的。

另外，为了支撑感知能力的迭代，支撑我们自动驾驶系统对各个场景的适应，百度也构造了传感器的仿真，实现了对各种光照条件和天气条件的覆盖。能够通过高精地图，自动地渲染出整个道路环境，能够端到端地去评测整体的系统。

针对迭代过程中对自动驾驶中的安全、体感、合规等方方面面的要求，百度也构建了相应的度量体系，去帮助工程师在迭代过程中去更好的评价自动驾驶系统的表现。

百度也发展了部分的障碍物交互能力，坦率地讲，在仿真系统中构造障碍物交互是一个比较困难的事，目前做的更多是排除一些典型的不合理的行为，而不是去构造一个能够进行复杂交互的障碍物系统。

作为结果，仿真系统在迭代过程中也发挥了非常重要的作用。支持了数百人团队的迭代，在仿真系统日行上百万公里，去验证自动驾驶能力的进步，同时也在仿真系统里去探索自动驾驶的更多可能性。

如果仅仅是在单个Case层面上去实现对道路的真实模拟其实不太够的，如何对每一次迭代带来的变化作出完整的评价，一直都是仿真系统面临的一个非常大的挑战。比如说在面对切车的时候，采取一些占据优势地位，避免被切的策略，这时候就会带来一些后续的交互行为，这种交互行为在仿真系统是很难模拟的，这时候会遇到一些极限的情况，导致急刹或者碰撞，这时候会面临一个灵魂拷问，这样的场景在路上会不会真的发生？

如果遇到这样的情况，自动驾驶能力是变好了还是变坏了呢？

如果脱离了大规模的数据分布，是没法讨论这个问题的，所以在仿真系统中，一定需要构建一个好的数据集合。数据其实是仿真系统的灵魂。

为此，百度在针对路上可能会出现的各种情况，建设了丰富的场景库，这些场景库会拿到跟路上去做比对，看看在路上场景的覆盖情况。

在建设过程中间发现，其实路上的场景绝大多数是可以通过大概600、700个场景就能够覆盖住的，后面就是一些分布的情况。在做泛化的时候也发现，其实后面很多情况不需要做泛化，这时候就针对这个路上常见的多个场景做了一些详细的维度拆分。比如说，刚提到的这个切车的场景，会根据切车的车辆类型、切入开始的距离、速度、速度差、切车幅度、切入时间等等各个维度，去建设一个能够充分刻画这个场景的维度体系，并且建设一个相应的自动化匹配机制，使得在路上遇到了一样的场景，能够自动的去匹配到场景体系上，把相应维度上的参数提取出来。

在这样的自动化挂接的基础上，百度针对各个场景建立了相应的集合，在这基础上统计了针对每个场景的数据分布，尤其是常见场景的数据分布。就可以清楚地了解到，这个场景在仿真系统内的真实运行场景，在真实世界里大概会是什么状态，发生的概率有多大。在这个基础上就构建一个针对仿真系统的、一个相对被扭曲的分布条件下，给出一个正确的度量。

这种度量不是像刚才提到的，从Worldsim中去泛化出来的这种场景，在那个场景里面很多车辆的行为、车辆的一些参数，和自然发生的情况还是会有些区别的，把真实世界的场景挂接到这个系统里面，它的运行也会变得更加的真实和可靠。

通过这样一个体系建设，百度也建设了针对一些特定需求的场景库，比如说针对交通法规，针对行使安全，针对主车通行等等，分别去建设场景库，充分的利用到迭代过程中，评估每一次变更带来的能力变化。

百度观察到，在从一个城市向另外一个城市迁移的过程中间，这个数据统计、数据的分布是有变化的，这时候要求自动驾驶能力、自动驾驶的一些策略，从一个城市向另外一个城市迁移的过程中间需要做一些细微的调整，整体的场景库也对迁移过程提供了很多的保障。

仿真系统在我们的自动驾驶技术迭代的过程中间发挥了非常重要的作用，是我们技术能力提升的重要支撑。

谢谢大家！

审核编辑 ：李倩