ARTICLE · INTELLIGENCE

战地情报 · 详情页

来自尧图项目组的一线实战观察与深度解析

端到端自动驾驶彻底讲透:原理、落地与踩坑指南

端到端自动驾驶彻底讲透:原理、落地与踩坑指南

如果你关注自动驾驶行业超过两年,一定会发现一个明显的风向转变:两三年前,大家讨论的还是激光雷达、高精地图、多传感器融合,传感器的选型都能开一整天会;而现在,几乎所有技术团队的嘴边都挂着一个词——端到端。但说实话,真正理解端到端自动驾驶是什么、为什么它能颠覆传统范式的人,其实并不算多,更多是被各种营销稿糊了一脸“端到端即王道”的既视感。

这篇文章打算从一个在智能驾驶一线摸爬滚打的从业者视角,把端到端自动驾驶彻底讲透:它到底怎么运作,和传统模块化路线有什么本质区别,想落地会踩什么坑,以及我个人的一些实操体会和踩坑实录。如果你正在做驾驶辅助、自动驾驶系统,或者正准备从传统模块化架构转向数据驱动的新架构,这篇文章值得你花十分钟看完,同时你也能拿里面的方法论直接去做技术选型参考。

1. 传统模块化自动驾驶:一套“分而治之”的精细系统,为什么遇到了天花板

1.1 四段式流水线的由来与分工

我们先把时间轴拨回去。二十多年前,自动驾驶刚起步时,研究者们面对的几乎是一张白纸,没有现成的算法能直接完成“看见路然后控车”的复杂任务,于是自然而然地采用了工程领域最经典的“化整为零”思路:把驾驶任务拆成四个独立模块,每个模块单独开发、单独验证、单独迭代,最后用一套中间接口把它们串起来。

这四个模块就是大家熟知的感知(Perception)、预测(Prediction)、规划(Planning)和控制(Control)。感知模块负责从摄像头图像、激光雷达点云、毫米波雷达数据中提取物体位置、类别、速度,同时完成车道线分割、红绿灯识别等任务;预测模块接收感知目标,利用轨迹预测算法估计每个目标未来几秒可能到达的位置;规划模块结合自身车辆状态、道路结构和高精地图,在前方几百米的范围内搜索一条安全、舒适、合法的轨迹;最后控制模块把规划的轨迹拆成油门、刹车和方向盘的具体指令,并通过车辆动力学模型保证跟踪精度。

这种层级化架构在设计之初非常合理,每个模块都可以用各自领域的成熟工具。感知可以用目标检测网络、预测可以用卡尔曼滤波加轨迹预测网络、规划可以用混合A*或优化求解器,控制则靠PID或线性二次调节器解决。团队也能按照模块划分职责,感知组的和规划组的可以并行开发,互不阻塞。

但问题也随之而来:模块之间的一切交互都发生在人工定义的接口上。感知层的输出不再是图像和点云,而是“类型为轿车、位置(100.2, 85.3)、速度18.6m/s、朝向正东”这样一条结构化的目标列表。预测层输入的是这个列表,输出的是每条目标的未来轨迹坐标;规划层再把这些目标轨迹和地图融合,生成路径。链路非常清晰,但每一层都在做“降维编码-解码”的操作,这中间的信息损耗就是传统架构最核心的隐形成本。

1.2 信息在接口之间“反复丢失”:模块化的隐性成本

我们来仔细复盘一遍丢失发生在哪里。

摄像头拍到的画面,其实包含了海量的驾驶环境信息:行人的姿态是弯腰还是站立、手臂有没有外展、目光是看着路面还是看手机;摩托车的轮子是否在轻微晃动;前方货车货架上有没有捆扎不牢的货物。这些原始特征对驾驶员判断意图至关重要。

但在经典感知模型里,它们会被压成“目标框+类别+速度”这个量级的结构化数据。模型只需要一个框框住行人,不需要知道行人是否点头、瞥望还是招手,因为这些姿态信息对“输出目标框”这个最终任务没有直接帮助。到了预测模块,它拿到手的只有几个运动学数据,没有姿态、没有纹理、没有历史图像帧,于是推断行人是否要横穿马路就变得非常困难。你看,感知模块在尽力提取“有用信息”,但这个“有用”是按接口设计时的偏见定义的,其他所有视觉线索统统被丢弃了,丢了一切可能对预测有用的线索。

