路面病害检测这几年在计算机视觉领域算是“老话常谈”但我发现真正能把一套系统从算法选型、数据集制作一路做到可用的工程化部署能讲清楚的人其实不多。这个项目标题——基于YOLO系列的路面坑洞检测系统设计与实现——我在实际项目里完整走了一遍从最早拿现成权重在测试图上跑着玩到最后在边缘设备上实时推流检测中间踩过不少坑。这篇文章就把整条链路拆开揉碎把选型逻辑、数据标注里的门道、训练调参的实操记录、部署优化的取舍都写清楚给正在做类似项目或者打算入坑视觉检测的朋友一个可以直接抄作业的参考。先交代一下背景。很多同学看到“基于YOLO”就以为核心工作是调个库跑通demo实际上真正要交付一个能用的检测系统工作量的分布大概是数据准备占四成训练调优占三成系统集成与部署优化占两成算法代码本身只占一成。这个项目就是围绕路面坑洞pothole这一特定目标搭建完整的数据采集标注流程训练一个高精度高召回的目标检测模型并把它嵌入到一个能够处理视频流、输出检测结果和告警信息的软件系统里。适合的人群很明确有Python和深度学习基础、想了解从算法到落地全流程的学生或工程师。1. 整体方案设计为什么选YOLO系列作为检测底座路面坑洞检测不是冷门方向你随便查都能看到各种论文但绝大多数都停留在算法对比阶段。真正到了系统设计环节第一件事不是选模型而是想清楚检测目标的形态和运行场景的特殊性。坑洞在图像里的特征是边界不规则、内部纹理与周围路面差异大、常常伴随裂缝、积水、阴影干扰。它不是那种“特征极其明确”的物体比如行人、车辆有非常强的结构化特征坑洞更像是一个纹理异常区域。这就意味着模型对大目标和小目标的适应能力都要强浅层特征和深层语义特征都要用得上。YOLO系列在这一点上有天然优势它从YOLOv3开始就引入了多尺度预测不同尺度的特征图分别负责检测大小不同的目标这对坑洞这种尺度跨度很大的目标非常友好——近处摄像头下的坑洞能占满画面的一半远处的坑洞可能只有二十几个像素。再就是实时性。道路检测系统分两种工作模式一种是巡检车后装相机边走边拍一种是固定点位或者手持设备定点采集。两种模式对实时性的要求都很高。巡检车要保证车速在30-60km/h时依然能连续检测每一帧画面固定点位要能对视频流做接近实时的分析。目前的Transformer类检测器在精度上确实有优势但在边缘设备上的推理速度根本跑不起来。YOLO系列是典型的单阶段检测器把目标分类和定位统一在一个卷积网络里完成不需要两阶段方法那种先区域提议再逐框分类的流程因此帧率能高出一个量级在Jetson系列设备上跑个30帧以上很轻松。这个性能余量在做“多路视频流并发”的时候就显得特别重要单路能跑快后面加路数才有的谈。还要考虑工程生态。YOLO系列经过多年迭代社区积累非常厚。无论你用的是哪个版本预训练权重好找导出ONNX和TensorRT的脚本成熟部署到不同平台都有现成案例。做项目最怕的就是算法跑通了部署时卡住YOLO系列的生态能省掉非常多排查成本。2. 数据准备与标注决定模型上限的隐形关键很多人训练完模型发现精度上不去第一反应是调网络结构、换更强的骨干网络实际上大多数精度问题出在数据。坑洞检测的数据集不像人脸识别有海量公开资源高质量的开源坑洞数据虽然有但普遍存在场景单一、天气条件受限、标注不统一的问题。直接用别人现成的数据训练出来的模型换个城市、换个路面材质大概率直接失效。别问我是怎么知道的——我第一次测出来模型在测试集上效果很好结果在一条水泥路面道路上跑了不到两百米误检率直接翻倍。2.1 数据来源与筛选策略数据来源我建议走“公开数据预训练自采数据微调”的组合路线。公开数据集可以选几种典型的做预训练比如常见的坑洞识别数据集、无人机航拍路面数据集或者直接用COCO上预训练好的YOLO权重作为起点。自采数据才是决定你模型能不能用的关键。自采数据不需要一步到位但要保证覆盖度。我当时列了一个数据采集计划表包含以下维度路面类型沥青路面、水泥路面、砖石路面不同材质背景对坑洞检测干扰程度差异很大光照条件晴天强光、阴天漫射光、黄昏低照度、夜间路灯照明天气状态干燥路面、湿滑路面、雨后积水路面拍摄角度平视、俯视、倾斜角度手持设备或车头安装角度不同拍摄距离近处1-3米、中距离3-8米、远处8米以上坑洞状态完好轮廓坑洞、边缘碎裂坑洞、带积水坑洞、带裂缝坑洞、浅层磨损坑洞每组至少采集200-300张有效图像。初期数据量不需要追求太多但是多样性要保证。我自己花了三周时间在不同路段、不同时段采集了大概5000张图像剔除掉严重模糊、遮挡严重、目标过小的剩了4200张能用的。这个数量对于微调一个YOLOv8s模型来说基本够用了。数据筛选这一步值得多说两句。很多同学喜欢把采集到图像全部丢进去训练这其实是错误做法。一定要做质量筛检去掉三类图完全模糊的、目标被树叶或者车辆严重遮挡的、坑洞占据画面面积小于千分之一的。第三类图会让模型学到“在没有坑洞的地方找坑洞”的坏习惯。2.2 标注规范与工具实操标注规范和坑洞检测的最终效果直接相关。项目中的坑洞定义是“路面结构完整性受到破坏形成的凹陷区域”但实际标注时边界怎么画不同人理解完全不同。我整理了一套标注规范项目的坑洞标注遵循以下原则坑洞边界按视觉可见的破损边缘为框不是按坑洞实际物理边缘因为实际边缘在图像上往往不明显如果坑洞边缘有裂缝延伸裂缝不单独标注统一算作坑洞的一部分坑洞内有积水只要还能看出坑洞轮廓正常标注两个坑洞距离较近时如果它们之间有明显的路面结构分隔分别标注如果视觉上已经连成一片标成一个井盖沉陷、施工切割缝都不算坑洞反过来这些区域往往会成为误检来源在后续需要重点观察标注工具我用的是LabelImg和X-AnyLabeling前者是老牌工具适合小批量标注后者支持半自动辅助标注能节省不少时间。但半自动标注有一个坑就是初始模型训练得不够好的时候辅助标注出来的框往往偏大或偏小如果你直接接受了AI的建议标注后面训练出来的模型也会继承这个偏差。我的经验是AI辅助标注只适合做预标注人工修正框的四个边是必不可少的一步。坑洞检出框的贴合度直接影响mAP中IoU的计算结果框偏大或偏小五个像素在0.5 IoU阈值下可能看不出来但到了0.75阈值就很明显了。整个数据集的标注给我最大的感受是坑洞这个目标看起来好标实际上比行人车辆这类目标难很多因为边界模糊是常态必须靠规则约束而不是靠眼睛感觉。标注完成之后做一次全量框检查把所有明显过大过小的框都过一遍值得花这个时间。3. 模型选型对比算力约束下YOLO家族的选择逻辑项目正式进入模型选型阶段时我拿YOLOv5、YOLOv8、YOLOv9、YOLOv10的多个子版本做了横向跑分。这里要明确一个观点选模型不是在精度榜单上挑最高的而是在你的算力预算和实时性要求约束下选最合适的那个。模型版本参数量(M)输入尺寸推理耗时(Jetson Orin Nano)实测mAP 50YOLOv5s7.2640约22ms87.6YOLOv8n3.2640约15ms84.3YOLOv8s11.2640约28ms90.2YOLOv9t2.0640约14ms85.1YOLOv10n2.3640约13ms86.4YOLOv10s7.2640约26ms91.0跑分环境统一为TensorRT FP16推理。需要说明的是这个mAP是在我标注的数据集上训练后的测试结果不同数据集之间不可直接对比主要是看相对差距。结论比较明确如果部署设备是低算力的嵌入式平台YOLOv8n或YOLOv10n是首选因为参数量小、帧率充沛虽然mAP略低但胜在稳定性好社区生态成熟。如果部署设备是巡检车内置的高算力工控机YOLOv10s是最优解mAP最高推理耗时仍然在实时范围以内。YOLOv10没有NMS后处理这个特性在部署时确实省事但它的训练细节有点特殊epoch拉长到300时反而更容易收敛到好的结果这个特点需要留意。如果追求最稳妥的方案我建议中低算力环境还是选YOLOv8n。原因很简单YOLOv8系列的导出工具链和部署案例最多踩坑成本最低。在工程交付时间紧迫的时候不要选最新版本的模型选社区验证最充分的模型。4. 训练实现从预训练权重到高精度模型的调节记录训练阶段是整个项目里可调参数最多、最容易让人反复折腾的部分。我把整套训练方案记录下来希望你能少走一些弯路。4.1 训练环境与参数配置算力方面我用了单张消费级显卡显存24G。在这个显存条件下batch size选16比较合适。如果你用的是8G显存batch size降到4-8输入尺寸从640降到512效果也不会差太多。关键是不要在低显存条件下强行上大分辨率输入。训练关键参数配置如下初始权重YOLOv8s在COCO上的预训练权重Epoch200轮Batch size16输入尺寸640 × 640优化器SGD初始学习率0.01配合余弦退火权重衰减0.0005数据增强Mosaic增强开启概率1.0HSV扰动设置饱和度±0.5、明度±0.4翻转概率0.5这里说一个实测感受坑洞检测的数据增强HSV扰动非常重要。不同光照条件下坑洞的视觉表现差异很大HSV扰动等于免费扩充了大量不同光线环境下的样本。我当时做了一个消融对比不开HSV扰动训练的模型在黄昏低照度测试集上的召回率掉了8个百分点。Mosaic增强在坑洞检测里要特别小心。Mosaic会把四张图拼在一起然后随机裁剪这对小目标检测很有帮助但是坑洞属于中等尺度目标偏多Mosaic拼图后坑洞的上下文信息会被截断模型容易学到“坑洞周围一定有路面纹理”的错误规律。实测下来Mosaic开启概率设成1.0反而比0.5差一些说明Mosaic的上下文扰动对坑洞确实有负面影响。4.2 迁移学习的正确打开方式我强烈建议用预训练权重做迁移学习而不是随机初始化从头训。原因不只是收敛快更大的意义在于预训练骨干网络已经学会了通用的纹理特征、边缘特征这些低级特征在坑洞检测中是共用的。随机初始化从头训200轮mAP大概在80左右而用COCO预训练权重起步同样200轮能到90。差距非常大。迁移学习过程中有一个值得注意的阶段划分。前50轮不要冻结骨干网络让骨干网络随着坑洞数据一起微调。等50轮之后模型逐渐稳定再解冻所有层全量训练。有些教程教你先冻结骨干训头、再解冻全量训这个策略在坑洞数据量比较少时是合理的可以防止骨干特征被少样本破坏。但如果你的自采数据到4000张以上直接全量训练效果更好因为坑洞数据本身的特征分布和COCO差异很大冻结骨干反而限制了模型适配能力。4.3 样本不平衡的处理思路坑洞标注框的尺度分布非常不均衡。近处的大坑洞框面积能到200×200以上远处的小坑洞只有20×20左右。这个时候如果直接训练模型会偏向学习大坑洞的特征小目标召回率会很惨。YOLO系列内部的anchor机制会缓解一部分但不能完全解决。我在训练时做了一项调整将训练集中小目标面积小于32×32的比例统计出来。如果小目标占比低于15%那么我从测试集中选取了部分包含小坑洞的图像以复制粘贴的方式增强到训练集中但注意目标不能直接粘贴在完全无关的背景上要选择同类型路面背景。这个方法粗糙但有效小坑洞的召回率提升了6个百分点。如果你追求更精细的做法可以尝试在训练时使用多尺度训练将输入尺寸在480到800之间随机切换这项操作对大小目标兼顾的效果很明显。4.4 指标观察与过拟合判断训练过程中我不是只盯着mAP每天训练完成之后会单独看Precision和Recall曲线。坑洞检测有其特殊性漏检比误检更危险。漏检一个坑洞意味着巡检车辆直接碾过去可能造成轮胎损坏或悬挂系统损伤误检一个只是多派一次人工复核成本低得多。所以在模型收敛阶段我会刻意选择一个Recall更高但Precision稍微低一点点的checkpoint作为最终模型。怎么在训练过程中找到这个checkpoint很简单train阶段的P-R曲线截距。当Precision接近峰值而Recall还在上升的那段时间里挑一个满足“Recall 90%且Precision 85%”的checkpoint。我当时在160轮附近锁定了这样一个权重比最后200轮收敛的权重在Recall上高了3个点虽然Precision低了1.5个点但整体误检数量在可接受范围内。关于过拟合坑洞数据量不算大训练到150轮以后val loss如果开始缓慢上升说明模型开始记忆训练集细节了。这种情况下有两个选择一是直接停止训练用150轮的权重二是把Mosaic概率降下来降低数据增强强度重新从头训练。我更推荐前者简单直接效果也不差。5. 系统实现从模型到端到端可用的检测系统模型训练完成只是系统的一半。整个检测系统设计为三个核心模块图像采集模块、模型推理模块、告警与可视化模块。下面按模块拆解。5.1 图像采集与视频流管理采集模块有两种输入形式。第一种是实时视频流适用于巡检车或者固定点位摄像头。第二种是本地图像文件或者视频文件批量处理适用于离线巡检数据的后处理。采集模块用OpenCV做视频流读取但要特别小心解码延迟的问题。OpenCV的VideoCapture在读取RTSP流时缓冲区设置不当会导致画面延迟越来越大。实测中我发现用cv2.VideoCapture直接读RTSP流大约半小时后延迟会从500ms增长到3秒以上。解决办法是使用FFmpeg的命令行做拉流解码或者设置CAP_PROP_BUFFERSIZE参数。如果追求更稳定可以直接用FFmpeg的subprocess调用把解码后的原始帧通过管道传给Python这样延迟始终能控制在200ms以内。图像采集频率也值得设计。巡检车车速60km/h时如果每帧都做推理对算力压力很大。我的方案是做抽帧检测每秒抽10帧做检测相邻帧之间做了简单的目标追踪匹配同一个坑洞在连续多帧中都被检测到时取置信度最高的那帧作为最终确认结果。这样既保证了实时性又避免了重复检测上报同一个小坑洞。5.2 模型推理加速与部署推理加速这块模型从PyTorch权重到最终部署踩过的细节不少。核心流程是PyTorch权重转ONNX再转TensorRT中间有一个关键步骤是固定batch size。很多同学在转ONNX的时候不指定动态轴默认导出的是动态batch版本。TensorRT对动态batch的支持没有问题但会损失一定优化空间。我的做法是直接导出固定batch1的ONNX后面如果需要多路并发就开多个推理实例。这样TensorRT可以针对输入尺寸做层融合、内存复用优化实测推理速度比动态batch版本快15%左右。精度上还有一个特别注意——TensorRT的FP16推理。正常情况下FP16对精度影响不大但在夜间低照度图像上有时会出现小坑洞的检测框抖动问题。这是因为FP16的数值范围较小低对比度区域的激活值量化误差被放大了。解决方案是夜间场景单独做一个预处理步骤先用伽马校正提升暗部细节再喂给模型这样能在不退回FP32的前提下保住召回率。如果你要处理的是红外热成像图像这一步更是必不可少。5.3 告警与可视化交互告警模块在PC端和边缘设备端表现不同。PC端我用了PyQt5做图形界面中间件负责接收检测结果界面上实时绘制检测框并附带坑洞坐标、面积估测、置信度三项信息。面积估测需要做像素距离标定不同安装高度的摄像头换算关系不一样这个标定数据存在配置文件中不同监控点位各一份。告警策略上做了两级过滤。第一级是置信度阈值过滤只有超过0.4的检测结果才会进入告警队列。第二级是连续帧确认同一个坑洞在连续三帧中都被检测到才生成最终告警。这两级过滤联合起来能把误报率压到非常低的水平。注意如果你在NMS之前做多帧确认比在NMS之后做效果更好因为NMS会给同一目标只保留一个框多帧确认就需要做跨帧目标匹配麻烦。我最后是在NMS之后增加了一个简单的IoU跨帧匹配效果也不错。可视化方面除了画框我还会在图像下方生成一个实时曲线图显示最近5分钟内的检测数量变化。这个功能在巡检场景中很好用道路养护人员可以直观看到哪一段路面的坑洞密度最高从而决定优先修复区域。6. 常见问题实录误检漏检与性能问题的排查手册这部分我结合自己做这个项目时踩过的坑整理成一个问题排查速查表每一条都是实际动过手之后的结论。问题现象可能原因排查方法解决方案阴影被误检为坑洞训练集中缺少带树影/桥影的图像检查测试样本中误检图的场景分布补充阴影场景训练数据或增加使用负面样本积水反光被误检积水反光的纹理特征与坑洞内部纹理相似单独统计积水反光误检频率增加积水坑洞和干净积水反光作为正负样本对比微调模型远处小坑洞漏检小目标训练样本不足统计训练集bbox面积分布复制粘贴增强小目标或使用多尺度训练策略夜间漏检严重图像整体亮度低特征不清晰可视化夜间中间层特征图加伽马校正预处理或调整HSV增强参数提升曝光鲁棒性高置信度误检集中在井盖区域井盖纹理与坑洞边缘形态相似统计误检框的位置分布增加井盖负样本或引入位置先验过滤规则模型在湿滑路面误检率飙升湿滑路面反光导致坑洞边缘模糊对比干湿路面的特征分布把湿滑路面图像单独作为一个场景类别参与训练或做色彩归一化边缘设备推理速度不达标TensorRT优化不足或模型偏大看TensorRT profiling找耗时层尝试FP16量化输入尺寸从640降到512或换更小的模型变体视频流延迟持续增长解码缓冲区堆积或推理队列阻塞查看CPU/内存占用和队列深度改用FFmpeg拉流使用异步推理队列关于井盖误检我想单独展开一下。很多城市的道路上井盖是圆形的坑洞也是圆形或椭圆形的而且井盖周围常年有沉降裂缝视觉上非常接近坑洞。我一开始训练出来的模型在测试集上mAP很高一跑到市政道路上就疯狂误检井盖。解决思路是数据驱动的我专门采集了300张带井盖的正常路面图像在标注时标注为独立类别“cover”训练的时候这个类别参与损失计算但推理时直接屏蔽掉这个类别的输出。这样模型学到了井盖和坑洞的差异特征误检率大幅下降。这是一个通用做法值得试一下。还有一个比较隐蔽的坑坑洞检测模型的误检和阈值关系密切但是阈值到底设多少不能靠拍脑袋。我的做法是画出一张P-R曲线然后结合道路养护的“漏检代价远高于误检代价”这一事实在曲线上找一个Recall掉点前、Precision相对较高的点。最后选出来的阈值大概是0.35-0.45之间而不是默认的0.25或0.5。每个数据集的最佳阈值都不同这个必须自己画曲线后选择。部署阶段还有一个高频问题模型在小batch推理时速度正常但接上视频流后帧率骤降。这多半不是模型算力问题而是推理线程和采集线程耦合了。图像采集线程和解码、推理在线程模型上分离用生产者-消费者模式设置一个最大队列长度队列满时丢帧而不是阻塞采集。这样即使某一帧推理耗时突增视频流也不会卡死。7. 扩展空间与个人经验总结这个系统做完以后我实际拿它去了一些真实道路场景做测试效果基本达标。但我个人觉得最有价值的不是这一个模型本身而是梳理出来了一套可以复制到其他道路病害检测上的方法流程。裂缝、龟裂、松散、沉陷这些其实都是同一类视觉问题——路面纹理的局部异常。你只要针对每种病害重新采集和标注一批数据换一个输出类别的模型头整套系统就能平移覆盖其他病害类型。后续如果有余力扩展我建议优先做三件事。第一把坑洞检测和GPS定位数据结合输出带地理坐标的路面病害地图这对道路养护部门做巡检计划非常有用。第二加入深度估计或者使用双目摄像头把检测结果从二维框升级成三维尺寸估测能更准确地评估修复所需材料量。第三主动收集误检样本做持续学习每隔一段时间用新数据增量训练一次模型防止场景分布漂移导致精度衰减。最后分享一点个人体会。做这种视觉检测项目算法模型的mAP并不是项目的全部真正决定落地效果的反而是那些“看起来不起眼”的部分——数据标注的规则统一性、差异场景的覆盖度、训练指标的选择偏向、部署时线程模型的合理性。你在这些细节上花的时间最后都会体现在系统稳定性上。如果你正在做类似的检测项目我建议你把一半以上的时间留给数据和工程不要沉迷于换模型提效果。先把数据搞扎实模型效果自然就上来了。