如果只是简单地依赖一个深度学习的物体检测算法，我们是永远不可能实现安全的L4级别公开道路自动驾驶的。换句话说，对于一个纯数据驱动的算法架构，出事故是一个早晚的事情。从技术的角度来讲，这也是目前基于统计的机器学习算法的局限，数据驱动只是建立起来一个从输入到输出的有效映射，而没有有效的推理（Reasoning），这就导致这些算法的泛化性能和人比起来仍有很大差距。还是举车这个例子，人可以去从功能和Affordance的角度拆解这样的一个概念：有轮子能承载其他物体运动的一个物体叫做车。更深一步，我们可以再去分解和定义什么叫做轮子/承载物体/运动。虽然学术界有这样的一些研究，但是仍然很初级，暂时不具备实用性。不像各种常见的手机娱乐应用甚至是安防应用，这些不确定性和失效，恰恰是我们在L4自动驾驶里不能回避的。

另外一个常见误区就是认为如果不是数据驱动的，那么就是基于手工规则的。这其实就走到了另外一个极端，在这中间我们仍然有很多数学工具可以讲我们的先验知识注入到模型中去。比如经典机器学习中的Bayesian方法，优化方法，都是一些典型的代表。他们在L4自动驾驶中发挥了重要不可或缺的作用。就像下面在我这几年对外校招的PPT里的一页：我们如果把整个L4自动驾驶的算法看做是这样一座冰山，经常被人提起的就是深度学习在各种识别问题中的应用，也就是图中浮在冰山之上的部分。然而在海平面之下，就算不提Localization和Planning&Trajectory这些基本一定不是深度学习问题的算法，支撑整座自动驾驶冰山的还有大量非深度学习、甚至非数据驱动非监督学习算法。这些问题因为非标准化，高度依赖于每一家各自系统的设计和传感器配置，较少有公开的数据集和评测标准，所以相对于火爆的深度学习，也较少被学术界所触及。但是这些部分恰恰成为了区分系统性能最关键的部分。

有海量数据L2就能演化成L4吗？

似乎唯数据至上成为了目前自动驾驶领域中的一个信条。在某些厂商和某些媒体有意或无意的渲染中，自动驾驶中数据就是灵丹妙药，只要能采集上上亿公里的数据，一个L2系统就可以自动“成长”成一个L4系统。但是真的是这样吗？下面我们可以先来不严谨地看看L2/L3/L4系统在做什么事情。先说在前面，虽然这个分级定义是从自动化角度来分析，但是实际应用中，我们经常也会将场景纳入在内，所以这里我们讨论的范围都是在公开城市道路中。

• L1/L2: 功能定义十分清晰，如ACC，LKA都是可以使用严谨的语言描述清晰预期功能和作用范围。但是在实际场景中，遇到的其他的问题，在Operational Design Domain （ODD）之外的问题，L2系统一概无视，比如经常会出现问题的高速封路，如果驾驶员不及时接管，那一定会出现安全事故。
• L3: 功能定义相对清晰，但是对于ODD之外的问题，L3系统需要有完善的预警和接管提醒方案，还是举封路这个例子，可能L3系统并没有能力准确识别封路范围并安全通过，但是可以在一个合理的预警时间内，检测到封路将控制权交接给人类驾驶员。
• L4: 无限接近于道路真实场景，ODD相对于L3系统大幅扩大（例如复杂困难的汇入、各种道路交通参与者的异常驾驶行为），但不同于L5，并非不限ODD，而是在应用场景下能够保证基本流畅行驶的需求。对于ODD之外的问题，L4系统需要有完整的风险迁移方案。对于不能解决的问题，不仅仅需要检测到，还需要保障绝对的安全。也就是说，对于ODD之外的场景，L4可以牺牲效率换取安全。只不过这个tradeoff是否能到达一个商业上的平衡点是一个技术需要突破的问题。仍然举封路的这个例子，可能L4系统要解决的问题就变成了，在正常锥桶封路的时候有着极高的通过成功率，如果遇到少见的用轮胎啊箱子啊标识封路的场景中，仍然能保证安全停下。

总结一下上面的比较，可以发现，L3相对于L2系统最大的区别在于检测ODD之外场景，L3与L4系统最大的区别在于ODD的极大拓展与ODD之外场景的风险迁移方案。L2系统根本不需要处理失效，L3系统只需要检测失效，而L4系统则要妥善处理失效。如果一个系统的架构是为了L2/L3级别设计（允许单点失效导致的系统失效），那么就算加入再多的数据，它也不可能自动完成失效检测和处理，完成级别的跨越。这样的跨越一定不会是“数据自发”的，而是一定需要自顶向下的全面设计才有可能实现的。如果理解了以上这些分析，下面引入了我下面要讲的一个概念——算法冗余就很自然了。

算法冗余设计会成为L4自动驾驶的关键

