企业官网建设流程全解析

自动驾驶轨迹预测模型的评估，长期以来被几个数字统治着：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 场景分类与权重分配

切片和过滤完成后，用前面说的多维度标签体系给每个片段打标签。打标签的过程可以并行化，用规则引擎跑一遍，再用聚类补充，最后人工抽检。抽检比例不用太高，百分之五到百分之十就够，重点是看规则和聚类有没有明显的误判。

标签打完，就可以分配权重了。我通常会用一张权重表来管理，横轴是风险等级，纵轴是场景稀有度，交叉点就是权重值。比如高风险加高稀有度权重设为十，高风险加低稀有度设为五，中风险加高稀有度设为三，以此类推。这张表不是一成不变的，每次评估结果出来之后，如果发现某个场景子集的指标和实际闭环表现严重不符，就要回头调整权重。

提示：权重表只是起点，不要把它当成真理。每次评估后都要用闭环结果反向校验权重是否合理，不合理就调。

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. 一些个人体会

场景驱动评估这件事，技术上的难点其实都能克服，真正的挑战在于观念转变。很多团队习惯了看一个数字排名，突然要接受一套多维度的、带权重的评估体系，会觉得麻烦、不直观。但只要你经历过一次"平均指标很好但实车表现拉胯"的事故，就会明白这种麻烦是值得的。

我自己的经验是，评估体系的建设要循序渐进。不要一上来就搞一套特别复杂的标签体系和权重方案，先从三五个核心场景开始，把流程跑通，让团队看到价值，再逐步扩展。一开始就追求大而全，往往推不动。

另外，评估指标不要太多。指标太多会分散注意力，而且不同指标之间可能相互矛盾，反而让人无所适从。我一般控制在五到八个核心指标，每个指标都有明确的物理意义和工程含义，多了就砍。

最后说一个容易被忽视的点：评估结果要定期回顾。不是评估完就完了，而是要定期把历史评估结果拿出来对比，看模型是在进步还是在原地踏步，看哪些场景一直是短板。这种纵向对比往往比单次评估更有价值，因为它能揭示出趋势性的问题。我一般每个月做一次回顾，把过去几个月的评估结果拉出来画趋势图，哪些指标在涨、哪些在跌，一目了然。这个习惯帮我提前发现了好几次模型性能的隐性退化，都是在还没造成严重后果之前就介入处理了。