3. Hard Case概念与分类

在自动驾驶研发中，Hard Case（困难案例）并不是简单的“表现不好的场景”，而是指在当前系统能力、数据分布或评价体系下，导致感知、预测、规划或控制出现显著偏差、失效或高风险行为的特定场景片段。它通常具备三个特征：可复现的触发条件、明确的失效表现、以及可归因的系统环节。理解Hard Case的关键，在于把它从“感觉很难”转化为“可定义、可分类、可度量、可闭环”的工程对象。

一、Hard Case的核心原理：从“难”到“可工程化”

Hard Case之所以“难”，往往不是单一原因，而是场景复杂度、传感器退化、模型泛化不足、规则冲突、标注歧义等因素叠加。工程上需要把它拆解为可观测的信号链：

• 输入层：光照、天气、道路结构、交通参与者行为、遮挡关系。
• 感知层：漏检、误检、分类错误、跟踪丢失、深度估计偏差。
• 预测层：意图误判、轨迹多模态覆盖不足、交互博弈失败。
• 规划控制层：急刹、犹豫、压线、避让不足、舒适性下降。
• 评价层：接管、碰撞、TTC低于阈值、加速度超限、路径偏离。

因此，Hard Case分类不能只看“场景名字”，而要同时看功能链路和失效模式。同一场景可能触发不同失效，同一失效也可能由不同场景引起。

二、按场景分类：从道路结构到交通行为

场景分类是最直观的维度，常用于数据检索和测试用例组织。典型类别包括：

• 道路结构类：无保护左转、环岛、匝道汇入、施工改道、车道线缺失。
• 交通参与者类：行人鬼探头、非机动车逆行、大车遮挡、加塞、cut-in。
• 环境条件类：逆光、夜间低照度、雨雾、雪地反光、隧道出入口。
• 动态交互类：多车博弈、让行冲突、紧急车辆避让、拥堵跟车。

场景分类的价值在于可检索、可复现，但它的局限是：同一个“无保护左转”在不同路口、不同交通流下难度差异巨大，必须结合边界定义。

三、按功能分类：定位到系统模块

功能分类直接对应研发责任归属，便于分派修复任务：

功能模块	典型Hard Case表现	常用指标
感知	远距离小目标漏检、遮挡后重现、雨雾误检	Recall、mAP、ID Switch
预测	行人意图误判、车辆变道预测延迟	MinADE、意图准确率
规划	无保护左转犹豫、避让轨迹不合理	接管率、舒适度、通行效率
控制	急刹、横向抖动、跟踪超调	加速度、 jerk、横向误差
定位与地图	隧道内漂移、匝道匹配错误	横向/纵向定位误差

四、按失效模式分类：从“现象”到“根因”

失效模式是Hard Case闭环的核心。常见分类包括：

1. 漏检/误检型：应识别未识别，或把背景识别为目标。
2. 误判型：分类、意图或行为预测错误。
3. 决策冲突型：规则之间矛盾，导致犹豫或急动。
4. 规划不可行型：生成轨迹违反动力学或碰撞约束。
5. 控制跟踪型：执行偏差导致舒适性或安全性下降。
6. 数据/标注型：真值错误、标注歧义、场景标签缺失。

五、典型示例与边界定义

下面给出一个典型Hard Case的结构化描述，便于进入挖掘与闭环流程：

case_id: HC-URBAN-UL-001
scene: 城市无保护左转
trigger:
  - 对向直行车流连续
  - 存在遮挡视线的停止车辆
  - 光照：逆光
behavior:
  - 自车在路口内停滞超过2.0s
  - 随后急加速通过，横向加速度峰值>2.5m/s²
failure_mode: 决策冲突 + 规划不可行
risk: 高（TTC_min < 1.8s，存在碰撞风险）
boundary:
  - 可通行间隙阈值：4.5s
  - 最大等待时间：3.0s
  - 舒适性上限：jerk < 2.0m/s³

边界定义是Hard Case从“主观难”走向“客观可判定”的关键。它通常包括：触发边界（什么条件下算进入该场景）、通过边界（什么表现算通过）、失败边界（什么表现算失败）、以及风险边界（TTC、加速度、jerk等阈值）。没有边界，Hard Case就无法自动挖掘和回归验证。

六、误区与复盘

• 误区一：只按场景分类，忽略功能与失效模式，导致修复责任不清。
• 误区二：边界定义过宽，导致大量正常案例被误判为Hard Case。
• 误区三：只记录现象，不记录触发条件和真值，导致无法复现。
• 复盘要点：每个Hard Case应至少回答“在哪一层失效、由什么触发、边界是什么、如何验证修复”。

综上，Hard Case的工程化定义必须同时覆盖场景、功能、失效模式三个维度，并用边界定义将其转化为可挖掘、可标注、可回归的对象。只有如此，Hard Case才能从“个案讨论”升级为“闭环资产”，持续驱动自动驾驶系统迭代。