1. 先把问题说透当前预测器评测到底差在哪里我做了三年多自动驾驶预测模型的评测工作一个最直观的感受是我们一直在用量表却忘了量的是不是该量的事。两年前我拿到一个在公开榜单上表现极为亮眼的轨迹预测模型ADE平均位移误差比上一代低了将近15%FDE终末位移误差也降了不少当时的结论几乎一边倒这个模型值得上车。结果我们把它接进仿真环境跑了一批真实路采数据发现它在高速汇入场景里频繁预测出贴着前车尾部的激进变道轨迹——数值上好看实际根本不能用。问题不是出在模型上而是出在评测方式上。传统的轨迹预测评测核心就那几把尺子ADE、FDE、MR错失率通常用2米阈值判断预测轨迹是否偏离真值。这三项指标覆盖了整体预测准不准终点落点偏不偏有没有大错三个维度看起来合理但它们的本质是对所有样本的算术平均。一旦样本池里普通直行和标准跟车的场景占了绝大多数复杂交互场景的误差就会被稀释掉。模型完全可以把90%的精力用在优化高频场景上剩下10%的场景随便应付——平均数字照样很好看。更要命的是这些指标从设计之初就没有回答一个问题预测误差对下游规划决策到底意味着什么一辆车在空旷直道上预测误差了50厘米规划器毫不在意同样50厘米的误差发生在十字路口两名玩家同时抢行的场景里可能直接导致一次紧急制动。传统评测把这两者的误差一视同仁地加进了同一个平均值相当于把心脏病和感冒混在一起统计治愈率——统计上没错临床上没用。这也正是我坚持认为场景驱动评测Scenario-Driven Evaluation应当被当作预测器评测的主干方法而不是补充方法的原因。应对不同的交通场景预测器要付出的努力程度完全不同。评测如果不把场景上下文考虑进来就像只告诉你一个人平均跑得很快却不告诉你他是在平地上跑还是扛着沙袋在爬坡。在做这篇分享之前我重新梳理了一遍我们团队这两年在场景驱动评测上踩过的坑、趟出来的路还有最终沉淀下来的一整套可执行的评估框架。这篇文章会把这套框架完整拆开从场景怎么定义、指标怎么重新设计到评测流程怎么落地、坑在哪里一次说透。适合正在搭建预测模型评测体系的团队也适合想把自己模型扒层皮看看真实水平的算法工程师。2. 一个被低估的前提假设场景分类体系是评测的根很多人一听到场景驱动评测第一反应就是把数据按场景分个类然后分别算指标。这句话对了一半。分个类确实是最表层的工作但真正的难点在于场景分类的粒度、层级和标签体系直接决定了你能从评测结果里挖出多少信息。2.1 从全局平均到场景切片三个层级的场景定义我们最终把场景定义拆成了三个层级分别解决不同层面的问题。第一层是道路结构层。这是最容易标注的层面直接来自地图或高精地图属性直道、弯道、十字路口、环岛、匝道、汇入汇出区、施工改道区。干净利落几乎没有标注歧义。这一层主要回答的是预测器在不同几何拓扑下的基础能力。第二层是交通状态层。这层描述的是场景内的交通流特性比如畅通、拥堵、走走停停、排队溢出、低速重载、高速跟驰等。这一层的难点在于状态和道路结构是耦合的——同样一个高速主路畅通状态下自车以120km/h巡航和拥堵状态下以15km/h蠕行预测器的行为逻辑完全不一样。第三层是交互模式层。这是最具有挑战性、同时也是判断一个预测器好坏最关键的一层。它描述的是自车与其他交通参与者之间的博弈关系典型例子包括行人横穿但意图不明确、对向车辆在双向两车道上侵占本车道超车、邻车在匝道汇入端与自车同时抢占同一条间隙、路口无保护左转时与直行车流的时间竞争。传统评测的问题在于它默认场景分布是均匀的——每个样本对评测结果的贡献权重相同。而这三个层级的切分方式把预测器的能力评估从一个模糊的平均分变成了一个多维度的能力画像。真实场景里第二层和第三层的某些组合比如拥堵状态下的行人穿梭邻车汇入极其罕见但它们恰恰是规划器最需要正确预测的地方评测体系如果连这种组合都不建标签预测器在这个组合上做得好坏就永远不会被衡量——没有被衡量的能力就永远不会被优化。2.2 场景切片的粒度scene-level和instance-level必须分开我们在搭建评测框架的初期踩过一个很大的坑把场景标签直接挂在整条路采数据片段上。比如某一段1分钟的数据交通状态被标为拥堵然后这一整段的模型预测指标都被归到拥堵场景下。这个做法看着没问题实际上糙得很。原因在于一条连续的轨迹数据里每个预测时刻点的上下文是动态变化的。同一个数据片段前5秒自车还在排队等红灯后5秒绿灯亮起开始启动跟车再往后10秒遇到一个行人横穿。如果整段打一个排队标签那行人横穿的预测误差就会被错误地归因到排队场景里——这个误差数据反而会污染整体的场景结论。正确的做法是把粒度细到instance-level。具体来说以一个预测时刻点或者被称为一个预测上下文为最小单位每个instance只关联到当前时刻的场景上下文当前道路结构、前T秒的交通状态、自车与其他道路使用者的相对位置和意图线索。这样一个场景标签体系建立在这里后评测才能做到在哪段路上哪种交通状态下与谁交互时这个预测器表现如何——而不是这个数据片段里预测器表现如何。这里我想强调一点instance-level的标签工作量和人力成本会比整段打标签高不少一次性给一千个小时的数据全部打上精细的场景标签并不现实。我们最终的取舍是先给全量数据打粗粒度标签筛出目标场景候选集再对候选集做细粒度instance级标注。粗筛可以靠规则和启发式算法自动完成细标则靠标注员在可视化工具里逐段确认成本和收益之间能取得一个比较理想的平衡。3. 重新定义好场景驱动之下的核心评估指标设计传统指标ADE/FDE/MR是纯几何指标它们的共同特征是只度量预测轨迹与真实轨迹的贴近程度完全不管这个误差发生在什么语境下。而场景驱动评测的第二步就是要把语境纳入到指标设计里。3.1 我们为什么放弃全局第一批TOR与DAC的意义在重构指标时我们首先确定的两个指标是TORTime of Reach到达时间和DACDistance at Completion完成间距。先说TOR。这个指标衡量的不是终末位置差了多远而是预测轨迹在多长时间内能够到达某个关键区域或完成某个关键动作。举个例子在匝道汇入主路这个场景里自车的关键区域是匝道终点与主路最外侧车道之间的交汇带一个预测器如果预测出的自车轨迹到达交汇带的时间比真实轨迹提前了0.8秒或者延迟了1.2秒即使在空间位置上误差很小FDE看起来不错对下游规划器的决策时间窗也会产生质的影响。TOR的计算不复杂它本质上是一个时间差选取一条预测轨迹定义一个关键区域算出预测轨迹从当前时刻第一次进入该区域的时刻再算出真实轨迹进入该区域的时刻两者作差。关键在于关键区域的定义必须因场景而异而不是全局统一。我们在实践里维护了一张场景-关键区域映射表比如无保护左转场景的关键区域是冲突车流的行驶车道投影区行人横穿场景的关键区域是斑马线两侧各1米宽的区域。再说DAC。这个指标解决的是当自车到达某个决策点比如停车线、让行点、汇入点时自车与目标对象之间的实际间距。为什么这个指标重要因为轨迹预测不只是为了画一条好看的行驶曲线它最核心的任务是给规划器提供一个在这个时刻如果发生冲突我和对方之间还有多少安全缓冲的估计。DAC计算时直接看某个关键时间点的两车或车与人间距误差越大说明预测器对这个安全缓冲的估值越失准。TOR和DAC跟ADE/FDE的本质区别是前者度量的是与决策相关的时刻和间距后者度量的是几何平均距离。它们不是替代关系而是层级关系——同一套模型在两种指标下的表现可以完全不同。我们遇到过不止一个模型ADE/FDE指标下降明显但DAC指标反而恶化了因为平均几何误差小了但模型对特定交互对象的间距估计反而系统性偏保守或偏激进这在全局平均值里完全看不出来。3.2 约束预测、偏离场景与预测熵三个容易忽略的暗礁除了TOR和DAC这两个决策相关指标我们后续还逐步加入了三个更隐蔽、更刁钻的指标我分别叫它们约束预测率偏离场景率和预测熵。约束预测率意思是预测轨迹是否违反了硬约束。这里的硬约束包括但不限于冲出可行驶区域边界、穿过实线、与静态障碍物碰撞、超出车辆动力学极限比如预测出横摆角速度超过物理上限的轨迹。用一句话说就是预测轨迹必须首先物理上可行、位置上合法。注意这个指标不需要跟真值对比它是自检式的。我们内部定了一个硬性的门槛任何模型在约束预测率超过0.5%时一律不允许进入下一轮安全评估。因为哪怕只有0.5%的预测轨迹穿进对向车道或骑上路沿在一个规模足够大的车队里也意味着每天都有几十次预测违反约束的case这会让后端的规划器在做可行性审查时疲于奔命。偏离场景率这个指标衡量的是当预测器被要求在某个特定场景下输出预测时它的输出是否符合该场景的物理规律。最典型的例子是在一个行人正在横穿马路的场景里预测器给出的行人轨迹是继续停在路边不动或者在一个前车已经亮起刹车灯、明显减速的场景里预测器给出的前车轨迹是保持原有速度继续行驶。这些预测在纯数值上可能不是最差的FDE因为真值只给了一条它偏到另一条合理轨迹上数值误差反而不算离谱但在安全语义上完全是错的。检测这个指标需要在场景标签里额外附带该场景的合理行为范围。这当然比纯几何标签更复杂但它的价值在于能抓出预测器的语义失聪——模型对场景的理解并没有体现在输出上。这类问题的危害往往是不连续的平时不出现一出现就是硬碰撞风险。预测熵是最后一个我们逐步重视起来的指标。它度量的是预测器输出的概率分布的集中度——如果预测器对某种场景的多种可能发展心中没数它的输出概率分布会变得非常扁平。熵太大说明模型在骑墙对场景不够笃定熵太小说明模型过于自信可能在真实情况偏离预期时完全没有缓冲。我们用熵作为评测的第三维度并不追求它越小越好或越大越好而是看它是否与场景的不确定性程度匹配。比如在拥堵缓行场景中周围车辆的意图空间本来就小预测熵理应偏低如果这种场景下出现高熵输出意味着模型可能没有学到拥堵场景下车辆轨迹相对可预测这一隐含规则。这四个指标和传统几何指标加在一起我们把一个预测器的评测从画线准不准扩展成了五个维度的画像几何精度、决策时序精度、安全缓冲精度、硬约束合规性、场景语义合理性。后者加起来才真正接近measuring what matters这个标题的含义。4. 场景驱动评测的落地流程从数据筛选到掉队根因分析指标设计得再漂亮如果流程跑不起来一切等于零。我们最终沉淀下来的评测流程分四步走每一轮模型迭代都要完整走一遍。4.1 第一步场景覆盖度盘点——先回答我们测全面了吗流程的开端不是跑指标而是先做一件事把测试集拿到手里按前面说的三层场景标签体系做一次覆盖度盘点。我们内部维护了一张场景覆盖度矩阵横轴是道路结构层的类别直道、弯道、匝道、路口等纵轴是交通状态层的类别畅通、缓行、拥堵、停车起步等另外还有一个独立的交互模式维度。每次更新测试集之后我们都要计算矩阵每个格子的样本量并把覆盖率低于阈值的格子标红。这个步骤的实际作用是防止评测偏差。如果某个版本为了提高整体评测速度无意间少采集了大曲率弯道的样本那一个在多弯道路段表现很差的模型可能在评测里轻松通过。关于覆盖度业界没有一个统一的黄金标准我分享一下我们的经验值核心高频场景直道畅通、跟车缓行每个格子至少500个instance关键安全场景路口无保护左转、汇入抢行、行人横穿至少200个instance长尾场景视资源情况尽量达到50个instance以上。如果低于这个数量评测结论只能作为参考不能作为放行依据。4.2 第二步分层指标计算——报告要让人一眼看出问题覆盖度确认之后进入正式评测阶段。我们不直接算全局ADE/FDE而是严格按照层级结构逐层聚合。先算每个instance的各项指标然后按三层标签分别聚合按道路结构层聚合得到直道/匝道/路口分别表现如何按交通状态层聚合得到拥堵时比畅通时差多少按交互模式层聚合得到行人交互和车车交互谁更难处理。这个分层报告的价值在于快速定位掉队方向。我们内部有个红色线机制任何指标在上一个聚合层级里如果表现低于基线模型或前一个版本的模型该格子会标红。评审时我们只看标红格子和为什么标红不看任何平均数字。以我们的真实经验为例某个版本的模型在全局ADE上下降了2%看起来是一次干净的优化但分层报告揭露出它在拥堵匝道汇入这个组合格子上表现倒退了9%。原因后来被定位到训练数据增广时低估了这个组合的样本权重。如果没有分层报告这个问题可能要到路测阶段才会暴露而那时定位和回归成本已经翻了数倍。4.3 第三步场景内瓶颈拆解——掉队了然后呢标红只是第一步预测器评测的真正功力在于解释标红的原因。我们把这步叫场景内瓶颈拆解。拿到一个掉队的场景组合后我们通常按以下顺序排查先看这个场景下的硬约束预测率是否上升——是则优先排查输出动力学合理性再看预测熵是否异常——如果熵显著升高说明模型在输入特征上出现了分布外OOD判据然后看TOR/DAC的误差方向——是系统性提前还是滞后是系统性偏近还是偏远方向性信息远比绝对误差值更有用最后才回到几何指标看空间上错在哪里是起步段带偏了还是终点发散。排查的产物是一个场景失败切片集。我们自动把掉队场景里的失败case切成短视频并叠加可视化预测轨迹与真值轨迹、场景标签和关键区域算法工程师在做模型迭代时参考的是这组切片而不是干巴巴的数值表。老实讲过去一年里我们定位到的绝大多数真实问题比如行人突然加速场景下模型的预测分布过于集中都是靠这些切片直接看出来的。4.4 第四步回归门禁与场景覆盖率增量报告评测流程的最后一道关卡是回归门禁。我们把引用了新数据、新标签、新模型版本的评测结果和上一轮结果做自动对比形成一份五维度的回归报告。门禁规则是不允许任何标红格子出现在高安全相关场景路口、汇入、行人横穿中低风险场景允许小幅回退但回退幅度不能超过对应指标方差的1.5倍任何模型在提升某类场景的同时若有其他类场景回退必须提交一份掉队场景归因说明否则不许合入主线。这套门禁规则最大的价值在于斩断了无限优化头部场景的路径。模型团队如果想提升全局数字必须同时保证安全相关场景不掉队这就在制度上把评测驱动改进从口号落到了流程里。5. 跑通这套流程后我趟过的几个重要的坑框架本身已经完整了但真正把它跑起来、用好还有一堆细节坑。我挑几个最典型的分享一下这些在论文和方法论里通常看不到。5.1 场景标签的一致性比精确性更重要我前面提到的三层场景标签体系听起来很系统但执行时的最大问题是不同标注员对拥堵和缓行的边界理解可能完全不同。同一段数据标注员A认为拥堵标注员B认为只是缓行。如果这类不一致长期存在最终的分层评测结果会整体失真——因为你其实在把不同语义框架下的数据混在一起算指标。我们的对策是在项目启动初期就建立场景标签的决策树式判定规则而不是依赖主观描述。比如拥堵不再是一个模糊的形容词而是一条明确的规则当前车道的平均车速低于15km/h且车头时距小于2秒持续至少5秒才判定为拥堵。每一条规则都附带数值阈值标注员不再需要感觉只需要按规则判断。另外一定要定期做一致性抽检。我们每两周随机抽3%的新标注数据让两名标注员独立标注并对比Kappa系数如果Kappa低于0.8就说明标签标准已经漂移了需要停下来对齐而不是继续往下标。这个投入看起来有点繁琐但比事后发现评测失真、重新标注的代价低得多。5.2 指标越多越好是个陷阱在设计评测指标时团队内部有不少人倾向于继续加码——把更细维度的几何误差、速度误差、加速度误差、横向偏离全部纳入。我在这件事上持明确反对态度。原因很简单每一项指标都在引导模型团队的优化注意力。如果你把加速度误差纳入评测体系模型团队就会花时间去优化预测轨迹的加速度平滑性而这个时间和精力原本应该花在更关键的TO/DAC和场景语义合理性上。评测指标不是越多越好而是越贴近规划器真正依赖什么决策信息越好。我们最后定下的原则是每增加一个新指标必须回答一个问题——这个指标能在何种程度上改变下游规划器的决策行为回答不出来的指标一律滚出评测体系。按这个标准我们砍掉了至少三个听起来很严谨但实际无用对决策无影响的指标。5.3 长尾场景的最小覆盖原则长尾场景的评测一直是个难题样本量太少统计意义不足单纯堆样本又成本过高。我们最终的折中方案是最小覆盖原则——不追求长尾场景的统计学显著性而是追求每个场景类型至少有20个精心挑选的、覆盖面足够大的代表性案例。20个案例无法告诉你这个模型在这个场景的ADE是1.3米还是1.5米但它足以告诉你这个模型在这个场景的约束预测率是否高得离谱、是否出现了明显的语义失聪。这个原则的本质是对长尾场景评测的目标从定量评估转变为定性筛查。当你只有能力获取少量样本时与其纠结用95%置信区间还是90%置信区间不如把预算花在提高样本的代表性上——选取该场景类型里最典型的几何拓扑、最典型的速度分布和最典型的交互博弈组合。5.4 与真值学习的自证循环问题这是我在整个实践过程中最想提醒大家的一点。传统评测默认把传感器观测到的真实轨迹当作真值但这个假设在某些场景下有严重问题——尤其是动态遮挡场景。比如在一个被大车遮挡的行人场景中真值轨迹是行人从遮挡物后面走出来之后的片段而预测器在行人出现之前就必须给出预判此时如果评测只比较预测轨迹和遮挡结束后观测到的真值轨迹就存在一个不可避免的系统性误差模型的预测来自不完全信息真值却是完全信息。更麻烦的是有些模型在训练阶段就见过类似场景的完整真值它会被引导为看到一点遮挡迹象就立刻输出跟真值一致的轨迹。这种模型在带真值的离线评测里分数极高但它并没有真正学会预测被遮挡行人的行为——它只是学会了凭遮挡线索猜测答案。这就是我所说的自证循环评测数据本身参与塑造了模型的输出而评测又用这份输出和同样的数据对比得出了一个虚假的高分。我们目前的应对办法是在评测集里刻意保留一部分未被训练集覆盖的、遮挡关系特殊的场景并在评测报告里单独标注这部分的结论把它当作泛化能力参考来用而不是并入全局指标。这个方法并不完美但至少能让我们对模型的信息充分性边界有一个不撒谎的感知。6. 关于好的定义我们团队内部最终吵出了一个共识经过近两年的实践我们团队内部在评测到底该追求什么这个根本问题上吵了很多轮最终的共识写在我们的评测规范文档里我把它摘出来作为这篇分享的收尾。第一评测不是为了让模型分数好看而是为了暴露模型在真实世界里的失败模式。一个指标体系如果跑了一整轮迭代却一个失败模式都没暴露那它不是一个好的评测体系它只是一个大号计算器。第二场景驱动评测的核心不是分类而是识别哪些场景对决策最敏感。分类只是手段它最终要服务于一个目标——让你知道哪个场景里预测器的误差会直接传导为规划器的保守绕行、急刹或冒险动作。一切不服务于这个目标的场景切片都是在给评测系统增加噪音。第三评测体系是一个活体不是一块石碑。随着预测模型的能力提升和新场景数据的积累场景标签体系、指标权重和门禁规则都需要按季度定期审视和调整。上一季度制定的严格门禁下一季度可能就不再合理因为模型能力整体上了一个台阶刹车距离、换道成功率这些底层分布发生了变化门禁自然要跟着移动。如果你正在搭建预测器评测体系我的建议是不要一上来就追求大而全先选两个决策敏感场景比如无保护左转和匝道汇入把从场景定义到指标计算到失败案例可视化的链路彻底跑通再逐步扩展场景版图和指标维度。这比一开始就重兵投入、铺得太大、最后复盘发现哪个层级都不够深要有效得多。毕竟量度一个有价值的维度远远好过量度十个无关痛痒的维度。
1. 先把问题说透当前预测器评测到底差在哪里我做了三年多自动驾驶预测模型的评测工作一个最直观的感受是我们一直在用量表却忘了量的是不是该量的事。两年前我拿到一个在公开榜单上表现极为亮眼的轨迹预测模型ADE平均位移误差比上一代低了将近15%FDE终末位移误差也降了不少当时的结论几乎一边倒这个模型值得上车。结果我们把它接进仿真环境跑了一批真实路采数据发现它在高速汇入场景里频繁预测出贴着前车尾部的激进变道轨迹——数值上好看实际根本不能用。问题不是出在模型上而是出在评测方式上。传统的轨迹预测评测核心就那几把尺子ADE、FDE、MR错失率通常用2米阈值判断预测轨迹是否偏离真值。这三项指标覆盖了整体预测准不准终点落点偏不偏有没有大错三个维度看起来合理但它们的本质是对所有样本的算术平均。一旦样本池里普通直行和标准跟车的场景占了绝大多数复杂交互场景的误差就会被稀释掉。模型完全可以把90%的精力用在优化高频场景上剩下10%的场景随便应付——平均数字照样很好看。更要命的是这些指标从设计之初就没有回答一个问题预测误差对下游规划决策到底意味着什么一辆车在空旷直道上预测误差了50厘米规划器毫不在意同样50厘米的误差发生在十字路口两名玩家同时抢行的场景里可能直接导致一次紧急制动。传统评测把这两者的误差一视同仁地加进了同一个平均值相当于把心脏病和感冒混在一起统计治愈率——统计上没错临床上没用。这也正是我坚持认为场景驱动评测Scenario-Driven Evaluation应当被当作预测器评测的主干方法而不是补充方法的原因。应对不同的交通场景预测器要付出的努力程度完全不同。评测如果不把场景上下文考虑进来就像只告诉你一个人平均跑得很快却不告诉你他是在平地上跑还是扛着沙袋在爬坡。在做这篇分享之前我重新梳理了一遍我们团队这两年在场景驱动评测上踩过的坑、趟出来的路还有最终沉淀下来的一整套可执行的评估框架。这篇文章会把这套框架完整拆开从场景怎么定义、指标怎么重新设计到评测流程怎么落地、坑在哪里一次说透。适合正在搭建预测模型评测体系的团队也适合想把自己模型扒层皮看看真实水平的算法工程师。2. 一个被低估的前提假设场景分类体系是评测的根很多人一听到场景驱动评测第一反应就是把数据按场景分个类然后分别算指标。这句话对了一半。分个类确实是最表层的工作但真正的难点在于场景分类的粒度、层级和标签体系直接决定了你能从评测结果里挖出多少信息。2.1 从全局平均到场景切片三个层级的场景定义我们最终把场景定义拆成了三个层级分别解决不同层面的问题。第一层是道路结构层。这是最容易标注的层面直接来自地图或高精地图属性直道、弯道、十字路口、环岛、匝道、汇入汇出区、施工改道区。干净利落几乎没有标注歧义。这一层主要回答的是预测器在不同几何拓扑下的基础能力。第二层是交通状态层。这层描述的是场景内的交通流特性比如畅通、拥堵、走走停停、排队溢出、低速重载、高速跟驰等。这一层的难点在于状态和道路结构是耦合的——同样一个高速主路畅通状态下自车以120km/h巡航和拥堵状态下以15km/h蠕行预测器的行为逻辑完全不一样。第三层是交互模式层。这是最具有挑战性、同时也是判断一个预测器好坏最关键的一层。它描述的是自车与其他交通参与者之间的博弈关系典型例子包括行人横穿但意图不明确、对向车辆在双向两车道上侵占本车道超车、邻车在匝道汇入端与自车同时抢占同一条间隙、路口无保护左转时与直行车流的时间竞争。传统评测的问题在于它默认场景分布是均匀的——每个样本对评测结果的贡献权重相同。而这三个层级的切分方式把预测器的能力评估从一个模糊的平均分变成了一个多维度的能力画像。真实场景里第二层和第三层的某些组合比如拥堵状态下的行人穿梭邻车汇入极其罕见但它们恰恰是规划器最需要正确预测的地方评测体系如果连这种组合都不建标签预测器在这个组合上做得好坏就永远不会被衡量——没有被衡量的能力就永远不会被优化。2.2 场景切片的粒度scene-level和instance-level必须分开我们在搭建评测框架的初期踩过一个很大的坑把场景标签直接挂在整条路采数据片段上。比如某一段1分钟的数据交通状态被标为拥堵然后这一整段的模型预测指标都被归到拥堵场景下。这个做法看着没问题实际上糙得很。原因在于一条连续的轨迹数据里每个预测时刻点的上下文是动态变化的。同一个数据片段前5秒自车还在排队等红灯后5秒绿灯亮起开始启动跟车再往后10秒遇到一个行人横穿。如果整段打一个排队标签那行人横穿的预测误差就会被错误地归因到排队场景里——这个误差数据反而会污染整体的场景结论。正确的做法是把粒度细到instance-level。具体来说以一个预测时刻点或者被称为一个预测上下文为最小单位每个instance只关联到当前时刻的场景上下文当前道路结构、前T秒的交通状态、自车与其他道路使用者的相对位置和意图线索。这样一个场景标签体系建立在这里后评测才能做到在哪段路上哪种交通状态下与谁交互时这个预测器表现如何——而不是这个数据片段里预测器表现如何。这里我想强调一点instance-level的标签工作量和人力成本会比整段打标签高不少一次性给一千个小时的数据全部打上精细的场景标签并不现实。我们最终的取舍是先给全量数据打粗粒度标签筛出目标场景候选集再对候选集做细粒度instance级标注。粗筛可以靠规则和启发式算法自动完成细标则靠标注员在可视化工具里逐段确认成本和收益之间能取得一个比较理想的平衡。3. 重新定义好场景驱动之下的核心评估指标设计传统指标ADE/FDE/MR是纯几何指标它们的共同特征是只度量预测轨迹与真实轨迹的贴近程度完全不管这个误差发生在什么语境下。而场景驱动评测的第二步就是要把语境纳入到指标设计里。3.1 我们为什么放弃全局第一批TOR与DAC的意义在重构指标时我们首先确定的两个指标是TORTime of Reach到达时间和DACDistance at Completion完成间距。先说TOR。这个指标衡量的不是终末位置差了多远而是预测轨迹在多长时间内能够到达某个关键区域或完成某个关键动作。举个例子在匝道汇入主路这个场景里自车的关键区域是匝道终点与主路最外侧车道之间的交汇带一个预测器如果预测出的自车轨迹到达交汇带的时间比真实轨迹提前了0.8秒或者延迟了1.2秒即使在空间位置上误差很小FDE看起来不错对下游规划器的决策时间窗也会产生质的影响。TOR的计算不复杂它本质上是一个时间差选取一条预测轨迹定义一个关键区域算出预测轨迹从当前时刻第一次进入该区域的时刻再算出真实轨迹进入该区域的时刻两者作差。关键在于关键区域的定义必须因场景而异而不是全局统一。我们在实践里维护了一张场景-关键区域映射表比如无保护左转场景的关键区域是冲突车流的行驶车道投影区行人横穿场景的关键区域是斑马线两侧各1米宽的区域。再说DAC。这个指标解决的是当自车到达某个决策点比如停车线、让行点、汇入点时自车与目标对象之间的实际间距。为什么这个指标重要因为轨迹预测不只是为了画一条好看的行驶曲线它最核心的任务是给规划器提供一个在这个时刻如果发生冲突我和对方之间还有多少安全缓冲的估计。DAC计算时直接看某个关键时间点的两车或车与人间距误差越大说明预测器对这个安全缓冲的估值越失准。TOR和DAC跟ADE/FDE的本质区别是前者度量的是与决策相关的时刻和间距后者度量的是几何平均距离。它们不是替代关系而是层级关系——同一套模型在两种指标下的表现可以完全不同。我们遇到过不止一个模型ADE/FDE指标下降明显但DAC指标反而恶化了因为平均几何误差小了但模型对特定交互对象的间距估计反而系统性偏保守或偏激进这在全局平均值里完全看不出来。3.2 约束预测、偏离场景与预测熵三个容易忽略的暗礁除了TOR和DAC这两个决策相关指标我们后续还逐步加入了三个更隐蔽、更刁钻的指标我分别叫它们约束预测率偏离场景率和预测熵。约束预测率意思是预测轨迹是否违反了硬约束。这里的硬约束包括但不限于冲出可行驶区域边界、穿过实线、与静态障碍物碰撞、超出车辆动力学极限比如预测出横摆角速度超过物理上限的轨迹。用一句话说就是预测轨迹必须首先物理上可行、位置上合法。注意这个指标不需要跟真值对比它是自检式的。我们内部定了一个硬性的门槛任何模型在约束预测率超过0.5%时一律不允许进入下一轮安全评估。因为哪怕只有0.5%的预测轨迹穿进对向车道或骑上路沿在一个规模足够大的车队里也意味着每天都有几十次预测违反约束的case这会让后端的规划器在做可行性审查时疲于奔命。偏离场景率这个指标衡量的是当预测器被要求在某个特定场景下输出预测时它的输出是否符合该场景的物理规律。最典型的例子是在一个行人正在横穿马路的场景里预测器给出的行人轨迹是继续停在路边不动或者在一个前车已经亮起刹车灯、明显减速的场景里预测器给出的前车轨迹是保持原有速度继续行驶。这些预测在纯数值上可能不是最差的FDE因为真值只给了一条它偏到另一条合理轨迹上数值误差反而不算离谱但在安全语义上完全是错的。检测这个指标需要在场景标签里额外附带该场景的合理行为范围。这当然比纯几何标签更复杂但它的价值在于能抓出预测器的语义失聪——模型对场景的理解并没有体现在输出上。这类问题的危害往往是不连续的平时不出现一出现就是硬碰撞风险。预测熵是最后一个我们逐步重视起来的指标。它度量的是预测器输出的概率分布的集中度——如果预测器对某种场景的多种可能发展心中没数它的输出概率分布会变得非常扁平。熵太大说明模型在骑墙对场景不够笃定熵太小说明模型过于自信可能在真实情况偏离预期时完全没有缓冲。我们用熵作为评测的第三维度并不追求它越小越好或越大越好而是看它是否与场景的不确定性程度匹配。比如在拥堵缓行场景中周围车辆的意图空间本来就小预测熵理应偏低如果这种场景下出现高熵输出意味着模型可能没有学到拥堵场景下车辆轨迹相对可预测这一隐含规则。这四个指标和传统几何指标加在一起我们把一个预测器的评测从画线准不准扩展成了五个维度的画像几何精度、决策时序精度、安全缓冲精度、硬约束合规性、场景语义合理性。后者加起来才真正接近measuring what matters这个标题的含义。4. 场景驱动评测的落地流程从数据筛选到掉队根因分析指标设计得再漂亮如果流程跑不起来一切等于零。我们最终沉淀下来的评测流程分四步走每一轮模型迭代都要完整走一遍。4.1 第一步场景覆盖度盘点——先回答我们测全面了吗流程的开端不是跑指标而是先做一件事把测试集拿到手里按前面说的三层场景标签体系做一次覆盖度盘点。我们内部维护了一张场景覆盖度矩阵横轴是道路结构层的类别直道、弯道、匝道、路口等纵轴是交通状态层的类别畅通、缓行、拥堵、停车起步等另外还有一个独立的交互模式维度。每次更新测试集之后我们都要计算矩阵每个格子的样本量并把覆盖率低于阈值的格子标红。这个步骤的实际作用是防止评测偏差。如果某个版本为了提高整体评测速度无意间少采集了大曲率弯道的样本那一个在多弯道路段表现很差的模型可能在评测里轻松通过。关于覆盖度业界没有一个统一的黄金标准我分享一下我们的经验值核心高频场景直道畅通、跟车缓行每个格子至少500个instance关键安全场景路口无保护左转、汇入抢行、行人横穿至少200个instance长尾场景视资源情况尽量达到50个instance以上。如果低于这个数量评测结论只能作为参考不能作为放行依据。4.2 第二步分层指标计算——报告要让人一眼看出问题覆盖度确认之后进入正式评测阶段。我们不直接算全局ADE/FDE而是严格按照层级结构逐层聚合。先算每个instance的各项指标然后按三层标签分别聚合按道路结构层聚合得到直道/匝道/路口分别表现如何按交通状态层聚合得到拥堵时比畅通时差多少按交互模式层聚合得到行人交互和车车交互谁更难处理。这个分层报告的价值在于快速定位掉队方向。我们内部有个红色线机制任何指标在上一个聚合层级里如果表现低于基线模型或前一个版本的模型该格子会标红。评审时我们只看标红格子和为什么标红不看任何平均数字。以我们的真实经验为例某个版本的模型在全局ADE上下降了2%看起来是一次干净的优化但分层报告揭露出它在拥堵匝道汇入这个组合格子上表现倒退了9%。原因后来被定位到训练数据增广时低估了这个组合的样本权重。如果没有分层报告这个问题可能要到路测阶段才会暴露而那时定位和回归成本已经翻了数倍。4.3 第三步场景内瓶颈拆解——掉队了然后呢标红只是第一步预测器评测的真正功力在于解释标红的原因。我们把这步叫场景内瓶颈拆解。拿到一个掉队的场景组合后我们通常按以下顺序排查先看这个场景下的硬约束预测率是否上升——是则优先排查输出动力学合理性再看预测熵是否异常——如果熵显著升高说明模型在输入特征上出现了分布外OOD判据然后看TOR/DAC的误差方向——是系统性提前还是滞后是系统性偏近还是偏远方向性信息远比绝对误差值更有用最后才回到几何指标看空间上错在哪里是起步段带偏了还是终点发散。排查的产物是一个场景失败切片集。我们自动把掉队场景里的失败case切成短视频并叠加可视化预测轨迹与真值轨迹、场景标签和关键区域算法工程师在做模型迭代时参考的是这组切片而不是干巴巴的数值表。老实讲过去一年里我们定位到的绝大多数真实问题比如行人突然加速场景下模型的预测分布过于集中都是靠这些切片直接看出来的。4.4 第四步回归门禁与场景覆盖率增量报告评测流程的最后一道关卡是回归门禁。我们把引用了新数据、新标签、新模型版本的评测结果和上一轮结果做自动对比形成一份五维度的回归报告。门禁规则是不允许任何标红格子出现在高安全相关场景路口、汇入、行人横穿中低风险场景允许小幅回退但回退幅度不能超过对应指标方差的1.5倍任何模型在提升某类场景的同时若有其他类场景回退必须提交一份掉队场景归因说明否则不许合入主线。这套门禁规则最大的价值在于斩断了无限优化头部场景的路径。模型团队如果想提升全局数字必须同时保证安全相关场景不掉队这就在制度上把评测驱动改进从口号落到了流程里。5. 跑通这套流程后我趟过的几个重要的坑框架本身已经完整了但真正把它跑起来、用好还有一堆细节坑。我挑几个最典型的分享一下这些在论文和方法论里通常看不到。5.1 场景标签的一致性比精确性更重要我前面提到的三层场景标签体系听起来很系统但执行时的最大问题是不同标注员对拥堵和缓行的边界理解可能完全不同。同一段数据标注员A认为拥堵标注员B认为只是缓行。如果这类不一致长期存在最终的分层评测结果会整体失真——因为你其实在把不同语义框架下的数据混在一起算指标。我们的对策是在项目启动初期就建立场景标签的决策树式判定规则而不是依赖主观描述。比如拥堵不再是一个模糊的形容词而是一条明确的规则当前车道的平均车速低于15km/h且车头时距小于2秒持续至少5秒才判定为拥堵。每一条规则都附带数值阈值标注员不再需要感觉只需要按规则判断。另外一定要定期做一致性抽检。我们每两周随机抽3%的新标注数据让两名标注员独立标注并对比Kappa系数如果Kappa低于0.8就说明标签标准已经漂移了需要停下来对齐而不是继续往下标。这个投入看起来有点繁琐但比事后发现评测失真、重新标注的代价低得多。5.2 指标越多越好是个陷阱在设计评测指标时团队内部有不少人倾向于继续加码——把更细维度的几何误差、速度误差、加速度误差、横向偏离全部纳入。我在这件事上持明确反对态度。原因很简单每一项指标都在引导模型团队的优化注意力。如果你把加速度误差纳入评测体系模型团队就会花时间去优化预测轨迹的加速度平滑性而这个时间和精力原本应该花在更关键的TO/DAC和场景语义合理性上。评测指标不是越多越好而是越贴近规划器真正依赖什么决策信息越好。我们最后定下的原则是每增加一个新指标必须回答一个问题——这个指标能在何种程度上改变下游规划器的决策行为回答不出来的指标一律滚出评测体系。按这个标准我们砍掉了至少三个听起来很严谨但实际无用对决策无影响的指标。5.3 长尾场景的最小覆盖原则长尾场景的评测一直是个难题样本量太少统计意义不足单纯堆样本又成本过高。我们最终的折中方案是最小覆盖原则——不追求长尾场景的统计学显著性而是追求每个场景类型至少有20个精心挑选的、覆盖面足够大的代表性案例。20个案例无法告诉你这个模型在这个场景的ADE是1.3米还是1.5米但它足以告诉你这个模型在这个场景的约束预测率是否高得离谱、是否出现了明显的语义失聪。这个原则的本质是对长尾场景评测的目标从定量评估转变为定性筛查。当你只有能力获取少量样本时与其纠结用95%置信区间还是90%置信区间不如把预算花在提高样本的代表性上——选取该场景类型里最典型的几何拓扑、最典型的速度分布和最典型的交互博弈组合。5.4 与真值学习的自证循环问题这是我在整个实践过程中最想提醒大家的一点。传统评测默认把传感器观测到的真实轨迹当作真值但这个假设在某些场景下有严重问题——尤其是动态遮挡场景。比如在一个被大车遮挡的行人场景中真值轨迹是行人从遮挡物后面走出来之后的片段而预测器在行人出现之前就必须给出预判此时如果评测只比较预测轨迹和遮挡结束后观测到的真值轨迹就存在一个不可避免的系统性误差模型的预测来自不完全信息真值却是完全信息。更麻烦的是有些模型在训练阶段就见过类似场景的完整真值它会被引导为看到一点遮挡迹象就立刻输出跟真值一致的轨迹。这种模型在带真值的离线评测里分数极高但它并没有真正学会预测被遮挡行人的行为——它只是学会了凭遮挡线索猜测答案。这就是我所说的自证循环评测数据本身参与塑造了模型的输出而评测又用这份输出和同样的数据对比得出了一个虚假的高分。我们目前的应对办法是在评测集里刻意保留一部分未被训练集覆盖的、遮挡关系特殊的场景并在评测报告里单独标注这部分的结论把它当作泛化能力参考来用而不是并入全局指标。这个方法并不完美但至少能让我们对模型的信息充分性边界有一个不撒谎的感知。6. 关于好的定义我们团队内部最终吵出了一个共识经过近两年的实践我们团队内部在评测到底该追求什么这个根本问题上吵了很多轮最终的共识写在我们的评测规范文档里我把它摘出来作为这篇分享的收尾。第一评测不是为了让模型分数好看而是为了暴露模型在真实世界里的失败模式。一个指标体系如果跑了一整轮迭代却一个失败模式都没暴露那它不是一个好的评测体系它只是一个大号计算器。第二场景驱动评测的核心不是分类而是识别哪些场景对决策最敏感。分类只是手段它最终要服务于一个目标——让你知道哪个场景里预测器的误差会直接传导为规划器的保守绕行、急刹或冒险动作。一切不服务于这个目标的场景切片都是在给评测系统增加噪音。第三评测体系是一个活体不是一块石碑。随着预测模型的能力提升和新场景数据的积累场景标签体系、指标权重和门禁规则都需要按季度定期审视和调整。上一季度制定的严格门禁下一季度可能就不再合理因为模型能力整体上了一个台阶刹车距离、换道成功率这些底层分布发生了变化门禁自然要跟着移动。如果你正在搭建预测器评测体系我的建议是不要一上来就追求大而全先选两个决策敏感场景比如无保护左转和匝道汇入把从场景定义到指标计算到失败案例可视化的链路彻底跑通再逐步扩展场景版图和指标维度。这比一开始就重兵投入、铺得太大、最后复盘发现哪个层级都不够深要有效得多。毕竟量度一个有价值的维度远远好过量度十个无关痛痒的维度。
