我做无人机视觉落地也有几年了，今年被问得最多的问题不是“模型怎么调”，而是“模型怎么到了现场就不灵”。很多朋友拿着公开的航拍检测模型，在桌面演示上mAP能到七八十个点，可一部署到国内的十字路口、老小区、城乡结合部，漏检和误检排着队来。问题不在模型架构，在数据本身。国内的车流形态、道路结构、建筑密度、拍摄习惯，和公开数据集里的国外街景完全是两套逻辑。我参与构建了一套面向国内场景的无人机车辆行人检测数据集，从采集、标注、训练到在智慧交通和应急救援两个方向的实际落地，整套流程都走了一遍。这篇文章就把这套数据集本身、背后的设计取舍、以及跑项目时踩过的坑，完整拆开来讲。
1. 公开数据集的“水土不服”：为什么必须自建国内场景数据集
1.1 公开航拍数据集与国内实际场景的三大落差
先说一个很多人没意识到的点：公开能拿到的无人机航拍检测数据集，主流来源基本是高校实验室和科研机构发布的场景库，拍摄地点多是国外城市、校园周边、高速路网，目标尺度偏大、场景开阔、光照规整。用它们做算法预研、打竞赛、验证模型结构完全没问题，但放到国内真实业务现场，立刻会撞上三堵墙。
第一堵墙是目标尺度的分布差异。公开数据集里的车辆，在画面里往往能占到几十乘几十像素，而国内无人机安防巡逻常用的飞行高度是80到120米，搭配普通可见光云台，一辆轿车在1080P画面里通常只有15到25像素宽。行人更夸张，基本在8到12像素之间。模型在公开数据集上长大的“目标感”偏大，一到国内实际航线，小目标召回天然吃亏。
第二堵墙是交通形态完全不同。国外数据集里最多是轿车、皮卡、巴士，道路规整、车道清晰。但国内场景大量存在三轮车、电动自行车、老年代步车、混行的非机动车道，而且违停、逆行、占用对向车道这些现象是常态。模型不认识三轮车，就会把大量该检出的目标漏掉，或者把三轮车认成“奇怪形状的小卡车”，对交通违法识别这种业务来说，这就是事故。
第三堵墙是场景纹理和背景复杂度。国内的老旧小区、城中村、建材市场，屋顶有太阳能板、彩钢棚、晾晒物，地面有地摊帐篷、施工围挡、堆料，这些杂乱背景在航拍俯视视角下会产生大量“伪目标纹理”。国外干净的道路和高尔夫草坪式背景训练出来的模型，遇到这些纹理很容易把空调外机、蓝色彩钢棚当车，把树荫里晃动的光影当行人。
这三堵墙，不是靠数据增强能绕过去的——增强只能让模型更鲁棒，但无法教会模型“认识”它从未见过的目标形态和场景分布。所以，要真正服务国内场景，就必须有国内场景的数据打底。
1.2 更深的错位：标注体系与业务指标对不上
比图像差异更棘手的，是标注体系跟业务需求之间的错位。公开数据集里的类别体系是学术导向的，比如“car”“truck”“pedestrian”，粒度到目标类型就停了。但实际业务里，智慧交通要的是“这辆车是不是违停”“这辆电动车是不是走了机动车道”“这个路口是不是发生了拥堵聚集”。
应急救援更典型。搜救场景里，模型要回答的不只是“这里有人”，而是“这里有人倒下/被困/聚集待援”。这些是任务级的语义，如果数据里只有“person”这个类别，下游业务就得写一堆后处理规则去猜，猜来猜去极易误报漏报。
所以我们这套数据集在设计之初就没按学术分类法走，而是按任务场景反推标注体系，把目标分成基础类别和业务属性两个维度。基础类别解决“是什么”，业务属性解决“该不该报警”。这样的数据才能真正接得住业务指标，而不是模型AP很好看，用户却用不起来。
2. 数据集的构成与组织：从原始航拍到标签文件的完整拆解
2.1 采集区域与覆盖策略
一套能用的数据集，第一件事是回答一个问题：我到底要覆盖哪些场景。我们当时没有贪多求全，而是聚焦三个最能代表国内无人机常态化巡逻需求的地方，我按项目内部编号叫它们A区、B区和C区。
A区是城市核心商务区，特点是高楼密、玻璃幕墙多、十字路口规整、人车密集。这个区域主要服务违停识别、路口车流量统计。
B区是城乡结合部，自建房密集、道路窄、三轮车和电动车大量出现、白天有集市、夜晚照明条件差。这个区域用于测试模型在“无序交通”下的表现。
C区是河滩、树林和疏浚工地，属于应急救援演练常选的野外环境。这里车辆少、行人散落、植被遮挡严重，目标经常处于半遮挡状态。
采集高度上，我们做了四档：30米、50米、80米、120米。30米和50米的画面能看清车辆细部，适合标注“车型”“颜色”属性；80米和120米则是实际巡逻里最常用的巡航高度，大量小目标样本要从这两档里来。角度以45度斜视和90度俯视为主，斜视贴近云台手操作习惯，俯视贴近航线任务模式，两者都保留，模型才不会在某个姿态下“偏科”。
时段上，白天和黄昏是大头，各约占四成，夜间约占两成。夜间样本我们特意留了低照度下的路灯环境，因为安防巡逻最关键的恰恰是夜里。
2.2 类别体系设计：基础类别与业务属性分离
这套数据集的类别体系，我会建议任何做落地场景数据集的人都参考一下。它把标注内容拆成两层：
第一层是基础检测类别，覆盖车辆和行人两大类。车辆类细分为轿车、SUV、面包车、货车、卡车、巴士、三轮车、摩托车、电动车；行人按状态再拆为站立行人、骑行人员、聚集人群、倒地人员。有人会问：倒地人员和站立行人，模型能区分吗？单帧静态确实困难，所以我们把“倒地/异常姿态”类主要放在静态特征强烈的样本上（如完全躺平、四肢展开），其他模糊情况一律标为站立行人，由时序模型在推理阶段补充判断。
第二层是业务属性标签，它不是目标框的内容，而是目标框的附加字段，包括“是否处于路口”“是否停在非泊位区域”“是否为静止目标”这类交通业务属性，以及“是否处于植被遮挡下”“是否位于水域附近”这类救援业务属性。标注时把这些属性记在JSON里，训练时基础检测头只吃框坐标和类别，业务属性则用来做后续的任务模型微调。
这样设计的好处是：一套数据可以在两个场景间复用。训练基础检测器时，两类目标一起进模型；做交通业务时，用属性过滤出违停车辆；做救援业务时，用属性过滤出高危目标。不用每次换场景都重标一遍底库。
2.3 目录结构与标注格式落地方案
数据规模上，整套数据集最终保留标注图像约3万张，检测框实例总数超过15万个。3万张听起来不算海量，但配合多高度、多时段、多场景的覆盖，实际训练出来的泛化能力明显优于直接拿公开数据集跑。因为无人机航拍连续帧之间大量重复，我们做了严格的去重筛选，保证同一条航线中相邻帧的相似度不超过阈值，让每张图都贡献独立信息。
标注格式我们同时导出了YOLO的txt格式和COCO的JSON格式。YOLO格式方便训练时直接读入，COCO格式方便做评测和可视化。这是项目里一个很实际的取舍：不要只留一种格式，团队里总有人要用另一种。
一条标注文件的示例大致长这样：
# 图片 <final_train/images/A_120m_day_traffic_00412.jpg> # 对应样本：轿车型车辆，目标较小，轻微遮挡 11 0.452381 0.327604 0.031846 0.024398 23 0.733254 0.284117 0.018742 0.012594前一个数字是类别编号，中间两个是归一化中心坐标，后两个是归一化宽高。我们专门做了目标尺寸分层统计，把最小目标下限定在6像素宽。小于6像素的实例不标，因为6像素以下连人工都难以确认，标了反而会引入大量噪声标注，训练时模型只能学到错误纹理。
目录结构按照深度学习项目的标准做法组织：
├── final_train │ ├── images │ └── labels ├── final_val │ ├── images │ └── labels ├── final_test │ ├── images │ └── labels ├── annotations │ ├── dataset_coco.json │ └── dataset_attrs.json └── data.yaml这里特别说一下数据划分的策略：划分维度是“场景”，不是“帧”。同一条航线的前后帧如果分别被划进训练集和验证集，验证分数会虚高，模型像是“背过答案”的考生。我们按航线ID整体划分，保证验证集里的画面和训练集完全来自不同航线。这是很多人容易忽略的细节，但影响极大。
3. 两个落地场景的差异化打磨：智慧交通与应急救援的双线复用
3.1 智慧交通场景：从“看见车辆”到“读懂违章”
智慧交通是这套数据集的第一个主战场景。我们内部跑通了一条完整的业务流：无人机按既定航线巡航，视频流实时接入机载算力或者地面站，检测模型输出目标框，后台跟踪算法把同一辆车跨帧关联，再利用GPS位置和地图网格判定这辆车所在区域是否属于可停区域。
只看车辆检测还不够，违停识别最大难点是“静止车辆”与“堵车缓行车辆”的区分。数据集中专门补充了静态车流场景，把路口排队、红绿灯等待、停车场、违停路段四类“车停着”的情况都做了充分标注。模型学习的是视觉特征，但“是不是违停”依赖的是目标在空间网格上的位置语义，这就需要属性标签里的“是否位于非泊位区域”“是否静止”信息来支撑。
非机动车道占用检测也很有代表性。国内大量路口存在电动车和自行车骑上机动车道的现象，这类目标小、速度快、形态多变，公开数据集几乎无法提供样本。我们在B区专门采集了混合交通流数据，把骑行人员单独设为一个基础类别，模型成功把这类目标的召回率从接手时的不到四成，提到了稳定七成以上。这个提升直接决定了客户愿不愿意把你这套系统接到他的大屏上。
3.2 应急救援场景：从“检出人群”到“判定受困状态”
应急救援场景的做法和交通有很大区别。交通场景路况相对可控，目标是细分类和属性判定；救援场景里目标极度稀疏、光照恶劣、背景极端复杂，你需要在“有人的画面”里找人，还需要判断人的状态。
比如河滩搜救演练，人员穿着和河滩砂石、枯草高度相似，躺倒的人从80米高度看下去，就是浅色背景上一小块灰色。这种目标，常规检测模型很容易当成地面纹理。我们针对性地在数据集中增加了“倒地人员”类别，采集了大量不同姿势、不同环境下的躺倒人员样本。模型在低可见度条件下对单个人的召回率，靠新增样本直接提升了十几个百分点。
夜里搜救是另一个硬骨头。单靠可见光，低照度下目标几乎看不清，我们对这类场景的策略是保留样本但降低预期：可见光模型负责检出“疑似目标区域”，再用热成像或高倍变焦二次确认。数据集中保留的夜间样本，保证了模型至少不会在夜里盲目漏掉所有目标，能给飞手提示“这里要看一眼”。
3.3 一个数据集两套标准的共存与取舍
一套数据同时服务两个场景，必然遇到类别定义上的冲突。行人这个类别，交通场景里就是过马路的普通人，救援场景里却可能是需要救助的被困者。我们不能建两套物理数据，但可以一套数据两套逻辑。
具体做法是：训练检测模型时使用统一的基础类别，也就是前面说的“轿车/SUV/行人/倒地人员”这套层次；业务侧在推理时通过属性标签继续灰度判断。比如倒地人员类别，既服务救援场景的“受困人员预检”，也能在交通场景中提示“有人跌倒需要处置”。实测下来，基础检测模型只需要一套权重文件，业务系统按需挂载属性分类模型或者规则引擎，两个场景都跑得通。
4. 用这套数据集训练检测模型的完整实践
4.1 模型选型：为什么以YOLO系为基线
目标检测模型现在可选范围很广，但我们最终以YOLO系作为主要基线。理由很朴素：无人机机载算力受限，边缘设备上要跑实时视频流，YOLO系列的推理速度和部署成熟度最稳。项目内部也对比过基于注意力机制的检测模型，精度确实更好，但推理速度在机载设备上撑不住30帧，业务上只能放弃。
具体版本上用了YOLOv8和YOLOv9两种做对比。YOLOv8训练稳定、生态好、文档全，适合起步和做基线；YOLOv9在部分小目标样本上的精度略高，但训练更吃显存和调参。我们的结论是：如果算力紧张、快速出结果，选YOLOv8m；如果后面要做切片推理提升小目标精度，可以尝试YOLOv9c。
4.2 训练配置：小目标场景下的关键参数调优
针对无人机航拍的小目标特点，训练配置有几个地方值得重点讲。
第一个是输入分辨率。常规目标检测默认608或者640，无人机航拍完全不够。我们把训练尺寸直接拉到了1280，推理时保持1280。分辨率提升带来的计算量上涨明显，但小目标召回率的收益更明显。实测从640升到1280，小目标AP大概能提8到10个点。如果你的机器实在带不动1280，至少也建议拉到960，再低就不太建议了。
第二个是多尺度训练。航拍场景目标尺度分布极宽，同一张图里既有占半个画面的巴士，也有只占百分之二像素的行人。我们开了多尺度训练，从960到1600之间动态随机缩放，让模型同时适应不同飞行高度下的尺度变化。
第三个是Mosaic增强策略。Mosaic一直是YOLO训练的好帮手，但在无人机场景里要注意，它对小目标其实是双刃剑：四张图拼一起，小目标会进一步被缩小，甚至缩到消失，相当于给样本引入了强噪声。我们的做法是前150个epoch用Mosaic，后面50个epoch关掉Mosaic，让模型回到真实分布的稳定精调阶段。
第四个是负样本策略。数据集中专门划出约800张无目标空场景图，不放任何标注框，作为负样本参与训练。这些图里有屋顶、停车场、河滩、树林，全部是为了压住误报。负样本对减少树影、彩钢棚误检的作用非常直接，强烈建议做落地场景数据时预留这一部分。
一个简化的训练配置参考如下：
# data.yaml 片段 train: final_train/images val: final_val/images test: final_test/images nc: 14 names: ['car', 'suv', 'van', 'truck', 'bus', 'tricycle', 'motorcycle', 'ebike', 'standing_person', 'cyclist', 'crowd', 'lying_person', 'water_vessel', 'barrier']# 训练命令示意 from ultralytics import YOLO model = YOLO('yolov8m-seg.pt') model.train( data='data.yaml', imgsz=1280, epochs=200, batch=16, device=0, workers=8, mosaic=1.0, close_mosaic=50, hsv_h=0.015, hsv_s=0.5, hsv_v=0.3, scale=0.5, )4.3 评测方式：不只看全局mAP，还要拆开看子场景
评测是这次项目里我认为最能帮到同行的一个环节。一套统一指标走天下是不够的，我们建了一套分层评测体系：
- 按目标尺寸分：小于16像素、16到32像素、大于32像素三档，分别看AP。小目标档位直接决定航线高度能否放开。
- 按时段分：白天、黄昏、夜间三个子集。夜间的AP下降多少，直接决定客户敢不敢让你夜里飞。
- 按场景分：A区、B区、C区单独出指标。很多模型在A区能达到较理想水平，到B区却掉得很厉害，如果不分层看，根本发现不了问题。
提示：评测时尽量使用COCO的API做标准化评测，不要只在训练日志里看曲线。训练曲线loss降得快，不代表小目标AP真的高，甚至可能只是背景学得好。
分层评测里我们发现过很典型的问题：某个版本在全局mAP上比旧版高2个点，但按高度一拆，80米和120米档位的召回率反而掉了3个点。原因是我们增加了大量大目标样本，把模型的容量吸走了一部分。如果不拆开看，这个模型就带着“整体更好”的错误结论上线了。
5. 数据生产中的真实教训：标注误差、类别不均衡与误检治理
5.1 标注误差对小目标检测的放大效应
数据生产走过一轮之后，最想说的一条教训就是：小目标场景下，标注误差对模型的影响会被放大很多倍。
一张800像素宽的画面里，一个12像素的小目标框，中心偏移1个像素、宽高偏差1个像素，相对误差就接近10%。而这个框进入训练后，模型会在它的邻域反复学习“正确”和“错误”两种特征，等于让同一个目标提供了矛盾样本。我们第一版模型的小目标AP始终上不去，排查后发现问题就出在质检环节：标注员在小目标上普遍存在2像素左右的偏移。
最后我们将质检规则改成“小目标像素差超过1.5像素必须返工”，并单独做了一轮小目标专项复标。仅仅这一项，小目标AP提升了近3个点。所以如果你自己建数据集，请对小目标框做单独质检，不要和大目标用同一套容差标准。
5.2 类别不均衡的治理：让三轮车和骑行人员被充分看见
类别不均衡是第二个坑。初始数据里轿车、SUV样本占比高，三轮车和骑行人员样本少，训练结果就是前者AP普遍较高，后者常被漏检。而业务上对这些“少数派”恰恰很敏感。
治理思路有三个，可以组合用：
- 数据加权：按类别样本反比设置loss权重，让少量类别获得更大的梯度贡献。
- 重复采样：三轮车和骑行人员样本做拼图增强，同一目标多角度、多时段的复制版合并训练。
- 定向补充：回采集区域专门补录三轮车、电动车密集的路段，把这两个类别的样本量补到与主要类别差距不超过3倍。
这是一个持续迭代的过程。我们的经验是不要企图一步到位，先把模型跑起来，再去看混淆矩阵里哪些类别的召回明显低，定向补数据比盲目堆数量高效得多。
5.3 误检雷区实测：树影、车顶、彩钢棚
误检大概是每一轮测试必遇到的问题，而且误检的对象总是出奇一致。
树影误检是第一名。阳光强烈时树枝在地面投下密集晃动阴影，模型经常把其中某块明暗变化明显的阴影判断为行人。这类误检靠调整置信度阈值压不掉，压到0.6确实能去掉不少，但也会误伤大量真实小目标。我们的做法是让负样本集中加入大量树影场景，模型学到的目标是“行人轮廓+与地面的相对关系”，而不是简单的“局部暗块”。
车顶误检也很有意思。深色车的车顶、天窗区域，在高分辨率图里经常被模型认成另一个目标，最常见的是把SUV天窗当骑行人员。我们分析是样本里行人多为深色衣服、集中在亮背景，特征上与“亮色天窗+深色车顶”过于接近。解决方式是补了一轮“车辆车顶区域标为忽略区”的精细化标注，让模型在训练时明确知道那是车辆的一部分，不用单独预测。
彩钢棚和蓝顶棚在城乡结合部极常见，色调和天空接近，边缘在俯视视角下又规整，容易误认为车顶。我们的对策是加大这类背景的负样本比例，并且调整检测头的锚框尺度匹配，让模型对“过大块面的矩形目标”更克制。
注意：这些误检治理没有一次性方案，每一轮测试都可能出现新雷区。项目上最好把误检样本持续回收，每周固定回灌一次负样本，模型才会越来越“懂事”。
5.4 验证集设计：别让航线的“惯性”骗了你
最后一个易踩的坑，在验证集上一个坑前面简单提过，这里展开说一下。无人机执行航线任务时，帧与帧之间有很强的空间相关性，如果验证集是从所有素材里随机抽帧得到的，那训练集必然会包含同一航线其他帧的画面。这类画面目标位置、角度、光照几乎一致，模型对它们“过拟合”得非常自然，验证AP会虚高。
我们当时的验证集设计改成两部分：一部分从已覆盖的航线中按场景抽帧，另一部分是完全新飞一条独立的、训练阶段从未见过的航线。训练过程中实时看已覆盖航线验证集的指标，每轮迭代后再独立航线上快速验证一遍。两者差距如果超过5个点，就说明模型已经过拟合既有航线，需要重新评估数据增强或者采样策略。
这种做法在项目交付中极其重要。客户最终看的不是你的验证集AP，而是你飞到他们的地盘上漏不漏检。别让数据划分帮你“作弊”。
数据之外的几句经验
整套流程走下来，我最想分享的心得其实就一句：数据集的价值不只是“让人工智能跑得更准”，而是让项目团队逼着自己先把业务定义清楚。我们前期花了大量时间讨论类别体系和属性标签，当时觉得费劲，后面训练、部署、验收反而越来越顺，因为业务指标在数据里早就有对应物了。
如果你想做类似的事情，我给三条最实在的建议：第一，数据采集前务必把业务场景按“风险等级”排优先级，先采集最影响客户感知的那部分；第二，小目标质检标准单独定，不要省这一步；第三，预留至少一成以上的负样本预算，误报清零永远比召回提升更难。下一步我们计划把红外模态加入数据采集序列，让全天候巡逻不再依赖运气，到时候再回来更新这套数据集构建方案的实际效果。