这只是单向丢失,更麻烦的是级联误差。感知模块在雨雾天漏检了一个目标,预测模块根本不知道目标存在,规划模块就会堂而皇之地从目标原来所在的位置碾压过去。传统系统确实为感知引入了“漏检补盲、延迟补偿”之类的机制,但本质上还是拆东墙补西墙。

我做项目时有过一次很深的体会:某驾驶辅助车型在高速上遇到前车掉落了一个黑色塑料桶,感知模型把它识别为“不可通行障碍物”,结果预测模块强烈提示“目标静止,但置信度只有0.41”,规划模块出于安全考虑目标是“减速停车”,于是系统在超车道急刹,导致后方车辆险些追尾。事后复盘发现,感知模型有好几帧其实已经捕捉到了桶在滚动的纹理特征,但在输出接口时只保留了静态目标框,这部分关键信息就“死”在感知模块里了。模块化架构把完整驾驶任务切成了四个互不通信的“部门”,这种被迫的简洁性,在长尾场景里代价非常高。

1.3 长尾问题与“手工规则”的恶性循环

传统架构的另一个大坑,是规划模块的规则化实现方式。规划模块面对的是前面守好的目标列表,它需要在一个可行的状态空间内搜索最优轨迹,同时满足交规、舒适度和动力学约束。为了让系统适应各种复杂场景,工程师们绞尽脑汁,把交规、驾驶礼仪和方便的逻辑一步步手工编码成规则库,再配合有限状态机做场景的状态迁移:巡航到前车减速,就切换到跟车;旁边有车切入,就切换到避让;前方堵死,就切换到停车等待。

这套手工规则系统在受限场景下表现很好,但一旦遇到长尾场景,规则就会被搅得一团乱麻。例如“前车突然掉下一根钢管”,规则库可能压根没有“钢管”这个类别,更谈不上应该选择绕行还是急刹;再比如“路边的环卫工人突然弯腰捡东西”,有限状态机根本没法预测这个动作,只能靠默认的“刹车”救场,可这种“一键急停”天天来几次就变成了典型的假安全体验。

长尾场景无穷无尽,而人类的规则是有限的。于是工程师只能不停查漏补缺,把场景测试发现的问题一条条加进规则库。我见过某团队的时间状态机代码量,光一个路口切入场景就写了上千行if-else判断。更麻烦的是,加新规则往往会引发旧规则的副作用,比如为了躲避侧方加塞,你把跟车距离动态调大了一些,结果高速上正常巡航时又容易被人频繁加塞,于是还得再加一条规则来把跟车距离调小。系统在这种补丁叠补丁的循环中变得越来越臃肿,越来越难以维护。

长尾问题本质上是一个数据覆盖度问题,而规则化方法根本无法跟上真实世界场景维度的膨胀速度。所以行业里逐渐形成了一个共识:继续在模块化架构上打补丁,是在和维数灾难对抗,这条路的天花板已经依稀可见。

2. 端到端自动驾驶的核心逻辑:一次“感知-决策”的统一革命

2.1 一个模型,从像素到方向盘转角的直接映射

端到端自动驾驶的思路,说白了就是不再做“拆解加汇总”,而是直接训练一个大的神经网络,把传感器原始输入(摄像头图像、激光雷达点云)映射到最终控制指令(方向盘转角、刹车油门踏板深度)。这个过程中间没有一个模块是人工单独设计的,没有任何一个人去定义“目标”的中间表示,也没有人去手写“如果前车刹车灯亮就减速”这样的规则。

这种思路在深度学习的学术圈里其实早就不新鲜了。上世纪八九十年代,ALVINN项目就尝试过用单层神经网络把摄像头图像映射成转向命令,只是受限于算力、数据和网络结构,效果远达不到实用水平。直到近两三年,大算力GPU、大规模真实驾驶数据、以及Transformer等新一代网络结构的出现,让端到端自动驾驶重新回到聚光灯下,并第一次展现出超越传统系统的潜力。

一个典型的端到端模型,输入可以是多个摄像头的画面,输出则是一个多维向量,包括当前时刻的方向盘转角、期望速度、期望加速度,甚至还可以输出未来的轨迹点序列。整个模型的核心是一个特征提取网络,把原始图像压缩成高维特征张量;紧跟着的是一系列时空建模模块,比如利用注意力机制融合多摄像头信息、感知目标的历史轨迹;最后通过一个控制头,输出精确的连续控制量。

