3、目标检测基础：目标检测任务定义、常用模型（YOLO、SSD、Faster R-CNN）简介、模型输出格式（边界框、类别、置信度）

在将目标检测模型部署到手机端之前，我们必须先建立对目标检测任务本身的清晰认知。目标检测（Object Detection）是计算机视觉中最核心的任务之一，它不仅要回答“图像中有什么物体”，还要回答“物体在哪里”。与图像分类（Image Classification）只输出整张图片的类别标签不同，目标检测需要同时输出多个物体的位置信息与类别信息。本章将系统梳理目标检测的任务定义、三类主流模型（YOLO、SSD、Faster R-CNN）的核心设计思想，以及模型输出的标准格式——边界框、类别与置信度。这些知识是后续进行ONNX模型转换、量化压缩和端侧推理优化的基础，理解不透彻将直接影响部署方案的选型与调优。

目标检测模型核心概念与输出格式 任务定义 输入：图像/视频帧 输出：多个物体位置+类别 与分类/分割的区别 常用模型家族 YOLO（单阶段，实时） SSD（单阶段，多尺度） Faster R-CNN（两阶段，高精度） → 部署选型核心权衡 输出格式 边界框 (x, y, w, h) 类别标签 (class_id) 置信度 (score) → NMS后处理输入 ONNX Runtime 手机端部署链路 PyTorch/TF训练 导出ONNX 量化/优化 NNAPI/CoreML 端侧推理

3.1 目标检测任务定义与问题建模

目标检测的任务定义可以形式化描述为：给定一张输入图像 \( I \)，模型需要输出一组检测结果 \( D = \{d_1, d_2, ..., d_n\} \)，其中每个检测结果 \( d_i \) 包含三个核心要素：边界框（Bounding Box）、类别标签（Class Label）和置信度（Confidence Score）。边界框通常用矩形框表示，常见表示方式有两种：一种是中心点坐标加宽高 \( (c_x, c_y, w, h) \)，另一种是左上角与右下角坐标 \( (x_1, y_1, x_2, y_2) \)。类别标签来自预先定义的类别集合 \( C = \{c_1, c_2, ..., c_m\} \)，例如COCO数据集的80类或VOC数据集的20类。置信度则是一个0到1之间的浮点数，表示模型对该检测结果可靠程度的估计。

从数学建模的角度看，目标检测是一个多任务学习问题：模型需要同时优化分类损失（判断框内物体属于哪个类别）和回归损失（精确调整边界框的位置与尺寸）。这种多任务特性使得目标检测比纯分类任务复杂得多，也直接影响了模型在手机端的计算开销和内存占用。在部署时，我们需要特别关注模型输出的张量形状——它通常是 \( [1, N, 5 + C] \) 或 \( [1, N, C+4] \) 的格式，其中 \( N \) 是预设的候选框数量（如YOLO的8400或SSD的8732），\( C \) 是类别数，4代表边界框坐标，1代表置信度（或与类别概率合并）。

部署视角的关键点：在手机端部署时，模型输出的原始张量往往包含大量低置信度的冗余检测框。例如YOLOv8在640×640输入下会输出8400个候选框，但实际有效物体可能只有几个。因此，后处理（Post-processing）——包括置信度阈值过滤和NMS（非极大值抑制）——是端侧推理中不可忽视的计算瓶颈。在ONNX Runtime中，这些后处理步骤既可以在模型图中以算子形式包含，也可以在应用层用C++/Java实现，两种方案各有优劣，后续章节会详细讨论。

3.2 三大主流模型架构对比

目标检测模型的发展经历了从两阶段到单阶段的演进，不同架构在精度、速度和计算量上各有取舍。理解这些差异对于选择适合手机端部署的模型至关重要。

3.2.1 Faster R-CNN：两阶段检测的开山之作

