最近在赶一个项目，把基于 YOLOv8 的灾难场景人员检测系统从中英文双语版一路做到可以演示的程度。老实说，刚接到这个需求的时候，我第一反应是“这不就是套个权重跑一下推理吗”，但真正上手之后才发现，灾难救援场景下的目标检测有一套完全不同于普通安防或自动驾驶的打法和坑。这篇文章不聊虚的，直接讲我用 YOLOv8 做人员检测的完整过程，包括双语言版本怎么落地、训练数据怎么准备、推理代码怎么组织，以及踩过的最关键的几个性能坑。
这个系统能干什么，一句话说清楚：给定地震、火灾、洪水、坍塌等灾害现场的图像或视频帧，模型自动标出画面中的所有人员位置，并用置信度标明检测结果。中英文双版的意思是：模型训练基于中英文双语标签体系，而且界面和输出结果支持两种语言切换，方便国内外的救援协调团队使用。适合谁看？准备做目标检测落地的开发者、想在垂直场景（比如救援、安防、工业巡检）里用 YOLOv8 的人，或者只是想把模型训练、推理、部署全链路走通的学生。
1. 项目背景与整体设计思路
1.1 为什么灾难场景的人员检测不能直接拿通用模型硬套
你可能觉得，YOLOv8 官方预训练模型已经在 COCO 上跑得很好了，COCO 里面也有人类这个类别，直接拿来推理不就行了吗？我一开始也这么想，但实际测试下来效果完全不行。
原因主要有三个。第一，COCO 数据集里的人物图像大多拍摄于正常生活环境，背景干净、光照均匀、人体姿态完整。而灾难现场是什么情况？扬尘、烟雾、浓雾、夜间低光照、肢体被废墟遮挡、人体蜷缩在角落里只露出半个头部——这些在通用数据集里占比极低。第二，灾难场景的拍摄视角非常刁钻，大部分来自无人机俯拍、救援机器人低角度拍摄、监控摄像头抖动画面，而 COCO 数据集的拍摄视角还是以平视为主。第三，灾难场景中背景复杂，废墟纹理和人体纹理常常高度相似，模型很容易把混凝土碎块识别成人，或者把深色衣物的人漏掉。
所以这个项目的核心设计思路不是“拿来就用”，而是“针对场景做适配”。我做了三件事：一是重建数据集，通过公开的灾害图像数据加上自己标注的样本，构建一个灾难场景专用的人员检测数据集；二是做数据增强，模拟真实的灾难环境（模糊、噪点、遮挡、色彩偏移）；三是双标签体系，在训练过程中同时输出中文标签和英文标签，方便跨语言部署。
1.2 为什么选择 YOLOv8 而不是其他目标检测框架
选型的时候我纠结过一阵子，主要是想在这几款之间做决定：YOLOv5、YOLOv8、RT-DETR 和传统两阶段的 Faster R-CNN。
先说结论：最终选了 YOLOv8，因为它在精度和速度之间平衡得最好，并且对边缘设备相对友好。
YOLOv5 虽然成熟稳定，但它的架构相对 YOLOv8 旧一些，C3 模块的计算效率不如 C2f，而且官方对 YOLOv5 的维护力度已经明显下降，新特性都跑到了 v8 和 v9 上面。RT-DETR 是百度提出的实时检测 Transformer，精度确实高，但对硬件要求也高，在推理阶段需要更大的显存，不太适合我们预期要跑在边缘盒子上的场景。Faster R-CNN 在这个任务上的精度上限其实不低，但推理速度完全无法满足实时检测的需求，灾难救援中无人机回传的视频流如果每秒处理不了几帧，就没有实际意义。
YOLOv8 相对轻量，同时支持目标检测、实例分割、姿态估计等多种任务，一套框架搞定多模型。而且 Ultralytics 的 API 封装得非常好，训练、验证、导出、推理全流程都能几行代码跑通，对快速原型验证极为友好。不过这里要重点提醒一句，不要把 Ultralytics 当成黑盒，后面排查问题的时候，还是要能够看懂配置文件的每一项。
1.3 中英文双标签体系的设计细节
做中英文双版，很多人第一反应是在 UI 上做 i18n 国际化，改改翻译就行。但对于模型输出来说，问题的本质是：模型的类别标签如何同时表达中文和英文？
我采用的方案是构造一个 categories 映射表，模型内部标签统一用数字 id 和英文标识（person、group 等），在最终展示层用国际化配置文件把英文标签映射成中文。但真正的难点在于训练阶段——训练数据集中如果只有英文标签，那么检测头学习到的语义特征仍然偏向英文语境，输出层没问题，可当你想在中文界面展示时就只是做了一次字符串替换，没有实际意义。
我调整了训练数据标注策略：在 YOLO 格式的 label 文件中，class id 对应英文类别名，但在数据集描述文件中维护一份中英文对照表，实际训练时用英文，在 UI 与日志模块中做实时翻译。这样的好处是模型权重完全不受语言影响，但项目交付时可以同时给中英文文档和界面。这其实是我踩过一个坑之后回退的方案：一开始我试过直接把中文“人”作为类别名去训练，结果模型收敛速度明显变慢，因为 Ultralytics 的标签编码处理对非 ASCII 字符的支持并不完善，后来果断回到 id + 映射表的方案。
2. 环境搭建与数据准备工作
2.1 训练环境的硬件配置与依赖安装
先讲一下我这边训练机器的配置，方便你评估自己的环境是否够用：GPU 是单张 12GB 显存的显卡（同档次即可），CPU 八核，内存 32GB，系统 Ubuntu。这个配置对 YOLOv8 来说属于“勉强够用但需要勤调参”的水平，如果你用 8GB 显存，可能需要把 batch size 调到 8 以下，或者直接用 nano 模型。
依赖安装这一块，我强烈建议用虚拟环境，不要图省事直接装在系统 Python 里。我用的是 conda，新建一个环境，Python 版本 3.10，然后安装 PyTorch 2.0+，CUDA 版本对应自己的显卡驱动。然后安装 Ultralytics 包，一条命令：
pip install ultralytics这里提醒一个细节：Ultralytics 包会自动把 torch 装成默认版本，如果你对 CUDA 版本有特殊要求，建议先手动装好指定版本的 torch，再装 ultralytics，避免它把 torch 覆盖成不兼容的版本。
我实际还额外装了这些库：
pip install opencv-python albumentations labelme其中 albumentations 是用来做第二步数据增强的，labelme 是用来检查标注质量的。OpenCV 是必备的，做视频流解码和图像预处理都靠它。
2.2 数据集构建：从公开数据到自标注
数据是灾难场景检测的灵魂。我最终使用的数据集由三部分混合而成：一部分来自公开的灾害图像数据集（主要是地震、火灾、洪水场景），一部分来自无人机航拍图像数据，还有一部分是我从一些模拟演练视频中截帧后手动标注的。
手动标注是最耗费时间的环节。我用 labelme 先标注了一遍，然后把标注文件转换成 YOLO 格式。转换的时候有几个细节需要注意，YOLO 格式的框坐标是归一化到 [0,1] 的 center_x, center_y, width, height，labelme 输出的是左上角和右下角的绝对坐标，所以转换公式是：
x_center = (x1 + x2) / 2 / img_width y_center = (y1 + y2) / 2 / img_height w = (x2 - x1) / img_width h = (y2 - y1) / img_height这个公式看起来简单，但容易搞错的是坐标体系。labelme 的坐标原点在图片左上角，x 轴向右，y 轴向下；OpenCV 读取图片的坐标体系是一致的，但有些工具（比如某些标注平台）用的是左下角原点，不仔细看文档就会出错。建议写一个脚本批量检查转换后的框是否越界，越界的框裁掉或跳过，别让脏数据进训练集。
我最终的数据集规模是 8000 多张图像，其中包含大约 23000 个标注实例。数量上不算大，但胜在标注质量比较高。记得留出 10% 到 20% 作为验证集，不要和训练集混在一起，否则验证结果很虚。
2.3 数据增强：让模型见过“灾难”
数据增强是这个项目里效果最被低估的一环。我深知模型在灾难场景里最怕的就是没见过的噪声模式，所以我的增强策略比常规目标检测要多几个针对性操作。
第一是低光照增强。模拟夜间搜救场景，随机把图像亮度降到原本的 40%~70%，并用 gamma 校正模拟不同光照下的对比度变化。这里我要说下——救援现场不一定都是白天，夜间搜救非常常见，如果模型只学过硬光下的图像，夜间基本废掉。
第二是模糊增强。模拟无人机高速飞行、相机抖动、火灾烟尘造成的图像模糊，用高斯模糊和运动模糊随机叠加。运动模糊尤其重要，因为无人机巡航时产生的画面模糊会极大影响小目标检测。
第三是遮挡增强。我自己写了一个随机遮挡算法，随机在画面上放置几个不规则的黑色矩形，模拟废墟遮挡或烟雾遮挡。这个增强说实话有一定风险，如果遮挡率太高会损坏真实标注框，参数需要反复调。我最终控制在每个样本最多遮挡 2 处，每处面积不超过图像面积的 5%。
第四是色彩偏移。灾难现场由于火光、粉尘和积水，图像色调往往偏红、偏灰或偏蓝，用随机颜色扰动来模拟。
这些增强操作建议在训练时用 albumentations 在线做，而不是保存增强后的数据到硬盘上。在线增强的好处是每轮 epoch 看到的增强结果都不一样，相当于间接把数据集扩大了好几个量级。
3. 模型训练与推理实现
3.1 训练配置：从预训练权重开始迁移学习
灾难场景数据虽然和 COCO 有差异，但底层特征（边缘、纹理、形状）是通用的，所以我没有从零训练，而是加载 YOLOv8 的 COCO 预训练权重迁移学习。这样能大幅缩短收敛时间，也避免灾难数据不足导致的过拟合。
训练命令如下，我用的 ultralytics CLI 方式：
yolo train data=disaster.yaml model=yolov8m.pt epochs=100 imgsz=640 batch=16 device=0 workers=8这里我解释几个配置的考虑。模型选的是 yolov8m（medium）而不是最大的 x，因为在灾难救援场景的常态化部署中，推理速度比极致精度更有价值，m 的参数量在速度和精度之间比较平衡。如果你显存有限，换成 yolov8s 也可以，精度大约降 3~5 个百分点，但推理速度会快很多。
epochs 设的是 100，配合早停策略（patience 设为 15）。实际训练在第 80 轮左右达到最佳验证 mAP，后面再训练反而过拟合了，早停帮我省了很多时间。
3.3 推理脚本与中英文输出的实现
训练完成后，我封装了一个完整的推理脚本，读取视频文件或摄像头流，实时输出检测结果。
3.3.1 推理核心流程设计
推理脚本大概分为四步：加载模型、读取视频帧、前向推理、后处理与绘制。用 Ultralytics 的 YOLO 类可以几行搞定，但为了便于集成到实际救援系统中，我手写了后处理和绘制逻辑。
代码示例：
from ultralytics import YOLO import cv2 model = YOLO("runs/detect/train/weights/best.pt") cap = cv2.VideoCapture("test_video.mp4") while cap.isOpened(): ret, frame = cap.read() if not ret: break results = model.predict(frame, conf=0.35, iou=0.5, verbose=False) for result in results: boxes = result.boxes for box in boxes: x1, y1, x2, y2 = box.xyxy[0].tolist() conf = float(box.conf[0]) cls_id = int(box.cls[0]) label = model.names[cls_id] cv2.rectangle(frame, (int(x1), int(y1)), (int(x2), int(y2)), (0, 255, 0), 2) cv2.putText(frame, f"{label} {conf:.2f}", (int(x1), int(y1)-10), cv2.FONT_HERSHEY_SIMPLEX, 0.6, (0, 255, 0), 2) cv2.imshow("Detection", frame) if cv2.waitKey(1) & 0xFF == ord('q'): break这段代码逻辑直接，但注意几个细节。conf 阈值我调到了 0.35，这个数字是我反复测试后选的。为什么不是默认的 0.25？因为在灾难场景中，低置信度的检测很多其实是背景噪声，0.25 会导致太多误报；但调到太高又会漏掉真正被遮挡的人体。0.35 是我的经验折中点，建议你根据自己的验证集指标微调。
3.3.2 中英文双语输出的实现方式
中英文双版的实现我在前面设计时已经提过：模型内部用英文标签，在页面/输出层做映射。具体到推理脚本中，我维护了一个标签映射字典：
class_map = { "person": {"zh": "人员", "en": "person"}, "face": {"zh": "面部", "en": "face"}, "helmet": {"zh": "头盔", "en": "helmet"}, }在绘制时读取配置的语言字段，选择对应的标签文字。这里我额外做了一个处理：中文字体在 OpenCV 里是没有的，直接用 cv2.putText 显示中文会乱码。所以我把绘制部分改成用 PIL 先把中文画到透明图层上，再贴到原图。
from PIL import Image, ImageDraw, ImageFont def draw_text_cn(img, text, pos, scale=2): overlay = Image.fromarray(img[..., ::-1]) # BGR to RGB draw = ImageDraw.Draw(overlay) font = ImageFont.truetype("NotoSansCJK-Regular.ttc", 20 * scale) draw.text(pos, text, font=font, fill=(0, 255, 0)) return cv2.cvtColor(np.array(overlay), cv2.COLOR_RGB2BGR)这个痛点是很多人不会提前想到的——你辛辛苦苦训练好了模型，结果界面上中文显示乱码，所有努力看起来像半成品。提前把这个坑填好，演示的时候会省很多尴尬。
3.4 导出到部署格式与推理加速
模型训练好后，如果只是在电脑上用 Python 推理演示，那没问题。但实际部署场景中，救援现场往往没有高性能 GPU，可能是只有 CPU 的笔记本或者边缘盒子。这时候就必须做模型导出和推理加速。
我的做法是导出为 ONNX 格式，再用 ONNXRuntime 做 CPU 推理。命令如下：
yolo export model=best.pt format=onnx opset=12 simplify=True这里讲一下为什么用 ONNX 而不是直接用 PyTorch。PyTorch 推理在 CPU 上慢得可怜，因为框架本身有大量动态图开销；ONNX 是静态图，经过优化后 CPU 推理速度可以提升 3~5 倍。实测下来，我导出的 ONNX 模型在普通笔记本 CPU 上大约 40~60ms 一帧，勉强做到 20 FPS 左右，对于灾难场景这种不追求极高帧率的任务已经完全够用。
如果进一步加速，可以导出 TensorRT 格式，但 TensorRT 只能在 NVIDIA GPU 上使用，且环境配置比较折腾，我当时没有在演示机上用它。如果你的目标是部署到 Jetson，建议直接用 Ultralytics 官方提供的 TensorRT 导出支持。
4. 常见问题排查与性能调优
4.1 训练 loss 不下降怎么办
这是我第一次跑灾难数据时遇到的第一个问题。前 20 轮 loss 下降明显，但从第 30 轮开始几乎不降了，而且验证集 mAP 也很低。
我排查下来的原因有两条。第一，学习率设得太高。我一开始用的是 0.01，在 COCO 大规模数据集上这个没问题，但我的灾难点 8000 张图像规模较小，0.01 容易震荡。我把 lr0 调整为 0.005，并用预热机制，前 3 轮慢热。第二，数据平衡问题。我的数据集中正常姿态的人占大多数，被遮挡的人实例相对少，导致模型对遮挡人学习不充分。这个问题的解法是在数据增强中提高遮挡增强的出现概率，把遮挡样本比例从 20% 提到 40%，但不改变增强强度。
如果你想快速验证是否是数据问题，可以先把 batch_size 调小，跑 10 轮观察 loss 曲线。如果 loss 正常下降，说明数据没问题，问题在超参数。
4.2 误检严重：模型把废墟砖块当成人员
这是灾难场景检测的经典问题。我第一次测试时，视频里地面的碎裂砖块结构被大量标成了人，而且置信度还很高，达到了 0.6 以上。
误检的主要原因有两个：一是灾难现场碎石块、倒塌墙体和人的纹理确实高度相似，二是我的训练数据中被遮挡人实例不够多，模型无法区分“看起来像人的纹理”和“真的是人”之间的边界。
我的解决方式是三步走的。第一步，在验证集上统计误检区域，把误检样本可视化出来，发现大部分误检集中在纹理丰富但结构不规则的区域。第二步，给训练数据增加明显负样本——也就是在图像中标注一些“不是人但纹理很像人”的区域，类别设置为 background。这不是正统做法，但很有效。第三步，调高置信度阈值。我把推理阈值从 0.35 调高到 0.45，误检率下降了一半左右，代价是部分遮挡人被漏掉。
这里要提醒，如果你手动增加了 background 负样本，要注意不要让超过 10% 的标注框是背景框，否则模型会过度倾向于预测背景。
4.3 漏检严重：模型对远处的“小目标”完全失效
灾难场景里，无人机在高空拍摄，画面中的人往往只占几十个像素。模型在这个尺度上频繁漏检。
小目标检测是个老难题。YOLOv8 的原生检测头对低分辨率目标效果不佳，因为下采样倍数太大，小目标的特征到深层时已经丢失。我的应对方案有两个。
第一个方案是提高输入分辨率。从默认的 640px 提高到 1280px，这样小目标在输入图像中的像素会变大，特征更充分。但代价是推理速度明显变慢，CPU 上基本跑不到 1 FPS。所以我只在离线图片分析时用这个方案，视频推理保持 640px。
第二个方案是用 tiling 切图检测。把一张大图切分成多个小图块，每个图块单独送入模型推理，最后把检测结果按坐标合并回原图。tiling 方案的优点是可以用原模型的精度处理小目标，缺点是需要后处理合并逻辑更复杂，容易出现一个目标被多个图块重复检测的情况。我写了一个非极大值抑制后的合并函数，处理重复框时保留置信度高的框。
4.4 摄像头视频流卡顿与延迟
演示的时候遇到一个尴尬情况：用 OpenCV 读取大分辨率视频文件，检测过程把每一帧都做前向推理，导致画面明显卡顿。
排查后原因有两个。第一，OpenCV 的 VideoCapture 默认读取的帧率不受控，它按照视频的原始帧率读取，但检测速度跟不上，于是 accumulate 了大量帧缓存，延迟越来越大。第二，我的推理循环是串行的，读帧、推理、绘制全都在一个线程里。
我的解决方案是引入双缓冲队列。用另一个线程专门读取视频帧，主线程做推理，用队列隔开，控制队列长度避免无限缓存。代码上很直接，但效果提升明显，演示时视频流流畅了很多。
这里也可以合理调节跳帧策略：如果检测速度确实追不上视频帧率，可以每 N 帧检测一次，N 根据实际表现动态调整。视频流检测不必做到逐帧，因为相邻帧之间的目标位置变化很小，跳帧不会造成大的漏检。
4.5 不同光照条件下的鲁棒性问题
夜间和强逆光场景的检测结果明显下降。虽然训练时做了低光照增强，但实际夜间救援现场的光照（比如探照灯直射）跟简单的亮度降低完全不同。
后来我增加了一个独立的夜间数据集增强管线：把图像分割成不同亮度区域，对暗部做局部增强，对亮部做局部压缩，模拟探照灯的强烈对比度。改成这类自适应光照增强之后，夜间检测的 mAP 提升了接近 8 个点。
这一点的经验是：不要以为做了一遍增强就万事大吉，要看实际测试中的失败案例，再针对失败模式设计新的增强方法。数据增强的本质是模拟测试时的分布偏移，而灾难场景的分布偏移往往比我们想象的多得多。
5. 效果演示与源码结构分享
5.1 演示视频的制作方法
一个项目能做到让人信服，演示视频的质量很关键。我之前踩过坑：模型做完了，但没有录一个像样的演示视频，结果汇报的时候很难直观展示效果。
这次我录制的思路如下：我准备了三段测试素材，第一段是无人机视角的模拟地震废墟场景，第二段是低光照的室内火灾场景，第三段是拥挤的避险场景。每条视频都左右分屏显示，左边是原始视频，右边是检测结果叠加。这样观众可以一目了然地看到模型在对应场景中的表现。
叠加信息里不仅仅有检测框，我还加了一个框计数器和平均置信度。框计数器显示当前帧检测到的人数，在救援场景中这就是“这个区域有多少人待援救”的核心数据。平均置信度可以作为系统可信度的参考，如果平均置信度掉到 0.4 以下，说明当前环境对模型不友好，需要提醒用户谨慎依赖结果。
录制工具我直接用 OpenCV 的 VideoWriter，把检测后的帧序列写为 MP4 文件。注意编码器选择 mp4v，不然在某些播放器上会出现兼容性问题。
5.2 完整源码的整体结构与关键模块
不少同学喜欢把训练和推理的代码全堆在几个大文件里，我以前也这样，后来维护成本太高。这次项目为了能够分享，我按功能拆了目录。
disaster_detection/ ├── data/ │ ├── dataset.yaml │ ├── labels_cn.json │ └── labels_en.json ├── models/ │ └── best.pt ├── scripts/ │ ├── train.py │ ├── val.py │ ├── inference.py │ └── export_onnx.py ├── docs/ │ ├── README_CN.md │ └── README_EN.md └── samples/ ├── test_1.mp4 ├── test_2.mp4 └── result_1.mp4labels_cn.json 和 labels_en.json 是前面说的双语映射表，用 JSON 维护的好处是，项目交付后，如果客户希望加一个日语版本，只需要新增一个 JSON 文件，完全不用改代码。
训练脚本里关键是 data.yaml 一定要指向正确的数据集路径，我昨天刚看到有人把路径写错导致训练时一直报错“No labels found”。这类问题很蠢但也最容易出现，建议在脚本开头用 os.path.abspath 自动定位绝对路径，避免因为启动位置不同导致路径失效。
5.3 效果演示数据与体验小结
我自己评估下来，最终模型在验证集上的 mAP50 达到了 89.4%，mAP50-95 是 71.2%。这个数字在目标检测里不算拔尖，但在灾难场景这种复杂背景下已经说服力绰绰有余。在实时推理方面，云端测试单帧耗时约 16ms，CPU 上运行 ONNX 大约 48ms，可以满足基本的实时监测。
不过我更看重的是现场测试里那些数字：在我录制的三段演示视频中，第一段无人机视角的检测准确率最高，几乎没有误检；第二段低光照场景中偶有一两个漏检，但整体稳定；第三段拥挤场景中互相遮挡严重，漏检率有所上升，但置信度阈值调低到 0.35 后有了明显改善。这些才是更能反映实际使用体验的结论。
6. 最后再分享一点个人的心得体会
项目做到这里，我最深的感觉就是，目标检测的模型训练只占整个项目三分之一的工作量，更多的精力花在了数据、工程和演示细节上。双语标签、切图检测、ONNX 导出、视频拼接，这些看起来不炫技的工作，恰恰是项目能否被落地使用的关键。
如果再给我一次机会，我会从一开始就把版本管理做得更好。项目前期我一部分代码在本地，一部分在云端，数据集也分散在不同目录，中间出现过一次标注文件丢失的情况，损失了好几天工作量。后来统一用 Git 管理代码，数据集也集中到规范目录，配合定期备份，再没出过这种问题。建议你们从一开始就按这个规范来。
还有一个小技巧：不要把模型直接拿来做最终部署，先用一段完全没参与训练的“边角料”视频测试。你训练时用过的验证视频，模型多多少少会产生过拟合记忆，表现会偏高。边角料视频里的检测结果才是真实水平。我后来把一段不同设备拍摄的素材加了进去，发现表现下降了约 5%，这才是项目的真实性能。
这个系统目前还只是一阶段的单模型方案。后续如果要做得更强，可以考虑加入骨架关键点检测来辅助判断“人是否活着”，或者接入多目标跟踪实现人员的持续定位。但这些都是下一个迭代的事了。这次分享的主要是把第一条链路走通——从数据到训练到推理再到演示，希望能给同样在折腾 YOLOv8 垂直场景的朋友一点参考。