这样从输入到输出,全链路只有一个优化目标,也就是“让车辆行驶轨迹尽量贴近人类驾驶员的轨迹”。中间每个环节的特征表示都是网络自己学出来的,不再有人为定义,也不再有接口间的信息降维。

2.2 神经网络凭什么能替代四段式流水线:隐式表征与端到端优化

看到这里你可能想问:一个黑盒子凭什么就能替代一个成熟的多模块系统?

核心答案藏在“端到端”这三个字的数学意义上。传统模块化系统里,整个链路是串行结构,感知模块的训练目标是“把目标框检测准”,它并不知道它的输出会被下游如何消费;如果你拿感知模块的损失函数直接对整个系统做梯度回传,梯度根本无法穿过那些人工定义的结构化接口。端到端模型不是这样,整个网络是一个完全可微的复合函数,从控制头的输出误差出发,梯度可以一级一级反向传播到最前面的图像输入层。这意味着,网络中的任何一个参数都可以为了“整体控制效果更好”而被优化,所有中间特征都会自发地朝着“有助于最终控制”的方向演化。

我们用生活化的类比来理解这件事。传统模块化就像一家把“翻译”环节拆给三个不同部门的公司,客服转给运营,运营写成需求文档,开发再转成代码;每个部门都做得最好,但需求在下一次转达时总会变得面目全非。端到端则像是一个什么都懂的超级产品经理,把用户反馈直接变成代码提交,虽然中间过程是黑盒,但最终交付的东西质量最高。

从驾驶任务本身来看,人类驾驶员的“感知-决策”本来就是高度一体化的:眼睛看到前车刹车灯亮起,大脑立刻控制右脚准备踩刹车,而不是先经过一个“目标识别模块”,再经过一个“行为预测模块”,最后再加上“轨迹规划模块”才产出行动。神经网络在训练中完全可以学到这种高度耦合的感知-决策能力,而且它具备挖掘隐蔽特征的潜力——比如它可能自己学会通过观察前车的微小抖动来预判大货车即将变道,这种能力在人标注的目标框里几乎是表达不出来的。

2.3 与模块化路线的系统级对比

为了更直观地感受“新范式”的含义,我把两条路线放在同一张表格里做了个对比,方便各位技术选型时直接参考。

维度传统模块化架构端到端架构
信息传递方向逐级结构化降维,接口有损原始特征端到端无损传递
系统复杂度高度复杂,规则库庞大网络结构统一,复杂度前移
可解释性模块内部可解释,全局难统一黑盒,需要外部可解释性工具
所需数据各模块独立标注,数据类型多样需要大规模人类驾驶轨迹数据
对传感器标定依赖中等,模块级可补偿高度敏感,标定错误直接影响输出
长尾场景处理依赖规则补充,难发尽依赖数据覆盖,数据足够则泛化
开发迭代周期模块级迭代,联调时间长数据驱动,模型一键升级
下游任务自适应接口固定,扩展难网络自行学习,扩展灵活

从这张表可以看到,端到端并非在所有维度上都占优,它在可解释性、传感器标定鲁棒性和数据需求上其实是明显的短板。传统模块化最大的优势在于“各个击破”的开发便利性,但它的天花板——规则无法穷尽长尾、接口信息丢失——已经成为全行业的共识。端到端之所以叫“颠覆传统的新范式”,恰恰因为它用一种更接近人类驾驶本质的方式,把叠加了二十年的手工规则简化成一个可优化的连续函数。

3. 从理论到落地:搭建端到端自动驾驶系统的完整链路

3.1 数据是“燃料”:传感器标定、时间同步与数据质量

聊完理念,该聊聊怎么落地了。端到端模型不是算法工程师在办公室拍拍脑袋就能训练出来的,它背后最核心的资产其实是数据:人类驾驶员的真实轨迹数据。

第一步是数据采集车的构建。一套完整的数据采集系统需要包含高精定位模块、多个摄像头、激光雷达和惯性测量单元。这里最容易被低估的是时间同步和外参标定。算法工程师经常拿到数据集就开训,完全没意识到数据采集时如果摄像头和激光雷达的外参有哪怕几厘米的偏差,端到端模型就会把“看到的物体”和“实际位置”错误关联起来,训练出来的模型在实车上会产生持续的横向误差。

