1. 项目全貌：为何要专门做“密集人群”检测
听到“基于深度学习的密集人群行人检测”这个名字，很多第一次接触的朋友会想：这不就是普通的目标检测套个框架吗？真把项目做进去以后你会发现，密集人群和普通检测完全是两种难度。空旷街道上零星行人识别，与地铁闸机、演唱会散场、商场中庭这类场景里几十上百人头攒动的情况，模型面对的挑战根本不在一个量级。
这篇文章是一套基于YOLOv12/v11/v8/v5四种模型的完整实战复盘，从数据整理、模型训练、部署推理到疑难排障，我会把整个链路里关键的技术细节和踩过的坑都展开讲。这套东西应对的问题很具体：如何让模型在互相遮挡、目标极小、光照混杂的密集人群场景下，依然保持较高的召回率与定位精度。内容适合三类读者：一是做安防监控、客流统计、儿童看护类项目的开发者；二是导师给布置了检测相关课题、需要快速找到有效训练路径的同学；三是想从单模型算法切换到多版本对比、搞清楚YOLO各代差异的工程爱好者。
1.1 密集人群场景，难在哪里
在确定选用YOLO哪些版本之前，我先把这类场景的典型痛点梳理了一遍。第一个痛点是遮挡，人与人之间的相互遮挡在密集场景中是常态，很多目标只露出半张脸、一个肩膀或者一条腿，检测框里的实际特征被严重污染，模型的分类置信度会因此大幅下降。
第二个痛点是尺度分布极广。近处的人占据大面积，远处的人可能只有十几个像素，一幅画面里会同时出现大目标和小目标。加上大量被画面边界截断的行人，半个身子在取景框外，这部分目标很容易被模型当作“难以判定的区域”直接忽略。
第三个痛点是背景的复杂性。商场、火车站、体育场这类场景有大量玻璃反光、地面纹理、栏杆结构，都在干扰模型的特征提取。稍不注意，训练出来的模型就会把栏杆竖直纹理或地砖缝隙当成行人轮廓，造成大量误检。
还有一点容易被忽略：密集人群的标注成本很高。一张图上几十个人，标注框互相重叠，标注员稍有疏忽就会把两个目标裁并成一个框，或者漏掉被完全遮挡的个体。数据质量一旦出问题，后面调什么模型都难有理想效果。
1.2 四个模型版本，各自扮演什么角色
有人可能会问：做项目选一个模型不就行了，为什么一口气上四个版本？这个问题其实对应着一个很常见的困惑：选择YOLO版本时应该遵循什么原则。
YOLOv5是这四个版本中训练资源要求最低、最稳定的一个。虽然它的结构相对早期，但社区生态非常完善，训练管线和部署工具都经受过大量验证。在算力有限、或者需要快速跑通一轮端到端验证时，v5是最让人省心的选择。我习惯把它当作整个项目的“流程验证器”，先把数据管线、训练脚本、导出步骤全部打通，再换更强的模型。
YOLOv8做出了两项关键改动：一是把C3模块换成C2f模块，让梯度在特征融合层里的流动更丰富；二是将分类和回归分支拆成了解耦头。在密集人群这种目标重叠严重的场景里，解耦头让分类与定位两个任务互不干扰，对mAP的提升是实打实的。
YOLOv11在v8的基础上进一步优化了特征融合结构，引入C3k2模块，延迟更低、轻量化程度更高。它在精度接近v8的中型版本的同时，参数量和推理耗时都更小，特别适合部署在边缘盒子和嵌入式设备上。
YOLOv12最大的变化在于注意力机制，它把区域级自注意力引入主干结构，增强了对遮挡目标的上下文建模能力。密集场景下，一个行人被挡住一大半时，若模型能利用周围人群的整体分布信息去推断这个遮挡实例，判断就会准很多。v12在这一点上有明显优势，不过它对算力的要求也更高。
所以我的选型策略是：不确定哪种方案最合适时，先拿v5跑通全流程，再用v8验证精度提升空间，接着用v11考察边缘部署可能性，最后用v12在算力充足的服务器上尝试突破。这样做既不会被一开始就复杂的参数配置拖住，也能在项目结束时得到一组完整的可解释对比数据。
2. 数据集整理：决定效果上限的关键前戏
数据决定了目标检测项目的效果上限，这句话在密集人群场景里尤其成立。模型结构上的差距可以用几个点来描述，但数据质量造成的差距可能是断崖式的。我在复盘时见过太多失败案例，模型结构上挑不出大毛病，最终效果惨不忍睹，问题基本都出在数据这一环。
2.1 用哪类数据集，怎么选场景
我做这个项目使用的是一组公开的密集行人标注数据，包含商场入口、地铁站闸机、户外广场三个子场景，总图片数约一万张，标注实例数超过八万个。密集程度不均匀，平均每张图8到15人，最密集的单张样本超过60人。
挑选数据集时我给自己定了三条规矩。第一，场景必须与最终业务场景贴近，监控视角和俯视视角训练出来的模型特性差别很大，如果最终要部署在3米高的摄像头位，训练数据就得尽量是类似高度的视角。第二，样本中必须包含大量“遮挡实例”，比如行人被柱子挡住一半、人与人重叠超过30%，这些是实际业务里的常态，不是在验证集里偶发的情况。第三，需要覆盖阴天、晴天、夜间多种光照条件，否则模型会对特定光线风格过拟合，换个现场就失效。
如果你的业务场景比较特殊，网络上找不到对应数据集，我强烈建议优先自行采集。自采数据虽然费时间，但它天然包含摄像头畸变、安装高度、画面比例等设备相关特征，这些信息在公开数据集里学不到，却在实际部署中至关重要。很多人忽略这一点，直接用网上数据训练出“实验优秀”的模型，一上真实现场就崩，这就是核心原因。
2.2 数据标注与格式转换的实操细节
原始标注数据的格式五花八门，常见的有COCO JSON、VOC XML、YOLO TXT三种。YOLO训练管线统一使用TXT格式，每行对应一个目标框，内容是：
类别id 中心点x 中心点y 框宽 框高
其中坐标全部归一化到0到1。做格式转换时有一个高频坑：很多公开数据集的标注是绝对像素坐标，比如用左上角x、左上角y、宽、高来表示，如果不做归一化，训练过程会反复震荡甚至梯度爆炸。我写了一个简单的Python脚本，把COCO格式转成YOLO格式：
import json import os def coco_to_yolo(json_path, img_dir, output_dir, categories): with open(json_path, 'r') as f: data = json.load(f) for img_info in data['images']: img_id = img_info['id'] img_w = img_info['width'] img_h = img_info['height'] lines = [] for ann in data['annotations']: if ann['image_id'] != img_id: continue cat_id = categories[ann['category_id']] x, y, w, h = ann['bbox'] # x, y 是左上角坐标 cx = (x + w / 2) / img_w cy = (y + h / 2) / img_h nw = w / img_w nh = h / img_h lines.append(f"{cat_id} {cx:.6f} {cy:.6f} {nw:.6f} {nh:.6f}") if lines: txt_name = os.path.splitext(os.path.basename(img_info['file_name']))[0] + '.txt' with open(os.path.join(output_dir, txt_name), 'w') as f: f.write('\n'.join(lines)) else: print("跳过空图片: ", img_info['file_name'])这个脚本里最关键的一点是按图片ID聚合标注，避免把一张图的框写到另一张图里。我第一次做转换时就踩过这个坑，生成的一批标注文件全部张冠李戴，导致模型前几个epoch的损失完全下不来，排查了半天才发现是聚合逻辑写错了。
提示：标注类别尽量保持简洁。密集人群场景中，用单一“person”类往往比分成“成人”“儿童”“背包者”多个类更稳定。子类之间特征差异太小，模型容易把它们相互混淆，反而增加训练难度和标签噪声。
2.3 密集场景的数据增强策略
常规的随机翻转、随机裁剪、色彩抖动，在密集人群任务里远远不够。我在实验中发现，影响最终效果最大的三个增强手段是随机尺度缩放、小目标复制粘贴增强、马赛克增强。
随机尺度缩放是把输入图像随机缩放到原始尺寸的0.5到1.5倍，模拟不同监控距离下的行人尺寸变化，对提升尺度泛化很有帮助。小目标复制粘贴增强的思路是：从训练集中挑出面积很小的行人实例，随机粘贴到其他图像的背景区域，同时调整标注框。这个操作特别针对密集人群中大量小目标的特点，能显著提升小目标召回率。我自己写了一个简单的粘贴逻辑，做了IoU重叠检查，避免粘贴位置覆盖到已有目标。
马赛克增强大家应该很熟悉，把四张图拼接成一张，既增加样本多样性，又让模型有机会看到更“拥挤”的画面。不过使用马赛克增强有一个注意点：如果训练全程开启，后期模型会频繁看到拼接痕迹明显的图像，对真实场景分布把握不准。我的做法是在前80%的epoch开启马赛克，最后20%个epoch逐步关闭，这个策略在多次实验中都很稳定，大家可以参考。
3. 模型训练：四套模型的完整实验流程
训练阶段我用了一台四卡GPU服务器和一台不带独立显卡的Windows开发机。GPU服务器负责模型训练和权重导出，开发机只做CPU推理验证。这里先把环境组合和训练配置讲清楚，再展开密集场景特有的训练技巧。
3.1 环境版本与依赖关系
一个容易踩坑的地方是CUDA与PyTorch版本匹配问题。我在这里给出一套验证过比较稳妥的组合，这套组合下四个模型都能正常训练：
Python 3.10 PyTorch 2.1.2 + CUDA 12.1 torchvision 0.16.2 OpenCV 4.8.0 Ultralytics 8.0+
安装完依赖后，我第一件事不是立刻开始训练，而是用官方预训练权重对数据集做一轮推理测试，检查图片读取、标注显示、类别映射是否正常。这一步很多人会跳过，但它能提前暴露90%的路径和格式问题。比如图片后缀名与标注文件名不匹配、类别id从1开始而从0开始这类错误，在这个阶段就能发现。
3.2 不同模型的训练命令与配置对比
YOLOv8、v11、v12在Ultralytics生态中都已支持通过同一个命令行入口训练，v5则需要使用独立仓库。为了让流程统一，我在v5部分使用了独立仓库，其余三个模型都走Ultralytics API。四组模型的具体配置如下：
| 模型 | 输入尺寸 | 初始学习率 | 批次大小 | 训练轮数 | 定位用途 |
|---|---|---|---|---|---|
| v5-s | 640 | 0.01 | 64 | 120 | 基准线，流程验证 |
| v8-m | 640 | 0.01 | 32 | 120 | 初步精度提升 |
| v11-m | 640 | 0.01 | 32 | 120 | 边缘部署候选 |
| v12-s | 640 | 0.005 | 16 | 120 | 大算力场景测试 |
学习率方面，v12我用0.005而不是常规的0.01。原因是v12引入了更复杂的注意力模块，训练早期梯度波动比v8更明显，若按习惯设0.01，前十个epoch很容易出现loss突跳甚至变成NaN。降低初始学习率后，训练平稳很多。
训练命令这里以v8为例：
yolo detect train data=config/crowd.yaml model=yolov8m.pt epochs=120 batch=32 imgsz=640 lr0=0.01 augment=True val=Truev5独立仓库的训练方式如下：
python train.py --data crowd.yaml --cfg models/yolov5s.yaml --weights yolov5s.pt --batch-size 64 --epochs 120这里特别说一下data配置文件的编写。crowd.yaml里需要指定训练集、验证集的图片路径以及类别列表：
train: ./datasets/crowd/train/images val: ./datasets/crowd/val/images nc: 1 names: ['person']很多新手会在这里踩坑，尤其是data.yaml里写绝对路径，后期换一台服务器就完全跑不动。我的习惯是全部使用相对路径，并在项目根目录下统一组织数据集目录，这样整套训练代码拷到哪里都能直接运行。
3.3 密集人群场景的损失函数与核心指标
YOLO系列的损失由三部分组成：分类损失、定位损失、置信度损失。在密集人群场景里，我特别关注两部分：一是定位损失在重叠目标上的表现，二是置信度损失上的正负样本不均衡问题。
定位损失方面，CIoU是常用选择，但在极度拥挤的场景中，边界框重叠度很高，CIoU的宽高比惩罚项会变得比较敏感。我在实验中换用EIoU损失后，遮挡场景下的定位偏移有可见改善。Ultralytics仓库中可以通过配置直接切换，改动成本不大，值得多试。
样本不均衡方面，密集人群里背景负样本数远多于前景正样本。如果模型不设置合适的平衡策略，很容易出现“预测框全部低置信度”的保守行为。YOLO使用Focal Loss缓解这个问题，但它的alpha和gamma参数默认值有时候不是最适合密集场景的。我最后使用的是alpha=0.25、gamma=2.0，对容易分类的背景样本做了更激进的压制，这个组合在密集人群任务上表现更稳。
评估环节我记录了mAP@0.5、mAP@0.5:0.95、Recall@0.5以及模型参数量。四组模型的最终表现如下：
| 模型 | mAP@0.5 | mAP@0.5:0.95 | Recall@0.5 | 参数量 |
|---|---|---|---|---|
| v5-s | 0.764 | 0.485 | 0.771 | 7.2 M |
| v8-m | 0.803 | 0.526 | 0.806 | 25.9 M |
| v11-m | 0.812 | 0.534 | 0.821 | 20.0 M |
| v12-s | 0.819 | 0.541 | 0.833 | 12.5 M |
以上结果是在相同数据集、相同输入尺寸、相同训练轮数下取得的。v12在遮挡样本上的Recall提升尤其明显，这与注意力机制对上下文建模的能力有关。v5虽然指标最低，但推理速度最快、内存占用最小，在低端设备上它的性价比反而最高。
必须强调一点：实际项目里指标高低不等于最终效果好坏。我曾经在某个客流统计需求里用过参数最大的模型，精度确实最好，但商用设备上帧率掉了近一半，最后不得不退回中型模型。所以做模型对比时，不要只看mAP，要同时记录FPS和显存占用，再根据现场设备算力边界做选型。
3.4 训练中遇到的损失值异常与处理
训练到40个epoch左右时，四组模型都陆续出现过损失突增的情况，v12尤其明显。排查后发现是两类原因叠加：其一是输入图像中混入了几张没有对应标注文件的样本，模型读到错误梯度；其二是部分样本的标注框坐标越界，比如中心点x或y大于1，或者框宽高为负，导致损失计算出现病态值。
解决办法是在训练前对标注文件做严格清洗，检查每个框是否在图像边界内、宽高是否大于零、类别id是否超范围。下面是我用的一个简单清洗逻辑：
import os def clean_annotations(ann_dir): for name in os.listdir(ann_dir): path = os.path.join(ann_dir, name) with open(path, 'r') as f: lines = f.readlines() clean_lines = [] for line in lines: parts = line.strip().split() if len(parts) != 5: continue cat_id, cx, cy, bw, bh = parts cx, cy, bw, bh = float(cx), float(cy), float(bw), float(bh) if bw <= 0 or bh <= 0: continue if cx < 0 or cx > 1 or cy < 0 or cy > 1: continue if cx - bw / 2 < 0 or cy - bh / 2 < 0 or cx + bw / 2 > 1 or cy + bh / 2 > 1: continue clean_lines.append(line) with open(path, 'w') as f: f.writelines(clean_lines)清洗完成后重新训练，损失曲线平稳了很多。后来我把这个清洗脚本做成了训练前的一个固定步骤，不管拿到什么数据集都先跑一遍，省了很多事。
4. 模型导出与部署：从训练服务器到业务现场
训练完成只是第一步，真正考验人的是把模型从Python环境拉出来，塞进生产环境。很多做研究的朋友第一次搞部署会被各种报错劝退，其实把导出流程的每一步核查点搞清楚后，会发现它比训练更可控。
4.1 ONNX导出与中间层验证
我用ONNX作为统一中间格式，后续再根据目标设备决定转成TensorRT还是OpenVINO。Ultralytics的导出命令很简单：
yolo export model=yolov8m.pt format=onnx dynamic=False imgsz=640导出后的第一步是立刻用onnxruntime跑一遍推理，对比原PyTorch模型的输出差异。正常情况下，ONNX模型与PyTorch模型在每个检测框上的坐标差异应控制在1e-4以内。差距过大，多半是某些自定义算子没有被正确映射。
YOLOv12因为引入了新的注意力算子，导出ONNX时要额外确认ONNX算子集版本。我遇到过某个算子集版本不兼容的情况，导出时没有任何报错，但推理输出全为零，后来换了一个更高版本的算子集才恢复正常。建议在导出前后分别打印模型的输入输出节点信息，确认输入名、形状、动态轴设置都符合后续推理引擎的要求。
4.2 TensorRT加速与精度损失评估
我的部署目标是在边缘设备上跑出实时帧率。以v11-m模型为例，在TensorRT FP16精度下，640×640输入在目标边缘设备上的推理耗时能到12毫秒左右，而相同模型用onnxruntime的CPU推理需要80毫秒以上，差距非常直观。
TensorRT优化过程中有四个关键点。第一，输入尺寸尽量固定，动态shape虽然灵活，但会导致引擎构建时间变长、部分kernel选择不够优化。第二，FP16带来的精度损失在目标检测任务里通常可以接受，但如果业务对定位精度极为敏感，建议先量化对比一组测试集再决定。第三，batch size的设置要和上线时的业务模式绑定，比如视频流按单帧检测则batch=1即可。第四，workspace参数控制临时计算内存，设得过大不会提升性能，设得过小则构建失败。
构建TensorRT引擎时，可以先使用官方trtexec工具验证和保存引擎：
trtexec --onnx=model.onnx --saveEngine=model.engine --fp16 --workspace=2048构建完成后，我会用onnxruntime与TensorRT分别处理同一批测试图，要求两者的mAP差异控制在0.01以内，再作为验收标准。
4.3 部署端的前后处理细节
部署阶段有一个经常被忽视的细节：NMS参数。YOLO原始输出是大量候选框，只有经过NMS抑制后才是最终检测结果。在密集人群中，如果NMS的IoU阈值设得太高，两个挨得很近的行人可能被合并成一个框；设得太低，大量冗余框又清除不干净。我最终把IoU阈值设为0.45，置信度阈值设为0.25，在漏检和误检之间是较好的平衡点。
注意：很多部署教程会忽略训练端与部署端图像预处理的一致性。训练时采用RGB输入、归一化到0-1范围，部署时也必须用完全相同的预处理方式，包括通道顺序、缩放方式（letterbox）和填充颜色。有一回我在部署后一直出现检测框整体偏移，排查到最后发现是视频帧是BGR格式，没转成RGB就直接送进了模型。
还有一个坐标还原的问题。模型输出的是letterbox处理后的坐标，业务系统通常需要的是原始图像坐标。需要根据原始图尺寸和letterbox参数做逆变换，否则检测框画到原图上会错位。这个逻辑虽然简单，但在接入多个摄像头时特别容易写乱。
5. 项目运行与效果验证：实际场景中的表现
模型部署到业务端后，我用三段真实监控视频做了压力测试。三段视频分别来自商场扶梯、地铁闸机、户外公园小径。这三类场景的密集程度、遮挡程度、光照条件差异很大，正好能检验模型的泛化能力。
5.1 现场跑测数据
现场跑测时我记录了几项关键指标：检测帧率、单帧最大检测人数、遮挡场景连续性。三个场景的表现差异如下：
| 场景 | 平均帧率 | 最大单帧检测数 | 遮挡召回情况 |
|---|---|---|---|
| 商场扶梯 | 28 FPS | 23人 | 遮挡约35%，召回约0.82 |
| 地铁闸机 | 25 FPS | 18人 | 遮挡约45%，召回约0.79 |
| 户外小径 | 31 FPS | 12人 | 遮挡约15%，召回约0.90 |
地铁闸机场景的召回率偏低，主要原因是闸机边缘行人被严重截断，加上玻璃围挡带来反光干扰。针对这类场景，我后续在训练集中加入了更多边缘截断样本和反光合成样本，再次验证时召回率回升到0.83以上。这说明场景适配比模型调参更能解决实际部署中的效果短板。
5.2 业务链路对接：检测结果如何用起来
单一检测模型不能直接产生业务价值，它通常需要与跟踪器、计数逻辑配合才能完成客流统计这类任务。我在项目中采用了一种轻量跟踪策略：对相邻两帧的检测框做IoU配对，然后根据检测框中心点是否跨过预设计数线来判定进出方向。
这里有一个很多人踩坑的地方：跟踪器会把短暂消失又重新出现的行人当成新ID，导致重复计数。我的解决办法是给每个跟踪ID设置一个“冷却帧数”，比如行人从画面消失后允许其在10帧内重新匹配，超过10帧才判定为离开。这个数字不是拍脑袋定的，是根据现场摄像头大约25帧每秒、行人穿过遮挡物平均耗时0.4秒算出来的。如果你换了一个帧率不同的摄像头，这个值就需要重新估算。
6. 常见问题与排查技巧实录
整个项目做下来，我整理了一份高频问题的排查手册，这里挑选几条最典型的来分享。每一条背后都是我被真实问题教育过的经验，比单纯看文档有用得多。
6.1 误检严重，路牌、栏杆、阴影被当人
这类问题绝大多数时候是数据层面的问题，而不是模型结构的问题。我的建议是：先截取几十张误检最典型的图像，统计误检框出现的位置、尺寸和上下文特征，然后去训练集中找同类样本，刻意增加包含这些干扰物的负样本图片，或者在标注时把容易混淆的干扰物单独处理，“告诉”模型这些区域不是人。
增加负样本后，误检往往在第一轮迭代中就能显著下降。如果仍然压不下去，再考虑调整NMS阈值和置信度阈值。比如置信度阈值从0.25提到0.35，误检会明显减少，代价是漏检率也可能小幅上升，需要根据业务容忍度来权衡。
6.2 漏检太多，尤其是画面边缘与远处小目标
漏检小目标的核心原因通常是下采样次数太多后，小目标的特征在深层特征图中已经几乎丢失。面对这种情况，我的第一步尝试是把输入分辨率从640提高到1024，让目标在特征图中的有效像素变大。输入分辨率在小目标召回上提升非常明显，但推理速度会下降，需要在效率和精度之间权衡。
画面边缘目标被截断明显时，需要检查letterbox处理。输入图像做letterbox缩放时会保留原始宽高比，四周填充灰色，如果填充区域过大，边缘目标会被压缩得很小。我的经验是，可以考虑裁剪式处理，或者把填充方式从灰色改成边缘像素复制，减少边缘信息的损失。这部分需要针对具体摄像头视角多试几种方案。
6.3 显存溢出与OOM
显存溢出是最常见的训练问题之一。它的排查路径很直接：先小batch测试，正常后逐步增加batch，直到OOM位置再退一个档位。减小batch后如果把学习率保持不变，训练会变得不稳定，正确做法是同步降低学习率或采用梯度累积。我在训练v8-m时，32的batch在单卡上刚好能跑，16的batch则需要把学习率从0.01降到0.005，才能保证训练稳定。
推理阶段遇到OOM，则多半是视频路数同时处理太多。GPU上跑多路视频时，我会把输入做定长队列，保证同一时刻只有预设数量的帧在做前向推理，其余帧排队等待。这个方法能有效避免显存峰值，比单纯调低模型精度更划算。
6.4 接口联调异常：检测结果接入业务系统时错乱
最后一个典型问题发生在把检测结果接入业务系统的时候。最常见的现象是本地单独跑模型完全正常，接入业务框架后结果丢失或错乱。排查时先确认数据类型与通道顺序，再确认坐标是否需要还原到原图尺寸。很多业务系统接收的是原图坐标，而模型输出的是letterbox后的像素坐标，需要根据原始图像尺寸和letterbox参数做逆变换，这个转换逻辑要单独封装成函数，并在联调前用固定样例验证输出坐标是否正确。
7. 多版本模型的最终取舍与心得
四个模型跑完全流程后，我的最终取舍逻辑可以归纳成三条。第一，在对帧率要求不高、算力充足的服务器场景中，v12-s是首选，它在遮挡场景下的召回表现最稳定。第二，在边缘设备上，v11-m的综合性价比最好，虽然精度比v12略低，但体积小、推理快、部署成本低。第三，v5-s最适合做基准验证和快速原型，用它验证数据管线是否合理最省时间。
如果是在一个全新的业务场景里启动密集人群检测项目，我的建议是先把v5-s训练到收敛，用它的结果检验数据质量；然后把v8-m完整训练一版，作为精度基线；再根据目标部署平台，在v11和v12中挑选一个继续优化。这个路径能帮你避免在最开始就陷入模型版本选择的纠结里，也能给团队留下一组可解释的对比数据，方便后续写方案或向客户说明选型理由。
代码与文档已经整理到项目目录中，包含训练脚本、数据集转换工具、导出部署手册和一份完整调参记录。实际上最值得看的不是那些“完美”的参数值，而是我在每轮实验里记录下来的失败尝试。正确地排除错误选项，同样能帮你节约大量时间。
最后说一下这几年做目标检测项目最真切的感受：密集人群检测的本质，不是把模型调得更深更宽，而是理解和控制数据里遮挡、尺度、光照变化带来的不确定性。模型版本的选择只是手段，对数据的深刻理解才是让项目真正跑通的关键。希望这篇复盘能让你少走一些我走过的弯路。
