场景驱动评测：轨迹预测模型从跑分到上路的落地实践

1. 为什么“跑分高”的轨迹预测模型一上路就露馅

做过自动驾驶轨迹预测的朋友大概都有过这种体验：论文里在Argoverse 2或者nuScenes上刷到minADE 0.6、minFDE 1.1，Miss Rate低得漂亮，评审看了都说好。结果一上实车或者一进闭环仿真，该刹不住还是刹不住，该犹豫还是犹豫，甚至在一些人类司机觉得“这有什么难”的场景里直接摆烂。问题出在哪？不是模型不行，是评测方式本身就在骗人。

轨迹预测这个任务，本质上是在回答一个概率问题：周围这些车、人、自行车，接下来几秒可能往哪儿走？学术界的标准做法是把数据集切成训练集和验证集，然后在验证集上算一堆基于位移误差的指标。这套流程看起来很科学，但它有一个致命的隐含假设——验证集里的场景分布和真实世界一样，而且每个场景的重要性相同。这个假设在现实中根本不成立。

我举个具体的例子。高速跟车场景占了公开数据集里相当大的比例，这种场景下所有车的运动模式高度重复，模型只要学会“保持当前车道、速度微调”就能拿到很低的误差。但真正决定自动驾驶系统安全性的，是那些低频但高风险的场景：无保护左转时对向直行车流的间隙判断、行人从遮挡物后突然窜出、施工区域锥桶引导下的非标准变道。这些场景在验证集里可能只占百分之几，但它们才是真正需要被测量的东西。

Scenario-Driven Evaluation（场景驱动评测）要解决的就是这个问题。它不再把验证集当成一个均匀的、无差别的整体，而是先把场景按照语义和风险等级拆解成一个个有明确边界的“场景单元”，然后在这些单元内部去评估预测器的表现。这样做的好处是，你能清楚地看到模型在“无保护左转”这个场景族里到底行不行，而不是被高速跟车的漂亮数字拉高了平均分。

这套思路适合谁？如果你是在做自动驾驶预测模块的工程师，或者是在做相关研究但发现论文指标和实际表现对不上，又或者你是做仿真评测平台的产品/技术负责人，那这套东西值得你花时间吃透。它不要求你重新训练模型，但要求你重新思考“什么叫预测得好”。

2. 场景驱动评测的整体设计思路拆解

2.1 从“平均误差”到“场景切片”的范式转换

传统评测的核心逻辑是：把所有样本的误差加起来求平均。这个逻辑的问题在于，它默认所有样本对系统的价值是等同的。但在自动驾驶里，一个导致急刹的预测错误和一个在空旷高速上多偏了半米的预测错误，代价完全不在一个量级。

场景驱动评测的做法是先分桶，再评估。具体来说，它把验证集里的每一个片段（segment）打上场景标签，比如“无保护左转”“环岛汇入”“行人横穿”“施工区绕行”等等。然后对每个场景桶单独计算指标，最后再根据场景的风险权重做一个加权汇总。这个加权汇总的分数，才更接近“这个预测器在真实世界里有多可靠”。

这里的关键设计决策是：场景标签怎么来？常见的有三种路径。第一种是用数据集自带的标注，比如nuScenes有场景描述，Argoverse有部分场景分类。第二种是用规则引擎自动打标，比如根据自车轨迹的曲率、周围交通参与者的交互密度、交通灯状态等特征来判定。第三种是人工标注一小部分高价值场景，然后用这个标注集去训练一个场景分类器，再对全量数据打标。实际落地时，通常是规则引擎打底，人工标注做校验和补充。

2.2 为什么不能只看minADE和minFDE

minADE和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。标准做法是K=6或K=10。K越大，minADE越低，但计算成本越高，而且分布指标会变差。我通常会在K=6和K=10之间做消融，看哪个在场景加权指标上更好。

场景权重的归一化。权重需要归一化，使得所有场景的权重之和为1。这样加权汇总的指标才能和传统指标在量级上可比。

置信区间的计算。对于每个场景族，用bootstrap方法估计指标的95%置信区间。如果某个场景族的置信区间太宽，说明样本量不够，需要合并或补充数据。

5. 常见问题与排查技巧实录

5.1 场景标签不准怎么办

这是最常见的问题。规则引擎打出来的标签，人工一看发现错得离谱。排查思路是：