Faster R-CNN由Ren等人在2015年提出，其核心思想是“先粗后精”。第一阶段使用区域提议网络（RPN, Region Proposal Network）从特征图中生成约2000个可能包含物体的候选区域（Region Proposals）；第二阶段对每个候选区域进行ROI Pooling，提取固定尺寸的特征，然后通过全连接层进行分类和边界框回归。这种两阶段设计使得Faster R-CNN在精度上表现出色，尤其是在小物体检测场景下优势明显。但其计算量巨大——单张图片需要处理数千个候选区域，在手机端CPU上推理一张640×480的图片通常需要数秒，即使经过优化也难以达到实时要求。

3.2.2 SSD：单阶段多尺度检测

SSD（Single Shot MultiBox Detector）由Liu等人在2016年提出，它摒弃了候选区域生成阶段，直接在多个不同尺度的特征图上进行密集采样和预测。SSD的关键创新在于多尺度特征图检测：浅层特征图（分辨率高、语义信息弱）负责检测小物体，深层特征图（分辨率低、语义信息强）负责检测大物体。SSD在VOC2007测试集上达到了72.1%的mAP，同时速度比Faster R-CNN快一个数量级。在手机端部署时，SSD的模型结构相对规整，卷积层和归一化层易于被ONNX Runtime的CPU算子优化，但需要处理8732个默认框（Default Boxes）的后处理，NMS耗时较长。

3.2.3 YOLO系列：实时检测的标杆

YOLO（You Only Look Once）由Redmon等人在2016年首次提出，其核心思想是将目标检测视为一个端到端的回归问题。YOLO将输入图像划分为S×S的网格，每个网格负责预测固定数量的边界框、置信度和类别概率。经过多次迭代，YOLOv5、YOLOv8等版本在保持高速的同时大幅提升了精度。以YOLOv8n为例，其参数量仅约3.2M，在手机端CPU上使用ONNX Runtime推理，640×640输入的单帧延迟可控制在100ms以内，是当前端侧部署的主流选择。YOLO系列模型的输出格式通常为 \( [1, 84, 8400] \)（COCO 80类），其中84 = 4（坐标）+ 80（类别概率），8400是不同尺度特征图上的锚点总数。

模型 阶段数 典型mAP (COCO) 参数量 手机端推理延迟 (CPU) 部署友好度
Faster R-CNN 两阶段 37.4 (ResNet50) ~41M 3-10秒/帧 低（结构复杂，后处理重）
SSD 单阶段 28.8 (VGG16) ~26M 300-800ms/帧 中（需处理8732个框）
YOLOv8n 单阶段 37.3 ~3.2M 50-150ms/帧 高（输出规整，易优化）
选型建议：对于手机端实时检测场景（如视频流分析、AR应用），优先考虑YOLO系列轻量版本（YOLOv5s、YOLOv8n）或SSD-Lite。如果业务对精度要求极高且允许离线处理（如拍照检测），可以尝试Faster R-CNN的量化版本，但需要接受较高的延迟和内存占用。

3.3 模型输出格式深度解析

无论使用哪种模型，最终导出为ONNX格式后，其输出张量的语义是部署工程师必须精确掌握的。以YOLOv8为例，其ONNX输出形状为 \( [1, 84, 8400] \)，这里的维度顺序是通道在前（Channel First）。84维向量中，前4维是边界框坐标（中心点x、中心点y、宽度w、高度h），后80维是每个类别的概率。8400个候选框来自三个不同尺度特征图的展平：80×80（6400个）、40×40（1600个）、20×20（400个）。

在端侧解码时，我们需要执行以下步骤：

  1. 转置与重塑：将 \( [1, 84, 8400] \) 转置为 \( [1, 8400, 84] \)，便于按行处理。
  2. 置信度计算：对于每个候选框，取80个类别概率的最大值作为该框的类别置信度，并记录对应的类别索引。
  3. 阈值过滤：将置信度低于预设阈值（如0.25）的候选框直接丢弃，通常可过滤掉90%以上的冗余框。
  4. 坐标转换：将中心点坐标格式转换为 \( (x_1, y_1, x_2, y_2) \) 格式，便于后续NMS和绘制。
  5. NMS：对同一类别的候选框按置信度降序排列，依次抑制与当前框IoU大于阈值的其他框。
