企业官网建设流程全解析

自动驾驶这个圈子里，这两年最明显的变化不是哪个传感器又降价了，而是“基础模型”这个词开始密集出现在工程讨论、招聘要求和项目立项书里。我前后花了两周时间啃完这篇名为《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乘704，patch大小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会比较紧张。

我给一个实际项目里测过的对比表，数字是粗估，具体会随实现差异浮动：

看到这个表就明白为什么很多团队在实车部署时还是选CNN骨干：延迟和显存是硬约束。折中方案是用ViT-Tiny或者混合架构，前面几层用卷积做局部特征，后面接少量注意力层做全局建模。

4.3 训练策略与微调技巧

学习率设置上，预训练骨干的学习率要比新初始化的任务头低一个量级左右，常见配置是骨干1e-5，任务头1e-4。warmup步数建议占总步数的百分之五到十，尤其是用大骨干的时候，warmup太短容易在训练初期把预训练权重破坏掉。

混合精度训练基本是标配，但要注意梯度裁剪和损失缩放。我遇到过loss突然变成NaN的情况，排查下来是某个batch里出现了异常大的梯度，加了梯度裁剪之后稳定了。梯度检查点能显著降显存，代价是训练速度下降三成左右，是否开启取决于显存瓶颈还是速度瓶颈。

冻结策略也值得说。全量微调效果最好但成本最高；只训任务头成本最低但迁移效果打折；折中方案是冻结骨干的前若干层，只微调后几层加任务头。我的经验是数据量小于一万帧时用折中方案，数据量充足时全量微调更划算。

4.4 评测指标体系怎么搭

感知任务的评测相对成熟，检测看mAP和各类别的召回，分割看mIoU，BEV任务还有专门的复合指标。但要注意这些指标都是闭集假设下的，如果你的模型带开放词汇能力，需要额外设计评测协议，比如用留出类别做零样本测试。

规划任务的评测更复杂。碰撞率是最硬的指标，但光看碰撞率不够，还要看舒适度（加速度和加加速度的分布）、通行效率（到达目的地的时间）、以及合规性（是否遵守交通规则）。这几个指标之间往往互相制约，激进策略通行效率高但舒适度和安全性差，保守策略反过来。实际评测时要根据业务场景设定权重，没有 universally 最优的组合。

端到端模型的评测最难。建议的做法是分层评测：既看最终的规划输出质量，也看中间表征的质量，比如用探针任务测试表征里是否编码了关键信息。这样出问题时至少能定位到大概环节。

5. 常见问题与排查技巧实录

5.1 训练不收敛的排查路径

第一步看数据。把batch里的图像和标签可视化出来，检查有没有标注错位、图像损坏、类别极度不平衡的情况。我遇到过标签坐标系搞反导致模型完全学不动的问题，可视化一眼就看出来了。

第二步看损失曲线。如果训练损失下降但验证损失上升，是过拟合，加数据增强或者正则。如果两个都不降，检查学习率是不是太大或者太小，检查梯度范数是否异常。如果损失出现周期性震荡，多半是batch size太小或者学习率调度有问题。

第三步看预训练权重有没有正确加载。层名不匹配导致部分权重没加载上，这种情况很隐蔽，模型能训但效果明显低于预期。加载后打印一下匹配上的参数比例，低于九成就要警惕。

5.2 部署阶段的坑

训练环境跑通不代表车上能跑。常见的坑包括：算子不支持，某些注意力实现在特定推理框架里没有优化实现，速度慢得离谱；精度差异，fp16训练fp32推理或者反过来，数值行为可能不一致；动态shape，车上输入分辨率可能随场景变化，模型要能处理变长输入。

还有一个容易被忽略的点是内存碎片。长时间运行后显存碎片化会导致偶发的分配失败，表现是跑几个小时突然崩一次。解决办法是预分配固定大小的内存池，避免频繁申请释放。

5.3 常见问题速查表

5.4 几条踩坑之后才明白的经验

第一条，不要迷信大模型。参数量翻倍带来的收益在数据量不足时非常有限，有那个算力不如先把数据质量和标注一致性提上去。

第二条，评测集要独立且固定。我见过团队反复在同一个验证集上调参，最后指标很好看但实车一塌糊涂。验证集的使用次数要有纪律。

第三条，模块化架构在现阶段的工程价值被低估了。端到端很美好，但出问题时你能快速定位到具体模块，这个能力在量产项目里值很多钱。

第四条，多模态对齐的效果很大程度取决于数据构造的精细度，模型结构反而是次要因素。同样的架构，细粒度描述数据训出来的效果能甩粗粒度数据一大截。

我个人在这个方向上的体会是，基础模型给自动驾驶带来的最大改变不是某个具体指标提升，而是工作方式的转变——从“针对每个任务设计专用模型”变成“先找一个好的通用表征，再想办法适配任务”。这个转变对团队的能力结构提出了新要求，既要懂预训练和微调，也要懂传统自动驾驶的工程约束，两头都懂的人目前还是稀缺的。