1. 为什么“跑分高”的轨迹预测模型一上路就露馅做过自动驾驶轨迹预测的朋友大概都有过这种体验论文里在Argoverse 2或者nuScenes上刷到minADE 0.6、minFDE 1.1Miss Rate低得漂亮评审看了都说好。结果一上实车或者一进闭环仿真该刹不住还是刹不住该犹豫还是犹豫甚至在一些人类司机觉得“这有什么难”的场景里直接摆烂。问题出在哪不是模型不行是评测方式本身就在骗人。轨迹预测这个任务本质上是在回答一个概率问题周围这些车、人、自行车接下来几秒可能往哪儿走学术界的标准做法是把数据集切成训练集和验证集然后在验证集上算一堆基于位移误差的指标。这套流程看起来很科学但它有一个致命的隐含假设——验证集里的场景分布和真实世界一样而且每个场景的重要性相同。这个假设在现实中根本不成立。我举个具体的例子。高速跟车场景占了公开数据集里相当大的比例这种场景下所有车的运动模式高度重复模型只要学会“保持当前车道、速度微调”就能拿到很低的误差。但真正决定自动驾驶系统安全性的是那些低频但高风险的场景无保护左转时对向直行车流的间隙判断、行人从遮挡物后突然窜出、施工区域锥桶引导下的非标准变道。这些场景在验证集里可能只占百分之几但它们才是真正需要被测量的东西。Scenario-Driven Evaluation场景驱动评测要解决的就是这个问题。它不再把验证集当成一个均匀的、无差别的整体而是先把场景按照语义和风险等级拆解成一个个有明确边界的“场景单元”然后在这些单元内部去评估预测器的表现。这样做的好处是你能清楚地看到模型在“无保护左转”这个场景族里到底行不行而不是被高速跟车的漂亮数字拉高了平均分。这套思路适合谁如果你是在做自动驾驶预测模块的工程师或者是在做相关研究但发现论文指标和实际表现对不上又或者你是做仿真评测平台的产品/技术负责人那这套东西值得你花时间吃透。它不要求你重新训练模型但要求你重新思考“什么叫预测得好”。2. 场景驱动评测的整体设计思路拆解2.1 从“平均误差”到“场景切片”的范式转换传统评测的核心逻辑是把所有样本的误差加起来求平均。这个逻辑的问题在于它默认所有样本对系统的价值是等同的。但在自动驾驶里一个导致急刹的预测错误和一个在空旷高速上多偏了半米的预测错误代价完全不在一个量级。场景驱动评测的做法是先分桶再评估。具体来说它把验证集里的每一个片段segment打上场景标签比如“无保护左转”“环岛汇入”“行人横穿”“施工区绕行”等等。然后对每个场景桶单独计算指标最后再根据场景的风险权重做一个加权汇总。这个加权汇总的分数才更接近“这个预测器在真实世界里有多可靠”。这里的关键设计决策是场景标签怎么来常见的有三种路径。第一种是用数据集自带的标注比如nuScenes有场景描述Argoverse有部分场景分类。第二种是用规则引擎自动打标比如根据自车轨迹的曲率、周围交通参与者的交互密度、交通灯状态等特征来判定。第三种是人工标注一小部分高价值场景然后用这个标注集去训练一个场景分类器再对全量数据打标。实际落地时通常是规则引擎打底人工标注做校验和补充。2.2 为什么不能只看minADE和minFDEminADE和minFDE是轨迹预测领域最常用的两个指标。minADE是模型输出K条候选轨迹中与真实轨迹平均位移误差最小的那条的平均值minFDE是终点位移误差。这两个指标的问题在于它们只关心位移不关心分布也不关心场景语义。我举个极端的例子。假设一个预测器在无保护左转场景下输出了K条轨迹其中有一条恰好和真实轨迹很接近但另外K-1条全部指向完全不合理的方向。minADE会只取最好的那条来算所以分数很好看。但实际部署时下游的规划模块拿到的是整个分布如果分布里充斥着垃圾候选规划模块很可能会选错。所以场景驱动评测通常会补充几类指标。第一类是分布质量指标比如NLL负对数似然或者Brier score衡量模型输出的概率分布是否校准。第二类是场景特定指标比如在行人横穿场景下关注模型是否给“行人突然加速”这个模式分配了足够的概率质量。第三类是闭环影响指标把预测结果喂给一个固定的规划器看规划器的行为是否安全、舒适、高效。2.3 场景权重的设定逻辑场景驱动评测的另一个核心设计是场景权重。不是所有场景都同等重要但怎么定权重是有讲究的。我见过几种做法频率加权按场景在真实数据中的出现频率来加权。这适合评估“平均表现”但会低估低频高风险场景。风险加权按场景的事故率或严重程度来加权。这适合安全评估但可能过度关注极端情况。混合加权频率和风险的乘积或某种组合。这是最实用的做法但需要调参。我的经验是不要试图找一个“客观正确”的权重。权重应该反映你的评测目的。如果你是在做量产前的安全验证风险权重要高如果你是在做模型迭代的日常评估频率加权更合适。关键是要把权重显式地写出来让所有看评测报告的人都知道你在优化什么。3. 核心细节解析与实操要点3.1 场景标签体系怎么搭场景标签体系是整套评测的地基。搭得不好后面所有分析都是空中楼阁。我的建议是从三个维度来组织标签第一个维度是道路结构。比如直道、弯道、交叉口、环岛、匝道、停车场。这个维度决定了交通参与者的基本运动约束。第二个维度是交互类型。比如跟车、换道、汇入、交叉、对向、行人交互。这个维度决定了预测器需要处理的核心难点。第三个维度是风险等级。比如常规、注意、危险。这个维度可以基于TTC碰撞时间、DRAC减速度需求等指标自动计算。这三个维度组合起来就能形成一个比较完整的场景描述。比如“交叉口-对向-危险”就是一个无保护左转时对向有直行车逼近的场景。实际使用时不需要把所有组合都列出来而是根据你的ODD运行设计域和业务重点选出几十个核心场景族就够了。注意场景标签的粒度不要太细。我见过有人把场景分成几百类结果每一类只有几个样本统计上完全没有意义。一般来说每个场景族至少有几百到几千个片段才能算出稳定的指标。3.2 评测指标的选择与计算在场景驱动评测框架下指标的选择要分层次。第一层是基础位移指标minADE、minFDE、Miss Rate还是要算的因为它们便于和已有工作对比。但不要只看这些。第二层是分布指标。我推荐至少算两个NLL和ECE期望校准误差。NLL衡量模型给真实轨迹分配的概率密度ECE衡量模型输出的置信度和实际准确率是否匹配。这两个指标能暴露很多minADE看不出来的问题。第三层是场景特定指标。这个需要针对每个场景族单独设计。比如在换道场景下可以算“目标车道后车是否被正确预测为减速让行”在行人场景下可以算“行人突然加速模式的召回率”。这些指标没有统一公式需要结合场景语义来定义。第四层是闭环指标。如果条件允许把预测结果接入一个固定的规划器在仿真里跑一遍统计急刹次数、碰撞次数、通行效率等。这是最接近真实表现的评估但计算成本也最高。3.3 数据切分的坑场景驱动评测对数据切分有额外要求。传统做法是随机切分但这样会导致同一个场景的不同片段被分到训练集和验证集造成信息泄漏。正确的做法是按场景切分确保验证集里的场景族在训练集里没有完全相同的实例。更严格的做法是按地理区域切分。比如用城市A的数据训练用城市B的数据验证。这能更好地评估模型的泛化能力。但这样做会导致验证集里的场景分布和训练集差异很大需要额外处理。我的实操建议是至少做到按片段切分确保同一个连续驾驶片段不会同时出现在训练和验证里。如果数据量允许再进一步做按场景族或地理区域的切分。4. 实操过程与核心环节实现4.1 从原始数据到场景标签的完整流水线假设你手头有一个标准的轨迹预测数据集比如Argoverse 2或者你自己采集的数据。下面是我实际用过的一条流水线。第一步片段提取与特征计算。把原始数据切成固定时长的片段比如历史2秒、未来6秒。对每个片段计算自车和周围参与者的运动学特征速度、加速度、航向角变化率、曲率等。同时计算交互特征最近距离、TTC、相对速度等。第二步规则引擎打标。用一组规则给每个片段打上初始标签。比如def label_intersection(features): if features[distance_to_intersection] 30 and features[speed] 8: return intersection return None def label_cut_in(features): if features[lateral_velocity] 0.5 and features[longitudinal_gap] 20: return cut_in return None规则引擎的好处是可解释、可调试坏处是覆盖不全。所以需要下一步。第三步聚类补充。对规则引擎没打上标签的片段用无监督聚类比如K-means或者DBSCAN在特征空间里找自然分组。然后人工看一下每个聚类中心对应的典型场景给它起个名字。第四步人工校验。从每个场景族里随机抽几十个片段人工确认标签是否正确。这一步不能省我见过太多规则引擎打出离谱标签的案例。第五步场景权重分配。根据你的评测目的给每个场景族分配权重。我通常会用频率和风险的几何平均weight sqrt(frequency * risk_score)。risk_score可以用该场景族在真实数据中的事故率来近似。4.2 评测代码的核心结构下面是一个简化的评测框架代码结构用Python写的你可以直接参考class ScenarioDrivenEvaluator: def __init__(self, scenario_weights): self.scenario_weights scenario_weights self.results {} def evaluate(self, predictor, dataloader): for batch in dataloader: scenarios batch[scenario_labels] predictions predictor(batch[history]) ground_truth batch[future] for scenario in set(scenarios): mask scenarios scenario metrics self.compute_metrics( predictions[mask], ground_truth[mask] ) self.results.setdefault(scenario, []).append(metrics) return self.aggregate() def compute_metrics(self, pred, gt): return { minADE: compute_min_ade(pred, gt), minFDE: compute_min_fde(pred, gt), NLL: compute_nll(pred, gt), MissRate: compute_miss_rate(pred, gt) } def aggregate(self): weighted_scores {} for scenario, metrics_list in self.results.items(): avg_metrics average(metrics_list) weight self.scenario_weights.get(scenario, 1.0) for key, value in avg_metrics.items(): weighted_scores[key] weighted_scores.get(key, 0) weight * value return weighted_scores这个框架的核心思想是按场景分组计算再按权重汇总。实际使用时你还需要加上置信区间估计因为有些场景族的样本量可能不够大。4.3 参数选择与计算过程场景驱动评测里有几个关键参数需要你根据实际情况来定。历史时长和未来时长。历史时长决定了模型能看到多少上下文未来时长决定了预测的难度。常见的选择是历史2秒、未来3秒或6秒。我的经验是如果做城市道路预测未来3秒足够覆盖大多数决策需求如果做高速预测未来6秒更合适因为高速上决策的提前量更大。候选轨迹数量K。标准做法是K6或K10。K越大minADE越低但计算成本越高而且分布指标会变差。我通常会在K6和K10之间做消融看哪个在场景加权指标上更好。场景权重的归一化。权重需要归一化使得所有场景的权重之和为1。这样加权汇总的指标才能和传统指标在量级上可比。置信区间的计算。对于每个场景族用bootstrap方法估计指标的95%置信区间。如果某个场景族的置信区间太宽说明样本量不够需要合并或补充数据。5. 常见问题与排查技巧实录5.1 场景标签不准怎么办这是最常见的问题。规则引擎打出来的标签人工一看发现错得离谱。排查思路是先看特征计算是否正确。很多标签错误其实是特征计算错误导致的。比如航向角变化率算错了导致弯道被误判为直道。再看规则阈值是否合理。阈值太松会导致误报太紧会导致漏报。可以用一小部分人工标注数据来调阈值。最后考虑用学习的方法替代规则。如果规则怎么调都不满意可以训练一个场景分类器。但要注意分类器的训练数据必须来自人工标注不能自己标自己。5.2 某些场景族样本太少低频高风险场景的样本量往往不够。解决办法有几个合并相似场景族。比如把“无保护左转”和“无保护右转”合并成“无保护转向”。用仿真补充数据。在仿真里复现这些场景生成大量变体。但要注意仿真数据和真实数据的分布差异。用重采样。在训练时对稀有场景过采样但在评测时不要过采样否则指标会失真。5.3 加权汇总的分数和直觉不符有时候加权汇总的分数很高但你知道模型在某些关键场景上表现很差。这通常是因为权重设置不合理。排查方法是检查权重是否被高频场景主导。如果高速跟车占了80%的权重那汇总分数基本反映的就是高速跟车的表现。单独看关键场景的指标。不要只看汇总分数要把每个场景族的指标都列出来。考虑用最差场景指标。除了加权平均还可以看“最差场景的minADE”这能反映模型的短板。5.4 闭环评测和开环评测结果不一致开环评测只算位移误差和闭环评测接入规划器跑仿真的结果经常不一致。原因通常是开环评测忽略了预测分布的影响。规划器用的是整个分布不是最好的那条轨迹。开环评测没有考虑预测的时间一致性。闭环里预测是滚动进行的前后帧的预测如果不一致规划器会震荡。开环评测没有考虑规划器的鲁棒性。有些规划器对预测误差不敏感有些则非常敏感。解决办法是以闭环评测为准但用开环评测做快速迭代。开环评测便宜、快适合日常开发闭环评测贵、慢适合里程碑验证。5.5 常见问题速查表问题现象可能原因排查方法解决思路场景标签错乱特征计算错误抽查特征值修正特征计算逻辑稀有场景指标波动大样本量不足看置信区间合并场景或补充数据加权分数虚高权重被高频场景主导检查权重分布调整权重或看分场景指标开闭环结果不一致分布质量差算NLL和ECE改进模型分布输出某些场景全部Miss场景定义太窄看场景内样本放宽场景定义或合并实操心得我建议在评测报告里除了汇总分数一定要附上每个场景族的指标和样本量。这样看报告的人能自己判断哪些结论可信哪些还需要更多数据。6. 场景驱动评测的扩展与落地建议6.1 从离线评测到在线监控场景驱动评测不仅适用于离线评估还可以扩展到在线监控。具体做法是在实车或仿真运行时实时给当前场景打标签然后监控预测器在该场景下的表现。如果某个场景的指标突然下降就触发告警。这套在线监控的价值在于它能发现离线评测发现不了的问题。比如模型在某个特定路口总是预测不准但这个问题在离线数据集里因为样本太少而被平均掉了。在线监控能捕捉到这种长尾问题。6.2 和主动学习结合场景驱动评测的另一个扩展方向是和主动学习结合。既然你能识别出模型表现差的场景族那就可以针对性地采集或标注这些场景的数据然后做增量训练。这比随机采样高效得多。具体流程是先用场景驱动评测找出短板场景然后在这些场景里找模型不确定性最高的样本优先标注这些样本再微调模型。这个循环跑几轮模型在关键场景上的表现会有明显提升。6.3 工具链和基础设施如果你打算把场景驱动评测做成常态化的工作建议尽早搭建工具链。核心组件包括场景标签服务输入片段输出场景标签和权重。评测计算服务输入预测结果和标签输出分场景指标。可视化面板展示各场景族的指标、样本量、置信区间。回归检测每次模型更新后自动跑评测和基线对比。这些组件不需要一开始就做得很完善但要有意识地积累。我见过很多团队每次评测都靠手写脚本效率低还容易出错。6.4 一些个人体会我在实际项目里推这套东西的时候最大的阻力不是技术而是习惯。大家习惯了看一个汇总数字突然要看成百上千个分场景数字第一反应是“太复杂了”。但只要你坚持用几次就会发现分场景的视角能帮你更快定位问题。另一个体会是场景定义不要追求一步到位。我一开始想设计一个完美的场景分类体系结果花了几个月还没落地。后来改成先用粗糙的规则跑起来再逐步迭代反而推进得快。场景驱动评测本身就是一个需要持续打磨的东西不要指望一次做对。最后再分享一个小技巧在评测报告里除了数字一定要附上每个场景族的典型可视化案例。一张图胜过一千个数字尤其是给非技术背景的人看的时候。
1. 为什么“跑分高”的轨迹预测模型一上路就露馅做过自动驾驶轨迹预测的朋友大概都有过这种体验论文里在Argoverse 2或者nuScenes上刷到minADE 0.6、minFDE 1.1Miss Rate低得漂亮评审看了都说好。结果一上实车或者一进闭环仿真该刹不住还是刹不住该犹豫还是犹豫甚至在一些人类司机觉得“这有什么难”的场景里直接摆烂。问题出在哪不是模型不行是评测方式本身就在骗人。轨迹预测这个任务本质上是在回答一个概率问题周围这些车、人、自行车接下来几秒可能往哪儿走学术界的标准做法是把数据集切成训练集和验证集然后在验证集上算一堆基于位移误差的指标。这套流程看起来很科学但它有一个致命的隐含假设——验证集里的场景分布和真实世界一样而且每个场景的重要性相同。这个假设在现实中根本不成立。我举个具体的例子。高速跟车场景占了公开数据集里相当大的比例这种场景下所有车的运动模式高度重复模型只要学会“保持当前车道、速度微调”就能拿到很低的误差。但真正决定自动驾驶系统安全性的是那些低频但高风险的场景无保护左转时对向直行车流的间隙判断、行人从遮挡物后突然窜出、施工区域锥桶引导下的非标准变道。这些场景在验证集里可能只占百分之几但它们才是真正需要被测量的东西。Scenario-Driven Evaluation场景驱动评测要解决的就是这个问题。它不再把验证集当成一个均匀的、无差别的整体而是先把场景按照语义和风险等级拆解成一个个有明确边界的“场景单元”然后在这些单元内部去评估预测器的表现。这样做的好处是你能清楚地看到模型在“无保护左转”这个场景族里到底行不行而不是被高速跟车的漂亮数字拉高了平均分。这套思路适合谁如果你是在做自动驾驶预测模块的工程师或者是在做相关研究但发现论文指标和实际表现对不上又或者你是做仿真评测平台的产品/技术负责人那这套东西值得你花时间吃透。它不要求你重新训练模型但要求你重新思考“什么叫预测得好”。2. 场景驱动评测的整体设计思路拆解2.1 从“平均误差”到“场景切片”的范式转换传统评测的核心逻辑是把所有样本的误差加起来求平均。这个逻辑的问题在于它默认所有样本对系统的价值是等同的。但在自动驾驶里一个导致急刹的预测错误和一个在空旷高速上多偏了半米的预测错误代价完全不在一个量级。场景驱动评测的做法是先分桶再评估。具体来说它把验证集里的每一个片段segment打上场景标签比如“无保护左转”“环岛汇入”“行人横穿”“施工区绕行”等等。然后对每个场景桶单独计算指标最后再根据场景的风险权重做一个加权汇总。这个加权汇总的分数才更接近“这个预测器在真实世界里有多可靠”。这里的关键设计决策是场景标签怎么来常见的有三种路径。第一种是用数据集自带的标注比如nuScenes有场景描述Argoverse有部分场景分类。第二种是用规则引擎自动打标比如根据自车轨迹的曲率、周围交通参与者的交互密度、交通灯状态等特征来判定。第三种是人工标注一小部分高价值场景然后用这个标注集去训练一个场景分类器再对全量数据打标。实际落地时通常是规则引擎打底人工标注做校验和补充。2.2 为什么不能只看minADE和minFDEminADE和minFDE是轨迹预测领域最常用的两个指标。minADE是模型输出K条候选轨迹中与真实轨迹平均位移误差最小的那条的平均值minFDE是终点位移误差。这两个指标的问题在于它们只关心位移不关心分布也不关心场景语义。我举个极端的例子。假设一个预测器在无保护左转场景下输出了K条轨迹其中有一条恰好和真实轨迹很接近但另外K-1条全部指向完全不合理的方向。minADE会只取最好的那条来算所以分数很好看。但实际部署时下游的规划模块拿到的是整个分布如果分布里充斥着垃圾候选规划模块很可能会选错。所以场景驱动评测通常会补充几类指标。第一类是分布质量指标比如NLL负对数似然或者Brier score衡量模型输出的概率分布是否校准。第二类是场景特定指标比如在行人横穿场景下关注模型是否给“行人突然加速”这个模式分配了足够的概率质量。第三类是闭环影响指标把预测结果喂给一个固定的规划器看规划器的行为是否安全、舒适、高效。2.3 场景权重的设定逻辑场景驱动评测的另一个核心设计是场景权重。不是所有场景都同等重要但怎么定权重是有讲究的。我见过几种做法频率加权按场景在真实数据中的出现频率来加权。这适合评估“平均表现”但会低估低频高风险场景。风险加权按场景的事故率或严重程度来加权。这适合安全评估但可能过度关注极端情况。混合加权频率和风险的乘积或某种组合。这是最实用的做法但需要调参。我的经验是不要试图找一个“客观正确”的权重。权重应该反映你的评测目的。如果你是在做量产前的安全验证风险权重要高如果你是在做模型迭代的日常评估频率加权更合适。关键是要把权重显式地写出来让所有看评测报告的人都知道你在优化什么。3. 核心细节解析与实操要点3.1 场景标签体系怎么搭场景标签体系是整套评测的地基。搭得不好后面所有分析都是空中楼阁。我的建议是从三个维度来组织标签第一个维度是道路结构。比如直道、弯道、交叉口、环岛、匝道、停车场。这个维度决定了交通参与者的基本运动约束。第二个维度是交互类型。比如跟车、换道、汇入、交叉、对向、行人交互。这个维度决定了预测器需要处理的核心难点。第三个维度是风险等级。比如常规、注意、危险。这个维度可以基于TTC碰撞时间、DRAC减速度需求等指标自动计算。这三个维度组合起来就能形成一个比较完整的场景描述。比如“交叉口-对向-危险”就是一个无保护左转时对向有直行车逼近的场景。实际使用时不需要把所有组合都列出来而是根据你的ODD运行设计域和业务重点选出几十个核心场景族就够了。注意场景标签的粒度不要太细。我见过有人把场景分成几百类结果每一类只有几个样本统计上完全没有意义。一般来说每个场景族至少有几百到几千个片段才能算出稳定的指标。3.2 评测指标的选择与计算在场景驱动评测框架下指标的选择要分层次。第一层是基础位移指标minADE、minFDE、Miss Rate还是要算的因为它们便于和已有工作对比。但不要只看这些。第二层是分布指标。我推荐至少算两个NLL和ECE期望校准误差。NLL衡量模型给真实轨迹分配的概率密度ECE衡量模型输出的置信度和实际准确率是否匹配。这两个指标能暴露很多minADE看不出来的问题。第三层是场景特定指标。这个需要针对每个场景族单独设计。比如在换道场景下可以算“目标车道后车是否被正确预测为减速让行”在行人场景下可以算“行人突然加速模式的召回率”。这些指标没有统一公式需要结合场景语义来定义。第四层是闭环指标。如果条件允许把预测结果接入一个固定的规划器在仿真里跑一遍统计急刹次数、碰撞次数、通行效率等。这是最接近真实表现的评估但计算成本也最高。3.3 数据切分的坑场景驱动评测对数据切分有额外要求。传统做法是随机切分但这样会导致同一个场景的不同片段被分到训练集和验证集造成信息泄漏。正确的做法是按场景切分确保验证集里的场景族在训练集里没有完全相同的实例。更严格的做法是按地理区域切分。比如用城市A的数据训练用城市B的数据验证。这能更好地评估模型的泛化能力。但这样做会导致验证集里的场景分布和训练集差异很大需要额外处理。我的实操建议是至少做到按片段切分确保同一个连续驾驶片段不会同时出现在训练和验证里。如果数据量允许再进一步做按场景族或地理区域的切分。4. 实操过程与核心环节实现4.1 从原始数据到场景标签的完整流水线假设你手头有一个标准的轨迹预测数据集比如Argoverse 2或者你自己采集的数据。下面是我实际用过的一条流水线。第一步片段提取与特征计算。把原始数据切成固定时长的片段比如历史2秒、未来6秒。对每个片段计算自车和周围参与者的运动学特征速度、加速度、航向角变化率、曲率等。同时计算交互特征最近距离、TTC、相对速度等。第二步规则引擎打标。用一组规则给每个片段打上初始标签。比如def label_intersection(features): if features[distance_to_intersection] 30 and features[speed] 8: return intersection return None def label_cut_in(features): if features[lateral_velocity] 0.5 and features[longitudinal_gap] 20: return cut_in return None规则引擎的好处是可解释、可调试坏处是覆盖不全。所以需要下一步。第三步聚类补充。对规则引擎没打上标签的片段用无监督聚类比如K-means或者DBSCAN在特征空间里找自然分组。然后人工看一下每个聚类中心对应的典型场景给它起个名字。第四步人工校验。从每个场景族里随机抽几十个片段人工确认标签是否正确。这一步不能省我见过太多规则引擎打出离谱标签的案例。第五步场景权重分配。根据你的评测目的给每个场景族分配权重。我通常会用频率和风险的几何平均weight sqrt(frequency * risk_score)。risk_score可以用该场景族在真实数据中的事故率来近似。4.2 评测代码的核心结构下面是一个简化的评测框架代码结构用Python写的你可以直接参考class ScenarioDrivenEvaluator: def __init__(self, scenario_weights): self.scenario_weights scenario_weights self.results {} def evaluate(self, predictor, dataloader): for batch in dataloader: scenarios batch[scenario_labels] predictions predictor(batch[history]) ground_truth batch[future] for scenario in set(scenarios): mask scenarios scenario metrics self.compute_metrics( predictions[mask], ground_truth[mask] ) self.results.setdefault(scenario, []).append(metrics) return self.aggregate() def compute_metrics(self, pred, gt): return { minADE: compute_min_ade(pred, gt), minFDE: compute_min_fde(pred, gt), NLL: compute_nll(pred, gt), MissRate: compute_miss_rate(pred, gt) } def aggregate(self): weighted_scores {} for scenario, metrics_list in self.results.items(): avg_metrics average(metrics_list) weight self.scenario_weights.get(scenario, 1.0) for key, value in avg_metrics.items(): weighted_scores[key] weighted_scores.get(key, 0) weight * value return weighted_scores这个框架的核心思想是按场景分组计算再按权重汇总。实际使用时你还需要加上置信区间估计因为有些场景族的样本量可能不够大。4.3 参数选择与计算过程场景驱动评测里有几个关键参数需要你根据实际情况来定。历史时长和未来时长。历史时长决定了模型能看到多少上下文未来时长决定了预测的难度。常见的选择是历史2秒、未来3秒或6秒。我的经验是如果做城市道路预测未来3秒足够覆盖大多数决策需求如果做高速预测未来6秒更合适因为高速上决策的提前量更大。候选轨迹数量K。标准做法是K6或K10。K越大minADE越低但计算成本越高而且分布指标会变差。我通常会在K6和K10之间做消融看哪个在场景加权指标上更好。场景权重的归一化。权重需要归一化使得所有场景的权重之和为1。这样加权汇总的指标才能和传统指标在量级上可比。置信区间的计算。对于每个场景族用bootstrap方法估计指标的95%置信区间。如果某个场景族的置信区间太宽说明样本量不够需要合并或补充数据。5. 常见问题与排查技巧实录5.1 场景标签不准怎么办这是最常见的问题。规则引擎打出来的标签人工一看发现错得离谱。排查思路是先看特征计算是否正确。很多标签错误其实是特征计算错误导致的。比如航向角变化率算错了导致弯道被误判为直道。再看规则阈值是否合理。阈值太松会导致误报太紧会导致漏报。可以用一小部分人工标注数据来调阈值。最后考虑用学习的方法替代规则。如果规则怎么调都不满意可以训练一个场景分类器。但要注意分类器的训练数据必须来自人工标注不能自己标自己。5.2 某些场景族样本太少低频高风险场景的样本量往往不够。解决办法有几个合并相似场景族。比如把“无保护左转”和“无保护右转”合并成“无保护转向”。用仿真补充数据。在仿真里复现这些场景生成大量变体。但要注意仿真数据和真实数据的分布差异。用重采样。在训练时对稀有场景过采样但在评测时不要过采样否则指标会失真。5.3 加权汇总的分数和直觉不符有时候加权汇总的分数很高但你知道模型在某些关键场景上表现很差。这通常是因为权重设置不合理。排查方法是检查权重是否被高频场景主导。如果高速跟车占了80%的权重那汇总分数基本反映的就是高速跟车的表现。单独看关键场景的指标。不要只看汇总分数要把每个场景族的指标都列出来。考虑用最差场景指标。除了加权平均还可以看“最差场景的minADE”这能反映模型的短板。5.4 闭环评测和开环评测结果不一致开环评测只算位移误差和闭环评测接入规划器跑仿真的结果经常不一致。原因通常是开环评测忽略了预测分布的影响。规划器用的是整个分布不是最好的那条轨迹。开环评测没有考虑预测的时间一致性。闭环里预测是滚动进行的前后帧的预测如果不一致规划器会震荡。开环评测没有考虑规划器的鲁棒性。有些规划器对预测误差不敏感有些则非常敏感。解决办法是以闭环评测为准但用开环评测做快速迭代。开环评测便宜、快适合日常开发闭环评测贵、慢适合里程碑验证。5.5 常见问题速查表问题现象可能原因排查方法解决思路场景标签错乱特征计算错误抽查特征值修正特征计算逻辑稀有场景指标波动大样本量不足看置信区间合并场景或补充数据加权分数虚高权重被高频场景主导检查权重分布调整权重或看分场景指标开闭环结果不一致分布质量差算NLL和ECE改进模型分布输出某些场景全部Miss场景定义太窄看场景内样本放宽场景定义或合并实操心得我建议在评测报告里除了汇总分数一定要附上每个场景族的指标和样本量。这样看报告的人能自己判断哪些结论可信哪些还需要更多数据。6. 场景驱动评测的扩展与落地建议6.1 从离线评测到在线监控场景驱动评测不仅适用于离线评估还可以扩展到在线监控。具体做法是在实车或仿真运行时实时给当前场景打标签然后监控预测器在该场景下的表现。如果某个场景的指标突然下降就触发告警。这套在线监控的价值在于它能发现离线评测发现不了的问题。比如模型在某个特定路口总是预测不准但这个问题在离线数据集里因为样本太少而被平均掉了。在线监控能捕捉到这种长尾问题。6.2 和主动学习结合场景驱动评测的另一个扩展方向是和主动学习结合。既然你能识别出模型表现差的场景族那就可以针对性地采集或标注这些场景的数据然后做增量训练。这比随机采样高效得多。具体流程是先用场景驱动评测找出短板场景然后在这些场景里找模型不确定性最高的样本优先标注这些样本再微调模型。这个循环跑几轮模型在关键场景上的表现会有明显提升。6.3 工具链和基础设施如果你打算把场景驱动评测做成常态化的工作建议尽早搭建工具链。核心组件包括场景标签服务输入片段输出场景标签和权重。评测计算服务输入预测结果和标签输出分场景指标。可视化面板展示各场景族的指标、样本量、置信区间。回归检测每次模型更新后自动跑评测和基线对比。这些组件不需要一开始就做得很完善但要有意识地积累。我见过很多团队每次评测都靠手写脚本效率低还容易出错。6.4 一些个人体会我在实际项目里推这套东西的时候最大的阻力不是技术而是习惯。大家习惯了看一个汇总数字突然要看成百上千个分场景数字第一反应是“太复杂了”。但只要你坚持用几次就会发现分场景的视角能帮你更快定位问题。另一个体会是场景定义不要追求一步到位。我一开始想设计一个完美的场景分类体系结果花了几个月还没落地。后来改成先用粗糙的规则跑起来再逐步迭代反而推进得快。场景驱动评测本身就是一个需要持续打磨的东西不要指望一次做对。最后再分享一个小技巧在评测报告里除了数字一定要附上每个场景族的典型可视化案例。一张图胜过一千个数字尤其是给非技术背景的人看的时候。