我们在某个模拟项目X里吃过一次大亏:有一辆采集车的外参标定文件里,某个摄像头相对车体的横滚角标错了0.8度,这个误差在单帧图像里人眼看不出任何问题,但端到端模型学习到的世界几何因此出现了系统性偏移。结果就是,模型在直道上行驶还算正常,一到弯道,车辆就会不断向内测修正车道,出现典型的“画龙”现象。排查了两周才定位到是数据源头的问题,从此我们把“采集车内参外参一致性校验”列为一个固定CI流程。

第二个数据质量的关键点是时间戳对齐。端到端模型要求输入是同一时刻下不同传感器的帧,如果摄像头帧和激光雷达帧相差了30毫秒,车辆在高速上已经运动了将近一米,模型学到的就是一组错位的对应关系。没有一个同步硬件方案,这个问题在软件层面很难彻底解决。现在主流做法是给每个传感器打上基于硬件同步信号的PPS时间戳,然后在模型输入时用插值或丢弃策略严格对齐。

除了硬件,数据覆盖度是另一个核心工程问题。一个合格的端到端训练集不能只包含晴朗白天的城市道路,应该覆盖夜间、雨天、逆光、隧道、施工区、小动物穿越、复杂路口、摩托车穿插等极端分布。我们在采集方案里会人为设计一定比例的长尾场景,比如专门在暴雨天气出车采集,在凌晨的环路上收数据,甚至在一些封闭测试场摆上各种异形障碍物做拍摄。这种做法成本很高,但却是端到端模型泛化性的根本来源。

3.2 模型架构选择:从CNN到Transformer的编码器-解码器设计

模型架构的设计思路,和自动驾驶的历史演进一脉相承。

早期的端到端模型是基于单张前视摄像头图像,用卷积神经网络提取特征,然后全连接层直接回归转向角。ALVINN项目用的是浅层网络,现代版本可以简单理解为一个轻量级ResNet或者MobileNet加上一个回归头。这类纯视觉模型的好处是部署轻量、推理快,但缺点是多摄像头信息和历史时序信息几乎没有被利用,单帧图像无法判断物体的运动趋势,更无法建立准确的空间拓扑。

到了今天,主流的端到端架构普遍采用“编码器-时空融合-解码器”三段式设计。

  • 编码器:每个摄像头视角的图像分别送入一个共享权重的主干网络,输出各自视角的特征图。常见主干包括ResNet-50、ResNet-101,以及基于自注意力机制的ViT或Swin Transformer。由于端到端模型对空间分辨率要求高,通常在图像层面输入分辨率会达到1280x720甚至更高,网络也会使用FPN结构来保留多尺度语义。
  • 时空融合模块:这一步是整个系统的关键创新所在。多视角图像的特征会在一个统一的鸟瞰空间或者前向空间表达中做融合。例如,我们可以利用可学习的查询向量,通过Transformer解码器把多个视角的特征交叉注意力地聚合到一个统一的空间表示里。同时把历史帧的特征通过时序注意力模块进行跨帧聚合,让模型理解运动信息。
  • 解码器:最后基于融合好的特征,用小型网络输出当前时刻的控制指令与未来轨迹。为了提升可解释性,很多方案会额外输出中间监督的头,比如预测目标物体的占用网格、预测车道的几何结构,这叫“多任务头”。它们不会干扰主任务,但可以让模型更快收敛,同时为工程师提供一定的可视化诊断依据。

在实际项目中,我们对模型规模的选择建议是:优先考虑算力平台的能力,不要一开始就堆一个几百亿参数的大模型。车端推理部署要求实时性达到15赫兹以上,为了在有限算力下运行,量化感知训练、模型剪枝、算子融合都是必做的功课。以我们某跨平台系统的经验来看,一个MobileNet编码器加轻量化Transformer Fusion的模型,在车载嵌入式平台上能做到4到6毫秒的单帧推理,完全满足实时要求。

3.3 训练策略:模仿学习、强化学习与多任务学习

模型结构是一辆车的骨架,训练策略则是它的发动机。端到端自动驾驶目前主流的训练方法有三种。