// 伪代码：YOLOv8输出解码核心逻辑
// 输入: output [1, 84, 8400], 置信度阈值 conf_thres=0.25, NMS阈值 iou_thres=0.45
for each of 8400 anchors:
    scores = output[0, 4:84, anchor]  // 80个类别概率
    conf, class_id = max(scores)
    if conf < conf_thres: continue
    cx, cy, w, h = output[0, 0:4, anchor]
    x1 = cx - w/2; y1 = cy - h/2
    x2 = cx + w/2; y2 = cy + h/2
    detections.append({x1, y1, x2, y2, conf, class_id})
// 按类别分组后执行NMS
for each class c:
    sort detections by conf descending
    while detections not empty:
        keep = detections[0]
        remove all detections with IoU(keep, d) > iou_thres

3.4 案例拆解：从COCO模型到手机端检测的完整链路

为了将上述概念串联起来，我们以一个实际场景为例：假设我们需要在Android手机上实现一个实时行人检测应用，选用YOLOv8n模型（COCO预训练，80类中包含person类）。

背景与约束：目标设备为搭载骁龙8 Gen 2芯片的Android手机，要求推理延迟低于80ms，内存占用低于500MB，检测精度mAP@0.5不低于0.45。

初始现象与关键指标：直接使用PyTorch导出的YOLOv8n ONNX模型（FP32精度），在手机CPU上使用ONNX Runtime实测延迟为180ms，远超80ms的目标。通过性能分析工具（如Perfetto）发现，耗时分布为：卷积层计算占65%，后处理（NMS）占25%，数据预处理占10%。

分析判断过程：首先，FP32模型在CPU上计算量过大，需要量化到INT8。其次，NMS在Java层实现效率低下，需要改用C++实现或集成到ONNX模型中。最后，输入分辨率从640×640降至480×480，可减少约44%的计算量，但需验证精度损失。

实际操作步骤：

  1. 使用ONNX Runtime的量化工具将模型转换为INT8动态量化版本，实测延迟降至95ms。
  2. 将NMS逻辑用C++重写，并通过JNI调用，延迟进一步降至70ms。
  3. 将输入分辨率调整为512×512，mAP下降约2%，但延迟降至55ms，满足要求。
  4. 最终方案：INT8量化 + 512×512输入 + C++后处理，总延迟52ms，内存占用380MB。

结果对比与复盘：量化带来的精度损失在可接受范围内（mAP从0.52降至0.49），而分辨率降低对行人这类中等尺寸物体影响较小。复盘发现，后处理优化往往比模型压缩更容易被忽视，但收益显著。此外，不同手机芯片的NPU加速能力差异巨大，后续章节将介绍如何通过ONNX Runtime的EP（Execution Provider）接口调用NPU。

常见误区提醒：很多初学者在部署时只关注模型本身的FLOPs和参数量，却忽略了后处理（NMS）在端侧的时间占比。在低端手机上，NMS可能占据总延迟的40%以上。建议在模型导出时就将NMS作为ONNX图的一部分（使用非极大值抑制算子），或使用高效的C++实现，避免在Java/Python层做循环处理。

3.5 总结与部署要点复盘

本章我们系统梳理了目标检测的基础知识，核心要点可以归纳为以下四条：

  • 任务本质：目标检测是分类与回归的联合任务，输出必须包含边界框、类别和置信度三要素。
  • 模型选型：手机端部署优先选择单阶段模型（YOLO、SSD），两阶段模型（Faster R-CNN）仅在离线高精度场景下考虑。
  • 输出格式：必须精确理解ONNX输出的张量形状和维度顺序，YOLO系列为 \( [1, C+4, N] \)，SSD为 \( [1, N, C+4] \)，解码逻辑完全不同。
  • 后处理不可忽视：置信度过滤和NMS是端侧推理的必要环节，其实现效率直接影响整体延迟。
← 上一章 📖 返回目录 下一章 →