3. 评测指标体系概览

自动驾驶系统的评测不能只看“有没有撞车”，也不能只看“开得快不快”。一个可落地的评测指标体系，必须把系统行为拆解为多个相互制约的维度，并为每个维度定义可测量、可复现、可比较的指标。本节从安全性、舒适性、效率、合规性四个核心维度出发，说明指标的分类逻辑与层级结构，帮助读者建立“从维度到指标、从指标到阈值”的完整认知。

一、核心原理：为什么需要多维度指标体系

自动驾驶系统的目标不是单一最优，而是在安全底线之上，尽可能提升通行效率与乘坐体验，同时遵守交通法规。这四个维度之间存在天然的张力：过于保守的安全策略会降低效率，过于激进的效率优化会牺牲舒适性，而合规性又会对安全与效率同时施加约束。因此，评测指标体系本质上是一个多目标约束系统，而不是一个可以简单加权的分数。

从工程实现角度看，指标体系需要满足三个条件：第一，每个指标必须能从日志或仿真数据中自动计算；第二，指标之间尽量正交，避免重复惩罚同一类错误；第三，指标要能映射到具体的系统模块或设计决策，否则评测结果无法指导改进。

二、指标分类与层级结构

一个典型的自动驾驶评测指标体系可以分为三层：维度层、类别层和指标层。维度层对应安全性、舒适性、效率、合规性；类别层是对维度的进一步细分，例如安全性可分为碰撞风险、冲突事件、系统失效等；指标层则是可直接计算的量化值，例如碰撞时间、减速度峰值、通行时间、违章次数等。

上图展示了从维度层到指标层的映射关系。需要注意的是，同一指标可能同时影响多个维度。例如“急刹车次数”既属于安全性中的冲突事件，也属于舒适性中的纵向舒适问题。在工程实践中，通常会在指标定义时明确其主归属维度，避免重复统计。

三、方法流程：从场景到指标的计算链路

指标不是凭空产生的，它依赖于场景、数据和计算规则。一个完整的指标计算链路通常包括以下步骤：

1. 场景定义：确定测试场景，例如前车急刹、无保护左转、行人横穿等，并标注场景中的关键对象和事件。
2. 数据采集：从仿真或实车日志中提取自车轨迹、障碍物轨迹、信号灯状态、地图信息等。
3. 事件检测：根据规则识别冲突事件、违规事件、急动事件等，例如 TTC 小于阈值即触发冲突事件。
4. 指标计算：对每个事件或整个行程计算量化指标，如最小 TTC、最大减速度、平均速度等。
5. 聚合与报告：按维度、场景、里程等维度聚合，生成分层评测报告。

下面是一个简化的指标计算配置示例，用于说明指标定义中需要包含的关键字段：

metric:
  name: min_ttc
  dimension: safety
  category: collision_risk
  unit: second
  threshold: 1.5
  direction: higher_is_better
  description: "自车与最近冲突目标的最小碰撞时间"
  data_source: ["ego_trajectory", "object_trajectory"]
  event_trigger: "ttc < threshold"

该配置明确了指标的名称、所属维度、单位、阈值、优化方向和数据来源。在实际平台中，这类配置通常以 YAML 或 JSON 形式管理，便于版本控制和批量评测。

四、案例/场景：城市路口左转的指标表现

以城市无保护左转场景为例，假设自车需要在对向直行车流中寻找间隙完成左转。该场景下四个维度的指标表现如下：

维度	关键指标	典型阈值	本场景表现
安全性	最小 TTC、冲突事件数	TTC ≥ 1.5s	最小 TTC 1.8s，无冲突事件
舒适性	横向加速度峰值、jerk	横向加速度 ≤ 2.5 m/s²	横向加速度 2.1 m/s²，jerk 1.2 m/s³
效率	左转通行时间、等待时间	通行时间 ≤ 15s	通行时间 12.4s，等待 3.2s
合规性	是否压线、是否让行	违规次数 = 0	无违规，完成让行

从表中可以看出，该场景下自车在四个维度均满足阈值要求，但舒适性指标接近边界，说明横向控制仍有优化空间。如果只关注安全性，可能会忽略乘客体验的下降；如果只关注效率，可能会压缩安全间隙。因此，分层报告比单一总分更有指导意义。

五、误区与复盘

复盘时，建议按以下清单检查指标体系是否完整：

• 是否覆盖安全性、舒适性、效率、合规性四个维度？
• 每个指标是否有明确的单位、阈值和优化方向？
• 指标是否可以从现有数据中自动计算？
• 是否存在同一问题被多个指标重复统计？
• 阈值是否与场景、车速、道路类型匹配？
• 评测报告是否分层呈现，而非单一总分？