模仿学习是目前最直接、最主流的方式。简单说,就是让模型从人类驾驶员的真实轨迹中学习“如果我看到这个场景,我应该怎么打方向盘、怎么给油门”。我们采集到的大量带标签数据,标签就是方向盘转角、车速、刹车油门深度,以及专家轨迹。训练时直接最小化模型输出与专家动作之间的误差。这类方法很好理解,但坑也明显:模型容易陷在“高频率场景”里,比如一直学的是直道行驶,结果对罕见的弯道场景就没有反应。为了缓解这个问题,我们会在训练集里做数据平衡采样,刻意提高弯道、路口等罕见但关键场景的权重。

强化学习是模仿学习之后的进阶版本,模型不再直接模仿人类,而是在环境交互中通过奖励函数学习最优策略。奖励函数至今仍然是一个玄学:安全性奖励、乘坐舒适性奖励、达到目的地的效率奖励,怎么加权怎么平衡都需要反复试。强化学习在仿真环境中表现亮眼,但在真实道路上有安全风险,所以目前更多用在仿真环境中做“预先打磨”,训练完之后再把策略迁移到真实世界。

多任务学习则是一种务实的工程选择。端到端模型的主任务是“输出控制指令”,但如果我们同时让它预测“前车在未来三秒的位置”“车道线的像素级分割”“自身与道路边界的横向距离”,那么主干特征就会学到更鲁棒的几何结构和语义信息。我们实测下来,加入中间监督后,端到端模型在夜间和雨天的表现都有明显提升,相当于给黑盒加装了骨架。

有趣的是,即使只用模仿学习,工程上还有一个极其影响最终效果细节:动作的平滑化。人体驾驶员的转向和油门信号本身就带噪声,如果我们直接拿原始信号做回归目标,模型会学到陡峭且高频的抖动。我们通常会先对专家动作序列做平滑滤波,然后再监督模型预测下一时刻的动作,同时加上对动作导数的正则项,比如限制方向盘的角加速度,这样可以显著提升模型的平顺性。

3.4 仿真与实车部署:虚拟环境+真实道路的闭环验证

真实的端到端自动驾驶模型,不能只在训练集上表现好,还必须在各种各样的环境里进行验证。这里的验证通常分两步走:仿真验证和实车验证。

仿真验证的价值在于可以快速生成大量边缘场景,比如模拟暴雨、模拟大雾、模拟对面车辆远光灯照射、模拟车道标志缺失。我们会在仿真环境里跑一套标准化的场景库,每晚定时触发几百个测试场景,对模型输出的安全性指标、偏离车道次数、与目标物的最小距离等做自动统计。一旦回归性指标恶化,就会报警。

不过仿真环境再怎么逼真,和真实物理世界还是有鸿沟,尤其是轮胎与地面的摩擦特性、悬挂系统的动态响应、车身的弯矩震动,这些车动力学层面的细节是仿真难以完全复刻的。因此实车排障始终是最终验收。我们的做法是先在封闭测试场做一支“验证车队”,先跑低速直线、标准掉头、U型弯等基本功,然后逐步扩大到封闭园区、再到半封闭道路、最后才到公开路段。每一次实车测试,都会记录模型输出和真实车辆响应之间的差异,拿到问题后回到仿真环境重现,不断迭代。

在实车部署阶段,一个特别容易出问题的点是模型推理的延迟。仿真中发现模型在GPU上单帧只用了5毫秒,看似安全,但实际车上的传感器数据需要经过图像编码、传输、候选区域预处理、推理、后处理再到控制指令下发,整个pipeline的延迟要远高于纯模型耗时。要是端到端模型引起额外30毫秒延迟,车辆在80公里/小时的速度下就多走了三分之二米,你的“安全余量”就这样被悄悄吃掉了。所以我们在开发时一定会对模型做延迟优化,并引入延迟补偿机制,用模型输出的未来几个周期的预测量来抵消系统延迟。

4. 实战中的避坑指南:我踩过的那些坑与解决办法

4.1 传感器标定误差的“蝴蝶效应”

这个坑前文已经提过一次,但值得单独拿出来再说一遍:在端到端系统里,传感器标定误差会被放大到不可思议的程度。

