3. 视觉感知性能验证的指标体系

在 EyeQ 平台上做视觉感知性能验证，最容易犯的错误是"只看一个数"。检测率很高，不代表系统可用；测距很准，也不代表不会漏掉横穿行人。真正能支撑验收决策的，是一组互相约束、彼此制衡的指标集合。本节围绕检测率、误检率、漏检率、测距精度、测速精度、分类准确率、时延与帧率八类关键指标，说明它们在 EyeQ 场景中的具体含义、计算口径与阈值设定方法。

一、指标的定义与计算口径

所有指标都必须先约定"匹配规则"，否则数字没有可比性。EyeQ 验证中通常采用 IoU 匹配：预测框与真值框的交并比大于阈值（如 0.5）即视为命中，同一真值只允许匹配一个预测框，多余预测框计入误检。

• 检测率（Recall / 召回率）：TP / (TP + FN)，即所有真实目标中被成功检出的比例。它回答"该看到的有没有看到"。
• 漏检率：FN / (TP + FN) = 1 − 检测率。与检测率互为补数，单独列出是为了在排障时直接定位"漏了什么"。
• 误检率（False Positive Rate）：FP / (FP + TN)，或工程上更常用"每帧误检数（FP/frame）"。前者受负样本总量影响大，后者更贴近实车体验。
• 测距精度：以纵向距离误差为主，常用绝对误差 |Z_pred − Z_gt| 与相对误差 |ΔZ|/Z_gt 两个口径，并按距离分段统计。
• 测速精度：相对速度误差 |V_pred − V_gt|，通常关注本车与目标相对速度，而非绝对速度。
• 分类准确率：在已正确检测的目标中，类别判定正确的比例，即 TP_correct / TP。它必须与检测率分开统计，否则分类错误会被检测错误掩盖。
• 时延：从传感器曝光时刻到感知结果输出的端到端时间，包含采集、传输、推理、后处理，单位 ms。
• 帧率：单位时间输出帧数（fps），需区分"传感器帧率"与"感知有效输出帧率"，掉帧同样计入性能损失。

二、EyeQ 场景中的指标含义

EyeQ 是面向 ADAS/AD 的嵌入式视觉 SoC，其感知输出直接进入 AEB、ACC、LKA 等控制链路，因此指标含义带有强烈的"功能后果"色彩。检测率不足，直接表现为 AEB 不触发；误检率过高，表现为幽灵刹车；测距误差偏大，会让 TTC 计算失真；时延过大，则会让本已正确的检测在时间上"迟到"，等效于漏检。

以 EyeQ4 典型配置为例，前视 120 万像素、约 36 fps 输入，感知输出帧率通常要求不低于 30 fps，端到端时延控制在 100 ms 以内。这些数字不是绝对值，而是与下游控制周期匹配的结果：若 AEB 控制周期为 50 ms，感知时延超过 100 ms 就会引入两拍以上的滞后，制动距离估算将明显偏乐观。

三、阈值设定的四步方法

阈值不能凭经验拍脑袋，也不能直接照搬公开数据集指标。推荐按以下四步推导。

第一步，功能反推。从下游功能的安全需求出发。以 AEB 为例，若要求对 40 m 内横穿行人在 1.2 s TTC 前完成触发，则感知必须在对应距离上保持足够高的检测率。工程上常把近距（<30 m）行人检测率阈值设为 ≥ 99%，中距（30–60 m）≥ 95%，远距（>60 m）≥ 85%。这些是示例性目标值，实际项目需结合安全分析和实车标定确定。

第二步，场景分层。同一指标在不同场景下阈值不同。白天高速场景测距误差可要求 ≤ 3% 或 ≤ 1.5 m（取较大者），夜间或逆光可放宽到 ≤ 5%。分层的目的不是降低标准，而是让测试结果可解释、可定位。

第三步，误检约束。检测率与误检率天然矛盾，必须同时设上限。常见做法是规定"每帧误检数 ≤ 0.1"，即平均 10 帧不超过 1 个误检目标。若只提检测率不提误检，很容易通过降低置信度阈值"刷"出高检测率，却带来大量幽灵目标。

第四步，回归验证。把阈值写进测试用例与判定脚本，每次版本迭代自动比对。若某版本检测率提升但误检率恶化超过设定比例，应视为回归失败而非改进。

四、指标之间的耦合关系

这八类指标并非独立。降低置信度阈值会同时提高检测率、提高误检率；提高分类阈值会提高分类准确率、降低检测率；增大推理输入分辨率会改善测距精度、但增加时延、降低帧率。因此阈值设定本质是一个多目标折中问题。

五、一个可执行的指标判定表

下表给出一个可直接用于测试报告的结构示例，数值为示例性目标，需按项目实际替换。

需要强调的是，表中每一个阈值都必须能追溯到具体的功能需求或安全分析结论，而不是"行业惯例"。当测试结果与阈值不符时，正确的做法是先检查匹配规则、真值标注质量与场景分布是否一致，再判断是感知算法问题还是阈值设定本身不合理。指标体系的真正价值，不在于给出一个漂亮的数字，而在于让每一次性能变化都能被解释、被定位、被复现。