← 返回 PaperDaily 视觉与图像

CVPR 2026前后脚？DriveVer让自动驾驶“先验再改”，34M参数补上安全一刀

自动驾驶最怕的不是“不会开”，而是“开错了还直接上路”。这篇 DriveVer 很有意思：不重训大模型，偏偏把活放到测试时做二次验证和修正，34M 参数、80ms 推理，工程味很足。

龙哥读论文 阅读 3 查看原文
#自动驾驶 #多模态 #模型架构
CVPR 2026前后脚？DriveVer让自动驾驶“先验再改”，34M参数补上安全一刀
🐉 龙哥读论文知识星球来了！
公众号每日8篇拆解不够看？星球无上限更AI领域论文、资讯、招聘、招博、开源代码，一站式干货，每日2分钟刷完即赚！
👇扫码加入「龙哥读论文」知识星球，前沿干货、实用资源一站式拿捏～ xingqiu_header

龙哥推荐理由：
自动驾驶最怕的不是“不会开”，而是“开错了还直接上路”。这篇 DriveVer 很有意思：不重训大模型，偏偏把活放到测试时做二次验证和修正，34M 参数、80ms 推理，工程味很足。


原论文信息如下：
论文标题:
DriveVer: Lightweight Trajectory Evaluator as Test-Time Verifier for Autonomous Driving
发表日期:
2026年07月
发表单位:
没有
原文链接:
https://arxiv.org/pdf/2607.00399v1.pdf

为何需要“测试时验证”？

自动驾驶里最怕的一件事，不是模型“不会开”，而是它“看起来会开，实际上把车往坑里送”。很多端到端规划器在训练时一路加大模型、加大数据、加大算力，成绩确实会涨，但代价也很直白：训练越来越贵，收益越来越像挤牙膏。更麻烦的是，绝大多数规划器还是一次性生成：感知一进来，轨迹一吐出来，后面就直接交给控制器执行，几乎没有“复查”和“改错”的机会。
DriveVer 的思路很反常识：既然训练时继续堆料越来越贵，那就把一部分功夫挪到测试时做。它不去改底层规划器的结构，而是在推理阶段额外挂一个轻量验证器，先判断这条轨迹靠不靠谱，再决定要不要修、往哪修。说白了，就是给自动驾驶加了一个“出门前先照镜子”的环节。🤚
图1：不同规划范式的概念对比。左边是传统的一次性轨迹输出，右边是 DriveVer 在测试时先验证、再修正轨迹，并给出安全分数。
这类方法真正有价值的地方，不在于“又多了一个模块”，而在于它把问题从“训练一个更大的规划器”改成了“训练一个更会挑错、也更会改错的小模块”。对于自动驾驶这种强实时场景，这个思路很务实：大模型负责出第一版答案，小验证器负责做第二次把关。别小看这一步，很多事故风险就是从“第一版答案看上去还行”开始的。

DriveVer的“双头”架构如何工作？

DriveVer 的输入并不神秘：多视角相机图像、车辆自身状态、导航指令，以及基座规划器给出的初始轨迹。它的关键不是“看更多”，而是“看懂轨迹和场景之间的关系”。为此，论文把它设计成一个双头架构：一个头负责打分，另一个头负责修正。
图2：DriveVer 总体架构。置信分支输出一个安全置信分数，用来判断是否需要介入；修正分支输出几何修正方向。推理时只有在置信分数超过阈值后，才会真正触发轨迹优化。
先说置信分支。它输出的是一个标量分数，作用很直接：判断这条初始轨迹是不是已经足够好，值不值得再动刀。这个设计非常关键，因为不是所有轨迹都适合“强行修一遍”。如果基座规划器本来已经很强，验证器还硬改，结果可能是好心办坏事，把原本不错的轨迹修坏了。论文的消融实验就证明了这一点：没有置信分支时，某些高质量轨迹反而会被修得更差。
再说修正分支。它不是直接预测每个点的绝对坐标残差，而是学习一个“几何修正方向”。这点听起来像换了个说法，实际差别不小。绝对残差要求模型精确猜每个点要挪多少，容易被细碎误差绑住；方向向量更像告诉模型“往哪边改更合理”，关注的是整体趋势，而不是每个 waypoint 的死磕。论文在这里用的是余弦相似度损失，英文是 cosine similarity loss，中文就是让预测方向和真实方向尽量对齐。这个做法很像开车时导航说“往左一点”，而不是精确到“左移 0.37 米”。人话更自然，模型也更稳。😏
Fig. 3
图3：置信分支和修正分支里使用的 Transformer Decoder 结构。它通过与场景 token 做交叉注意力，把轨迹、视觉信息和车辆状态对齐起来。
这里还有一个很工程化的点：视觉编码器并不是从零训练，而是借用了 DrivoR 的视觉编码思路，并用 LoRA（Low-Rank Adaptation，低秩适配）去做参数高效微调。LoRA 的意思很简单：不把大模型全身都重新训练一遍，而是只在关键位置加少量可学习参数，省钱、省显存、也更容易落地。DriveVer 的视觉骨干还冻结了参数，进一步压低了训练成本。对于一个“外挂式验证器”来说，这种配置很合理：别把自己也训练成一个巨兽，轻量才是正道。
推理阶段的逻辑也很朴素：先由置信分支判断是否需要介入，只有当分数超过阈值时，修正分支才会启动。也就是说，DriveVer 不是每次都“全力修车”，而是按需出手。这个设计的本质是节流：把算力用在最需要的地方，避免在已经足够好的轨迹上白白浪费时间。
Fig. 4
图4：定性可视化对比。红色是 DiffusionDrive 的初始轨迹，蓝色是 DriveVer 修正后的轨迹，绿色是真实轨迹。可以直观看到，DriveVer 会把危险轨迹往更安全的车道中心、可行驶区域里拉回来。