传统模块化系统里,某个摄像头的外参偏了一点,感知模块输出目标框的时候可能只是框右下角稍微偏了几厘米,预测和规划模块有其他传感器(比如激光雷达)来互相纠正,不太会直接影响最终轨迹。但在端到端模型里,所有摄像头和激光雷达的特征会先在网络内部做融合,如果标定错了,特征融合的空间坐标就先天不对齐,模型就必须靠训练数据里的统计规律硬记一套扭曲的几何映射。结果就是,它能在你测试的那条专用环路上表现得很完美,一旦换了其他道路,横向误差立刻暴露出来。

我们的应对策略是把“标定一致性检查”变成一个常驻在线任务。每次车辆启动时,系统会通过车道线重投影偏差、激光雷达与摄像头的边缘对齐误差等指标自动判断标定状态;一旦超出阈值,就禁止启动自动驾驶功能并提示人工检修。另外在训练端,我们也会故意做“标定随机扰动”数据增强:每次给模型喂样本时,把外参随机加一个微小扰动,模拟标定误差,这样模型自己就具备了一点点抗标定漂移的能力。实测下来效果立竿见影,换车标定后系统横向误差下降了四成。

4.2 数据分布偏斜:让模型在夜间/雨天“失明”

刚才我说数据要有覆盖度,但光有覆盖度还不够,数据分布偏斜是另一种隐性灾难。

我们曾经有一个模型,白天晴天的成功率接近99%,但一到下雨天就接连出鬼故事:雨刮器的阴影被误识别为前车轮廓,积水反光导致车道线偏移,雨点在夜间被车灯一照变成类似“鬼影”的光斑。训练数据里其实有相当比例的雨天样本,但比例只有5%,远远不够让模型把雨滴噪点和真实障碍区分开。

解决办法分三个层面。第一是数据重采样:把那些表现明显较差的场景占比强制提高,比如夜间20%、雨天25%、逆光10%,宁可牺牲一些白天直道样本,也要让模型在这些难例上过拟合。第二是数据增强:利用色彩抖动、模拟雾气、添加随机雨线噪点、模拟雨刮器遮挡等图像退化手段,低成本地制造海量难例。第三是主动难例挖掘:在实车和仿真里跑模型,把那些端到端模型输出置信度低、轨迹波动大的片段自动采集下来,交给数据团队加标签并补充进训练集。

经过这三板斧调整之后,我们模型的雨天视频测试通过率从61%直接拉升到88%,这个提升幅度说明,端到端模型在数据层面的潜力比传统模块化大得多,只要“喂”得准,它很乐意去学那些我们觉得它学不会的东西。

4.3 模型可解释性与安全冗余:监管和测试的“紧箍咒”

端到端系统最被攻击的点,就是黑盒。在传统架构里,测试人员至少能够说:“你看,是感知模块漏检了目标框,所以规划模块才没刹车。”而在端到端系统里,模型只是输出一个转向信号,出了事故,你很难定位到是“感知”错了还是“决策”错了。

为了解决这个问题,我们做了三件事。

第一件事是给模型加“可解释性出口”。不是改变模型的决策方式,而是在模型主干中额外训练一个“注意力图”头,它能输出每个输入像素对整个控制决策的贡献权重。展示在可视化工具上,工程师可以直接看到模型在转弯时到底是盯着车道线还是盯着路边行人。有一次我们通过注意力图发现模型在夜间总是“盯”着对向车道的远光灯,导致转向提前,原因就是白天数据里很少有远光灯干扰,模型把“前方亮点”当成了障碍物。这个发现靠传统测试要费几个小时,而注意力图一次调试就揪出来了。

第二件事是安全冗余层。即便端到端模型是主力,我们依然会在外围套上独立的安全监控模块,比如前向碰撞预警、限速保护,一旦检测到端到端输出异常,比如连续急转、靠近高风险区域,安全监控会通过仲裁机制接管车辆。这套设计本质上是用一个简单但可靠的规则系统,给黑盒兜底。

第三件事是数据回放测试。我们在发布每个模型之前,都会用全天候的驾驶数据做自动回放,统计在每个场景子类上的指标,再结合注意力图分析异常。这样做是为了满足安全评审的要求,也是为了让工程师自己心里有底:模型不是在“盲开”。

4.4 性能评估:离线指标不等于上车体验

最后聊聊评估,这是很多团队踩得最痛的坑。模型在离线测试集上的loss降到了很低,你是不是就以为可以上车了?大错特错。

