做自动驾驶的朋友应该都有过这种经历：想给团队做一次关于感知的分享，翻遍资料库找不到一份系统又不过时的材料，要么是纯理论推导看到一半就困，要么是网上打包的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内容有疑问的地方，我会尽量回复。
: 选择题和判断题（题解）)