如何在数据匮乏场景下训练验证器？

验证器最难的地方，不是网络结构，而是数据。因为普通自动驾驶数据集通常只有“人类专家轨迹”这种高质量正样本，真正适合训练验证器的“好轨迹、坏轨迹、半好不坏轨迹”并不多。没有这些样本，模型就很难学会一条轨迹到底是“还能救一下”，还是“已经该重来”。
DriveVer 的办法是基于 NAVSIM 重新构造一个专门的轨迹验证数据集。这里的 NAVSIM 是一个来自真实世界 nuPlan 的基准，强调的是那些很难靠历史模式外推的复杂场景。论文先按车辆状态和导航指令做条件聚类，再从每个场景里采样出一组候选轨迹。这样做的好处是：同一个场景里既有高质量轨迹，也有低质量轨迹，模型才能真正学会“分辨差异”。
接着，论文用 PDMS（Predictive Driver Model Score，预测驾驶模型分数）给每条候选轨迹打分。这个分数综合了碰撞、可行驶区域、时间碰撞风险、舒适性和前进效率等指标。简单理解就是：不是只看“像不像人类开车”，而是看“开得安不安全、顺不顺、有没有真正往前走”。对于自动驾驶来说，这种闭环指标比单纯的轨迹拟合更有意义。
为了让模型别被“全是好样本”带偏，论文把轨迹按分数切成高质量和低质量两组，再做平衡采样。最后还把人类专家轨迹加进去作为参考。这样得到的数据池既有正样本，也有负样本，还有贴近边界的中间样本，验证器学到的就不是“见好就说好”，而是更细的判断边界。这个思路很像训练一个裁判：不能只看冠军队，还得看犯规队和擦边球队，不然裁判上场就只会鼓掌了。😂
在监督信号上，修正分支并不直接学“坐标差”，而是学“从初始轨迹到专家轨迹的方向”。这种设计的直觉很强：现实里轨迹修正往往不是逐点精确回归，而是先判断大方向，再做细调整。比如一条轨迹太靠近路边，修正的关键不是每个点都算得毫米不差，而是整体往车道中心偏回去。方向监督更符合这个逻辑，也更利于泛化。
TABLE III
表3：置信分支消融实验。可以看到，加入置信分支后，多个基座规划器的 PDMS 都更稳，说明“先判断要不要修”这一步确实不是摆设。
TABLE IV
表4：修正方式对比。方向向量 + 余弦损失的方案优于直接回归绝对残差的方案，说明“学趋势”比“死抠坐标”更适合这个任务。

能否实时运行在自动驾驶系统上？

自动驾驶论文最容易翻车的一点，就是实验看着很漂亮，一上车就卡成 PPT。DriveVer 这次在工程上交代得比较清楚：模型只有 34M 参数，在单张 NVIDIA 4090 上，修一条轨迹大约 80ms。这个数字不算“毫秒级神话”，但放在测试时验证这个任务里，已经很接近可用区间了。
更重要的是，它不是一个需要重构整套规划系统的巨型模块，而是一个即插即用的后处理验证器。论文把它接到多个不同的基座规划器上，包括 DiffusionDrive、AdaThinkDrive、ELF-VLA 和 DrivoR，结果都能带来稳定提升。工程上最怕这种“只能在自家模型上灵”的方法，而 DriveVer 至少从实验上证明了自己不是只会挑食。
TABLE I
表1：NAVSIMv1 上的主结果对比。DriveVer 接到不同基座规划器后，PDMS 都有稳定提升，其中对 DiffusionDrive 的增益最明显。
TABLE II
表2：NAVSIMv2 上的主结果对比。DriveVer 在更复杂的 EPDMS 指标下依然能带来小幅但稳定的收益，说明它不只是对单一版本有效。
从结果上看，DriveVer 的提升幅度不是那种“把榜单掀翻”的夸张型，而是更像一个靠谱的安全补丁：有的基座模型涨得多一点，有的涨得少一点，但整体趋势一致。尤其值得注意的是，强基座模型上也能继续涨分，哪怕只是 0.1、0.2 这种小数点级提升，也说明它不是简单靠“把差模型救回来”吃饭，而是真的学到了一些有效的轨迹评估和修正能力。
定性可视化也挺直观。图4里能看到，DriveVer 会把贴近障碍物的轨迹往车道中间拉，把偏离可行驶区域的轨迹拉回合法区域。这类修正看起来不像“花活”，更像是把自动驾驶里最值钱的那点常识补上了：别撞、别越界、别离前车太近。听起来朴素，做起来一点也不朴素。
不过也要冷静一点看。DriveVer 目前解决的是“在已有轨迹上做验证和修正”，不是从根上解决规划器的感知盲区，也不是替代完整的安全验证体系。它更像一层轻量保险，而不是万能刹车。对于极端复杂场景，修正器能改善多少，仍然依赖基座规划器给出的初始轨迹质量；如果初始轨迹已经离谱到没法救，验证器也不是魔法师。😊