离线loss低,只能说明模型输出的动作和专家动作的平均误差小,但它完全无法反映“真实驾驶体验”。比如模型在弯道中可能出现高频抖动,虽然平均误差不大,但实车乘坐体验像坐过山车;再比如模型在接近路口时习惯性提前减速,导致跟在后面的车老是要急刹,安全隐患极大。

所以我们的评估体系,会分成三个层级。

  • 指标层:回归loss、轨迹偏差、方向盘转角变化率、横向加速度峰值等数值。
  • 场景层:在仿真里统计“是否压线”“是否与前车距离过近”“是否超出安全边界”等离散事件。
  • 体验层:邀请参与试驾的同事主观打分,并在封闭场地用编队车辆做一些互动博弈式测试。

经验之谈:不要只看单一指标。有一次我们发现一个模型在标准场景测试集的loss低了0.2,但上车体验感全线拉胯,原因是它在变道时习惯性压着最低横向加速度走,结果经常让后方车辆误以为它要强行并入。这个毛病靠离线指标根本测不出来,只有把“变道频率”“平均变道时段”“后方借道触发率”这些场景级指标纳入sanity check才能发现。

5. 未来演进:从“端到端”到“可解释端到端”,以及商业化路径

5.1 可解释性不再只是“软需求”

刚才说到注意力图时,有同学可能会问:“注意力图真的能揭示模型的底层逻辑吗?”我的回答是:它揭示的是一种“关联性”而不是“因果性”,但对工程调试已经足够有价值了。未来可解释性的研究重点,一定会从“这张图很漂亮”演进到“如何让模型在决策时主动使用可解释的中间表征”。

目前已经有方案提出“结构化端到端”的思路,即不直接让网络输出方向盘转角,而是先预测一个低维的“驾驶意图空间”,比如“是否让行”“是否变道”“目标车道线位置”,再经过一个可微的策略层生成控制指令。这样模型在用数据驱动方式进行决策的同时,依然保留了对人类可理解的中间语义的约束。它将融合端到端的高性能和模块化的可审查性,是我认为最有前景的演进方向之一。

5.2 车路协同如何反哺端到端模型

端到端自动驾驶目前主要靠单车自己“看”,但未来的交通系统一定会进入车路协同时代。路侧的红绿灯信息、拥堵预警、盲区车辆状态都能通过车联网传递给车辆,这些信号如果也能像摄像头图像一样,作为额外输入接入端到端模型,那么整个系统就具备了“上帝视角”。

我们做过一个模拟实验:在模型输入中接入前方交叉路口的实时V2X信号,模型在无保护左转场景下的成功率提升了近20%。这不是传统规则系统能做到的,因为规则系统需要人工定义“如果收到什么信号就做什么动作”,而端到端模型只需要把这些信号当成一种新的输入通道,就能自动学会它们与驾驶动作之间的可量化关系。未来车企与道路基础设施运营商之间的数据合作,大概率会围绕这个方向展开。

5.3 我的判断:哪些场景会最先落地

虽然业内都在高喊端到端“颠覆传统”,但真正商业化落地需要冷静,我认为最先跑通的全场景,大概率集中在三个梯度。

第一梯队是封闭园区内的低速物流车、矿区运输车以及自动泊车。这些场景速度低、道路环境可控、安全风险相对有限,端到端模型能快速积累数据并迭代。

第二梯队是高速公路上的领航驾驶。虽然没有完全封闭,但高速场景相对结构统一、车道线清晰、驾驶行为模式化,端到端系统在安全冗余层的辅助下,可以大幅提升驾驶员的一通到底体验。

第三梯队才是复杂的城市开放道路,包括无信号灯路口、机非混行、施工绕行等。这个梯队的全面落地,可能需要等待车路协同基础设施成熟、以及法规对端到端系统的严格认证标准出台,三到五年的周期是少不了的。

最后分享一个我个人的小建议:做端到端项目时,不要一上来就追求“纯又纯”的端到端,也不要直接拥抱“模型万能论”。在工程落地的全链条里,一条又一条的规则和外部安全机制都是必须存在的”安全带“。先把数据飞轮转起来,把模型从“能跑”打磨到“爱跑”,端到端自动驾驶的颠覆性,才会真正在道路上被证明。

RELATED READING

延伸阅读

更多一线实战笔记与深度复盘,助您持续精进