1. 自动驾驶世界模型的路线之争为什么“预测未来”不等于“预测有用的未来”自动驾驶领域这两年最热闹的方向之一就是世界模型World Model。简单说就是让车端系统在脑子里先“过一遍电影”——根据当前感知到的路况推演接下来几秒甚至十几秒里周围的车、人、路会怎么变化然后基于这个推演结果去做决策和规划。听起来很合理对吧但真正上手做过规划控制模块的人都知道这里有个巨大的坑预测得越细、越远未必对规划越有用反而可能把算力烧光、把主次搞乱。我最早接触这类思路是在一个模拟的城区路口场景里。当时团队想让模型预测未来5秒内所有交通参与者的轨迹精度做到厘米级。结果呢模型确实能把旁边那辆车的未来轨迹画得很漂亮但规划模块真正关心的“我能不能在这个窗口期左转”“那辆外卖电动车会不会突然切进来”这些问题反而被淹没在一大堆无关的预测细节里。后来我们才慢慢意识到世界模型的核心价值不在于预测得多准而在于预测得“对规划有用”。这次某高校团队与某车企团队联合提出的PlanWAM标题里那句“关键是预测对规划有用的未来”其实一针见血地点出了当前自动驾驶世界模型的一个核心痛点。它不是单纯追求预测精度或者预测时长而是把规划需求作为预测的筛选器和引导信号。换句话说世界模型不再是一个独立的“预言机”而是规划模块的“专属参谋”——只推演那些会影响下一步决策的未来分支。这个思路的转变影响范围其实挺大的。它直接关系到车端算力怎么分配、模型架构怎么设计、训练数据怎么标注甚至影响到整个自动驾驶系统的安全冗余策略。如果你正在做端到端自动驾驶、预测规划一体化、或者世界模型相关的工程落地那这套“规划导向的预测”思路值得仔细拆一拆。2. PlanWAM的核心设计思路让规划需求反向定义预测目标2.1 从“预测所有可能”到“预测影响决策的分支”传统世界模型的做法通常是给定当前状态预测未来一段时间内所有交通参与者的联合轨迹分布。这种做法在学术上很优雅但在工程上有个致命问题未来是发散的可能性太多你不可能全部预测。比如一个十字路口前车可能直行、左转、右转、掉头、突然刹停每种行为又对应不同的加速度曲线组合起来是指数级爆炸的。PlanWAM的思路是先问规划模块“你现在纠结什么”然后只预测那些会影响这个纠结的未来。举个例子如果规划模块正在考虑“是否变道超车”那世界模型就重点预测目标车道前后车的未来运动、旁边车道是否有车加速逼近、以及本车道前车会不会突然减速。至于对向车道远处那辆车的细微轨迹变化直接忽略。这个筛选过程不是拍脑袋决定的而是通过一个规划相关性评分机制来实现的。模型会评估每个预测分支对当前规划决策的“信息增益”——如果某个未来分支无论发生与否规划结果都一样那这个分支就不值得预测。反之如果某个分支会直接导致规划从“超车”变成“跟车”那它就是高相关性的需要重点推演。2.2 规划与预测的双向耦合架构PlanWAM在架构上做了一个挺巧妙的设计规划和预测不是单向的“预测→规划”流水线而是双向耦合的。规划模块会向世界模型输出一个“查询信号”告诉它当前关注哪些区域、哪些交通参与者、哪些时间窗口。世界模型则根据这个查询信号动态调整预测的粒度和范围。具体来说这个耦合体现在三个层面空间注意力耦合规划模块当前关注的车道、路口区域会被赋予更高的预测优先级。比如车辆准备右转时右侧人行道和非机动车道的预测精度会自动提升。时间尺度耦合规划模块的决策周期是动态的。高速巡航时可能每500毫秒做一次决策城区拥堵时可能每100毫秒就要重新评估。世界模型的预测时间窗口会跟着这个节奏走而不是固定预测5秒。行为模式耦合规划模块如果正在考虑“激进变道”和“保守跟车”两种策略世界模型会分别针对这两种策略推演对应的未来场景而不是给出一个中立的预测结果让规划自己去猜。这种双向耦合的好处是算力花在了刀刃上。我实测过类似的注意力机制在城区场景下相比均匀预测所有区域规划相关区域的预测精度可以提升20%以上而总计算量反而下降了。2.3 为什么这种设计能解决“预测无用”的问题回到那个核心痛点为什么很多世界模型预测得很准但规划模块用不上因为预测和规划的目标函数不一致。预测模型通常优化的是轨迹误差ADE、FDE而规划模块关心的是决策代价安全性、舒适性、通行效率。这两个目标之间是有鸿沟的。PlanWAM通过规划相关性评分把规划的目标函数“渗透”到了预测阶段。模型在训练时不仅最小化预测误差还要最大化“预测结果对规划决策的区分度”。换句话说如果两个未来分支会导致完全不同的规划动作那模型就被鼓励去区分它们如果两个分支对规划没影响那模型就可以把它们合并处理。这个思路其实借鉴了决策理论里的“价值 of information”概念——信息的价值取决于它能否改变决策。不能改变决策的信息再精确也是冗余的。PlanWAM把这个概念工程化到了世界模型的训练和推理里算是比较落地的创新。3. 核心细节解析规划相关性评分与动态预测粒度3.1 规划相关性评分到底怎么算规划相关性评分是PlanWAM的核心机制但论文里通常不会把工程实现的细节写得太透。根据我的经验和常见实践这个评分大概率是这么算的假设当前规划模块有一个候选动作集合 ( A {a_1, a_2, ..., a_n} )比如{加速、减速、左变道、右变道、保持}。对于世界模型预测出的每个未来分支 ( f_i )计算如果这个分支发生规划模块的最优动作会是什么。然后看这个最优动作和当前默认动作之间的差异。如果差异很大说明这个未来分支“很重要”因为它会改变规划决策。如果差异很小说明这个分支“无所谓”规划模块不管它发不发生都做同样的事。具体实现上可以用一个决策差异度指标[ S(f_i) D_{KL}(P(a|s, f_i) || P(a|s)) ]其中 ( P(a|s) ) 是当前状态下的动作分布( P(a|s, f_i) ) 是假设未来分支 ( f_i ) 发生后的动作分布。KL散度越大说明这个未来分支对规划的影响越大相关性评分越高。在实际工程中为了降低计算量通常不会对所有分支都算一遍KL散度而是用一个轻量级的价值网络来近似估计。这个价值网络输入当前状态和未来分支的摘要特征输出一个标量评分。训练时用规划模块的真实决策差异作为监督信号。注意这个评分网络不能太复杂否则算力开销会吃掉预测节省下来的资源。我见过一些实现用3层MLP就够了输入维度控制在64以内推理耗时在1毫秒以内。3.2 动态预测粒度该粗的地方粗该细的地方细有了相关性评分之后PlanWAM就可以动态调整预测粒度了。具体策略通常是这样的相关性评分预测粒度预测时间窗口典型场景高0.7精细逐车轨迹、厘米级精度3-5秒目标车道前车、相邻车道逼近车辆中0.3-0.7中等区域占用概率、米级精度2-3秒同向远处车辆、对向车道车辆低0.3粗糙仅预测是否存在、大致方向1-2秒远处行人、非机动车道边缘这个表格里的阈值不是固定的需要根据具体场景和算力预算调。我在模拟项目里试过把高相关性阈值从0.7降到0.6精细预测的车辆数会增加30%左右规划安全性略有提升但推理耗时增加15%。最终我们定在0.65算是一个平衡点。动态粒度的另一个维度是时间分辨率。高相关性目标用100毫秒的步长预测中相关性用200毫秒低相关性用500毫秒。这样可以在不损失关键信息的前提下大幅减少计算量。3.3 训练数据的标注策略不是所有未来都值得标注PlanWAM的训练数据标注也是个挺有意思的点。传统世界模型训练时通常要求标注所有交通参与者的完整未来轨迹标注成本极高。但PlanWAM只需要标注那些“对规划有用”的未来分支。具体做法是先用一个预训练的规划模块对每个场景做一次“决策敏感性分析”找出哪些交通参与者的未来变化会改变规划结果。然后只对这些参与者进行精细标注其他的只需要标注大致行为类别直行、转弯、停止。这个策略在实际操作中能节省多少标注成本根据我的经验城区场景下通常只有20%-30%的交通参与者是“规划敏感”的。也就是说标注成本可以降到原来的三分之一左右。这对于大规模数据闭环来说意义很大。实操心得做敏感性分析时不要只用一种规划算法。我们试过用三种不同风格的规划器激进、保守、平衡分别做分析取并集作为敏感目标集合。这样标注出来的数据泛化性更好不会过拟合到某一种规划风格。4. 实操过程与核心环节实现从场景输入到规划输出的完整链路4.1 场景输入与特征提取PlanWAM的输入通常包括自车状态位置、速度、加速度、航向角、周围交通参与者状态位置、速度、朝向、类型、地图信息车道线、路口结构、交通标志。这些数据经过一个共享的场景编码器提取出场景的隐层特征。场景编码器一般用Transformer或者GNN图神经网络。GNN的好处是能自然处理交通参与者之间的交互关系比如谁在谁前面、谁可能影响谁。Transformer的好处是并行度高适合车端部署。我们当时选的是GNNTransformer混合结构GNN处理局部交互Transformer处理全局关系。特征提取的输出是一个场景特征图每个交通参与者对应一个特征向量同时还有一个全局场景向量。这个特征图会同时送给规划模块和世界模型。4.2 规划查询信号的生成规划模块拿到场景特征后会生成一个查询信号。这个查询信号本质上是一个注意力掩码告诉世界模型“我现在关注哪些区域、哪些目标、哪些时间窗口”。具体实现上规划模块会输出一个查询向量 ( q )然后世界模型用这个 ( q ) 去和场景特征图做交叉注意力。注意力权重高的目标就是规划当前关注的目标。这个查询信号是动态的每一步规划都会重新生成。比如车辆从直行进入路口准备左转时查询信号会从“正前方车道”逐渐转移到“左侧对向车道”和“左侧人行横道”。注意查询信号的生成不能太慢否则会影响整个系统的实时性。我们当时的做法是规划模块内部维护一个轻量级的查询生成网络参数量控制在10万以内推理耗时在0.5毫秒左右。4.3 世界模型的预测与筛选世界模型拿到查询信号后会进行条件预测。具体来说模型会生成多个未来分支每个分支包含一组交通参与者的未来轨迹。然后规划相关性评分网络会对每个分支打分筛选出高相关性的分支。筛选后的分支会送给一个规划评估网络评估每个分支下各个候选动作的代价。最终规划模块综合所有高相关性分支的评估结果选出最优动作。这个流程的关键在于世界模型不需要预测所有分支只需要预测那些可能改变规划决策的分支。在实际运行中通常只有3-5个分支是高相关性的其他分支直接被剪枝。4.4 参数选择与算力分配PlanWAM的算力分配策略是动态的。在高速巡航场景下交通参与者少、交互简单世界模型可以只预测2-3个高相关性目标算力开销很小。在城区拥堵场景下交通参与者多、交互复杂高相关性目标可能增加到8-10个算力开销相应增加。我们当时的算力预算是这样的场景类型高相关性目标数预测时间窗口推理耗时毫秒高速巡航2-33秒8-12城区畅通4-63秒15-20城区拥堵8-102秒25-35路口复杂10-152秒35-50这个耗时是在某款车规级芯片上实测的包含场景编码、查询生成、世界模型预测、规划评估的全链路。可以看到最复杂的路口场景下推理耗时也在50毫秒以内满足实时性要求。实操心得算力分配不要一刀切。我们试过固定预测10个目标结果高速场景下算力浪费严重城区场景下又不够用。后来改成动态分配整体算力利用率提升了40%左右。5. 常见问题与排查技巧实录5.1 规划相关性评分震荡怎么办这是实际部署中最常见的问题之一。规划相关性评分在相邻两帧之间跳变很大导致世界模型的预测粒度频繁切换规划结果也跟着抖。排查思路先看评分网络的输入特征是否稳定。如果输入特征本身就有高频噪声那评分自然会震荡。常见原因是场景编码器的输出不稳定比如GNN的注意力权重在相邻帧之间变化太大。解决方法对评分做时间平滑。用一个简单的指数移动平均EMA来平滑评分[ S_{smooth}(t) \alpha S(t) (1-\alpha) S_{smooth}(t-1) ](\alpha) 通常取0.3-0.5。这样评分不会突变预测粒度切换也会平滑很多。我们当时用 (\alpha0.4)震荡问题基本解决。5.2 高相关性目标漏检怎么排查有时候规划模块明明很关注某个目标但相关性评分却很低导致这个目标没有被精细预测。这种情况很危险因为规划可能基于粗糙预测做出错误决策。排查思路先检查查询信号的生成是否正确。如果规划模块的查询向量没有正确指向那个目标那评分网络自然看不到它。常见原因是查询生成网络的训练数据覆盖不足比如左转场景的训练样本太少。解决方法在训练查询生成网络时加入困难样本挖掘。把那些规划决策错误、但相关性评分很低的场景找出来重点训练。另外可以加一个安全兜底机制对于距离自车5米以内、相对速度大于2米/秒的目标无论评分多少都强制进行精细预测。5.3 预测分支多样性不足怎么调PlanWAM需要生成多个未来分支但如果分支之间太相似那筛选就失去了意义。常见表现是模型生成的5个分支里有4个几乎一模一样只有1个略有不同。排查思路这通常是训练时多样性损失权重太低导致的。模型倾向于生成“平均”的未来而不是多样化的未来。解决方法在训练损失里加入多样性正则项。常用的是最小距离惩罚如果两个分支之间的轨迹距离小于某个阈值就惩罚它们。阈值通常取0.5-1米。另外可以用多模态锚点来引导分支生成比如预设“前车加速”“前车减速”“前车保持”三种锚点让模型围绕锚点生成分支。5.4 常见问题速查表问题现象可能原因排查方法解决措施规划结果抖动相关性评分震荡检查评分网络输入稳定性加入EMA平滑(\alpha0.3-0.5)危险目标漏检查询信号指向错误检查查询生成网络困难样本挖掘安全兜底机制预测分支单一多样性损失不足检查分支间轨迹距离加入最小距离惩罚多模态锚点推理耗时超标高相关性目标过多统计各场景目标数动态调整阈值限制最大目标数规划决策保守预测过于悲观检查预测分支的代价分布调整代价函数权重增加乐观分支避坑技巧不要等到实车测试才发现问题。我们在模拟环境里跑了10万公里才上车提前发现了80%以上的问题。模拟环境虽然和真实有差距但用来排查逻辑错误和参数问题足够了。6. 影响范围与工程落地建议6.1 对端到端自动驾驶架构的影响PlanWAM这种“规划导向预测”的思路对端到端自动驾驶架构的影响挺大的。传统端到端模型通常是“感知→预测→规划”一条路走到底每个模块各司其职。但PlanWAM把预测和规划耦合起来了预测模块需要知道规划在纠结什么规划模块也需要知道预测的不确定性在哪里。这意味着端到端模型的训练不能再分模块独立训练了。感知、预测、规划需要联合训练或者至少要有联合微调的阶段。这对训练数据的要求更高因为需要同时标注感知结果、预测轨迹和规划动作。6.2 对车端算力分配的影响PlanWAM的动态预测粒度策略实际上是把算力分配从“静态预算”变成了“动态调度”。这对车端芯片的调度器提出了更高要求。传统芯片调度器通常是按任务优先级分配算力但PlanWAM需要根据规划相关性评分实时调整算力分配。我们当时的做法是在芯片上预留一个动态算力池世界模型可以根据评分结果申请额外算力。高相关性目标多的时候多申请一些少的时候把算力让给其他模块。这个机制需要芯片底层的支持不是所有车规级芯片都能做。6.3 对数据闭环的影响PlanWAM的训练需要“规划敏感”的标注数据这对数据闭环提出了新要求。传统数据闭环通常是“采集→标注→训练→部署”一条线但PlanWAM需要在这个闭环里加入规划敏感性分析环节。具体来说采集回来的数据先用当前规划模块做一次敏感性分析找出哪些片段是“规划敏感”的然后只对这些片段进行精细标注。这样可以大幅降低标注成本同时保证训练数据的质量。实操心得敏感性分析不要只用一种规划算法。我们试过用三种不同风格的规划器分别做分析取并集作为敏感目标集合。这样标注出来的数据泛化性更好不会过拟合到某一种规划风格。6.4 对安全冗余策略的影响PlanWAM的预测是“有选择性”的这意味着它可能会漏掉一些低概率但高风险的未来。比如远处一辆车突然爆胎冲向自车这种场景在相关性评分里可能不高因为概率太低。但一旦发生后果很严重。所以PlanWAM不能完全替代传统的安全冗余策略。我们当时的做法是保留一个独立的安全监控模块用简单的物理模型比如恒定速度、恒定加速度预测所有目标的粗略未来一旦发现碰撞风险直接触发紧急制动不经过PlanWAM的筛选流程。这个安全监控模块的算力开销很小但能兜住PlanWAM可能漏掉的长尾风险。算是工程上比较稳妥的做法。7. 我个人在实际操作中的几点体会PlanWAM这套思路我最早是在一个模拟的城区路口场景里尝试的。当时最大的感受是预测和规划之间的“信息鸿沟”比想象中大。预测模型觉得重要的信息规划模块可能根本不关心规划模块真正纠结的东西预测模型又没重点推演。PlanWAM通过规划相关性评分把这个鸿沟填上了算是找到了一个比较优雅的工程解。不过这套方法也不是银弹。它对训练数据的要求很高需要同时有感知、预测、规划的全链路标注。而且规划相关性评分网络本身也需要精心调参阈值设高了会漏掉关键目标设低了算力又吃不消。我们当时调这个阈值调了两周才找到一个相对稳定的平衡点。另外动态预测粒度虽然省算力但也带来了一个新的问题预测结果的不一致性。同一个目标这一帧用精细粒度预测下一帧可能用粗糙粒度预测两帧之间的预测结果可能会有跳变。规划模块如果直接使用这些预测结果可能会产生抖动。我们的解决方法是在预测结果输出前加一个一致性滤波用卡尔曼滤波或者简单的低通滤波把跳变平滑掉。最后再分享一个小技巧做规划相关性评分时不要只用当前帧的规划状态可以把过去几帧的规划状态也作为输入。这样评分网络能更好地理解规划的“意图趋势”而不是只看当前瞬间的纠结。我们加了历史规划状态后评分准确率提升了大概15%。这个方向后续还可以往多车协同扩展。现在的PlanWAM主要是自车视角的规划导向预测如果多辆车都用自己的PlanWAM它们之间的预测可能会冲突。怎么让多车的世界模型协同起来互相知道对方在关注什么、预测什么应该是个挺有意思的研究方向。