龙迷三问

下面是龙哥对于大家可能的一些问题的解答：

这篇论文到底解决什么问题？它解决的是自动驾驶规划里“只出一次答案、没法复查”的老毛病。DriveVer 在测试时额外做一次验证和修正，让基座规划器的初始轨迹更安全、更稳。

PDMS 和 EPDMS 是什么意思？PDMS 是 Predictive Driver Model Score，中文可理解为“预测驾驶模型分数”，综合碰撞、可行驶区域、碰撞时距、舒适性和前进效率；EPDMS 是 Extended Predictive Driver Model Score，中文可理解为“扩展预测驾驶模型分数”，在新版本里加入了更多交通规则和舒适性相关项。

为什么不用直接回归绝对轨迹残差？因为绝对残差更像“逐点抠坐标”，容易让模型被局部误差绑架；方向向量更关注整体修正趋势，配合余弦损失后，通常更稳、更容易泛化到没见过的场景。

如果你还有哪些想要了解的，欢迎在评论区留言或者讨论~

龙哥点评

论文创新性分数：★★★✰✰

把测试时验证引入自动驾驶轨迹规划，思路不算空前，但把“打分 + 修正 + 轻量部署”做成一个即插即用模块，方向是对的。

实验合理度：★★★★✰

接入多个基座模型、同时看 NAVSIMv1 和 NAVSIMv2，还做了置信分支和修正方式消融，实验链条比较完整，可信度不错。

学术研究价值：★★★★✰

它把“测试时算力”这条路往自动驾驶里推进了一步，尤其对安全验证、轨迹修正和轻量后处理模块都有启发。

稳定性：★★★✰✰

轻量、可插拔是优点，但它仍依赖基座规划器给出“还能修”的初始轨迹，极端场景下不可能包打天下。

适应性以及泛化能力：★★★★✰

能挂到多个不同规划器上，说明适配性还可以；不过泛化到更复杂城市、不同传感器配置时，仍需要进一步验证。

硬件需求及成本：★★★★✰

34M 参数、80ms/轨迹，这个成本在验证器里算很克制了；如果不是极端低算力车端，部署门槛不高。

复现难度：★★★✰✰

方法主体不复杂，但数据构造和场景采样策略是关键，细节没拿稳的话，复现结果可能会打折。

产品化成熟度：★★★✰✰

作为规划器后处理安全模块已经有雏形，但要进真实车队，还需要更严格的长尾场景验证和失效保护机制。

可能的问题：提升幅度总体偏稳健而非爆炸式，且依赖高质量候选轨迹；若基座模型初始输出过差，验证器的上限也会被拖住。


主要参考文献

[1] He C, Luo Y, Li F, Xu S, Wen F. DriveVer: Lightweight Trajectory Evaluator as Test-Time Verifier for Autonomous Driving. arXiv, 2026.
[2] NAVSIM benchmark official paper and dataset documentation, used in this work for training and evaluation.
[3] DrivoR visual encoder and LoRA-based parameter-efficient fine-tuning strategy, referenced by the proposed model.

轨迹先过一遍“安检”，再上路，心里才更踏实。想看更多这种能落地、讲效率、重安全的AI论文，欢迎加入『龙哥读论文』星球和微信群，一起把前沿拆成能用的干货。
扫描下方二维码，备注“自动驾驶+地点+学校/公司+昵称”即可进群～

end
欢迎加入龙哥读论文粉丝群，扫描下方二维码或者添加龙哥助手微信号加群：kangjinlonghelper。一定要备注：研究方向+地点+学校/公司+昵称（如 图像处理+上海+清华+龙哥），根据格式备注，可更快被通过且邀请进群。
『龙哥读论文』微信群目前包含：图像处理、大模型及智能体、自动驾驶及机器人、AI医疗及AI金融5个群
wechat_helperdianzan
转发文章 微博 X LinkedIn Facebook
龙哥读论文 · PaperDaily

本文基于龙哥读论文 PaperDaily 数据库整理，结合论文原文与工程视角进行解读。