端到端时代自动驾驶的主线：数据闭环与评测体系

1. 先把“主线”这个词掰开揉碎我做了五六年自动驾驶算法感知、预测、规控都沾过GTC26 的自动驾驶相关 session 基本一场不落。这一届看下来印象最深的不是某个具体的黑科技而是满屏的“端到端”三个字台上讲端到端台下也在聊端到端可每个人嘴里的端到端含义都不太一样。这篇文章不打算复述发布会我想从一个算法工程师的视角把“端到端时代自动驾驶的主线到底是什么”这个问题拆开聊一聊技术方向、落地方法还有我们这拨人接下来到底该把力气往哪使。在搞自动驾驶算法、正在转型入行、或者带算法团队的朋友应该都能从中找到一些能拿去用的判断。1.1 端到端快被说成“玄学”了先别急着争论模型第一步是搞清楚大家嘴里的端到端到底指什么。我在会上至少听到了三种说法一种是感知到规划的联合优化内部依然有明确模块只是接口可微另一种是传感器进、控制指令出的纯端到端中间完全靠网络自己表达还有一种是把大模型、世界模型、VLA 都塞进去的“大端到端”。这三类东西的训练方式、数据要求、失效模式、评测手段完全不一样硬放在一个词底下讨论最后必然会变成各说各话。这种含糊带出一个实际问题很多项目立项时说“我们要上端到端”但并没有定义是哪种端到端结果算法团队按联合优化做产品团队以为能去掉规则缓解管理层希望一步到位换掉整个老系统。不到三个月交付标准和预期就会开始打架。所以我的建议永远是谈端到端之前先把范围和验收约束写清楚否则后面大概率要互相甩锅。1.2 车圈聊的主线和算法圈聊的主线根本不是一回事把“主线”这个词放到自动驾驶语境里至少有两个完全不同的方向。车企和产品侧眼里的主线其实是“规模化迭代能力”能不能让系统又快又便宜地量产、能不能通过监管和保险、能不能让用户真的敢用。算法侧眼里的主线通常是“模型能力的下一个突破点”网络结构怎么演进、长尾场景怎么解决、新的训练范式什么时候能落地。这两个主线长期错位也是项目最容易对不齐的深坑。以我自己的经历为例。某次内部评审会上产品负责人问“端到端什么时候能去掉安全员”算法这边只能指着指标解释“接管间隔还差一个数量级而且长尾场景的置信度不够”。两边其实都认为自己在聊主线但一个聊的是商业化节奏一个聊的是技术成熟度。真正的分歧不是技术上的而是大家对“主线”的定义不同步。想明白了这一点很多争论其实能收敛成“先定主线口径再定优先级”的讨论。1.3 我的答案主线在数据闭环和评测体系现在说我的核心判断。模型架构的趋同速度比很多人想象得快。今天你手里的 Transformer 家族、VLA 范式、世界模型思路竞争对手大概率半年到一年内也会握在手里。但数据管道、自动标注体系、场景挖掘能力、评测基准、仿真回放系统这些东西没法靠一篇文章或一次开源快速复制它们需要持续投入并且得在真实路况里被反复打磨。所以我的答案很明确端到端时代自动驾驶的主线不是某一个更深的模型而是“数据闭环的工程效率”和“评测体系的诚实程度”。谁能让数据闭环转得更快谁的评测体系更能暴露问题谁就能在接下来的迭代竞赛里占住身位。这条判断贯穿我后面的所有内容后面的技术风向、落地细节、避坑经验都是围绕它展开的。2. GTC26 上我看到的四个技术风向2.1 风向一数据生产力取代模型炫技这一届 GTC26 上的自动驾驶分享给我的一个直观变化是大家不再只秀模型指标而是开始展示“数据是怎么被生产出来的”。某厂商的流水线从路采原始数据开始经过场景挖掘、自动标注、难例筛选再到训练集发布全链路讲得很细。另一个团队讲的是如何把一次真实碰擦事件的几十秒录像重建成高保真场景再扩展出成百上千个带噪声变体的训练样本。这个变化背后其实是被逼出来的。当大家的骨干网络都差不多时端到端模型的泛化能力基本是由训练数据的分布决定的。你想让模型学会极端近距离切入、不规则路口、刁钻天气下的行为靠手写规则和人工调参根本不现实只能靠持续地往训练集里注入高质量稀缺样本。所以“数据从哪来、怎么标注、怎么去重、怎么保证质量”这类问题反而变成了最值钱的算法问题。2.2 风向二场景重建与生成式仿真成为标配和上一届相比场景重建、生成式仿真这次明显从“学术 demo”变成了“工程基座”。基于神经辐射场或三维高斯溅射的方向能把路采视频恢复成可以任意变换视角、调整光照的虚拟场景扩散模型则被用来生成现实中很难遇到的对抗性场景比如碎片横飞的匝道、突然压线的大车。配合一套可控场景编辑器测试效率能得到数量级提升。我在这块吃过亏。早期做仿真用的是手搭的 3D 场景模型在仿真里跑得顺风顺水一上真车就露馅原因是仿真场景和真实路采在纹理、遮挡、传感器噪声上的差距太大。后来改成“真实场景重建加参数化扰动”也就是先把真实录像重建出来再在重建场景里加扰动、换天气、改障碍物轨迹测试结果和实车的相关性才明显提上来。这个转变也让我理解了为什么 GTC26 上各家都在强调场景重建因为它本质上是在补“仿真与真实之间的桥”。2.3 风向三大模型开始渗透规控VLA 概念持续升温VLA视觉-语言-动作模型是这次会上被反复提及的词。粗看它和端到端是同一条路线的延伸把视觉输入、语言指令和动作输出统一到一个模型里。争议点也很现实语言模型对驾驶究竟是有真理解还是在用海量数据“记忆”场景。我的倾向是VLA 更适合处理需要常识推理和用户交互的细分场景比如理解“前车打灯但意图模糊”“施工标识和导航出现矛盾”但在安全关键的执行路径上短期还是得靠轻量模型加规则兜底。这里可以把几条技术路线放在一起看路线可解释性数据需求部署成本适合场景模块化传统方案高中中安全兜底、按模块验收纯端到端方案低高中感知到规划联合优化、弱规则场景VLA/大模型混合中很高高复杂推理、人机交互、小概率事件对算法工程师来说选哪条路线不取决于谁的论文更漂亮而取决于团队手里的数据、算力和评测能力能不能撑起这条路。很多团队一上来就追 VLA结果连基础的数据闭环都没有模型训出来根本没法验收这个顺序我觉得是错的。2.4 风向四车端推理效率被摆上台面大模型往车端走第一个撞上的就是算力、功耗和时延这三堵墙。今年的分享里针对注意力机制的稀疏化、低比特量化、token 化的时空表达、流式推理这些技术被反复提到说明大家已经不再满足于在云端跑大模型而是开始认真考虑“它能不能在车里实时跑”。对量产项目来说模型涨两三个点的指标通常抵不上一句“端到端延迟增加 10 毫秒就不能上车”。我自己做部署时的体感是算法工作量的重心正在从“刷精度”往“精度、延迟、功耗三角”转移。一个看起来简单的量化操作放到量产链路里可能要过功耗测试、热管理测试、寿命老化测试。所以如果你的团队想走端到端路线建议从立项第一天就把部署团队拉进来而不是等模型训好了再谈优化否则大概率要推倒重来。3. 端到端项目落地我踩过的坑和攒下的经验3.1 数据闭环的最小可用版本怎么搭很多人以为端到端项目的第一步是选模型但我的经验是第一步永远是搭闭环。最小可用版本大概这么几条线采集按触发条件收集原始数据触发条件可以是重刹车、近距离切入、异常天气、高精地图边界等。粗筛与去重先去掉无效路段再用向量聚类降低重复度保留高信息量片段。自动标注用基础模型先标一遍人工只抽检高难样本而不是全部人工标注。训练与对比新模型和旧模型在同一个固定评估集上做 AB 对比指标不涨不准进下一环。回放与仿真把新样本注入仿真环境跑一轮闭环测试确认没有明显退化。影子模式验证在车上并行跑统计收集接管和干预样本。回流把失败样本重新送回标注和训练环节形成循环。听起来不复杂但每条线上都有坑。采集触发条件定得太松一天能录十几个小时无效数据定得太紧关键的接管前几秒又总录不上。自动标注省了人力但模型标注错的东西被当成真值喂回去就是雪球式的自污染。我自己的做法是给每一批训练数据都加“来源标记”回放评测时按来源切片看指标哪一批数据让指标变差能很快定位到是哪个环节出了问题。注意数据闭环的价值不是“数据量”而是“最短回旋时间”。从发现一个 bad case 到它变成训练样本再到评测回流这个周期能不能压缩到一周以内往往决定了团队的迭代速度。3.2 影子模式是最便宜的安全验证方式真实路测成本极高端到端模型又没法像规则系统那样逐条去查逻辑影子模式就成了性价比很高的验证手段。做法并不复杂把新模型部署在一批车上但不让它控制车辆只在后台和线上系统并行运行记录它的输出、线上系统的输出、以及最终驾驶员的行为。一旦人类接管、触发紧急制动、或者规则系统介入这几秒的传感器数据连同三个输出就一起被存下来成为后续分析的样本。这里要特别说一个常见的认知误区影子模式收集的样本在严格意义上不是“模型错了”而是“模型和人类行为不一致”。不一致不一定是错误可能只是策略风格不同。我们当时给差异做了分类安全相关差异、舒适度差异、无效差异。只有安全相关差异才会被直接加入训练集舒适度差异可能只是参数调整无效差异直接丢弃。不做这个分类训练集里很快会堆满“看似重要但毫无训练价值”的噪声。3.3 别拿单一指标验收模型三层评估体系端到端模型最怕用单一指标验收。我们的评测体系分三层每一层回答不同的问题层级关注对象代表指标反映的问题场景层典型与长尾场景场景通过率、成功率功能覆盖率够不够系统层整体系统表现平均接管间隔、干预次数、最小风险状态触发率安全和稳定性是否达标体验层乘客主观感受横向冲击度、加速度变化率、跟车时距、主观评分用户愿不愿意用三层指标的视角完全不同。场景通过率高只能说明设计好的场景没问题说明不了真实路口涌现出来的各种组合平均接管间隔高了又可能意味着系统在边缘场景里过于保守。所以我给团队定了一个硬规矩发布模型必须同时跑这三层且任何一层出现明显回退都不能上线。哪怕整体指标在涨某一层回落也得先解释原因再说。因为这个回落往往就是下一次事故的种子。3.4 端到端也要有安全带部署侧的兜底设计我再强调一遍我的观点端到端负责聪明兜底负责不蠢。量产系统里安全兜底不是要不要的问题而是怎么设计边界的问题。具体来说输入端要做传感器一致性检查和信号质量校验输出端要对控制指令做范围限制、平滑处理和单调性约束系统级还要有最小风险状态MRM一旦端到端模型给出明显越界的输出自动切到规则安全模式或执行减速、靠边停车。有人会觉得加规则兜底是“退回到传统方案”我不这么看。规则兜底本质上是一个浅层的高频保护回路它和端到端模型并不是二选一而是叠加关系。真正危险的是把宣传话术当成技术方案觉得“端到端不需要规则”。我见过不止一个项目因为盲目追求“纯端到端”而砍掉兜底逻辑最后在评测中暴露出大量本可以用简单规则挡掉的风险。这个教训希望看到这篇文章的朋友能记住。4. 常见问题速查新手最容易卡住的地方4.1 训练不收敛、效果时好时坏怎么办端到端项目里“训练不收敛”和“效果忽好忽坏”是最常被问到的问题。但我的排查经验里一大半情况根本不是训练的问题而是评测不稳定。换个随机种子、换一批数据采样同一套代码的评估结果都能差一大截那你怎么判断迭代方向所以遇到这类问题第一件事是固定评估集、固定推理参数、固定随机种子先确认你的观测本身是稳定的。如果确认了训练确实有问题再从头检查数据分布。端到端模型对数据分布极其敏感某个场景类别样本突然变多或某批自动标注的标签存在系统性偏差loss 曲线就会变得“看着玄学”。我们的惯例是按数据来源和场景切片看指标单独观察长尾子集的 loss 和精度。几乎所有“时好时坏”的模型最终都能定位到某个数据来源的标签质量在波动。4.2 仿真成绩很好、实车一塌糊涂的排查思路这是最经典的落差我在不同项目里遇到过不止一次。仿真成绩漂亮说明模型在“标准输入”上表现良好失败的根因通常有三类第一是传感器差异仿真里的点云和图像太干净缺少真实噪声、运动模糊和遮挡第二是时序差异实车有控制延迟、底盘响应和标定误差仿真往往过于理想第三是场景组合差异仿真脚本不会自动生成真实世界里那些“半遮半掩、意图不明”的交通参与者组合。所以如果仿真成绩好而实车差我的建议是别急着改模型先做输入一致性测试。把实车采集的原始数据拿到仿真环境里做回放看模型输出是否和实车端一致如果不一致很可能是时序对齐、传感器标定或者推理环境不同造成的。把这一层问题先清掉再谈模型本身行不行。4.3 长尾场景数据永远不够到底怎么取舍端到端时代大家都抱怨长尾数据永远不够但“不够”其实不是一个数量问题而是分布问题。你需要的是“对场景空间的覆盖率”不是绝对数据的多少。我们在做数据预算时会先按“风险等级乘发生频率乘可挖掘难度”给场景排序优先补那些高风险、有一定发生频率、又最容易通过采集或仿真拿到足够样本的场景而不是看到什么有趣就采什么。另外一个取舍原则是看数据的“有效信息量”。一条 100 公里的平顺高速对模型的训练价值可能不如一个 5 秒的极端切入片段。所以采集端我们会刻意配置触发条件只存有用的片段离线端再用嵌入向量做聚类去重把重复度极高的样本降到最低。用这个思路训练集可以在不涨绝对样本量的前提下明显提升模型在长尾上的表现。4.4 团队转型算法工程师的“新基本功”最后聊个和每个人直接相关的事端到端时代算法工程师的角色正在变化。以前大家觉得算法工程师就是写模型、调参、刷指标但现在更值钱的技能是理解数据从哪来、标注怎么做、评测怎么搭、仿真怎么用、部署怎么落。我招聘时基本不先问网络结构而是让候选人现场设计一个数据闭环从发现 bad case 开始说明怎么筛数据、怎么标注、怎么训练、怎么验证、怎么回流。这个问题的答案基本能看出一个人是在做“模型”还是在做“系统”。我不是说要放弃模型能力恰恰相反理解模型原理仍然是基本功。但在端到端时代模型越来越像一个大工业系统里的标准件真正拉开团队差距的是把这个标准件装进数据闭环和评测体系里的工程能力。所以我的建议很直白每周留一点时间去看数据管道、评测平台和仿真工具的进展比追着每篇新论文跑更有长期复利。5. 我再多说几句个人判断5.1 两三年内主线大概率还是这三件事把自己这些年看到的和踩过的放在一起我对端到端时代主线的最终判断是三条第一数据闭环的工程效率这决定你迭代的速度第二可解释、可验证的安全体系这决定你敢不敢把系统交给用户第三低成本、可扩展的部署能力这决定你能不能把技术变成产品。这三条每一条做扎实都比单纯堆模型参数更接近自动驾驶的真正主线。这里也是想给刚开始关注这个领域的朋友提个醒别被“某个网络刷新了指标”的新闻带着走。新闻里的每个突破放在真实量产语境里通常只是整个系统的一小块拼图。看一场技术会议最有价值的动作不是记住几个炫酷的名字而是观察各家在数据、安全和工程上到底把资源押在了哪里。5.2 算法工程师接下来建议补的三类能力如果非要给同行一个更具体的建议我会说补三类能力。第一是数据工程能力包括场景挖掘、自动标注质量评估、数据版本管理第二是评测与仿真能力能设计出暴露问题而不是掩盖问题的评估方案第三是部署与量化能力理解模型在真实算力、功耗和延迟约束下如何存活。这三类能力不会因为某个新模型出现而贬值反而会在行业回归理性后变得越来越刚需。顺便说一句很多在校学生或者想转入自动驾驶的朋友一上来就研究最前沿的模型结构这没错但我更建议他们同时花时间做小规模的闭环项目自己设计一个最小数据管道、训练一个小模型、再搭一套简单的回放评测。这个闭环哪怕是玩具级别也会让你在面试和实际工作中的认知比别人高一层因为你会真正理解“纸上模型”和“线上系统”之间的距离。5.3 最后分享一个我自己的工作习惯我平时有个习惯每隔一段时间就把最近一次模型发布时的失败案例重新翻出来看一遍记录“当时为什么没发现”“后来是怎么发现的”“如果重来一次哪个环节可以先拦住”。端到端系统最大的风险就是问题发现得晚因为它的失败往往不是一个模块的逻辑错而是数据分布、标注质量或者评测盲区一点点累积出来的。这个复盘习惯帮我在很多项目里提前挡住了问题也希望对你有点用。算下来我在这个行业里也踩了不少坑但对自动驾驶这件事仍然保持乐观。端到端不是魔法它只是把更多决策交给了数据而数据背后的工程体系恰恰是我们这些算法工程师最能发挥价值的地方。多关注闭环、多盯住安全、多理解部署比任何单点技术突破都更能决定你在这个时代的位置。