★ FEATURED ARTICLE 自动驾驶这个圈子里这两年最明显的变化不是哪个传感器又降价了而是“基础模型”这个词开始密集出现在工程讨论、招聘要求和项目立项书里。我前后花了两周时间啃完这篇名为《A Survey for Foundation Models in Autonomous Driving》的综述最大的感受是它把过去散落在感知、预测、规划、数据闭环各个角落的工作用“基础模型”这一条主线串了起来。这篇综述讨论的核心是大规模预训练模型如何进入自动驾驶技术栈涉及视觉基础模型、多模态大语言模型、世界模型、端到端驾驶策略等方向覆盖面相当广。它适合三类人刚入行的算法工程师可以拿它当技术地图做系统架构的可以拿它做选型参考做数据闭环的能从中找到自动标注与场景生成的落地思路。下面我不做逐段直译而是按自己的理解把这篇文章的骨架拆开把里面值得深挖的点补上工程层面的细节。1. 这篇综述到底在解决什么问题1.1 从模块化堆叠到统一表征的范式迁移传统自动驾驶栈是典型的分模块设计感知负责检测、分割、跟踪预测负责轨迹推演规划负责决策控制负责执行。每个模块有独立的数据集、独立的评价指标、独立的模型版本。这套架构的好处很实在——可解释、可局部调试、出问题能快速定位到某个环节。但它的毛病也同样明显模块之间的信息损失严重。感知模块输出的是框和类别这些符号化结果到了预测模块手里原始像素里那些丰富的纹理、光照、材质信息基本被丢干净了。一个被部分遮挡的骑行者感知给个低置信度的框预测模块就只能在这个模糊输入上做推演。综述反复强调的一个判断是基础模型提供了另一种可能——用大规模预训练得到的通用表征把多个环节打通。这里的逻辑不难理解。预训练模型在海量数据上学到的是世界的统计规律比如物体的形状先验、场景的几何结构、运动的一致性约束这些知识不是针对某个具体任务标注出来的而是从数据分布里自然涌现的。下游任务只需要少量微调就能借用这些通用知识。我自己的体会是这种迁移在数据稀缺的长尾场景上收益最明显因为微调阶段见过的样本少模型更多是在靠预训练阶段积累的先验做判断。1.2 综述的覆盖面与组织逻辑这篇综述采用了一个双维度交叉的组织方式一个维度是基础模型的类型另一个维度是自动驾驶的任务环节。类型上它覆盖了视觉基础模型以Transformer为骨干的一类、多模态大模型视觉-语言联合建模、世界模型对未来观测或状态进行预测、以及面向决策的大规模序列模型。任务上覆盖感知、预测、规划、仿真、数据生成这几个主要环节。这种组织方式的好处是读者能按需检索想查感知就翻对应章节想查数据闭环也有专门段落。坏处也很直接同一项工作可能在不同章节反复出现因为一项工作往往同时涉及模型类型和任务环节两个属性。我读第一遍的时候有点晕后来自己做了一张映射表把每个方向的核心工作、输入输出形式、评价指标列成三列技术演进路线才清晰起来。这个动作建议每个读者都做一遍比单纯顺着读效率高得多。1.3 为什么值得花时间读这类综述工程上最怕的不是难而是重复造轮子。一个团队闷头做了半年的自动标注方案结果发现综述里早就总结过同类思路的三种变体和各自的失效边界这种浪费是真实存在的。综述的价值就在于它把散落在不同论文里的共性问题和差异化方案摆在一起让你在做技术选型之前先看清楚地形。另一个容易被忽略的价值是评价体系的差异。感知任务习惯用mAP和NDS规划任务看碰撞率、舒适度和通行效率语言模型那套又变成了BLEU、CIDEr或者人工评分。这些指标背后的假设不一样有的假设类别闭集有的假设场景分布稳定。不理解这些假设跨方向比较模型性能就是自欺欺人。综述在这方面给了不少提醒我后面会结合具体例子展开。2. 基础模型在自动驾驶里的四类落点2.1 感知层从闭集检测走向开放词汇理解传统检测是闭集范式训练时定义了哪些类别推理时只能输出这些类别遇到没见过的物体要么漏检要么强行归到某个已知类。基础模型带来的开放词汇能力改变了这个局面。背后的技术路线主要是对比学习把图像和文本描述映射到同一个语义空间让匹配的图文对距离近、不匹配的远。这样一来推理时给一个文本查询比如“路边倾倒的共享单车”模型就能在图像里找对应区域不需要这个类别出现在训练标签里。听起来很美实际落地有坑。车载相机拍到的图像和互联网图文对之间存在明显的域差异视角低、动态模糊多、夜间光照极端、雨雪天气干扰强。直接拿通用模型的特征做零样本检测召回率通常撑不住。比较务实的做法是把预训练模型当骨干用在自己的数据上做微调同时保留开放词汇的文本分支作为补充通道主检测头还是走闭集监督。这样既拿到了预训练表征的红利又不至于让线上指标失控。具体到架构上视觉基础模型和BEV表征的结合是目前讨论最多的方案。流程大致是多路相机图像先过预训练ViT骨干提取多尺度特征然后通过视角转换模块把图像特征投到鸟瞰图空间再做时序融合最后接不同的任务头。视角转换有两条主流路线一条是基于深度分布的显式投影另一条是基于注意力采样的隐式查询。前者可解释性强但深度估计误差会传导后者灵活但对训练数据量要求高。2.2 预测与规划层把驾驶当成序列决策问题预测模块的核心是建模交通参与者之间的交互。早期做法是给每个参与者单独编码历史轨迹再用图神经网络或者社会池化层聚合邻居信息。基础模型思路引入后主流方案变成了向量化表征加Transformer把场景里的车道线、交通元素、参与者轨迹都切成片段每个片段编码成一个token然后让注意力机制自己去学哪些片段之间有关联。这种做法的好处是不需要手工设计交互规则模型能从数据里学到“前车急刹时右侧车道车辆会犹豫”这类隐式知识。规划层的尝试更大胆一些。有一类工作把驾驶场景用自然语言描述出来比如“前方路口绿灯左侧有车接近本车时速四十”然后让语言模型输出决策指令或者高层动作。这类方案的优势是能利用语言模型的世界知识和常识推理处理一些规则难以覆盖的模糊场景。但风险同样突出语言模型的输出不可控可能生成语法通顺但物理上不可行的指令。工程上必须加约束解码或者后处理校验把输出限制在可行的动作空间内。我个人对这条路线持谨慎乐观态度它在解释性和人机交互上有独特价值但短期内不太可能替代基于优化的规划器。2.3 数据闭环自动标注与场景生成如果说基础模型在哪个环节落地最快我的答案是数据闭环。自动驾驶最贵的成本之一就是标注尤其是三维框标注和语义分割标注人工成本高、周期长。用大模型做离线自动标注人工只做抽检和修正这套流程在很多团队已经跑通了。自动标注的关键是精度和召回的权衡。大模型标注的召回通常不错能发现人工容易漏掉的远处小目标但精度会差一些边界框贴合度不够。实际做法是设置双阈值高置信度结果直接入库中等置信度结果进人工复核队列低置信度丢弃。这个阈值怎么定需要拿一批人工标注的黄金数据做校准画精度-召回曲线找业务能接受的工作点。场景生成是另一条路。用扩散模型或者神经渲染技术合成corner case比如罕见的事故形态、极端的天气组合。这条路的技术难点不在于生成得像而在于生成得对——物理规律要自洽交通参与者的行为要合理传感器的噪声特性要匹配真实设备。我见过一些生成数据训出来的模型在仿真里表现很好一上实车就崩原因就是生成数据的分布和真实分布有系统性偏差。所以生成数据的使用比例要严格控制并且必须留出真实数据做验证集。2.4 座舱交互语言模型的价值边界座舱场景是语言模型落地阻力最小的方向因为它和驾驶栈相对解耦出问题的影响面可控。常见的应用包括多轮对话式的车辆控制、基于场景的主动服务推荐、以及驾驶员状态的语义理解。这里要说清楚价值边界。语言模型擅长的是意图理解和自然语言生成不擅长的是精确的数值计算和实时性要求极高的决策。让模型理解“我有点冷”并调高空调温度这是合理用法让模型直接计算刹车距离这是错误用法。另外幻觉问题在座舱场景同样存在模型可能编造出不存在的车辆功能。工程上需要用工具调用或者检索增强的方式把模型的能力约束在真实可用的功能集合内。3. 关键技术拆解这些模型凭什么能用3.1 视觉基础模型与BEV表征的结合细节BEV表征之所以成为主流是因为它把多视角的图像统一到了一个物理意义明确的平面上下游的检测、预测、规划都能在这个平面上做坐标系一致融合自然。视觉基础模型进来之后变化主要在骨干网络和预训练策略上。传统BEV方案多用ResNet做骨干原因是它在检测任务上成熟、推理速度快。换成ViT之后全局感受野带来的收益在远距离目标和大范围场景理解上比较明显但代价是显存和延迟。我在一个六路相机输入的项目里做过对比测试输入分辨率统一缩到256乘704patch大小16每路图像产生约700个token六路合计四千出头。这个量级下ViT-B还能在单卡上跑起来ViT-L就必须上梯度检查点加混合精度训练吞吐掉到原来的三分之一左右。预训练权重的来源也值得说。自然图像上预训练的权重直接迁移到车载图像效果会有折扣因为两者的成像特性差异大。比较稳的做法是先用大规模行车数据做自监督预训练比如掩码图像重建或者对比学习再在具体任务上微调。自监督的好处是不需要标注能充分利用车队回传的海量无标注数据。3.2 多模态对齐的难点在哪里多模态大模型在自动驾驶里的用法大致可以分成两类一类是把视觉特征对齐到语言空间用于开放词汇感知和场景描述另一类是把语言指令作为条件引导模型完成特定任务。对齐的第一难点是数据。高质量的图文配对数据在自动驾驶领域非常稀缺互联网上的图文对和驾驶场景差异太大。常见的做法是用规则模板从标注数据自动生成描述文本比如根据检测框的位置、类别、运动状态拼出一句话。这种合成数据的优点是规模大、可控缺点是语言风格单一模型学到的表达多样性不足。第二难点是粒度。驾驶场景的描述需要精确到米级和秒级而通用视觉-语言模型训练时用的描述往往是粗粒度的。“前方有车”和“前方三十米处有一辆时速二十的白色轿车正在向左变道”这两句话对应的监督信号强度完全不同。要训练出后一种能力需要在数据构造阶段就把细粒度信息注入进去。第三难点是评测。语言生成任务的自动指标和实际驾驶需求之间的相关性很弱。一句描述在BLEU上得分高不代表它包含了规划模块需要的关键信息。比较靠谱的评测还是靠下游任务的表现倒推比如把生成的场景描述喂给规划模块看决策质量有没有提升。3.3 世界模型与仿真预测未来的能力世界模型这个概念在综述里占了不小的篇幅它的核心能力是给定当前观测和动作预测未来的观测或者隐状态。用途有两个方向一是作为仿真环境生成逼真的未来画面供规划模块训练二是作为辅助训练目标逼迫模型学到物理规律和因果结构。作为仿真环境使用时最大的挑战是误差累积。自回归地预测未来帧每一步的小误差会在几十步之后放大成完全不同的场景。工程上的缓解办法是缩短预测窗口只预测未来一两秒然后用真实的下一帧重新锚定。另一个办法是引入物理约束比如光流一致性、深度一致性让生成的画面在几何上说得通。作为辅助训练目标使用时世界模型更像是一种正则化手段。让感知模型不仅要完成检测任务还要能预测下一帧的特征表示这会促使它学到更有预测性的表征。这类做法在小样本场景下提升明显但需要仔细调权重辅助损失太强会干扰主任务收敛。3.4 端到端方案的诱惑与风险端到端是综述里讨论最热烈的方向之一思路是把感知到控制的链路打通用一个大模型直接从传感器输入映射到控制输出或者规划轨迹。它的理论优势很吸引人信息无损传递所有环节可以联合优化避免了模块化设计中的信息瓶颈。但风险同样真实。第一是可解释性差模型输出的轨迹如果异常很难定位是感知错了、预测错了还是决策逻辑有问题。第二是长尾场景难调试模块化架构下发现某个场景失败可以针对性补充该模块的训练数据端到端架构下你很难判断应该往训练集里加什么类型的数据。第三是训练数据的分布问题端到端模型对训练数据的覆盖度要求极高稍微偏离分布就可能出现不可预期的行为。我的判断是端到端在限定场景比如结构化道路、低速泊车里会先落地全场景端到端还需要较长时间。过渡期的务实方案是部分端到端比如感知和预测联合训练规划和控制的接口保留显式表达兼顾优化收益和可调试性。4. 实操视角怎么在自己的项目里试起来4.1 数据准备与预处理的关键参数动手之前先把数据这件事想清楚。以常见的城区多传感器数据集为例典型配置是六路相机加激光雷达相机帧率十二赫兹图像分辨率在900乘1600这个量级。直接拿原始分辨率喂给ViT是不现实的token数量会爆炸。工程上通常缩到256乘704或者384乘1056等比缩放保持宽高比多余部分做padding。这里有个细节容易被忽略缩放会改变内参如果后续要做几何投影内参矩阵必须同步更新换算关系。我见过有团队在预处理阶段缩了图但忘了改内参导致BEV投影整体偏移排查了两天才发现问题。标注规范也要提前统一。三维框的中心点定义、朝向角的范围、遮挡等级的划分这些在不同数据集里的约定不一样混合训练之前必须做归一化。相机和激光雷达的时间同步误差要控制在毫秒级否则高速运动目标会出现重影。4.2 模型选型与显存预算估算选型的第一步是算显存。粗略的估算方法是这样激活值占用的显存大致和batch size、token数量、隐藏维度、层数成正比再乘一个与具体实现相关的系数。以六路相机、输入256乘704、patch size 16为例每路约700个token六路合计约4200个token。在fp16精度下ViT-B级别骨干、batch size为2时仅前向激活就需要十几个GB反向传播还要再翻倍加上优化器状态单卡24GB会比较紧张。我给一个实际项目里测过的对比表数字是粗估具体会随实现差异浮动骨干类型参数量单卡显存占用batch2fp16相对训练吞吐ResNet-50约25M6GB左右基准1.0ViT-S/16约22M9GB左右0.85ViT-B/16约86M14GB左右0.55ViT-L/16约307M28GB以上0.3以下看到这个表就明白为什么很多团队在实车部署时还是选CNN骨干延迟和显存是硬约束。折中方案是用ViT-Tiny或者混合架构前面几层用卷积做局部特征后面接少量注意力层做全局建模。4.3 训练策略与微调技巧学习率设置上预训练骨干的学习率要比新初始化的任务头低一个量级左右常见配置是骨干1e-5任务头1e-4。warmup步数建议占总步数的百分之五到十尤其是用大骨干的时候warmup太短容易在训练初期把预训练权重破坏掉。混合精度训练基本是标配但要注意梯度裁剪和损失缩放。我遇到过loss突然变成NaN的情况排查下来是某个batch里出现了异常大的梯度加了梯度裁剪之后稳定了。梯度检查点能显著降显存代价是训练速度下降三成左右是否开启取决于显存瓶颈还是速度瓶颈。冻结策略也值得说。全量微调效果最好但成本最高只训任务头成本最低但迁移效果打折折中方案是冻结骨干的前若干层只微调后几层加任务头。我的经验是数据量小于一万帧时用折中方案数据量充足时全量微调更划算。4.4 评测指标体系怎么搭感知任务的评测相对成熟检测看mAP和各类别的召回分割看mIoUBEV任务还有专门的复合指标。但要注意这些指标都是闭集假设下的如果你的模型带开放词汇能力需要额外设计评测协议比如用留出类别做零样本测试。规划任务的评测更复杂。碰撞率是最硬的指标但光看碰撞率不够还要看舒适度加速度和加加速度的分布、通行效率到达目的地的时间、以及合规性是否遵守交通规则。这几个指标之间往往互相制约激进策略通行效率高但舒适度和安全性差保守策略反过来。实际评测时要根据业务场景设定权重没有 universally 最优的组合。端到端模型的评测最难。建议的做法是分层评测既看最终的规划输出质量也看中间表征的质量比如用探针任务测试表征里是否编码了关键信息。这样出问题时至少能定位到大概环节。5. 常见问题与排查技巧实录5.1 训练不收敛的排查路径第一步看数据。把batch里的图像和标签可视化出来检查有没有标注错位、图像损坏、类别极度不平衡的情况。我遇到过标签坐标系搞反导致模型完全学不动的问题可视化一眼就看出来了。第二步看损失曲线。如果训练损失下降但验证损失上升是过拟合加数据增强或者正则。如果两个都不降检查学习率是不是太大或者太小检查梯度范数是否异常。如果损失出现周期性震荡多半是batch size太小或者学习率调度有问题。第三步看预训练权重有没有正确加载。层名不匹配导致部分权重没加载上这种情况很隐蔽模型能训但效果明显低于预期。加载后打印一下匹配上的参数比例低于九成就要警惕。5.2 部署阶段的坑训练环境跑通不代表车上能跑。常见的坑包括算子不支持某些注意力实现在特定推理框架里没有优化实现速度慢得离谱精度差异fp16训练fp32推理或者反过来数值行为可能不一致动态shape车上输入分辨率可能随场景变化模型要能处理变长输入。还有一个容易被忽略的点是内存碎片。长时间运行后显存碎片化会导致偶发的分配失败表现是跑几个小时突然崩一次。解决办法是预分配固定大小的内存池避免频繁申请释放。5.3 常见问题速查表现象可能原因排查动作训练loss不降学习率过大、标签错位、权重未加载可视化数据、打印梯度范数、检查权重匹配率验证指标远低于训练过拟合、数据分布不一致检查增强策略、对比训练验证集分布推理速度不达标算子未优化、输入分辨率过高profile各层耗时、尝试降低分辨率或换骨干偶发崩溃显存碎片、数值溢出预分配内存池、加梯度裁剪和数值检查开放词汇召回低域差异大、文本查询粒度不当用目标域数据微调、调整查询模板生成数据训练效果差分布偏差、物理不一致控制生成数据比例、加真实数据验证5.4 几条踩坑之后才明白的经验第一条不要迷信大模型。参数量翻倍带来的收益在数据量不足时非常有限有那个算力不如先把数据质量和标注一致性提上去。第二条评测集要独立且固定。我见过团队反复在同一个验证集上调参最后指标很好看但实车一塌糊涂。验证集的使用次数要有纪律。第三条模块化架构在现阶段的工程价值被低估了。端到端很美好但出问题时你能快速定位到具体模块这个能力在量产项目里值很多钱。第四条多模态对齐的效果很大程度取决于数据构造的精细度模型结构反而是次要因素。同样的架构细粒度描述数据训出来的效果能甩粗粒度数据一大截。我个人在这个方向上的体会是基础模型给自动驾驶带来的最大改变不是某个具体指标提升而是工作方式的转变——从“针对每个任务设计专用模型”变成“先找一个好的通用表征再想办法适配任务”。这个转变对团队的能力结构提出了新要求既要懂预训练和微调也要懂传统自动驾驶的工程约束两头都懂的人目前还是稀缺的。
阅读完成 · 觉得有帮助？
