轨迹预测这个名词放在自动驾驶整个系统里其实特别有意思——感知给的是“现在”决策给的是“怎么做”但中间缺了一个“即将发生什么”。如果一辆车没有预判能力到了十字路口才反应那它就永远只能在低速封闭园区里转悠。2024年我花了大半年时间在智能驾驶团队里专门做视觉感知算法中的轨迹预测模块先后实战了VectorNet和MultiPath两条技术路线踩了不少坑也积累了一些可复用的经验。这篇博文就围绕轨迹预测中的这两套典型方案展开聊聊它们各自解决的问题、核心设计、训练部署中的实操细节以及我个人在这过程中的体会。1. 轨迹预测在自动驾驶系统里的真实位置1.1 预测的不是“一条线”而是一组概率很多新人刚接触轨迹预测时容易犯一个理解偏差以为预测就是输入历史轨迹输出一条未来轨迹任务完成。但在真实的智能驾驶场景里这种做法根本不可用。原因很简单未来不是确定的。一个行人可能直行也可能突然左拐一辆车在十字路口可能直行、左转、右转甚至靠边停车。如果模型只输出一条轨迹就意味着把多模态的未来强行压缩成了单峰分布一旦预测落在那条没选中的模态上决策模块就被带偏了。所以业界的普遍共识是轨迹预测本质上是输出一组带概率的候选轨迹每条轨迹刻画一种可能的未来行为模式。比如在十字路口场景模型应该输出“直行概率0.4、左转概率0.35、右转概率0.25”这样的结果每个分支附带一条完整轨迹。VectorNet和MultiPath在这件事上走向了不同的技术路径但它们共同奠定了多模态轨迹预测的基本框架。搞清楚这个背景后面的设计思路就顺理成章了。1.2 坐标系与时间窗口第一步路必须走对在进入算法细节之前先把两个工程上的基础问题说清楚因为这两个问题不处理好后面所有工作都白费。第一个是坐标系。轨迹预测模块接收的输入来自上游的感知与跟踪模块这些模块输出的物体轨迹通常在世界坐标系或者自车坐标系下表达。我的经验是预测模块内部应该统一到一个以目标物体为中心的局部坐标系——以目标当前时刻的位置为原点以其航向角为x轴方向。这样做的原因有两个一是特征表达变得稳定无论目标在场景中的哪个位置输入到网络里的坐标分布都差不多模型不需要费劲去学位置偏移二是数据增广方便在这个局部坐标系下做平移、旋转增广物理含义非常清晰。第二个是时间窗口。业界比较常用的配置是历史轨迹取3秒按10Hz采样就是30个历史点预测未来取6秒按10Hz采样就是60个未来点。但实际部署中要考虑计算量很多方案会把预测输出降频到2Hz表达。在我自己做的模拟项目X里我采用历史2秒20个点 预测6秒12个输出点5Hz采样的配置精度和计算量之间平衡得比较好。2. VectorNet把驾驶场景翻译成图神经网络能听懂的语言2.1 为什么要抛弃栅格化在VectorNet出现之前很多轨迹预测模型走的是“栅格化”路线把高精地图渲染成一张鸟瞰图再把目标历史轨迹也画上去最后用CNN提取特征。这个方法思路直观但问题也很突出——分辨率越高计算量越大分辨率低了车道线的拓扑细节又丢了。更关键的是CNN的感受野是局部的要让一个目标感知到几百米外的另一个目标需要网络堆叠很深特征传递效率很低。我之前尝试过一个栅格化方案地图范围取100米x100米分辨率0.5米/像素输入就是200x200的图配合一个ResNet骨干单帧推理耗时大约15毫秒。听起来还行但当场景变大、目标增多时这个方案的瓶颈就暴露了每个目标都要单独渲染一张图、过一遍网络目标越多计算量线性膨胀而且大量计算浪费在生成背景图上真正的语义信息反而被卷积层一层层“磨”掉了。VectorNet的核心思路是换一种场景表达把地图元素和目标轨迹全部向量化用图结构来组织空间关系。一条车道线被拆成若干小段每段用起点坐标和终点坐标表示一段车辆历史轨迹也按时间切分成小段相邻段之间有先后关系。这样整个场景就变成了一个图节点是“向量化的片段”边是“空间或时间连接关系”后面用图神经网络做信息聚合效率和表达力都上了一个台阶。2.2 节点、边与消息传递我复现VectorNet的时候把整个编码器的搭建拆成了三步第一步构建节点特征第二步构建图结构第三步消息传递与全局聚合。这三步每一步都有不少细节需要注意。第一步节点特征。每个地图元素比如一段车道线被表示为一组向量节点节点特征除了起点和终点的坐标还应该包含节点自身的几何属性。我常用的特征向量是起点坐标2维、终点坐标2维、节点朝向1维用起点到终点的方向角、节点长度1维、以及一个one-hot类型编码车道线、路沿、人行横道、停车线等。这里面有个细节特征尽量用相对坐标即相对于目标物体当前位置的坐标这样模型对“绝对位置”不敏感泛化能力更好。第二步构建图结构。图的边有两种一种是“顺序边”连接同一条车道线上相邻的节点或者同一段轨迹里相邻时间步的节点这种边能保持线条的连贯性另一种是“交互边”连接空间上距离较近的节点不管它们来自地图还是来自其他目标。交互边是让信息在不同物体之间流动的关键也是预测“交互博弈”行为的基础。第三步消息传递。我实现的时候采用的是分层聚合策略每个节点先经过一层全连接编码然后做多轮消息传递每轮里节点把自己的特征聚合给邻居节点再更新自身特征。消息传递的层数不要贪多我在模拟项目X里试过2层、3层、4层发现3层效果最好再往上收益很小反而增加计算量。这三步完成后整个场景的信息就都被压缩到了每个节点的特征里。但对于轨迹预测来说我们更关心的是被预测目标本身。所以最后还需要做一个全局聚合把所有节点特征池化成一个全局场景特征向量做一次max-pooling或者attention加权求和。我实际测试下来attention加权求和比max-pooling在部分场景尤其是有多个交互目标时表现稍好但是代价是计算量增加在车端部署时我最终还是换回了max-pooling。2.3 训练数据组织与增广技巧数据组织这一步看似不起眼实际上决定了模型性能的天花板。先把我的实践流程写在这里大家可以对照自己的数据集做调整。第一件事是场景裁剪。每次训练样本要以目标为中心取周围一定范围内的地图元素。我用的范围是半径150米太近了会丢掉关键拓扑信息比如一个长直道后面200米才是路口那150米就看不到路口了太远了则引入大量无关节点白白增加计算量。采样的时候要注意多个目标可以共享同一个场景所以在一次前向中同时为多个目标输出预测这样训练效率更高。第二件事是数据增广。轨迹预测的增广和平常图像增广不太一样不能随便裁剪翻转。我常用三种全局旋转把整个场景旋转一个随机角度、全局平移把场景整体平移到局部坐标系的不同位置、时间反向。时间反向这个技巧比较冷门——把轨迹倒过来播放相当于制造了一组“反向运动”的训练数据对提升模型在异常运动模式下的鲁棒性有帮助。不过时间反向增广不能对所有场景使用尤其是车道方向性很强的场景反向之后物理意义就变了我只在自由移动的行人目标上用它。第三件事是轨迹插值与对齐。上游跟踪模块输出的轨迹往往是不等间隔的中间可能有跳变。我在预处理阶段会把历史轨迹重采样到固定频率比如10Hz然后用线性插值补齐缺失点。这里有个容易忽略的问题如果连续缺失超过0.5秒就不要硬插值了那段数据要么丢弃要么把缺失标志位拼进特征里让模型自己学习如何处理不完整轨迹。3. MultiPath从“回归未来”到“选择未来”3.1 锚点从哪来先列出一张“可能清单”MultiPath这套方案的思路和VectorNet完全不同它不试图直接从历史轨迹“回归”出一条未来轨迹而是先把轨迹预测问题转换成两个子问题——“最像哪个预设模式”和“在这个模式基础上偏多少”。这个转换是整个算法最精妙的地方。所谓锚点就是提前定义好的一组“可能的未来轨迹”。比如在一个十字路口锚点可以是“直行、左转、右转”三条典型路径。但实际场景远不止三种可能所以锚点的生成通常采用数据驱动的方式把训练数据里所有目标的真实未来轨迹做归一化处理后用K-means聚类聚类中心就是锚点。我在模拟项目X里用K64个聚类中心运行效果比较稳定。K值选择的关键在于它要能覆盖绝大多数运动模式K太小预测多样性不够K太大回归头要预测的偏移量太多训练难度增加。这里有个非常重要的实操细节锚点轨迹的坐标也应该在目标局部坐标系里表示并且所有锚点都要做标准化对齐——把锚点的起点平移到坐标系原点这样每个锚点的首段方向能体现一类“转向意图”而不是受某个具体目标位置影响。3.2 分类头与回归头的组合细节MultiPath的网络结构很简洁和很多检测网络类似共享一个场景编码器这里可以复用VectorNet的编码器也可以替换成其他结构然后分出两个分支头——分类头和回归头。分类头的任务是输出每个锚点被选中的概率。它输出的维度等于锚点数量经过softmax归一化后代表模型对“目标接下来最可能走哪个模式”的判断。回归头的任务是输出相对每个锚点的偏移。你可能会问既然已经有锚点了为什么还要回归偏移因为锚点只是“聚类中心”是那些典型模式的均值真实轨迹会在中心附近波动。回归头学习的就是“真实轨迹相对于锚点中心”的偏差比如“直行但稍微靠右一点”或者“左转但转得比锚点更快一点”。训练时有两个关键点要处理好。第一是损失函数的权重配比。分类用交叉熵损失回归用Smooth L1损失也可以尝试负对数似然损失后者的概率解释性更强。我在实验中给回归损失的权重是分类损失的2倍一开始我没给足模型表现得很保守几乎都走直线。第二是每个anchor都参与回归损失计算但只有真实轨迹对应的那个anchor参与分类损失。等等——这是不对的。准确来说分类损失是模型预测的每个anchor概率与真实anchor one-hot标签之间的交叉熵而实际训练中业界常做的做法是先找出和真实轨迹最接近的anchor作为正样本让模型学“强化这个anchor的概率”其他anchor作为负样本。推理阶段的输出就是一条条候选轨迹配上概率值。输出后处理也很关键如果两个候选轨迹的终点距离很近比如小于1米会做一次抑制只保留概率较大的那一个避免输出一堆几乎重复的轨迹。这一步我最初没做结果可视化时经常看到数条轨迹挤在一起下游决策模块很痛苦。3.3 多模态输出与车端消费逻辑MultiPath这类“多模态输出”方案的工程意义在于它能直接对接决策规划模块。规划器拿到的不再是一条确定轨迹而是一组带概率的选项可以据此做闭环的决策——比如“前方左侧车道车辆有20%概率向左变道那么我稍微减速并保持在右侧更安全”。我在实车测试中体会最深的一点是预测结果的概率分布本身比具体的轨迹坐标更有价值。比如在拥堵路段一辆车反复在车道线附近摇摆坐标轨迹噪声很大但概率分布却能稳定地告诉决策模块“它大概率是跟随车流直行”。所以我会建议下游模块优先消费概率信息把轨迹坐标当作附带的细化结果。不过多模态输出也带来一个麻烦车辆必须要从N条候选中选一条执行。如果概率最高的那条轨迹和其他车预测的轨迹发生碰撞该选第二条还是做速度调整这就涉及预测与规划的联合优化了已经超出了轨迹预测模块本身的范畴。但在算法设计时至少要保证输出的候选轨迹之间有足够的多样性让规划器有真正的选择空间而不是选来选去都在一个地方打转。4. 训练、指标与车端部署的务实取舍4.1 真值清洗与数据组织轨迹预测模型的训练数据很多人以为直接拿跟踪模块的输出拼一拼就可以了。实际做过一遍之后才知道这一步的水很深。跟踪模块的输出里天然包含两类脏数据一类是“身份切换”导致的轨迹断裂另一类是障碍物遮挡导致的短暂消失。我处理这两类问题的方式第一做轨迹平滑和插值对短时间小于0.3秒的丢失用线性插值补齐第二超过0.5秒的轨迹中断就直接切断把中断点前后拆成两条训练样本不强制让模型学“凭空恢复”这种不靠谱的任务第三对航向角突变足够大的点做剔除因为航向角突变往往意味着跟踪目标ID切换而不是真实运动行为。另外真值轨迹要在目标局部坐标系下存储这样不同场景的样本在特征空间里是齐分布的。训练的时候再按批次随机平移旋转增强相当于变相扩大了数据集规模。这个细节做对之后模型在小数据集上也能有不错的表现。4.2 损失函数权重与评估指标解读轨迹预测的评估指标和检测、分割都不一样常用的指标有minADE最小平均位移误差、minFDE最小终点位移误差和Miss Rate漏检率。先解释一下minADE的意思是在模型输出的N条候选轨迹中选择一条与真实轨迹误差最小的计算其所有时间点的平均位移误差minFDE是取终点误差最小的那条候选轨迹计算终点位移误差。这两个指标反映的是“模型预测的候选覆盖能力”——只要N条候选里有一条接近真实指标就好。但这里有个陷阱minADE/minFDE不惩罚模型输出多余的、不相关的候选轨迹。你可能输出64条轨迹里面只有1条踩中指标依旧漂亮但车端决策模块拿到64条乱七八糟的轨迹根本执行不了。所以我的做法是除了看minADE/minFDE还要人工检查概率校准程度——用预测概率排序后画可靠性曲线reliability diagram看模型预测概率为0.7的轨迹实际命中率是否接近0.7。如果概率校准不好下游决策模块会做很多无用功。训练损失上分类和回归的权重配比也很关键。我最终固定为分类1.0、回归2.0这个比例下模型既不会太保守分类主导导致总选最常见的模式也不会太冒进回归主导导致轨迹形变过大。4.3 车端部署的延迟预算与量化轨迹预测模块在车端部署时的核心矛盾是一个场景里往往有多个目标需要同时预测而每个目标又需要不同的场景上下文。我的方案是“共享编码器 多目标并行头”先编码整个场景一次提取全局特征然后在每个目标的位置上做特征抽取分别预测各自的轨迹。这样整帧场景只过一次编码器大大降低了计算量。实测下来在一个中等规模的模拟测试场景中单帧包含约20个目标时VectorNet编码器加MultiPath头部的总推理时间可以控制在8毫秒以内在嵌入式计算平台上。但如果每个目标单独做一次全场景编码耗时就会飙升到几十毫秒这在车端是根本不可接受的。所以一定不要走“每个目标单独过模型”的老路。模型量化方面我试过INT8量化模型体积缩小约4倍推理速度提升约2倍minADE指标退化大约3-5%在可接受范围。不过量化后要重点留意分类头的概率输出是否过于平滑——也就是所有候选轨迹概率接近均等。如果出现这个现象可以在量化后微调分类头的温度系数让概率分布重新锐化一些。5. 常见问题与排查技巧实录5.1 模态坍缩预测结果过于保守这是轨迹预测模型训练中最常见的问题之一训练到后期模型输出的候选轨迹开始趋向于“预测直线行驶”各种转向概率被压缩到接近于零。症状看起来就是可视化时默认参数下几乎看不到转弯轨迹。排查思路一般从三个方向入手第一检查锚点分布是否有足够多的转向模式如果聚类中心里直线模式占绝对多数回归头无论怎么学都很难帮模型突破这个先验第二检查分类损失权重是否过大导致模型认为预测“直行”永远是最安全的因为它最接近训练集的先验分布第三检查数据增强是否覆盖了足够的转向样本如果没有就需要增加旋转增强的强度或者对稀有转向场景做上采样。我在模拟项目X里遇到这个问题时最终通过两个手段解决一是把K从32调大到64增加锚点的多样性二是对转向场景做了2倍过采样。调完之后模型的转向召回率提升了约18个百分点。5.2 轨迹抖动逐帧预测不稳定轨迹预测是逐帧执行的上一帧预测结果和下一帧预测结果在时间上应该平滑过渡但实际跑起来经常出现相邻两帧输出轨迹差异很大的情况特别是在目标低速运动或静止时。抖动的原因很可能是下游决策模块不敢直接用预测结果因为一会说目标左转一会说目标直行谁都不敢信。我排查抖动问题时先确认了是不是输入噪声放大的结果——目标静止时跟踪输出会有微小跳动这些跳动经过模型放大后体现在轨迹形态上。一个有效的缓解手段是“时间平滑”对分类概率做指数滑动平均同时对回归偏移量做轻量级滤波。另一个角度是修改训练策略在输入轨迹上叠加一小段时间噪声作为数据增强让模型学会忽略小幅抖动只响应有意义的运动模式变化。这两个手段叠加后实测轨迹抖动降低了70%以上。5.3 车辆被遮挡时的预测连续性真实的城市道路里车辆被遮挡是家常便饭——两辆大货车中间夹着一辆小车或者在路口被对向车辆挡住半边车身。感知模块一旦短暂丢失目标跟踪轨迹就会中断预测模块拿到的历史轨迹里就有一段空洞。这类问题我的处理方式是在特征层面为每个历史时间步拼接一个“是否有效”的标志位让模型自己学习在部分缺失的情况下该如何处理。这个技巧虽然简单但效果出奇地好——模型会自动学会用最近的有效轨迹点推断当前的合理运动状态。注意不要试图用插值把空洞填得完美因为填充轨迹本身会引入额外噪声。模型真正需要的是“感知到这里有缺失”而不是看到一段不真实的完美轨迹。5.4 交叉路口的多条候选轨迹互相打架使用MultiPath时还有一个典型问题交叉路口场景下输出的64条候选轨迹可能很多都挤在“左转”这个模式附近而真正重要的“直行”候选反而概率不高。这会导致下游决策模块认为“目标大概率左转”但目标其实直行最终决策失误。检查后发现问题出在锚点聚类阶段——K-means聚类对轨迹形状的区分不如对轨迹终点的区分敏感导致大量转弯模式被合并成一个簇。解决方式是改用“终点位置 轨迹形状”的组合特征做聚类同时增加转向场景在聚类数据中的比例。做完这两个调整后多样性问题有明显改善。6. 最后分享一点落地体会把VectorNet和MultiPath从论文搬到代码、再从代码搬到车端实跑的整个过程我个人的核心体会是算法不是越新越好工程落地的关键在细节深浅。VectorNet的价值在于它提供了一套高效的场景编码方式而MultiPath的价值在于它把预测问题构造得对下游极其友好——天然的多模态输出配合概率信息让决策模块可以量化评估风险。如果你现在要选型做决策我给你一个实用的判断标准如果你的计算资源有限、场景相对简单比如高速巡航、封闭园区MultiPath配合一个简单的场景编码器就够用如果场景复杂、交互频繁、需要精细的空间拓扑理解比如城市道路十字路口那么把VectorNet当作编码器、再接MultiPath头是经过验证的稳妥组合。最后再分享一个小技巧不管用哪种方案训练时一定要使用“未来轨迹逆推”的验证思维——也就是用一段真实历史的末尾做输入预测其后续再和真实未来轨迹对比。这个验证方式比只看训练集指标更能暴露模型在实际场景中的偏移偏差能帮你提前发现很多部署后才暴露的问题。做轨迹预测真正的功夫一半在模型设计另一半在数据与指标的理解深度上。
轨迹预测这个名词放在自动驾驶整个系统里其实特别有意思——感知给的是“现在”决策给的是“怎么做”但中间缺了一个“即将发生什么”。如果一辆车没有预判能力到了十字路口才反应那它就永远只能在低速封闭园区里转悠。2024年我花了大半年时间在智能驾驶团队里专门做视觉感知算法中的轨迹预测模块先后实战了VectorNet和MultiPath两条技术路线踩了不少坑也积累了一些可复用的经验。这篇博文就围绕轨迹预测中的这两套典型方案展开聊聊它们各自解决的问题、核心设计、训练部署中的实操细节以及我个人在这过程中的体会。1. 轨迹预测在自动驾驶系统里的真实位置1.1 预测的不是“一条线”而是一组概率很多新人刚接触轨迹预测时容易犯一个理解偏差以为预测就是输入历史轨迹输出一条未来轨迹任务完成。但在真实的智能驾驶场景里这种做法根本不可用。原因很简单未来不是确定的。一个行人可能直行也可能突然左拐一辆车在十字路口可能直行、左转、右转甚至靠边停车。如果模型只输出一条轨迹就意味着把多模态的未来强行压缩成了单峰分布一旦预测落在那条没选中的模态上决策模块就被带偏了。所以业界的普遍共识是轨迹预测本质上是输出一组带概率的候选轨迹每条轨迹刻画一种可能的未来行为模式。比如在十字路口场景模型应该输出“直行概率0.4、左转概率0.35、右转概率0.25”这样的结果每个分支附带一条完整轨迹。VectorNet和MultiPath在这件事上走向了不同的技术路径但它们共同奠定了多模态轨迹预测的基本框架。搞清楚这个背景后面的设计思路就顺理成章了。1.2 坐标系与时间窗口第一步路必须走对在进入算法细节之前先把两个工程上的基础问题说清楚因为这两个问题不处理好后面所有工作都白费。第一个是坐标系。轨迹预测模块接收的输入来自上游的感知与跟踪模块这些模块输出的物体轨迹通常在世界坐标系或者自车坐标系下表达。我的经验是预测模块内部应该统一到一个以目标物体为中心的局部坐标系——以目标当前时刻的位置为原点以其航向角为x轴方向。这样做的原因有两个一是特征表达变得稳定无论目标在场景中的哪个位置输入到网络里的坐标分布都差不多模型不需要费劲去学位置偏移二是数据增广方便在这个局部坐标系下做平移、旋转增广物理含义非常清晰。第二个是时间窗口。业界比较常用的配置是历史轨迹取3秒按10Hz采样就是30个历史点预测未来取6秒按10Hz采样就是60个未来点。但实际部署中要考虑计算量很多方案会把预测输出降频到2Hz表达。在我自己做的模拟项目X里我采用历史2秒20个点 预测6秒12个输出点5Hz采样的配置精度和计算量之间平衡得比较好。2. VectorNet把驾驶场景翻译成图神经网络能听懂的语言2.1 为什么要抛弃栅格化在VectorNet出现之前很多轨迹预测模型走的是“栅格化”路线把高精地图渲染成一张鸟瞰图再把目标历史轨迹也画上去最后用CNN提取特征。这个方法思路直观但问题也很突出——分辨率越高计算量越大分辨率低了车道线的拓扑细节又丢了。更关键的是CNN的感受野是局部的要让一个目标感知到几百米外的另一个目标需要网络堆叠很深特征传递效率很低。我之前尝试过一个栅格化方案地图范围取100米x100米分辨率0.5米/像素输入就是200x200的图配合一个ResNet骨干单帧推理耗时大约15毫秒。听起来还行但当场景变大、目标增多时这个方案的瓶颈就暴露了每个目标都要单独渲染一张图、过一遍网络目标越多计算量线性膨胀而且大量计算浪费在生成背景图上真正的语义信息反而被卷积层一层层“磨”掉了。VectorNet的核心思路是换一种场景表达把地图元素和目标轨迹全部向量化用图结构来组织空间关系。一条车道线被拆成若干小段每段用起点坐标和终点坐标表示一段车辆历史轨迹也按时间切分成小段相邻段之间有先后关系。这样整个场景就变成了一个图节点是“向量化的片段”边是“空间或时间连接关系”后面用图神经网络做信息聚合效率和表达力都上了一个台阶。2.2 节点、边与消息传递我复现VectorNet的时候把整个编码器的搭建拆成了三步第一步构建节点特征第二步构建图结构第三步消息传递与全局聚合。这三步每一步都有不少细节需要注意。第一步节点特征。每个地图元素比如一段车道线被表示为一组向量节点节点特征除了起点和终点的坐标还应该包含节点自身的几何属性。我常用的特征向量是起点坐标2维、终点坐标2维、节点朝向1维用起点到终点的方向角、节点长度1维、以及一个one-hot类型编码车道线、路沿、人行横道、停车线等。这里面有个细节特征尽量用相对坐标即相对于目标物体当前位置的坐标这样模型对“绝对位置”不敏感泛化能力更好。第二步构建图结构。图的边有两种一种是“顺序边”连接同一条车道线上相邻的节点或者同一段轨迹里相邻时间步的节点这种边能保持线条的连贯性另一种是“交互边”连接空间上距离较近的节点不管它们来自地图还是来自其他目标。交互边是让信息在不同物体之间流动的关键也是预测“交互博弈”行为的基础。第三步消息传递。我实现的时候采用的是分层聚合策略每个节点先经过一层全连接编码然后做多轮消息传递每轮里节点把自己的特征聚合给邻居节点再更新自身特征。消息传递的层数不要贪多我在模拟项目X里试过2层、3层、4层发现3层效果最好再往上收益很小反而增加计算量。这三步完成后整个场景的信息就都被压缩到了每个节点的特征里。但对于轨迹预测来说我们更关心的是被预测目标本身。所以最后还需要做一个全局聚合把所有节点特征池化成一个全局场景特征向量做一次max-pooling或者attention加权求和。我实际测试下来attention加权求和比max-pooling在部分场景尤其是有多个交互目标时表现稍好但是代价是计算量增加在车端部署时我最终还是换回了max-pooling。2.3 训练数据组织与增广技巧数据组织这一步看似不起眼实际上决定了模型性能的天花板。先把我的实践流程写在这里大家可以对照自己的数据集做调整。第一件事是场景裁剪。每次训练样本要以目标为中心取周围一定范围内的地图元素。我用的范围是半径150米太近了会丢掉关键拓扑信息比如一个长直道后面200米才是路口那150米就看不到路口了太远了则引入大量无关节点白白增加计算量。采样的时候要注意多个目标可以共享同一个场景所以在一次前向中同时为多个目标输出预测这样训练效率更高。第二件事是数据增广。轨迹预测的增广和平常图像增广不太一样不能随便裁剪翻转。我常用三种全局旋转把整个场景旋转一个随机角度、全局平移把场景整体平移到局部坐标系的不同位置、时间反向。时间反向这个技巧比较冷门——把轨迹倒过来播放相当于制造了一组“反向运动”的训练数据对提升模型在异常运动模式下的鲁棒性有帮助。不过时间反向增广不能对所有场景使用尤其是车道方向性很强的场景反向之后物理意义就变了我只在自由移动的行人目标上用它。第三件事是轨迹插值与对齐。上游跟踪模块输出的轨迹往往是不等间隔的中间可能有跳变。我在预处理阶段会把历史轨迹重采样到固定频率比如10Hz然后用线性插值补齐缺失点。这里有个容易忽略的问题如果连续缺失超过0.5秒就不要硬插值了那段数据要么丢弃要么把缺失标志位拼进特征里让模型自己学习如何处理不完整轨迹。3. MultiPath从“回归未来”到“选择未来”3.1 锚点从哪来先列出一张“可能清单”MultiPath这套方案的思路和VectorNet完全不同它不试图直接从历史轨迹“回归”出一条未来轨迹而是先把轨迹预测问题转换成两个子问题——“最像哪个预设模式”和“在这个模式基础上偏多少”。这个转换是整个算法最精妙的地方。所谓锚点就是提前定义好的一组“可能的未来轨迹”。比如在一个十字路口锚点可以是“直行、左转、右转”三条典型路径。但实际场景远不止三种可能所以锚点的生成通常采用数据驱动的方式把训练数据里所有目标的真实未来轨迹做归一化处理后用K-means聚类聚类中心就是锚点。我在模拟项目X里用K64个聚类中心运行效果比较稳定。K值选择的关键在于它要能覆盖绝大多数运动模式K太小预测多样性不够K太大回归头要预测的偏移量太多训练难度增加。这里有个非常重要的实操细节锚点轨迹的坐标也应该在目标局部坐标系里表示并且所有锚点都要做标准化对齐——把锚点的起点平移到坐标系原点这样每个锚点的首段方向能体现一类“转向意图”而不是受某个具体目标位置影响。3.2 分类头与回归头的组合细节MultiPath的网络结构很简洁和很多检测网络类似共享一个场景编码器这里可以复用VectorNet的编码器也可以替换成其他结构然后分出两个分支头——分类头和回归头。分类头的任务是输出每个锚点被选中的概率。它输出的维度等于锚点数量经过softmax归一化后代表模型对“目标接下来最可能走哪个模式”的判断。回归头的任务是输出相对每个锚点的偏移。你可能会问既然已经有锚点了为什么还要回归偏移因为锚点只是“聚类中心”是那些典型模式的均值真实轨迹会在中心附近波动。回归头学习的就是“真实轨迹相对于锚点中心”的偏差比如“直行但稍微靠右一点”或者“左转但转得比锚点更快一点”。训练时有两个关键点要处理好。第一是损失函数的权重配比。分类用交叉熵损失回归用Smooth L1损失也可以尝试负对数似然损失后者的概率解释性更强。我在实验中给回归损失的权重是分类损失的2倍一开始我没给足模型表现得很保守几乎都走直线。第二是每个anchor都参与回归损失计算但只有真实轨迹对应的那个anchor参与分类损失。等等——这是不对的。准确来说分类损失是模型预测的每个anchor概率与真实anchor one-hot标签之间的交叉熵而实际训练中业界常做的做法是先找出和真实轨迹最接近的anchor作为正样本让模型学“强化这个anchor的概率”其他anchor作为负样本。推理阶段的输出就是一条条候选轨迹配上概率值。输出后处理也很关键如果两个候选轨迹的终点距离很近比如小于1米会做一次抑制只保留概率较大的那一个避免输出一堆几乎重复的轨迹。这一步我最初没做结果可视化时经常看到数条轨迹挤在一起下游决策模块很痛苦。3.3 多模态输出与车端消费逻辑MultiPath这类“多模态输出”方案的工程意义在于它能直接对接决策规划模块。规划器拿到的不再是一条确定轨迹而是一组带概率的选项可以据此做闭环的决策——比如“前方左侧车道车辆有20%概率向左变道那么我稍微减速并保持在右侧更安全”。我在实车测试中体会最深的一点是预测结果的概率分布本身比具体的轨迹坐标更有价值。比如在拥堵路段一辆车反复在车道线附近摇摆坐标轨迹噪声很大但概率分布却能稳定地告诉决策模块“它大概率是跟随车流直行”。所以我会建议下游模块优先消费概率信息把轨迹坐标当作附带的细化结果。不过多模态输出也带来一个麻烦车辆必须要从N条候选中选一条执行。如果概率最高的那条轨迹和其他车预测的轨迹发生碰撞该选第二条还是做速度调整这就涉及预测与规划的联合优化了已经超出了轨迹预测模块本身的范畴。但在算法设计时至少要保证输出的候选轨迹之间有足够的多样性让规划器有真正的选择空间而不是选来选去都在一个地方打转。4. 训练、指标与车端部署的务实取舍4.1 真值清洗与数据组织轨迹预测模型的训练数据很多人以为直接拿跟踪模块的输出拼一拼就可以了。实际做过一遍之后才知道这一步的水很深。跟踪模块的输出里天然包含两类脏数据一类是“身份切换”导致的轨迹断裂另一类是障碍物遮挡导致的短暂消失。我处理这两类问题的方式第一做轨迹平滑和插值对短时间小于0.3秒的丢失用线性插值补齐第二超过0.5秒的轨迹中断就直接切断把中断点前后拆成两条训练样本不强制让模型学“凭空恢复”这种不靠谱的任务第三对航向角突变足够大的点做剔除因为航向角突变往往意味着跟踪目标ID切换而不是真实运动行为。另外真值轨迹要在目标局部坐标系下存储这样不同场景的样本在特征空间里是齐分布的。训练的时候再按批次随机平移旋转增强相当于变相扩大了数据集规模。这个细节做对之后模型在小数据集上也能有不错的表现。4.2 损失函数权重与评估指标解读轨迹预测的评估指标和检测、分割都不一样常用的指标有minADE最小平均位移误差、minFDE最小终点位移误差和Miss Rate漏检率。先解释一下minADE的意思是在模型输出的N条候选轨迹中选择一条与真实轨迹误差最小的计算其所有时间点的平均位移误差minFDE是取终点误差最小的那条候选轨迹计算终点位移误差。这两个指标反映的是“模型预测的候选覆盖能力”——只要N条候选里有一条接近真实指标就好。但这里有个陷阱minADE/minFDE不惩罚模型输出多余的、不相关的候选轨迹。你可能输出64条轨迹里面只有1条踩中指标依旧漂亮但车端决策模块拿到64条乱七八糟的轨迹根本执行不了。所以我的做法是除了看minADE/minFDE还要人工检查概率校准程度——用预测概率排序后画可靠性曲线reliability diagram看模型预测概率为0.7的轨迹实际命中率是否接近0.7。如果概率校准不好下游决策模块会做很多无用功。训练损失上分类和回归的权重配比也很关键。我最终固定为分类1.0、回归2.0这个比例下模型既不会太保守分类主导导致总选最常见的模式也不会太冒进回归主导导致轨迹形变过大。4.3 车端部署的延迟预算与量化轨迹预测模块在车端部署时的核心矛盾是一个场景里往往有多个目标需要同时预测而每个目标又需要不同的场景上下文。我的方案是“共享编码器 多目标并行头”先编码整个场景一次提取全局特征然后在每个目标的位置上做特征抽取分别预测各自的轨迹。这样整帧场景只过一次编码器大大降低了计算量。实测下来在一个中等规模的模拟测试场景中单帧包含约20个目标时VectorNet编码器加MultiPath头部的总推理时间可以控制在8毫秒以内在嵌入式计算平台上。但如果每个目标单独做一次全场景编码耗时就会飙升到几十毫秒这在车端是根本不可接受的。所以一定不要走“每个目标单独过模型”的老路。模型量化方面我试过INT8量化模型体积缩小约4倍推理速度提升约2倍minADE指标退化大约3-5%在可接受范围。不过量化后要重点留意分类头的概率输出是否过于平滑——也就是所有候选轨迹概率接近均等。如果出现这个现象可以在量化后微调分类头的温度系数让概率分布重新锐化一些。5. 常见问题与排查技巧实录5.1 模态坍缩预测结果过于保守这是轨迹预测模型训练中最常见的问题之一训练到后期模型输出的候选轨迹开始趋向于“预测直线行驶”各种转向概率被压缩到接近于零。症状看起来就是可视化时默认参数下几乎看不到转弯轨迹。排查思路一般从三个方向入手第一检查锚点分布是否有足够多的转向模式如果聚类中心里直线模式占绝对多数回归头无论怎么学都很难帮模型突破这个先验第二检查分类损失权重是否过大导致模型认为预测“直行”永远是最安全的因为它最接近训练集的先验分布第三检查数据增强是否覆盖了足够的转向样本如果没有就需要增加旋转增强的强度或者对稀有转向场景做上采样。我在模拟项目X里遇到这个问题时最终通过两个手段解决一是把K从32调大到64增加锚点的多样性二是对转向场景做了2倍过采样。调完之后模型的转向召回率提升了约18个百分点。5.2 轨迹抖动逐帧预测不稳定轨迹预测是逐帧执行的上一帧预测结果和下一帧预测结果在时间上应该平滑过渡但实际跑起来经常出现相邻两帧输出轨迹差异很大的情况特别是在目标低速运动或静止时。抖动的原因很可能是下游决策模块不敢直接用预测结果因为一会说目标左转一会说目标直行谁都不敢信。我排查抖动问题时先确认了是不是输入噪声放大的结果——目标静止时跟踪输出会有微小跳动这些跳动经过模型放大后体现在轨迹形态上。一个有效的缓解手段是“时间平滑”对分类概率做指数滑动平均同时对回归偏移量做轻量级滤波。另一个角度是修改训练策略在输入轨迹上叠加一小段时间噪声作为数据增强让模型学会忽略小幅抖动只响应有意义的运动模式变化。这两个手段叠加后实测轨迹抖动降低了70%以上。5.3 车辆被遮挡时的预测连续性真实的城市道路里车辆被遮挡是家常便饭——两辆大货车中间夹着一辆小车或者在路口被对向车辆挡住半边车身。感知模块一旦短暂丢失目标跟踪轨迹就会中断预测模块拿到的历史轨迹里就有一段空洞。这类问题我的处理方式是在特征层面为每个历史时间步拼接一个“是否有效”的标志位让模型自己学习在部分缺失的情况下该如何处理。这个技巧虽然简单但效果出奇地好——模型会自动学会用最近的有效轨迹点推断当前的合理运动状态。注意不要试图用插值把空洞填得完美因为填充轨迹本身会引入额外噪声。模型真正需要的是“感知到这里有缺失”而不是看到一段不真实的完美轨迹。5.4 交叉路口的多条候选轨迹互相打架使用MultiPath时还有一个典型问题交叉路口场景下输出的64条候选轨迹可能很多都挤在“左转”这个模式附近而真正重要的“直行”候选反而概率不高。这会导致下游决策模块认为“目标大概率左转”但目标其实直行最终决策失误。检查后发现问题出在锚点聚类阶段——K-means聚类对轨迹形状的区分不如对轨迹终点的区分敏感导致大量转弯模式被合并成一个簇。解决方式是改用“终点位置 轨迹形状”的组合特征做聚类同时增加转向场景在聚类数据中的比例。做完这两个调整后多样性问题有明显改善。6. 最后分享一点落地体会把VectorNet和MultiPath从论文搬到代码、再从代码搬到车端实跑的整个过程我个人的核心体会是算法不是越新越好工程落地的关键在细节深浅。VectorNet的价值在于它提供了一套高效的场景编码方式而MultiPath的价值在于它把预测问题构造得对下游极其友好——天然的多模态输出配合概率信息让决策模块可以量化评估风险。如果你现在要选型做决策我给你一个实用的判断标准如果你的计算资源有限、场景相对简单比如高速巡航、封闭园区MultiPath配合一个简单的场景编码器就够用如果场景复杂、交互频繁、需要精细的空间拓扑理解比如城市道路十字路口那么把VectorNet当作编码器、再接MultiPath头是经过验证的稳妥组合。最后再分享一个小技巧不管用哪种方案训练时一定要使用“未来轨迹逆推”的验证思维——也就是用一段真实历史的末尾做输入预测其后续再和真实未来轨迹对比。这个验证方式比只看训练集指标更能暴露模型在实际场景中的偏移偏差能帮你提前发现很多部署后才暴露的问题。做轨迹预测真正的功夫一半在模型设计另一半在数据与指标的理解深度上。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