• 先看特征计算是否正确。很多标签错误其实是特征计算错误导致的。比如航向角变化率算错了，导致弯道被误判为直道。
• 再看规则阈值是否合理。阈值太松会导致误报，太紧会导致漏报。可以用一小部分人工标注数据来调阈值。
• 最后考虑用学习的方法替代规则。如果规则怎么调都不满意，可以训练一个场景分类器。但要注意，分类器的训练数据必须来自人工标注，不能自己标自己。

5.2 某些场景族样本太少

低频高风险场景的样本量往往不够。解决办法有几个：

• 合并相似场景族。比如把“无保护左转”和“无保护右转”合并成“无保护转向”。
• 用仿真补充数据。在仿真里复现这些场景，生成大量变体。但要注意仿真数据和真实数据的分布差异。
• 用重采样。在训练时对稀有场景过采样，但在评测时不要过采样，否则指标会失真。

5.3 加权汇总的分数和直觉不符

有时候加权汇总的分数很高，但你知道模型在某些关键场景上表现很差。这通常是因为权重设置不合理。排查方法是：

• 检查权重是否被高频场景主导。如果高速跟车占了80%的权重，那汇总分数基本反映的就是高速跟车的表现。
• 单独看关键场景的指标。不要只看汇总分数，要把每个场景族的指标都列出来。
• 考虑用最差场景指标。除了加权平均，还可以看“最差场景的minADE”，这能反映模型的短板。

5.4 闭环评测和开环评测结果不一致

开环评测（只算位移误差）和闭环评测（接入规划器跑仿真）的结果经常不一致。原因通常是：

• 开环评测忽略了预测分布的影响。规划器用的是整个分布，不是最好的那条轨迹。
• 开环评测没有考虑预测的时间一致性。闭环里预测是滚动进行的，前后帧的预测如果不一致，规划器会震荡。
• 开环评测没有考虑规划器的鲁棒性。有些规划器对预测误差不敏感，有些则非常敏感。

解决办法是：以闭环评测为准，但用开环评测做快速迭代。开环评测便宜、快，适合日常开发；闭环评测贵、慢，适合里程碑验证。

5.5 常见问题速查表

实操心得：我建议在评测报告里，除了汇总分数，一定要附上每个场景族的指标和样本量。这样看报告的人能自己判断哪些结论可信，哪些还需要更多数据。

6. 场景驱动评测的扩展与落地建议

6.1 从离线评测到在线监控

场景驱动评测不仅适用于离线评估，还可以扩展到在线监控。具体做法是：在实车或仿真运行时，实时给当前场景打标签，然后监控预测器在该场景下的表现。如果某个场景的指标突然下降，就触发告警。

这套在线监控的价值在于，它能发现离线评测发现不了的问题。比如模型在某个特定路口总是预测不准，但这个问题在离线数据集里因为样本太少而被平均掉了。在线监控能捕捉到这种长尾问题。

6.2 和主动学习结合

场景驱动评测的另一个扩展方向是和主动学习结合。既然你能识别出模型表现差的场景族，那就可以针对性地采集或标注这些场景的数据，然后做增量训练。这比随机采样高效得多。

具体流程是：先用场景驱动评测找出短板场景，然后在这些场景里找模型不确定性最高的样本，优先标注这些样本，再微调模型。这个循环跑几轮，模型在关键场景上的表现会有明显提升。

6.3 工具链和基础设施

如果你打算把场景驱动评测做成常态化的工作，建议尽早搭建工具链。核心组件包括：

• 场景标签服务：输入片段，输出场景标签和权重。
• 评测计算服务：输入预测结果和标签，输出分场景指标。
• 可视化面板：展示各场景族的指标、样本量、置信区间。
• 回归检测：每次模型更新后自动跑评测，和基线对比。

这些组件不需要一开始就做得很完善，但要有意识地积累。我见过很多团队每次评测都靠手写脚本，效率低还容易出错。

6.4 一些个人体会

我在实际项目里推这套东西的时候，最大的阻力不是技术，而是习惯。大家习惯了看一个汇总数字，突然要看成百上千个分场景数字，第一反应是“太复杂了”。但只要你坚持用几次，就会发现分场景的视角能帮你更快定位问题。

另一个体会是，场景定义不要追求一步到位。我一开始想设计一个完美的场景分类体系，结果花了几个月还没落地。后来改成先用粗糙的规则跑起来，再逐步迭代，反而推进得快。场景驱动评测本身就是一个需要持续打磨的东西，不要指望一次做对。

最后再分享一个小技巧：在评测报告里，除了数字，一定要附上每个场景族的典型可视化案例。一张图胜过一千个数字，尤其是给非技术背景的人看的时候。