有了以上的分析，其实在这里就可以引出一个我认为很重要的概念“算法冗余”。往往我们在自动驾驶领域听说的都是，车辆执行器冗余，硬件冗余。那对于一个L4自动驾驶车辆来说，什么叫做算法冗余呢？类比于其他模块，我们可以将算法冗余定义为L4自动驾驶算法架构中关键功能的冗余。其他各种冗余我们可以天天听到，但算法冗余这一个概念，我至少目前没有见有人提到过。

从相关性和冗余的有效性上来看，以下的冗余设计方式可靠性逐步增加，当然难度也逐步递增，也更加考验整个算法架构设计的能力：

1. 相同任务，不同模型；和上述类似，问题的定义（输入、输出）和方法的原理是相同的，只不过通过不同的计算模型来完成。这个其实也就是最简单的ensemble和majority vote。可以一定程度上减轻模型不确定性，但是对于数据不确定性无能为力。在深度学习的语境下，可以简单认为是两个结构不同的模型结果融合。
2. 达成相同功能，但通过不同假设和算法完成。例如单目视觉测距，我们可以通过深度学习方法直接预测距离，也可以通过相机参数和对场景的不同假设来测量距离。虽然都是完成测距这个功能，但是不同算法和任务的假设不同，很大程度上避免了共因失效。
3. 达成相同功能，但是通过不同的数据源完成。这个在自动驾驶里面，最直接的体现就是不同传感器之间的冗余备份。虽然会有很多声音challenge说如果出现不一致结果，融合有多不可靠云云。但是：1) 从算法角度而言，只要保证训练/测试数据分布一致，那么加上更多的信息，结果一定不会变差。2) 不一致的结果本身就是很好地故障或ODD外检测的依据 3) 融合和冗余不应仅仅发生在结果层面，而是在整个算法的设计中就应该考虑清楚不同算法输出的表示形式，以便互补融合。

当然这些方案并没有绝对的优劣，如何结合实际应用场景合理利用这些方案就是非常考验算法架构设计的了。

可靠性分析之殇

说了上面这么多，其实想告诉大家的都是一个道理：一个可靠的L4系统，是需要工程、算法、硬件、车辆多方面协同配合才有可能创造出来的。千万不要因为某些商家的营销行为把高级别自动驾驶当成一个纯深度学习问题！具体在算法方面，我们仍然需要严谨的架构设计来保障系统的一个可靠性。然而，对于这样一个混杂着各种不确定性的复杂系统而言，我们如何能分析清楚整体的可靠性呢？无论是传统的ISO26262针对于汽车电子的标准，还是最近提出的ISO21448 SOTIF预期功能安全标准，对于L4系统而言都是无能为力的。当然我们可以通过大量统计数据下的MPI来作为标准，但是我们仍然会遇到为了覆盖某些corner case，需要天文数字测试里程的问题。在这个方向，我们仍然需要大量的探索、试错，从第一原理出发，才能探索出一条适合L4自动驾驶可靠性分析之路。

其他的一些Open Problem

除了上面说到的可靠性的问题，其实L4自动驾驶里，还有很多除了技术之外的Open Problem，试举几例：

1. 前文多次提到了ODD的概念，那什么是合适于L4级别自动驾驶的ODD划分方法？照搬L2/L3级别的方法论一定是不行的。
2. 如何定义L4级别系统的预期行为？因为影响系统反馈的因素可能有非常非常多，我们可能很难用一个简单的自然语言去向客户描述清楚系统的预期行为，那如果不行，我们又该如何定义PRD？
3. 在ODD范围之内如何有效测试L4系统的预期行为？如何在ODD空间中不重不漏划分测试样例？

这其实对应到的就是自动驾驶产品部门的工作。我认为这部分工作是和技术同等挑战的。如果有兴趣的同学欢迎了解一下我们目前开放的相关职位~

总结

数据在智能时代是非常宝贵的资产，这点毋庸置疑。然而，数据也不是自动驾驶的全部。尤其是对高级别自动驾驶，关键模块依赖单一的数据驱动算法不能保证对可靠性的要求。因为目前阶段而言，纯数据驱动的算法必然存在失效的场景，而L4系统不同于L2/L3系统，在单个模块失效的时候仍然要保持系统的健壮性。所以，算法层面的冗余设计就成为了关键。

最后，想说一句话和各位同行共勉：L4级别的纯无人运营是需要非常努力才有可能达到的。如果有一天能实现大规模的无人运营，希望我们靠的是严谨的逻辑推理与数据支撑，而不仅仅是鲁莽的"勇气"。

最后的最后，希望大家理性讨论，欢迎不同声音，但是请列证据+逻辑。无脑宣泄情绪会删评+拉黑希望理解。

[A] Kendall, A., & Gal, Y. (2017). What uncertainties do we need in bayesian deep learning for computer vision?. arXiv preprint arXiv:1703.04977.