告别minADE刷榜：场景驱动的自动驾驶轨迹预测评估实战

自动驾驶轨迹预测模型的评估长期以来被几个数字统治着minADE、minFDE、Miss Rate。刷榜刷到麻木之后你会发现一个尴尬的事实——榜单上排名靠前的模型在真实路测中未必比排名靠后的那个更让人放心。问题出在哪出在评估方式本身。用全场景平均的位移误差去衡量一个在加塞、鬼探头、无保护左转这些极端场景下表现迥异的模型就像用平均气温去描述一个既有极寒又有酷暑的星球信息量几乎为零。这篇内容就是围绕场景驱动的轨迹预测评估展开的我会把为什么传统指标不够用、场景驱动评估到底怎么做、落地时会踩哪些坑以及一套可复现的评估流程完整地拆开讲一遍。适合做自动驾驶感知预测方向的算法工程师、评测工程师以及任何对模型评估方法论感兴趣的人。1. 为什么minADE这类指标会骗人1.1 平均指标的统计陷阱先说一个我亲身经历的事。之前团队里有两个轨迹预测模型A模型在内部测试集上minADE是0.78米B模型是0.85米。按常规逻辑A应该更好。但把两个模型都放到同一个仿真环境里跑闭环测试B的碰撞率反而比A低了将近三成。当时整个团队都懵了后来把测试集按场景类型拆开一看真相就出来了A模型在直行跟车这类简单场景上误差极低把整体平均值拉了下来但在无保护左转和密集加塞场景上误差爆炸B模型在简单场景上略差一点但在复杂场景上稳定得多。这就是平均指标最大的问题——它对所有样本一视同仁。但现实世界里一个直行跟车样本和一个鬼探头样本对安全的意义完全不对等。前者预测错了顶多让乘坐体验差一点后者预测错了可能就是一次事故。minADE把这两者的误差直接相加再平均等于默认它们同等重要这在工程上是不成立的。更隐蔽的一个问题是样本分布。公开数据集里直行、跟车这类常规场景占比往往超过七成复杂交互场景可能只占百分之几。这意味着即使一个模型在复杂场景上表现很差只要它在常规场景上足够好平均指标依然会很漂亮。模型会学会把精力放在那些数量多、容易拟合的样本上因为那才是拉低平均误差的关键。这不是模型的问题是评估指标引导出来的必然结果。1.2 多模态预测与单点误差的错配轨迹预测本质上是一个多模态问题。同一个场景前车可能继续直行可能变道也可能减速。一个合格的预测器应该输出多条可能的轨迹而不是一条最可能的轨迹。minADE的初衷是好的它取的是预测轨迹集合中与真值最接近的那条试图衡量模型有没有把正确答案包含在候选里。但这里有个微妙的问题minADE只关心最近的那条有多近不关心其他候选有多离谱。一个模型完全可以输出一条几乎完美的轨迹加上一堆乱七八糟的轨迹minADE依然很好看。可实际下游规划模块拿到这些轨迹时是要综合考虑所有候选的。如果模型输出的分布极度不合理——比如把百分之九十的概率质量压在一条错误轨迹上——规划模块很可能被带偏。我见过一个模型minADE只有0.6米但它的概率分布几乎是均匀的每条候选轨迹概率都差不多。这种模型在指标上很好看但下游规划根本没法用因为它等于没给出任何有效的信息。评估一个预测器光看几何误差是不够的还得看它的概率校准做得好不好也就是模型说这条轨迹概率是0.8的时候它到底是不是真的有八成会走这条。1.3 开环评估与闭环后果的断裂minADE是典型的开环指标。它拿预测轨迹和真值轨迹做比对整个过程和下游规划、控制完全解耦。但轨迹预测的价值最终是要体现在闭环驾驶行为上的。一个预测误差稍大但方向正确的模型可能比一个误差稍小但方向错误的模型对下游规划更友好。举个具体的例子。前车在路口有轻微的左偏趋势真值轨迹是继续直行但略微偏左。模型A预测了一条直行轨迹模型B预测了一条左转轨迹。从位移误差看模型A更接近真值minADE更低。但如果下游规划模块因为模型B的左转预测而采取了更保守的策略反而避免了一次潜在风险那模型B在闭环里的价值就更高。开环指标完全捕捉不到这种差异。这也是为什么现在越来越多的工作开始强调闭环评估。开环指标可以作为快速筛选的工具但真正决定一个模型能不能上车的是它在闭环仿真或者实车测试里的表现。场景驱动的评估本质上就是要在开环指标和闭环后果之间搭一座桥。2. 场景驱动评估的核心思路拆解2.1 从平均所有到分类加权场景驱动评估的第一个转变就是放弃所有样本一视同仁的假设转而承认不同场景的重要性不同。具体做法是先把测试集按场景类型切分成若干子集每个子集单独计算指标然后再按预设的权重聚合。权重的设定是这里面最需要工程判断的地方。一种思路是按安全风险定权重比如鬼探头、无保护左转这类高风险场景给高权重直行跟车给低权重。另一种思路是按场景稀有度定权重越稀有的场景权重越高因为稀有场景往往是模型泛化能力的试金石。还有一种更激进的做法是只关注最差的那批场景比如取所有场景子集中表现最差的百分之十专门优化这部分。我在实际项目里更倾向于混合策略先按风险等级把场景分成高、中、低三档高风险场景权重设为中低风险的三到五倍然后在每一档内部再按稀有度做微调。这个权重不是拍脑袋定的而是要结合具体的ODD运行设计域和下游规划模块的敏感度来定。比如主要跑高速的自动驾驶系统匝道汇入和cut-in的权重就应该远高于城市道路场景。2.2 场景标签体系的搭建场景驱动评估能不能落地很大程度上取决于场景标签体系建得好不好。标签太粗比如只分简单和复杂那和平均指标区别不大标签太细比如每个具体路口都算一类那每类样本太少统计意义不足。一个比较实用的做法是采用多维度标签。第一个维度是道路结构比如直道、弯道、路口、匝道、环岛。第二个维度是交互对象比如前车、旁车、行人、非机动车。第三个维度是行为类型比如跟车、变道、加塞、横穿、掉头。第四个维度是风险等级比如常规、注意、危险。一个场景可以同时打上多个标签比如路口行人横穿危险。标签体系的搭建最好和下游规划模块对齐。规划模块关心什么评估就重点看什么。如果规划模块对cut-in特别敏感那cut-in相关的标签就要做得细一点比如区分低速cut-in和高速cut-in区分相邻车道cut-in和隔车道cut-in。我见过一些团队评估标签和规划的关注点完全脱节评估报告写得漂漂亮亮规划工程师看了却没有任何 actionable 的信息这就白做了。2.3 场景挖掘与自动标注手工标注场景标签成本极高一个中等规模的数据集动辄几十万条片段靠人一条条看根本不现实。所以场景挖掘和自动标注是绕不开的一环。自动标注的核心思路是基于规则和聚类。规则部分比较好理解比如通过车道线曲率判断直道还是弯道通过目标车的横向位移和持续时间判断是否变道通过目标车与自车的相对位置和速度变化判断是否cut-in。这些规则不需要很精确能达到百分之八九十的准确率就够用了剩下的靠人工抽检修正。聚类部分主要用于发现那些规则覆盖不到的边缘场景。做法是把每个片段用一组特征向量表示比如目标数量、速度分布、加速度分布、车道关系、交互强度等然后跑聚类算法把特征空间里远离主群的簇挑出来人工审查。这些簇往往就对应着一些规则没覆盖到的稀有场景。我自己的经验是规则能覆盖大概七成的场景剩下三成里有一半能靠聚类挖出来最后剩下一成半确实需要人工介入但相比全人工已经省了太多力气。3. 一套可落地的场景驱动评估流程3.1 数据准备与场景切片评估流程的第一步是把原始数据切成一个个独立的场景片段。切片的粒度很关键太短了上下文信息不足太长了场景不纯。我的经验是以目标车的意图变化为锚点来切比如从一次变道开始到变道结束算一个片段从进入路口到离开路口算一个片段。每个片段保留前后各两秒的上下文这样既保证了场景的完整性又不至于混入太多无关信息。切片完成后要对每个片段做质量过滤。过滤掉那些传感器数据缺失严重、目标跟踪不稳定、地图匹配失败的片段。这些脏数据如果混进评估集会严重干扰指标的可信度。我一般会设几个硬性阈值比如目标跟踪连续丢失超过五帧的片段直接丢弃地图匹配误差超过一米的片段直接丢弃。过滤比例通常在百分之十到百分之二十之间如果超过百分之三十那说明数据采集或者预处理环节有问题得回头查。3.2 场景分类与权重分配切片和过滤完成后用前面说的多维度标签体系给每个片段打标签。打标签的过程可以并行化用规则引擎跑一遍再用聚类补充最后人工抽检。抽检比例不用太高百分之五到百分之十就够重点是看规则和聚类有没有明显的误判。标签打完就可以分配权重了。我通常会用一张权重表来管理横轴是风险等级纵轴是场景稀有度交叉点就是权重值。比如高风险加高稀有度权重设为十高风险加低稀有度设为五中风险加高稀有度设为三以此类推。这张表不是一成不变的每次评估结果出来之后如果发现某个场景子集的指标和实际闭环表现严重不符就要回头调整权重。风险等级高稀有度中稀有度低稀有度高风险1075中风险532低风险21.51提示权重表只是起点不要把它当成真理。每次评估后都要用闭环结果反向校验权重是否合理不合理就调。3.3 指标计算与聚合每个场景子集内部除了minADE、minFDE这些常规指标我强烈建议加上几个场景敏感的指标。第一个是概率校准误差衡量模型输出的概率和实际命中率之间的差距。第二个是模式覆盖率衡量真值轨迹落在模型预测分布高概率区域内的比例。第三个是极端误差率比如统计误差超过三米的样本占比这个指标比平均误差更能反映模型的尾部风险。聚合的时候不要简单地把各子集指标加权平均。更好的做法是分层聚合先算每个风险等级内部的加权平均再算风险等级之间的加权平均。这样做的目的是避免低风险场景因为样本多而淹没高风险场景的信号。我见过太多评估报告高风险场景指标明明很差但因为低风险场景样本占了八成加权平均之后看起来还行问题就被掩盖了。3.4 结果解读与归因分析指标算出来只是第一步更重要的是解读。一个场景子集指标差可能有很多原因模型本身能力不足、训练数据里这类场景太少、场景标签打错了、真值轨迹本身有噪声。不做归因分析光看数字很容易得出错误结论。归因分析我一般分三步走。第一步看数据。把指标差的场景片段调出来人工看几十条判断是模型问题还是数据问题。第二步看分布。统计这些片段在训练集里的占比如果训练集里几乎没有那就是数据覆盖问题不是模型问题。第三步看对比。把不同模型在同一个场景子集上的表现拉出来对比如果所有模型都差那大概率是场景本身太难或者真值有问题如果只有某个模型差那才是模型的问题。4. 实操中那些没人告诉你的坑4.1 场景标签的边界模糊问题场景标签听起来很清晰实际打起来边界极其模糊。一个前车缓慢向左偏移的场景到底算直行还是算变道偏移多少算变道持续多久算变道这些问题没有标准答案不同标注员给出的结果可能完全不同。我的处理方式是给每个标签定义明确的量化边界并且把边界写进标注规范里。比如变道定义为目标车横向位移超过一个车道宽度的百分之六十且持续时间超过两秒且横向速度方向保持一致。满足这三条才算变道否则算直行偏移。这种量化定义不可能完美但至少保证了标注的一致性。一致性比绝对正确更重要因为评估看的是相对比较只要所有模型用的是同一套标签比较就是公平的。还有一个技巧是引入不确定标签。对于那些确实处于边界地带的片段不要强行归类直接打上不确定标签在评估时单独处理或者排除。这样比强行归类造成的噪声要小得多。4.2 真值轨迹本身的噪声这个问题特别隐蔽但影响巨大。我们默认真值轨迹是绝对正确的但实际上真值轨迹是从传感器数据里估计出来的本身就有误差。在遮挡、远距离、恶劣天气等条件下真值轨迹的误差可能达到几十厘米甚至更大。如果真值本身有半米的误差那模型预测误差在零点几米这个量级的比较就失去了意义。你没法区分这零点几米的差距是模型真的更好还是只是运气好碰上了真值噪声的方向。处理这个问题有两个思路。一个是给真值轨迹也加上置信度评估时按置信度加权低置信度的样本降低权重。另一个是在评估前做真值平滑用样条或者卡尔曼滤波把真值轨迹里的高频噪声滤掉。我一般两个都用先平滑再按置信度加权。平滑的强度要控制好过度平滑会把真实的急转弯、急刹车也抹掉那就得不偿失了。4.3 场景权重的主观性争议权重分配这件事天然带有主观性。你说鬼探头权重应该是直行的五倍凭什么这个质疑在评审会上几乎每次都会遇到。我的应对策略是准备两套权重一套是安全优先权重高风险场景权重拉满一套是体验优先权重更均衡地分配。然后两套权重都跑一遍评估看结果差异。如果两个模型在两套权重下的排名一致那说明结论是稳健的不用纠结权重。如果排名不一致那就要具体分析是哪个场景子集导致了差异这个差异本身就是一个有价值的发现说明这两个模型各有侧重选哪个取决于产品定位。把权重的主观性摆到台面上比假装它是客观的要好得多。评估的目的不是给出一个绝对正确的排名而是帮助团队理解模型的行为特征做出更明智的取舍。4.4 评估集泄漏与过拟合场景驱动评估有一个容易被忽视的风险评估集泄漏。因为场景标签是人工或者半自动打的打标签的过程中不可避免地会引入对模型表现的先验判断。比如标注员知道某个模型在cut-in场景上表现好打标签时可能不自觉地倾向于把cut-in标签打给那些模型表现好的片段。这种偏差很微妙但会系统性地高估模型。防范措施是评估集和训练集严格隔离评估集的标签由独立于模型开发的人员来打而且打标签的人不知道模型的表现。另外评估集要定期更新不能一个评估集用两年。模型会随着迭代逐渐过拟合到评估集上哪怕没有直接训练只是反复用评估集调参也会产生过拟合。我的做法是每季度换掉评估集里百分之二十的样本用新采集的数据补充保持评估集的新鲜度。5. 从开环指标到闭环验证的衔接5.1 开环评估的定位说了这么多场景驱动评估的好处但必须明确一点开环评估永远只是筛选工具不是最终裁判。它的价值在于快速、低成本地发现模型的问题缩小候选范围而不是直接决定哪个模型上车。我通常把开环评估当作第一道筛子。先用场景驱动评估把明显有问题的模型筛掉比如某个模型在鬼探头场景上误差是其他模型的三倍那基本不用往下走了。剩下的模型进入第二道筛子闭环仿真。闭环仿真成本高但能捕捉到开环评估捕捉不到的交互效应和累积误差。5.2 闭环仿真中的场景复现闭环仿真最大的挑战是场景复现。开环评估里场景是固定的模型预测完就结束了。闭环仿真里自车的动作会影响其他交通参与者场景会动态演化。这就要求仿真环境里的其他车辆和行人也要有合理的行为模型。行为模型的保真度直接决定了闭环评估的可信度。如果仿真里的其他车辆都是简单的匀速直线运动那闭环评估的结果参考价值就很有限。我一般会用基于真实数据驱动的行为模型比如从真实轨迹里学习一个行为分布仿真时从分布里采样。这样虽然不能完全复现真实世界的复杂性但至少比规则驱动的行为模型要真实得多。场景复现的另一个问题是初始状态的选择。同一个场景初始时刻不同演化结果可能完全不同。我的做法是对每个场景做多次仿真每次用不同的初始状态扰动比如位置加一点随机偏移速度加一点随机噪声然后统计多次仿真的平均表现。这样比单次仿真要稳健得多。5.3 闭环指标的设计闭环评估的指标和开环完全不同。开环看的是预测误差闭环看的是驾驶后果。常用的闭环指标包括碰撞率、急刹车频率、通行效率、乘坐舒适度等。碰撞率是最硬的指标但也是最稀疏的。很多场景跑下来可能一次碰撞都没有这时候碰撞率就是零没法区分模型好坏。所以需要辅助指标比如最小安全距离、碰撞时间的最小值、规划模块的急动度等。这些指标虽然不如碰撞率直接但能提供更细粒度的区分度。我比较喜欢用的一个组合是碰撞率加最小碰撞时间加规划急动度。碰撞率看底线最小碰撞时间看风险余量规划急动度看乘坐体验。三个指标一起看基本能勾勒出一个模型在闭环里的综合表现。5.4 开环与闭环的相关性分析开环评估要真正有用必须和闭环结果有足够的相关性。如果开环指标好的模型在闭环里反而差那开环评估就失去了筛选价值。我建议定期做开环闭环相关性分析。具体做法是选一批模型同时跑开环和闭环评估然后算开环指标和闭环指标之间的秩相关系数。如果相关系数高说明开环评估是有效的如果低那就要回头检查开环评估的场景划分和权重设置是不是有问题。这个分析我一般每半年做一次每次都会发现一些之前没注意到的问题。有一次发现开环评估里表现很好的模型在闭环里碰撞率偏高查了半天最后发现是开环评估的场景切片把一些关键的交互上下文切掉了导致模型在开环里看起来很好但闭环里因为缺少上下文而表现不佳。后来调整了切片策略相关性就上去了。6. 工具链与工程化落地6.1 评估框架的模块化设计场景驱动评估的工程实现最好从一开始就做成模块化的。核心模块包括数据加载、场景切片、标签引擎、指标计算、结果聚合、可视化报告。每个模块之间通过标准接口通信方便替换和扩展。数据加载模块要支持多种数据格式因为不同项目的数据格式可能不一样。场景切片模块要支持可配置的切片策略因为不同ODD的切片逻辑可能不同。标签引擎要支持规则和聚类的混合而且规则要能热更新不用改代码就能加新规则。指标计算模块要支持插件式扩展方便加新指标。结果聚合模块要支持多种权重方案。可视化报告模块要能自动生成减少人工整理的时间。我见过一些团队把评估代码写成一坨所有逻辑混在一个大文件里加个新指标要改十几个地方。这种代码维护成本极高而且容易出bug。模块化设计前期多花点时间后期省下的时间是指数级的。6.2 评估流水线的自动化评估应该是一个自动化的流水线而不是每次手动跑脚本。理想的状态是模型训练完成后自动触发评估评估结果自动生成报告报告自动推送给相关人。这样能大大加快迭代速度。流水线的关键节点包括模型导出、评估集加载、场景切片、标签匹配、指标计算、结果聚合、报告生成、通知推送。每个节点都要有失败重试和日志记录。评估失败时能快速定位是哪个环节出了问题。自动化还有一个好处是保证了评估的一致性。手动跑评估时不同的人可能用不同的参数、不同的评估集版本结果没法比较。自动化流水线固定了所有参数和版本保证了每次评估都是可比较的。6.3 评估结果的可视化评估报告的可视化做得好不好直接决定了评估结果能不能被有效利用。我见过太多评估报告就是一堆表格和数字规划工程师看了根本不知道该怎么用。好的可视化应该做到一眼能看出模型在哪些场景上强、哪些场景上弱。我常用的做法是画场景热力图横轴是场景类型纵轴是模型格子的颜色代表指标好坏。这样一眼就能看出哪个模型在哪个场景上有问题。另外还会画误差分布图不只看平均值还看分布的尾部因为尾部才是风险所在。对于关键场景还会把具体的预测轨迹和真值轨迹画出来对比。这种可视化对定位问题特别有用比看数字直观得多。我一般会挑每个场景子集里误差最大的十条片段画出来人工看一遍往往能发现一些指标反映不出来的问题。6.4 与训练流程的闭环评估的最终目的是指导训练。如果评估结果不能反馈到训练流程里那评估就白做了。所以评估和训练之间要形成一个闭环。具体做法是评估发现某个场景子集指标差就把这个子集的样本在训练集里的权重调高重新训练再看评估结果。如果指标上去了说明问题确实是数据权重的问题如果没上去那可能是模型结构或者特征的问题需要进一步排查。这个闭环说起来简单做起来需要不少工程投入。训练集要支持按场景标签动态采样训练流程要支持增量训练或者微调评估要能快速反馈。但一旦跑通了迭代效率会有质的提升。我之前带的一个项目跑通这个闭环之后复杂场景的指标在两个月内提升了将近百分之四十靠的就是评估精准定位问题加训练快速响应。7. 一些个人体会场景驱动评估这件事技术上的难点其实都能克服真正的挑战在于观念转变。很多团队习惯了看一个数字排名突然要接受一套多维度的、带权重的评估体系会觉得麻烦、不直观。但只要你经历过一次平均指标很好但实车表现拉胯的事故就会明白这种麻烦是值得的。我自己的经验是评估体系的建设要循序渐进。不要一上来就搞一套特别复杂的标签体系和权重方案先从三五个核心场景开始把流程跑通让团队看到价值再逐步扩展。一开始就追求大而全往往推不动。另外评估指标不要太多。指标太多会分散注意力而且不同指标之间可能相互矛盾反而让人无所适从。我一般控制在五到八个核心指标每个指标都有明确的物理意义和工程含义多了就砍。最后说一个容易被忽视的点评估结果要定期回顾。不是评估完就完了而是要定期把历史评估结果拿出来对比看模型是在进步还是在原地踏步看哪些场景一直是短板。这种纵向对比往往比单次评估更有价值因为它能揭示出趋势性的问题。我一般每个月做一次回顾把过去几个月的评估结果拉出来画趋势图哪些指标在涨、哪些在跌一目了然。这个习惯帮我提前发现了好几次模型性能的隐性退化都是在还没造成严重后果之前就介入处理了。