2. 自动驾驶系统概述

自动驾驶系统并不是单一算法，而是一条从传感器输入到车辆执行输出的实时计算链路。工程上通常把它拆成感知、预测、规划、控制四个核心模块，再叠加定位、地图、仿真、数据平台与运维体系。理解这条链路的输入输出、时延预算与失效模式，是后续训练、评测、部署一体化的前提。

一、四大模块的职责与接口

感知负责回答“周围有什么、在哪里”。它把摄像头、激光雷达、毫米波雷达、IMU、轮速等原始信号，转换为目标框、语义分割、车道线、可行驶区域、障碍物轨迹等结构化结果。感知的输出不是“图像”，而是带置信度、时间戳、坐标系的目标列表。

预测负责回答“它们接下来会怎么动”。基于感知目标的历史轨迹、地图先验、交通规则与交互关系，预测模块输出多模态的未来轨迹及概率。预测的难点在于他车意图不可观测，必须用概率分布表达不确定性。

规划负责回答“我该怎么走”。它结合导航路线、地图、预测轨迹、车辆动力学约束与舒适性要求，生成一条安全、可通行、平滑的轨迹。规划通常分为全局路由、行为决策、局部轨迹优化三层。

控制负责回答“如何精确执行”。它把规划轨迹转换为油门、刹车、转向指令，通过横纵向控制算法跟踪目标轨迹，并处理执行器延迟、路面附着变化与乘坐舒适性。

二、数据闭环：从“一次性交付”到“持续进化”

传统软件交付后行为基本固定，而自动驾驶面对的是开放世界，长尾场景不断出现。数据闭环的本质，是让车端运行数据持续转化为训练与评测资产，再以模型更新回到车端。一个可落地的闭环通常包含以下环节：

1. 触发与采集：通过影子模式、接管事件、急刹、低置信度、规划抖动等信号触发数据回传，避免全量上传造成带宽与存储浪费。
2. 场景挖掘与标注：按场景标签（加塞、鬼探头、施工区、无保护左转）聚类，配合自动预标注与人工质检，形成高质量标签。
3. 数据集版本化：训练集、验证集、测试集必须可追溯，记录数据版本、标签版本、代码版本与模型版本。
4. 训练与评测：训练产出候选模型，评测在离线回放、场景仿真、实车测试三层依次过滤。
5. 部署与回流：通过 OTA 灰度发布，车端监控指标回流，形成下一轮闭环输入。

三、训练、评测、部署一体化的意义

很多团队把训练、评测、部署当作三个独立阶段，结果出现三类典型问题：训练用 Python 框架、部署用 C++ 推理引擎，算子行为不一致导致精度掉点；评测集与训练集分布不同，离线指标很好但实车表现差；模型版本、数据版本、配置版本散落各处，问题无法复现。

一体化工程的核心目标，是让同一份模型定义、同一套数据版本、同一组评测指标贯穿训练、评测、部署全流程。具体价值体现在：

• 一致性：训练与推理共享算子语义与预处理逻辑，减少“离线好、上车差”的精度鸿沟。
• 可复现：任何一次评测结果都能追溯到数据、代码、模型、配置四元组。
• 效率：自动化流水线替代手工导出模型、手工跑评测、手工打包发布。
• 安全：评测门禁拦截回归，灰度发布限制影响范围，监控告警快速回滚。

四、典型场景：一次加塞场景的闭环处理

假设车端记录到一次旁车加塞导致急刹的接管事件。闭环流程如下：

触发条件: 接管 + 纵向减速度 > 3.0 m/s² + 旁车横向侵入
采集数据: 前视摄像头 30fps、激光雷达 10Hz、CAN 总线、规划轨迹
场景标签: cut_in / urban / 40km/h / 雨天
归因分析: 预测模块对旁车意图概率输出偏低，规划未提前减速
修复动作: 补充同类场景 1200 帧，调整预测损失权重，重训模型
评测验证: 离线回放通过 + 仿真 500 次通过 + 实车 20 次通过
部署发布: OTA 灰度 5% 车队，监控接管率与急刹率 72 小时

这个例子说明：闭环不是“采集—训练”两步，而是包含归因、修复、验证、发布、监控的完整工程链路。任何一环缺失，问题都可能再次发生。

五、常见误区与复盘要点

误区	表现	改进方向
只关注感知指标	mAP 很高，但实车仍频繁接管	建立端到端闭环指标，如接管率、急刹率、通行效率
评测集与训练集同源	离线指标虚高，泛化差	按场景、地域、天气分层划分，保留独立测试集
训练部署两套代码	精度掉点、算子不兼容	统一模型中间表示，训练后直接导出部署产物
版本管理缺失	问题无法复现，回滚困难	数据、代码、模型、配置四元组统一版本化
只做离线评测	仿真通过但实车失败	离线、仿真、实车三层评测，逐层放行

综上，感知、预测、规划、控制构成自动驾驶的实时主链路，数据闭环让系统具备持续进化能力，而训练评测部署一体化则保证这种进化是可控、可复现、可上线的。三者缺一不可，共同决定了自动驾驶系统从“能跑”走向“可靠”的工程上限。