做自动驾驶的朋友应该都有过这种经历想给团队做一次关于感知的分享翻遍资料库找不到一份系统又不过时的材料要么是纯理论推导看到一半就困要么是网上打包的PPT模板内容空到只有标题页能看。我自己也一直被这个问题困扰上个月干脆花了两周时间把深度学习在自动驾驶感知领域的应用整理成了一套43页的PPT从任务定义、模型选型、数据工程、恶劣天气、模型部署到常见故障排查覆盖了感知方向从入门到量产落地的主要内容。这套PPT给内部团队讲过三轮每次讲完都有人来拷走源文件这次干脆把核心内容直接写成文章让不方便下载的朋友也能一次看个透。文章适合三类读者正在学习自动驾驶感知方向的学生工作两三年想系统梳理知识树的算法工程师以及想了解感知技术在量产项目里到底怎么落地的产品经理和技术管理者。PPT里涉及的深度学习模型包括目标检测、语义分割、多目标跟踪这几个大方向以及它们在实际项目里的工程取舍。下面按PPT的章节顺序展开来讲尽量把每个选择背后的原因和踩过的坑都说清楚。1. 感知在自动驾驶系统里的位置和核心任务1.1 自动驾驶软件栈里感知到底管哪一段把自动驾驶的软件系统拆开看大致就是感知、预测、规划、控制四个环节。感知在最前端负责回答一个最基本的问题车周围有什么。具体到道路场景就是要搞清楚车道线在哪里、前车在什么位置速度多快、行人会不会横穿、红绿灯是什么状态、路边的锥桶和施工标志有没有被识别出来。这套PPT的第一部分我花了不少篇幅讲这个分层关系。因为很多刚接触的人会把感知和整个自动驾驶画等号其实感知只是输入环节。感知的输出通常是一组结构化信息目标列表每个目标带类别、位置、尺寸、速度可行驶区域车道拓扑交通标志状态。这些信息送到预测模块预测模块判断每个目标未来几秒的运动意图规划模块再基于这些判断生成驾驶路径和控制指令。这个位置关系决定了你怎么设计感知接口、怎么定义精度指标。比如规划模块对感知的实时性要求极高感知延迟100毫秒车按60公里时速算已经往前走了接近1.7米这在高速场景是致命的。所以感知系统设计的两个核心约束永远是准和快而不是单看某一个指标。我在PPT里用一个具体的延迟预算表说明这件事摄像头采集、预处理、模型推理、后处理、消息传递每一环都要控制延迟整个链路才能满足规划模块的输入刷新要求。这个表后来被组里新同学当成入门材料反复看我觉得比单纯讲算法有价值得多。1.2 感知任务的三个基本盘检测、分割、跟踪PPT里我把感知任务归纳成三个基本盘目标检测、语义分割、多目标跟踪。目标检测负责“是什么、在哪里”用一个矩形框把车辆、行人、骑行者框出来并给出类别语义分割负责逐像素理解场景特别是可行驶区域、车道线这类不适合用矩形框表达的目标多目标跟踪负责回答“这辆车从上一秒到这一秒是不是同一辆”保证目标ID的连续性和轨迹的稳定。这三个任务不是各自独立的。实际工程里检测和分割经常共享一个骨干网络跟踪则建立在检测输出之上也就是业内常说的tracking by detection范式。我在PPT里画了一张数据流图一帧图像输入先进骨干网络提取特征再分出检测头和分割头检测结果送入跟踪模块做数据关联分割结果直接输出给下游。这套流程到今天依然是绝大多数量产感知方案的主干先把这条链路跑通比急着追新模型重要得多。另外这三个任务现在越来越倾向于收敛到一个统一的模型里做也就是多任务学习。好处很明显特征共享能省算力、全任务只需要过一次网络、各任务感受野互补还能互相提升。坏处是任务之间可能抢loss需要精心设计每项任务的权重和采样策略。我在PPT里给了自己常用的多任务loss权重初始值后面训练调参部分会再展开。2. 感知模型选型不是参数越大越好2.1 目标检测从YOLO到DETR的路线之争目标检测是感知里最核心的模块这套PPT里我对比了现在主流的几条技术路线。第一条是单阶段检测器代表的YOLO系列从YOLOv5到YOLOv8一直是工程落地首选第二条是双阶段检测器比如Faster R-CNN精度高但速度普遍跟不上车载算力在自动驾驶量产里已经很少用了第三条是DETR这类基于Transformer的检测器用集合预测替代了锚框和NMS思路优雅对小目标和遮挡目标的建模能力更强但对训练数据和调参的要求都极高。我的选型建议一直很直白做实时性要求高的量产项目老老实实用YOLO系列量化友好、部署生态成熟、社区资料多出了任何问题都能搜到解决方案。做科研预研或者算力比较宽裕的项目可以认真考虑Transformer路线。PPT里给了一张对比表把主流的检测模型在精度、速度、参数量、部署难度四个维度列了一遍这里直接贴出来模型精度(mAP)推理速度参数量部署难度适用场景YOLOv5s中极快7.2M低量产首选YOLOv8s较高快11.2M低量产/预研Faster R-CNN较高慢41M中学术基线DETR高慢60M高预研项目注意这个表只是通用参考自动驾驶场景里真正要看的还是自有数据集上的表现。我自己测下来YOLO系列在车辆、行人这类常规目标上经过充分训练后精度完全够用真正拉开差距的是小目标、遮挡和恶劣天气这时候数据质量和数量比模型结构更关键。有一个词最近很火叫动手深度学习我的理解就是别只看论文和PPT拿到数据先跑通baseline再在这个基础上做改进这个顺序对于检测任务特别有效。2.2 语义分割与BEV感知行业为什么转向统一视角语义分割在自动驾驶里的典型应用是车道线检测和可行驶区域划分。早期做法是分割网络输出像素级类别再做曲线拟合提取车道线。现在行业的主流方向是BEV感知也就是鸟瞰视角把相机、激光雷达的特征统一转到车顶俯视坐标系下在俯视图里做检测、分割、跟踪输出天然就是下游规划模块需要的横截面信息。PPT里我重点讲了为什么要转BEV。摄像头和激光雷达都在车身上各自看出去的视角是透视的会出现近大远小、目标互相遮挡的问题而且不同传感器的坐标系不统一融合困难。BEV相当于把所有信息铺到一张二维俯视图上目标大小不随距离变化传感器之间更好融合车道线、路口等几何关系也更直观。特斯拉的纯视觉方案、国内不少量产智能驾驶方案走的都是这个方向。转BEV不是没有代价。最大的代价是训练数据需求量大增因为模型要额外学习视角变换其次是相机内外参标定精度会影响投影质量标定偏一点BEV空间里的目标位置就歪一截。另外一个实际的工程问题是BEV模型普遍比较重对车载芯片的算力压力大通常要做结构轻量化和量化压缩才能上量产的域控制器。PPT的参考文献里列了相关代表工作想深入研究的可以按图索骥。2.3 传感器融合摄像头、激光雷达、毫米波雷达怎么配合感知系统的传感器配置我在PPT里总结成一句话摄像头提供语义激光雷达提供深度毫米波雷达提供速度和全天候稳定性。摄像头分辨率高、成本低、颜色纹理信息丰富但怕黑、怕逆光、怕雨雾激光雷达测距准、不受光照影响能直接拿到三维点云但成本高、雨雾天有衰减、对深色物体反射差毫米波雷达穿透性强、对速度敏感但点云稀疏、角度分辨率低静止目标经常被漏检。融合策略市面上主流有后融合、前融合、特征融合三种。后融合最简单每个传感器各自输出目标列表再按规则合并去重前融合是把图像和点云原始数据拼在一起早期做法多但受传感器时间同步和空间对齐影响大特征融合是在神经网络中间层把多模态特征拼起来是目前工程性价比最高的方案。PPT里画了三者的对比图核心结论是后融合容易出重复目标和矛盾判断前融合对硬件同步要求苛刻特征融合虽然工程复杂度高但效果上限也最高。提示激光雷达和摄像头的融合时间戳和外参必须严格对齐。我见过不少项目模型结构没问题就是融合结果飘查到最后是外参标定跑了或者时间同步差了太多。标定这件事一定要纳入日常运维不是出厂标一次就一劳永逸的。3. 数据工程自动驾驶感知的真正护城河3.1 公开数据集与自有数据的取舍做感知算法起步接触最多的就是公开数据集。KITTI是经典老牌适合入门做检测和跟踪基线nuScenes数据模态全摄像头、激光雷达、毫米波雷达都有还带了天气场景标注是业内做多模态感知的首选之一Waymo Open Dataset规模大、场景真实但数据格式和标注规范上手成本高。国内也有不少高质量开源数据集很多包含典型的中国路况比如密集的电瓶车流、复杂的人车混行路口这些在国外的数据集里很难看到。选数据集的逻辑不是越大越好而是看任务匹配度。专攻激光雷达检测KITTI和nuScenes都合适专攻恶劣天气感知就要找带雨雾场景的标注数据公开的不多很多时候得自采。PPT中间部分列了一张数据集对照表把数据规模、传感器配置、标注类别、适用任务都标了出来方便按图索骥。客观说公开数据集只能用来做算法研究和验证量产项目的数据壁垒还是来自自有数据。自有数据的核心优势是场景可控、标注规范可控、链路完整能围绕目标场景持续迭代。我见过不少团队犯一个错误起步阶段一味追求数据量堆了几万小时路采但场景分布极其不均衡高速晴天占了九成真正头疼的城市场景和恶劣天气寥寥无几。数据采集一定要有场景预算表每个典型场景至少采足多少小时、覆盖多少天气和时间段都要提前规划好。3.2 标注规范、难例挖掘与训练细节数据工程里最容易翻车的不是采集是标注。举一个真实的例子行人标注框到底框到哪条边界手里的雨伞算不算在框内骑自行车的人按行人标还是按骑行者标这些边界问题不定义清楚不同标注员的标注就会不一致模型学到的目标边界自然是模糊的。团队内应该有标注规范文档和抽检机制定期计算标注一致性发现分歧及时组织复盘。难例挖掘是感知数据工程里必须做的一环。所谓难例就是模型预测置信度低但标注正确的样本以及大量看起来相似但语义不同的场景比如夜间远处穿深色衣服的行人、被雨刷挡了一半的前车。难例挖掘的操作流程我在PPT里写得很具体模型在验证集上跑一遍按预测loss排序取top难例交给标注员确认确认后加入训练集重新训练再挖。循环三四轮模型在复杂场景的表现会有肉眼可见的提升。训练细节这里补充三个容易被忽略的点。第一是类别不平衡车辆样本往往远多于行人样本要用focal loss或者按类别加权采样第二是图像分辨率输入分辨率太低远处小目标直接丢细节太高又拖慢推理需要按目标距离分布折中第三是数据增强的度增强不是越猛越好过度增强会破坏真实分布我试过把亮度扰动范围调得过大结果模型在白天正常光照下反而变差了。3.3 仿真与数据增强怎样让模型见过足够多的意外数据增强是感知模型泛化的重要来源。图像方面常用亮度扰动、仿射变换、随机遮挡、MixUp点云方面有全局旋转、随机裁剪、地面增强。增强策略要结合场景制定比如做夜间感知重点增强光照和对比度变化做雨雾感知重点加模糊和噪声扰动。仿真在感知训练里的角色越来越大。业内常用仿真平台和游戏引擎渲染合成数据比如用风格迁移把晴天图变成雨天图或者在仿真环境里搭建极端交通场景来补足真实路采的盲区。甚至有人用欧卡2这类模拟器生成驾驶场景数据贵在场景可控、成本极低。仿真最大的问题是域差模型在仿真数据上练得越好上真车越容易露馅。我的应对经验是用域随机化把渲染参数、光照、纹理、天气全都随机化强迫模型学到目标本质特征而不是仿真特有的合成痕迹。这里顺便聊一下数据规模的话题。业内有句话叫有多少人工就有多少智能数据标注的投入在感知项目里通常占总成本的一半以上。自动化标注技术越来越成熟比如用训练好的模型做预标注人工只做修正能大幅降低标注成本。但预标注有个坑模型会把自己的错误带进标注形成自我强化的偏见所以预标注一定要配合人工抽检和难例重标。4. 恶劣天气下的感知鲁棒性绕不开的工程难题4.1 雨雾场景为什么这么难恶劣天气是感知系统量产路上最大的拦路虎之一四十分钟的车程里可能就有一段暴雨而这段暴雨场景出了事就是大事。我把恶劣天气的影响拆成三个层面传感器层面、数据层面、模型层面。传感器层面是物理限制。摄像头在雨雾里图像对比度下降、细节丢失夜晚逆光直接白茫茫一片激光雷达点云在雨滴影响下会产生大量噪点对深色潮湿路面反射也很弱毫米波雷达虽然穿透力好但雨雾对电磁波仍有衰减而且潮湿路面会产生镜面反射。这些都不是算法能解决的只能靠传感器配置互补。数据层面是标注困难。雨雾天图像人眼都看不太清标注员怎么保证质量我调研过几家常合作的标注商发现雨天数据的标注一致率比晴天低不少这直接影响模型训练质量。模型层面是泛化不足。晴天训练出来的模型特征是沿着晴天分布学习的一遇到雨雾输入分布发生偏移精度断崖式下降。在PPT里我放了一组对比实验数据一个在晴天数据上训练得很好的检测模型直接喂雨雾图像mAP从70多掉到40多视觉上就是漏检、误检满天飞。这说明恶劣天气不能靠事后补救必须在数据、模型、传感器三个层面同时做设计。4.2 雾感知密度评估与场景自适应PPT里有一个值得展开的新思路与其用一个模型硬扛所有天气不如先判断当前场景的恶劣程度再决定启用哪套处理策略。比如用雾感知密度评估器对输入图像估算一个雾浓度指标浓度低就走常规检测流程浓度高则先做图像去雾预处理或者调整传感器融合权重。这个思路的逻辑很朴素统一模型要想同时适配晴天和暴雨往往两头都做不好因为两类场景的图像分布差异太大。分场景自适应则可以让常规模型保持晴天高精度恶劣场景单独启用增强链路。我在团队内部做过一个小实验在合成雾天数据上验证密度评估加去雾预处理目标检测的mAP比硬扛基线高了大约5到8个百分点。当然这套方案也有代价。多一个前置模块就多一份延迟和故障点密度评估本身也可能误判。天气切换还需要滞回控制不能忽晴忽雨地反复切换策略。工程上我倾向于把它做成一个低频的环境状态估计模块用于给融合权重做慢调而不是高频搞图像增强这样延迟和稳定性都可控。4.3 恶劣天气数据的积累路径恶劣天气数据的积累我建议三条路并行。第一条是自采在雨季、冬季、清晨大雾时段安排采集车出去跑这是最真实但成本最高的方式第二条是合成用渲染引擎或者风格迁移生成雨雾雪效果量大管饱但不完全真实第三条是找第三方数据集和行业共享数据不少机构公开了恶劣天气标注数据需要筛选匹配自己的场景。自采数据有个细节容易忽略天气数据要带天气传感器做记录。采集车应该同步记录温度、湿度、雨量、能见度这类天气元数据这样后续才能把数据按照能见度等级、雨量等级做精细分桶训练的时候按场景分布采样。没有天气元数据的路采数据只能靠人工看图分类效率极低还容易出错。这套流程在PPT里占了不小篇幅原因是恶劣天气数据工程做得好不好直接决定了模型在极端场景的天花板。5. 模型部署与工程化从Demo到量产的鸿沟5.1 算力评估模型跑得动才是真的好PPT里我用了一个词叫算力焦虑。很多算法团队在服务器上用A100跑得飞快的模型拿到车载芯片上一测帧率只有个位数整个demo瞬间卡成幻灯片。车载平台的算力是固定的几十TOPS的芯片要同时跑感知、融合、预测、规划、控制分给感知模型的预算非常有限。所以模型选型阶段就要算清楚感知链路的帧率要求是多少、每个模型推理延迟上限是多少、CPU端还有多少后处理负担这些参数要先定下来。算力评估有个实用方法写进了PPT先把模型放到目标芯片的推理工具链上做一次profiling拿到每一层的延迟和内存占用再看有没有算子跑得特别慢。车载芯片对一些算子支持很差比如某些Transformer的注意力算子在低算力平台上效率惨不忍睹这时候要么算子重写要么换模型结构。另一个经验是别只看模型总延迟要关注p99延迟也就是最慢的那百分之几的帧实车场景里偶发的高延迟帧比稳定均值更危险。5.2 模型压缩与量化INT8是量产标配模型压缩是感知上车的必经之路常用手段有剪枝、蒸馏、量化。剪枝是去掉冗余权重和通道蒸馏是用大模型教小模型量化是把FP32的权重和激活换算成INT8大幅降低计算量和内存带宽。业界量产感知模型基本都以INT8量化为主配合一些通道剪枝精度损失能控制在很小的范围。INT8量化有个关键步骤是校准集的选择。校准集是用来统计激活值分布、确定量化参数的如果校准集选得没代表性量化后的模型精度就会崩。我踩过的一个坑是校准集全用了白天晴天数据量化模型上线后夜间场景精度掉得离谱查了很久才发现是校准分布和夜间输入分布不匹配。后来把白天、夜晚、雨雾的数据都混进校准集才稳住。这个案例我在PPT里当成反面教材讲提醒大家校准集选择真不是小事。注意校准集的场景分布一定要和实际运行环境匹配否则量化后的模型会“偏科”白天好好的一到晚上就露馅。5.3 从仿真到实车为什么仿真指标好上路就打折仿真和实车的差异是每个做感知工程的人都要面对的落差。最常见的原因有三个传感器差异、图像质量差异、运行环境差异。仿真里的相机参数是理想的实车摄像头有畸变、噪声、动态模糊仿真数据干干净净实车图像里可能有泥点、光晕、镜头脏污甚至昆虫尸体。PPT里我特别强调了一个观点感知系统的鲁棒性一半靠算法一半靠传感器质量和部署细节。应对办法是建立一套实车回归测试集。每次改模型、改预处理、改部署代码都要在测试集上重新跑一遍关键指标防止修了A场景坏了B场景。我个人的经验是实车测试集一定要包含雨天、夜晚、隧道出入口、强逆光这四个典型场景这四个场景占了量产感知问题的一大半。测试集的管理也要规范化每次新增典型问题都要沉淀成回归用例逐渐形成一套覆盖越来越全面的能力基线。6. 常见问题与避坑指南来自一线的排查经验6.1 模型指标高但实车体验差怎么办这是感知团队最常被投诉的问题。原因往往是评测指标和用户体感不一致。离线评测看整体mAP但用户感受最强烈的是某些具体场景比如小区门口乱穿马路的电动车、高速上突然近距离加塞的车辆。我在团队里推了一个做法除了整体指标还要按场景拆分成细项指标每个场景单独打分模型要上线必须所有关键场景过线。这个做法写进了PPT的第38页是这套分享里最实用的一页之一。另外一个容易忽略的指标是误报率。很多团队只盯着召回率追结果模型为了多召回导致大量误检实车体验是刹车不断、体验很差。检测模型上线前一定要画P-R曲线在可接受的误报率下尽量提高召回而不是单点追指标。6.2 训练发散、loss不降的排查顺序训练感知模型最头疼的就是loss不降或者直接发散。我总结了一套排查顺序写在PPT里供团队参考先看数据标注质量、类别平衡、数据总量够不够再看超参学习率起步是否过大、batch size是否太小、loss权重是否失衡最后看模型有没有梯度爆炸、骨干网络是否初始化不当。具体排查时可以先用一个很小的数据子集做过拟合测试如果小数据子集都拟合不了那就是模型或者代码的问题如果小数据子集能拟合但完整训练集不行那大概率是数据或超参的问题。这个二分定位法能省大量时间。还有一个常见坑是增强策略和验证集不匹配比如训练时做了强烈的几何增强验证集没做导致离线验证指标虚高上线后真实表现反而一般。6.3 标注不一致导致模型摇摆标注不一致在感知项目里非常普遍。同一个目标有的标注员框车头到车尾有的只框车身同一根车道线这个说虚线那个说实线。这类问题模型学出来就是摇摆的今天输出这种明天输出那种。团队内部一定要建立抽检机制定期算标注一致性发现问题及时做标注规范复盘。我的经验是规范文档要配图配例最好把典型错误标注和正确标注放在一起做对比这样标注员学起来最快。另外新版本规范发布时一定要全员培训不要默认大家都认真看了文档。这个环节看着不性感但真的是决定模型上限的关键一环。整理这套43页PPT的过程我自己最大的收获是把脑子里碎片化的经验重新串了一遍。深度学习在自动驾驶感知领域的应用说到底工程问题多过算法问题数据、标注、部署每个环节都能成为瓶颈。我在实际项目里的体会是不要盲目追求新模型先把检测、分割、跟踪三个基本盘做扎实把数据管线跑通把实车回归测试建立起来比追任何论文都管用。希望这篇文章能帮你少走一些弯路也欢迎在评论区聊聊你在感知项目里踩过的坑或者对PPT内容有疑问的地方我会尽量回复。 
长河君 · 2026/10/15 11:04:55 · 阅读 1.2k 深度学习自动驾驶感知全解析：从模型选型到量产部署
做自动驾驶的朋友应该都有过这种经历想给团队做一次关于感知的分享翻遍资料库找不到一份系统又不过时的材料要么是纯理论推导看到一半就困要么是网上打包的PPT模板内容空到只有标题页能看。我自己也一直被这个问题困扰上个月干脆花了两周时间把深度学习在自动驾驶感知领域的应用整理成了一套43页的PPT从任务定义、模型选型、数据工程、恶劣天气、模型部署到常见故障排查覆盖了感知方向从入门到量产落地的主要内容。这套PPT给内部团队讲过三轮每次讲完都有人来拷走源文件这次干脆把核心内容直接写成文章让不方便下载的朋友也能一次看个透。文章适合三类读者正在学习自动驾驶感知方向的学生工作两三年想系统梳理知识树的算法工程师以及想了解感知技术在量产项目里到底怎么落地的产品经理和技术管理者。PPT里涉及的深度学习模型包括目标检测、语义分割、多目标跟踪这几个大方向以及它们在实际项目里的工程取舍。下面按PPT的章节顺序展开来讲尽量把每个选择背后的原因和踩过的坑都说清楚。1. 感知在自动驾驶系统里的位置和核心任务1.1 自动驾驶软件栈里感知到底管哪一段把自动驾驶的软件系统拆开看大致就是感知、预测、规划、控制四个环节。感知在最前端负责回答一个最基本的问题车周围有什么。具体到道路场景就是要搞清楚车道线在哪里、前车在什么位置速度多快、行人会不会横穿、红绿灯是什么状态、路边的锥桶和施工标志有没有被识别出来。这套PPT的第一部分我花了不少篇幅讲这个分层关系。因为很多刚接触的人会把感知和整个自动驾驶画等号其实感知只是输入环节。感知的输出通常是一组结构化信息目标列表每个目标带类别、位置、尺寸、速度可行驶区域车道拓扑交通标志状态。这些信息送到预测模块预测模块判断每个目标未来几秒的运动意图规划模块再基于这些判断生成驾驶路径和控制指令。这个位置关系决定了你怎么设计感知接口、怎么定义精度指标。比如规划模块对感知的实时性要求极高感知延迟100毫秒车按60公里时速算已经往前走了接近1.7米这在高速场景是致命的。所以感知系统设计的两个核心约束永远是准和快而不是单看某一个指标。我在PPT里用一个具体的延迟预算表说明这件事摄像头采集、预处理、模型推理、后处理、消息传递每一环都要控制延迟整个链路才能满足规划模块的输入刷新要求。这个表后来被组里新同学当成入门材料反复看我觉得比单纯讲算法有价值得多。1.2 感知任务的三个基本盘检测、分割、跟踪PPT里我把感知任务归纳成三个基本盘目标检测、语义分割、多目标跟踪。目标检测负责“是什么、在哪里”用一个矩形框把车辆、行人、骑行者框出来并给出类别语义分割负责逐像素理解场景特别是可行驶区域、车道线这类不适合用矩形框表达的目标多目标跟踪负责回答“这辆车从上一秒到这一秒是不是同一辆”保证目标ID的连续性和轨迹的稳定。这三个任务不是各自独立的。实际工程里检测和分割经常共享一个骨干网络跟踪则建立在检测输出之上也就是业内常说的tracking by detection范式。我在PPT里画了一张数据流图一帧图像输入先进骨干网络提取特征再分出检测头和分割头检测结果送入跟踪模块做数据关联分割结果直接输出给下游。这套流程到今天依然是绝大多数量产感知方案的主干先把这条链路跑通比急着追新模型重要得多。另外这三个任务现在越来越倾向于收敛到一个统一的模型里做也就是多任务学习。好处很明显特征共享能省算力、全任务只需要过一次网络、各任务感受野互补还能互相提升。坏处是任务之间可能抢loss需要精心设计每项任务的权重和采样策略。我在PPT里给了自己常用的多任务loss权重初始值后面训练调参部分会再展开。2. 感知模型选型不是参数越大越好2.1 目标检测从YOLO到DETR的路线之争目标检测是感知里最核心的模块这套PPT里我对比了现在主流的几条技术路线。第一条是单阶段检测器代表的YOLO系列从YOLOv5到YOLOv8一直是工程落地首选第二条是双阶段检测器比如Faster R-CNN精度高但速度普遍跟不上车载算力在自动驾驶量产里已经很少用了第三条是DETR这类基于Transformer的检测器用集合预测替代了锚框和NMS思路优雅对小目标和遮挡目标的建模能力更强但对训练数据和调参的要求都极高。我的选型建议一直很直白做实时性要求高的量产项目老老实实用YOLO系列量化友好、部署生态成熟、社区资料多出了任何问题都能搜到解决方案。做科研预研或者算力比较宽裕的项目可以认真考虑Transformer路线。PPT里给了一张对比表把主流的检测模型在精度、速度、参数量、部署难度四个维度列了一遍这里直接贴出来模型精度(mAP)推理速度参数量部署难度适用场景YOLOv5s中极快7.2M低量产首选YOLOv8s较高快11.2M低量产/预研Faster R-CNN较高慢41M中学术基线DETR高慢60M高预研项目注意这个表只是通用参考自动驾驶场景里真正要看的还是自有数据集上的表现。我自己测下来YOLO系列在车辆、行人这类常规目标上经过充分训练后精度完全够用真正拉开差距的是小目标、遮挡和恶劣天气这时候数据质量和数量比模型结构更关键。有一个词最近很火叫动手深度学习我的理解就是别只看论文和PPT拿到数据先跑通baseline再在这个基础上做改进这个顺序对于检测任务特别有效。2.2 语义分割与BEV感知行业为什么转向统一视角语义分割在自动驾驶里的典型应用是车道线检测和可行驶区域划分。早期做法是分割网络输出像素级类别再做曲线拟合提取车道线。现在行业的主流方向是BEV感知也就是鸟瞰视角把相机、激光雷达的特征统一转到车顶俯视坐标系下在俯视图里做检测、分割、跟踪输出天然就是下游规划模块需要的横截面信息。PPT里我重点讲了为什么要转BEV。摄像头和激光雷达都在车身上各自看出去的视角是透视的会出现近大远小、目标互相遮挡的问题而且不同传感器的坐标系不统一融合困难。BEV相当于把所有信息铺到一张二维俯视图上目标大小不随距离变化传感器之间更好融合车道线、路口等几何关系也更直观。特斯拉的纯视觉方案、国内不少量产智能驾驶方案走的都是这个方向。转BEV不是没有代价。最大的代价是训练数据需求量大增因为模型要额外学习视角变换其次是相机内外参标定精度会影响投影质量标定偏一点BEV空间里的目标位置就歪一截。另外一个实际的工程问题是BEV模型普遍比较重对车载芯片的算力压力大通常要做结构轻量化和量化压缩才能上量产的域控制器。PPT的参考文献里列了相关代表工作想深入研究的可以按图索骥。2.3 传感器融合摄像头、激光雷达、毫米波雷达怎么配合感知系统的传感器配置我在PPT里总结成一句话摄像头提供语义激光雷达提供深度毫米波雷达提供速度和全天候稳定性。摄像头分辨率高、成本低、颜色纹理信息丰富但怕黑、怕逆光、怕雨雾激光雷达测距准、不受光照影响能直接拿到三维点云但成本高、雨雾天有衰减、对深色物体反射差毫米波雷达穿透性强、对速度敏感但点云稀疏、角度分辨率低静止目标经常被漏检。融合策略市面上主流有后融合、前融合、特征融合三种。后融合最简单每个传感器各自输出目标列表再按规则合并去重前融合是把图像和点云原始数据拼在一起早期做法多但受传感器时间同步和空间对齐影响大特征融合是在神经网络中间层把多模态特征拼起来是目前工程性价比最高的方案。PPT里画了三者的对比图核心结论是后融合容易出重复目标和矛盾判断前融合对硬件同步要求苛刻特征融合虽然工程复杂度高但效果上限也最高。提示激光雷达和摄像头的融合时间戳和外参必须严格对齐。我见过不少项目模型结构没问题就是融合结果飘查到最后是外参标定跑了或者时间同步差了太多。标定这件事一定要纳入日常运维不是出厂标一次就一劳永逸的。3. 数据工程自动驾驶感知的真正护城河3.1 公开数据集与自有数据的取舍做感知算法起步接触最多的就是公开数据集。KITTI是经典老牌适合入门做检测和跟踪基线nuScenes数据模态全摄像头、激光雷达、毫米波雷达都有还带了天气场景标注是业内做多模态感知的首选之一Waymo Open Dataset规模大、场景真实但数据格式和标注规范上手成本高。国内也有不少高质量开源数据集很多包含典型的中国路况比如密集的电瓶车流、复杂的人车混行路口这些在国外的数据集里很难看到。选数据集的逻辑不是越大越好而是看任务匹配度。专攻激光雷达检测KITTI和nuScenes都合适专攻恶劣天气感知就要找带雨雾场景的标注数据公开的不多很多时候得自采。PPT中间部分列了一张数据集对照表把数据规模、传感器配置、标注类别、适用任务都标了出来方便按图索骥。客观说公开数据集只能用来做算法研究和验证量产项目的数据壁垒还是来自自有数据。自有数据的核心优势是场景可控、标注规范可控、链路完整能围绕目标场景持续迭代。我见过不少团队犯一个错误起步阶段一味追求数据量堆了几万小时路采但场景分布极其不均衡高速晴天占了九成真正头疼的城市场景和恶劣天气寥寥无几。数据采集一定要有场景预算表每个典型场景至少采足多少小时、覆盖多少天气和时间段都要提前规划好。3.2 标注规范、难例挖掘与训练细节数据工程里最容易翻车的不是采集是标注。举一个真实的例子行人标注框到底框到哪条边界手里的雨伞算不算在框内骑自行车的人按行人标还是按骑行者标这些边界问题不定义清楚不同标注员的标注就会不一致模型学到的目标边界自然是模糊的。团队内应该有标注规范文档和抽检机制定期计算标注一致性发现分歧及时组织复盘。难例挖掘是感知数据工程里必须做的一环。所谓难例就是模型预测置信度低但标注正确的样本以及大量看起来相似但语义不同的场景比如夜间远处穿深色衣服的行人、被雨刷挡了一半的前车。难例挖掘的操作流程我在PPT里写得很具体模型在验证集上跑一遍按预测loss排序取top难例交给标注员确认确认后加入训练集重新训练再挖。循环三四轮模型在复杂场景的表现会有肉眼可见的提升。训练细节这里补充三个容易被忽略的点。第一是类别不平衡车辆样本往往远多于行人样本要用focal loss或者按类别加权采样第二是图像分辨率输入分辨率太低远处小目标直接丢细节太高又拖慢推理需要按目标距离分布折中第三是数据增强的度增强不是越猛越好过度增强会破坏真实分布我试过把亮度扰动范围调得过大结果模型在白天正常光照下反而变差了。3.3 仿真与数据增强怎样让模型见过足够多的意外数据增强是感知模型泛化的重要来源。图像方面常用亮度扰动、仿射变换、随机遮挡、MixUp点云方面有全局旋转、随机裁剪、地面增强。增强策略要结合场景制定比如做夜间感知重点增强光照和对比度变化做雨雾感知重点加模糊和噪声扰动。仿真在感知训练里的角色越来越大。业内常用仿真平台和游戏引擎渲染合成数据比如用风格迁移把晴天图变成雨天图或者在仿真环境里搭建极端交通场景来补足真实路采的盲区。甚至有人用欧卡2这类模拟器生成驾驶场景数据贵在场景可控、成本极低。仿真最大的问题是域差模型在仿真数据上练得越好上真车越容易露馅。我的应对经验是用域随机化把渲染参数、光照、纹理、天气全都随机化强迫模型学到目标本质特征而不是仿真特有的合成痕迹。这里顺便聊一下数据规模的话题。业内有句话叫有多少人工就有多少智能数据标注的投入在感知项目里通常占总成本的一半以上。自动化标注技术越来越成熟比如用训练好的模型做预标注人工只做修正能大幅降低标注成本。但预标注有个坑模型会把自己的错误带进标注形成自我强化的偏见所以预标注一定要配合人工抽检和难例重标。4. 恶劣天气下的感知鲁棒性绕不开的工程难题4.1 雨雾场景为什么这么难恶劣天气是感知系统量产路上最大的拦路虎之一四十分钟的车程里可能就有一段暴雨而这段暴雨场景出了事就是大事。我把恶劣天气的影响拆成三个层面传感器层面、数据层面、模型层面。传感器层面是物理限制。摄像头在雨雾里图像对比度下降、细节丢失夜晚逆光直接白茫茫一片激光雷达点云在雨滴影响下会产生大量噪点对深色潮湿路面反射也很弱毫米波雷达虽然穿透力好但雨雾对电磁波仍有衰减而且潮湿路面会产生镜面反射。这些都不是算法能解决的只能靠传感器配置互补。数据层面是标注困难。雨雾天图像人眼都看不太清标注员怎么保证质量我调研过几家常合作的标注商发现雨天数据的标注一致率比晴天低不少这直接影响模型训练质量。模型层面是泛化不足。晴天训练出来的模型特征是沿着晴天分布学习的一遇到雨雾输入分布发生偏移精度断崖式下降。在PPT里我放了一组对比实验数据一个在晴天数据上训练得很好的检测模型直接喂雨雾图像mAP从70多掉到40多视觉上就是漏检、误检满天飞。这说明恶劣天气不能靠事后补救必须在数据、模型、传感器三个层面同时做设计。4.2 雾感知密度评估与场景自适应PPT里有一个值得展开的新思路与其用一个模型硬扛所有天气不如先判断当前场景的恶劣程度再决定启用哪套处理策略。比如用雾感知密度评估器对输入图像估算一个雾浓度指标浓度低就走常规检测流程浓度高则先做图像去雾预处理或者调整传感器融合权重。这个思路的逻辑很朴素统一模型要想同时适配晴天和暴雨往往两头都做不好因为两类场景的图像分布差异太大。分场景自适应则可以让常规模型保持晴天高精度恶劣场景单独启用增强链路。我在团队内部做过一个小实验在合成雾天数据上验证密度评估加去雾预处理目标检测的mAP比硬扛基线高了大约5到8个百分点。当然这套方案也有代价。多一个前置模块就多一份延迟和故障点密度评估本身也可能误判。天气切换还需要滞回控制不能忽晴忽雨地反复切换策略。工程上我倾向于把它做成一个低频的环境状态估计模块用于给融合权重做慢调而不是高频搞图像增强这样延迟和稳定性都可控。4.3 恶劣天气数据的积累路径恶劣天气数据的积累我建议三条路并行。第一条是自采在雨季、冬季、清晨大雾时段安排采集车出去跑这是最真实但成本最高的方式第二条是合成用渲染引擎或者风格迁移生成雨雾雪效果量大管饱但不完全真实第三条是找第三方数据集和行业共享数据不少机构公开了恶劣天气标注数据需要筛选匹配自己的场景。自采数据有个细节容易忽略天气数据要带天气传感器做记录。采集车应该同步记录温度、湿度、雨量、能见度这类天气元数据这样后续才能把数据按照能见度等级、雨量等级做精细分桶训练的时候按场景分布采样。没有天气元数据的路采数据只能靠人工看图分类效率极低还容易出错。这套流程在PPT里占了不小篇幅原因是恶劣天气数据工程做得好不好直接决定了模型在极端场景的天花板。5. 模型部署与工程化从Demo到量产的鸿沟5.1 算力评估模型跑得动才是真的好PPT里我用了一个词叫算力焦虑。很多算法团队在服务器上用A100跑得飞快的模型拿到车载芯片上一测帧率只有个位数整个demo瞬间卡成幻灯片。车载平台的算力是固定的几十TOPS的芯片要同时跑感知、融合、预测、规划、控制分给感知模型的预算非常有限。所以模型选型阶段就要算清楚感知链路的帧率要求是多少、每个模型推理延迟上限是多少、CPU端还有多少后处理负担这些参数要先定下来。算力评估有个实用方法写进了PPT先把模型放到目标芯片的推理工具链上做一次profiling拿到每一层的延迟和内存占用再看有没有算子跑得特别慢。车载芯片对一些算子支持很差比如某些Transformer的注意力算子在低算力平台上效率惨不忍睹这时候要么算子重写要么换模型结构。另一个经验是别只看模型总延迟要关注p99延迟也就是最慢的那百分之几的帧实车场景里偶发的高延迟帧比稳定均值更危险。5.2 模型压缩与量化INT8是量产标配模型压缩是感知上车的必经之路常用手段有剪枝、蒸馏、量化。剪枝是去掉冗余权重和通道蒸馏是用大模型教小模型量化是把FP32的权重和激活换算成INT8大幅降低计算量和内存带宽。业界量产感知模型基本都以INT8量化为主配合一些通道剪枝精度损失能控制在很小的范围。INT8量化有个关键步骤是校准集的选择。校准集是用来统计激活值分布、确定量化参数的如果校准集选得没代表性量化后的模型精度就会崩。我踩过的一个坑是校准集全用了白天晴天数据量化模型上线后夜间场景精度掉得离谱查了很久才发现是校准分布和夜间输入分布不匹配。后来把白天、夜晚、雨雾的数据都混进校准集才稳住。这个案例我在PPT里当成反面教材讲提醒大家校准集选择真不是小事。注意校准集的场景分布一定要和实际运行环境匹配否则量化后的模型会“偏科”白天好好的一到晚上就露馅。5.3 从仿真到实车为什么仿真指标好上路就打折仿真和实车的差异是每个做感知工程的人都要面对的落差。最常见的原因有三个传感器差异、图像质量差异、运行环境差异。仿真里的相机参数是理想的实车摄像头有畸变、噪声、动态模糊仿真数据干干净净实车图像里可能有泥点、光晕、镜头脏污甚至昆虫尸体。PPT里我特别强调了一个观点感知系统的鲁棒性一半靠算法一半靠传感器质量和部署细节。应对办法是建立一套实车回归测试集。每次改模型、改预处理、改部署代码都要在测试集上重新跑一遍关键指标防止修了A场景坏了B场景。我个人的经验是实车测试集一定要包含雨天、夜晚、隧道出入口、强逆光这四个典型场景这四个场景占了量产感知问题的一大半。测试集的管理也要规范化每次新增典型问题都要沉淀成回归用例逐渐形成一套覆盖越来越全面的能力基线。6. 常见问题与避坑指南来自一线的排查经验6.1 模型指标高但实车体验差怎么办这是感知团队最常被投诉的问题。原因往往是评测指标和用户体感不一致。离线评测看整体mAP但用户感受最强烈的是某些具体场景比如小区门口乱穿马路的电动车、高速上突然近距离加塞的车辆。我在团队里推了一个做法除了整体指标还要按场景拆分成细项指标每个场景单独打分模型要上线必须所有关键场景过线。这个做法写进了PPT的第38页是这套分享里最实用的一页之一。另外一个容易忽略的指标是误报率。很多团队只盯着召回率追结果模型为了多召回导致大量误检实车体验是刹车不断、体验很差。检测模型上线前一定要画P-R曲线在可接受的误报率下尽量提高召回而不是单点追指标。6.2 训练发散、loss不降的排查顺序训练感知模型最头疼的就是loss不降或者直接发散。我总结了一套排查顺序写在PPT里供团队参考先看数据标注质量、类别平衡、数据总量够不够再看超参学习率起步是否过大、batch size是否太小、loss权重是否失衡最后看模型有没有梯度爆炸、骨干网络是否初始化不当。具体排查时可以先用一个很小的数据子集做过拟合测试如果小数据子集都拟合不了那就是模型或者代码的问题如果小数据子集能拟合但完整训练集不行那大概率是数据或超参的问题。这个二分定位法能省大量时间。还有一个常见坑是增强策略和验证集不匹配比如训练时做了强烈的几何增强验证集没做导致离线验证指标虚高上线后真实表现反而一般。6.3 标注不一致导致模型摇摆标注不一致在感知项目里非常普遍。同一个目标有的标注员框车头到车尾有的只框车身同一根车道线这个说虚线那个说实线。这类问题模型学出来就是摇摆的今天输出这种明天输出那种。团队内部一定要建立抽检机制定期算标注一致性发现问题及时做标注规范复盘。我的经验是规范文档要配图配例最好把典型错误标注和正确标注放在一起做对比这样标注员学起来最快。另外新版本规范发布时一定要全员培训不要默认大家都认真看了文档。这个环节看着不性感但真的是决定模型上限的关键一环。整理这套43页PPT的过程我自己最大的收获是把脑子里碎片化的经验重新串了一遍。深度学习在自动驾驶感知领域的应用说到底工程问题多过算法问题数据、标注、部署每个环节都能成为瓶颈。我在实际项目里的体会是不要盲目追求新模型先把检测、分割、跟踪三个基本盘做扎实把数据管线跑通把实车回归测试建立起来比追任何论文都管用。希望这篇文章能帮你少走一些弯路也欢迎在评论区聊聊你在感知项目里踩过的坑或者对PPT内容有疑问的地方我会尽量回复。